webentwicklung-frage-antwort-db.com.de

Ausführbare Dateien vor Reverse Engineering schützen?

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 arbeite, darf jedoch niemals überprüft oder verstanden werden, um die Sicherheit verschiedener Personen zu gewährleisten.

Jetzt ist dies ein neues Thema für mich, und das Internet ist nicht wirklich einfallsreich für Verhinderung von Reverse Engineering, sondern zeigt Tonnen von Informationen über wie man Reverse Engineering durchführt

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

  • Code-Injection (Aufrufen von Dummy-Funktionen vor und nach tatsächlichen Funktionsaufrufen)
  • Code Obfustication (verstümmelt die Zerlegung 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 Exit erzwingen, falls erkannt)

  • Funktionstrampoline

     void trampoline(void (*fnptr)(), bool ping = false)  
     {  
       if(ping)  
         fnptr();  
       else  
         trampoline(fnptr, true);  
     }
    
  • Sinnlose Zuweisungen und Freigabe von Zuweisungen (Stapel ändert sich sehr)

  • Sinnlose Dummy-Anrufe und Trampoline (jede Menge Sprünge bei der Demontage)
  • Tonnenweise Guss (für die verschleierte Demontage)

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

202
graphitemaster

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

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

148
Stephen Canon

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

Wenn Sie Leuten ein Programm geben, das sie ausführen können, können sie es auch rückentwickeln, wenn sie genügend Zeit haben. 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.

173
Amber

Safe Net Sentinel (früher Aladdin). Vorsichtsmaßnahmen: Die API und die Dokumentation sind mies und beides im Vergleich zu den SDK-Tools großartig.

Ich habe ihre Hardwareschutzmethode ( Sentinel HASP HL ) für viele Jahre verwendet. Es ist ein proprietärer USB-Schlüsselanhänger erforderlich, der als "Lizenz" für die Software fungiert. Ihr 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üsselt werden und wird daher nicht ausgeführt. Der Schlüssel verwendet sogar ein benutzerdefiniertes USB-Kommunikationsprotokoll (außerhalb meines Wissens bin ich kein Gerätetreiber), um die Erstellung eines virtuellen Schlüssels oder Manipulationen der Kommunikation zwischen dem Laufzeit-Wrapper und dem Schlüssel zu erschweren. 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 implementierten, waren 7 Piraten bekannt, die den Dotfuscator-Schutz vom Produkt entfernt hatten. Wir haben den HASP-Schutz gleichzeitig mit einem großen Update der Software hinzugefügt, mit der einige umfangreiche Berechnungen für Videos in Echtzeit durchgeführt werden. Wie sich am Profiling und Benchmarking ablesen lässt, hat der HASP HL-Schutz die intensiven Berechnungen nur um ca. 3% verlangsamt. Seitdem diese Software vor ungefähr 5 Jahren veröffentlicht wurde, wurde kein neuer Pirat des Produkts gefunden. Die Software, die sie schützt, ist in ihrem Marktsegment sehr gefragt, und dem Kunden ist bekannt, dass mehrere Wettbewerber aktiv versuchen, ein Reverse Engineering durchzuführen (bisher ohne Erfolg). Wir wissen, dass sie versucht haben, Hilfe von einigen Gruppen in Russland zu erbitten, die für einen Dienst werben, mit dem der Softwareschutz aufgehoben werden soll, da zahlreiche Beiträge in verschiedenen Newsgroups und Foren die neueren Versionen des geschützten Produkts enthielten.

Kürzlich haben wir die Softwarelizenzlösung (HASP SL) für ein kleineres Projekt ausprobiert, das unkompliziert genug war, um zu arbeiten, wenn Sie bereits mit dem HL-Produkt vertraut sind. Es scheint zu funktionieren; Es wurden keine Fälle von Piraterie gemeldet, aber dieses Produkt ist viel weniger gefragt.

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

41
RyanR

Nehmen Sie zum Beispiel den AES-Algorithmus . Es ist ein sehr, sehr öffentlicher Algorithmus und es ist 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 sich außerhalb Ihres Codes befindet, als den Code selbst geheim zu halten. 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 Angreifern das Knacken Ihrer Algorithmen erschweren? Um es ihnen zu erschweren, ausnutzbare Fehler in Ihrem Code zu finden? Sie müssten keinen Code verschleiern, wenn der Code überhaupt nicht geknackt werden könnte. Die Wurzel des Problems ist knackbare Software. Beheben Sie die Wurzel Ihres Problems und verschleiern Sie es nicht einfach.

