Wie schütze ich Konstanten vor Disassembler?

... komplette Frage anzeigen

4 Antworten

Lies dir mal bitte meine Kommentare auf die anderen beiden Antworten durch. :)

Kurz gesagt: Vergiss es. Es gibt nichts, aber auch GAR nichts, was verhindern wird, dass jemand deine Variablen / Konstanten ausliest.

Du kannst die Arbeit zwar (enorm) erschweren, aber wenn dein Programm für eine gewisse Gruppe von Leuten wichtig oder sehr beliebt ist, dann WERDEN die Werte ausgelesen, und das kannst du leider nicht verhindern ... schon gar nicht mit C#, was sich vieeeel leichter knacken lässt, als "echter" Maschinen-Bytecode. (wobei dieser auch nicht schwierig ist) :)

Wenn du ein unglaublicher Crack bist und wirklich viel Ahnung hast, und dir wirklich eine Methode überlegst, die noch unbekannt ist, wird es dennoch binnen Wochen irgendwelchen cleveren Leuten gelingen, deine Methode zu umgehen. Ist deine Software hingegen nicht wichtig genug und nur für ein kleineres Publikum interessant, lohnt sich der Einbau von Sicherheitsmaßnamen auch nicht.

Anti-Crack-Methoden gehen fast immer nach hinten los, und nerven ehrliche Kunden. (Lizenzschlüsseleingabe, Programmabstürze, etc.)

Du könntest auf kommerzielle (und teure) Kopierschutzsysteme - wie z.B. Themida - zurückgreifen, die auf ihrer Website (Link!) gaaaanz tolle Sachen versprechen.

Solche Software verspricht generell und immer was ganz Tolles! Und zwar, so lange ich mich daran erinnern kann, seit 1993 ... und sie wurden alle geknackt!

"Sie wurden alle geknackt", bedeutet, dass innerhalb von Tagen (spätestens Wochen) ein sog. Unpacker im Netz verfügbar war, mit dem man dann mit ein paar Klicks, die Original EXE Datei entpacken und erfolgreich disassemblieren konnte.

Lies dir ruhig mal durch, was alles für versprechen auf der Themida Website stehen. Da denkt man doch erst mal: "Boah, das ist DIE Lösung ... will ich haben!", oder? Behalte aber im Hinterkopf, dass es für JEDE Themida Version, die jemals erschienen ist, innerhalb von Tagen Unpacker gab! Auf Youtube erklären Skript-Kiddies sogar deren Funktionsweise, und führen diese vor ... tja, SO einfach ist das. :)

Wobei ich sagen muss, dass diese kommerziellen Kopierschutzsysteme echt sehr intelligente und gute Ansätze haben! Das Problem an der Sache ist, man kann sie ALLE leicht umgehen kann! :)

Ach so, und Themida hat noch das Problem und ist absolut paranoid. Wenn auf dem Rechner bereits "nur" ein Hexeditor installiert ist, denkt Themida, dass es geknackt werden soll, und startet den Rechner neu. Wie du siehst, haben diese Kopierschutzmechanismen nur Nachteile, nerven ehrliche Kunden, sind keine Hürde für Cracker, kosten Geld und sorgen für eine instabile Ausführung des Programms, was dann zu Supportanfragen der Kunden führt und somit auf beiden Seiten direkt oder indirekt Kosten verursacht!

Also ... Kopierschutzmechanismen selbst ausdenken bringt nichts, da die zu 99% vermutlich zu primitiv und schon lange bekannt sind, was bedeutet, dafür gibt es Skripte, die den eigenen "Kopierschutz" automatisch entfernen. Und von den kommerziellen brauchen wir gar nicht erst zu reden ... die sind einfach zu populär und es ist ein Volkssport unter Hackern, wer den ersten Unpacker für Version X.Y.Z veröffentlicht.

Hör auf, darüber nachzudenken und investiere deine Zeit lieber in die Entwicklung deiner Software, ins Debuggen und in neue Features, anstatt das Rad mit einem tollen Kopierschutz neu zu erfinden, der sowieso nichts bringt. :)

