Ausführbare Datei vor Reverse Engineering schützen?

210

Ich habe darüber nachgedacht, wie ich meinen C / C ++ - Code vor Demontage und Reverse Engineering schützen kann. Normalerweise würde ich dieses Verhalten in meinem Code niemals selbst dulden. Das aktuelle Protokoll, an dem ich gearbeitet habe, darf jedoch niemals überprüft oder verständlich sein, um die Sicherheit verschiedener Personen zu gewährleisten.

Dies ist ein neues Thema für mich, und das Internet ist nicht wirklich nützlich, um Reverse Engineering zu verhindern , sondern zeigt unzählige Informationen zum Reverse Engineering

Einige der Dinge, an die ich bisher gedacht habe, sind:

  • Code-Injection (Aufruf von Dummy-Funktionen vor und nach tatsächlichen Funktionsaufrufen)
  • Code-Obfustication (beeinträchtigt die Demontage der Binärdatei)
  • Schreiben Sie meine eigenen Startroutinen (für Debugger schwieriger zu binden)

    void startup();  
    int _start()   
    {  
        startup( );  
        exit   (0)   
    }  
    void startup()  
    {  
        /* code here */  
    }
  • Laufzeitprüfung für Debugger (und Beenden erzwingen, wenn erkannt)

  • Funktionstrampoline

     void trampoline(void (*fnptr)(), bool ping = false)  
     {  
       if(ping)  
         fnptr();  
       else  
         trampoline(fnptr, true);  
     }
  • Sinnlose Zuweisungen und Freigaben (Stapeländerungen stark)

  • Sinnlose Dummy-Rufe und Trampoline (Tonnen von Sprüngen in der Demontageausgabe)
  • Tonnenweise Guss (für verschleierte Demontage)

Ich meine, dies sind einige der Dinge, an die ich gedacht habe, aber sie können alle von Code-Analysten im richtigen Zeitrahmen umgangen oder herausgefunden werden. Gibt es noch eine Alternative, die ich habe?

Graphitemaster
quelle
172
"Das aktuelle Protokoll, an dem ich gearbeitet habe, darf jedoch niemals überprüft oder verständlich sein, um die Sicherheit verschiedener Personen zu gewährleisten." -- viel Glück damit.
Amber
62
Sie können das Reverse Engineering Ihrer Anwendung erschweren. Sie können es nicht unmöglich machen, nicht solange der andere einen wesentlichen Teil Ihrer Teile in der Hand hat. Achten Sie darauf, die volle Sicherheit zu gewährleisten, insbesondere wenn Leben auf dem Spiel stehen - Sie können nicht liefern.
Michael Petrotta
127
Wenn Ihr Computer den Code verstehen kann, kann dies auch eine Person.
Leichtigkeitsrennen im Orbit
78
Machen Sie den Code Open Source, und niemand wird ihn zurückentwickeln.
Benutzer unbekannt
28
"Sicherheit durch Dunkelheit hat nie funktioniert."
Bot47

Antworten:

151

Was Amber gesagt hat, ist genau richtig. Sie können das Reverse Engineering erschweren, aber niemals verhindern. Sie sollten niemals "Sicherheit" vertrauen , die auf der Verhinderung von Reverse Engineering beruht .

Die besten Anti-Reverse-Engineering-Techniken, die ich gesehen habe, konzentrierten sich jedoch nicht darauf, den Code zu verschleiern, sondern die Tools zu beschädigen, mit denen die Leute normalerweise verstehen, wie Code funktioniert. Kreative Wege zu finden, um Disassembler, Debugger usw. zu brechen, ist wahrscheinlich sowohl effektiver als auch intellektuell befriedigender als nur Unmengen von schrecklichem Spaghetti-Code zu generieren. Dies blockiert einen entschlossenen Angreifer nicht, erhöht jedoch die Wahrscheinlichkeit, dass J Random Cracker abwandert und stattdessen an etwas Einfacherem arbeitet.

Stephen Canon
quelle
14
Ich verstehe das und habe ein paar Artikel über Skype-Sicherheit gelesen, die erklärt wurden, und ich habe über die gleichen Ideen nachgedacht, die Skype bereits versucht hat, um mein Protokoll nicht zu verhindern, sondern zu schützen. Etwas, das sich angesichts der offensichtlichen Umstände für Skype als würdig genug erwiesen hat.
Graphitemaster
8
Skype ist tatsächlich das erste Beispiel, das mir in den Sinn gekommen ist. Ich bin froh, dass Sie bereits versuchen, ihre Methoden zu emulieren.
Ricket
175

Sie können jedoch alle von Code-Analysisten im richtigen Zeitrahmen umgangen oder herausgefunden werden.

Wenn Sie den Benutzern ein Programm geben, das sie ausführen können, können sie es bei ausreichender Zeit auch rückentwickeln. Das ist die Natur von Programmen. Sobald die Binärdatei für jemanden verfügbar ist, der sie entschlüsseln möchte, können Sie ein eventuelles Reverse Engineering nicht verhindern. Schließlich muss der Computer in der Lage sein, es zu entschlüsseln, um es auszuführen, und ein Mensch ist einfach ein langsamerer Computer.

Bernstein
quelle
113
+1. Lesen Sie mehr über die glorreichen Tage des Kopierschutzes auf dem Apple II, den immer weiter eskalierenden Krieg zwischen den Verschleiern und den Crackern, die verrückten Tricks mit dem Schrittmotor der Diskette und den undokumentierten 6502-Anweisungen und so weiter ... Und dann weinen Sie selbst Schlaf, weil du nichts annähernd so Aufwendiges implementieren wirst und sie alle irgendwann geknackt wurden.
Nemo
2
Es ist einfacher, einen Simulator zu verwenden und eine bessere Sichtbarkeit zu erzielen, als visuell oder mit einem Disassembler rückzuentwickeln. Wenn die Sicherheit nicht in die von Ihnen verwendete Hardware integriert ist, beträgt der Durchschnitt der Welt durchschnittlich zwei Tage bis zwei Wochen, um so ziemlich alles, was herauskommt, zurückzuentwickeln und zu besiegen. Wenn Sie mehr als zwei Tage benötigen, um dies zu erstellen und zu implementieren, haben Sie zu viel Zeit aufgewendet.
old_timer
5
Das einzige vernünftig funktionierende DRM ist heute die Kombination eines Schlüssels und eines Internet-Servers, die überprüft, ob nur eine Instanz des Schlüssels gleichzeitig aktiv ist.
Thorbjørn Ravn Andersen
2
@Rotsor: Der Computer kann es nicht verstehen, weil wir diese Art von Intelligenz (noch) nicht auf einen Algorithmus reduzieren konnten, nicht weil es irgendeine physische oder technologische Barriere gibt. Der Mensch kann es verstehen, weil er alles kann, was der Computer kann (wenn auch langsamer) , sowie Vernunft .
Adam Robinson
3
An diesem Punkt wird jemand versuchen, den Computer zurückzuentwickeln, es sei denn, er ist nur in einer von Ihnen kontrollierten Umgebung verfügbar.
Amber
41

Safe Net Sentinel (ehemals Aladdin). Vorsichtsmaßnahmen - ihre API ist zum Kotzen, die Dokumentation zum Kotzen, und beide sind im Vergleich zu ihren SDK-Tools großartig.

