Quels sont les avantages de masquer le code de version?

L'exemple spécifique que j'ai en tête concerne le jeu actuellement alpha, Minecraft, mais c'est une question générale qui, je pense, mérite une conversation.

Minecraft est écrit en Java, et les traces de pile ressemblent généralement à ceci (exemple réel):

java.lang.NullPointerException
    at d.a(SourceFile:247)
    at gi.b(SourceFile:92)
    at bd.a(SourceFile:33)
    at bn.a(SourceFile:69)
    at bn.e(SourceFile:115)
    at bn.d(SourceFile:103)
    at net.minecraft.client.Minecraft.i(SourceFile:1007)
    at net.minecraft.client.Minecraft.run(SourceFile:596)
    at java.lang.Thread.run(Unknown Source)

Évidemment, ce ne sont pas les vrais noms de package et de méthode que le développeur utilise lorsqu'il écrit. Puisqu'il est en phase alpha, il semble que le développeur souhaite pouvoir comprendre les traces de sa pile, surtout si quelqu'un est en mesure d'en fournir une pour un rapport de bogue. Dans l'état actuel des choses, cela n'a pratiquement aucun sens.

Quel avantage pourrait-on espérer gagner en obscurcissant son code comme celui-ci qui surmonte les inconvénients d'une identification de bogue plus difficile?

obfuscation

— StrixVaria
source

Autrement dit, l'obscurcissement modifie l'économie de la rétro-ingénierie de votre code, rien de plus.

— Mark Booth

Réponses:

Nous obscurcissons également notre code Java ....

L'avantage est qu'il est plus difficile de procéder à une rétro-ingénierie (si vous craignez que quelqu'un vole votre base de code et l'utilise comme base pour créer un produit concurrent similaire, par exemple, etc.).

Vous pouvez récupérer la trace de pile d'origine: il existe des outils d'obscurcissement qui créent des fichiers de référence spéciaux que vous pouvez utiliser pour exécuter les traces de pile obscurcies, et il sort avec la trace de pile source d'origine. Ceux-ci sont générés par le processus d'obscurcissement lui-même, vous ne pouvez donc pas récupérer la trace de pile d'origine à moins que vous n'ayez les mains sur le fichier de référence que vous avez utilisé pour obscurcir le code en premier lieu.

Cela n'a vraiment aucun inconvénient. :)

— Tables Bobby
source

Intéressant, je ne savais pas qu'ils étaient venus avec un "désobscurcissement de trace de pile" (n'ayant jamais utilisé d'obscurcisseur) ... quelle bonne idée :-)

— Dean Harding

Le seul inconvénient que j'ai jamais rencontré est parfois un obfuscateur (un .NET dans ce cas) l'obscurcissant au point où la gigue ne pouvait même pas le lire (instructions illégales). Échec massif.

— vcsjones

@vcsjones: Ce n'est pas vraiment de l'obscurcissement alors ...

— configurateur

vous protéger la propriété intellectuelle

La plupart des obscurcisseurs optimisent également votre code , suppriment les métadonnées inutiles ou le code non utilisé, la compression, l'élimination du code mort ou l'élimination des doublons.

Si l'on doit utiliser un obfuscateur pour de telles optimisations, le compilateur utilisé doit être un logiciel vraiment paresseux.

— phresnel

@phresnel: Oui l'obfuscateur peut faire du très bon travail

@phresnel: incomplet, probablement, mais merdique ...

Tu as raison. Permettez-moi de republier.

— phresnel

Ce n'est pas que je ne te crois pas; Je fais! Mais toutes ces optimisations sont généralement également exercées par des compilateurs modernes. Au moins, je sais que gcc les a tous. Donc, mon opinion est la suivante: si un obfuscateur vous donne vraiment une accélération significative, alors soit le compilateur [fournisseur] n'a pas essayé assez fort, soit il n'a pas reçu d'indicateurs d'optimisation appropriés.

— phresnel