Discussion :

[dtcSearch]

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.

[deadalnix]

Bah faut bien désassembler à un moment si tu veux que le processeur ai les instructions

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.

[dtcSearch]

malheureusement... je sais bien, mais si y'avais un outil qui complexifierai plus plus la tâche? et le mieux? ça serait lequel?

[koala01]

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

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

[3DArchi]

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.

[dtcSearch]

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?

[3DArchi]

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.

[Mac LAK]

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.

C'est strictement impossible sur un processeur normal.

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.

[deadalnix]

C'est strictement impossible sur un processeur normal.

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.

[LittleWhite]

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 ( 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 ( pardon )

[diablox0147]

Qui pourrais m'éclaire pourquoi ce n'est pas possible d'empecher le désassemblage? plus précis, plus concret et plus technique

[Lavock]

C'est strictement impossible sur un processeur normal.

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.

...

[nikko34]

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... )

[Mac LAK]

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.

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"...

@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...

Qui pourrais m'éclaire pourquoi ce n'est pas possible d'empecher le désassemblage? plus précis, plus concret et plus technique

Ma réponse ci-dessus le fait... Est-ce qu'il y a un point en particulier qui te pose problème ?

...

Mais encore ?

une entreprise qui fait des logiciels pour l'armement... )

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.

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...

[Lavock]

En conclusion, il y a rien de 100% efficace ... sinon Ubisoft ne ferai pas une politique de merde ( pardon )

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 ?
@dtcSearch : propose de faire comme eux, on sait jamais !

Mais encore ?

Réponse rapide à quelqu'un qui n'avait apparemment pas bien lu >< !

[Mac LAK]

comment peux tu désassembler du code que tu n'as pas oO ?

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.

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.

Réponse rapide à quelqu'un qui n'avait apparemment pas bien lu >< !

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...

Tu n'aurais pas confondu désassemblage et décompilation ?

[Lavock]

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.

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.

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.

Soit faut que je dorme un peu plus, soit t'es pas super clair...

Un peu des deux je pense ><... Je répondais à diablox0147 qui demandait des précisions que, il me semble, tu avais déjà fourni.

[Mac LAK]

Certes, mais dans l'ensemble, tu ne disposes pas vraiment de l'ensemble du code. Je te l'accorde, c'est une approximation grossière.

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.

Ben ça suffit quand même pour permettre à certains hackers de passer au travers...

Un peu des deux je pense ><... Je répondais à diablox0147 qui demandait des précisions que, il me semble, tu avais déjà fourni.

Ah !!! OK, effectivement, on s'est mal compris.

[Invité(e)]

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.

[Mac LAK]

[*]décrypte et exécute le programme sensible;

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...

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.