Source Code verschlüsseln

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

Welche Möglichkeiten habe ich, bestimmte Units für andere Entwickler nicht sichtbar zu machen.

Ich habe mir folgendes überlegt:
Ich könnte bestimmte Berechnungen / Algorithmen in DLLs auslagern, deren Quellcode nur ein erlesener Kreis hat. Oder ich könnte im SVN nur die DCUs einchecken und die PAS Dateien einbehalten. Beides ist aber relativ schlecht, da die Methoden sehr viele Abhängigkeiten zum Rest des Quellcodes haben. Wenn sich die Signatur von anderen genutzten Objekten ändern würde, wäre die DCU nicht mehr kompatibel. Die Idee mit der DLL hätte den Nachteil, dass ich Sachen wie Datenbankconnections übergeben muss und das wird auch eher schwierig.

Vielleicht gibt es ja ein Howto oder Tool mit dem ich mein Ziel erreichen kann.

Viele Grüße und vielen Dank!

[himitsu]

Quellcode verschlüsseln geht garnicht, denn der Compiler soll das ja lesen können,
wobei ein bewisses Maß an durch Obfuscation möglich ist, was sich aber natürlich entziffern/entschlüsseln lässt.

Klar, man kann den Code als DCU, BPL oder DLL kompileren und den Quellcode garnicht erst im "offenen" Repository verteilen, sondern nur die Compilate.



ABER, dennoch sollte dir bewusst sein, dass es bedingt möglich ist jeden kompilierten Code auch zu disassemblieren/decompilieren.

[sakura]

Zuerst, zugegeben, dass ich keine Ahnung von Cola-Rezepturen habe, aber sollten die sich nicht nicht ständig ändern? Wenn das nur eine Wortnutzung war, dann immer noch die Frage, welche Parameter sich denn ständig in eurer Geschäftslogik ändern, dass diese so schnelllebig sind, dass die sich nicht relativ leicht kapseln lassen.

Zitat:

Zitat von OlliWW (Beitrag 1466674)

da die Methoden sehr viele Abhängigkeiten zum Rest des Quellcodes haben. Wenn sich die Signatur von anderen genutzten Objekten ändern würde

Stichworte wären hier die Patterns: Builder (GoF, 97), Facade (GoF, 185) und ggf. Chain of Responsibility (GoF, 223).

Zitat:

Zitat von OlliWW (Beitrag 1466674)

dass ich Sachen wie Datenbankconnections übergeben muss und das wird auch eher schwierig.

Spannende Frage wäre, wieso müssen Berechnungen auf die DB zugreifen, eine saubere Kapselung sieht vor, das solch ein Teil der Businesslogik gar nicht mit persistenten Daten arbeiten würde. Die reine Berechnung sollte immer vollständig mit bereit gestellten Daten arbeiten, nur so lässt diese sich auch gut testen.

...:cat:...

GoF: Design Patterns, Elements of Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (ISBN: 9780201633610)

[TigerLilly]

Muss das Cola Rezept selbst verfügbar sein? Genügt vielleicht ein Interface? Stubs? Mocks?

(BTW: Das Cola-Rezept ist eines der am besten erforschten und bekanntesten Rezepte.)

[Sherlock]

Zeit, Energie und am Ende sogar Geld in sowas zu verschwenden ist...nunja, Verschwendung. Wer Leute einstellt, denen er nicht vertrauen kann, macht an der Stelle bereits einen Fehler.

Sherlock

[sakura]

Zitat:

Zitat von Sherlock (Beitrag 1466686)

Zeit, Energie und am Ende sogar Geld in sowas zu verschwenden ist...nunja, Verschwendung. Wer Leute einstellt, denen er nicht vertrauen kann, macht an der Stelle bereits einen Fehler.

Ich denke, gerade wenn es um Firmengeheimnisse geht, dann ist es ein Fehler einfach jedem zu vertrauen. Und es ist auch nicht nötig. Von daher kann ich den Grund gut verstehen. Schließlich kann man in ein, zwei Job-Interviews niemals einen Menschen komplett kennen lernen. Je nach Branche werden auch Leute bewusst eingeschleust, um Firmengeheimnisse auszuspähen, von daher kann ich Deinen Beitrag überhaupt nicht nachvollziehen.

...:cat:...

[Sherlock]

Echt? So schlimm ist das? Und Reverse Engineering zieht man nicht in Betracht? Dann nehme ich alles zurück und behaupte das Gegenteil.

Sherlock

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