Source Code verschlüsseln

**mensch72**

https://www.oreans.com/CodeVirtualizer.php

so als "kleine Hürde" kommt das dem von dir gesuchtem schon sehr nah

Allerdings solltest du deine "Rezepte" irgendwie separieren und auslagern.
Ob via DLL's, oder moderner via Multi-Tier-Architektur in verschiedene Programme/Dienste, welche z.B. native per RPC/IPC oder standardisiert per JSON/REST kommunizieren... Hauptsache alles "NonPublic" ist separiert und einfach austauschbar auch gegen ein Dummy(also geheime Rezepte für VitaCola,CocaCola,PepsiCola PLUS plublic Apfelschorle)

**Moombas**

Ich kenne eure Strukturen nicht aber was ist, wenn diese "geheimen Code Zeilen" (Dateien, or what ever) nur dem "vertrauten Team" zur Verfügung stehen und diese dann entsprechend nur die komplette Kompilierung durchführen können!?
Der Rest des Teams kann ja an seinen Modulen arbeiten, muss für eine ggf. Funktionsprüfung (sofern der geheime Teil zur Funktionsprüfung gebraucht wird), auf diese Personen zurück greifen.

**jaenicke**

Wenn diese geheimen Units andere Units verwenden, die wiederum jeder im Team ändern können sollte, bleibt nur ein Buildserver wie Jenkins als sinnvolle Variante. Der kompiliert die betreffenden Units und stellt sie als .dcu bereit, z.B. in einem eigenen Repository. Dann kann jeder diese Units als kompilierte Units einbinden oder mit entsprechenden Zugriffsrechten als Quelltext. Die Unterscheidung kann dann einfach über den Bibliothekspfad gemacht werden.

Das Konzept muss noch einmal genau durchdacht werden, aber vom Grundprinzip her sollte es so funktionieren.

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

**IBExpert**

Zitat von Sherlock:

ZWer Leute einstellt, denen er nicht vertrauen kann, macht an der Stelle bereits einen Fehler.
Sherlock

Da kann ich dir von diversen Kunden und sogar von ehemaligen eigenen Mitarbeitern
durchaus interessante Geschichten erzählen, aber garantiert nicht hier ...

Es ist auch nicht so, das immer nur der unten in der Hierarchie das A...loch ist und mit
seinem Know How abhaut, oft ist es auch ein Wechsel in der Geschäftsführung, die den
Chefarchtekt hinter einer gesamten Softwarelösung in die Selbstständigkeit treiben
und warum sollte dieser sein Branchen Know How nicht woanders einsetzen, verträge
hin oder her ....

**WladiD**

Was spricht gegen diese Struktur im Repository?:

markieren

Code:

			ColaLib\

- Source\ > Source.7z mit Passwort

- ColaLib.dcu (für alle)

- BuildColaLib.bat

Das Passwort bekommen nur ausgewählte Entwickler und diese können die DCUs mittels der BuildColaLib.bat auch jederzeit erzeugen und im Repository aktualisieren.

Wenn Änderungen am ColaLib\Source durchgeführt wurden, muss die Source.7z neu erstellt (z.B. über eine Batch) und wieder eingecheckt werden. Diese Vorgehensweise hätte auch den Vorteil, dass das Source.7z auch versioniert wäre.

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

**Hobbycoder**

Zitat von IBExpert:

Es ist auch nicht so, das immer nur der unten in der Hierarchie das A...loch ist und mit
seinem Know How abhaut, oft ist es auch ein Wechsel in der Geschäftsführung, die den
Chefarchtekt hinter einer gesamten Softwarelösung in die Selbstständigkeit treiben
und warum sollte dieser sein Branchen Know How nicht woanders einsetzen, verträge
hin oder her ....

Nicht selten werden Mitarbeiter, die über entsprechendes internes Wissen verfügen, genau deswegen von anderen Firmen oder Konzernen für viel Geld abgeworben.

**jfheins**

Also die ganz wesentlichen Maßnahmen wurden hier ja schon angerissen:
- Nur Kompilate verteilen
- Obfuscator (gibt es bestimmt auch schon fertig

)

Ich würde da aber immer dazu raten, das ordentlich zu versionieren. Also bspw. mit einem eigenen git. Da hast du dann im großen Repo das Rezept auf einer bestimmten Version. Und sobald eine "Rezeptänderung" nötig ist, wird das Rezept (in einem anderen Repo) weiterentwickelt und die dcus können dann ins große Repo kopiert werden.

Statt dcu geht natürlich auch hässlicher Code, da braucht dann die Build-Pipeline den Obfuscator und das kommt als Artefakt raus.

Zitat:

ColaLib\
- Source\ > Source.7z mit Passwort
- ColaLib.dcu (für alle)
- BuildColaLib.bat

Davon würde ich abraten. Irgendwann verlässt ein Passwort-kenner die Firma, erzählt seinem Ex-Kollegen das Passwort damit er auch mal schauen kann ...