Je verwirrender Sie Ihren Code gestalten, desto schwerer 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 warten sein, und selbst gut geschriebener, klarer Code kann schwierig zu warten sein. Mach es nicht schlimmer.

21
Phil

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

CLC
BCC over
.byte 0x09
over:

Der Disassembler muss das Problem beheben, dass ein Verzweigungsziel das zweite Byte in einem Multi-Byte-Befehl ist. Ein Befehlssatzsimulator wird jedoch kein Problem haben. Die Verzweigung zu berechneten Adressen, die Sie von C aus verursachen können, erschwert die Demontage ebenfalls. Befehlssatzsimulator wird kein Problem damit haben. Mithilfe eines Simulators zum Aussortieren von Zweigzielen können Sie den Demontageprozess unterstützen. Kompilierter Code ist für einen Disassembler relativ sauber und einfach. Deshalb denke ich, dass eine Versammlung erforderlich ist.

Ich denke, es war kurz vor dem Beginn von Michael Abrashs Zen of Assembly Language, in dem er einen einfachen Trick gegen Disassembler und Debugger zeigte. Der 8088/6 hatte eine Prefetch-Warteschlange. Sie hatten eine Anweisung, die die nächste Anweisung oder ein Paar vor Ihnen änderte. Wenn Sie in Einzelschritten arbeiten, haben Sie die geänderte Anweisung ausgeführt. Wenn Ihr Befehlssatzsimulator die Hardware nicht vollständig simuliert hat, haben Sie die geänderte Anweisung ausgeführt. Auf normal laufender echter Hardware wäre der echte Befehl bereits in der Warteschlange und der geänderte Speicherort würde keinen Schaden anrichten, solange Sie diese Befehlsfolge nicht erneut ausführen. Sie könnten wahrscheinlich noch heute einen solchen Trick anwenden, wenn Pipeline-Prozessoren den nächsten Befehl abrufen. Wenn Sie wissen, dass die Hardware über einen separaten Befehls- und Datencache verfügt, können Sie eine Anzahl von Bytes ändern, wenn Sie diesen Code in der Cache-Zeile richtig ausrichten. Das geänderte Byte wird nicht über den Befehlscache, sondern über den Datencache geschrieben Ein Befehlssatzsimulator, der nicht über geeignete Cache-Simulatoren verfügte, 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 bereits solche Dinge 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 es umgehen.

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

Lesen Sie auch Kevin Mitnicks Buch The Art of Deception. Eine Person wie diese könnte zum Telefon greifen und Sie oder einen Mitarbeiter bitten, die Geheimnisse an das System weiterzugeben. Sie denken, es sei ein Manager oder ein anderer Mitarbeiter oder Hardware-Ingenieur in einem anderen Teil des Unternehmens. Und deine Sicherheit ist aufgeblasen. Bei Sicherheit geht es nicht nur um das Management der Technologie, sondern auch um das Management der Menschen.

21
old_timer

Das Zurückentwickeln von Code wird als Codeverschleierung bezeichnet.

Die meisten Techniken, die Sie erwähnen, sind relativ 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 (wobei running_under_a_debugger Als Funktion, die prüft, ob der Code unter einem Debugger ausgeführt wird, nicht leicht zu identifizieren sein sollte - es sollte nützliche Berechnungen mit der Debuggererkennung mischen):

a = 42 - running_under_a_debugger();

Effektive Verschleierung ist nicht nur in der Kompilierungsphase möglich. Was auch immer der Compiler tun kann, kann ein Decompiler tun. Sicher, Sie können die Belastung für die Dekompilierer erhöhen, aber es wird nicht weit gehen. Effektive Verschleierungstechniken umfassen, sofern vorhanden, das Schreiben einer verschleierten Quelle ab dem ersten Tag. Ändern Sie Ihren Code selbst. 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 some_data_structure kennen:

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

Wenn Sie es mit der Verschleierung ernst meinen, sollten Sie Ihrer Planung mehrere Monate hinzufügen. Verschleierung ist nicht billig. Und denken Sie daran, dass die beste Möglichkeit, Rückentwicklungen Ihres Codes zu vermeiden, darin besteht, ihn unbrauchbar zu machen, damit sie sich nicht darum kümmern. Es ist eine einfache wirtschaftliche Überlegung: Sie werden ein Reverse Engineering durchführen, wenn der Wert für sie höher ist als die Kosten. Wenn Sie jedoch die Kosten erhöhen, erhöhen Sie auch die Kosten erheblich. Verringern Sie daher den Wert für sie.

