Discussion :

[haypo]

De plus je pense que l'idée de l'auteur du post est bel et bien de se protéger du piratage de son logiciel. Quand on parle de reverse engineering, dans 99% ça veut dire : faire sauter la protection d'un logiciel !

Pas exactement... au fait je prépare mon travail de diplôme (mémoire), (...)

Ah ok, si c'est pour un mémoire, alors je vais rétablir la vérité. NON, le reverse engineering ne sert pas qu'à cracker des logiciels.

On peut analyser le code pour voir comment ça marche (et chercher des failles potentielles) : audit de sécurité ... enfin, je sais pas trop si c'est fait. Je sais que les pirates cherchent des failles dans le code de Linux ... qui lui est disponnible :-p Je dis que c'est pas du cracking, car il n'y a pas que ceux qui crackent qui cherchent les failles, mais aussi ceux qui veulent s'en protéger ! Il y a un gros débat entre "source ouverte ou source fermée" pour la sécurité. Moi je dirai : comparez la sécurité de Windows et celle de Linux ... c'est très net !

On peut analyser le code source pour écrire un pilote d'un périphérique sous Linux ou autre système dont le pilote "officiel" ne sortira probablement jamais. J'ai pas exemple un ami qui cherche à écrire un pilote pour un scanner via USB qui n'existe pas sous Linux.

On peut aussi faire du reverse engineering pour décoder un format de fichier propriétaire pour pouvoir écrire un logiciel qui sache l'importer, voir exporter dans ce format. Voyez le gros problème du format Word .... OpenOffice est dessus depuis très longtemps !

Par reverse engineering, j'entend désassembler un programme. Mais ça peut aussi vouloir dire "écouter" la carte réseau (pour comprendre le protocole MSNP9 et écrire un client alternatif), "écouter" le port USB (écrire un pilote), ou écouter une autre voix de communication. C'est très large comme sujet ! Ca se borne pas à faire sauter la protection d'un shareware !

Allez, @+
Haypo

[Morgatte]

Il semble kue (ma lettre KU est HS désolé) kue rolKa confonde Hacking et Cracking. Bon pas grâve... (on ne parle pas de l'intrusion d'un réseau)



Je confirme ku'il n'y a aucun moyen d'empêcher kuelku'un de modifier un programme si il a vraiment les compétences pour le faire.

Cependant on peut lui mettre pas mal de batons dans les roues. Un petit tour d'horizon pourra peut-être t'aider à mieux comprendre ce kui peut être fait.
Je pense en particulier à :

