Source Code verschlüsseln

[IBExpert]

Zitat von OlliWW:

Hallo Zusammen,
Ich denke wahrscheinlich gibt es keine Lösung dafür, aber ich frage trotzdem mal
Wir sind ein relativ großes Team von Entwicklern, die in Delphi an einer großen Software entwickeln. Das Projekt wird per SVN verwaltet. Da einige Programmbereiche unser "Cola-Rezept" enthalten, möchte ich ungern, dass der Quellcode dieser Stellen für alle Entwickler sichtbar ist.

so als Idee mal das was wir für einen sehr großen Konzern mit dem quellcode gemacht haben, auf den er meinte, zwar das Recht zu haben, diesen zu bekommen, obwohl er nicht den vollen Angebotsbetrag zahlen wollte und wir die voll funktionale delphi exe schon ausgeliefert hatten. Nachdem es einen Meinungsaustausch mit dem Projektverantwortlichen gab (vorher hatte der seine Meinung, nachher hatte der meine Meinung), haben die dann doch voll bezahlt und wir brauchten das nicht mehr, war aber damals schon einsatzbereit, hab ich aber leider nicht mehr ohne intensive suche. Die Motivation war aber ja im Endeffekt eine andere, und es ist auch keineswegs unentschlüsselbar, aber jemand der das komplett verstehen will, braucht dafür schon einiges an zeit und aufwand.

wir haben da (vor ca 17 Jahren, aber das geht gfg noch ähnlich heute) folgendes gemacht

Im prinzip war das ganze ein Non standard obfuscator/uglifier oder wie auch immer man das nennt.

1. Alle eigennamen (variablen, eigene typen, konstanten, functions, procedures) wurde aus dem quelltext ausgelesen und in eine Datenbank gepackt (mit referenz, wo das denn herkommt usw, was ein wenig tüftelei, aber war die mühe und den Spaß wert).
2. Diese Eigennamen wurde dann durch möglichst kurze ersetzt, die mit random funktionen erzeugt wurden aus 1.zeichen a-z, rest immer a-z+0-9 und dann per suchen/ersetzen im gesamten Quellcode
3. sämtliche Stringkonstanten aus dem code wurde ersetzt durch eine funktion, die eine random key mit einer damit erzeugten hex konstante für den eigentlichen String als parm bekommt, die decode function dazu hatte ein bekannter in fiesem inline assembler erstellt, die war dann natürlich im code enthalten, aber für leute mit durchschnittsknow how nicht verständlich
4. sämtliche zeilenvorschübe wurde da wo es die Pascalsyntax zulässt entfernt und an abstrusen anderen stellen wieder ergänzt. Die maximale codezeilenlänge wurde fast immer ausgenutzt, so das teilweise 4-5 befehle in einer zeile waren
5. sämtliche kommertare (auch die automatisch erzeugten) wurde entfernt, dafür würde abstruse kommentare aus einem lexikon ergänzt
6. Während ich das gebaut hab, habe ich immer wieder die Aufrufsyntax und Darstellung der Software geprüft, es war am Ende immer noch funktional identisch zu dem was der original quellcode erzeugt hatte
7. einige andere typische sprachelemente wurde dann auch ncoh vergewaltigt oder ergänzt, variableninhalte würden ziemlich sinnlos verändert, also hochgerechnet, danach irgendwann vor der nächsten echten benutzung wieder runter usw.

der weiterhin compilierbare quellcode machte das gleiche was das gesamte Projekt machte, liess sich aber ähnlich gut lesen wie direkter hex code der exe, ich hatte das einem
Bekannten gezeigt mit sehr guten Delphi Kenntnissen und der sagte, das wäre für ihn keine chance, da auch nur irgendwas drin zu verstehen, geschweige denn sinnvoll zu debuggen und das war ja das ziel

trotzdem hätte damit jemand bei entsprechendem Aufwand eine Version erzeugen können, die wieder mehr oder weniger benutzbar ist.

Wenn es aber um Teamwork geht und nicht darum, voll compilierbaren unverständlichen sourcecode zu haben, dann würde ich die sensiblen Units halt gar nicht als pas verfügbar machen, sondern nur als dcu, das würde den o.a. aufwand ersetzen und ist seit jahren von Komponentenherstellern ein bewährstes verfahren, wird ja auch von einigen hier so vorgeschlagen.

[Uwe Raabe]

Zitat von IBExpert:

2. Diese Eigennamen wurde dann durch möglichst kurze ersetzt, die mit random funktionen erzeugt wurden aus 1.zeichen a-z, rest immer a-z+0-9 und dann per suchen/ersetzen im gesamten Quellcode

