x86 saut à une adresse

Comme une mission pour une sécurité de classe, je suis en train d'utiliser __asm__("jmp 0xbffff994"); dans mon code, mais quand je l'ai démonter des choses dans gdb, l'instruction est changé à jmp 0xc8047e2a.
Aucune idée de pourquoi et comment puis-je accéder à une adresse particulière?

  • Pourquoi diable avez-vous besoin pour passer à une crue de l'adresse? Je vais avoir du mal à comprendre tout possible (non infâme) l'utilisation que.
  • Quel système utilisez-vous?
  • peu importe, sa question a été posée, nous allons essayer d'y répondre.
InformationsquelleAutor Martin | 2009-04-21
  1. 23

    Probablement parce que c'est un saut à une adresse relative, et l'éditeur de liens ou du chargeur a déplacé votre code. Essayez de mettre l'adresse dans une variable, puis faire:

    jmp dword [var]

    ou alternativement:

    push 0xbffff994
ret
    • que est la bonne réponse, notez également que: "mov eax, 0x11223344; jmp eax"; également le travail et est probablement la plus simple.
    • très vrai, mais il pourrait être à l'aide de fastcall (je ne suis pas sûr de la signification de 0xbffff994).
    • Le PUSH RET combinaison fonctionne! Merci!!!!
    • 0xbffff994 probable = un emplacement de la pile sur une machine linux 😛
    InformationsquelleAutor Mark
  2. 0

    Daniel Explique pourquoi votre saut n'est pas le même que vous avez programmée. Il a à voir avec les fichiers objets et de liaison.

    si vous souhaitez accéder à une adresse particulière, il est préférable de patch le saut à l'aide d'un Débogueur ou Désassembleur.

    InformationsquelleAutor toto
  3. 0

    Il est difficile de déterminer l'adresse exacte sur le temps de compilation, avez-vous essayé d'utiliser des étiquettes? Il est beaucoup plus fréquent pour les utiliser avec jmp.

    exemple:

    start:
 jmp exit

exit:
 ret
    InformationsquelleAutor John T
  4. 0

    Je vous conseille d'utiliser un éditeur hexadécimal et il suffit de changer la valeur, si c'est juste une chose.

    InformationsquelleAutor samoz
  5. 0

    Sur mon système (gcc version 4.2.4, Ubuntu), c'est bien sur le disassmbley (insight):

    int main() 
{ 
asm("jmp 0xbffff994"); 
return 0; 
};

    résultats de la disassmbley (insight):

     0x8048344 : lea 0x4(%esp),%ecx 
- 0x8048348 : et $0xfffffff0,%esp 
- 0x804834b : pushl -0x4(%ecx) 
- 0x804834e : push %ebp 
- 0x804834f : mov %esp,%ebp 
- 0x8048351 : push %ecx 
- 0x8048352 : jmp 0xbffff994 
- 0x8048357 : mov $0x0,%eax 
- 0x804835c : pop ecx 
- 0x804835d : pop %ebp 
- 0x804835e : lea -0x4(%ecx),%esp 
- 0x8048361 : ret
    • Je suppose que je démonte montre le décalage de la jmp, et non de sa réelle de la cible. (l'instruction jmp prend un décalage par rapport à l'eip lorsque vous lui donnez un 32-bit opérande immédiat).
    • Pourquoi voudriez-vous deviner qui? est-il un moyen de le tester? il est une interface graphique à l'aide de GDB ci-dessous.
    • Ou peut-être qu'il n'y a pas de réinstallation. Toutefois, si vous videz les opcodes avec l'assemblée, vous serez en mesure de voir le décalage.
    • Je vois ce 8048352: e9 3d 76 fb b7 jmp bffff994 <_end+0xb7fb6454> ne peut pas trouver le _end étiquette, mais il a l'air puissant fermer à la fin du programme.
    InformationsquelleAutor Liran Orevi