JMP à l'adresse absolue (op codes)

Je suis en train de coder un exe packer/protecteur comme un moyen d'en apprendre plus sur l'assembleur, c++, et comment PE fichiers de travail. J'ai actuellement ai eu de travail de sorte que la section contenant l'EP est XORed avec une clé et une nouvelle section est créée qui contient le code de décryptage. Tout fonctionne très bien sauf quand j'essaie de le JMP à l'origine du PE après le déchiffrement.

Fondamentalement, je fais ceci:

DWORD originalEntryPoint = optionalHeader->AddressOfEntryPoint;
//-- snip -- //
    crypted.put(0xE9);
 crypted.write((char*)&orginalEntryPoint, sizeof(DWORD));

Mais au lieu de lui sauter au point d'entrée, ollydbg montre que ce code démonte:

00404030   .-E9 00100000    JMP 00405035 ; should be 00401000 =[

et quand j'essaie de la modifier manuellement dans olly le nouveau opcode montre que

00404030    -E9 CBCFFFFF    JMP crypted.00401000

Où avez-0xCBCFFFFF venir? Comment puis-je générer que du C++?

À ceux qui pourraient tomber sur ce, il y a une question similaire, au cours de RÉ.SE où j'ai fourni une explication détaillée: reverseengineering.stackexchange.com/questions/19459/...

OriginalL'auteur Christopher Tarquini | 2009-10-09

  1. 5

    Je pense que E9 est un opcode pour un parent de saut: son opérande indique une distance relative à sauter, plus ou moins depuis le début de la prochaine instruction.

    Si vous voulez l'opérande de spécifier une adresse absolue, vous auriez besoin d'un opcode différent.

    Toutes les idées de ce qui peut être un remplacement pour E9?
    cela peut vous aider dans votre recherche de: ref.x86asm.net
    Les sauts sont généralement relatif. Il y a un opcode EA pour un saut à un absolu adresse de loin, et opcodes pour les sauts indirects adresse (si l'opérande indique l'emplacement mémoire qui contient l'adresse de sauter aux).
    Ce n'ai pas la réponse à la question, vient de confirmer que l'OP a eu la mauvaise réponse.
    La question était: "Où avez-0xCBCFFFFF?" De toute façon, apparemment, l'OP compris la réponse, et/ou qui ont été satisfaits par EA dans le commentaire.

    OriginalL'auteur ChrisW

  2. 18

    vous pouvez utiliser:

    mov eax,DESTINATION_VA
jmp eax                ; pick any register the destination doesn't care about

    ou

    push DESTINATION_VA
ret                    ; not recommended for performance

    Cela et la prochaine à 16 ret instructions de remonter l'arbre d'appel supérieur à cette profondeur mispredict, sauf s'ils ont été poussés hors de l'adresse de retour prédicteur de la pile par un approfondissement de l'appel en profondeur. (Les Processeurs actuels ont généralement un 16-entrée prédicteur de la pile).

    relative E9 jmp encodage est utilisé comme ceci:

    CURRENT_RVA: jmp (DESTINATION_RVA - CURRENT_RVA - 5 [sizeof(E9 xx xx xx xx)])

    push + ret est la plus petite solution si vous avez de la VA, de l'adresse et de l'image n'est pas déplacée, mais c'est toujours 6 octets de sorte qu'il est plus grand qu'un direct jmp rel32.

    Registre indirect est probablement le plus efficace si vous ne pouvez pas utiliser une normale direct jmp.

    merci pour savin' me!
    push/ret déséquilibre de l'adresse de retour prédicteur de la pile. mov eax,addr / jmp eax est à seulement 1 octet plus et n'ont pas ce problème. Voir aussi l'Appel d'une absolue pointeur dans la machine x86 code.
    Je suis à la recherche d'une méthode similaire pour la version 64 bits de l'adresse de l'espace, avec op codes.

    OriginalL'auteur Bartosz Wójcik

  3. 4

    opcode absolue indirects saut est FF + 4byte adresse. C'est le plus souvent utilisé pour jumptables des adresses stockées dans les données.

    Adresses absolues ne nécessite un déplacement lorsqu'il n'est pas chargé à l'adresse prévue, de manière relative, les adresses sont généralement préférés. Code relative des sauts est également de 2 octets pour les plus petits.

    Intel optimisation manuel indique que le processeur s'attend call et ret à être utilisés en paires, de sorte que le ret sans appel suggéré dans la réponse 2 serait la cause de ce qu'ils appellent un "performances".

    Aussi, si le code n'a pas été chargé à la même adresse que le compilateur suppose, de la ret serait probablement planter le programme. Il serait plus sûr pour calculer une adresse relative.

    peut-être vous dire FF 25 4byte.. FF 4 octets n'a aucun sens.
    il a encore un sens depuis FF est l'opcode et nous savons que le mnémonique est jmp. Il pourrait être FF /4 ou FF /5 puisqu'ils sont tous deux de saut absolu, indirect, l'un étant un près, et l'autre, loin de saut. Mais oui, FF 25 aa bb cc dd est de savoir comment vous observer FF /4 (le plus commun des deux) en code machine.
    Le dernier paragraphe n'est pas de droit: push imm32 / ret ne tombent pas en panne, déménager le code ne va pas changer l'objectif absolu de l'adresse que ret sauts de. Le problème, c'est de la performance: déséquilibrer l'adresse de retour de la pile de certains rendements futurs mispredict. Un mov reg,imm32 + 2 octets de registre indirect saut est probablement votre meilleur pari (plutôt que de charger un pointeur de mémoire) si pour quelque raison vous ne pouvez pas encoder un jmp rel32 depuis une adresse connue,. l'Appel d'une absolue pointeur dans la machine x86 code.
    Il serait bon de mentionner une correspondance jmp opcode pour le mode 64 bits.

    OriginalL'auteur Ann