Ich habe ihre Hardwareschutzmethode ( Sentinel HASP HL ) seit vielen Jahren verwendet. Es ist ein proprietärer USB-Schlüsselanhänger erforderlich, der als "Lizenz" für die Software fungiert. Das SDK verschlüsselt und verschleiert Ihre ausführbaren Dateien und Bibliotheken und ermöglicht es Ihnen, verschiedene Funktionen in Ihrer Anwendung mit Funktionen zu verknüpfen, die in den Schlüssel eingebrannt sind. Ohne einen vom Lizenzgeber bereitgestellten und aktivierten USB-Stick kann die Software nicht entschlüsseln und wird daher nicht ausgeführt. Der Schlüssel verwendet sogar ein angepasstes USB-Kommunikationsprotokoll (außerhalb meines Wissens bin ich kein Gerätetreiber), um das Erstellen eines virtuellen Schlüssels zu erschweren oder die Kommunikation zwischen dem Laufzeit-Wrapper und dem Schlüssel zu manipulieren. Ihr SDK ist nicht sehr entwicklerfreundlich und es ist ziemlich schmerzhaft, zusätzlichen Schutz in einen automatisierten Erstellungsprozess zu integrieren (aber möglich).

Bevor wir den HASP HL-Schutz implementiert haben, waren 7 Piraten bekannt, die den Dotfuscator-Schutz vom Produkt entfernt hatten. Wir haben den HASP-Schutz gleichzeitig mit einem wichtigen Update der Software hinzugefügt, das einige umfangreiche Berechnungen für Videos in Echtzeit durchführt. Wie ich am besten anhand von Profiling und Benchmarking erkennen kann, verlangsamte der HASP HL-Schutz die intensiven Berechnungen nur um etwa 3%. Seit der Veröffentlichung dieser Software vor ungefähr 5 Jahren wurde kein neuer Pirat des Produkts gefunden. Die Software, die es schützt, ist in seinem Marktsegment sehr gefragt, und dem Kunden sind mehrere Wettbewerber bekannt, die aktiv versuchen, ein Reverse Engineering durchzuführen (bisher ohne Erfolg). Wir wissen, dass sie versucht haben, einige Gruppen in Russland um Hilfe zu bitten, die für einen Dienst werben, um den Softwareschutz zu brechen.

Kürzlich haben wir ihre Softwarelizenzlösung (HASP SL) an einem kleineren Projekt ausprobiert, das einfach genug war, um zu arbeiten, wenn Sie bereits mit dem HL-Produkt vertraut sind. Es scheint zu funktionieren; Es wurden keine Piraterievorfälle gemeldet, aber die Nachfrage nach diesem Produkt ist viel geringer.

Natürlich kann kein Schutz perfekt sein. Wenn jemand ausreichend motiviert ist und ernsthaftes Geld zum Verbrennen hat, kann der Schutz, den HASP bietet, sicher umgangen werden.

RyanR
quelle
19
Moderator Hinweis: Kommentare unter dieser Antwort wurden entfernt, da in antagonistisches Rauschen abgewichen wurde.
Tim Post
2
+1 für Erfahrung, aber ich möchte wiederholen, dass es nicht perfekt ist. Maya (3D-Suite) verwendete einen Hardware-Dongle (nicht sicher, ob es sich um HASP handelte), der Piraten nicht lange abschreckte. Wo ein Wille ist, ist auch ein Weg.
Robert Fraser
1
AutoCAD verwendet ein ähnliches System, das mehrfach geknackt wurde. HASP und andere, die es mögen, werden ehrliche Menschen ehrlich halten und gelegentliche Piraterie verhindern. Wenn Sie das nächste Designprodukt im Wert von mehreren Milliarden Dollar bauen, haben Sie immer mit Crackern zu kämpfen. Es geht nur darum, die Rendite zu senken - wie viele Stunden Aufwand lohnt es sich, Ihren Softwareschutz zu knacken, anstatt nur dafür zu bezahlen.
RyanR
6
Ich möchte mich auch aus der Perspektive von jemandem einschalten, der HASP-gesicherte Software verwendet hat. HASPs sind für den Endbenutzer ein königlicher Schmerz im Arsch . Ich habe mich mit einem Dallas iButton und einem Aladdin HASP befasst, und beide waren wirklich fehlerhaft und haben dazu geführt , dass die Software zufällig nicht mehr funktioniert und das HASP getrennt und erneut verbunden werden muss.
Gefälschter Name
4
Es ist auch erwähnenswert, dass HASP-Sicherheitsmaßnahmen nicht unbedingt sicherer sind als die Verschleierung von Code - sicher, dass sie eine andere Methode für das Reverse Engineering erfordern, aber es ist sehr gut möglich, sie rückgängig zu machen - siehe: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Gefälschter Name
22

Die besten Anti-Disassembler-Tricks, insbesondere für Befehlssätze mit variabler Wortlänge, sind Assembler- / Maschinencode, nicht C. Zum Beispiel

CLC
BCC over
.byte 0x09
over:

Der Disassembler muss das Problem lösen, dass ein Verzweigungsziel das zweite Byte in einem Mehrbytebefehl ist. Ein Befehlssatzsimulator hat jedoch kein Problem. Die Verzweigung zu berechneten Adressen, die Sie von C aus verursachen können, macht die Demontage ebenfalls schwierig bis unmöglich. Der Befehlssatzsimulator hat kein Problem damit. Die Verwendung eines Simulators zum Sortieren von Verzweigungszielen für Sie kann den Demontageprozess unterstützen. Kompilierter Code ist für einen Disassembler relativ sauber und einfach. Daher denke ich, dass eine Montage erforderlich ist.

Ich denke, es war kurz vor dem Beginn von Michael Abrashs Zen of Assembly Language, wo er einen einfachen Anti-Disassembler- und Anti-Debugger-Trick zeigte. Der 8088/6 hatte eine Prefetch-Warteschlange. Sie hatten eine Anweisung, die die nächste Anweisung oder ein paar voraus änderte. Wenn Sie einen einzelnen Schritt ausführen, haben Sie den geänderten Befehl ausgeführt. Wenn Ihr Befehlssatzsimulator die Hardware nicht vollständig simuliert hat, haben Sie den geänderten Befehl ausgeführt. Auf realer Hardware, die normal ausgeführt wird, befindet sich der reale Befehl bereits in der Warteschlange, und der geänderte Speicherort würde keinen Schaden verursachen, solange Sie diese Befehlsfolge nicht erneut ausführen. Sie könnten heute wahrscheinlich noch einen solchen Trick anwenden, wenn Pipeline-Prozessoren die nächste Anweisung abrufen. Wenn Sie wissen, dass die Hardware über einen separaten Befehls- und Datencache verfügt, können Sie eine Anzahl von Bytes im Voraus ändern, wenn Sie diesen Code in der Cachezeile ordnungsgemäß ausrichten. Das geänderte Byte wird nicht über den Anweisungscache, sondern über den Datencache und geschrieben Ein Befehlssatzsimulator, der keine geeigneten Cache-Simulatoren hatte, konnte nicht ordnungsgemäß ausgeführt werden. Ich denke, dass nur Software-Lösungen Sie nicht sehr weit bringen werden.