Ich weiß, das ist ne harte Erkenntnis und viele Entwickler sträuben sich, das zu glauben, aber disassemblierter Code liest sich für erfahrene Augen wirklich sehr schnell und klar und verständlich lesbar. Reverse Engineering können zwar nur die wenigsten, aber DIE die diese Kunst beherrschen, sind in der Regel echt gut darin! Also glaub nicht, dass du solche Leute effektiv herausfordern kannst. :)

In Insiderkreisen gibt es sogenannte "CrackMes" ... das sind Programme, die einen Text, eine Zahl oder ein Bild verbergen, und die man knacken muss, um an die Informationen zu kommen. Die werden VON Crackern FÜR Cracker zu Übungszwecken geschrieben, und es gibt ganze Websites, die sich ausschließlich diesen CrackMes widmen.

Dort sind oft Ansätze vertreten die viiieeeelll besser sind, als alle anderen Kommerziellen, die ich jemals gesehen habe! Und nicht EIN EINZIGES davon blieb ungeknackt!

Fakt ist: Bis heute gibt es KEIN EINZIGES CrackMe, welches nicht geknackt wurde!!! Das musst du dir mal auf der Zunge zergehen lassen!

Die Dinger wurden von absoluten Insidern geschrieben und benutzen alle noch so fiesen Tricks, um das Knacken zu verhindern ... dennoch sind selbst die schwierigsten nach 2 Wochen gebrochen. (sofern genügend Interesse besteht und die Community groß genug ist)

Also nochmal: Denk nicht, dass du irgendjemanden davon abhalten kannst, deine Variablen und Konstanten auszulesen! Investiere die Zeit in etwas Sinnvolles FÜR dein Programm und nicht GEGEN Cracker ... es bringt einfach nichts! :)

Antwort bewerten Vielen Dank für Deine Bewertung
Kommentar von TeeTier
01.07.2014, 02:58

PS: Egal, was du im Internet für Kopierschutzsysteme oder -maßnahmen findest, such einfach mal bei Google nach "XYZ unpacker", "XYZ crack", "disassemble XYZ", oder so ... wobei XYZ für den von dir gefundenen Kopierschutz steht.

Wenn du vernünftig suchst, wirst du IMMER fündig werden! Es sei denn, der Kopierschutz ist erst ein paar Tage alt ... dann musst du u.U. zwei bis drei Wochen warten und dann deine Suche wiederholen. :)

0

Wenn es nur darum geht, das fertige Programm zu schützen, ist es nicht allzu schwer.

Eine String-Variable (oder irgend etwas anderes) kannst du in einen Byte-Array umwandeln.

Dann nimmst du einen zweiten Byte-Array (gleicher oder besser größerer Länge - bei größerer Länge musst du die Nutzlänge irgendwo notieren) und füllst den mit Zufallswerten auf.

Diese beiden Arrays verknüpfst du mit XOR und speicherst sie in einem dritten Array.

Den zweiten und dritten Array kannst du hartkodiert in den Code einsetzen. Wenn der zweite Array wirklich zufällig ist, gibt es keine Möglichkeit, aus einem der beiden Arrays auf den ursprünglichen zurückzuschließen. Und zu finden, wo bedeutsame Arrays aus Zufallsbytes im fertigen Programm sind, ist fast unmöglich.

Was den Disassembler betrifft: Da hilft wohl nur Spaghetti-Code, eine kompliziertere Umschreibung der XOR-Operation (oder mehrere, die wahlweise genommen werden) und Anwenden der XOR-Operationen in einer anderen Reihenfolge sowie zeitlich geteilt. Womöglich noch auf mehrere Threads aufgeteilt.

Antwort bewerten Vielen Dank für Deine Bewertung
Kommentar von TeeTier
01.07.2014, 02:13

Das, was du hier beschreibst, und zusätzlich noch wesentlich clevere Obfuscation-Methoden, sehe ich oft in disassembliertem Code.

Das Problem an der Sache: Es bringt nichts! :)

