Discussion :

[souviron34]

Le gros probleme actuellement c'est que meme obfusqué le code reste assez facilement craquable. C'est encore plus vrai avec les codes sur des machines virtuelles tel que .net ou java ou là les generateurs de code inversé font des merveilles.

ben ça c'est totalement normal (et déjà traité plus haut dans le sujet), puisqu'en grande partie le code est en clair.... et "compilé" au runtime...

[edfed]

il y a deux solutions pour proteger son code du reverse enginering.

le cryptage du code.
la clé LPT, utilisée comme parametre dans le programme.

je propose une combinaison des deux:

faire un crytage du programme avec un petit crypteur à base de randxor necessitant la presence d'une clé (un code d'initialisation du generateur pseudo rand) sur le port paralelle pour bien decrypter le programme et le lancer.
alors à moins que les clients se mettent eux aussi à cracker du code pour le voler, ça devrait aller.
je met n'importe qui au defi de desassembler un tel programme sans la clé, avant qu'une meilleure version ne voie le jour.

[_skip]

Et pour ce qui est du coût de mise en place?

[edfed]

le cout du truc de cryptage?
pas enorme.
il faut juste creer une clé LPT, un programme de decryptage (en general le meme que celui du cryptage) ce programme de cryptage est la seule partie du code à etre non cryptée.
l'algo d'implementation de cette methode est hardcore par contre.
il faut que le programme .EXE soit crypté, et aussi que le HEADER soit non crypté. et le decrypteur doit etre le point d'entrée du programme.
voire avec des habitués de la programmation .EXE pour plus de details.
pour ce qui est de la clé materielle, ça coute pas cher, moins cher que le manque à gagner en cas de vol.

[Médinoc]

Trouver la clé de cryptage n'est pas forcément si difficile que ça s'il y a des séquences connues: par exemple, si on sait que la première instruction du main() est d'empiler le frame pointer (oui, je sais que ça ne se fait plus beaucoup de nos jours) ou des motifs similaires...

[edfed]

seulement, la clé est une clé pour un generateur aleatoire.
et le mec qui code le programme à proteger ne vat pas ecrire le debut de maniere conventionelle.
la clé peut faire autant de bits qu'on veu.
si il le faut, la clé peut aussi etre en deux parties, trois parties, x parties.
le cryteur du programme peut aussi etre crypté, et ceci est possible sur un nombre d'etages infini.
donc, le mec qui veu cracker le code, il serai obligé de chercher des dixaines de clés, il finirait à l'asile de fou avant d'avoir trouvé la troisieme clé.

[Médinoc]

Ou bien, comme le client possède forcément la clé, il peut toujours soit acheter le produit s'il est pour le grand public, soit glisser une envoloppe à un employé du client...

[edfed]

il reste là solution du crypteur qui demande l'entrée d'une clé decidée sur le site de l'editeur. et qui necessite une webcam pour voir si c'est bien le client normal qui veut faire fonctionner le programme, en esperant que le client n'ai pas de jumeaux hackers.
sinon, fournir un programme super bien, bien maitenu, avec un bon sav, des evolutions logicielles frequentes, ça aide à le proteger.

[_skip]

Ce qui me dérange, c'est que sur les dernières cartes mère, les ports LPT commencent à disparaître.

[edfed]

alors, une clé sur le port serie, ou meme un fichier dans une clé usb, voire sur un cd rom.
mais bon.
je trouve ça de toute façon tres abusif.
comme si tout le monde etait un sale voleur.
comme je l'ai ecrit dans le post precedant, un programme bien maintenu et souvent mis a jour n'a pas trop de raisons d'etre cracké.

[ptah35]

Bonjour à tous,

edfed, je pense effectivement que la grande majorité des gents ne sont pas des voleurs; cependant, peu d'entre eux lisent les contrats de licence et s'ils peuvent d'installer une application sur deux PC sans aucune limitation, ils n'auront pas le moins du monde l'impression de voler quoi que ce soit.

Je travail dans un domaine ou la facturation à l'utilisation (pay-per-use) est important et comme une grande partie de nos client travaillent dans des réseaux qui ne peuvent pas être connectés à l'Internet, nous sommes forcé de protéger notre code.

Comme il a déjà été dit, assembleur, IL ou Bytecode, peu importe du code peut-être lu, compris et modifier. Notre stratégie est donc de combiner plusieurs techniques dont l'obfuscation et l'encryptions du code contre l'analyse statique, du code de détection de dévermineurs contre l'analyse dynamique et plusieurs niveaux d'encryptions et de validations des compteurs d'utilisations pour les protéger contre des modifications frauduleuses.

Il va de soit qu'aucune de ces barrière n'est infranchissable, puisque si le programme peut modifier les données des compteurs alors n'importe qui peut le faire. Nous avons pris le parti d'ajouter autant de protection que nécessaire pour décourager les pirates occasionnels qui pourrait exister parmi nos clients, sans pour autant mettre en péril la maintenance et la stabilité de l'application.

