Discussion :

[Corine 2015]

Bien chers tous,

J'avais décidé d'apprendre le langage Java pour développer un programme. Quelques jours plus tard, patatra, un ingénieur en informatique me dit "Java can be easily reverse-engineered ; just see how many Android applications can be cracked nowadays".

Je demande alors à une entreprise qui commercialise des applications grâce auxquelles "les licences d'un logiciel peuvent être protégées" si leur technologie permet de résoudre ce défaut de Java.

Réponse : "Unfortunately we do not have anything that would assist in this area."

Mais alors, que faut-il faire ?

Renoncer à Java ? Développer une Web application en Java ? Appliquer une procédure de sécurité spécifique à Java ? Protéger un logiciel développé en Java grâce à une autre technologie ? Si oui, laquelle ?

Merci.

Bien à vous

Corine

[tchize_]

Les technique de retro ingénirie se sont fortement développé depuis leur début, presque tout le langages peuvent être décompilé sans grosse difficulté. Ca n'a rien de nouveau et quand je regarde en arrière, le seuls système de protection qui ont jamais vraiment fonctionné étaient ceux où ce sont les serveurs qui font le travail. On ne peux pas craquer quelque chose qu'on n'a pas. C'est comme ça que survivent les gros licenses de jeu. Si tu ne peux pas jouer en ligne et que le jeu est inutile en solo, l'intérêt du crack deviens limité. Ca n'a rien de spécifique à java et si tu débute, ce n'est pas ça qui doit t'arrêter. Pour faire simple, si tu veux viser le marché mobile tu sera obligé de faire de l'android et de l'ios, donc au final que ce soit crackable ou pas t'intéresse peu. Après des boites vendent des solution qui bidouillent le byte code pour rendre la décompilation difficile ou impossible, mais ça n'a jamais arrêté un crack On n'a pas besoin de pouvoir décompiler une application pour faire un crack, quel que soit le language.

[joel.drigo]

Salut,

Oui, les applications Java peuvent être facilement décompilées et étudiées. Maintenant, ce n'est pas le seul langage qui soit dans ce cas. D'ailleurs, on peut faire aussi l'effort d'étudier du langage machine si on veut, et beaucoup de hackers ne s'en privent pas d'ailleurs.

Ensuite, dans le domaine professionel ou industriel, le source n'est pas tout. Dans le modèle économique de ma société, on fournit des applications Java, en code source non protégé (on envisage même de les passer en open source, du moins pour une application). Les licences ne concernent pas l'applicatif, mais juste son usage et le service qui va avec.
Celle sur laquelle je bossais il y a peu de teps avait plus d'1 millions de lignes de code : il faut déjà être motivé pour faire le reverse-ingeniering, en avoir le temps, et l'intérêt surtout. Mais ce qu'on fait payer avant tout, c'est le service qui va avec, service sans lequel avoir l'application ne permet pas d'aller très loin.
Sur l'autre applicatif qu'on distribue, nos clients nous commandent régulièrement des évolutions : ils n'ont aucun intérêt à les faire eux-même.

Ensuite, on pourrait imaginer qu'une bande de gars regardent nos sources et reconstruisent une application à l'identique pour la vendre : quel intérêt de passer du temps à lire notre code ? Autant réécrire from scratch une application originale : il y a bien plus de chance de la vendre, et au moins, on maitrise la technologie et le service qui va avec, et on apporte sur le marché une vraie nouveauté qui peu amener un client à choisir cette application plutôt que la nôtre. En plus, je les vois bien se présenter aux mêmes appels d'offre que nous avec une application identique. Faudrait qu'il soit nettement moins chers pour devenir intéressant, et proposer un service au moins équivalent.

Evidemment, il peut y avoir des parties technologiques originales : mais là c'est pareil, le source n'est pas tout, il faut maitriser la techno aussi. Après, l'important c'est de rentabiliser la techno le plus vite, pour que si quelqu'un d'autre l'imite, on n'ait plus à craindre de perdre l'investissement en R&D et qu'on ne soit plus que sur de la concurrence classique (sur le service donc).

[hwoarang]

Quelques jours plus tard, patatra, un ingénieur en informatique me dit "Java can be easily reverse-engineered ; just see how many Android applications can be cracked nowadays".

