Der Fall der Code-Verschleierung?

Was sind die Hauptgründe für das Schreiben von verschleiertem Code im Hinblick auf einen echten Nutzen für die Entwickler des Codes und das Unternehmen, das diesen Code ausführt (wenn es sich bei dem fraglichen Code tatsächlich um kommerziellen Code handelt)? Gibt es dokumentierte Fälle (an einigen Orten online verfügbar), die beschreiben, wann die Verschleierung mehr gut als schlecht war? Gibt es bekannte Beispiele, bei denen nachgewiesen wurde, dass eine Verschleierung einen böswilligen Dritten davon abhält, an den Code zu gelangen? Es scheint so, als würde das Aufrollen Ihrer Autofenster nicht verhindern, dass die Leute sie zerbrechen und Ihre Stereoanlage stehlen. Wenn Sie Ihren Code verschleiern, bleiben ehrliche Leute ehrlich.

=========

Hintergrund:

Dies ist ein Versuch, meine Annahmen zu diesem Thema absichtlich in Frage zu stellen.

Ich bin ein großer Gegner der Verwendung von Code-Verschleierung im Allgemeinen, aber ich bin neugierig, ob mir etwas fehlt. Ich verstehe, warum in Fällen wie JavaScript die Minimierung das Laden der Dinge beschleunigt (da gibt es einen echten funktionalen Vorteil), aber ich kann anscheinend keinen einzigen Grund für die Codeverschleierung nennen, um ein Hindernis zu sein zu entdecken, was ein Abschnitt von Code / Algorithmus tut , ist für jeden Zweck effektiv.

Angesichts der verrückten Beliebtheit von Open Source scheint die Frage zu sein, ob der Code freigegeben oder geschützt werden soll. Wenn es um kommerziellen Code geht, kann ich verstehen, warum Sie nicht alles teilen können und Sie das Gesetz haben, um Diebstahl zu bekämpfen.

Übrigens, wenn der Grund, warum jemand verschleierten Code schreibt, "Job-Sicherheit" ist, würde ich jeden Programmierer entlassen, von dem festgestellt wurde, dass er konsequent ist, und die Verschleierung absichtlich einsetzen, um zu helfen, ihre Jobs zu behalten, es sei denn, er könnte vernünftigerweise nachweisen, dass er welche hat Geschäftsvorteil. Es ist so komplett gegen Teams, dass es lächerlich ist, und weist auf jemanden hin, der sich mehr darum kümmert, seinen Job durch fehlgeleitete Praktiken zu erhalten und ihn dann beizubehalten, weil er großartige Software schreibt.

Ich erwähne nur diesen speziellen Fall, weil ich, obwohl mir klar ist, dass die Leute normalerweise Witze machen, alle Antworten abschrecken möchte, deren Grundgedanke darin besteht, dass die Verschleierung der Arbeitsplatzsicherheit allein eine gute Idee ist.

Ein sehr interessanter Anwendungsfall für die Verschleierung ist die Verfolgung der Herkunft illegaler Kopien. Unter der Annahme, dass die Verschleierung eine relativ kostengünstige Operation ist, kann der ursprüngliche Autor jedem Kunden unterschiedlich verschleierte Versionen der Anwendung zur Verfügung stellen. Wenn eine illegale Kopie gefunden wird, kann der Autor diese mit den gelieferten Versionen vergleichen und die Quelle der Piraterie zurückverfolgen.

Das ist eine Form der Steganographie , inspiriert und in Variation der kryptografischen Schemata der "Verräter-Verfolgung" . Ich habe keine Ahnung, ob es häufig ¹ ist oder ob es eine gute Idee ist, aber ich habe gesehen, dass es in der Praxis unter den folgenden Parametern angewendet wird:

• Stark umkämpfter bundesweiter Markt mit nur zwei Anbietern,
• Etwa 50 Bereitstellungen deckten den Markt ab,
• Die durchschnittliche Entwicklungszeit für beide Anwendungen betrug einige Jahre (mehr oder weniger).
• Die durchschnittliche Verschleierungszeit für unsere Anwendung betrug einige Stunden.
• Die Lebensdauer für beide Anwendungen wurde auf etwa zehn Jahre veranschlagt.

