Was sind die Vorteile der Verschleierung von Release-Code?

Das konkrete Beispiel, an das ich denke, betrifft das aktuelle Alpha-Spiel Minecraft, aber dies ist eine allgemeine Frage, die meiner Meinung nach eine Unterhaltung rechtfertigt.

Minecraft ist in Java geschrieben und Stack-Traces sehen normalerweise so aus (reales Beispiel):

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)

Offensichtlich sind dies nicht die echten Paket- und Methodennamen, die der Entwickler beim Schreiben verwendet. Da er sich in einer Alpha-Phase befindet, scheint es, dass der Entwickler in der Lage sein möchte, seine Stack-Traces zu verstehen, insbesondere wenn jemand in der Lage ist, einen Bug-Report zu erstellen. So wie es aussieht, ist es meistens bedeutungslos.

Welchen Vorteil könnte man möglicherweise erhoffen, wenn man seinen Code so verschleiert, dass die Nachteile einer schwierigeren Fehleridentifikation überwunden werden?

obfuscation

— StrixVaria
quelle

Vereinfacht gesagt, ändert die Verschleierung die Wirtschaftlichkeit der Rückentwicklung Ihres Codes, nicht mehr.

— Mark Booth

Antworten:

Wir verschleiern auch unseren Java-Code ....

Der Vorteil ist, dass das Reverse Engineering schwieriger wird (wenn Sie befürchten, dass jemand Ihre Codebasis stiehlt und sie beispielsweise als Basis für die Erstellung eines ähnlichen Konkurrenzprodukts usw. verwendet).

Sie können die ursprüngliche Stapelablaufverfolgung zurückerhalten: Es gibt Verschleierungstools, die spezielle Referenzdateien erstellen, mit denen Sie die verschleierten Stapelablaufverfolgungen durchlaufen können, und sie werden mit der ursprünglichen Stapelablaufverfolgung für den Quellstapel ausgegeben. Diese werden durch den Verschleierungsprozess selbst generiert, sodass Sie die ursprüngliche Stapelverfolgung nur dann wiederherstellen können, wenn Sie die Referenzdatei zur Hand haben, mit der Sie den Code ursprünglich verschleiert haben.

Das hat eigentlich keine Nachteile. :)

— Bobby Tische
quelle

Interessant, ich wusste nie, dass sie mit "Stack Trace Un-Obfuscation" kamen (nachdem sie noch nie einen Obfuscator verwendet hatten) ... was für eine nette Idee :-)

— Dean Harding

Der einzige Nachteil, auf den ich jemals gestoßen bin, ist, dass gelegentlich ein Obfuscator (in diesem Fall ein .NET) ihn so weit verschleiert hat, dass der Jitter ihn nicht einmal lesen konnte (illegale Anweisungen). Massiver Misserfolg.

— Vcsjones

@vcsjones: Das ist dann nicht wirklich Verschleierung ...

— Konfigurator

Schutz Ihres geistigen Eigentums

Die meisten Verschleierer optimieren auch Ihren Code , entfernen unbrauchbare Metadaten oder nicht verwendeten Code, komprimieren, beseitigen toten Code oder beseitigen doppelte Codes.

Wenn man für solche Optimierungen einen Obfuscator verwenden muss, muss der verwendete Compiler eine wirklich faule Software sein.

— Phresnel

@phresnel: Ja, obfuscator kann einen ziemlich guten Job machen

@ phresnel: unvollständig, wahrscheinlich, aber beschissen ...

Du hast recht. Lass mich umbuchen.

— Phresnel

Es ist nicht so, dass ich dir nicht glaube; Ich mache! Aber all diese Optimierungen werden in der Regel auch von modernen Compilern durchgeführt. Zumindest weiß ich, dass gcc sie alle hat. Meine Meinung ist also: Wenn ein Obfuscator Sie wirklich erheblich beschleunigt, hat sich entweder der Compiler [Hersteller] nicht genug Mühe gegeben, oder es wurden keine geeigneten Optimierungsflags vergeben.

— Phresnel