Nun, da ich Ihnen gesagt habe, dass die Verschleierung schwer und teuer ist, werde ich Ihnen sagen , dass dies nicht der Fall ist für dich sowieso . Du schreibst

das aktuelle Protokoll, an dem ich gearbeitet habe, darf niemals überprüft oder verstanden werden, um die Sicherheit verschiedener Personen zu gewährleisten

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

Literatur-Empfehlungen:

19
Gilles

Die Angst, dass Ihr Produkt in umgekehrter Reihenfolge hergestellt wird, ist oft verlegt. Ja, es kann rückentwickelt werden. aber Wird es in kurzer Zeit so berühmt werden, dass es sich für Hacker lohnt, es rückgängig zu machen? (Dieser Job ist keine kleine zeitliche Aktivität für umfangreiche Codezeilen).

Wenn es wirklich ein Geldverdiener wird, sollten Sie genug Geld gesammelt haben, um es auf legale Weise zu schützen, wie Patent- und/oder Urheberrechte.

IMHO, treffen Sie die grundlegenden Vorsichtsmaßnahmen, die Sie treffen werden, und geben Sie sie frei. Wenn es sich um einen Reverse Engineering-Punkt handelt, der bedeutet, dass Sie wirklich gute Arbeit geleistet haben, werden Sie selbst bessere Möglichkeiten finden, diesen zu überwinden. Viel Glück.

12
iammilind

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

Mit modernen kryptografischen Techniken sollte es durchaus möglich sein, dass Ihr System offen ist (ich sage nicht, dass es offen sein sollte , genau so, wie es könnte be) und haben dennoch absolute Sicherheit, solange der kryptografische Algorithmus keine Lücke aufweist (nicht wahrscheinlich, wenn Sie eine gute auswählen), bleiben Ihre privaten Schlüssel/Passwörter privat und Sie haben keine Sicherheitslücken In Ihrem Code ( ist dies das, worüber Sie sich Sorgen machen sollten).

11
asmeurer

Seit Juli 2013 besteht ein erneutes Interesse an einer kryptografisch robusten Verschleierung (in Form von Indistinguishability Obfuscation), das sich aus der ursprünglichen Forschung von Amit Sahai zu ergeben scheint.

Sie können einige destillierte Informationen in diesem Quanta Magazine-Artikel und in diesem IEEE Spectrum-Artikel finden.

Gegenwärtig ist diese Technik aufgrund ihres Ressourcenaufwands unpraktisch, doch AFAICT ist der Konsens in Bezug auf die Zukunft eher optimistisch.

Ich sage das sehr beiläufig, aber für alle, die es gewohnt sind, die Verschleierungstechnologie instinktiv zu verwerfen - das ist etwas anderes. Wenn sich herausstellt, dass sie wirklich funktioniert und praktisch ist Dies ist in der Tat wichtig und nicht nur zur Verschleierung.

7
tne

Lesen Sie die akademische Literatur zu Code-Verschleierung, um sich zu informieren. 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 hinter dieser Literatur zurückgeblieben, 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, und es kostet einen Angreifer exponentielle Zeit (unter Verwendung der bekanntesten Techniken), um herauszufinden, welche Fragmente Ihres Codes ausgeführt werden und welche nicht.

7
Norman Ramsey

Es gibt eine kürzlich erschienene Veröffentlichung mit dem Titel " Programmverschleierung und Einmalprogramme ". Wenn Sie es wirklich ernst meinen mit dem Schutz Ihrer Anwendung. Die Arbeit 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 der gleichen Funktionalität und der gleichen Größe liefert. Die Arbeit zeigt jedoch, dass informationstheoretisch am besten ein Zusammenbruch der Polynom-Hierarchie impliziert.

Diese Papiere sollten Ihnen mindestens ausreichende bibliografische Hinweise geben, um in der zugehörigen Literatur nachzuschlagen, wenn diese Ergebnisse nicht für Ihre Bedürfnisse geeignet sind.

Update: Ein neuer Begriff der Verschleierung, der als ununterscheidbare Verschleierung bezeichnet wird, kann das Unmöglichkeitsergebnis abmildern (Papier)

6
M. Alaggan

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's auch schon. Wenn Sie wirklich etwas darüber lernen möchten, besorgen Sie sich eine Kopie von http://www.hex-rays.com/idapro/ und zerlegen Sie ein paar 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.