Mit halbwegs aktuellen Delphi-Versionen kann man auch Unicode-Zeichen als Bezeichner verwenden. Da sind immerhin schon eine ganze Menge an Bezeichnern, die man dann mit nur einem Character ersetzen kann.

[himitsu]

Es gibt auch mehrere "Leerzeichen", die Delphi falsch einordned (als normale "Buchstaben") und somit kann man sogar unsichtbare Bezeichner erstellen.
Aber ja, sowas Chineisch oder Arabisch macht sich seit 11 Jahren auch besonders gut.

Und es gibt ein paar Zeichen die im Debugger die Zeilenzuordnung durcheinander bringen.
Einige fanden das schon nervig, aber hier wäre es zu praktisch, wobei man erstmal sämtliche Debuginfos und die erweiterte RTTI hier so schön abschalten sollte.

[Benmik]

Zitat von IBExpert:

Wir haben da (vor ca 17 Jahren, aber das geht ggfs. noch ähnlich heute) Folgendes gemacht...

Wenn ich die Charakterstruktur von Programmierern bisher richtig kennen gelernt habe, dann ist dies ein unwiderstehlicher Anreiz, diese Abwehr zu knacken, auch für solche Leute, die ursprünglich gar kein Interesse am Geheimnis an sich hatten. Eine ganze Reihe der Maßnahmen kann man ohne Mühe durch einen einfachen Code-Formatierer wieder beseitigen. Dann noch ein paar kleine Helferlein geschrieben... Also, dieser Schuss könnte nach hinten losgehen.

[IBExpert]

Zitat von Benmik:

Eine ganze Reihe der Maßnahmen kann man ohne Mühe durch einen einfachen Code-Formatierer wieder beseitigen. Dann noch ein paar kleine Helferlein geschrieben... Also, dieser Schuss könnte nach hinten losgehen.

bei komplexen Programmen ist aber ein großer Teil der Lernkurve damit verbunden, aus den Bezeichnungen Zusammenhänge herzustellen. Sicher gibt es Leute die Assembler im Kopf verstehen und ausführen können, aber die sind selten und auch die stützen ihr wissen auf bekannte Bezeichner.

Wenn du ein Beispielcode von irgendjemanden hier im Forum liest, dauert es wenige Sekunden, anhand der Bezeichner die Idee zu verstehen, was der Autor damit sagen will.

Wenn dir aber alleine dieser Bezug schon komplett durch unwiederbringliche Abkürzungen genommen wird, hilft dir der codeformatter nur dabei, das zum Teil wieder in passende Zeilen zu verteilen, aber die sind auch nicht alle perfekt (wir haben einen in IBExpert für sql und der macht je nach Einstellung manchmal sogar weniger lesbare ergebnisse als vorher, wer der ursprungscode seltsame geschrieben ist und sql hat auch noch ziemlich wenige Sprachelemente).

In irgeneiner exe mal eben die passende Stelle der Lizenzabfrage zu finden und aus einem assmeber hex code jump equal einen hex code jump not equal zu machen, ist für einen Profi eine Lachnummer, wenn man freundlicherweise direkt nach dem Lizenzcheck per showmessage meckert, das die software nicht lizensiert ist. Das ist sicherlich auch das was viele reizt, zu knacken, ohne auch nur irgendein Interesse an der eigentlichen software zu haben (wir waren selber oft genug opfer, wehren uns dagegen auch nur auf andere Art und Weise, die wir so gar nicht erklären )

Ich glaub aber nicht das der Threadautor so was banales verbergen will, weil wenn das deren Geheimnis ist, dann ist das begrenzt schützenswert.

Wenn das aber wie bei einem Kunden früher mal ein komplett in Pascal geschrieben modul ist mit extrem komplexen mathematischen Routinem zur Brillenglasberechnung, die für das Unternehmen mal ein Professor noch in Turbopascalzeiten geschrieben hat und den man auch nicht im realen Quellcode komplett verstanden hat (ich jedenfalls nicht, hab aber auch nicht die Lust und Zeit dazu gehabt, weil ich es nur compilieren musste über mit den Auftragsdaten aufrufen musste, war das ziemlich egal).

Ein erfahrener Mathamtiker/Optiker hätte sicher anhand der Bezeichnungen das ganze nachvollziehen, verbessern oder an neue Anforderungen anpassen können und nicht so gruselige Workarounds da eingebaut (die da wirklich drin waren): if kunde = xxx then dicke muss größer als 2 sein o.ä. In dem Moment wenn du aber keinen einzigen Bezeichner im Code verstehst, hast du kaum eine Chance, solche wenn auch miese Lösungen an die richtige Stelle da einzubauen.