Discussion :

[souviron34]

Si Einstein avait eu une société de fabrication de bombes A, je ne suis pas sûr qu'il aurait publié ...

d'ailleurs, il suffit de voir les pieds et les mains que font que ce soit la France ou les US pour empêcher que d'autres pays possède la bombe (et si vous croyez que c'est pour la paix, vous êtes bien naifs)..

Qui a publié comment ça se faisait ?

[GnuVince]

Le problème, c'est que si le code source est vendu avec, un client peu scrupuleux peut diffuser sur internet le code de vérification de la clé de license (point 2) ou tout simplement supprimer ce code pour permettre au programme de tourner sans license.

C'est d'ailleurs la principale motivation de la Security Through Obscurity: Ce n'est pas pour protéger le client des hackers, mais pour protéger l'éditeur des clients...

Et évidemment, il existe aucun keygen pour des logiciels propriétaires? Personne a jamais fait de no-cd crack?

[Médinoc]

Si, bien sûr.
Je n'ai jamais dit que c'était efficace, seulement qu'ils le faisaient...

[Garulfo]

[...] Si Einstein avait eu une société de fabrication de bombes A, je ne suis pas sûr qu'il aurait publié ...

Et c'est d'ailleurs peut-être une des raisons pour laquelle il ne l'a pas fait.
Un vrai et pur scientifique a ce besoin de donner son savoir au monde et de publier. Sinon ce n'est qu'une marionnette pour quelqu'un d'autre.

Mais publier un article scientifique n'a rien à voir avec écrire un programme. Difficile de faire un lier direct.

[_solo]

Qui a publié comment ça se faisait ?

the register et wired sans oublier les eternelles manuels du parfait petit anarchiste .

Et pendant ce temps on se 'fatigue' le verceau sur les pseudos logiciels fait par des soit-disaant djihadistes qi vont 0wn3d th3 w0rld... j'ai exploser de rire que j'ai vu ce qu'il avait fait meme mon neveu de 10ans qui va sur ces 15 fait mieux

Dès lors, personne ne sera assez idiot pour tenter de déssassembler ton code... enfin j'ose le croire

il s'avere que enormement de faille de secu sont souvent decouvert apres desassemblage de binaire et ce meme dans le libre non! non! c'est pas une blague pour t'en convaincre regarde les challenges de pull the plug .

[Garulfo]

mon neveu de 10ans qui va sur ces 15 fait mieux

Il ne passe pas par 11, 12, 13 et 14 d'abord ?

il s'avere que enormement de faille de secu sont souvent decouvert apres desassemblage de binaire et ce meme dans le libre

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

[shkyo]

Personnellement, je pense que tout est une question de motivation (et de compétences... )...

Toutes les protections logiciels & matériels ont toujours été cassé par des gens très motivés (et compétents), regardez l'exemple récent du iPhone aux usa, côté dévérouillage ça n'a pas trainé !!

Ou même les protections de DVD, aucun n'y résiste, et même les nouveaux formats du type blue-ray ou hd-dvd y sont passés aussi, ils peuvent maintenant être copier sans problème...

Quelqu'un de suffisament motivé arrivera toujours à ces fins, il y a des exemples dans le monde des hackers qui montre plusieurs mois d'acharnement avant d'y arriver...

Je pense que les logiciels très bien développés et adaptés à un (ou des) besoin, se vendront bien de toute façon.
Souvent, ceux qui pirates les softs ne les auraient pas acheté de toute façon...
Regardez les bons jeux sur PC, ils se vendent par centaine de milliers, alors que sur PC, ça fait longtemps que la copie est très facile !

Et en plus, je pense que quand on maîtrise (réellement !) l'assembleur, presque tout est possible, et ce sera encore vrai dans 10 ou 20 ans...

[JPDMJC]

j'ajouterai que ça dépend aussi à qui l'on distribue le logiciel.

- un logiciel genre MS Word : biensûr qu'il sera craqué quelques jours après sa sortie, et c'est normal vu le nombre de gens qui peuvent s'y attaquer. Dans ce cas la protection ne peut que limiter la casse (si casse il y a).

- un logiciel qui, par exemple, est distribué à UNE (ou peu de) société, disons la SNCF : vous croyez que les secrétaires et autres employés ou encore le patron vont ne serait-ce que penser à craquer le logiciel ?
Biensûr que non, car non seulement ils n'ont pas les gens fais pour ça, mais bonjour la super-prune lors du prochain contrôle : où sont les licences ? ^^. Et pas ce licence : pas de support technique. Pas de support technique : pas de "allô, ça marche pas", et pas de "allô ça marche pas" : c'est la cata, hahaha !

Et pour finir sur "Peut-on protéger son code du reverse engineering ?", à mes yeux la réponse est naturellement NON.
Le reverse-machin-truc, la base du principe, c'est quand même "quel est le principe de ce procédé ?" pour en arriver à "j'ai compris son truc et je suis capable de faire un autre procédé qui fait la même chose, ou du moins qui donne le même résultat".
Bref, je ne vois pas comment se prémunir de la réflexion humaine. On a déjà démontré dans ce sujet que l'on pouvait rendre le procédé moins attractif, mais c'est tout.

[sakli]

Merci pour toutes les informations et les éclaircis.

[mouhammed]

Je ne pense pas qu'il soit possible de protéger ton code du reverse engineering car il est toujours possible de le desassembler ou de le voir en hexa, mais la il faut des connaissances très pointu en informatique, de plus ca doit vraiment valoir le coup. A mon avis seul le entreprises pense a ce geanre de trucs.

[shkyo]

Je ne pense pas qu'il soit possible de protéger ton code du reverse engineering car il est toujours possible de le desassembler ou de le voir en hexa, mais la il faut des connaissances très pointu en informatique, de plus ca doit vraiment valoir le coup. A mon avis seul le entreprises pense a ce geanre de trucs.

Un des intérêts du reverge engineering (mis à part le fait de vouloir comprendre un truc) est pour les virus !

Les gars capables de détecter un nouveau virus, de le choper, de le désassembler et de comprendre ce qu'il fait sont assez forts, et utiles !!!

Et la-dessus certaines dernières générations de virus commence à utiliser un peu de cryptage de code pour tromper l'ennemi...

[Bluedeep]

Je ne pense pas qu'il soit possible de protéger ton code du reverse engineering car il est toujours possible de le desassembler ou de le voir en hexa, mais la il faut des connaissances très pointu en informatique.

Si on commence à qualifier la capacité de lire l'assembleur de "connaissance très pointue en informatique", c'est que l'informatique est tombée bien bas ...

[shkyo]

Si on commence à qualifier la capacité de lire l'assembleur de "connaissance très pointue en informatique", c'est que l'informatique est tombée bien bas ...

Ah ?? Je ne vois pas ce qu'il y a de "bien bas" à maîtriser les entrailles de sa machine ?
C'est sur, c'est très loin de Java ou PHP, mais ce n'est pas fait pour le même usage !

Peux-tu étayer ton propos ?

[Bluedeep]

Ah ?? Je ne vois pas ce qu'il y a de "bien bas" à maîtriser les entrailles de sa machine ?
*

Tu donnes à ma phrase exactement le sens contraire de celui qu'elle a. Re-lis len-te-ment ma phrase, ainsi que l'intervention à laquelle je répondais.

Je veux dire que, pour moi, connaitre un minimum d'assembleur est un "basic" incontournable (par "un minimum", j'entends être capable de déchiffrer la signification d'une "routine" pas trop longue, et pas être capable d'écrire un OS complet), et que, donc, affirmer que connaitre cela constitue une compétence pointue (ce "cela" que je considère comme un minimum) semblerait indiquer que le niveau en IT est tombé bien bas.