Die oben genannten sind alt und bekannt, ich weiß nicht genug über die aktuellen Tools, um zu wissen, ob sie solche Dinge bereits umgehen. Der selbstmodifizierende Code kann / wird den Debugger auslösen, aber der Mensch kann / wird das Problem eingrenzen und dann den selbstmodifizierenden Code sehen und ihn umgehen.

Früher brauchten die Hacker ungefähr 18 Monate, um etwas auszuarbeiten, zum Beispiel DVDs. Jetzt sind sie durchschnittlich 2 Tage bis 2 Wochen (wenn motiviert) (Blue Ray, Iphones usw.). Das bedeutet für mich, dass ich wahrscheinlich meine Zeit verschwenden werde, wenn ich mehr als ein paar Tage mit Sicherheit verbringe. Die einzige wirkliche Sicherheit, die Sie erhalten, ist die Hardware (zum Beispiel werden Ihre Anweisungen verschlüsselt und nur der Prozessorkern im Chip wird kurz vor der Ausführung so entschlüsselt, dass die entschlüsselten Anweisungen nicht verfügbar gemacht werden können). Das könnte Ihnen Monate statt Tage kosten.

Lesen Sie auch Kevin Mitnicks Buch The Art of Deception. Eine solche Person könnte ein Telefon abheben und Sie oder einen Mitarbeiter die Geheimnisse an das System weitergeben lassen, wenn Sie glauben, es sei ein Manager oder ein anderer Mitarbeiter oder Hardware-Ingenieur in einem anderen Teil des Unternehmens. Und Ihre Sicherheit ist aufgeblasen. Bei Sicherheit geht es nicht nur um die Verwaltung der Technologie, sondern auch um die Verwaltung der Menschen.

Oldtimer
quelle
1
Außerdem müssen Sie keinen Zugriff auf den Quellcode (oder sogar den zerlegten Quellcode) haben, um eine Sicherheitslücke zu finden. Dies kann durch Zufall geschehen oder durch die Verwendung der Tatsache, dass die meisten Löcher auf dieselben Probleme im Code zurückzuführen sind (z. B. Pufferüberläufe).
Asmeurer
2
Es gibt große Probleme mit selbstmodifizierendem Code. Die meisten modernen Betriebssysteme / Hardware lassen Sie dies nicht ohne sehr hohe Berechtigungen tun, es kann zu Cache-Problemen kommen und der Code ist nicht threadsicher.
Martin James
1
Bei modernen x86-Prozessoren sind solche Tricks oft schlecht für die Leistung. Die Verwendung desselben Speicherplatzes als Teil von mehr als einem Befehl hat wahrscheinlich einen ähnlichen Effekt wie ein falsch vorhergesagter Zweig. Selbstmodifizierender Code bewirkt, dass der Prozessor Cache-Zeilen verwirft, um die Kohärenz zwischen dem Befehls- und dem Daten-Cache aufrechtzuerhalten (wenn Sie den geänderten Code viel häufiger ausführen als ändern), kann dies immer noch ein Gewinn sein).
Jilles
2
Ich bin vor 20 Jahren darauf gestoßen. Wir haben fast eine halbe Stunde gebraucht, um herauszufinden, was passiert ist. Nicht sehr gut, wenn Sie einen längeren Schutz benötigen.
Bo Persson
1
"Der eigentliche Befehl befindet sich bereits in der Warteschlange und der geänderte Speicherort würde keinen Schaden verursachen." Bis dazwischen ein Interrupt auftritt, wird die Befehlspipeline geleert und der neue Code wird sichtbar. Jetzt hat Ihre Verschleierung einen Fehler für Ihre legitimen Benutzer verursacht.
Ben Voigt
21

Nehmen Sie zum Beispiel den AES-Algorithmus . Es ist ein sehr, sehr öffentlicher Algorithmus und SEHR sicher. Warum? Zwei Gründe: Es wurde von vielen klugen Leuten überprüft, und der "geheime" Teil ist nicht der Algorithmus selbst - der geheime Teil ist der Schlüssel, der eine der Eingaben in den Algorithmus ist. Es ist ein viel besserer Ansatz, Ihr Protokoll mit einem generierten "Geheimnis" zu entwerfen, das außerhalb Ihres Codes liegt, als den Code selbst geheim zu machen. Der Code kann immer interpretiert werden, egal was Sie tun, und (idealerweise) das generierte Geheimnis kann nur durch einen massiven Brute-Force-Ansatz oder durch Diebstahl gefährdet werden.

Ich denke, eine interessante Frage ist: " Warum möchten Sie Ihren Code verschleiern?" Sie möchten es Angreifern schwer machen, Ihre Algorithmen zu knacken? Um es ihnen schwerer zu machen, ausnutzbare Fehler in Ihrem Code zu finden? Sie müssten den Code nicht verschleiern, wenn der Code überhaupt nicht knackbar wäre. Die Wurzel des Problems ist knackbare Software. Beheben Sie die Wurzel Ihres Problems, verschleiern Sie es nicht nur.

Je verwirrender Sie Ihren Code machen, desto schwieriger wird es für SIE, Sicherheitslücken zu finden. Ja, es wird schwer für Hacker, aber Sie müssen auch Fehler finden. Code sollte in Jahren leicht zu pflegen sein, und selbst gut geschriebener klarer Code kann schwierig zu pflegen sein. Mach es nicht schlimmer.

Phil
quelle
3
+1 für den gesunden Menschenverstand: Warum sollten Sie es sich schwerer machen, wenn Sie einfach ein besseres System entwerfen könnten?
Necrolis
1
Wie ich immer sage, wenn Sie alles serverseitig halten, ist es sicherer
Liamzebedee
20

Das Zurückentwickeln von Code zu erschweren, wird als Code-Verschleierung bezeichnet.

Die meisten der von Ihnen erwähnten Techniken sind ziemlich einfach zu umgehen. Sie konzentrieren sich darauf, nutzlosen Code hinzuzufügen. Aber nutzloser Code ist leicht zu erkennen und zu entfernen, sodass Sie ein sauberes Programm haben.

Für eine effektive Verschleierung müssen Sie das Verhalten Ihres Programms von den nutzlosen Bits abhängig machen, die ausgeführt werden. Zum Beispiel, anstatt dies zu tun:

a = useless_computation();
a = 42;

mach das:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Oder anstatt dies zu tun:

if (running_under_a_debugger()) abort();
a = 42;

Tun Sie dies (wo running_under_a_debuggersollte nicht leicht als eine Funktion zu identifizieren sein, die testet, ob der Code unter einem Debugger ausgeführt wird - es sollte nützliche Berechnungen mit der Debuggererkennung mischen):

a = 42 - running_under_a_debugger();

Effektive Verschleierung kann nicht nur in der Kompilierungsphase durchgeführt werden. Was auch immer der Compiler kann, ein Dekompiler kann. Sicher, Sie können die Belastung der Dekompilierer erhöhen, aber es wird nicht weit gehen. Effektive Verschleierungstechniken beinhalten, sofern vorhanden, das Schreiben einer verschleierten Quelle ab Tag 1. Machen Sie Ihren Code selbstmodifizierend. Verunreinigen Sie Ihren Code mit berechneten Sprüngen, die aus einer großen Anzahl von Eingaben stammen. Zum Beispiel anstelle eines einfachen Anrufs

some_function();

Tun Sie dies, wo Sie zufällig das genaue erwartete Layout der Bits in kennen some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

