Source Code verschlüsseln

[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

[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

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

[Benmik]

Zitat von Assarbad:

Wenn du deinen Entwicklern nicht vertrauen kannst, haste ein ganz dickes Problem.

Das hat man vielleicht. Aber ich vermute mal vorsichtig, dass du in deinem Leben noch nicht so viele Leute eingestellt hast. Ich habe da schon erhebliche Erfahrung und man glaubt gar nicht, was sich hinter Leuten verbergen kann, die tadellose Zeugnisse anbringen und im Bewerbungsgespräch (und in den ersten Monaten danach) eine absolut gute Figur machen. Ich bin zu dem Schluss gekommen, dass es einfach unmöglich ist, alle Bewerber auch nur rudimentär zu durchschauen. Es gibt eine Regel für Leute mit Führungsaufgaben: Ab 10 Mitarbeitern geht die Chance, dass du einen schwierigen Fall darunter hast, gegen 100%. Solche Fälle können sich auch mit den Jahren entwickeln. In einer großen Firma, wie der TE schreibt, ist es praktisch zwangsläufig so, dass es dort schwierigste Kollegen gibt.

Ich habe mal den Fall erlebt, dass sich einer unserer Systembetreuer von zuhause aus ins System eingeloggt hat, um es komplett zu sabotieren. Das Ganze ohne erkennbaren Grund und ohne finanziellen Gewinn. Er hinterließ allerdings digitale Spuren, an die er hinterher nicht mehr herankam, so dass er nach dem Ausloggen zuhause saß und auf die Polizei wartete. Ich kannte den Mann auch. Alle waren platt; nie, nie hätte man dem das zugetraut.

Ich meine auch, dass du unterschätzt, wie sehr die Existenz einer Firma von einem bestimmten, vielleicht sogar eng begrenzten Spezialwissen abhängen kann. In der Industrie sind das oft Verfahrenstechniken; wenn dein Schatz sich in einem Stück Software materialisiert, dann ist es existenziell, dass du das schützt. Ich persönlich würde dafür auch ein hohes Maß an Umbequemlichkeit in Kauf nehmen. Alles andere fände ich sehr naiv.

[sakura]

Zitat von Assarbad:

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.

Hi Assarbad, ich habe immer großen Respekt vor Deinem Wissen gehabt, insbesondere Deine Qualitäten auf genau dem Gebiet. Und Entwickler mit Deinem Wissen auf diesem Gebiet mit Deinem Know-How gibt es einige, aber gemessen an der Gesamtzahl aller Entwickler ist das ein extrem kleiner Anteil. Und (fast) jeder hier weiß, dass für alles, was ein Computer ausführen kann, jemand auch mehrere Entwickler existieren, die das verstehen werden, egal wie komplex und verschleiert es ist. Aber das heißt nicht, dass man es der Konkurrenz zu leicht machen sollte. Im Gegenteil, bei diese Einstellung ist lächerlich.
Und zu glauben, dass solche Dinge nur bei den großen auftreten, das ist extrem naiv. Ich habe für kleine Unternehmen gearbeitet, denen das passiert ist, und ich kenne mehrere Firmen aus meinem alten Kundenkreis, welche dieses Problem ernsthaft hatten. Keiner hat erwartet, dass es 100% Schutz gibt, insbesondere bei Programmen, welche auch außer Haus installiert wurden (sehr oft). Aber keiner wollte es der Konkurrent dann auch zu leicht machen. Ein Wissensvorsprung, auch in Software, von nur ein paar Wochen kann Millionen Umsatz bedeuten. Und das sollte einem Entwickler mit Deiner Intelligenz eigentlich auch verständlich sein, oder?

......