Es macht wirklich nur mehr Arbeit für den Entwickler, als für den, der das Programm knacken will.

Die von dir beschriebene Methode ist so ausgelutscht, dass man die beim ersten Versuch mit einem Standardskript entdecken und dekodieren können sollte.

Mehraufwand für den Entwickler: 15 Minuten! Mehraufwand für den Hacker: ~30 Sekunden?!?!

Es bringt nichts ... :)

1

TeeTier hat sich ja schon ausgiebig und zur Genüge ausgelassen, aber auch ich möchte noch ein wenig meinen Senf dazu ablassen.

Die wesentliche Frage ist imho: Gegen wen willst du das Programm schützen?

  • Ist es ein privates Programm und du willst nur nicht, dass der neugierige kleine Bruder/die kleine Schwester unbefugten Zugriff erhält?

Dann kann u.U. eine einfache Passwortabfrage mit hart codiertem Gegenschlüssel ausreichen (außer der Bruder/die Schwester kann mit einem Hexeditor umgehen, dann sollte etwas mehr Aufwand betrieben werden).

  • Geht es um ein Programm, bei dem nicht einfach jeder Büro-Schlurf, der mal ein VBA-Makro programmiert hat, Zugriff erhalten soll?

Dann kann eine Verschlüsselung wie von PWollf beschrieben auch noch funktionieren. Nennt sich "security through obscurity" und funktioniert gegen Leute, die bei 3 Seiten Source schon glasige Augen bekommen. Ist die unsicherste Methode, dafür aber auch ohne echten Mehraufwand zu implementieren.

  • Willst du dein Programm gegen Leute absichern, die einigermaßen sicher mit einem PC umgehen können und auch in der Lage sind, mit einem (Hex-) Editor compilierte Dateien zu öffnen und einigermaßen scrubben zu können (z.B. Informatik-Erstsemester, MTAs etc.)?

Dann lässt sich vielleicht noch etwas mit zusammengesetzten Gegenschlüsseln, Staffelung von ROT- und Vigenére-Chiffre und verteilter Datenhaltung im Speicher in einem Junkfeld was erreichen. Aber bereits da ist zu bedenken, ob sich der Aufwand überhaupt noch lohnt.

  • Willst du dein Programm gegen "einfache" Cracker absichern?

Dürfte nur noch mit staatlicher Subventionierung im militärischen oder nachrichtendienstlichen Bereich funktionieren. Denn Cracker können dein Programm relativ gut zerlegen. Das Szenario ist aber uninteressant, da du von C# geschrieben hast und das ist dafür zu 100% ungeeignet. Auf diesem Level greifen ganz andere Mechanismen, sowohl hardware- als auch softwareseitig.

  • Soll dein Programm gegen jeden Angriff gesichert sein?

Vergiss es. Da greift das, was TeeTier geschrieben hat. Alleine der Versuch ist vergebene Liebesmüh.

Antwort bewerten Vielen Dank für Deine Bewertung

Der fehler liegt bei .net ... Bytecodesprachen wie .net sind wesentlich einfacher zu decompillen als Mascheinencode (soweit ich mich erinnern kann)

Antwort bewerten Vielen Dank für Deine Bewertung
Kommentar von TeeTier
01.07.2014, 02:17

Also ich habe i.d.R. keinerlei Probleme damit, disassemblierten Bytecode flüssig und schnell zu lesen. Wenn man Erfahrung hat, liest man so etwas fast so schnell, wie normale C-Sourcen. (Gut, vielleicht 3 mal langsamer ... aber nicht mehr!)

Bei den Sprachen, die in IL kompiliert werden ist es aber - wie du schon angesprochen hast - so unglaublich einfach, wieder einen Quelltext daraus zu machen, da nützt jegliche "Verschleierung" nichts.

Sogar die gängigen Obfuscatoren bringen da nicht wirklich viel. :)

Wenn jemand an die Daten rankommen will, dann kommt er daran. Da kann man sich die Kopfstände auch gleich sparen. :)

1

Was möchtest Du wissen?