Wenn Sie die Verschleierung ernst nehmen, verlängern Sie Ihre Planung um mehrere Monate. Verschleierung ist nicht billig. Und denken Sie daran, dass der weitaus beste Weg, um zu vermeiden, dass Leute Ihren Code rückentwickeln, darin besteht, ihn unbrauchbar zu machen, damit sie sich nicht darum kümmern. Es ist eine einfache wirtschaftliche Überlegung: Sie werden rückentwickeln, wenn der Wert für sie höher ist als die Kosten; Aber wenn Sie ihre Kosten erhöhen, erhöhen sich auch Ihre Kosten erheblich. Versuchen Sie also, den Wert für sie zu senken.

Jetzt, wo ich dir gesagt habe, dass Verschleierung schwer und teuer ist, werde ich dir sagen, dass es sowieso nichts für dich ist . Du schreibst

Das aktuelle Protokoll, an dem ich gearbeitet habe, darf zur Sicherheit verschiedener Personen niemals überprüft oder verständlich sein

Das wirft eine rote Fahne. Es ist Sicherheit durch Dunkelheit , die eine sehr schlechte Bilanz hat. Wenn die Sicherheit des Protokolls von Personen abhängt, die das Protokoll nicht kennen, haben Sie bereits verloren .

Literatur-Empfehlungen:

Gilles 'SO - hör auf böse zu sein'
quelle
1
@ Gilles, das ist deine Aussage, die sehr stark ist, also liegt die Beweislast bei dir. Ich werde jedoch ein einfaches Beispiel geben: 2+2Kann vom Compiler vereinfacht werden 4, aber der Dekompiler kann es nicht zurückbringen 2+2(was wäre, wenn es tatsächlich so wäre 1+3?).
Rotsor
7
@Rotsor 4und 2+2sind beobachtungs gleichwertig, so dass sie die gleichen für diesen Zweck, nämlich um herauszufinden , was das Programm macht. Ja, natürlich kann der Dekompiler den Quellcode nicht rekonstruieren, aber das ist irrelevant. Bei diesen Fragen und Antworten geht es um die Rekonstruktion des Verhaltens (dh des Algorithmus und genauer eines Protokolls).
Gilles 'SO - hör auf böse zu sein'
1
Sie müssen nichts tun, um das Verhalten zu rekonstruieren. Sie haben bereits das Programm! Normalerweise müssen Sie das Protokoll verstehen und etwas daran ändern (z. B. eine 2 in 2+2durch 3 ersetzen oder die +durch a ersetzen *).
Rotsor
1
Wenn Sie alle verhaltensäquivalenten Programme als gleich betrachten, kann der Compiler ja nichts tun, da er nur eine Einrückungstransformation ausführt. Der Dekompiler ist dann auch nutzlos, da es sich wieder um eine Identitätstransformation handelt. Wenn Sie dies jedoch nicht tun, ist 2+2-> 4ein gültiges Beispiel für eine vom Compiler durchgeführte nicht umkehrbare Transformation. Ob es das Verständnis einfacher oder schwieriger macht, ist ein separates Argument.
Rotsor
2
@ Gilles Ich kann Ihre Analogie mit Apfel nicht erweitern, weil ich mir keinen strukturell anderen, aber verhaltensmäßig gleichwertigen Apfel vorstellen kann. :)
Rotsor
13

Oft ist die Angst, dass Ihr Produkt rückentwickelt wird, fehl am Platz. Ja, es kann rückentwickelt werden. Aber wird es in kurzer Zeit so berühmt, dass Hacker es wert finden, Engg umzukehren? es? (Dieser Job ist keine kleine Zeitaktivität für umfangreiche Codezeilen).

Wenn es wirklich zu einem Geldverdiener wird, sollten Sie genug Geld gesammelt haben, um es mit legalen Methoden wie Patent und / oder Urheberrechten zu schützen .

IMHO, treffen Sie die grundlegenden Vorsichtsmaßnahmen, die Sie treffen werden, und geben Sie es frei. Wenn es zu einem Punkt des Reverse Engineering wird, der bedeutet, dass Sie wirklich gute Arbeit geleistet haben, werden Sie selbst bessere Wege finden, dies zu überwinden. Viel Glück.

iammilind
quelle
1
Ich meine, dies ist eine tragfähige und zutreffende Antwort, aber die Grenze zwischen Schutz und einem Einkommen von ein paar Millionen, damit andere Ihr Produkt für Sie schützen, ist eine wirklich lange Linie.
Graphitemaster
12

Lesen Sie http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Ich bin sicher, andere könnten wahrscheinlich auch bessere Quellen dafür nennen, warum Sicherheit durch Dunkelheit eine schlechte Sache ist.

Es sollte durchaus möglich sein, moderne Verschlüsselungstechniken verwenden, das System offen zu haben (ich sage nicht , es sollte offen sein, so dass es sein könnte), und habe immer noch absolute Sicherheit, solange der Verschlüsselungsalgorithmus nicht Haben Sie eine Lücke (wahrscheinlich nicht, wenn Sie eine gute auswählen), bleiben Ihre privaten Schlüssel / Passwörter privat und Sie haben keine Sicherheitslücken in Ihrem Code ( dies ist, worüber Sie sich Sorgen machen sollten).

asmeurer
quelle
2
Dem würde ich zustimmen. Ich denke, Sie haben möglicherweise ein konzeptionelles oder ein Designproblem. Gibt es ein Analogon zu einer Private-Public-Key-Pair-Lösung? Sie geben den privaten Schlüssel niemals weiter, er verbleibt beim Eigentümer, dessen sicherer Client ihn verarbeitet. Können Sie den sicheren Code von ihrem Computer fernhalten und die Ergebnisse nur an den Benutzer zurückgeben?
Dizzley
8

Seit Juli 2013 besteht ein erneutes Interesse an einer kryptografisch robusten Verschleierung (in Form einer Verschleierung der Ununterscheidbarkeit ), die aus den ursprünglichen Forschungen von Amit Sahai hervorgegangen zu sein scheint .

Einige destillierte Informationen finden Sie in diesem Artikel im Quanta Magazine und in diesem IEEE Spectrum-Artikel .

Gegenwärtig macht es die Menge an Ressourcen, die erforderlich sind, um diese Technik zu nutzen, unpraktisch, aber AFAICT, der Konsens ist ziemlich optimistisch für die Zukunft.

Ich sage das sehr beiläufig, aber für jeden, der es gewohnt ist, die Verschleierungstechnologie instinktiv abzulehnen - das ist anders. Wenn sich herausstellt, dass es wirklich funktioniert und praktisch ist, ist dies in der Tat wichtig und nicht nur zur Verschleierung.

tne
quelle
7

Um sich zu informieren, lesen Sie die akademische Literatur zur Code-Verschleierung . Christian Collberg von der University of Arizona ist ein angesehener Wissenschaftler auf diesem Gebiet. Salil Vadhan von der Harvard University hat ebenfalls gute Arbeit geleistet.

Ich bin mit dieser Literatur im Rückstand, aber die wesentliche Idee, die mir bewusst ist, ist, dass Sie einen Angreifer nicht daran hindern können, den Code zu sehen, den Sie ausführen werden, aber Sie können ihn mit Code umgeben, der nicht ausgeführt wird, und es kostet Eine exponentielle Zeit des Angreifers (unter Verwendung der bekanntesten Techniken), um herauszufinden, welche Fragmente Ihres Codes ausgeführt werden und welche nicht.