Et moi, je te dirais : "C++ can be easily reverse-engineered ; just see how many C++ games can be cracked nowadays". Et j'aurais dit une betise aussi grosse que celle de ton ami.
Deja, il n'y a pas de lien direct entre la decompilation et le crack. Bien sur, c'est plus simple de cracker un programme decompilé puisqu'il est plus lisible mais un programme compilé n'a jamais arreté un hacker.

Ce qu'il faut savoir, c'est qu'un programme informatique pourra toujours etre hacké (quel que soit le language). L'effort pour le proteger doit etre proportionnel au besoin de protection. Mais comme ca a été dit, la seule protection fiable est de ne pas donner l'executable (typiquement en laissant tout sur un serveur). De toute facon, dans la plupart des cas, ce n'est pas le programme lui-meme qui a de la valeur mais les données qu'il utilise. Et c'est elles qu'il faut proteger.

[Corine 2015]

Bien chers tous,

Merci beaucoup à hwoarang, joel.drigo, tchize_.

Vos arguments sont intéressants et convaincants.

* * *

la seule protection fiable est de ne pas donner l'executable (typiquement en laissant tout sur un serveur). De toute facon, dans la plupart des cas, ce n'est pas le programme lui-meme qui a de la valeur mais les données qu'il utilise. Et c'est elles qu'il faut proteger.

Donc, si je vous comprends bien, pour protéger un logiciel, il faut partitionner l'executable sur plusieurs serveurs indépendants et protéger sa base de données par un firewall fiable.

Merci.

Avec mes salutations les meilleures,

Corine

[Laurent 1973]

La question a se posé: Est ce que la protection des sources de ton logiciel impact ton modèle économique?

En gros, que vends tu? (Un logiciel en ligne, un service, de la formation, des licences, ...)
et pour quel public? (entreprise, particulier, occasionnel, régulier, ...)

De là, tu devrais te poser la question de l'impacte de ton business si un utilisateur 'découvre' ton code.
Quel est serait le rapport coût/risque que tu es prêt a accepter?
A toi de prendre la meilleur solution alors: rentre ton logiciel open-source, le laisser en java, utiliser un offuscateur, le faire en c++, en faire une web application ...

[hwoarang]

Donc, si je vous comprends bien, pour protéger un logiciel, il faut partitionner l'executable sur plusieurs serveurs indépendants et protéger sa base de données par un firewall fiable.

La, tu parles de protection physique des données. Oui, il faut que ce soit aussi securisé que possible pour eviter qu'un hacker puisse acceder directement au serveur et pomper la base de données.

Mais dans nos messages, nous parlions plutot de la partie exploitation des données. Il ne faut pas oublier qu'au final, ton programme devra bien recuperer les données et les afficher au client.
La plupart des programmes demandent un login/password et donnent acces aux fonctionnalitées liées au droits de la personne qui s'authentifie. La methode intuitive est d'envoyer ce login/password au serveur, recuperer les droits et activer l'IHM d'apres ce qu'on a lu. Ce qui est assez facile a contourner s'il suffit de sniffer les données recues du serveur et de modifier l'executable pour qu'il ait l'impression que la personne loggée est toujours un administrateur (qui aura donc acces a toutes les fonctionnalitées).
De toute facon, pour bien faire, il faut toujours partir du principe qu'une donnée entrée par le client peut etre mauvaise. Par exemple, si on crée un formulaire avec un champ "age" formaté de type "numérique", il ne faut pas partir du principe que le champ sera toujours numérique. Il est facile de le changer pour pouvoir mettre un texte à l'interieur. Il faut donc toujours verifier coté serveur la validité des données avant de les utiliser dans la base de données.

[Corine 2015]

Bonjour,

Comment développer un logiciel en Java dont l'interface de connexion ( qui demande un identifiant et un mot de passe ) ne peut être ni séparée du logiciel, ni piratée ?

Merci

Corine

[eulbobo]

Comment développer un logiciel en Java dont l'interface de connexion ( qui demande un identifiant et un mot de passe ) ne peut être ni séparée du logiciel, ni piratée ?

En faisant en sorte que l'utilisateur n'ait qu'une interface communiquant avec une application distante.

Une application WEB par exemple, dans laquelle toute la logique fonctionnelle est installée sur un serveur (donc exécutable non accessible donc non décompilable), et pour laquelle l'utilisateur ne dispose que d'une page HTML pour échanger avec l'application.