Discussion :

[LunaVorax]

Bonjour tout le monde !

Je suis un grand débutant en programmation et j'aimerais un jour (comme certains de mon âge) apprendre le reverse-engineering.

Seulement, comme souvent chez les débutants, je ne sais pas par où commencer et, qui plus est, j'ai du mal à trouver de l'information sur le sujet. Je ne parviens pas à trouver de réponses claires et précises sur ce sujet et je me retrouve toujours dans des réponses vagues « Il faut apprendre l'assembleur x86 mais il n'y a pas que ça » ou encore « C'est quelque chose de long et compliqué » comme si l'on voulait me décourager plutôt que de me donner une bride d'information.

Aussi à la grande question « Pourquoi veux-tu apprendre ça ? », je répondrais avec la même intelligence « Parce que ». Je pense avoir dépassé le stade des lamerz qui veulent à tout prix apprendre à cracker des logiciels et ce qui m'intéresse plutôt ici serait de tenter de recréer le moteur d'un jeu DOS 16bits/Windows 32bit des années 90 (à l'instar du logiciel ScummVM).

Aussi, après tout ce blabla, je viens poster une question simple.

Apprendre l'assembleur x86 sera-t-il suffisant pour commencer à effectuer le reverse engineering d'un petit logiciel à l'aide de IDA 4.9 par exemple ? Les cours présents sur developpez.com sont-ils suffisants pour ce sujet ?

Je suis actuellement en train d'apprendre à utiliser la bibliothèque SDL avec le langage C, aussi j'avais prévu que mon parcours d'apprentissage serait celui-ci :
C -> SDL -> C++ -> ASM x86

Voilà ! Je pense que j'ai dit tout ce que je voulais.
Je vous remercie infiniment par avance pour vos réponses et votre intérêt !

[Obsidian]

Bonsoir et bienvenue.

comme si l'on voulait me décourager plutôt que de me donner une bride d'information.

En fait, c'est surtout parce qu'il n'y a pas, à ma connaissance, de méthode officielle de rétro-ingénierie, et qu'en plus, c'est très souvent à la limite du légal. Le code de la propriété intellectuelle définit un cadre strict et très mince dans lequel il est autorisé de se livrer à ce genre de pratique, même si c'est sans volonté de pirater.

Toutefois, il faut distinguer rétro-ingénierie et désassemblage. En général, on utilise le deuxième pour mener à bien la première, mais ce n'est pas implicite : tout dépend de ce que tu cherches à analyser.

Il faut également être conscient que l'assembleur, en soi, n'est pas un « langage comme un autre ». Les langages compilés de plus haut niveau résolvent le code écrit en langage machine. C'est pour cela qu'il te faut désassembler un exécutable en langage machine pour voir comment il fonctionne : parce qu'il ne subsiste rien de plus haut niveau dans l'exécutable. Tu ne peux donc pas a priori savoir quel est le langage du programme source. Tu peux en revanche réunir suffisamment d'indices pour le deviner, mais cela ne t'apportera pas grand chose.

Apprendre l'assembleur x86 sera-t-il suffisant pour commencer à effectuer le reverse engineering d'un petit logiciel à l'aide de IDA 4.9 par exemple ?

En soi oui, mais il te faudra quand même beaucoup de pratique, d'une part, et cela dépendra également du « petit logiciel » en question. Par ailleurs, quasiment tous les logiciels sont écrits dans des langages de haut niveau. Si certaines routines sont résolues en langage machine de manière très efficace, la majeure partie du code risque d'être assez redondante : cadres de pile, référence aux variables locales, etc. et il faudra faire attention de ne pas se perdre.

Sache également que l'assembleur x86 bits est assez différent de l'assembleur x86 32 bits, voire 64. On peut pratiquement les considérer comme des langages différents, au même titre que le C et le C++.

C -> SDL -> C++ -> ASM x86

C'est un bon programme mais cela risque de te prendre plusieurs années si tu comptes le faire sérieusement (connaître les langages sur le bout des doigts, respecter les normes, etc.).

Je te conseille de voir l'assembleur en même temps que le C ou un peu avant si tu le peux. Cela t'aidera beaucoup à comprendre les concepts qui ont été choisis.

Enfin, dernier conseil : ne fais pas d'assembleur sans voire l'architecture des ordinateurs avec. L'assembleur est le langage du micro-processeur lui-même et ce que tu vas écrire va être intimement lié à l'environnement matériel. Si tu comprends bien à quoi correspond chaque notion, alors cela va devenir passionnant (l'âge d'or était, à mon goût, les années 80 et les huit bits), sinon cela risque de devenir vite très abscons.

[Neitsa]

Bonjour,

Une très bonne connaissance de l'assembleur x86 (x64) est une condition sine qua non pour le reverse-engineering (RE) sous la plupart des O.S répandus.

Ceci dit, l'assembleur ne fait pas tout et il est impossible de s'abstraire du système sous-jacent (Windows, Linux, etc.), parce que chaque système a ces propres spécificités: format d'exécutables (PE, ELF, etc.), API système, mécanismes internes (allocation, scheduling, etc.).

Pour le RE, l'assembleur n'est donc qu'une base nécessaire sur laquelle viennent se greffer plein d'autres concepts et connaissances qu'il faut mettre ensembles pour avoir une idée générale de la cible que l'on étudie.

En ce qui concerne les langages, le C et le C++ sont très importants du fait de leurs parts dominantes dans le monde de la programmation et aussi du fait qu'ils soient "proches" de la machine.

Tout comme Obsidian, je te conseillerais de faire un apprentissage du C en parallèle de l'assembleur x86. Compiler tes propres programmes en C et voir à quoi ils ressemblent une fois désassemblés (attention au C++ qui peut être assez difficile à comprendre une fois désassemblé).

Bienvenue dans le monde passionnant du RE

[LunaVorax]

Merci pour vos réponses, j'en suis très heureux

Effectivement, l'on m'avait conseillé d'apprendre l'assembleur avec le C car "cela sert à comprendre comment le C fonctionne" ou "pourquoi le C est comme ça", je ne me souviens plus très précisément des propos.

Une autre personne compétente dans ce domaine m'a assuré qu'il n'étais pas nécessaire d'apprendre l'assembleur car "lire l'assembleur est plus simple que l'écrire" en parlant de ce que l'on obtenait en désassemblant un logiciel. Cela m'a beaucoup étonné et m'a semblé très étrange.

Compiler tes propres programmes en C et voir à quoi ils ressemblent une fois désassemblés

C'est un conseil d'une simplicité et d'une évidence absolue... et pourtant je n'y avais pas pensé une seule seconde. Merci infiniment

Merci encore pour votre aide, j'attends de voir si d'autres personnes ont d'autres conseils.

[Obsidian]

Une autre personne compétente dans ce domaine m'a assuré qu'il n'étais pas nécessaire d'apprendre l'assembleur car "lire l'assembleur est plus simple que l'écrire" en parlant de ce que l'on obtenait en désassemblant un logiciel. Cela m'a beaucoup étonné et m'a semblé très étrange.

Ça, c'est vrai pour toutes les langues et langages. Je ne sais pas si c'est le meilleur conseil, mais en lire beaucoup aide à bien comprendre, c'est certain. Cela dit, on ne trouve plus beaucoup, aujourd'hui, d'assembleur écrit à la main. S'habituer au code produit par les compilateurs n'est pas forcément ce qu'il y a de mieux…

Cela dit, si tu t'y attaches, le mieux est d'avoir sous les yeux une table telle que celle-ci de toutes les instructions. Il peut il y en avoir un certain nombre, mais ce nombre est toujours fini. Le mieux est un tableau qui te donne verticalement la liste des instructions et horizontalement les modes d'adressage, avec les codes-opération dans les cases, comme pour le 6809, pages 31 et 32. Quoi que mettre cela en forme pour le x86, ça risque de ne pas être évident.

C'est un conseil d'une simplicité et d'une évidence absolue... et pourtant je n'y avais pas pensé une seule seconde. Merci infiniment

Si tu utilises GCC, c'est l'option -S

Merci encore pour votre aide, j'attends de voir si d'autres personnes ont d'autres conseils.

À bientôt.