Norman Ramsey
quelle
7

Es gibt ein kürzlich veröffentlichtes Papier mit dem Titel " Programmverschleierung und einmalige Programme ". Wenn Sie es wirklich ernst meinen, Ihre Anwendung zu schützen. Das Papier umgeht im Allgemeinen die theoretischen Unmöglichkeitsergebnisse durch die Verwendung einfacher und universeller Hardware.

Wenn Sie es sich nicht leisten können, zusätzliche Hardware zu benötigen, gibt es auch ein anderes Dokument, das die theoretisch bestmögliche Verschleierung " Über bestmögliche Verschleierung " unter allen Programmen mit derselben Funktionalität und derselben Größe enthält. Die Arbeit zeigt jedoch, dass die bestmögliche Informationstheorie einen Zusammenbruch der Polynomhierarchie impliziert.

Diese Artikel sollten Ihnen zumindest genügend bibliografische Hinweise geben, um in der verwandten Literatur zu lesen, wenn diese Ergebnisse nicht für Ihre Bedürfnisse geeignet sind.

Update: Ein neuer Begriff der Verschleierung, der als nicht unterscheidbare Verschleierung bezeichnet wird, kann das Unmöglichkeitsergebnis abschwächen (Papier).

Mohammad Alaggan
quelle
6

Wenn jemand die Zeit verbringen möchte, um Ihre Binärdatei umzukehren, können Sie absolut nichts tun, um sie zu stoppen. Sie können es etwas schwieriger machen, aber das war es auch schon. Wenn Sie wirklich mehr darüber erfahren möchten, besorgen Sie sich eine Kopie von http://www.hex-rays.com/idapro/ und zerlegen Sie einige Binärdateien.

Die Tatsache, dass die CPU den Code ausführen muss, ist Ihr Rückgängigmachen. Die CPU führt nur Maschinencode aus ... und Programmierer können Maschinencode lesen.

Davon abgesehen ... haben Sie wahrscheinlich ein anderes Problem, das auf andere Weise gelöst werden kann. Was versuchst du zu schützen? Abhängig von Ihrem Problem können Sie wahrscheinlich eine Verschlüsselung verwenden, um Ihr Produkt zu schützen.

Brian Makin
quelle
6

Um die richtige Option auswählen zu können, sollten Sie die folgenden Aspekte berücksichtigen:

  1. Ist es wahrscheinlich, dass "neue Benutzer" nicht bezahlen möchten, sondern Ihre Software verwenden?
  2. Ist es wahrscheinlich, dass bestehende Kunden mehr Lizenzen benötigen als sie haben?
  3. Wie viel sind potenzielle Benutzer bereit zu zahlen?
  4. Möchten Sie Lizenzen pro Benutzer / gleichzeitigen Benutzer / Workstation / Unternehmen vergeben?
  5. Benötigt Ihre Software Schulungen / Anpassungen, um nützlich zu sein?

Wenn die Antwort auf Frage 5 "Ja" lautet, machen Sie sich keine Sorgen über illegale Kopien. Sie wären sowieso nicht nützlich.

Wenn die Antwort auf Frage 1 "Ja" lautet, denken Sie zuerst über die Preisgestaltung nach (siehe Frage 3).

Wenn Sie die Fragen 2 mit "Ja" beantworten, ist möglicherweise ein "Pay-per-Use" -Modell für Sie geeignet.

Nach meiner Erfahrung ist Pay-per-Use + Anpassung und Schulung der beste Schutz für Ihre Software, weil:

  • Neue Benutzer werden vom Preismodell angezogen (wenig Nutzen -> wenig Lohn)
  • Es gibt fast keine "anonymen Benutzer", da diese geschult und angepasst werden müssen.
  • Keine Softwareeinschränkungen schrecken potenzielle Kunden ab.
  • Es gibt einen kontinuierlichen Geldstrom von bestehenden Kunden.
  • Aufgrund einer langfristigen Geschäftsbeziehung erhalten Sie von Ihren Kunden wertvolles Feedback für die Entwicklung.

Bevor Sie an die Einführung von DRM oder Verschleierung denken, sollten Sie sich diese Punkte überlegen und ob sie auf Ihre Software anwendbar sind.

Schwarz
quelle
Sehr guter Rat (und ich habe ihn positiv bewertet), aber er spricht diese spezielle Frage nicht wirklich an
Mawg sagt, dass Monica
5

Geschützter Code in einer virtuellen Maschine schien zunächst nicht rückentwickelbar zu sein. Themida Packer

Aber es ist nicht mehr so ​​sicher. Und egal wie Sie Ihren Code packen, Sie können jederzeit einen Speicherauszug aller geladenen ausführbaren Dateien erstellen und diese mit jedem Disassembler wie IDA Pro zerlegen.

IDA Pro wird auch mit einem raffinierten Assembler-Code für den C-Quellcode-Transformator geliefert, obwohl der generierte Code eher wie ein mathematisches Zeiger- / Adress-Durcheinander aussieht. Wenn Sie ihn mit dem Original vergleichen, können Sie alle Fehler beheben und alles herausreißen.

SSpoke
quelle
5

Keine Würfel, Sie können Ihren Code nicht vor dem Zerlegen schützen. Sie können den Server für die Geschäftslogik einrichten und den Webservice verwenden, um ihn für Ihre App bereitzustellen. Natürlich ist dieses Szenario nicht immer möglich.

Lukasz Madon
quelle
8
Die einzige Möglichkeit, um zu vermeiden, dass Personen Ihren Code zerlegen, besteht darin, ihnen niemals physischen Zugriff darauf zu gewähren. Dies bedeutet, dass Sie Ihre Anwendung ausschließlich als SAAS anbieten, Anfragen von Remoteclients entgegennehmen und die verarbeiteten Daten zurückgeben. Stellen Sie den Server in einem verschlossenen Raum in einem unterirdischen Bunker auf, der von einem Alligatorgraben und einem 5 m hohen elektrifizierten Stacheldraht umgeben ist, zu dem Sie den Schlüssel wegwerfen, bevor Sie ihn mit 10 m Stahlbeton abdecken, und hoffen Sie dann, dass Sie nicht vergessen haben, Tonnen zu installieren von Softwaresystemen, um das Eindringen in das Netzwerk zu verhindern.
Jwenting
6
Ich hoffe, ich bekomme nie den Vertrag zur Wartung Ihrer Server
Colin Pickard
5

Um Reverse Engineering zu vermeiden, dürfen Sie den Code nicht an Benutzer weitergeben. Trotzdem empfehle ich die Verwendung einer Online-Bewerbung ... jedoch (da Sie keinen Kontext angegeben haben), die für Sie sinnlos sein könnte.

Galliumnitrid
quelle
Dies ist die wirkliche Lösung ... nämlich Ihre Kronjuwelen auf Ihrem eigenen Server auf Ihrem eigenen VPS-Computer zu platzieren und nur API-Aufrufe auf diesem Server vom Client (Browser oder API-Client)
Scott Stensland
5

Möglicherweise ist Ihre beste Alternative immer noch die Verwendung der Virtualisierung, die eine weitere Ebene der Indirektion / Verschleierung einführt, die umgangen werden muss. Wie SSpoke in seiner Antwort sagte , ist diese Technik jedoch auch nicht 100% sicher.


