J'ai lu cette citation (ci-dessous) plusieurs fois, plus récemment ici, et je suis continuellement perplexe sur la façon dont dd
peut être utilisé pour patcher n'importe quoi sans parler d'un compilateur :
Le système Unix que j'utilisais à l'école, il y a 30 ans, était très limité en RAM et en espace disque. En particulier, le
/usr/tmp
système de fichiers était très petit, ce qui entraînait des problèmes lorsque quelqu'un tentait de compiler un programme volumineux. Bien sûr, les étudiants n'étaient pas censés écrire de "grands programmes" de toute façon ; les grands programmes étaient généralement des codes sources copiés de "quelque part". Beaucoup d'entre nous ont copié/usr/bin/cc
vers/home/<myname>/cc
, et utilisédd
patcher le binaire pour utiliser/tmp
au lieu de/usr/tmp
, qui était plus grand. Bien sûr, cela n'a fait qu'aggraver le problème - l'espace disque occupé par ces copies importait à l'époque, et maintenant/tmp
rempli régulièrement, empêchant même les autres utilisateurs de modifier leurs fichiers. Après avoir découvert ce qui s'est passé, les administrateurs système ont fait unchmod go-r /bin/* /usr/bin/*
qui a "résolu" le problème et supprimé toutes nos copies du compilateur C.
(C'est moi qui souligne)
Le dd
man-page ne dit rien sur les correctifs et ne pense pas qu'il puisse être réutilisé pour le faire de toute façon.
Les binaires pourraient-ils vraiment être patchés avec dd
? Y a-t-il une signification historique à cela ?
Réponse acceptée :
Essayons. Voici un programme C trivial :
#include <stdio.h>
int main(int argc, char **argv) {
puts("/usr/tmp");
}
Nous allons l'intégrer dans test
:
$ cc -o test test.c
Si nous l'exécutons, il affiche "/usr/tmp".
Découvrons où "/usr/tmp
” est en binaire :
$ strings -t d test | grep /usr/tmp
1460 /usr/tmp
-t d
imprime le décalage en décimal dans le fichier de chaque chaîne qu'il trouve.
Créons maintenant un fichier temporaire avec juste "/tmp