Discussion :

[-Lyxx]

Bonsoir,
Aujourd'hui j'ai eu un cours d'archi nous expliquant les étapes, partant d'un .c, pour aller à un .exe,
avec un intérêt tout particulier pour le passage du .asm au .obj, qu'on pouvait utiliser des paramètres (dans notre cas /l, /z, et /zi) pour des options de débogage, mais que attention, si activées, permettaient de remonter du .exe vers le .asm

Or, sur internet, il y a plein d'articles concernant des méthodes pour entraver la récuperation des sources à travers un .exe (aléatoire, overload, invisibilité, tout ça tout ça).
Ma question est donc de savoir les raisons d'être de toutes ces technologie d'obfuscation et de desobfuscations si le développeur n'a qu'à simplement remettre au client un produit sans les options de débug ? Qu'est-ce qui se cache derrière tout ça ?

Merci d'avance

[BufferBob]

salut,

alors tout d'abord je reviens sur le terme "obfuscation" qui apparemment est un anglicisme, chose courante en informatique et qui permet en outre d'avoir un jargon commun avec les anglophones, mais si l'on cherche sur Wikipédia par exemple (qui n'est pourtant pas un dictionnaire, mais une encyclopédie) on ne le trouvera pas.
on trouvera à la place des articles sur le "code impénétrable" ou l'"offuscation" (terminologie correcte, mais issue d'un sens tombé en désuétude du vieux Français), et ça bien que le terme soit très largement répandu dans la littérature associée depuis des années, et tout ça par la volonté d'un seul et unique blaireau qui fait la guéguerre aux anglicismes.

à bon entendeur...

Ma question est donc de savoir les raisons d'être de toutes ces technologie d'obfuscation et de desobfuscations si le développeur n'a qu'à simplement remettre au client un produit sans les options de débug ?

faire de la décompilation sur un binaire c'est très difficile et peu fiable, il faut des outils spécialisés dont l'efficacité est tout à fait subjective et qui ne permettent actuellement pas de fournir un code source compilable tel quel

on peut aussi envisager une décompilation "partielle", à la main, en étudiant le code machine contenu dans le binaire et en déduisant le code C qui a permis d'en arriver là, et on peut également étudier le code machine sans volonté de revenir à un langage de plus haut niveau, c'est tout le propos de la rétro-ingénierie (reverse engineering, RE pour les intimes)

que ce soit le client final qui tente de regarder sous le capot les petits secrets de fabrication, le pirate qui cherche à faire sauter la protection logicielle (cracking) ou le chercheur en sécurité qui essaye de décortiquer un binaire malveillant pour analyse, on trouve toujours à la base le même rapport de force entre "je suis caché" et "je t'ai trouvé", c'est tout le propos des techniques d'obfuscation de code; tenter de ralentir le plus possible l'humain qui analyse le binaire voire de le perdre, et par là rester à l'abri des regards le plus longtemps possible

par ailleurs il faut bien comprendre que ces techniques sont complexes et requièrent une expertise que peu de gens ont réellement, pour finalement tenir à l'écart une minorité d'individus, on comprend alors qu'il est infiniment plus simple de ne livrer au client que la version release (par opposition à la debug) qui découragera +90% des curieux par sa seule nature binaire, là où rajouter de l'obfuscation aura un coût et les quelques % de fouineurs restants, hautement spécialisés, seront de toutes façons difficile à arrêter

[-Lyxx]

Bonjour,

merci pour cette réponse !

Cependant je ne comprend toujours pas la nuance : j'ai par exemple lu que pour opacifier le code, on va chercher à mettre des identifiants identiques partout ou cela est possible, ou encore ajouter des chaines de caractères illisible dans le source.
Or, dans la version release, il nous a été dit en cours que nous n'avons plus aucun moyen de connaitre le noms des identificateurs par exemple, alors en quoi cette modification s’avère pertinente ? Aurais-tu un exemple concret (et accessible) ou l'opacification de la source complexifie l'analyse du fichier binaire ?

[BufferBob]

Cependant je ne comprend toujours pas la nuance : j'ai par exemple lu que pour opacifier le code, on va chercher à mettre des identifiants identiques partout ou cela est possible, ou encore ajouter des chaines de caractères illisible dans le source.

identiques ou difficilement reconnaissables oui, par exemple appeler une variable _@fdfhjlkmdf au lieu de l'appeler var, et une fonction avec un nom proche comme _@fdfhjikmdf, ça vaut pour les langages interprétés, pas pour les langages compilés puisque comme tu dis les symboles disparaissent, on peut prendre l'exemple des codes malveillants en JavaScript, ou des backdoors PHP etc.

à l'inverse concernant les langages voués à être compilés comme le C, il faut bien faire la distinction justement, on peut s'amuser à obfusquer le code source (cf. le concours IOCCC), mais ça n'est utile que pour gêner la lecture... du code source.

si on veut gêner le désassemblage et la lecture du code machine généré, il faut recourir à des obfucations plus profondes, souvent directement en assembleur
on prend par exemple le bout de code machine désassemblé suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$ echo -ne "\xeb\x01\x05\x68\x72\x65\x74\x0a\x68\x73\x65\x63\x00" | ndisasm -u -
00000000  EB01              jmp short 0x3
00000002  0568726574        add eax,0x74657268
00000007  0A6873            or ch,[eax+0x73]
0000000A  656300            arpl [gs:eax],ax

on voit en début de programme une instruction jmp short 0x3, c'est à dire un saut en plein milieu de l'instruction suivante qui commence à l'adresse 0x2, le code s'en trouve alors désaligné et on perd la lisibilité du code, tandis qu'à l'exécution le cpu lui verra :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
00000000  EB01              jmp short 0x3
00000002  05                 -- junk, jamais exécuté --
00000003  687265740A        push dword 0x0a746572
00000008  6873656300        push dword 0x00636573

on a donc dissimulé 10 octets (les 2 instructions push) juste en insérant 1 seul octet au bon endroit

on sent bien que mettre en œuvre ce genre de technique directement au sein du code source C peut vite s'avérer compliqué, et donc ça a un coût, que les entreprises n'assument en général pas
pour autant il me semble me souvenir que le binaire de Skype typiquement était bourré de code obfusqué il y a plusieurs années (bien avant son rachat par Microsoft), je ne sais pas si c'est toujours le cas aujourd'hui

[-Lyxx]

Un grand merci à toi pour ta réponse très complète, c'est clair maintenant !