6
Brian Makin

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

  1. Ist es wahrscheinlich, dass "neue Benutzer" Ihre Software nicht bezahlen, sondern nutzen möchten?
  2. Ist es wahrscheinlich, dass bestehende Kunden mehr Lizenzen benötigen als sie haben?
  3. Wie viel sind potenzielle Nutzer bereit zu zahlen?
  4. Möchten Sie Lizenzen pro Benutzer/gleichzeitige Benutzer/Workstation/Firma 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, da:

  • Neue Benutzer werden durch das Preismodell angezogen (wenig Gebrauch -> wenig Bezahlung)
  • 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.

5
Black

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 über den Webservice für Ihre App bereitstellen. Natürlich ist dieses Szenario nicht immer möglich.

5
Lukasz Madon

Ich denke nicht, dass irgendein Code nicht gehackt werden kann, aber die Belohnungen müssen großartig sein, damit jemand es versuchen will.

Trotzdem 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 Assembly-Sequenz abzurufen, sondern auch darum, den Code zu verstehen und ihn in eine übergeordnete Sprache wie C zu portieren). Hoch optimierter Code kann ein b --- h sein, dem man folgen kann.
  • Machen Sie Strukturen dicht, indem Sie keine größeren Datentypen als nötig verwenden. Strukturelemente zwischen offiziellen Code-Releases neu anordnen. 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 Byte-Vektor "vwxyz" enthält, können Sie einen anderen Byte-Vektor mit "abcde" haben und die Unterschiede vergleichen. Der Funktion, die dies ausführt, 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) == irgendein 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.

4
Olof Forshell

