Programme d'étude sur le C++ bas niveau n° 3 : la Pile

L'objectif de cette série d'articles d'Alex Darby sur la programmation « bas-niveau » est de permettre aux développeurs ayant déjà des connaissances de la programmation C++ de mieux comprendre comment ses programmes sont exécutés en pratique. Ce troisième article explique le rôle et le fonctionnement de la Pile, son usage lors de l'appel d'une fonction, la gestion des variables locales ainsi que la gestion de la valeur de retour d'une fonction.

Programme d'étude sur le C++ bas niveau n° 3 : la Pile

:fleche: Connaissiez-vous bien le fonctionnement de la Pile et des appels de fonctions ?
:fleche: Connaissez-vous d'autres détails important mais mal connus sur la Pile ?

Retrouver l'ensemble des articles de cette série sur la page d'index.

Article très intéressant ! :ccool:

Néanmoins je me demande à quoi servent les 64 octets réservés au début de la Stack Frame :/

En tout cas ça à l'air très pratique pour hacker (sens premier du terme bien-sur)

c'est quoi le sens premier et le sens second du terme ??

Il fait référence au white hack (modifier du code) et black hack (piratage)

En fait, si les 64 octets ne sont jamais utilisés, tu peux y inscrire du code asm et modifier le code original pour qu'il appelle ton code.
La recherche de zones de codes 'vides' est essentielle car il y a beaucoup d'adresses/saut relatifs et donc modifier la longueur du code peut avoir des effets de bords.

hum ok intéréssant

D'après un commentaire sur le site original, les 64 octets sont pour le "Edit and Continue" du debugger.

Aussi, il y a une erreur dans l'article, qui a été traduite telle quelle: La convention d'appel pour les fonctions non-membres / C n'est pas stdcall, mais cdecl.

Je dois bien avouer que n'étant pas du tout un spécialiste des fonctions d'appels, j'aurais du mal à me prononcer.

Premier point, dans une traduction, on traduit, on modifie pas le texte :) S'il y a une erreur, on laisse... (bon, ok, on laisse pas totalement, on met une note de traduction pour prévenir le lecteur. Et on prévient l'auteur. Mais on ne modifie pas les propos de l'auteur)

Pour cette histoire de fonction d'appel, ça me semble pas si évident (et faux de la part de l'auteur). Une petite recherche très rapide me le confirme.
A priori, pour linux, gcc utilise bien cdecl par défaut, mais sous windows (comme dans l'article), c'est bien stdcall. Il est également possible de choisir le type d'appel

Code:

---

1 2 3 4 5 6 7

// avec gcc type __attribute__((cdecl)) nom (paramètres) type __attribute__((stdcall)) nom (paramètres)   // avec VS type __cdecl nom (paramètres) type __stdcall nom (paramètres)

---

Bref, je me prononce pas, mais cela ne me semble pas faux (au pire, incomplet)

C'est bien à une note de traducteur que je pensais.

Mais mon argument ultime, c'est que le désassemblage montré sur les captures montre bien la convention d'appel cdecl. Le ret est tout seul (en stdcall, il aurait un paramètre) et l'appelant fait un add esp, 4 après l'appel pour nettoyer la pile (ce qu'il ne fait pas en stdcall).

La NdT me paraît donc tout indiquée.

L'auteur est déjà prévenu, par le premier commentaire de son article. Vieux de plus d'un an.