[Débutant] Simple embûche à la décompilation

Version imprimable

29/08/2009, 18h18
mattaku

[Débutant] Simple embûche à la décompilation

Bonjour à tous,

Je programme dans un langage très facilement décompilable (AutoIt), dans le fait qu'il suffit d'un simple programme pour apercevoir le code source entier. Pour mettre une minuscule embûche a ce décompilateur que beaucoup utilise, j'aimerais faire un système dans un autre langage (C/C++ ou n'importe quoi qui fonctionnerais) qui ressemblerait à sa :

1) L'on lance le fichier .exe d'un autre langage que celui que j'utilise
2) Le .exe va lancer "Mon" .exe qui est facilement décompilable. (soit en mode caché, soit copier dans un autre dossier)

Gros bémole, je n'ai jamais touché au C ou C++ ou même Java, de plus se poste peux largement ressembler à un poste pour un Virus ou Malware.
Pour plus d'information sur le langage que j'utilise : http://www.autoitscript.fr/forum/viewtopic.php?f=3&t=1192

P.S : Je sais très bien que mon programme sera toujours décompilable mais cette simple embûche peux en décourager plus d'un !

Merci d'avance

Salut,

Avec l'instruction system ?
Code:

1 2 3 4 5 6 7 # include <stdlib.h> /* inclure pour utiliser system */ int main (void) { system ("CheminDuProgramme"); /* system permet d'exécuter une commande interne du système, ici elle invoque le programme grâce à son chemin (pour Windows)*/ return 0; }
Si tu veut distribuer ton programme ce n'est surement pas une solution (tu devras fournir deux exécutables dont celui qui est "décompilable" ce qui n'arrange rien) ... essayes peut être un autre langage ou renseignes toi sur les possibilités de cryptage de ce langage (que je ne connais pas).

P.S : tu utilises Windows sans doute, non ?

30/08/2009, 22h26
mattaku

Tout d'abord merci beaucoup pour ta réponse.

Oui je vais belle et bien fournir 2 exécutable, mais j'aimerais que le .exe décompilable soit "caché", pour éviter une décompilation beaucoup trop simple.
En gros il faudrait mettre le .exe décompilable dans le .exe en C, le C copiera le .exe décompilable dans un dossier secret ou dans la mémoire temporaires. (Le .exe décompilable fait moins de 1 MO.)

Ton code permet de lancer un .exe, c'est parfait mais il faudrait comme dit plus haut, que le C intègre un autre .exe...
Et je ne sais pas comment faire...

encore merci.
31/08/2009, 11h23
ok.Idriss

Salut,

Je viens de voir un sujet similaire sur le sdz, sans aucun doute posté par toi ...
Apparemment personne n'a pu satisfaire ta demande, pour cela je te conseil à nouveau de te pencher sur les possibilités de cryptage de ce langage, et des choses dans le genre (s'il y en a).

Bonne chance.

Edit : après une recherche, je suis tombé sur ce forum qui dit que l'on ne peut pas protéger son code dans ce langage, est-ce ceci qui t'a poussé a te servir d'un autre langage ?

En tout cas, je ne peut pour l'instant plus t'aider.
Bonne chance :aie: .
31/08/2009, 12h34
Mac LAK

Ou regarder du côté de UPX : ce n'est pas parfait (loin de là !!), mais ça peut déjà plomber pas mal le lambda moyen...
31/08/2009, 17h17
ok.Idriss

Le lambda moyen ne songera pas à pirater les sources d'un exécutable AMHA ...
31/08/2009, 17h34
Mac LAK

Citation:

Envoyé par ok.Idriss

Le lambda moyen ne songera pas à pirater les sources d'un exécutable AMHA ...

Le gros avantage est que beaucoup d'antivirus savent analyser un exécutable compressé par UPX (donc, OK pour la sécurité, ça ne permet pas à un virus de passer sans être vu), et que tu ne dois pas avoir plus d'un quart des développeurs qui sauraient reconnaître un exécutable "UPX-é"... Alors un non-développeur, c'est presque illusoire, et ça permet de "cacher" un peu le script AutoIt.
31/08/2009, 21h41
mattaku

Lors de la compilation Autoit propose d'utiliser l'UPX, et avec ou sans, l'on peux quand même le décompiler.
Si vous connaisez un moyen de "mettre "un .exe dans un .exe dans un autre langage que le C manifester vous.

Merci d'avance.
31/08/2009, 21h51
dourouc05

AutoIt fonctionne sous Windows, et uniquement sous Windows. Tu peux donc sans problème utiliser les ressources.

Tu peux, dans un premier temps, mettre ton exécutable dans les ressources, puis sauter vers le point d'entrée de l'exécutable. Très facilement attaquable, cela ne fait que mettre un peu de C dans l'affaire.

Ensuite, tu peux compresser cet exécutable, comme avec UOX, mais cela ne résistera pas longtemps. Ensuite, tu peux cryper cet exécutable, et ne le décrypter qu'à l'exécution, le placer en mémoire, et sauter sur le point d'entrée.