T'as compris maintenant ?

[shkyo]

Tu donnes à ma phrase exactement le sens contraire de celui qu'elle a. Re-lis len-te-ment ma phrase, ainsi que l'intervention à laquelle je répondais.

Je veux dire que, pour moi, connaitre un minimum d'assembleur est un "basic" incontournable (par "un minimum", j'entends être capable de déchiffrer la signification d'une "routine" pas trop longue, et pas être capable d'écrire un OS complet), et que, donc, affirmer que connaitre cela constitue une compétence pointue (ce "cela" que je considère comme un minimum) semblerait indiquer que le niveau en IT est tombé bien bas.

T'as compris maintenant ?

OKOK ! Effectivement, j'avais compris l'inverse, désolé...

Sinon, je suis bien d'accord avec toi sur le fait de connaître un minimum d'assembleur est un basic, mais par contre, moins d'agressivité dans les réponses serait mieux, reste zen...

[Bluedeep]

moins d'agressivité dans les réponses serait mieux, reste zen...

Ma réponse ne contenait pas une once d'agressivité. J'avoue ne pas comprendre où tu as pu en trouver

[_skip]

Bonsoir,
Je souhaiterai intervenir sur ce sujet surtout pour répondre à tout ceux qui disent que la protection ne sert à rien, que de toutes façons une personne motivée finira toujours par cracker un logiciel etc...