Der Punkt ist, dass Sie keinen ultimativen Schutz erhalten, weil es so etwas nicht gibt, und wenn es jemals sein wird, wird es nicht lange dauern, was bedeutet, dass es überhaupt kein ultimativer Schutz war.

Was auch immer der Mensch zusammenbaut, kann zerlegt werden.

Es ist normalerweise wahr, dass (richtiges) Zerlegen oft (ein bisschen oder mehr) schwieriger ist, also muss Ihr Gegner geschickter sein , aber Sie können davon ausgehen, dass es immer jemanden von solcher Qualität gibt, und es ist eine sichere Wette.

Wenn Sie etwas vor REs schützen möchten, müssen Sie mindestens die von REs verwendeten Techniken kennen.

Also Worte

Das Internet ist nicht wirklich einfallsreich für die Verhinderung von Reverse Engineering, sondern enthält unzählige Informationen zum Reverse Engineering

zeige deine schlechte Einstellung. Ich sage nicht, dass Sie, um Schutz zu verwenden oder einzubetten, wissen müssen, wie man ihn bricht, aber um ihn mit Bedacht einzusetzen, sollten Sie seine Schwächen und Fallstricke kennen. Du solltest es verstehen .

(Es gibt Beispiele für Software, die den Schutz falsch verwendet, sodass ein solcher Schutz praktisch nicht vorhanden ist. Um ein vages Sprechen zu vermeiden, gebe ich Ihnen ein im Internet kurz beschriebenes Beispiel: Oxford English Dictionary Second Edition auf CD-ROM v4. Sie können darüber lesen Die fehlgeschlagene Verwendung von SecuROM auf der folgenden Seite: Oxford English Dictionary (OED) auf CD-ROM in einer 16-, 32- oder 64-Bit-Windows-Umgebung: Festplatteninstallation, Fehler, Textverarbeitungsmakros, Netzwerk, Schriftarten und so weiter )

Alles braucht Zeit.

Wenn Sie mit dem Thema noch nicht vertraut sind und keine Monate oder Jahre haben, um sich richtig mit RE-Themen zu befassen, sollten Sie sich für verfügbare Lösungen entscheiden, die von anderen entwickelt wurden. Das Problem hier ist offensichtlich, sie sind bereits vorhanden, sodass Sie bereits wissen, dass sie nicht 100% sicher sind. Wenn Sie jedoch Ihren eigenen neuen Schutz erstellen, haben Sie nur das falsche Gefühl, geschützt zu sein, es sei denn, Sie kennen den Stand der Technik in Reverse Engineering und Schutz (aber zumindest derzeit nicht).

Der Zweck des Softwareschutzes besteht darin, Neulinge zu erschrecken, gängige REs zu blockieren und erfahrenen REs nach ihrer (hoffentlich interessanten) Reise in die Mitte Ihrer Anwendung ein Lächeln ins Gesicht zu zaubern.

Im Geschäftsgespräch kann man sagen, dass es darum geht, den Wettbewerb so weit wie möglich zu verzögern.

(Schauen Sie sich die schöne Präsentation Silver Needle in the Skype von Philippe Biondi und Fabrice Desclaux an, die auf Black Hat 2006 gezeigt wird.)


Du bist dir bewusst, dass es eine Menge Dinge über RE gibt, also fang an, es zu lesen. :) :)

Ich sagte über Virtualisierung, also gebe ich Ihnen einen Link zu einem beispielhaften Thread aus dem EXETOOLS FORUM : Bester Software-Protector: Themida oder Enigma Protector? . Es kann Ihnen bei weiteren Suchen etwas helfen.

przemoc
quelle
4

Ich denke nicht, dass irgendein Code nicht hackbar ist, aber die Belohnungen müssen großartig sein, damit jemand es versuchen möchte.

Allerdings gibt es Dinge, die Sie tun sollten, wie zum Beispiel:

  • Verwenden Sie die höchstmögliche Optimierungsstufe (beim Reverse Engineering geht es nicht nur darum, die Assemblierungssequenz abzurufen, sondern auch darum, den Code zu verstehen und in eine übergeordnete Sprache wie C zu portieren). Hochoptimierter Code kann a b --- h folgen.
  • Machen Sie Strukturen dicht, indem Sie nicht größere Datentypen als nötig haben. Ordnen Sie die Strukturelemente zwischen den offiziellen Code-Releases neu an. Neu angeordnete Bitfelder in Strukturen können ebenfalls verwendet werden.
  • Sie können überprüfen, ob bestimmte Werte vorhanden sind, die nicht geändert werden sollten (eine Copyright-Meldung ist ein Beispiel). Wenn ein Bytevektor "vwxyz" enthält, können Sie einen anderen Bytevektor mit "abcde" verwenden und die Unterschiede vergleichen. Der Funktion, die dies tut, sollten keine Zeiger auf die Vektoren übergeben werden, sondern externe Zeiger verwenden, die in anderen Modulen als (Pseudo-C-Code) "char * p1 = & string1 [539];" definiert sind. und "char p2 = & string2 [-11731];". Auf diese Weise gibt es keine Zeiger, die genau auf die beiden Zeichenfolgen zeigen. Im Vergleichscode vergleichen Sie dann für " (p1-539 + i) - * (p2 + 11731 + i) == irgendeinen Wert". Der Cracker wird denken, dass es sicher ist, string1 zu ändern, da niemand darauf zu verweisen scheint. Begrabe den Test an einem unerwarteten Ort.

Versuchen Sie, den Assembly-Code selbst zu hacken, um zu sehen, was einfach und was schwierig zu tun ist. Es sollten Ideen auftauchen, mit denen Sie experimentieren können, um das Reverse Engineering des Codes zu erschweren und das Debuggen zu erschweren.

Olof Forshell
quelle
2
Ihr erster Punkt macht keinen Sinn, optimierter Code schneidet Cruft aus, dies erleichtert das Umkehren (ich spreche aus Erfahrung). Ihr dritter Punkt ist auch Zeitverschwendung, und Reverse Engineer, die sein Geld wert sind, wissen, wie man Speicherzugriffs-Breakpointing durchführt. Aus diesem Grund ist es wahrscheinlich am besten, kein System selbst zu entwerfen, sondern Bibliotheken von Drittanbietern, die noch nicht "geknackt" wurden, da dies wahrscheinlich etwas länger dauert als alles, was ein "Anfänger" erstellen könnte ...
Necrolis
Da es so aussieht, als ob ich nichts zu diesem Thema weiß, sollte ich mich vielleicht an einen Fachmann wie Sie wenden, um meine Softwareentwicklungsanforderungen zu erfüllen, anstatt selbst Code zu schreiben.
Olof Forshell
4

Wie viele bereits sagten: Auf einer normalen CPU kann man sie nicht aufhalten, man kann sie nur verzögern. Wie mein alter Kryptolehrer mir sagte: Sie brauchen keine perfekte Verschlüsselung, das Brechen des Codes muss nur teurer sein als der Gewinn. Gleiches gilt für Ihre Verschleierung.

