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 von OlliWW:

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 von OlliWW:

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.

......

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

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.

......

[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

[Assarbad]

Zitat von sakura:

Zitat von 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.

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.

Sorry, da lach ich mich scheckig. Als Rückentwickler lernt man vor allem eins: daß Leute ihre tollen Firmengeheimnisse und ihren endgeilen Code total überschätzen. Und Mitarbeiter einschleusen mag vielleicht bei Firmen der Größe von Google, Microsoft oder Amazon klappen, gehört aber ansonsten wohl eher in den Bereich Verschwörungstheorien.

Bin da voll bei Sherlock.

Erstens: wenn ich einen Entwickler an meinen Code ranlasse, dann vertraue ich ihm. Punkt. Gegenteilige Maßnahmen sind ähnlich "zielführend" (lies: bescheuert) wie einem Kunden nicht zu vertrauen, daher starke Kryptographie einzusetzen und dennoch alle Informationen auf dem Kundenrechner vorzuhalten (inkl. geheimer Schlüssel; anstatt bspw. "Wissen" - bspw. in Form eines Algorithmus - in einen Hardwaredongle auszulagern). Das ist in sich widersinnig. Entweder du vertraust, oder du vertraust nicht. Beides geht nicht. Und im Zweifel nervst du ohnehin nur die Kunden, bzw. in diesem Fall die Entwickler. Klar kann man das machen, aber es ist halt Schlangenöl.

Aber technische Maßnahmen für soziale Probleme waren ohnehin noch nie eine Lösung.

Und ohnehin frage ich mich was genau ein Dieb denn mit den Quellen machen kann. Bei 1:1-Nutzung würde er/sie sich jedenfalls strafbar machen. Das ist ungefähr wie das Argument ein Arbeitnehmer könne sich beim Verlassen der Firma den Quellcode mitnehmen:

1. Wozu?
2. Wie soll ich den danach "nutzen" (also bspw. zu Geld machen)?
3. FLOSS-Projekte würden vermutlich nicht existieren, gäbe es nicht räudigen, verkrusteten Legacy-Code der nach Vorgaben von Firmen über Jahrzehnte von verschiedenen Entwicklern mit verschiedenster Fachkompetenz ineffizient zusammengeklöppelt werden mußte, anstatt die richtigen Werkzeuge und Methoden zu verwenden und dem Ganzen eine schöne Testabdeckung zu spendieren und ihn regelmäßig auf den Stand der Zeit anzuheben (Refactoring). Womit wir wieder bei der Überschätzung des ach so wertvollen Codes wären.

Hier wird zwar nicht viel vom Themenersteller verraten, aber wenn es um Interop geht, ist RCE ohnehin in der EU legitim. Dem kommt man also nicht einmal mit rechtlichen Mitteln bei.

Zitat von Sherlock:

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.

Oh Gott, den Bereich haben wir bei uns auch. Haufenweise Vorgaben; aber viele Häkchen scheinen nur proforma gemacht zu werden. Anders kann ich mir diverse unsinnige, teils komplett kosmetische, Kodierrichtlinien bspw. nicht erklären. Da wären Regeln ala MISRA C/C++ schon zielführender.

Zitat von mensch72:

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

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

Ja? Schonmal probiert? Also das rückzuentwickeln? Sicher, Logik zu verschleiern könnte ein wenig helfen. Vor allem hält es Skriptkiddies ab.

Aber angenommen es handelt sich bei den besagten Cola-Rezepten um die endgeilsten 100 Codezeilen die jemals geschrieben wurden. Dann gibt es grob gesehen zwei Varianten:

1. Die sind endgeil, weil sie superschnell sind. Virtualisierung (Themida ist da sozusagen der Großvater von) macht dir das alles zunichte. Muß man halt wollen.
2. Das ist so endgeil, daß ein Konkurrent nicht den Aufwand scheut einen Rückentwickler dranzusetzen.

In letzterem Fall hast du schon verloren. Denn inzwischen bietet wirklich jeder aktuelle Disassembler die Möglichkeit Prozessormodule zu schreiben (mithin also die "virtuelle Architektur" zu dekodieren). Klar, bedeutet etwas mehr Aufwand, aber wenn der Code so endgeil ist, dann sind das Peanuts im Vergleich zum Nutzen für die Konkurrenz.

Aber zumeist wird es einfach ausreichen alles drumherum zu instrumentieren. Du würdest dich wundern was sich mit PIN, DynamoRIO, Wine oder auch mit Virtualisierung so alles herausbekommen läßt. Von DLL-Placement-Angriffen, die du mit einer Auftrennung in Module u.U. noch erleichterst, haben wir dabei noch nicht einmal geredet.

Es scheint sowieso ein komplett falscher Eindruck von Rückentwicklung (RCE = Reverse Code Engineering) zu existieren. Die Schnittstellen zu einem solchen "geschützten" Modul wären ja dennoch recht einfach für einen Rückentwickler zu ermitteln.

So, dann hab ich also eine Schnittstelle. Jede Menge "Geschäftscode" den ich - als "interessierter Konkurrent" - so oder so ähnlich ohnehin schon habe und/oder kenne. Aber dann habe ich da ein extra geschütztes Modul. Jetzt rate mal worauf genau sich meine Aufmerksamkeit konzentrieren wird?!

Als Rückentwickler guckst du ja nicht nach dem ganzen Boilerplate-Code der überall 08/15 ist, sondern du guckst nach den wenigen Prozent oder gar Promille die interessant sind. Um das Arbeitsfeld einzugrenzen hilft so ein vermeintlicher Schutz also auch erst einmal. Und klar, diese Teile ala Themida sind echt nervig, aber sie sind nicht unknackbar. Wenn ich also das fertige Endprodukt erwerben kann und sich daraus ergibt, daß sich der Aufwand lohnt, dann ist der Schutz trotzdem allenfalls das was man von diesen ganzen Spieleschutztechniken kennt: ein paar Wochen oder Monate. Bei Spielen lohnt sich das häufig, weil die ganzen Spieler den Herstellern bei Veröffentlichung die Bude einrennen und das dann abebbt. Aber wie man schon der Tatsache, daß diese Schutzmechanismen in Spieleupdates oft wieder verschwinden, entnehmen kann, ist der Effekt zeitlich begrenzt. Wäre dies bei der hier avisierten Schutzmaßnahme auch der Fall? Klingt nicht danach.

Echten Schutz bekommst du nur, wenn die eigentliche proprietäre Logik nicht für den, dem man nicht vertraut, zugreifbar ist. Also in einem "smarten" Hardwaredongle oder serverseitig. Was dann natürlich wieder andere Einschränkungen mit sich bringt.

Und nein, diese Form von Sicherheit läßt sich nicht kaufen. Ich habe schon mehrere Hardwaredongle geknackt und das Problem lag immer in unzureichendem Schutz auf Seiten des PC. Im einen Fall wurde sogar nur ganz stupide ein Wert ausgelesen und an die Anwendung übergeben. Ohne den Code der Anwendung oder seine DLLs auch nur anzufassen, habe ich da einfach eine eigene DLL plaziert, die den Wert genauso zurückgab. Wunderbar. Problem (Parallel-Hardwaredongle "schützen", denn die waren sehr fragil) gelöst. Das Programm wurde dennoch nur entsprechend der Anzahl der Lizenzen eingesetzt und falls - was ich nie überprüft habe - diese Zahl mehr als eine Lizenz- oder Kundennummer war und bspw. die Features des Programms kodierte, habe ich das nicht ausgenutzt. Es ging ganz simpel darum, daß bei Ausfall des Dongles ("durchbrennen") oder anderen Unwägbarkeiten der Geschäftsbetrieb aufrechterhalten werden konnte.

Und bei alledem kommt die Diskussion der Sinnhaftigkeit noch immer zu kurz, denn "mein" Entwickler, den ich anstelle, soll ja nicht etwa nur in der Lage sein Code zu entwickeln, sondern diesen auch zu debuggen. Ich schieße mir also mittelfristig damit selbst ins Knie. Von der desaströs demotivierenden Botschaft, die von derlei Verfahrensweise ausgeht, ganz zu schweigen.

Zitat von IBExpert:

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

Du willst uns also allen Ernstes erklären, daß das BGB (Verträge) und Urheberrecht zahnlose Papiertiger sind?

Zitat von Hobbycoder:

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

... und dann ggf. wegen Verrats von Geschäftsgeheimnissen zur Verantwortung gezogen.

Zitat von Benmik:

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.

Eben. Allerdings wird man sich in einem Kundenverhältnis zumeist anders einig, weshalb es häufig unnötig ist zu derlei Maßnahmen zu greifen.

Nochmal: wenn du deinen Entwicklern nicht vertrauen kannst, haste ein ganz dickes Problem. Wer den Feind eben bereits im eigenen Hause verortet, sollte sich mal echt Gedanken machen. Entweder bringst du deinen Entwicklern nicht die Wertschätzung entgegen, du bezahlst sie nicht entsprechend ihrer Qualifikation oder es gibt andere Gründe.

Und ja: Programmierer != Entwickler (hier nochmal auf Delphi: Programmier <> Entwickler )

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

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