Wie viele bereits sagten: Auf einer normalen CPU kann man sie nicht davon abhalten, 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 entwickelt, und oft werden FPGAs verwendet. Z.B. Die Virtex 5 FX haben eine PowerPC-CPU und Sie können die APU) verwenden, um eigene CPU-Opcodes in Ihre Hardware zu implementieren. Mit dieser Funktion können Sie die Anweisungen für den PowerPC wirklich entschlüsseln Kein Zugriff von außen oder von anderer Software oder Ausführen des Befehls in der Hardware. Da das FPGA eine AES-Verschlüsselung für den Konfigurations-Bitstream eingebaut hat, konnte es nicht rückentwickelt werden (außer es gelingt jemandem, AES zu beschädigen, aber dann haben wir es wohl andere Probleme ...). Auf diese Weise schützen Anbieter von Hardware-IP auch ihre Arbeit.

  2. Sie sprechen vom Protokoll. Sie sagen nicht, um was für ein 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 undebuggbar/nicht lauffähig. Versuchen Sie, eine Art Erkennung für das Debuggen zu verwenden, und wenden Sie sie z. in irgendeiner Formel oder Hinzufügen eines Debug-Register-Inhalts zu einer magischen Konstante. Es ist viel schwieriger, wenn Ihr Programm im Debug-Modus angezeigt wird, wenn es normal ausgeführt wird, aber eine völlig falsche Berechnung, Operation oder eine andere durchführt. Z.B. Ich kenne einige Öko-Spiele, die einen wirklich üblen Kopierschutz hatten (ich weiß, Sie möchten keinen Kopierschutz, 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 einzige Ressource . Der Pirat hat es gerade geknackt (d. H. 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 Entdeckung erscheinen, sondern nur verzögert.

Abschließend würde ich vorschlagen: Schätzen Sie den Gewinn, den die Leute durch das Reverse Engineering Ihrer Software erzielen, übersetzen Sie diesen in eine gewisse Zeit (z. B. indem Sie das billigste indische Gehalt verwenden) und veranlassen Sie das Reverse Engineering so zeitaufwendig, dass es größer ist.

4
flolo

Möglicherweise ist die beste Alternative immer noch die Verwendung von Virtualisierung, die eine weitere Ebene der Umgehung von Indirektion/Verschleierung einführt, aber wie SSpoke in seinem Antwort sagte, ist diese Technik auch nicht 100% sicher.


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

Was auch immer der Mensch zusammenbaut, kann zerlegt werden.

Normalerweise ist das (ordnungsgemäße) Zerlegen (ein bisschen oder mehr) eine schwierige Aufgabe, daher muss Ihr Gegner sein ) erfahrener , aber Sie können davon ausgehen, dass es immer jemanden von solcher Qualität gibt, und es ist eine sichere Wette.

Wenn Sie etwas gegen 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 Vorbeugung gegen Reverse Engineering, sondern zeigt Tonnen von Informationen darüber, wie man Reverse Engineering durchführt

zeige deine schlechte Einstellung. Ich sage nicht, dass man, um Schutz zu verwenden oder einzubetten, wissen muss, wie man ihn zerstört, aber um ihn mit Bedacht einzusetzen, sollte man seine Schwächen und Gefahren kennen. Sie sollten es verstehen .

(Es gibt Beispiele für Software, die den Schutz in falscher Weise verwendet, so dass ein solcher Schutz praktisch nicht vorhanden ist. Um ein vages Sprechen zu vermeiden, werde ich Ihnen ein kurz im Internet beschriebenes Beispiel geben: 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, Textverarbeitungs-Makros, Netzwerk , Schriften usw. )

Alles braucht Zeit.

Wenn Sie noch nicht mit dem Thema vertraut sind und nicht über Monate oder Jahre verfügen, um sich richtig mit RE zu beschäftigen, sollten Sie verfügbare Lösungen von anderen wählen. Das Problem liegt auf der Hand, sie sind bereits vorhanden, sodass Sie bereits wissen, dass sie nicht zu 100% sicher sind. Wenn Sie jedoch Ihren eigenen neuen Schutz einrichten, würden Sie sich nur dann falsch geschützt fühlen, wenn Sie nicht wirklich den neuesten Stand der Technik kennen Reverse Engineering und Schutz (aber Sie nicht, zumindest in diesem Moment).

Der Zweck des Softwareschutzes besteht darin, Neulinge zu erschrecken, gewöhnliche REs zu blockieren und den erfahrenen RE nach seiner (hoffentlich interessanten) Reise in das Zentrum Ihrer Anwendung ein Lächeln auf den Lippen zu zaubern.

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

(Schauen Sie sich die Präsentation von Nice an Silver Needle in the Skype von Philippe Biondi und Fabrice Desclaux auf Black Hat 2006).


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

Ich habe über Virtualisierung gesprochen, daher verweise ich auf einen beispielhaften Thread aus EXETOOLS FORUM : Bester Software-Protektor: Themida oder Enigma Protector? . Es kann Ihnen bei der weiteren Suche helfen.

4
przemoc

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 immer einen Speicherauszug einer geladenen ausführbaren Datei erstellen und ihn mit einem Disassembler wie IDA Pro zerlegen.

IDA Pro wird auch mit einem raffinierten Assembler-Code-zu-C-Quellcode-Umsetzer geliefert, obwohl der generierte Code eher wie ein mathematisches Durcheinander von Zeigern und Adressen aussieht. Wenn Sie ihn mit dem Original vergleichen, können Sie alle Fehler beheben und alles herausreißen.

4
SSpoke

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

4
Gallium Nitride

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 den Agenten nachweislich davon abhalten, solche Antworten zu erhalten.

Sie können dies tun, indem Sie sich auf das Halteprogramm ("Hält Programm X an?") Verlassen, das im Allgemeinen nicht gelöst werden kann. Das Hinzufügen von Programmen, über die Sie nur schwer nachdenken können, macht es für Sie schwierig, über die Sie nachdenken können. Es ist einfacher, solche Programme zu erstellen, als sie zu zerreißen. Sie können dem Programm auch Code hinzufügen, der unterschiedliche Schwierigkeitsgrade für die Argumentation aufweist. Ein guter Kandidat ist das Argumentationsprogramm für Aliase ("Zeiger").

Collberg et al haben eine Veröffentlichung ("Manufacturing Cheap, Resilient and Stealthy Opaque Constructs"), die diese Themen behandelt und eine Vielzahl von "opaken" Prädikaten definiert, die es sehr schwierig machen können, über Code zu argumentieren:

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

Ich habe Collbergs spezifische Methoden für den Produktionscode nicht gesehen, insbesondere nicht für 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/

3
Ira Baxter

Sicherheit durch Dunkelheit funktioniert nicht, wie Menschen viel schlauer zeigen 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 umfassend geprüft wird.

Dies gilt für den Fall, dass Personen den Code einsehen können. Wenn Ihre Anwendung auf einem eingebetteten Mikroprozessor ausgeführt werden soll, können Sie einen mit einer Versiegelungsfunktion auswählen, 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. (Mit Ausnahme von Hardware-Invasionstechniken können Sie den Chip sorgfältig zerlegen und mithilfe fortschrittlicher Geräte die Ströme einzelner Transistoren überprüfen.)

Ich bin der Autor eines Reverse Engineering Assemblers für den x86. Wenn Sie zu einer kalten Überraschung bereit sind, senden Sie mir das Ergebnis Ihrer Bemühungen. (Kontaktieren Sie mich über meine Websites.) Wenige, die ich in den Antworten gesehen habe, stellen eine erhebliche Hürde für mich dar. Wenn Sie sehen möchten, wie hochentwickelter Reverse Engineering-Code funktioniert, sollten Sie Websites mit Reverse Engineering-Herausforderungen genau untersuchen.

Ihre Frage könnte eine Klarstellung gebrauchen. Wie können Sie ein Protokoll geheim halten, wenn der Computercode für Reverse Engineering geeignet ist? Wenn mein Protokoll das Senden einer RSA-verschlüsselten Nachricht (sogar eines öffentlichen Schlüssels) wäre, was bringt es Ihnen, wenn Sie das Protokoll geheim halten? Für alle praktischen Zwecke würde ein Inspektor mit einer Folge von Zufallsbits konfrontiert.

Groetjes Albert

Im Gegensatz zu dem, was die meisten Leute aufgrund ihrer Intuition und persönlichen Erfahrung sagen, halte ich eine kryptografisch sichere Programmverschleierung im Allgemeinen 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);

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

