it-swarm.com.de

Der Fall für die Verschleierung von Code?

Was sind die Hauptgründe für das Schreiben von verschleiertem Code im Hinblick auf einen echten Vorteil 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 (online an einem bestimmten Ort verfügbar), die beschreiben, wann die Verschleierung mehr gut als schlecht war? Gibt es bekannte Beispiele, bei denen beispielsweise nachgewiesen wurde, dass die Verschleierung einen böswilligen Dritten erheblich davon abhält, an die Website zu gelangen? Code? Es scheint, dass, genau wie das Aufrollen Ihrer Autofenster die Leute nicht davon abhält, sie zu zerbrechen und Ihre Stereoanlage zu stehlen, die Verschleierung Ihres Codes nur ehrliche Leute ehrlich hält.

=========

Hintergrund:

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

Ich bin sehr dagegen, Code-Verschleierung im Allgemeinen zu verwenden, aber ich bin neugierig, ob mir etwas fehlt. Ich verstehe, warum in Fällen wie JavaScript die Minimierung dazu beiträgt, dass die Dinge schneller geladen werden (es gibt dort einen echten funktionalen Vorteil), aber ich kann anscheinend keinen einzigen Grund finden, warum Code verschleiert wird, zu diesem Zweck) ein Hindernis zu sein, um herauszufinden, was ein Abschnitt des Codes/Algorithmus tut, ist tatsächlich für jeden Zweck wirksam.

Da Open Source verrückt beliebt ist, scheint die Frage zu lauten: "Teilen Sie den Code oder behalten Sie ihn proprietär?" Wenn es um Handelscode geht, kann ich verstehen, warum Sie nicht alles teilen können und Sie haben das Gesetz an Ihrer Seite, um Diebstahl zu bekämpfen.

Übrigens, wenn der Grund, warum jemand verschleierten Code schreibt, "Arbeitsplatzsicherheit" ist, würde ich jeden Programmierer feuern, der konsequent und absichtlich verschleiert ist mit dem alleinigen Zweck, seine Jobs zu behalten es sei denn, er konnte vernünftigerweise zeigen, dass es einen geschäftlichen Nutzen hatte. Es ist so völlig gegen das Team, dass es lächerlich ist und auf jemanden hinweist, der mehr daran interessiert ist, seinen Job durch fehlgeleitete Praktiken zu behalten, als ihn zu behalten, weil er großartige Software schreibt.

Ich erwähne diesen speziellen Fall nur, 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.

47
jefflunt

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

Das ist eine Form von Steganographie , inspiriert und in Variation der kryptografischen Schemata "Traitor Tracing" . Ich habe keine Ahnung, ob es üblich ist1, oder auch wenn es eine gute Idee ist, aber ich habe gesehen, dass sie in der Praxis unter den folgenden Parametern angewendet wird:

  • Wettbewerbsintensiver bundesweiter Markt mit nur zwei Anbietern,
  • Über 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 beider Anwendungen wurde auf etwa zehn Jahre geschätzt.

Das Grundprinzip war natürlich anfangs Sicherheit durch Dunkelheit , und es entwickelte sich irgendwann zu dem oben genannten Schema2. Beide Anbieter hatten legal Zugriff auf den Binärcode des jeweils anderen, 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 Nischenmarkt arbeiteten. Letztendlich waren unsere Produkte mehr als ähnlich, und jeder Wettbewerbsvorteil wurde durch andere, weniger obskure 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 Verfolgungsschemas (falls vorhanden) und (b) einen Teil meiner Beteiligung bekam mit dem Projekt war unter einer NDA.

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

Wenn Ihre Firma IP-Arbeit für Technologieunternehmen leistet oder in Fälle mit Software-Quellcode verwickelt ist, müssen Sie möglicherweise den Quellcode Ihres Kunden dem USPTO, einem Gericht oder einem Dritten vorlegen.

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

IANAL, und der Link ist für gedruckte Code-Kopien relevanter als für tatsächlichen Arbeitscode, sodass dies möglicherweise völlig irrelevant ist.

Da Javascript das kanonische Beispiel für die Verschleierung ist, gibt es einen Nebeneffekt, der nicht allgemein berücksichtigt wird und der bösartigen Code in verschleiertem Javascript verbirgt. Obwohl es definitiv Vorteile beim Minimieren gibt3 Javascript, ich sehe keinen Sinn in der tatsächlichen Verschleierung und bin glücklich Douglas Crockford stimmt mir zu :

Dann gibt es endlich diese Frage des Datenschutzes. Dies ist eine verlorene Sache. Es gibt keine Transformation, die einen entschlossenen Hacker davon abhält, Ihr Programm zu verstehen. Dies gilt für alle Programme in allen Sprachen. Dies gilt nur für JavaScript, da es in Quellform geliefert wird. Der durch die Verschleierung gewährte Datenschutzvorteil ist eine Illusion. Wenn Sie nicht möchten, dass andere Benutzer Ihre Programme sehen, trennen Sie den Server vom Computer.

