Question:
Quelles sont les différences qualitatives entre le code de rétro-ingénierie x64 / Win64 et le code x32 / Win32?
Rolf Rolles
2013-03-27 06:16:16 UTC
view on stackexchange narkive permalink

De nombreux ingénieurs inverseurs professionnels passent leurs journées à regarder du code 32 bits compilé pour Windows, et la familiarité engendre la maîtrise. Quelles sont les différences de haut niveau entre la rétro-ingénierie des programmes Windows 64 bits par rapport aux programmes 32 bits?

Je parle de choses qui me regarderont tout le temps en face, par opposition à, disons , comportement légèrement différent des API. Par exemple,

  • Les compilateurs 64 bits utilisent-ils des optimisations particulières rarement vues dans un contexte 32 bits?
  • Vais-je voir des instructions dans les programmes 64 bits qui sont différent ou inexistant dans le jeu d'instructions 32 bits?
  • Y a-t-il quelque chose en particulier que j'ai besoin de savoir sur la prise en charge de l'outil sur x64 par rapport à x86?
Trois réponses:
#1
+12
mncoppola
2013-03-29 09:22:41 UTC
view on stackexchange narkive permalink

L'une des plus grandes différences entre x86 et x86_64 est l'introduction de l'adressage relatif à RIP. Semblable à ARM 32 bits, les données peuvent maintenant être (facilement) référencées à un décalage par rapport à la valeur RIP actuelle.

Par exemple, voici les premières instructions de __libc_csu_init () dans un programme x86:

  08048420 <__libc_csu_init>: 8048420: 55 push% ebp 8048421: 57 push% edi 8048422: 31 ff xor% edi,% edi 8048424: 56 push% esi 80484258 push fe ff ff call 8048324 <__x86.get_pc_thunk.bx> 804842b: 81 c3 79 12 00 00 add $ 0x1279,% ebx 8048431: 83 ec 1c sub $ 0x1c,% esp 8048434: 8b 6c 24 30 mov 0x30% ebp (esp) 8048438: 8d b3 0c ff ff ff lea -0xf4 (% ebx),% esi  

Et le voici sur x86_64 (notez 0x40050a et 0x400511):

  0000000000400500 <__libc_csu_init>: 400500: 48 89 6c 24 d8 mov% rbp, -0x28 (% rsp) 400505: 4c 89 64 24 e0 mov% r12, -0x20 (% rsp) 40050a: 48 8d 2d 97 01 20 00 lea 0x200197 (% rip), % rbp # 6006a8 <__init_array_end> 400511: 4c 8d 25 88 01 20 00 lea 0x200188 (% rip),% r12 # 6006a0 <__frame_dummy_init_array_entryAili 5hcdvhg 400511: 4c 8d 25 88 01 20 00 lea 0x200188 (% rip),% r12 # 6006a0 <__frame_dummy_init_array_entryAili 5hcddvhg 400: 48 x 248% rbp: 89 x 248% mov% r13, -0x18 (% rsp) 400522: 4c 89 74 24 f0 mov% r14, -0x10 (% rsp) 400527: 4c 89 7c 24 f8 mov% r15, -0x8 (% rsp)  

Vous trouverez plus d'informations sur cette convention ici: http://www.codegurus.be/codegurus/programming/riprelativeaddressing_en.htm

Le lien est mort ~~~
#2
+10
Robert Mason
2013-03-27 08:18:55 UTC
view on stackexchange narkive permalink

Une des grandes choses qui sera différente est la convention d'appel - sur 64 bits, certains paramètres sont passés dans les registres; voir http://en.wikipedia.org/wiki/X86_calling_conventions et les références

D'autres choses évidentes incluent les registres plus grands, plus de registres SSE et l'arithmétique 64 bits ( mov QWORD / movq et al.). Au-delà de ce à quoi vous vous attendez, les choses sont en fait assez similaires. Voir http://en.wikipedia.org/wiki/X86-64#Architectural_features pour un aperçu des grandes différences - la plupart des autres nouvelles fonctionnalités sont plus importantes pour le code de l'espace noyau que pour le code de l'espace utilisateur. . Au-delà des extensions logiques des instructions 32 bits aux instructions 64 bits, le jeu d'instructions reste assez statique.

#3
+1
ekse
2013-08-16 00:53:54 UTC
view on stackexchange narkive permalink

En ce qui concerne la prise en charge des outils, Ollydbg (et Immunity Debugger) ne prend pas en charge x64. Windbg est probablement la meilleure alternative gratuite.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...