App - Système

bonjour,

comment débugger le binaire sachant qu’il ne contient pas de symboles, j’essaye de placer un breakpoint avec gdb mais j’arrive pas.

merci

Moi perso, j’ai plutôt installé une vm windows, récupéré le binaire via scp et debuggé avec immunity debugger.
Une fois que tu as ta solution, il faut l’utiliser sur le wrapper.sh.

Bon courage,

Salut Aelk,

je suis dessus moi aussi. Tu peux trouver l’addresse de main avec objdump sur le .obj :
$ objdump.exe -x -D ch72.obj | grep "<_main>"
00000020 <_main> :

C’est une adresse relative. Tu peux trouver le début de la section text avec le .exe :
objdump.exe -x -D ch72.exe | grep "<.text>"
00401000 <.text> :

Donc en principe main est à 0x00401020 et tu peux setter un break point avec : b *0x00401020

Le problème est que le gdb qui est fourni est un gdb 64 bits et qu’il part en vrille. Il faudrait gdb32.exe. Si un admin lis ce message, ce serait sympa d’installer gdb32.exe dans la jail. Merci :)

Bonjour,

Il n’est pas prévu d’installer gdb 32 bits sur la machine.
Par contre, vous avez cdb.exe :

Bon courage

Merci echo. Pour ma part, je suis habitué à gdb donc je travaille en local pour le moment.

On utilise les outils adaptés, c’est mieux, habitude ou pas . Debuggé un PE avec gdb n’a aucun sens.

je butte sur le même problème de débugger : gdb bof ici...
qd on se connecte, un message liste bien cdb dans les outils à disposition...
mais qd je fais cdb ou même cdb.exe... inconnu au bataillon !

Salut,

J’ai créé deux liens symboliques :

Tu peux donc utiliser cdb32.exe et cdb64.exe directement via le PATH.
Mais dans tous les cas, tu pouvais utiliser les full path que j’ai donné plus haut :

merci
effectivement avec cdb c’est plus facile de manipuler le .exe !
et une fois qu’on a compris comment utiliser le wrapper.sh...
ça marche !!
 🙂