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:
- Wozu?
- Wie soll ich den danach "nutzen" (also bspw. zu Geld machen)?
- 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.
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.
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:
- 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.
- 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.
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?
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.
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
)