Source Code verschlüsseln

[TigerLilly]

Es gibt sicherheitskritische Anwendungen, bei denen sowas üblich ist. Oder auch vom Kunden vorgeschrieben. Aber auch im Glückspielsbereich ist das so.

[Sherlock]

Im Glücksspielbereich? Da würde ich eigentlich Quelloffenheit vorschreiben, um sicherzustellen, daß die versprochenen Chancen tatsächlich gegeben sind. Aber das ist wohl nicht mehr das Thema. Sorry.
In meinem Feld, den Medizinprodukten, ist das anspruchsvolle nicht die Entwicklung, sondern die Dokumentation, und Normkonformität. Und die beiden letzteren Punkte sind ohnehin in großen Teilen einsehbar.

Sherlock

[OlliWW]

Hallo,

Vielen Dank für die zahlreichen Antworten.

Ich bin mir sehr bewusst darüber dass nichts "sicher" ist und dass man alles reversen kann bzw. analysieren kann. Es wäre aber trotzdem schön, wenn man zumindest eine Hürde einbauen könnte. Ich hatte gedacht vielleicht gibt es Compiler / IDE Erweiterungen die soetwas können.

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

[WladiD]

Was spricht gegen diese Struktur im Repository?:

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.