Das Grundprinzip war natürlich anfangs Sicherheit durch Unbekanntheit , und es entwickelte sich irgendwann bei dem oben erwähnten Schema ² . Beide Anbieter hatten legal gegenseitigen Zugriff auf den Binärcode, und ich denke, es ist offensichtlich, dass Dekompilierungsversuche von beiden erwartet wurden. Die Verschleierung hat auf lange Sicht nichts zur Sicherheit beigetragen. Beide Anbieter hatten hochmotivierte und talentierte Teams, die in einem äußerst profitablen und Nischenmarkt arbeiteten. Am Ende waren unsere Produkte mehr als ähnlich, und jeder Wettbewerbsvorteil wurde durch andere, weniger undurchsichtige Mittel erzielt.

Ich kann nicht wirklich expandieren, weil (a) es sehr früh in meiner Karriere war und ich keinen klaren Überblick über die Entwurfsentscheidungen oder die Ergebnisse des Rückverfolgungsschemas (falls vorhanden) und (b) einen Teil meines Engagements bekam Mit dem Projekt wurde im Rahmen einer NDA.

Ein anderer gültiger Anwendungsfall für die Verschleierung könnte sein, wenn Sie gesetzlich dazu verpflichtet sind, Ihren Code an Dritte weiterzuleiten :

Wenn Ihre Firma IP für Technologieunternehmen ausführt oder in Fällen mit Software-Quellcode involviert ist, müssen Sie möglicherweise den Quellcode Ihres Kunden beim USPTO, einem Gericht oder Dritten einreichen.

Da der Quellcode als Geschäftsgeheimnis betrachtet wird, verwenden die meisten Aufsichtsbehörden eine "50%" -Regel. Der übermittelte Quellcode ist verdeckt, so dass er nicht unverändert verwendet werden kann.

IANAL, und der Link ist relevanter für Hardcodekopien als für den eigentlichen Arbeitscode, sodass dies möglicherweise völlig irrelevant ist.

Nun, da Javascript das kanonische Beispiel für die Verschleierung ist, gibt es einen Nebeneffekt, der nicht allgemein berücksichtigt wird und der schädlichen Code in verschleiertem Javascript verbirgt. Obwohl die Minimierung von ³ Javascript einige Vorteile mit sich bringt , sehe ich keinen Grund für eine tatsächliche Verschleierung, und ich bin froh, dass Douglas Crockford mir zustimmt :

Dann ist da noch die Frage des Code-Datenschutzes. Dies ist eine verlorene Sache. Es gibt keine Transformation, die einen entschlossenen Hacker davon abhält, Ihr Programm zu verstehen. Dies trifft auf alle Programme in allen Sprachen zu. Bei JavaScript ist dies nur offensichtlicher, da es in Quellform geliefert wird. Der Datenschutzvorteil durch Verschleierung ist eine Illusion. Wenn Sie nicht möchten, dass andere Ihre Programme sehen, trennen Sie den Server vom Computer.

Was die Verschleierung für "Arbeitsplatzsicherheit" angeht, so sollte dieses Verhalten die Codeüberprüfung niemals bestehen, und wenn es identifiziert wird, sollte es nicht toleriert werden. Anfangs würde ich nicht so weit gehen, den Täter zu feuern, aber Wiederholungstäter verdienen auf jeden Fall eine gute Tracht Prügel.

Zusammenfassend lässt sich sagen, dass die Verschleierung ein typisches Beispiel für Sicherheit durch Verschleierung ist. Es liegt nur auf der Hand, dass sie abschreckend wirkt und nicht mehr. Es mag kreative Anwendungsfälle geben ^{4, von denen} ich nichts weiß, aber im Allgemeinen sind die Vorteile bestenfalls minimal.

_{¹ Nachdem ich dies geschrieben hatte, fand ich diese Antwort heraus, die im Grunde das gleiche Schema beschreibt, so dass es vielleicht üblicher ist, als ich dachte.
² Obwohl Steganographie immer noch Sicherheit durch Dunkelheit ist.
³ Minimierung ~ Leerzeichen entfernen und Token kürzen, nicht absichtlich verdecken.
⁴ Zählt der International Obfuscated C Code Contest ?}

Der Fall der Code-Verschleierung ist, dass ein Dritter die Messlatte höher legt, um zu bestimmen, was / wie der Code funktioniert.

Dies bedeutet jedoch NICHT , dass ein Entwickler jemals verschleierten Code schreiben sollte.

Sehen Sie, dies ist das, was Ihrer Frage meines Erachtens fehlt: Die Verschleierung von Code (genau wie die JavaScript-Minimierung) muss und sollte nicht manuell vom Entwickler vorgenommen werden. Ebenso sollte dies auch nicht als Kernquelldatei in der Versionskontrolle gespeichert werden.

