Bonjours � tous,
j'aimerai savoir si il exist� des outils qui permettent de rendre le code impossible � d�sassembler?
si vous avez des retours? un bien?
je vous remercie d'avance.
Version imprimable
Bonjours � tous,
j'aimerai savoir si il exist� des outils qui permettent de rendre le code impossible � d�sassembler?
si vous avez des retours? un bien?
je vous remercie d'avance.
Bah faut bien d�sassembler � un moment si tu veux que le processeur ai les instructions :roll:
Si l'utilisateur ne peut pas d�sassembler, il ne pourra pas ex�cuter le code.
Ceci dit, avec le code en assembleur, on ne fait pas grand chose.
Tu peux bien complexifier la tache (par exemple en cryptant le code compil�, et en le d�codant juste avant de l'ex�cuter) mais dans tous les cas tu devra fournir la routine pour retrouver le code compil� en clair, donc c'est passablement inutile.
malheureusement... je sais bien, mais si y'avais un outil qui complexifierai plus plus la t�che? et le mieux? �a serait lequel?
Salut,
A vrai dire, j'aurais presque tendance � demander pour quelle raison tu aurais besoin d'un tel outil...
Comprenons nous bien: C et C++ �tant des langage compil�s, il est d�j� difficile de r�cup�rer le "code" au d�part de l'ex�cutable, contrairement aux langages interpr�t�s.
De plus, il faut te dire qu'aucune protection n'est viable � 100%... Les �diteurs de jeux et / ou de syst�mes d'exploitation en savent quelque chose :D
Enfin, je ne verrais personnellement un avantage �ventuel que si, vraiment, j'impl�mentais un algorithme r�ellement r�volutionnaire...
D�s lors, crois tu vraiment que ce soit int�ressant :question:
Salut,
Je ne connais pas de solution magique. D�j� d�sassembler un code C++ vers de l'asm d'une application un peu complexe ne produit pas forc�ment un code ASM tr�s �vident... Ensuite, tu peux essayer des techniques d'obfuscation mais qui auront un co�t (code mort, changement des options de compils, membres inutiles ou redondant, variables et codes au milieu de traitements mais qui ne produisent rien, etc.).
Et puis, �a d�pend vraiment de ton objectif. Pourquoi vouloir compliquer ce d�sassamblage ? Vers tous tes clients ? Vers seulement un seul ? Etc.
c'est une demande d'un client qui aimerai voir son code (que l'on produit) s�curis� contre la d�compilation et le d�sassemblage.
j'avoue ne pas trop connaitre la chose, mais il est clair que dans le code peut �tre pack�? upx? des trucs dans le genre? �a fonctionne? utile?
Salut,
UPX compresse l'ex�cutable et le d�compresse au chargement de ce que j'ai cru comprendre. Ca peut rendre le d�sassamblage moins imm�diat � partir du fichier, mais en rien le pr�venir. Puisqu'il suffit de de d�compresser.
Il faudrait un �quivalent qui chiffre et d�chiffre au chargement, mais in-fine, �a ne permettrait quand m�me pas d'�viter un dump m�moire de l'ex�cutable pour un d�sassamblage.
C'est strictement impossible sur un processeur normal.Citation:
Envoy� par dtcSearch
En effet, le code est forc�ment, � un moment o� � un autre, ex�cutable directement par le CPU, donc il peut �tre d�sassembl�. Point final.
Tu peux encrypter ta RAM, ton ex�cutable, ton OS ou ce que tu veux, il suffit (au pire !) d'une b�te sonde sur le CPU et/ou sur le bus m�moire pour r�cup�rer en clair l'ensemble des instructions.
Et c'est la solution de bourrin, �a : vu que l'image de l'ex�cutable (d�compact� / d�crypt� / etc.) existe dans la m�moire du syst�me d'exploitation, et que le moindre compte d'administrateur permet d'aller tout dumper (donc, d�sassembler) bien proprement.
Donc, la demande est irr�aliste. On peut au mieux un peu complexifier le travail de la personne qui voudrait d�sassembler le programme, ou se pr�munir contre les hackers du mercredi, mais pas plus.
Pour pouvoir honorer cette demande, il te faut un syst�me int�grant un CPU cod�, et c'est une autre paire de manches : �a ne court pas les rues (en dehors de quelques domaines ultra sp�cifiques) et ils ne te donneront JAMAIS le moindre acc�s � cette technologie quoi qu'il en soit.
J'ai m�me envie de dire que le devoir de conseil du professionnel aurait �t� de le dire au client plut�t que de prendre un cahier des charges irr�aliste.Citation:
Envoy� par Mac LAK
Je dirais, que j'ai entendu parler d'une m�thode qui utiliserai des langages �sot�riques ( Brainfuck ... et autre truc du genre ) qui serais utilis� sur les parties de code critique des logiciels libres ( code ouvert ). �a peut �tre une m�thode ...
Sinon, upx bloquera un d�butant quelques heures :D ( pour peu qu'il est pas internet ).
( Y a plein d'autre outil, faut pas croire )
En conclusion, il y a rien de 100% efficace ... sinon Ubisoft ne ferai pas une politique de merde :D ( pardon )
Qui pourrais m'�claire pourquoi ce n'est pas possible d'empecher le d�sassemblage? plus pr�cis, plus concret et plus technique:P
...Citation:
Envoy� par Mac LAK
T'invente une technologie bidon, et tu dis que tu l'as appliqu� � ton executable sans rien faire. Ou ils vont vraiment tester le coup du desassemblage??
Hmm sinon il travaille dans quoi ton client? Il a peur de qui, de quoi? Peut-�tre qu'on peut donner une r�ponse plus claire si on sait ce qu'il craint. ( il y a une diff�rence entre Michel Compta SSII , une entreprise de jeux vid�os, une entreprise qui fait des logiciels pour l'armement... )
Bien entendu, mais le commercial de base qui dit "oui" � tout ce que demande le client pour toucher sa com a rarement l'id�e de demander aux techniques AVANT de dire "oui"... :cry:Citation:
Envoy� par deadalnix
@LittleWhite : L'obscurcissement permet de ralentir un d�sassemblage, mais pas plus. Quel que soit le langage source, � un moment ou a un autre, �a finira forc�ment en instructions ASM, et une addition sera toujours un ADD... ;)
Ma r�ponse ci-dessus le fait... Est-ce qu'il y a un point en particulier qui te pose probl�me ?Citation:
Envoy� par diablox0147
Mais encore ? ;)Citation:
Envoy� par Lavock
La D�fense ne se pose pas trop ce genre de questions : soit �a tourne sur du mat�riel sp�cifique (type processeurs cod�s et autre trucs totalement ind�boulonnables), soit t'as la meilleure protection du monde : ce n'est pas sur un r�seau, ni accessible librement.Citation:
Envoy� par nikko34
Et en plus, il y a quelques centaines de soldats et plusieurs tonnes de munitions pr�ts � te tomber dessus si tu t'approches trop pr�s de la machine, ce qui dissuade en g�n�rale le hacker moyen... :twisted:
Remarque quand-m�me que ils ont trouv� la soluce ultime � ce probl�me : comment peux tu d�sassembler du code que tu n'as pas oO ?Citation:
Envoy� par LittleWhite
@dtcSearch : propose de faire comme eux, on sait jamais :P !
R�ponse rapide � quelqu'un qui n'avait apparemment pas bien lu >< !Citation:
Envoy� par Mac LAK
Si c'est ex�cut� sur ta machine, tu as le code... ;) Ce que tu n'as pas, c'est par exemple le code d'IA ex�cut� sur serveur et pour lequel tu n'as que la question/r�ponse vers ledit serveur.Citation:
Envoy� par Lavock
En dehors de �a, avec un acc�s � la machine, tu peux toujours d�sassembler le code. Rendre la machine d'ex�cution et/ou le fichier ex�cutable inaccessibles est une protection totalement ind�pendante de la possibilit� de d�sassembler ou pas le programme.
Soit faut que je dorme un peu plus, soit t'es pas super clair... J'ai r�pondu � l'OP, sur sa question "j'aimerai savoir si il exist� des outils qui permettent de rendre le code impossible � d�sassembler? si vous avez des retours?". Le "impossible" est - justement - impossible � faire, et toutes les "protections" pr�cit�es ne peuvent que ralentir la d�sassemblage, et non pas l'emp�cher...Citation:
Envoy� par Lavock
Tu n'aurais pas confondu d�sassemblage et d�compilation ? ;)
Certes, mais dans l'ensemble, tu ne disposes pas [i]vraiment[i] de l'ensemble du code. Je te l'accorde, c'est une approximation grossi�re.Citation:
Envoy� par Mac LAK
Un peu des deux je pense ><... Je r�pondais � diablox0147 qui demandait des pr�cisions que, il me semble, tu avais d�j� fourni.Citation:
Envoy� par Mac LAK
Tu disposes de tout ce qui est r�ellement ex�cut� sur ta machine. Pour prendre un parall�le, c'est comme un site Web : tu as l'int�gralit� du code Javascript et HTML (sur ta machine), mais pour le code PHP sur le serveur, tu n'as que les questions/r�ponses.Citation:
Envoy� par Lavock
Ben �a suffit quand m�me pour permettre � certains hackers de passer au travers... :twisted:
Ah !!! OK, effectivement, on s'est mal compris.Citation:
Envoy� par Lavock
Bonjour,
Il y a une approche plus tordue :
- Crypte le programme sensible;
- Faut un deuxi�me programme qui � chaque utilisation :
- demande un mot de passe � chaque utilisation;
- d�crypte et ex�cute le programme sensible;
- efface le programme sensible � la fin de l'ex�cution (le plus facile est de passer par un RAM-disque).
D'un point de vu contractuel, un cracker ne pourra rien faire sans le mot de passe dans un temps raisonnable. (Sauf s'il a acc�s � la machine lors de l'ex�cution du programme).
Cela dit, ce genre de tour de passe-passe ne s'adapte pas � tous les besoins.
Et c'est l� que se joue le drame : via un trojan de type viral, c'est � ce moment pr�cis que tu peux passer outre toutes les protections... Sans m�me parler du fait que tu peux extorquer le MdP, ou encore plus simple : lire l'ex�cutable d�crypt� directement, pendant son ex�cution...Citation:
Envoy� par mabu
J'insiste, mais tant qu'il n'y a pas de protection physique de la machine (= impossibilit� d'acc�der � la machine et aux fichiers ex�cutables), toute forme de "protection" n'est qu'un simple facteur de ralentissement. Et beaucoup de ces protections ne sont en plus qu'un �cran de fum�e avec une faille b�ante dedans : le logiciel reste ex�cutable sans contraintes.
A part jouer avec un dongle de cryptage qui va remplacer des instructions du programme (ce qui revient � d�porter du code dans une sorte de processeur cod�, d'ailleurs), il n'y a PAS de solution sans failles... Et elles sont souvent assez grosses, en plus.
Certes, on peut cumuler les protections les unes sur les autres d�s que l'on en trouve une. Toutefois, il faut voir que toutes ne sont pas forc�ment compatibles entre elles pour commencer, ou peuvent produire des effets de bord ind�sirables. Ensuite, cela va consid�rablement alourdir le programme, que ce soit au niveau de la taille de l'ex�cutable qu'au niveau des performances / ressources consomm�es.
A partir d'un certain moment, qui � mon sens va arriver tr�s vite, il deviendra bien trop p�nalisant de tenter de continuer � prot�ger l'ex�cutable.
Quant � prot�ger physiquement la machine, �a va �tre difficile suivant le type d'application... Notamment si elle est d�ploy�e sur toutes les machines de l'entreprise.