Particulièrement sur ce post :

Et ça sert à quoi de faire des pieds et des mains pour empêcher quelqu'un de voir le code de votre application? S'il est vraiment motivé, il va y arriver.

Personnellement, j'ai toujours trouvé que si du code était caché, c'était pour trois raisons:

1. Le code est tellement mauvais que personne voudrait jamais utiliser une application si mal codée
2. Le programmeur pense qu'en cachant le code, son application est plus sécure
3. Le programmeur pense qu'il est le plus brillant programmeur au monde et que personne ne serait jamais capable de faire une fonctionnalité comme il l'a fait

Sans vouloir vexer ou insulter qui que ce soit, il faudrait peut être réfléchir un peu plus loin que le bout de son nez avant d'affirmer ce genre de chose. C'est peut être vrai pour les petites bricoles et application de style notepad diffusées sur internet, mais c'est une théorie qui atteint très vite ses limites sitôt qu'on entre dans le milieu professionnel.

Dans la société pour laquelle je travaille, nous avons bossé sur une application en .Net durant plus d'une année... Les montants investis par la société sont conséquents (des milliers d'heures de travail) et ont été en partie amenés par des emprunts bancaires et de ce fait notre survie dépend du retour sur investissement, soit directement de la vente.

Imaginez donc la catastrophe que cela serait si un concurrent peu scrupuleux pouvait en deux ou trois jours, au prix d'efforts insignifiants revenir au code source de notre logiciel, il lui suffirait de changer le logo et de faire quelques adaptations pour s'approprier le fruit de notre travail qu'il pourrait ensuite offrir aux clients à un prix imbattable.
Ne venez pas me dire que personne ne ferait cela, des entreprises de crapules j'en connais plein, il y en a déjà un paquet qui se permettent d'installer des SGBD et des logiciels en clientèle sans payer de licences ou même d'employer carrément des outils commerciaux crackés pour leur développement.

Le choix d'une protection (en l'occurrence obfuscation) n'a absolument rien a y voir avec la qualité du code source ou des problèmes d'ego démesuré. Il s'explique par le fait qu'on ne veut pas se faire coiffer au poteau après avoir enduré une pression considérable due aux investissements et à la prise de risque. Bien sûr, cette protection n'en est pas une pour celui qui veut y passer du temps, mais elle multipliera sans doute par 100 ou 200 le temps nécessaire à la compréhension du code et à son refactoring vers quelque chose de maintenable et entre temps, nous aurons des updates qui permettront de conserver notre avance.
En effet, vous imaginez que s'il s'agit de comprendre un programme dans lequel tous les noms de classes, variables et fonctions ressemblent aux résultats de hash MD5, c'est presque plus vite fait de tout recoder que d'essayer d'en faire quelque chose d'exploitable.

Vous l'aurez compris, ce n'est pas tant de protéger à tout prix le produit qui compte, mais au moins suffisamment de temps pour assurer le retour sur investissement en empêchant les autres d'exploiter le fruit de votre propre travail à vos dépens.
Il en est de même pour le jeu vidéo que quelqu'un a cité. Selon ce que j'ai pu lire (ce n'est pas mon invention), les éditeurs de jeuxvidéo qui ont recours aux protections espèrent qu'elles seront efficace au moins quelques jours après la sortie du produit car c'est à ce moment-là que le gros du bénéfice est réalisé. Ensuite, passé les premiers mois, lorsque l'éditeur a tiré le gros de ce qu'il y avait à tirer, à la limite il s'en fiche que le jeu se fasse cracker.

Donc non ça ne sert pas à rien de protéger, même si des personnes motivées finissent plus ou moins toujours par casser la protection et diffuser les cracks sur le net.

[GnuVince]

Dans la société pour laquelle je travaille, nous avons bossé sur une application en .Net durant plus d'une année... Les montants investis par la société sont conséquents (des milliers d'heures de travail) et ont été en partie amenés par des emprunts bancaires et de ce fait notre survie dépend du retour sur investissement, soit directement de la vente.

