He leído esta cita (a continuación) varias veces, la más reciente aquí, y me sorprende continuamente cómo dd se puede usar para parchear cualquier cosa mucho menos un compilador:
El sistema Unix que usaba en la escuela, hace 30 años, era muy limitado en RAM y espacio en disco. Especialmente, el /usr/tmp El sistema de archivos era muy pequeño, lo que generaba problemas cuando alguien intentaba compilar un programa grande. Por supuesto, no se suponía que los estudiantes escribieran "programas grandes" de todos modos; los programas grandes eran típicamente códigos fuente copiados de "algún lugar". Muchos de nosotros copiamos /usr/bin/cc a /home/<myname>/cc , y usó dd parchear el binario para usar /tmp en lugar de /usr/tmp , que era más grande. Por supuesto, esto solo empeoró el problema:el espacio en disco ocupado por estas copias sí importaba en esos días, y ahora /tmp se llenaba regularmente, impidiendo que otros usuarios incluso editaran sus archivos. Después de descubrir lo que sucedió, los administradores de sistemas hicieron un chmod go-r /bin/* /usr/bin/* que "solucionó" el problema y eliminó todas nuestras copias del compilador C.
(Énfasis mío)
El dd La página de manual no dice nada sobre la aplicación de parches y no creo que pueda ser rediseñada para hacer esto de todos modos.
¿Podrían los binarios realmente parchearse con dd? ? ¿Hay algún significado histórico para esto?
Respuesta aceptada:
Vamos a intentarlo. Aquí hay un programa en C trivial:
#include <stdio.h>
int main(int argc, char **argv) {
puts("/usr/tmp");
}
Construiremos eso en test :
$ cc -o test test.c
Si lo ejecutamos, imprime “/usr/tmp”.
Averigüemos dónde está “/usr/tmp ” está en binario:
$ strings -t d test | grep /usr/tmp
1460 /usr/tmp
-t d imprime el desplazamiento en decimal en el archivo de cada cadena que encuentra.
Ahora hagamos un archivo temporal con solo “/tmp