Aber 3 zusätzliche Hinweise:

  1. Es ist möglich, Reverse Engineering unmöglich zu machen, ABER (und dies ist ein sehr sehr großes, aber), Sie können es nicht auf einer herkömmlichen CPU tun. Ich habe auch viel Hardware-Entwicklung gemacht und oft werden FPGAs verwendet. Auf dem Virtex 5 FX befindet sich beispielsweise eine PowerPC-CPU, und Sie können die APU verwenden, um eigene CPU-Opcodes in Ihrer Hardware zu implementieren. Sie können diese Funktion verwenden, um Anweisungen für den PowerPC, auf die von außen oder andere Software nicht zugegriffen werden kann, wirklich zu entschlüsseln oder sogar den Befehl in der Hardware auszuführen. Da das FPGA eine AES-Verschlüsselung für seinen Konfigurationsbitstream eingebaut hat, konnten Sie es nicht zurückentwickeln (außer jemand schafft es, AES zu brechen, aber dann haben wir wohl andere Probleme ...). Auf diese Weise schützen Anbieter von Hardware-IP auch ihre Arbeit.

  2. Sie sprechen vom Protokoll. Sie sagen nicht, um welche Art von Protokoll es sich handelt, aber wenn es sich um ein Netzwerkprotokoll handelt, sollten Sie es zumindest vor Netzwerk-Sniffing schützen. Dies können Sie in der Tat durch Verschlüsselung tun. Wenn Sie jedoch die Entschlüsselung vor einem Eigentümer der Software schützen möchten, kehren Sie zur Verschleierung zurück.

  3. Machen Sie Ihr Programm nicht abbaubar / nicht ausführbar. Versuchen Sie, eine Art Debugging-Erkennung zu verwenden, und wenden Sie diese z. B. in einer Formel an oder fügen Sie einer magischen Konstante einen Debug-Registerinhalt hinzu. Es ist viel schwieriger, wenn Ihr Programm im Debug-Modus aussieht, wenn es normal ausgeführt wird, aber eine völlig falsche Berechnung, Operation oder eine andere ausführt. ZB kenne ich einige Öko-Spiele, die einen wirklich bösen Kopierschutz hatten (ich weiß, dass Sie keinen Kopierschutz wollen, aber es ist ähnlich): Die gestohlene Version hat die abgebauten Ressourcen nach 30 Minuten Spielzeit geändert, und plötzlich haben Sie nur noch eine Ressource. Der Pirat hat es gerade geknackt (dh rückentwickelt) - überprüft, ob es läuft, und Volia hat es freigegeben. Solche geringfügigen Verhaltensänderungen sind sehr schwer zu erkennen, insb. wenn sie nicht sofort zur Erkennung erscheinen, sondern nur verzögert.

Schließlich würde ich vorschlagen: Schätzen Sie, welchen Nutzen die Leute für das Reverse Engineering Ihrer Software haben, übersetzen Sie dies in einige Zeit (z. B. durch Verwendung des günstigsten indischen Gehalts) und machen Sie das Reverse Engineering so zeitaufwändig, dass es größer ist.

flolo
quelle
3

Im Gegensatz zu dem, was die meisten Leute aufgrund ihrer Intuition und persönlichen Erfahrung sagen, halte ich eine kryptografisch sichere Programmverschleierung im Allgemeinen nicht für unmöglich.

Dies ist ein Beispiel für eine perfekt verschleierte Programmanweisung, um meinen Standpunkt zu demonstrieren:

printf("1677741794\n");

Man kann nie erraten, was es wirklich tut

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

Zu diesem Thema gibt es ein interessantes Papier, das einige Unmöglichkeitsergebnisse belegt. Es heißt "Über die (Un-) Möglichkeit, Programme zu verschleiern". .

Obwohl das Papier beweist, dass die Verschleierung, die das Programm nicht von der von ihm implementierten Funktion unterscheidbar macht, unmöglich ist, ist eine auf schwächere Weise definierte Verschleierung möglicherweise immer noch möglich!

Rotsor
quelle
7
1. Ihr Beispiel ist hier nicht relevant; Die beiden Programme, die Sie anzeigen, sind verhaltensmäßig äquivalent. Bei dieser Frage geht es darum, das Verhalten eines Programms herauszufinden und nicht seinen Quellcode zu rekonstruieren (was offensichtlich unmöglich ist). 2. Dieses Papier ist ein theoretisches Papier; Es ist unmöglich, den perfekten Verschleierer zu schreiben, aber es ist auch unmöglich, den perfekten Dekompiler zu schreiben (aus den gleichen Gründen, aus denen es unmöglich ist, den perfekten Programmanalysator zu schreiben). In der Praxis ist es ein Wettrüsten: Wer kann den besseren (De-) Obfuscator schreiben?
Gilles 'SO - hör auf böse zu sein'
1
@ Gilles, das Ergebnis der (korrekten) Deobfuscation entspricht immer dem verschleierten Code. Ich sehe nicht, wie das die Bedeutung des Problems untergräbt.
Rotsor
Auch zum Wettrüsten: Hier geht es nicht darum, wer mehr in die Forschung investiert, sondern darum, wer Recht hat. Richtige mathematische Beweise gehen nicht schief, nur weil jemand möchte, dass sie wirklich schlecht sind.
Rotsor
1
Okay, vielleicht haben Sie Recht mit dem Wettrüsten in der Praxis. Ich glaube, ich habe das falsch verstanden. :) Ich hoffe jedoch, dass eine kryptografisch sichere Verschleierung möglich ist.
Rotsor
Versuchen Sie für einen interessanten Fall der Verschleierung Smartcards, bei denen das Problem darin besteht, dass der Angreifer physischen Zugriff hat (White-Box-Verschleierung). Ein Teil der Antwort besteht darin, den Zugriff auf physische Weise zu beschränken (der Angreifer kann geheime Schlüssel nicht direkt lesen). Aber auch die Verschleierung von Software spielt eine Rolle, vor allem, um Angriffe wie DPA nicht zu nützlichen Ergebnissen zu führen. Ich habe leider keine gute Referenz zu bieten. Die Beispiele in meiner Antwort sind vage von Techniken inspiriert, die in diesem Bereich verwendet werden.
Gilles 'SO - hör auf böse zu sein'
3

Sicherheit durch Dunkelheit funktioniert nicht, wie Menschen gezeigt haben, die viel klüger sind als wir beide. Wenn Sie das Kommunikationsprotokoll Ihrer Kunden schützen müssen, sind Sie moralisch verpflichtet, den besten Code zu verwenden, der offen ist und von Experten vollständig geprüft wird.

Dies ist für die Situation vorgesehen, in der Personen den Code überprüfen können. Wenn Ihre Anwendung auf einem eingebetteten Mikroprozessor ausgeführt werden soll, können Sie einen auswählen, der über eine Versiegelungsfunktion verfügt, die es unmöglich macht, den Code zu überprüfen oder mehr als triviale Parameter wie die aktuelle Verwendung während der Ausführung zu beobachten. (Außer bei Hardware-Invasionstechniken zerlegen Sie den Chip sorgfältig und verwenden fortschrittliche Geräte, um die Ströme an einzelnen Transistoren zu überprüfen.)

Ich bin der Autor eines Reverse Engineering Assemblers für den x86. Wenn Sie für eine kalte Überraschung bereit sind, senden Sie mir das Ergebnis Ihrer besten Bemühungen. (Kontaktieren Sie mich über meine Websites.) Wenige, die ich in den Antworten gesehen habe, würden eine erhebliche Hürde für mich darstellen. Wenn Sie sehen möchten, wie ausgefeilter Reverse Engineering-Code funktioniert, sollten Sie Websites mit Reverse Engineering-Herausforderungen wirklich studieren.