Imaginez donc la catastrophe que cela serait si un concurrent peu scrupuleux pouvait en deux ou trois jours, au prix d'efforts insignifiants revenir au code source de notre logiciel, il lui suffirait de changer le logo et de faire quelques adaptations pour s'approprier le fruit de notre travail qu'il pourrait ensuite offrir aux clients à un prix imbattable.

Ne venez pas me dire que personne ne ferait cela, des entreprises de crapules j'en connais plein, il y en a déjà un paquet qui se permettent d'installer des SGBD et des logiciels en clientèle sans payer de licences ou même d'employer carrément des outils commerciaux crackés pour leur développement.

Salut _skip,

Bien que je suis pas complètement d'accord avec ton point de vue, je le respecte et je comprends ce que tu veux dire. On est des programmeurs ici, on vit du code que l'on écrit et se le faire voler est chien en sacrament.

Celà dit, j'aimerais adresser un point, celui du concurrent déloyal qui prend le code source, le recompile sous son nom et l'offre à un moindre prix. Il y a un recours contre celà: une poursuite en justice.

Si on fait une analogie avec les livres, on pourrait dire que comme les mots du livre sont directement accessibles à tous, un auteur peu scrupuleux pourrait reprendre le scénario, changer le titre, peut-être le nom des personnages et le publier. Évidemment, ça prendrait peu de temps avant qu'il se fasse amener en court.

Dans les deux cas, je crois pas qu'il serait difficile de prouver qui est le vrai auteur.

C'est sûr que la plupart des gens aimeraient mieux ne pas avoir à aller en court pour ce genre de problème s'ils peuvent être évités en ayant du code non-lisible (dans le cas d'un langage à implémentation interprétée) ou non-textuel (code compilé), mais c'est une possibilité.

L'obfuscation du code me cause également des problèmes (par contre j'ai fait 0 recherche, donc corrigez-moi si je fais erreur) avec du code qui utilise de la réflection. Par exemple, voici un programme Perl:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
use strict;
use warnings;

my %colors = (
    blue => "#0000ff",
    red => "#ff0000",
    green => "#00ff00",
);

{
    no strict;

    while (my ($color, $color_code) = each(%colors)) {
        *$color = sub {
            "<font color=\"$color_code\">@_</font>";
        };
    }
}

print red("Hello"), "\n";
print green("World"), "\n";

Les fonctions red(), green() et blue() sont définies dynamiquement. Qu'est-ce qui arriverait si on utilisait un obfuscateur? La définition resterait très certainement la même, mais est-ce que le nom des fonctions dans les appels changerait?

Mon problème reste toujours la capacité à m'aider moi-même. J'ai un exemple concret, cette semaine je cherchais une galerie en Flash pour le site web d'un client. J'en ai trouvé plusieurs gratuites, par contre aucune ne fonctionnait. La raison est que j'utilise Django et que les URLs ne sont pas représentatives de la structure des dossiers, contrairement à quand on utilise du HTML pur ou du PHP.

Aucun des logiciels fournissait le code source, j'ai donc dû abandonner l'idée de la galerie Flash (pas une mauvaise chose de mon point de vue, mais le client en sera certainement déçu.) Si le code avait été disponible, j'aurais -- peut-être -- pu l'éditer et faire les modifications nécessaires pour qu'il fonctionne dans mon environnement.

En enlevant la possibilité (facile) à des personnes peu scrupuleuses de voler le code source, on enlève également la possibilité à d'autres programmeurs d'arranger le code pour leur environnement. J'imagine que la différence d'opinion dépend de ce qu'on considère comme la possibilité la moins agréable.

[_skip]

Hello GnuVince,
C'était ton post que j'ai cité au départ, je n'ai pas laissé ton nom car je ne voulais pas que ma réaction soit perçue comme une aggression à ton encontre.

