Después de cargar un archivo ejecutable en gdb, ¿cómo puedo interrumpir en el punto de entrada, antes de que se ejecute la primera instrucción?Parando en la primera instrucción de código máquina en GDB
El ejecutable que estoy analizando es una pieza de malware cifrada, por lo que break main no hace absolutamente nada.
El comando info files podría darle una dirección se puede romper en:
(gdb) info files
...
Entry point: 0x80000000
...
(gdb) break *0x80000000
(gdb) run
"b _start" o "b start" podría o no funcionar. De lo contrario, averigüe la dirección del punto de entrada con readelf/objdump y utilice "b *0x<hex address>".
Lo raro es que se rompe en el punto de entrada especificado en el encabezado y el desmontaje se ve bien, pero un desmontaje directo del ejecutable muestra basura. Pero respondiste la pregunta. ;) Por cierto, ¡me siento honrado de recibir una respuesta de un chico de Hex-Rays! – rickythefox
'_init' de' cru/init-first.c' parece ejecutarse incluso antes de '_start' o de la dirección de entrada en GCC 4.8 glibc 2.19 Ubuntu 14.04 cuando intento' b _init; correr' en GDB. Que esta pasando? –
Preguntado en: http://stackoverflow.com/questions/31379422/why-is-init-from-glibcs-csu-init-first-c-called-before-start-even-if-start-i –
Después de cargar un ejecutable en gdb, ¿cómo rompo en el punto de entrada, antes de que se ejecute la primera instrucción?
puede encontrar qué funciones se llaman antes int main() con set backtrace past-main on y después de encontrar a establecer un punto de interrupción en ellas y reiniciar su programa:
>gdb -q main
Reading symbols from /home/main...done.
(gdb) set backtrace past-main on
(gdb) b main
Breakpoint 1 at 0x40058a: file main.cpp, line 25.
(gdb) r
Starting program: /home/main
Breakpoint 1, main() at main.cpp:25
25 a();
(gdb) bt
#0 main() at main.cpp:25
#1 0x0000003a1d81ed1d in __libc_start_main() from /lib64/libc.so.6
#2 0x0000000000400499 in _start()
(gdb) b _start
Breakpoint 2 at 0x400470
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/main
Breakpoint 2, 0x0000000000400470 in _start()
La solución obviedad es utilizar el efecto secundario de la falta de un punto de ruptura:
$ gdb /bin/true
Reading symbols from /bin/true...(no debugging symbols found)...done.
(gdb) b *0
Breakpoint 1 at 0x0
(gdb) r
Starting program: /bin/true
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x0
(gdb) disas
Dump of assembler code for function _start:
=> 0xf7fdd800 <+0>: mov eax,esp
0xf7fdd802 <+2>: call 0xf7fe2160 <_dl_start>
End of assembler dump.
Idea tomada de this answer at RE.SE.
Curiosamente, no pudo usar puntos de corte en GDB en una aplicación Go hasta su solución. Cualquier otro método no funciona. –
funcionó bien para mí también, pero incluso 'stepi' estaba fallando, así que también tuve que usar' eliminar puntos de interrupción' para continuar. – Ped7g
@ Ped7g, puede eliminar el punto de corte exacto que configuró para fallar, en el ejemplo anterior sería 'd 1'. No es necesario borrar todo. – Ruslan
Comenzando con GDB 8.1, hay un comando especial para esto: starti. Ejemplo sesión de GDB:
$ gdb /bin/true
Reading symbols from /bin/true...(no debugging symbols found)...done.
(gdb) starti
Starting program: /bin/true
Program stopped.
0xf7fdd800 in _start() from /lib/ld-linux.so.2
(gdb) x/5i $pc
=> 0xf7fdd800 <_start>: mov eax,esp
0xf7fdd802 <_start+2>: call 0xf7fe2160 <_dl_start>
0xf7fdd807 <_dl_start_user>: mov edi,eax
0xf7fdd809 <_dl_start_user+2>: call 0xf7fdd7f0
0xf7fdd80e <_dl_start_user+7>: add ebx,0x1f7e6
Por 'lldb', véase: [? ¿Cómo detener depurador justo después de la ejecución] (http://reverseengineering.stackexchange.com/q/9583/12021) – kenorb