Utiliser gdb pour un code d’assemblage en une seule étape en dehors de l’exécutable spécifié provoque une erreur “impossible de trouver des limites de la fonction en cours”

Je ne suis pas l’exécutable cible de gdb et je n’ai même pas de stack correspondant à cette cible. Je veux quand même effectuer une seule étape pour pouvoir vérifier ce qui se passe dans mon code d’assemblage, car je ne suis pas expert en assemblage x86. Malheureusement, gdb refuse de faire ce simple débogage au niveau de l’assemblage. Cela me permet de définir et d’arrêter le point d’arrêt approprié, mais dès que j’essaye de faire un pas en avant, gdb signale l’erreur “Impossible de trouver les limites de la fonction actuelle” et l’EIP ne change pas.

Détails supplémentaires:

Le code machine a été généré par les instructions gcc asm et je l’ai copié à l’emplacement de la mémoire du kernel où il s’exécute, à partir de la sortie de objdump -d. Cela ne me dérangerait pas un moyen simple d’utiliser un chargeur pour charger mon code object dans une adresse déplacée, mais gardez à l’esprit que le chargement doit être effectué dans un module du kernel.

Je suppose qu’une autre alternative serait de produire un faux module de kernel ou un fichier d’informations de débogage à donner à gdb, pour lui faire croire que cette zone se trouve dans le code du programme. gdb fonctionne bien sur l’exécutable du kernel lui-même.

(Pour ceux qui veulent vraiment savoir, j’insère du code lors de l’exécution dans l’espace de données du kernel Linux à l’intérieur d’une VM VMware et le débogue à partir du débogage à distance du kernel via le stub gdb intégré de VMware Workstation. Je suis un étudiant diplômé en sécurité qui écrit un prototype.)

(Je peux définir un point d’arrêt pour chaque instruction à l’intérieur de mon assembly. Cela fonctionne mais deviendrait très laborieux, car la taille des instructions d’assemblage x86 varie et l’emplacement de l’assembly change à chaque redémarrage.)

Vous pouvez utiliser stepi ou nexti (qui peut être abrégé en si ou ni ) pour parcourir votre code machine.

Au lieu de gdb , lancez gdbtui . Ou lancez gdb avec le commutateur -tui . Ou appuyez sur Cx Ca après avoir entré gdb . Maintenant, vous êtes en mode TUI de GDB.

Entrez layout asm pour que l’assemblage d’affichage de la fenêtre supérieure – cela suivra automatiquement votre pointeur d’instruction, bien que vous puissiez également modifier les frameworks ou faire défiler pendant le débogage. Appuyez sur Cx s pour accéder au mode SingleKey, où la run continue up down finish etc. sont abrégées en une seule touche, ce qui vous permet de parcourir votre programme très rapidement.

    + ------------------------------------------------- -------------------------- +
 B +> | 0x402670  push% r15 |
    | 0x402672 
 mov% edi,% r15d |
    | 0x402675 
 push% r14 |
    | 0x402677 
 push% r13 |
    | 0x402679 
 mov% rsi,% r13 |
    | 0x40267c 
 push% r12 |
    | 0x40267e 
 push% rbp |
    | 0x40267f 
 push% rbx |
    | 0x402680 
 sub $ 0x438,% rsp |
    | 0x402687 
 mov (% rsi),% rdi |
    | 0x40268a 
 movq $ 0x402a10,0x400 (% rsp) |
    | 0x402696 
 movq $ 0x0,0x408 (% rsp) |
    | 0x4026a2 
 movq $ 0x402510,0x410 (% rsp) |
    + ------------------------------------------------- -------------------------- +
 processus enfant 21518 Dans: Ligne principale: ??  PC: 0x402670
 (gdb) fichier / opt / j64-602 / bin / jconsole
 Lecture des symboles de /opt/j64-602/bin/jconsole...done.
 (pas de symboles de débogage trouvés) ... terminé.
 (gdb) layout asm
 (gdb) commence
 (gdb)

La chose la plus utile que vous puissiez faire ici est display/i $pc , avant d’utiliser stepi comme cela a déjà été suggéré dans la réponse de R Samuel Klatchko. Ceci indique à gdb de désassembler l’instruction en cours juste avant d’imprimer l’invite à chaque fois; alors vous pouvez simplement continuer à stepi sur Entrée pour répéter la commande stepi .

(Voir ma réponse à une autre question pour plus de détails – le contexte de cette question était différent, mais le principe est le même)