Après, tu peux mettre les deux ensemble, et même plusieurs fois (en alternant, sinon le résultat pourrait être moins bon : compresser un fichier compressé...).

Mais, pour cela, il faudrait passer à l'assembleur...

Pour la compression : il n'existe pas que UPX, tu peux utiliser des algorithmes plus répandus (BZip, GZip, 7z...), qui utilisent une librairie de compression, que tu peux toi aussi utiliser dans ton application.
31/08/2009, 22h16
Mac LAK

Citation:

Envoyé par dourouc05

Pour la compression : il n'existe pas que UPX, tu peux utiliser des algorithmes plus répandus (BZip, GZip, 7z...), qui utilisent une librairie de compression, que tu peux toi aussi utiliser dans ton application.

Sauf qu'ils ne seront utilisables que sur des données (ils ne permettent pas de conserver un exécutable exécutable, justement...).
Et si tu fais ça sur des ressources, il faudra les extraire et les décompresser dans un répertoire temporaire, donc laisser l'exécutable bien visible et totalement décompressé durant toute l'exécution du programme (pas top).

Il existe peut-être d'autres compacteurs comme UPX sous Windows, mais en tout cas, je ne les connais pas.
31/08/2009, 22h23
dourouc05

Citation:

Envoyé par Mac LAK

Sauf qu'ils ne seront utilisables que sur des données (ils ne permettent pas de conserver un exécutable exécutable, justement...).
Et si tu fais ça sur des ressources, il faudra les extraire et les décompresser dans un répertoire temporaire, donc laisser l'exécutable bien visible et totalement décompressé durant toute l'exécution du programme (pas top).

Il existe peut-être d'autres compacteurs comme UPX sous Windows, mais en tout cas, je ne les connais pas.

Ce sont des algorithmes de compression, ils n'ont cure de ce qu'ils compressent. Ils compressent indifféremment images, sons... et exécutables ! (UPX n'utilise pas l'algorithme 7z, par hasard ?).

Si tu charges ton programme en tant que variable, tu peux décompresser cette variable avec ces librairies. Ensuite, tu lances le contenu de cette variable (le programme).

Les ressources, c'est une méthode pour inclure des fichiers dans un exécutable. Sans en être trop sûr, ces ressources doivent être stockées dans une section, tu peux donc lire cette section de ton programme. Pas besoin de l'extraire sur le disque dur, tout se passe en mémoire.

Je ne propose pas d'utiliser une solution toute faite (un module SFX, trop facile à casser), mais de réutiliser des bouts de code spécialisés (la compression) pour arriver à nos fins.
31/08/2009, 23h11
Mac LAK

Citation:

Envoyé par dourouc05

Ce sont des algorithmes de compression, ils n'ont cure de ce qu'ils compressent. Ils compressent indifféremment images, sons... et exécutables ! (UPX n'utilise pas l'algorithme 7z, par hasard ?).

UPX utilise la librairie de compression NRV, une variante du LZO, lui-même variante du LZ. C'est un compacteur relativement ancien, en fait.
Certes, tu peux compresser ce que tu veux avec ces algos généralistes, c'est un fait. Mais...

Citation:

Envoyé par dourouc05

Si tu charges ton programme en tant que variable, tu peux décompresser cette variable avec ces librairies. Ensuite, tu lances le contenu de cette variable (le programme).

Et c'est là que ça fait mal : tu lances comment un exécutable PE dont l'image est déjà en RAM ? La fonction CreateProcess ne te permet pas de donner un pointeur en mémoire, il faut lui donner un nom de fichier externe exécutable !
Et n'oublie pas qu'un tel fichier n'est pas réellement exécutable : il n'est ni relogé, ni lié dynamiquement aux DLL dont il dépend... C'est le système d'exploitation qui assure la transformation entre le contenu du binaire "exécutable" et l'image-mémoire réellement exécutable par le CPU.

Citation:

Envoyé par dourouc05

Les ressources, c'est une méthode pour inclure des fichiers dans un exécutable. Sans en être trop sûr, ces ressources doivent être stockées dans une section, tu peux donc lire cette section de ton programme. Pas besoin de l'extraire sur le disque dur, tout se passe en mémoire.

En effet, on peut parfaitement lire les ressources sans les extraire de l'exécutable (elles sont effectivement dans une section spéciale du fichier). Toutefois, il faut voir ces ressources exclusivement comme des fichiers de données particuliers, cf. l'aide de LoadResource.

Citation:

Envoyé par dourouc05

Je ne propose pas d'utiliser une solution toute faite (un module SFX, trop facile à casser), mais de réutiliser des bouts de code spécialisés (la compression) pour arriver à nos fins.

Mais tu ne sortiras pas du problème qu'il faudra à un moment où à un autre écrire le fichier exécutable quelque part pour pouvoir le lancer...
La seule solution que je vois, et c'est en se limitant aux partitions NTFS, est de sauvegarder l'exécutable dans un flux alternatif NTFS... Toutefois, il y a de fortes chances que cela pose des problèmes de verrouillage de fichiers, étant donné que l'exécutable primaire (celui qui lance le tout) sera verrouillé exclusivement par Windows pendant l'exécution.