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.
Entièrement plussoyer ! Si c'est pour du "long terme", ça sert vraiment à rien >< ! C'est dans le JV qu'on trouve le plus de protection "grand public", et là, tous les indus te diront que ce sont des protections courtes... Qui en plus te font généralement mauvaise presse...Citation:
Envoyé par Mac LAK
Citation:
Envoyé par Mac LAK
Je suis d'accord avec vous, mais je vois mal dtcSearch dire au commercial ou au client "C'est pas possible".Citation:
Envoyé par Lavock
La solution idéale n'existe pas, mais il doit bien y avoir un compromis.
Si le demande du client final est vague, une simple protection UPX devrait lui suffire, si les détails de la protection sont donnés (chiffrés) c'est qu'il doit avoir une idée derrière la tête, mais je pencherai plutôt pour la première solution.
La solution idéale c'est comme l'a dit mac_lak d'avoir des cpu qui intégrent des technologies qui permettent de mettre en oeuvre ce genre de sécurité. (instruction chiffré etc). C'est le cas de l'architecture de la PS3 il me semble. Tout est codé...
S'il est CP, c'est pourtant bien son problème de le dire au client... S'il n'est que le pauvre dév à qui l'on a balancé la patate chaude, alors il y a quelqu'un de mieux payé que lui dont c'est le boulot... Au pire, tu renvoie le responsable initial, c'est à dire celui qui a dit "oui, on va le faire".Citation:
Envoyé par mabu
Au moins, l'OP a les billes pour pouvoir dire pourquoi ce n'est pas possible. Le reste, c'est l'affaire du client qui devra expliciter son besoin réel, et du CP qui négociera une dérogation.
Ceci étant dit, vu les sommes qui seront englouties par une protection un minimum décente, je n'ai pas beaucoup de doutes sur le fait que le client se contentera d'un exécutable strippé... :twisted:
Ce n'est d'ailleurs pas neuf : l'architecture [ame="http://fr.wikipedia.org/wiki/CPS2"]CPS2[/ame] fonctionnait également ainsi. La protection a tenu le coup pendant sept ans, avant d'être complètement déplombée... Tout ça parce qu'il y avait un accès physique aux machines, bien sûr.Citation:
Envoyé par Goten
Le problème, c'est que ce sont systématiquement des fabrications spécifiques (on ne peut pas acheter de processeur codé dans le commerce). Et étant donné que la fiabilité de la protection réside dans le fait de ne PAS expliquer l'algo de codage, il est évident qu'en fabriquer un soi-même impose de repartir de zéro ou peu s'en faut.
On peut en partie utiliser des CPU codés virtuels implantés sur des ASIC/FPGA, mais c'est pas très reluisant côté perfs par rapport à un processeur "fondu"... Et l'accès par JTAG n'aide pas à rendre le machin inviolable, en plus.
C'est marrant que certains croient encore au secret du code comme assurance de sécurité. Le principe Kerckhoffs existe depuis les années 1880 et pourtant, il y en a encore qui n'ont pas tilté.Citation:
Envoyé par Mac LAK
mabu > Je ne vois pas pourquoi ce serait à dtcsearch de supporter les conneries du commercial. Qui plus est, si tu ne remet jamais le commercial en face de ses anneries, il continuera à te vendre n'importe quoi et faudra assurer des truc impossible derrière.
Il a vendu un truc impossible, faut assumer maintenant.
Et si jamais c'est dtcsearch qui se pose cette contrainte lui-même, bah faut assumer quand on fait des conneries.
Dans un monde logique, je suis d'accord.Citation:
Envoyé par deadalnix
Mais imagine qu'un un commercial ai lu magazine parlant de ça sans le comprendre ou qu'il soit très haut placé dans la boite... (oui c'est du vécu).
En réponse au post initial, tu peux effectivement regarder du coté des "packers" genre Armadillo ou autre....
Ces packers permettent de crypter l'exécutable, protéger le fichier avec un checksum (entre autre) il est ensuite décrypté lors de l'exécution (en mémoire).
Il faut cependant savoir que comme dit plus haut, il est toujours possible de l'exécuter avec un debugger (genre ollydbg) et la on voit tout le code assembleur (donc le décryptage... jusqu'à l'exécution du programme réel). Le principal intérêt étant finalement de protéger le code orignal de toutes modifications (pour faire des cracks par exemple).
Cependant même avec ce genre de protection, toujours avec ollydbg par exemple, un mec avec un peu de cerveau peu arriver à trouver le point d'entré du programme réel et donc du coup faire un dump et arriver a reconstruire le fichier exécutable non crypté et du coup facilement modifiable.... on trouve même des outils tout prêt pour faire ce genre de choses...
En expérant avoir un peu éclairé ta lanterne :)
Perso je le fais. Je t'avoue que ça ne s'est pas toujours bien passé, mais je préfère encore ça.Citation:
Envoyé par mabu
Je vous remercie tous, je pense que la demande du client sera tout simplement refusé pour non faisabilité.
J'en ai appris pas mal sur le sujet grâce à vous, je laisse le sujet ouvert au cas où ;)
merci
Heu... Ai-je dit le contraire ?? Bien entendu que ce n'est pas une assurance de sécurité, c'est simplement un facteur de ralentissement avant désassemblage et reverse. Je l'ai dit, sans matériel de support non dumpable, c'est impossible à effectuer. Pour citer ce principe, c'est un des (très rares) moyens de sévèrement ralentir la connaissance du système, de préférence bien au delà de la limite de validité des données protégées. Jusqu'à l'arrivée des système quantiques, on n'a pas mieux en stock à proposer.Citation:
Envoyé par deadalnix
La seule chose qu'une protection "soft" peut permettre, c'est d'exploser l'utilité du reverse : sur un programme spécifique, dont les sources ne sont pas disponibles, plomber l'exécutable permet de rendre plus coûteux le fait de le cracker que de l'acheter... A condition que le prix de la licence soit bien sûr adapté au niveau de la protection, et que la protection soit adaptée aux enjeux liés au programme (financiers, politiques, voire militaires). Il est évident que c'est très difficile à équilibrer correctement, comme équation...
A noter que ceci n'est plus vrai dès qu'il y a diffusion de masse : le nombre de cracks / hacks disponibles pour les jeux et autres programmes vastement diffusés en est la preuve la plus flagrante.
Bien sur que non, c'était pour plussoyer dans ton sens.Citation:
Envoyé par Mac LAK
OK, je me disais aussi... ;)Citation:
Envoyé par deadalnix