Quelque soit le mode de protection, je crois qu'il est particulièrement important de soigner la communication avec le client dans le cas où le système de protection détecte un problème. Il peut toujours s'agir d'un faut positif et il serait alors très malvenu de traiter un client de pirate.

Meilleures salutations,
Jérôme

[_solo]

il faut que le programme .EXE soit crypté, et aussi que le HEADER soit non crypté. et le decrypteur doit etre le point d'entrée du programme

trop basique comme protection tant qu'a faire un crypteur/decrypteur , emprunter les techniques utiliser en matiere de devellopement virale : du code metamorphique ( le code du crypteur/decrypteur change apres chaque execution ) .

Je ne suis pas du tout convaincu de ton « énormément ».
Ce « challenge » est-il une étude statistique ?
Je suppose que non.

encore un qui croit dans les discourts des commerciaux lol

definition[statistiques] mirroir au alouette des dsi/rssi

[kisitomomotene]

L'utilisation des web services (une partie de l'application s'exécute localement chez le client, une autre sur un serveur distant par les web services ) n'est elle pas une solution fiable? car pour craquer entièrement l'appli, il faudrait accéder à mon serveur!
Java offre aussi une solution plus souple en permettant de télécharger au moment de l'exécution certaine module de l'application.

[Garulfo]

[...]
encore un qui croit dans les discourts des commerciaux lol

definition[statistiques] mirroir au alouette des dsi/rssi

Non je crois dans les discours (sans 't') scientifiques comme tout bon scientifique que je suis. Ne te prononces pas sur qqun que tu ne connais pas.

Ton challenge n'a aucune valeur d'étude et ne permet certainement pas de pouvoir juger. Pour que tu puisses dire « énormément » il faut que tu ai des preuves basées sur autre chose que ce que tu vois. Car, jusqu'à preuve du contraire, tu es une personne avec ses expériences mais pas une référence mondiale en la matière. Tu as donc une vue biaisé par ce que tu vis directement qui t'empêches d'appréhender la généralité des cas a priori. C'est un phénomène connu.

[_skip]

L'utilisation des web services (une partie de l'application s'exécute localement chez le client, une autre sur un serveur distant par les web services ) n'est elle pas une solution fiable?

Je dirai que c'est excellent si tu veux protéger un savoir-faire, mais faut que le contexte d'exécution et les contraintes de vitesse le permettent.
Malheureusement, la haute disponibilité est souvent requise, on peut pas fermer l'entreprise si y'a une coupure d'internet.

[_solo]

Non je crois dans les discours (sans 't') scientifiques comme tout bon scientifique que je suis. Ne te prononces pas sur qqun que tu ne connais pas.

je ne juge pas les gens juste leur propos lol

Ton challenge n'a aucune valeur d'étude et ne permet certainement pas de pouvoir juger. Pour que tu puisses dire « énormément » il faut que tu ai des preuves basées sur autre chose que ce que tu vois.

Non rectification pas sur ce que je vois mais ce sur que je fait presque tous les jours

Car, jusqu'à preuve du contraire, tu es une personne avec ses expériences mais pas une référence mondiale en la matière. Tu as donc une vue biaisé par ce que tu vis directement qui t'empêches d'appréhender la généralité des cas a priori. C'est un phénomène connu.

c'est vrai

[Garulfo]

je ne juge pas les gens juste leur propos lol

Quand tu dis que « je crois les discours commerciaux » tu portes un jugement sur moi et non sur ce que je dis : « ça n'est pas une étude statistique. »

Non rectification pas sur ce que je vois mais ce sur que je fait presque tous les jours [...]

Et donc ce que tu vois.
C'est pourquoi quand tu avances ce que tu as avancé, il te faut une étude sérieuse. Le challenge que tu as posté ici est très intéressant, mais loin de pouvoir servir d'étude.

[unrealfreerider]

bonjour,


le reverse engineering est une technique qui constiste à etudier
le code/autre dun site pour essayer de trouver ce qu'il faut pour arriver à son but.

donc tout dépend du but, du site, et des webservices qu'il propose...

Cordialement

eX-

[carl1]

trop basique comme protection tant qu'a faire un crypteur/decrypteur , emprunter les techniques utiliser en matiere de devellopement virale : du code metamorphique ( le code du crypteur/decrypteur change apres chaque execution ) .

Code polymorphique ou non, toute protection est inutile.
Ca se cracke soit en 30 secondes, soit en 3 jours, mais aucune ne peut résister à un simple debugger.

[_solo]

Code polymorphique ou non, toute protection est inutile.
Ca se cracke soit en 30 secondes, soit en 3 jours, mais aucune ne peut résister à un simple debugger.

je veux bien ta doc si tu me casse un truc comme ca en 30 seconde ou 3 jour http://cat.inist.fr/?aModele=afficheN&cpsidt=5053511

rienque le 3DSmax ( 2007 si ma memoire me fait pas defaut ) a resister 9mois en beaucoup moins complexe et la c'etait pas du crackeur de bac a sable , mais la ca devait etre plus pour l'ego et le challenge intellectuel qu'autres choses .