Obwohl das Papier beweist, dass die Verschleierung, durch die das Programm nicht von der von ihm implementierten Funktion unterschieden werden kann, unmöglich ist, kann eine Verschleierung, die auf eine schwächere Weise definiert wurde, dennoch möglich sein!

3
Rotsor

Hat jemand versucht CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Oder Themida: http://www.oreans.com/themida_features.php ?

Später sieht man vielversprechender aus.

2
AareP

ERSTE ERINNERUNG ZUM VERSTECKEN IHRES CODES: Nicht jeder Code muss ausgeblendet sein.

THE END GOAL: Mein Endziel für die meisten Softwareprogramme ist die Möglichkeit, verschiedene Lizenzen zu verkaufen, mit denen bestimmte Funktionen in meinen Programmen aktiviert und deaktiviert werden.

BESTE TECHNIK: Ich finde, dass das Einbinden eines Systems von Hooks und Filtern wie WordPress) die absolut beste Methode ist, um Ihre Gegner zu verwirren bestimmte Trigger-Assoziationen 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 das: Der Hauptgrund für das Knacken von Code ist nicht die böswillige Verteilung von Lizenzen, sondern die Notwendigkeit, Ihren Code zu ändern, und die Notwendigkeit, kostenlose Kopien zu verteilen.

ERSTE SCHRITTE: Legen Sie die kleine Menge an Code, die Sie verschlüsseln möchten, beiseite. Der Rest des Codes sollte versucht werden, in EINER Datei gespeichert zu werden, um die Komplexität und das Verständnis zu erhöhen.

VORBEREITUNG ZUM VERSCHLÜSSELN: Sie werden mit meinem System in mehreren Ebenen 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. Anschließend müssen Sie den verschleierten Code base64 und in einer temporären Datei speichern, 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 das Ende verwendet wird Benutzer.

SCHRITT DREI: Wiederholen Sie Schritt zwei so oft, wie Sie möchten. Sobald dies ohne Entschlüsselungsfehler funktioniert, werden Sie anfangen wollen, Landminen für Ihre Gegner zu bauen.

LAND MINE ONE: Sie werden die Tatsache, dass Sie benachrichtigt werden, geheim halten wollen. Bauen Sie also ein Sicherheitswarn-Mail-System für den Cracker-Versuch für Schicht 2 ein. Dieses wird ausgelöst, um Sie über die Einzelheiten Ihres Gegners zu informieren, falls etwas schief gehen sollte.

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

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

ZU ERINNERNDE DINGE: Sie können Ihren Code tatsächlich verschlüsseln, anstatt ihn zu base64en. Auf diese Weise entschlüsselt ein einfacher base64 das Programm nicht.

INVOICE : Denken Sie daran, dass dies tatsächlich eine symbiotische Beziehung zwischen Ihnen und Ihrem Gegner sein kann. Ich setze immer einen Kommentar in die erste Ebene, der Kommentar gratuliert dem Cracker und gibt ihm einen Gutscheincode, den er verwenden kann, um eine Geldprämie von Ihnen zu erhalten.

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

VIEL GLÜCK!