Die Verschleierung der "Arbeitsplatzsicherheit" ist ein Verhalten, das niemals die Codeüberprüfung bestehen sollte, und wenn es identifiziert wird, sollte es nicht toleriert werden. Ich würde zunächst nicht so weit gehen, den Täter zu feuern, aber Wiederholungstäter verdienen zumindest eine gute Tracht Prügel.

Zusammenfassend ist die Verschleierung ein typisches Beispiel für Sicherheit durch Dunkelheit. Es ist nur ein offensichtlicher Verdienst, abschreckend zu wirken, und nicht mehr. Möglicherweise gibt es kreative Anwendungsfälle4 Ich weiß es nicht, aber im Allgemeinen sind die Vorteile bestenfalls minimal.

1 Nachdem ich dies geschrieben hatte, fand ich heraus, diese Antwort , die im Grunde das gleiche Schema beschreibt, so dass es häufiger sein könnte, als ich dachte.
2 Obwohl Steganographie immer noch Sicherheit durch Dunkelheit ist.
3 Minimierung ~ Entfernen von Leerzeichen und Kürzen von Token, nicht absichtlich verdeckt.
4 Zählt der International Obfuscated C Code Contest ?

49
yannis

Der Fall für die Verschleierung von Code besteht darin, dass die Messlatte für Dritte höher gelegt wird, um festzustellen, was/wie der Code funktioniert.

Dies bedeutet jedoch [~ # ~] nicht [~ # ~] , dass ein Entwickler jemals verschleierten Code schreiben sollte.

Sehen Sie, dies ist das, was meiner Meinung nach in Ihrer Frage fehlt: Die Verschleierung von Code (genau wie die JavaScript-Minimierung) muss und sollte vom Entwickler nicht manuell durchgeführt werden. Ebenso sollte dies auch nicht als Ihre Kernquelldateien in der Versionskontrolle gespeichert werden.

Die Verschleierung des Codes sollte als Nachbearbeitungsschritt während der Kompilierung in Ihren Produktionsbuild erfolgen. Es gibt auch viele Produkte von Drittanbietern, daher gibt es fast keinen Grund, dies intern zu tun.

Zum Beispiel: Dotfuscator

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

Die Ergebnisse zeigen, dass das Umbenennen von Identifikatoren die Effizienz von Angriffen erheblich verringert () und mindestens die Zeit verdoppelt , um einen erfolgreichen Angriff abzuschließen (selbst im schlimmsten Fall, d. H. 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, denen ähnlicher, die an sich schwerer zu erreichen sind brechen.

Hervorhebung von mir.

40
Dan McGrath

Ich habe an der Entwicklung eines MMORPG teilgenommen. Dies umfasste Serverlogik und Clientlogik. Während der langjährigen Entwicklung des Projekts war die Regel, wann immer wir die Schnittstelle zwischen dem Client und dem Server betrachteten, dass der Client vom Server jederzeit unter der Annahme behandelt werden sollte, dass er gehackt wurde. Mit anderen Worten, der Server musste so geschrieben werden, dass keine Antwort vom Client kam, 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öcher im System finden und diese ausnutzen würden, um zu betrügen. Und nach einer Weile taten sie es.

Bevor wir den Kunden in die große Welt da draußen schickten, haben wir natürlich 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 beim Erreichen von Hacks.
  3. Es reduzierte die Anzahl der von erfahrenen Hackern erzielten Hacks.
  4. Es begrenzte die Wirksamkeit der Hacks.
  5. Am wichtigsten: Es führte dazu, dass die Hacker mehr Testläufe mit ihren gehackten Clients gegen unsere Server durchführten, bevor sie einen funktionierenden Hack erreichten. 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 teurer 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 gehackt werden kann. (Zum Beispiel Software mit Kopierschutzmaßnahmen.)

Die Auswirkungen der Verschleierung auf die Wartung waren nahezu unbegrenzt. Es gab einige Stellen, an denen einige unerfahrene Programmierer Annahmen über die Namen von Bezeichnern machten (sie verwendeten Reflexion), aber sobald diese aussortiert waren, war alles in Ordnung. Der Verschleierungsschritt wurde einfach Teil des gesamten Erstellungsschritts 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 so geändert, dass die vom Verschleierer erstellte Zuordnungstabelle (Zuordnung von verschleierten Bezeichnern zu richtigen Bezeichnern) verwendet wird, um die Protokolle für uns im laufenden Betrieb zu übersetzen Bei Post-Mortem-Untersuchungen auf der Grundlage von Protokollen, die auf dem Feld gesammelt wurden, mussten sogar verschleierte Kennungen angezeigt werden.

35
Mike Nakis

Das Lesen und Verstehen (und offensichtlich das Schreiben) von verschleiertem Code kann eine interessante mentale Herausforderung sein. Es fällt wahrscheinlich nicht in den Bereich Ihrer Fragen, aber Beispiele wie IOCCC können sowohl eine Quelle der Belustigung als auch des Grauens sein.

3
Vatine