Comment puis-je déterminer l'emplacement du code désassemblé dans un exécutable?

Question

J'ai un fichier exécutable (C ++, i386, compilé sous MacOS / X Tiger, si c'est important) qui contient un bogue. Le correctif pour le bogue est simple: il y a un endroit dans le code où il appelle fork () et ce ne devrait pas être le cas. Parce que le correctif est simple et qu’il serait difficile de recompiler l’exécutable à partir de rien (ne le demandez pas), j’aimerais simplement corriger directement le fichier exécutable / binaire.

Comme première étape, j'ai lancé "otool -tV MyExecutableName". sur mon exécutable, et voilà, je l'ai trouvé dans la sortie de désassemblage:

./MyExecutableName:
(__TEXT,__text) section
[... many lines omitted ...]
0002ce0d        subl    <*>x10,%esp
0002ce10        calll   0x0051adac
0002ce15        movzbl  0x14(%ebp),%esi
0002ce19        calll   0x00850ac9      ; symbol stub for: _fork
0002ce1e        cmpl    <*>x00,%eax
0002ce21        jll     0x0002cf02
0002ce27        jle     0x0002ce34
[... many more lines omitted ...]

Donc, ce que je voudrais faire, c'est remplacer l'opcode à la ligne 0002ce19, de sorte qu'au lieu d'appeler _fork, il saute simplement et inconditionnellement au cas d'échec (c'est-à-dire qu'il devrait agir comme si fork () avait retourné -1 )

Malheureusement, je suis un débutant en matière de correction de balisage / désassemblage, je ne suis donc pas sûr de savoir comment procéder. En particulier, mes questions sont les suivantes:

1) Quels octets devrais-je écrire aux emplacements 0002ce19 à 0002xe1d pour obtenir ce que je veux? Je suppose que ce serait l’équivalent assemblé de "jmp 0x0002cf02", mais comment puis-je savoir ce que sont ces octets?

2) Les décalages imprimés par " otool -tV " semblent être des décalages dans le segment __TEXT de l'exécutable. Comment puis-je déterminer le delta d'octet entre les décalages imprimés et le haut du fichier, afin de pouvoir éditer / corriger les octets corrects dans le fichier?

Merci pour tout conseil que vous pouvez donner!

Answer 1

Je ne connais pas bien MacOS / X, mais je peux vous donner quelques conseils.

La bonne façon de résoudre ce problème consiste à utiliser un désassembleur pour patcher votre fichier.

0002ce19        calll   0x00850ac9

peut être remplacé par

0002ce19        movl   eax, -1 ; mov eax, 0xFFFFFFFF

Les décalages que vous voyez sont relatifs, vous ne pouvez donc pas les trouver dans le fichier.
Par exemple, jll 0x0002cf02 est en réalité jll 0x000000DF

Si je ne me trompe pas, le bloc de code ci-dessous

0002ce19        calll   0x00850ac9      ; symbol stub for: _fork
0002ce1e        cmpl    
0x  E8   AB3C8200
    83F8 00
    0F8C DF000000
    0F84 0B000000
x00,%eax
0002ce21        jll     0x0002cf02
0002ce27        jle     0x0002ce34

aura cette forme assemblée (20 octets):

<*>

Si cette séquence est unique dans le fichier, vous pouvez essayer de remplacer E8AB3C8200 par B8FFFFFFFF , si vous ne pouvez pas utiliser de désassembleur.

Answer 2

Le plus simple serait probablement de mettre mov $ -1,% eax à la place de l'appel. Vous pouvez trouver à quels octets cela correspond en le mettant dans un fichier .s, en le compilant et en vidant le résultat, en le complétant avec nops s'il est plus court que l'emplacement du correctif. Je reçois "b8 ff ff ff ff", ce qui convient parfaitement.

Vous pouvez trouver le début de __ TEXT en exécutant otool -l et en recherchant le décalage.

Answer 3

otx et Hex Fiend seront vos amis. otx vous donnera un désassemblage avec des décalages relatifs aux fichiers, et Hex Fiend vous laissera patcher le saut. N'oubliez pas que 0x90 correspond à l'opcode (x86) pour NOP. Par conséquent, 9090909090 constitue un remplacement approprié pour l'appel fork (). (Gardez simplement à l'esprit que cela ne générera pas de valeur de retour, donc quelque chose d'étrange peut aboutir à eax.)