Die Verschleierung von Code sollte als Nachbearbeitungsschritt während der Kompilierung in Ihrem Produktionsbuild erfolgen. Es gibt auch viele Produkte von Drittanbietern, daher gibt es fast keinen Grund, dies im eigenen Haus zu tun.

Zum Beispiel: Dotfuscator

Die IEEE hat ein Papier über die Wirksamkeit der Code-Verschleierung

Die Ergebnisse zeigen, dass das Umbenennen von IDs die Effizienz von Angriffen erheblich verringert und zumindest die für einen erfolgreichen Angriff erforderliche Zeit verdoppelt (selbst im schlimmsten Fall, dh gegen den besten Angreifer). Darüber hinaus verringert die Verschleierung die Lücke zwischen unerfahrenen und erfahrenen Angreifern, wodurch letztere weniger effizient sind , und macht Systeme, die leichter anzugreifen sind, klarer denen, die an sich schwerer zu brechen sind.

Betonung meiner.

Ich habe an der Entwicklung eines MMORPG teilgenommen. Dies umfasste Serverlogik und Clientlogik. Während der langjährigen Entwicklung des Projekts galt, wann immer wir die Schnittstelle zwischen Client und Server betrachteten, die Regel, dass der Client jederzeit vom Server unter der Annahme behandelt werden sollte, dass er gehackt wurde. Mit anderen Worten, der Server musste so geschrieben sein, dass es keine Antwort vom Client gab, die zum Ausfall des Servers oder zum Betrügen des Clients führen würde. Dennoch war von Anfang an bekannt, dass Hacker unweigerlich Lücken im System finden und ausnutzen würden, um zu betrügen. Und nach einer Weile taten sie es.

Natürlich haben wir vor dem Versand des Kunden in die große Welt darauf geachtet, ihn zu verschleiern. Wir glauben, dass die Verschleierung die folgenden Auswirkungen hatte:

1. Es hielt die nicht-erfahrenen Hacker davon ab, es überhaupt zu versuchen.
2. Es verzögerte erfahrene Hacker, irgendwelche Hacks zu erreichen.
3. Es reduzierte die Anzahl der von erfahrenen Hackern erzielten Hacks.
4. Dies hat die Effektivität der Hacks eingeschränkt.
5. Das Wichtigste: Die Hacker führten mehr Testläufe mit ihren gehackten Clients auf unseren Servern durch, bevor ein funktionierender Hack durchgeführt wurde. Dies erhöhte die Wahrscheinlichkeit, dass wir sie entdeckten, indem wir nach unregelmäßigen Aktivitäten in den Serverprotokollen suchten.

Spielkonten von entdeckten Hackern wurden ohne Rückerstattung gekündigt, was das Hacking-Geschäft kostspieliger und weniger attraktiv machte.

Aus all diesen Gründen glaube ich, dass die Verschleierung einen insgesamt positiven Effekt in unserem Spiel hatte, und im weiteren Sinne kann die Verschleierung einen insgesamt positiven Effekt in jeder Software haben, die dazu neigt, gehackt zu werden. (Zum Beispiel Software mit Kopierschutzmaßnahmen.)

Die Auswirkungen der Verschleierung auf die Instandhaltung waren nahezu gleich. Es gab ein paar Stellen, an denen einige unerfahrene Programmierer Annahmen über die Namen der Bezeichner machten (sie verwendeten Reflektion), aber sobald diese aussortiert waren, war alles in Ordnung. Der Verschleierungsschritt wurde einfach Teil des gesamten Build-Schritts für die Produktionsversion des Spiels, sodass sich die meisten von uns Entwicklern nie darum kümmern mussten oder irgendetwas damit zu tun hatten. Wir hatten bereits ein Tool zum Anzeigen der Protokolle des Spiels, daher haben wir das Tool dahingehend geändert, dass die vom Obfuscator erstellte Zuordnungstabelle (Zuordnung von verschleierten Bezeichnern zu richtigen Bezeichnern) verwendet wird, um die Protokolle im laufenden Betrieb für uns zu übersetzen Sogar verschleierte Identifikatoren mussten bei Obduktionsuntersuchungen auf der Grundlage von Feldprotokollen festgestellt werden.

Das Lesen und Verstehen (und offensichtlich das Schreiben) von verschleiertem Code kann eine interessante mentale Herausforderung sein. Es fällt wahrscheinlich nicht in den Rahmen, den Sie fragten, aber Beispiele wie IOCCC können sowohl für Unterhaltung als auch für Entsetzen sorgen.