Ihre Frage könnte eine Klarstellung gebrauchen. Wie können Sie ein Protokoll geheim halten, wenn der Computercode für das Reverse Engineering geeignet ist? Wenn mein Protokoll darin bestehen würde, eine RSA-verschlüsselte Nachricht (sogar einen öffentlichen Schlüssel) zu senden, was gewinnen Sie, wenn Sie das Protokoll geheim halten? Für alle praktischen Zwecke würde ein Inspektor mit einer Folge von Zufallsbits konfrontiert.

Groetjes Albert

Albert van der Horst
quelle
3

Herkömmliche Reverse Engineering-Techniken hängen von der Fähigkeit eines intelligenten Agenten ab, mithilfe eines Disassemblers Fragen zum Code zu beantworten. Wenn Sie starke Sicherheit wünschen, müssen Sie Dinge tun, die nachweislich verhindern, dass der Agent solche Antworten erhält.

Sie können dies tun, indem Sie sich auf das Halting-Programm ("Stoppt Programm X?") Verlassen, das im Allgemeinen nicht gelöst werden kann. Das Hinzufügen von Programmen, über die Sie nur schwer nachdenken können, erschwert das Nachdenken über Ihr Programm. Es ist einfacher, solche Programme zu erstellen, als sie auseinander zu reißen. Sie können dem Programm auch Code hinzufügen, dessen Argumentationsschwierigkeiten unterschiedlich sind. Ein guter Kandidat ist das Argumentationsprogramm über Aliase ("Zeiger").

Collberg et al. Haben ein Papier ("Herstellung billiger, widerstandsfähiger und verstohlener undurchsichtiger Konstrukte"), das diese Themen behandelt und eine Vielzahl von "undurchsichtigen" Prädikaten definiert, die es sehr schwierig machen können, über Code nachzudenken:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

Ich habe nicht gesehen, dass Collbergs spezifische Methoden auf Produktionscode angewendet wurden, insbesondere nicht auf C- oder C ++ - Quellcode.

Der DashO Java Obfuscator scheint ähnliche Ideen zu verwenden. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

Ira Baxter
quelle
2

ERSTE ERINNERUNG AN DAS VERSTECKEN IHRES CODES : Nicht Ihr Code muss ausgeblendet werden.

DAS ENDZIEL : Mein Endziel für die meisten Softwareprogramme ist die Möglichkeit, verschiedene Lizenzen zu verkaufen, mit denen bestimmte Funktionen in meinen Programmen ein- und ausgeschaltet werden.

BESTE TECHNIK : Ich finde, dass der Aufbau eines Systems von Hooks und Filtern wie WordPress die absolut beste Methode ist, um Ihre Gegner zu verwirren. Auf diese Weise können Sie bestimmte Triggerzuordnungen verschlüsseln, ohne den Code tatsächlich zu verschlüsseln.

Der Grund dafür ist, dass Sie so wenig Code wie möglich verschlüsseln möchten.

KENNEN SIE IHRE CRACKER : Wissen Sie : Der Hauptgrund für das Knacken von Code liegt nicht in der böswilligen Verteilung von Lizenzen, sondern darin, dass Sie Ihren Code ändern müssen und sie nicht wirklich kostenlose Kopien verteilen müssen.

ERSTE SCHRITTE : Wenn Sie die kleine Menge an Code beiseite legen, die Sie verschlüsseln möchten , sollte der Rest des Codes versuchen, in EINE Datei gepackt zu werden, um die Komplexität und das Verständnis zu erhöhen.

VORBEREITUNG ZUR ENCRYPTIERUNG : Sie werden mit meinem System in Schichten verschlüsseln. Es wird auch eine sehr komplexe Prozedur sein. Erstellen Sie also ein anderes Programm, das für den Verschlüsselungsprozess verantwortlich ist.

SCHRITT 1 : Verschleiern Sie die Verwendung von base64-Namen für alles. Sobald dies erledigt ist, base64 den verschleierten Code und speichere ihn in einer temporären Datei, die später zum Entschlüsseln und Ausführen dieses Codes verwendet wird. Sinn ergeben?

Ich werde es wiederholen, da Sie dies immer wieder tun werden. Sie erstellen eine base64-Zeichenfolge und speichern sie in einer anderen Datei als Variable, die entschlüsselt und gerendert wird.

SCHRITT ZWEI : Sie werden diese temporäre Datei als Zeichenfolge einlesen und verschleiern, dann base64 und in einer zweiten temporären Datei speichern, die zum Entschlüsseln und Rendern für den Endbenutzer verwendet wird.

SCHRITT DREI : Wiederholen Sie Schritt zwei so oft, wie Sie möchten. Sobald dies ordnungsgemäß funktioniert, ohne Fehler zu entschlüsseln, möchten Sie mit dem Bau von Landminen für Ihre Gegner beginnen.

LAND MINE ONE : Sie werden die Tatsache, dass Sie benachrichtigt werden, absolut geheim halten wollen. Bauen Sie also ein Sicherheitswarnsystem für Cracker-Versuche für Schicht 2 ein. Dieses wird ausgelöst, damit Sie die Einzelheiten über Ihren Gegner erfahren, falls etwas schief gehen soll.

LAND MINE TWO : Abhängigkeiten. Sie möchten nicht, dass Ihr Gegner Layer 1 ausführen kann, ohne Layer 3 oder 4 oder 5 oder sogar das eigentliche Programm, für das er entwickelt wurde. Stellen Sie also sicher, dass Sie in Ebene 1 eine Art Kill-Skript einfügen, das aktiviert wird, wenn das Programm nicht vorhanden ist, oder die anderen Ebenen.

Ich bin sicher, Sie können sich Ihre eigenen Landminen einfallen lassen und viel Spaß damit haben.

ERINNERUNG : Sie können Ihren Code tatsächlich verschlüsseln, anstatt ihn zu base64'en. Auf diese Weise entschlüsselt eine einfache base64 das Programm nicht.

BELOHNUNG : Denken Sie daran, dass dies tatsächlich eine symbiotische Beziehung zwischen Ihnen und Ihrem Gegner sein kann. Ich platziere immer einen Kommentar innerhalb der ersten Ebene. Der Kommentar gratuliert dem Cracker und gibt ihm einen Promo-Code, den er verwenden kann, um eine Geldprämie von Ihnen zu erhalten.

Machen Sie die Geldprämie ohne Vorurteile signifikant. Normalerweise sage ich so etwas wie 500 Dollar. Wenn Ihr Mann der erste ist, der den Code knackt, dann zahlen Sie ihm sein Geld und werden Sie sein Freund. Wenn er ein Freund von Ihnen ist, wird er Ihre Software nicht vertreiben. Fragen Sie ihn, wie er es gemacht hat und wie Sie sich verbessern können!

VIEL GLÜCK!

Unternehmensarchitekt
quelle
4
Hast du die Frage überhaupt gelesen? Ich habe nie nach Methoden gefragt, wie man sich vor Piraterie schützt. Die Anwendung ist kostenlos. Es ist das zugrunde liegende Protokoll, das aufgrund der Art der Sicherheit geschützt werden muss.
Graphitemaster