Pour ce qui est du vol de code source, bien sûr qu'il existe des lois contre cela mais les procédures juridiques sont fastidieuses et s'étalent parfois sur des années tout en demandant de grands frais. Et tout cela sans avoir la garantie du gain de cause.
De plus, rien n'indique que l'on va vous concurrencer directement sur votre marché local, peut être que l'on va proposer votre produit en Allemagne, en Autriche ou n'importe ou en Europe.
Et même, il faut déjà savoir que quelqu'un vous a pompé votre produit lorsqu'il s'agit d'un système qui ne se vend pas sur internet mais seulement par l'intermédiaire d'un commercial après négociation avec le client, car souvent vous n'avez absolument pas accès aux offres de vos concurrents.

En effet, l'obfuscation et la reflexion ne font pas bon ménage mais les logiciels d'obfuscation commerciaux ont généralement des techniques qui permettent de détecter ce qui peut ou non être obfusqué, heureusement car sinon tout ce qui est databinding cesserait déjà de fonctionner.
En dehors de ce qui est fait de manière transparente par le framework, nous n'utilisons que très peu de reflexion car il existe souvent (bien que pas toujours) des solutions plus élégantes pour résoudre certains problèmes, de plus, nous sommes adeptes de code fortement typé offrant un maximum de vérification lors de la compilation.
Voici pour ce qui est interne à l'application, en ce qui concerne l'usage extérieur de nos assemblys par reflexion, nous pensons simplement que ça n'a aucune raison d'exister dans le contexte actuel.

Mon problème reste toujours la capacité à m'aider moi-même. J'ai un exemple concret, cette semaine je cherchais une galerie en Flash pour le site web d'un client. J'en ai trouvé plusieurs gratuites, par contre aucune ne fonctionnait. La raison est que j'utilise Django et que les URLs ne sont pas représentatives de la structure des dossiers, contrairement à quand on utilise du HTML pur ou du PHP.

Aucun des logiciels fournissait le code source, j'ai donc dû abandonner l'idée de la galerie Flash (pas une mauvaise chose de mon point de vue, mais le client en sera certainement déçu.) Si le code avait été disponible, j'aurais -- peut-être -- pu l'éditer et faire les modifications nécessaires pour qu'il fonctionne dans mon environnement.

En enlevant la possibilité (facile) à des personnes peu scrupuleuses de voler le code source, on enlève également la possibilité à d'autres programmeurs d'arranger le code pour leur environnement.

Bien sûr, la transparence et la disponibilité du code sont des avantages indéniables si l'usage qui en est fait demeure respectueux de la licence et de l'auteur.
Ce qui est différent dans ton exemple, c'est que déjà à la base le produit que tu as recherché était gratuit, donc on peut sans doute en conclure qu'en ce qui concerne son auteur, ce n'est pas ça qui lui amène le steack sur sa table à midi. Dans mon cas, c'est tout l'inverse.
Donc dans la mesure ou le produit final est de toute manière gratuit, pourquoi ne pas diffuser son code source? En dehors du besoin peut être d'éviter de voir exploser des clones à profusion sur le net, avec ce que çela peut impliquer en terme d'éloignement d'un standard (fichiers de sauvegardes non compatibles, etc...), là je reconnais que ça *pourrait* être l'une des raisons évoquées dans ton post précédent, celui que j'ai cité.

Cependant, je reste d'avis que produit commercial et code source disponible ne font pas souvent bon ménage. Comment convaincre les gens de payer pour ce qu'ils peuvent voler en toute discrétion et sécurité? Bien il existe quelques cas que je peux citer :

- Les utilisateurs enregistrés bénéficient de mises à jour fréquentes et de correctifs contrairement à ceux qui piratent (DevExpress).
- Les utilisateurs enregistrés bénéficient d'un support privilégié en cas d'incident (mySQL)
- La clientèle visée est suffisamment sérieuse pour respecter les droits, pour les produits qui ne visent que les entreprises par exemple (La version de MySQL compatible SAP par exemple)...

Pour le reste, s'il faut s'appuyer sur la seule bonne foi de la population, il suffit de regarder combien de fois par jour, dans les parkings de grands centres commerciaux vous voyez de grands monsieurs tirés à 4 épingles parquer leur gros 4x4 sur les places handicapés pour ne pas avoir besoin de marcher 50 mètres à pied... Je sais pas si c'est que je suis paranoïaque mais j'ai l'impression qu'il faut se méfier.

[zolive]

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.