Création de programmes Java non ingénierie inverse

Question

Existe-t-il un moyen de déployer un programme Java dans un format non compatible avec le reverse engineering?

Je sais comment convertir mon application en un fichier JAR exécutable, mais je veux m'assurer que le code ne peut pas être désossé, ou du moins, pas facilement.

Les obscurcissements du code source ne comptent pas ... cela rend plus difficile la compréhension du code, mais ne le cache pas.

Une question connexe est Comment verrouiller la compilation Des classes Java pour empêcher la décompilation?

Une fois le programme terminé, j'aurais toujours accès à la source originale. Par conséquent, le problème ne serait pas de maintenir l'application. Si l'application est distribuée, je ne souhaite pas que les utilisateurs puissent la décompiler. L'obfuscation n'atteint pas cet objectif, car les utilisateurs seraient toujours en mesure de le décompiler. S'ils auraient du mal à suivre l'action, ils pourraient voir le code et éventuellement en extraire des informations.

Ce qui me préoccupe, c’est qu’il existe dans le code des informations relatives à l’accès à distance. Il existe un hôte auquel l'application se connecte à l'aide d'un ID utilisateur et d'un mot de passe fournis par l'utilisateur. Existe-t-il un moyen de masquer l'adresse de l'hôte à l'utilisateur si cette adresse se trouve dans le code source?

Answer 1

Vous pouvez masquer votre fichier JAR avec YGuard . Cela n'obscurcit pas votre code source , mais les classes compilées, il n'y a donc aucun problème à ce que le code soit conservé ultérieurement.

Si vous souhaitez masquer une chaîne, vous pouvez la chiffrer, ce qui rend plus difficile sa lecture en examinant le code source (il est même préférable de masquer le fichier JAR).

Answer 2

La réponse courte est "Non, cela n'existe pas".

La rétroingénierie est un processus qui n'implique pas du tout le code . Il s'agit essentiellement d'essayer de comprendre les mécanismes sous-jacents, puis de les imiter. Par exemple, c'est ainsi que JScript apparaît dans les laboratoires Microsoft en copiant le comportement JavaScript de Netscape sans avoir accès au code. La copie était si parfaite que même les insectes ont été copiés.

Answer 3

Si vous connaissez les plates-formes que vous ciblez, obtenez quelque chose qui compile votre Java en code natif, tel que Excelsior JET ou GCJ .

En dehors de cela, vous ne pourrez jamais cacher le code source, car l'utilisateur a toujours votre bytecode et peut Jad , il.

Answer 4

Vous écrivez dans une langue dont l'introspection fait partie intégrante. Il génère des fichiers .class dont les spécifications sont largement connues (permettant ainsi à d'autres fournisseurs de produire des implémentations en salle blanche de compilateurs et d'interprètes Java).

Cela signifie qu'il existe des décompilateurs disponibles au public. Quelques recherches sur Google suffisent, et vous avez du code Java qui fait la même chose que le vôtre. Juste sans les commentaires et certains noms de variables (mais les noms de fonctions restent les mêmes).

Vraiment, l’obscurcissement est à peu près tout ce que vous pouvez obtenir (même si le code décompilé sera déjà légèrement obscurci) sans passer à C ou à un autre langage entièrement compilé, de toute façon.

Answer 5

N'utilisez pas un langage interprété? Qu'essayez-vous de protéger de toute façon? Si sa valeur est suffisante, tout peut être inversé. Les chances que quelqu'un se soucie suffisamment de la rétro-ingénierie pour la plupart des projets sont minimes. L’obscurcissement offre au moins un obstacle minimal.

Assurez-vous que votre propriété intellectuelle est protégée par d'autres mécanismes. Pour le code de sécurité en particulier, il est important que les utilisateurs puissent inspecter les implémentations, de sorte que la sécurité soit dans l'algorithme et non dans la source.

Answer 6

Je serais tenté de vous demander pourquoi vous voudriez faire cela, mais je vais laisser ça tranquille ...

Le problème que je vois est que la JVM, à l'instar du CLR, doit pouvoir vous insérer dans le code afin de le compiler et de l'exécuter. Vous pouvez le rendre plus "complexe". mais étant donné que la spécification pour le bytecode est plutôt bien documentée et qu'elle existe à un niveau beaucoup plus élevé que quelque chose comme la spécification d'assembleur x86, il est peu probable que vous puissiez "masquer" le flux de processus, car il doit être là pour que le programme fonctionne en premier lieu.

Answer 7

Cela ne peut pas être fait.

Tout ce qui peut être compilé peut être décompilé. Le mieux que vous puissiez faire est d’en dissimuler l’enfer.

Cela étant dit, il se passe des choses intéressantes dans la cryptographie quantique. Essentiellement, toute tentative de lecture du message le modifie. Je ne sais pas si cela pourrait être appliqué au code source ou non.

Answer 8

Même si vous compilez le code en langage machine natif, de nombreux programmes vous permettent essentiellement de le décompiler en langage assembleur et de suivre le flux de processus (OlyDbg, IDA Pro).

Answer 9

Faites-en un service Web. Ensuite, vous êtes le seul à pouvoir voir le code source.

Answer 10

Cela ne peut pas être fait. Ce n'est pas un problème de Java. Toute langue pouvant être compilée peut être décompilée pour Java, c'est simplement plus facile.

Vous essayez de montrer à quelqu'un une image sans lui montrer réellement. Ce n'est pas possible. Vous ne pouvez pas non plus cacher votre hôte même si vous vous cachez au niveau de l'application. Quelqu'un peut toujours le saisir via Wireshark ou tout autre renifleur de réseau.

Answer 11

Comme l’a dit quelqu'un ci-dessus, l’ingénierie inverse peut toujours décompiler votre fichier exécutable. Le seul moyen de protéger votre code source (ou algorithme) est de ne pas distribuer votre exécutable.

séparez votre application en un code serveur et une application client, masquez la partie importante de votre algorithme dans votre code serveur et exécutez-la sur un serveur cloud, distribuez simplement le code client qui fonctionne uniquement en tant que récupérateur et expéditeur de données.

De ce fait, même votre code client est décompilé. Vous ne perdez rien.

Mais à coup sûr, cela réduira les performances et la commodité de l'utilisateur.

Je pense que ce n'est peut-être pas la réponse que vous recherchez, mais simplement pour donner une autre idée de la protection du code source.

Answer 12

Si quelque chose est interprété à un moment donné, il doit être traité "en clair". La chaîne apparaîtrait clairement en tant que jour une fois que le code sera exécuté via JAD. Vous pouvez déployer une clé de chiffrement avec votre application ou un chiffrement ceasar de base pour chiffrer les informations de connexion de l'hôte et les déchiffrer au moment de l'exécution ...

Toutefois, lors du traitement, les informations de connexion à l'hôte doivent être mises en clair pour que votre application se connecte à l'hôte ...

Vous pouvez donc le masquer de manière statique, mais vous ne pouvez pas le masquer lors de l'exécution s'ils exécutent un débogueur

Answer 13

C'est impossible. La CPU devra exécuter votre programme, c’est-à-dire que votre programme doit être dans un format qu’une CPU peut comprendre. Les processeurs sont beaucoup plus bêtes que les humains. Ainsi, si un processeur peut comprendre votre programme, un humain peut le faire.

Answer 14

Pour éviter de dissimuler le code, j'exécuterais quand même ProGuard .