- du code détectant les débuggers (facile à péter cependant)
- du code CCA (Code Changeant d'Apparence = une sorte de polymorphisme) c'est très simple à faire, un simple jmp sautant au dessus d'un byte inutilisé mais ayant une signification pour le processeur et le tour est joué.
ex:

Code :

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

1
2
3
4
EB01       jmp SautLeByte
0F         leByte db 0Fh
SautLeByte:
E807000000 CALL MaProcedure

Le processeur va l'interpréter ainsi car 0F+... a une signification propre :

Code :

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

1
2
3
EB01      jmp SautLeByte
0FE807    psubsb MM0, [edi]
0000      add [eax], al

Le truc c'est ku'en traçant, on voit le code changer, ça permet de cacher des points clefs et ça peut être superchiant à tracer.
Mais avec un peu de pratikue on peut facilement anéantir ça. Pour ma part je patch tous les bytes kue saute le jmp par des 90h.
puiskue 90h (un NOP) est interprété sans suite, 90h+AUTRECHOSE ne peut rien donné d'autre kue ça. UPX l'utilise beaucoup...

- Bon plus puissants sont les cryptage/décryptage PE. Un programme cypté possède une partie non crypté (un loader) kui sert à décrypté le reste du programme une fois ku'il a été mappé en mémoire.
Du coup avec un débugger on ne voit plus rien car le code crypté n'a plus une signification réelle. Cependant c'est toujours possible de le reconstituer. Il suffit pour ça de laisser le loader décrypter le vrai programme et une fois u'on se trouve sur la première ligne du programme décrypté, de faire un dump (copie d'une zone de mémoire, ici le prog décrypté). On en refait un *.exe et ensuite on fait repointer OEP (Original Entry Point) sur la première ligne du prog décrypté, Le tour est joué.
La seule difficulté c'est de retrouver l'OEP (surtout si les BPR ont été mis hors d'état de fonctionnés par le loader).
C'est le niveau ultime utilisé par UPX.

- Toujours plus puissant, ce serait évidemment de crypter le programme mais en plus de faire en sorte d'empêcher le DUMP. Et c'est possible, mais ce serait trop long à explikuer en détail. En résumé, L'IAT kui est une section de ton programme où se trouvent écrits tous les noms des fonctions ku'il utilise. Le truc c'est ku'il est possible de faire en sorte kue le programme s'exécute normalement avec les bonnes fonctions, mais en plus de modifier son IAT en mémoire pour kue toutes les fonctions soient remplacées par ExitProcess par exemple. On s'en fout de modifier, l'IAT par la suite car il a servit au début mais plus jamais ensuite. Par contre un DUMP du programme en mémoire va faire en sorte u'une fois reconstitué en un *.exe, tout son IAT n'aura u'une seule fonction, ExitProcess.
C'est bien joué ça, 1 : Le programme est Cypté donc on ne voit rien. 2 : Si on le dump pour faire en sorte de retrouver sa version décrypté, il ne marche plus.
Seule solution, tout faire soit même à la main. C'est à dire laisser le loader décrypter le programme MAIS en prenant garde aux passage du loader kui modifient l'IAT. Ecraser ces passages pour l'empêcher d'agir. Evidemment, ça suppose de tracer le programme en comprenant ce ku'il fait, et c'est plus du niveau des premiers crakers. Ca suppose de connaitre intimement l'IAT.

- Dans un autre genre, tout aussi efficace, le cas des dernières versions d'ASPROTEC.
En décortikuant ses entrailles on s'aperçoit kuil remplace par exemple :

CALL BFF70000 kui pourrait correspondre à l'appelle de la fonction MessageBoxA par exemple.

Code :

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

1
2
3
PUSH ESP
MOV ESP, EBP
CALL BFF70003

Pourkuoi ?

En fait kuand il appelle une fonction et bien il saute "au-debut de cette fonction + 3 bytes" et justement ces 3 bytes ku'il ne va pas exécuter dans la fonction même, il le recopie directement dans le programme pour kue rien ne mankue lors de l'exécution globale.
Du coup les débuggers ne reconnaissent plus les Noms des fonctions puisku'elles ne pointent plus sur leur début. En plus après un Dump en mémoire, on se retrouve avec des petits bouts de code supplémentaires (PUSH ESP...) dans le programme kui le font planter car la pile reçoit des données en trop.
Bien entendu le remède existe, un simple bout de papier et un cerveau, ou bien le vraiment excellent programme Revirgin de +Tsehp (mais pas évident à aborder)


Donc voilà, tu vois kue tant ku'un debugger pourra lire la première ligne d'un programme, la possibilité d'abbattre les différentes protections sera toujours possible pour peu kue le savoir et l'acharnement suivent. Cependant faut pas nier kue ça se pête pas comme ça les doits dans le nez, comme c'était le cas y a encore 7 ou 8 ans.


(Je différencie clairement Cracking et Reverse, dans le premier cas de simples bases en programmation peuvent suffir dans les cas simples. Dans le second cas de réelles compétences en programmation sont indispensables)

[SKZ81]

Pour l'IAT, je veux pas trop m'avancer pcq je connaissait même pas son existance... (à moins que ce soit encore un autre nom pour un truc que je connais : bref...)
Un truc que je me disait tout de même... Ok normalement on peut lui faire confiance (seul un prog protégé modifira le contenu) mais si une protection peut l'écraser impunément, c'est qu'elle doit être recopiée qqpart à disposition du prog... On devrait pouvoir la retrouver :

[rolkA]

Par reverse engineering, j'entend désassembler un programme.
Haypo

Je comprends donc mieux la divergence: pour moi ce n'est pas çà. pour moi le désassemblage est une étape du reverse engineering seulement. Exemple concret: photoshop utilise un certain algo pour réaliser la fonction ajustements->correction automatique du contraste. pour moi le reverse-engineering consiste à découvrir cet algorithme... et pas seulement décompiler les plug-ins en assembleur !!!

[Morgatte]

Pour répondre à SKZ8un (Mon chiffre un est HS lui aussi)

Pour l'IAT, je veux pas trop m'avancer pcq je connaissait même pas son existance... (à moins que ce soit encore un autre nom pour un truc que je connais bref...)
Un truc que je me disait tout de même... Ok normalement on peut lui faire confiance (seul un prog protégé modifira le contenu) mais si une protection peut l'écraser impunément, c'est qu'elle doit être recopiée qqpart à disposition du prog... On devrait pouvoir la retrouver.

Non, L'IAT est propre au programme (.idata parfois .rdata), tout comme l'est sa section code (.text).
Pour être un peu plus précis, l'IAT contient d'autres choses kue les noms des fonctions utilisées par le prog. en particulier pour chakue nom de fonction un
- DWORD Original_First_Thunk (Son vrai nom c'est THUNK_DATA)
- DWORD First_Thunk (Son vrai nom est aussi THUNK_DATA)
- et un DWORD Time_Date_Stamp
lui sont associés.

kuand un PE File (un *.exe) est exécuté sous windows, la première chose kue fait windows c'est récopier le programme en mémoire, ensuite d'après les noms des fonctions présents dans l'IAT, Il remplace les membres fait une copie comforme des membres First_Thunk à partir des membres Original_First_Thunk, ainsi chakue CALL NomDeFonction sait où pointer à l'intérieur des APIs en se référent aux membres First_Thunk, car NomDeFonction vient d'être remplacé par une adresse.
Les Original_First_Thunk sont toujours fixés lors de la compilation du programme et resteront toujours invariables, Ils sont seulement recopiés dans le First_Thunk kui seuls eux comptent, et c'est une étape rapide. C'est le seul but de ce méchanisme, vite retrouver les adresses des fonctions à partir des OFT. Donc à priorie, les noms des fonctions présents dans l'IAT sont complètement inutiles.
Là où le bas blesse, c'est kue les versions des DLL évolues et donc les adresses d'une version à l'autre peuvent différer (méchant plantage).
Pour résoudre ça le membre Time_Date_Stamp pour chakue fonction dans le programme est comparer à un autre membre lui aussi appelé Date_Time_Stamp se trouvant dans la DLL exportant la fonction, Comme ça si pour une même fonction Time_Date_Stamp dans le programme et dans la DLL sont égaux alors c'est kue la DLL utilisée actuellement par le programme est de la même version kue celle kui à servit au moment de sa compilation. Du coup tout baigne. Le méchanisme est celui vue ci-dessus.
Par contre si les deux Time_Date_Stamp sont différents alors c'est kue la DLL actuelle n'est pas de la version de celle d'origine. Dans ce cas le loader de Windows (toujours lui) réactualise les Membres First_Thunk non plus en recopiant les Original_First_Thunk mais en appelant la fonction GetProcAddress en lui passant les noms des fonctions trouvées dans l'IAT. Le First_Thunk redeviennent correctent. Mais c'est un peut plus lent. Cependant dans tout les cas le programme fonctionne.
Kuand Windows en à finit avec la reconstitution d'un IAT approprié en mémoire il passe le controle au programme kui peut alors exécuter pour la toute première fois sa première instruction de code.

Maintenant en gardant ce méchanisme en tête, revenons au principe de l'Anti-Dump :

Imaginons un crypteur kui ait vidé l'IAT d'origine sauf les Original_First_Thunk, et l'a récrit ailleurs dans la partie loader de décryptage du programme, Il a aussi crypté la section .code.
On exécute notre programme. D'abord c'est Windows kui a la main et puiskue les Original_First_Thunk sont à leurs places, la copie vers le First_Thunk se fait, les call sont bons, et une fois décrypté le programme fonctionnera. Mais le loader de décryptage ne s'en tien pas ku'a ça... Windows à fait son boulot OK, mais lui il va en plus recopier dans le vrai IAT (prekue vide) le nom d'une seule fonction ExitProcess et mettre tous les membres Time_Date_Stamp à 0FFFFFFFFh.
Du coup bien kue le programme s'exécute, si on fait un dump et ku'on l'exécute, puiskue les Time_Date_Stamp sont incorrectes (aucune date peut être FFFFFFF) alors ils réactualise les First_Thunk en retrouvant les noms des fonctions dans l'IAT, Et tous pointent sur ExitProcess. Et, et... après un Dump y a rien d'autre de disponible kue cette fonction, les autres ont été perdues en chemin.




(Je ne vous ai pas parlé des fonctions exportées BY_ORDINAL là c'était le cas des BY_NAME. Ca complikue juste un peu l'affaire.)

Désolé d'être si long, mais en réalité c'est encore plus complikuer kue ça. (Il y a d'autres Structures telle kue IMAGE_IMPORT_DESCRIPTOR, IMAGE_IMPORT_BY_NAME ...).

[Didier Derain]

Pour info je suis un peut dans le meme cas, (ca ne marche pas encore mais bientot) pour camoufler une routine critique je la crypte dans un premier temps puis au moment de l'executer je la decrypte par l'intermediare de l'int de debbugage a savoir je decode l'instruction suivante puis je recode la precedente de telle sorte qu'a aucun moment ma routine n'est entierement visible meme sous un debuggeur qui ne peut voir ce que je fait puisque je suis caller sur son int. (l'astuce consiste a utiliser le code (le code asm de la routine) de decryption plus le contenue de la pile et aussi le contenue des registre DR0... code clef de decriptage..

[Blustuff]

Si je comprends bien la logique, un désasm/débugueur suffisement puissant pour lequel tout marcherait par scripting, du désassemblage, au tracage, en passant par la recherche des symboles viendrait a bout de n'importe quoi non ? Si un script était éxécuté après chaque instruction, il y aurait moyen de détecter chaque appel de fonction, chaque accès en mémoire etc.

Pourquoi après avoir dumpé la mémoire rétablir l'IAT originale ?

[doccpu]

Si je comprends bien la logique, un désasm/débugueur suffisement puissant pour lequel tout marcherait par scripting, du désassemblage, au tracage, en passant par la recherche des symboles viendrait a bout de n'importe quoi non ?

Non un script n'est pas intelligent ! En tout cas pas autant que nous, et il faut le mettre sans cesse à jour pour qu'il fonctionne sur (presque) tout !

Si un script était éxécuté après chaque instruction, il y aurait moyen de détecter chaque appel de fonction, chaque accès en mémoire etc.

Oui dans la théorie c'est possible mais il y aura toujours un ingénieur qui sera capable de faire en sorte que le désassembleur se mette à tourner en rond dans le processus de désassemblage et donc plantera le désassembleur ou le fera s'arrêter si le désassembleur est équipé d'un whatchdog cependant un humain sera beaucoup plus lent à faire le travail mais il ne se laissera pas prendre à ce piège. Du moins pas éternellement.

[Smortex]

Salut

Sans même chercher plus profondément: si le CPU peut l'exécuter, ça peut être désossé.

C'est complètement stupide mais ça se résume ainsi.
C'est comme la musique-pleine-de-DRM-anti-copie... Pas escence, si on peut l'écouter, on peut le copier.

Je pense que le commun des mortels croit dur comme fer en la magie Le seul moyen d'avoir un programme qui soit impossible à désosser, c'est de le mettre sur un serveur auquel personne n'a un accès autre que pour y faire entrer ses données et récupérer ses résultats... et n'avoir aucune faille de sécurité dans le code (on sait jamais, un utilisateur mal intentionné qui récupère des bout de mémoire en passant des données un peu louches)!

[Juju_41]

Sans même chercher plus profondément: si le CPU peut l'exécuter, ça peut être désossé.

C'est complètement stupide mais ça se résume ainsi.
C'est comme la musique-pleine-de-DRM-anti-copie... Pas escence, si on peut l'écouter, on peut le copier.

+1 il n'y a pas de protection infaillible

Le seul moyen d'avoir un programme qui soit impossible à désosser, c'est de le mettre sur un serveur auquel personne n'a un accès autre que pour y faire entrer ses données et récupérer ses résultats... et n'avoir aucune faille de sécurité dans le code

Même si il n'y a aucune faille de sécurité dans le code, il reste les attaques "physiques" qui permettent de récupérer du code/des données sans pour autant avoir accès au matériel. Par exemple, les attaques DPA (Differential Power Analysis) sur les cartes à puce : en analysant la consommation électrique aux bornes de certains contacts de la carte, on peut en déduire l'instruction en cours d'exécution sur le micro-processeur de la carte.

[millie]

Même si il n'y a aucune faille de sécurité dans le code, il reste les attaques "physiques" qui permettent de récupérer du code/des données sans pour autant avoir accès au matériel. Par exemple, les attaques DPA (Differential Power Analysis) sur les cartes à puce : en analysant la consommation électrique aux bornes de certains contacts de la carte, on peut en déduire l'instruction en cours d'exécution sur le micro-processeur de la carte.

Les attaques physiques sont délicates à réaliser si le serveur est à 10.000 km.

[Morgatte]

Désolé de répondre après X temps je n'avais pas vu la kuestion ci-dessus. Mais un Post récent faisant référence à celui-ci m'a dirigé de nouveau ici et je viens de voir cette dernière kuestion.

donc...

>> Pourquoi après avoir dumpé la mémoire rétablir l'IAT originale ?

Il est impératif d'avoir un IAT valide pour ku'un *.exe fonctionne. L'unikue destinée de l'IAT est de remplir correctement ses propres membres First_Thunk. Leurs valeurs sont attribués dynamikuement et représentent les adresses des API telles kue BFF0xxxx pour ExitProcess par exemple.
Kuand on écrit un programme, les 'CALL fonctions' ku'il utilise ne pointent jamais directement sur les adresses de ses fonctions à l'intérieur des dll.

Kuand on tombe sur :
- Call MessageBoxA
En fait ce n'est jamais un call du type :
- Call BFF0xxxx
Mais bien un call du type suivant :
- Call 004........
Où l'adresse fait bien partie de l'IAT (sur un des membre First_Thunk)

Donc si votre IAT n'est pas valide (ou au stricte minimum si les First_Thunk ne sont pas valides) alors les call ne peuvent pas appeler les fonctions et votre programme échoue.


C'est pour ça kue faire un travail sur l'IAT pour protéger un programme est intéressant.
Si vous réussissez juste avant l'exécution de la première ligne de code à avoir des first_thunk valides et kue le loader ait décrypté la section .text (code) du programme alors ce programme est fonctionnel.
Mais en même temps si tout le reste de l'Iat est non valide, alors si vous faite un dump du programme pour laisser le loader décryter la section code, il ne fonctionnera pas. Car l'IAT étant reconstruit dynamikuement à chakue ouverture du programme, les first_thunk valides (au moment du dump) auront été remplacés par des first_thunk corrompus lors de la nouvelle réactualisation).


Une kuestion bête pour finir..... Pourkuoi donc se sevir d'un IAT plutôt kue d'appeler directement les fonctions dans les dll ?

Parce kue si vous changer de version de dll, leurs adresses peuvent être différentes et du coup votre programme peut fonctionner chez vous, mais pas chez votre copin. L'iat à pour rôle de retrouver dans tous les cas les bonnes adresses des fonctions.


J'avais codé deux crypteurs sur ce principe ici : http://membres.lycos.fr/w32assembly/...atte/Crypt.ace
et un tut inclus explikant plus abilement ce pincipe. (le second crypteur ne fonctionnera pas sous XP) car il possède d'autres principe ku'XP n'apprécie pas, en particulier une routine en Ring0 détectant SoftIce et autres débuggeur) Il suffira de la supprimer pour ku'il redeviennet fonctionnel sous cet OS.
Le fonctionnement complet de l'IAT est décrit dans ce tut ci http://membres.lycos.fr/w32assembly/...rgatte/Iat.ace kui est en réalité la première partie du précédent.

[BigTick]

Hello,

Ma petite contribution sur le sujet (C++ et asm):
http://bigtick.pastnotecut.org/tutorials/cp.html

'Tick

[doccpu]

Hello,

Ma petite contribution sur le sujet (C++ et asm):
http://bigtick.pastnotecut.org/tutorials/cp.html

'Tick

Pas mal ton site et la protection expliqué mais t'a oublié le plus simple des hack en brute force :
Tu cherche les test et/ou les comparaisons suivis d'un jz ou jnz (ou équivalent) 1 par 1 et tu les inverse 1 par 1 jusque à ce que le logiciel te laisse entrer à se moment la tu vien de générer un programe yes (sauf pour le bon code pour lequel il répondra non)un hackeur peut faire ca même sans débugueur avec un éditeur hexa (je te l'accorde, il faut être chevronné pour le faire en hexa).