Ausführbare Datei 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 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?

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.

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.

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.

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.

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.

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:

• Die Sicherheitsbibel: Security Engineering von Ross Anderson
• Die Verschleierungsbibel: Schleichsoftware von Christian Collberg und Jasvir Nagra

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.

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).

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 .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Verschleierung der Kandidatenunterscheidbarkeit und funktionale Verschlüsselung für alle Schaltkreise (21. Juli 2013).
• Sahai, Waters, Verwendung der Ununterscheidbarkeitsverschleierung: Verleugnbare Verschlüsselung und mehr .
• Sahai, Barak, Garg, Kalai, Paneth, Schutz der Verschleierung vor algebraischen Angriffen (4. Februar 2014).

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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!

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

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/

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!

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

Später sieht man vielversprechender aus.