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.

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

[IBExpert]

Zitat:

Zitat von OlliWW (Beitrag 1466674)

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.

so als Idee mal das was wir für einen sehr großen Konzern mit dem quellcode gemacht haben, auf den er meinte, zwar das Recht zu haben, diesen zu bekommen, obwohl er nicht den vollen Angebotsbetrag zahlen wollte und wir die voll funktionale delphi exe schon ausgeliefert hatten. Nachdem es einen Meinungsaustausch mit dem Projektverantwortlichen gab (vorher hatte der seine Meinung, nachher hatte der meine Meinung), haben die dann doch voll bezahlt und wir brauchten das nicht mehr, war aber damals schon einsatzbereit, hab ich aber leider nicht mehr ohne intensive suche. Die Motivation war aber ja im Endeffekt eine andere, und es ist auch keineswegs unentschlüsselbar, aber jemand der das komplett verstehen will, braucht dafür schon einiges an zeit und aufwand.

wir haben da (vor ca 17 Jahren, aber das geht gfg noch ähnlich heute) folgendes gemacht

Im prinzip war das ganze ein Non standard obfuscator/uglifier oder wie auch immer man das nennt.

1. Alle eigennamen (variablen, eigene typen, konstanten, functions, procedures) wurde aus dem quelltext ausgelesen und in eine Datenbank gepackt (mit referenz, wo das denn herkommt usw, was ein wenig tüftelei, aber war die mühe und den Spaß wert).
2. Diese Eigennamen wurde dann durch möglichst kurze ersetzt, die mit random funktionen erzeugt wurden aus 1.zeichen a-z, rest immer a-z+0-9 und dann per suchen/ersetzen im gesamten Quellcode
3. sämtliche Stringkonstanten aus dem code wurde ersetzt durch eine funktion, die eine random key mit einer damit erzeugten hex konstante für den eigentlichen String als parm bekommt, die decode function dazu hatte ein bekannter in fiesem inline assembler erstellt, die war dann natürlich im code enthalten, aber für leute mit durchschnittsknow how nicht verständlich
4. sämtliche zeilenvorschübe wurde da wo es die Pascalsyntax zulässt entfernt und an abstrusen anderen stellen wieder ergänzt. Die maximale codezeilenlänge wurde fast immer ausgenutzt, so das teilweise 4-5 befehle in einer zeile waren
5. sämtliche kommertare (auch die automatisch erzeugten) wurde entfernt, dafür würde abstruse kommentare aus einem lexikon ergänzt
6. Während ich das gebaut hab, habe ich immer wieder die Aufrufsyntax und Darstellung der Software geprüft, es war am Ende immer noch funktional identisch zu dem was der original quellcode erzeugt hatte
7. einige andere typische sprachelemente wurde dann auch ncoh vergewaltigt oder ergänzt, variableninhalte würden ziemlich sinnlos verändert, also hochgerechnet, danach irgendwann vor der nächsten echten benutzung wieder runter usw.

der weiterhin compilierbare quellcode machte das gleiche was das gesamte Projekt machte, liess sich aber ähnlich gut lesen wie direkter hex code der exe, ich hatte das einem
Bekannten gezeigt mit sehr guten Delphi Kenntnissen und der sagte, das wäre für ihn keine chance, da auch nur irgendwas drin zu verstehen, geschweige denn sinnvoll zu debuggen und das war ja das ziel

trotzdem hätte damit jemand bei entsprechendem Aufwand eine Version erzeugen können, die wieder mehr oder weniger benutzbar ist.

Wenn es aber um Teamwork geht und nicht darum, voll compilierbaren unverständlichen sourcecode zu haben, dann würde ich die sensiblen Units halt gar nicht als pas verfügbar machen, sondern nur als dcu, das würde den o.a. aufwand ersetzen und ist seit jahren von Komponentenherstellern ein bewährstes verfahren, wird ja auch von einigen hier so vorgeschlagen.

[IBExpert]

Zitat:

Zitat von Sherlock (Beitrag 1466686)

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

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

[Uwe Raabe]

Zitat:

Zitat von IBExpert (Beitrag 1466748)

2. Diese Eigennamen wurde dann durch möglichst kurze ersetzt, die mit random funktionen erzeugt wurden aus 1.zeichen a-z, rest immer a-z+0-9 und dann per suchen/ersetzen im gesamten Quellcode

Mit halbwegs aktuellen Delphi-Versionen kann man auch Unicode-Zeichen als Bezeichner verwenden. Da sind immerhin schon eine ganze Menge an Bezeichnern, die man dann mit nur einem Character ersetzen kann.

[himitsu]

Es gibt auch mehrere "Leerzeichen", die Delphi falsch einordned (als normale "Buchstaben") und somit kann man sogar unsichtbare Bezeichner erstellen.
Aber ja, sowas Chineisch oder Arabisch macht sich seit 11 Jahren auch besonders gut.

Und es gibt ein paar Zeichen die im Debugger die Zeilenzuordnung durcheinander bringen.
Einige fanden das schon nervig, aber hier wäre es zu praktisch, wobei man erstmal sämtliche Debuginfos und die erweiterte RTTI hier so schön abschalten sollte.

[Hobbycoder]

Zitat:

Zitat von IBExpert (Beitrag 1466751)

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.

[jfheins]

Also die ganz wesentlichen Maßnahmen wurden hier ja schon angerissen:
- Nur Kompilate verteilen
- Obfuscator (gibt es bestimmt auch schon fertig ;-) )

Ich würde da aber immer dazu raten, das ordentlich zu versionieren. Also bspw. mit einem eigenen git. Da hast du dann im großen Repo das Rezept auf einer bestimmten Version. Und sobald eine "Rezeptänderung" nötig ist, wird das Rezept (in einem anderen Repo) weiterentwickelt und die dcus können dann ins große Repo kopiert werden.

Statt dcu geht natürlich auch hässlicher Code, da braucht dann die Build-Pipeline den Obfuscator und das kommt als Artefakt raus.

Zitat:

ColaLib\
- Source\ > Source.7z mit Passwort
- ColaLib.dcu (für alle)
- BuildColaLib.bat

Davon würde ich abraten. Irgendwann verlässt ein Passwort-kenner die Firma, erzählt seinem Ex-Kollegen das Passwort damit er auch mal schauen kann ... ;-)

[Benmik]

Zitat:

Zitat von IBExpert (Beitrag 1466748)

Wir haben da (vor ca 17 Jahren, aber das geht ggfs. noch ähnlich heute) Folgendes gemacht...

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.

[IBExpert]

Zitat:

Zitat von Benmik (Beitrag 1466799)

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.

bei komplexen Programmen ist aber ein großer Teil der Lernkurve damit verbunden, aus den Bezeichnungen Zusammenhänge herzustellen. Sicher gibt es Leute die Assembler im Kopf verstehen und ausführen können, aber die sind selten und auch die stützen ihr wissen auf bekannte Bezeichner.

Wenn du ein Beispielcode von irgendjemanden hier im Forum liest, dauert es wenige Sekunden, anhand der Bezeichner die Idee zu verstehen, was der Autor damit sagen will.

Wenn dir aber alleine dieser Bezug schon komplett durch unwiederbringliche Abkürzungen genommen wird, hilft dir der codeformatter nur dabei, das zum Teil wieder in passende Zeilen zu verteilen, aber die sind auch nicht alle perfekt (wir haben einen in IBExpert für sql und der macht je nach Einstellung manchmal sogar weniger lesbare ergebnisse als vorher, wer der ursprungscode seltsame geschrieben ist und sql hat auch noch ziemlich wenige Sprachelemente).

In irgeneiner exe mal eben die passende Stelle der Lizenzabfrage zu finden und aus einem assmeber hex code jump equal einen hex code jump not equal zu machen, ist für einen Profi eine Lachnummer, wenn man freundlicherweise direkt nach dem Lizenzcheck per showmessage meckert, das die software nicht lizensiert ist. Das ist sicherlich auch das was viele reizt, zu knacken, ohne auch nur irgendein Interesse an der eigentlichen software zu haben (wir waren selber oft genug opfer, wehren uns dagegen auch nur auf andere Art und Weise, die wir so gar nicht erklären ;-) )

Ich glaub aber nicht das der Threadautor so was banales verbergen will, weil wenn das deren Geheimnis ist, dann ist das begrenzt schützenswert.

Wenn das aber wie bei einem Kunden früher mal ein komplett in Pascal geschrieben modul ist mit extrem komplexen mathematischen Routinem zur Brillenglasberechnung, die für das Unternehmen mal ein Professor noch in Turbopascalzeiten geschrieben hat und den man auch nicht im realen Quellcode komplett verstanden hat (ich jedenfalls nicht, hab aber auch nicht die Lust und Zeit dazu gehabt, weil ich es nur compilieren musste über mit den Auftragsdaten aufrufen musste, war das ziemlich egal).

Ein erfahrener Mathamtiker/Optiker hätte sicher anhand der Bezeichnungen das ganze nachvollziehen, verbessern oder an neue Anforderungen anpassen können und nicht so gruselige Workarounds da eingebaut (die da wirklich drin waren): if kunde = xxx then dicke muss größer als 2 sein o.ä. In dem Moment wenn du aber keinen einzigen Bezeichner im Code verstehst, hast du kaum eine Chance, solche wenn auch miese Lösungen an die richtige Stelle da einzubauen.

[Assarbad]

Zitat:

Zitat von sakura (Beitrag 1466687)

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.

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:

Zitat von Sherlock (Beitrag 1466693)

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:

Zitat von mensch72 (Beitrag 1466697)

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:

Zitat von IBExpert (Beitrag 1466751)

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:

Zitat von Hobbycoder (Beitrag 1466770)

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:

Zitat von Benmik (Beitrag 1466799)

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 :zwinker:)

[Benmik]

Zitat:

Zitat von Assarbad (Beitrag 1466804)

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:

Zitat von Assarbad (Beitrag 1466804)

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?

...:cat:...

[TigerLilly]

Die Frage des Te war:

Zitat:

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

Und wir reden jetzt darüber, warum er diese Frage gar nicht stellen soll? Wie schon gesagt, es gibt Branchen, da ist das ist das ein Muss.

[dummzeuch]

Um das Ganze mal abzukürzen:

• Es ist sinnlos zu versuchen den Sourcecode zu "verschlüsseln" (Code obfuscation). Alle Methoden, die es dazu gibt, lassen sich mit mehr oder weniger großem Aufwand rückgängig machen. Wenn das "Geheimnis" wirklich so wichtig ist, wird jemand diesen Aufwand treiben. Und außerdem sind die meisten Softwareentwickler von Natur aus neugierig und ein solcher Code würde sie dazu bringen, zu versuchen in wieder lesbar zu machen.
• Also darf man nicht den Sourcecode sondern nur eine binäre Form herausgeben (dabei nicht vergessen: Auch für diesen Teil des Sourcecodes sollte man ein SCM verwenden! Zugriffsbeschränkungen sind da ja möglich.). Das können DCUs oder eine DLL sein.
• Wenn es Abhängigkeiten gibt, die letzteres verhindern, muss man diese mittels Refactoring entfernen. Wenn das "Geheimnis" wirklich so wichtig ist, dann muss man diesen Aufwand treiben. (-> Entscheidung trifft der Firmenchef oder wie hoch auch immer sie aufgehängt werden muss.)

[sakura]

Wenn es eine in-house Anwendung ist, dann gäbe es noch die Möglichkeit, die Routinen ausschließlich über einen REST-Server anzubieten. Hier kommt es natürlich auf die Umstände an, wie diese Berechnungen benötigt werden.

Zitat:

Zitat von Sherlock (Beitrag 1466693)

In meinem Feld, den Medizinprodukten, ist das anspruchsvolle nicht die Entwicklung...

oder eine Kombination daraus. Oocyten-Stadium und Qualitätserkennung ist weiterhin einer der Bereich eines ehemaligen AGs von mir, auf dessen Gebiet dieser führend ist. Auch darauf hatten nur sehr wenige Entwickler Zugriff. Selbst die Kunden haben die Routinen nie bekommen. Auch diese Dinge wurden ausschließlich über REST angeboten. Und dann kam die wunderbare Doku für weltweite Zulassungen hinzu. Oh ja...

...:cat:...

[Assarbad]

Zitat:

Zitat von sakura (Beitrag 1466819)

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.

Erstmal: es ging hier nicht um die Konkurrenz, es ging um die Entwickler im eigenen Hause. Diese Entwickler haben - schon von Rechts wegen - eine Verpflichtung zur Loyalität, genau wie (bspw. in der aktuellen Situation) die Firma eine Fürsorgepflicht hat.

Den Konkurrenten muß es niemand einfach machen. Aber nochmal: wer den Feind (sprich: den Konkurrenten) bereits im eigenen Hause verortet hat größere Probleme als das "Cola-Rezept" vor seinen Entwicklern zu schützen. Ohnehin ließe sich Schaden seitens eines Konkurrenten deutlich subtiler anrichten als durch den Klau von Firmengeheimnissen.

Zitat:

Zitat von sakura (Beitrag 1466819)

Und zu glauben, dass solche Dinge nur bei den großen auftreten, das ist extrem naiv.

Mag sein. Ich halte es wiederum naiv davon auszugehen, jemand begäbe sich freiwillig und sehenden Auges in eine Vertragssituation gegenüber dem Konkurrenten um diesen auszuspähen. Da halte ich es doch für deutlich wahrscheinlicher, daß man bei der Reinigungsfirma des Konkurrenten anheuert und die Tatsache ausnutzt, daß es 1. Lücken in Software gibt 2. Lücken in sicherheitsrelevanten Richtlinien gibt (bspw. das Sperren des Rechners beim Weggehen, was mit Vorliebe die Leute mit den weitgehendsten Rechten "nervig" finden, weshalb sie sich von den entsprechenden Vorgaben entbinden lassen). Sichwort in diese Richtung: BadUSB. Der kleine USB-Stick vom Parkplatz könnte sich aus Kombination von Eingabegeräten und Massenspeicher mit drahtloser Netzwerkanbindung entpuppen, die wie von Geisterhand ungesperrte Rechner übernimmt. Oder in unserem Szenario übernimmt das Anstecken und Abziehen - alles in unter einer Minute - die unterbezahlte Putzfrau aus Südosteuropa gegen eine kleine finanzielle Anerkennung. Es gibt dutzende kommerziell verfügbare Gadgets, die sich statt von einem seitens der eigenen Firma angeheuerten Pentester auch von einem böswilligen Angreifer nutzen lassen. Mit rudimentärer Kenntnis des Zielsystems kann man erstmal "den Fuß in die Tür kriegen und diese dann weiter aufstoßen". Selbst gebastelt oder beim Auftragsfertiger in China bestellt macht das noch schwieriger nachzuverfolgen, falls der Agent ertappt wird.

Zitat:

Zitat von sakura (Beitrag 1466819)

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.

Ich bin mir nicht sicher welchen Aspekt du hier ansprichst. Dir sind viele Fälle von eingeschleusten Getreuen der Konkurrenz bekannt, oder dir sind viele Fälle von entwendetem "geistigen Eigentum" bekannt?

Zumindest wenn der Konkurrent, anstatt jemanden einzuschleusen, einfach über RCE einen Klon erstellen, würde dies ebenfalls rechtliche Fragen aufwerfen und dem eigentlichen Urheber gewisse juristische Mittel an die Hand geben.

Wenn du sagst dieses Thema sei extrem verbreitet auch bei kleineren Firmen, stellt sich die Frage warum die Rechtsmittel dann nicht ausgeschöpft werden? Wird die Schöpfungshöhe bei diesen "Cola-Rezepten" am Ende doch nicht erreicht? Oder ist das "Cola-Rezept" am Ende weniger wert als den Konkurrenten mit dem eigenen Werk ziehen zu lassen?

Abgesehen davon stellt sich natürlich die Frage, ob man nicht eventuell die vielen Stunden, Tage oder Wochen, die für solche Schlangenölmaßnahmen aufgewendet werden in Qualitätssicherung und Weiterentwicklung der Software stecken sollte?! Da freuen sich die Kunden und man macht es dem Konkurrenten so auch schwer.

Man stelle sich vor der Themenersteller "sichert" das alles mit einem tollen Drittanbieter-Schlangenöl-Werkzeug (was in sich schon Projektrisiken birgt) und der eigentliche Code landet (im Klartext) in einem separaten SCM. Wird denn HTTPS bzw. SSH im Firmennetz verwendet? Teilt man sich - auch mal aus Versehen - Paßwörter? Läuft der selbstgehostete Chatdienst auch mit Transportverschlüsselung? Wie ist denn so insgesamt die Sicherheit im Netzwerk? Kurzum: wir drehen uns im Kreis und landen wieder bei meiner Aussage von letzter Nacht, daß, wer den Feind im eigenen Haus verortet, größere Probleme hat als mit dieser Methode sich und anderen "Sicherheit" vorzugaukeln.

Zitat:

Zitat von sakura (Beitrag 1466819)

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?

Nochmal: es ging dem Themenersteller um Entwickler im eigenen Hause, die man als Agenten der Konkurrenz vermutet.

Das andere Thema habe ich selbst aufgeworfen (zeitlicher Vorsprung) und stelle es somit nicht infrage. Die Schlußfolgerungen stelle ich hingegen sehr wohl infrage. Wir landen also nicht beim Konsenseinheitsbrei, sondern bei einem Dissens; und trotzdem haben alle etwas gelernt.

Zitat:

Zitat von sakura (Beitrag 1466848)

Wenn es eine in-house Anwendung ist, dann gäbe es noch die Möglichkeit, die Routinen ausschließlich über einen REST-Server anzubieten. Hier kommt es natürlich auf die Umstände an, wie diese Berechnungen benötigt werden.

Eben!

Zitat:

Zitat von Assarbad (Beitrag 1466804)

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.

[joachimd]

Zitat:

Zitat von Assarbad (Beitrag 1466853)

Aber nochmal: wer den Feind (sprich: den Konkurrenten) bereits im eigenen Hause verortet hat größere Probleme als das "Cola-Rezept" vor seinen Entwicklern zu schützen. Ohnehin ließe sich Schaden seitens eines Konkurrenten deutlich subtiler anrichten als durch den Klau von Firmengeheimnissen.

87% aller Informationssicherheitsverletzungen gehen von den eigenen Mitarbeitern aus ... und von den Wenigsten wissentlich bzw absichtlich. Ich finde es daher schon sinnvoll, dass man _jedem_ Benutzer nur die notwendigsten Zugriffsrechte gibt. Egal, wie sinnvoll Dir jetzt ein Cola-Rezept erscheint, aber die Firma hat es als schützenswert eingestuft und hier geht es darum, wie man es technisch umsetzen kann.
Wenn die Mitarbeiter an gewisse Information nicht kommen, können diese sie auch nicht unabsichtlich weitergeben (und wenn es "bloß" Ausspähen durch Schadsoftware ist).
Zur technischen Umsetzung: ist es für die Entwicklung wichtig, das richtige Rezept zu haben? Wenn nicht, Stichworte wie MockUp, Fake-Daten usw sind ja schon gefallen. Erst das endgültige Resultat nutzt eben die echte Unit. Damit schränkt man den Zugriff auf wenige Projekt Owner ein.

[Assarbad]

Zitat:

Zitat von joachimd (Beitrag 1466870)

87% aller Informationssicherheitsverletzungen gehen von den eigenen Mitarbeitern aus ... und von den Wenigsten wissentlich bzw absichtlich.

Keine Ahnung was die Quelle ist, klingt aber prinzipiell plausibel. Jetzt frage ich mich halt welcher Prozentsatz davon wiederum auf die verschwunden gegangenen Firmengeheimnisse entfällt und wie viel davon wiederum Entwicklern angelastet werden kann?! Gibt's dazu auch aussagekräftige Zahlen?

Zitat:

Zitat von joachimd (Beitrag 1466870)

Ich finde es daher schon sinnvoll, dass man _jedem_ Benutzer nur die notwendigsten Zugriffsrechte gibt.

Klar, soziale Probleme mit technischen Maßnahmen "erschlagen" ist bekanntlich ein Lieblingsthema der inkompetentesten IT-Abteilungen. Firmen schulen ihre Mitarbeiter zwar in Arbeitssicherheit und dazu was zu tun ist wenn der Feueralarm losgeht, meist mindestens jährlich, aber Schulung der Mitarbeiter in Grundlagen der IT-Sicherheit durch die IT-Abteilungen ist ein Unding, weil das Kontakt der IT mit echten Menschen erfordern würde; und eine Behandlung der Benutzer die nicht "von oben herab" und abschätzig den "LUsern" gegenüber ist, sondern Wissensvermittlung auf Augenhöhe und Offenheit für Rückmeldungen auch von Laien erfordert.

Und das sage ich ausdrücklich als ehemaliger Admin der jetzt nicht gerade die große Leuchte im Umgang mit Leuten (also keine "people person") ist, der aber gelernt hat, daß IT-Sicherheit durch technische Maßnahmen nur marginal verbessert wird, durch Wissenstransfer zu den "Anwendern" hingegen fundamental.

Bin ein großer Verfechter des Zero-Trust-Ansatzes in internen Firmennetzen. Aber wenn für alle möglichen Autoritätspersonen innerhalb der Firmenhierarchie ohnehin Extrawürste gebraten werden (weil die ihre "Managerkarte" zücken), ist das eben kein Zero-Trust und fällt auseinander bevor es zusammengebaut ist. Oder anders ausgedrückt: du kannst zwar deine "Bodentruppen" (die Entwickler) mit Scheinsicherheit gängeln, aber wenn die sehen, daß das Scheunentor woanders offen gelassen wird, schwindet die Akzeptanz für solche Maßnahmen ganz schnell. Dazu haben die meisten Entwickler zu viel Einblick in die Materie ... und mindestens deutlich mehr als die Buchhalterin oder der Assistent des Geschäftsführers.

Zitat:

Zitat von joachimd (Beitrag 1466870)

Egal, wie sinnvoll Dir jetzt ein Cola-Rezept erscheint, aber die Firma hat es als schützenswert eingestuft und hier geht es darum, wie man es technisch umsetzen kann.

Das Framing "wie man es technisch umsetzen kann" ist genau der Punkt den ich bemängele. Wenn dich jemand fragt wie er am besten mit nem Hammer das Bücherregal an der Leichtbauwand festschraubt empfiehlst du doch auch nicht besonders fest draufzuhauen oder lieber einen Drittanbieterhammer zu benutzen, oder?

Zitat:

Zitat von joachimd (Beitrag 1466870)

Wenn die Mitarbeiter an gewisse Information nicht kommen, können diese sie auch nicht unabsichtlich weitergeben (und wenn es "bloß" Ausspähen durch Schadsoftware ist).

Die stärkste Kette ist nur so stark wie ihr schwächstes Glied.

Und klar, nix dagegen das zu trennen (separates Repo wurde ja schon genannt). Absolut nicht. Besonders wenn man Praktikanten/Werksstudenten im Hause hat, möchte man da sicher eine Abstufung des Zugriffs auf die "Kronjuwelen". Diese Abstufung klang im Beitrag eingangs aber nicht an. Und wenn der Zugriff auf das Repo mit dem "Cola-Rezept" eingeschränkt ist und ein Mock während der Entwicklung existiert braucht es eben keine Schlangenöllösung.

[IBExpert]

Zitat:

Zitat von Assarbad (Beitrag 1466804)

Zitat:

Zitat von IBExpert (Beitrag 1466751)

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?

Jein, es ist ist in diesem Umfeld erstens ein sehr großes Problem, das vor Gericht
ohne jeden Zweifel zu beweisen.

Wissen über Prozessdetails bzw Anklage des Mißbrauchs sind ohne umfassendes Patent
nicht wirklich erfolgreich einklagbar. Und zumindest in Deutschland wirst nicht
mit vertretbarem Aufwand ein Patent für deine Software bekommen.

Jeden externen, der per reverse engineer deine Software komplett analysiert
und sich dann auf deine Verfahren und apis drauf setzt, wirst du auch nur
sehr begrenzt verklagen können, gpl etc. hin oder her, warum sollte er deine
Sourcecodes benutzen. Vielleicht ist es ja auch deine Schuld, das deine API
zu banal ist und schon ist da kein klarer Sieger mehr sichtbar.

Da kannst du ansonsten sehr viel gutes Geld dem verlorenen schlechten Geld
hinterher schmeißen und am meisten freuen sich die Anwälte, die am Ende
im Vergleichsverfahren ihr volle Kohle von beiden Parteien bekommen und
gewonnen hast du gar nichts.

Recht haben und Recht bekommen sind zwei völlig verschiedene Baustellen.

[bepe]

Tendenziell gehöre ich eher dem „Vertrauen muss sein und ob sich der Aufwand lohnt?“-Lager an. Aber jetzt habe ich einmal zu oft „Konkurrenz“ gelesen :)
Die gibt es und die sind teils ernsthaft bemüht. Aber egal….

Bei einem ehemaligen Arbeitgeber gab es einen Kollegen, der irgendwann gehen musste (div. Gründe aber eigentlich alles ganz friedlich). Einige Monate später meldete sich ein Kunde beim Support. Dieser Kunde war nur nicht unser Kunde.

Der Kollege hat sich den gesamten Source mitgenommen und damit selbständig gemacht. Da er nicht sehr bemüht war, den Produkt- und Firmennamen auszutauschen, hat er einige Stellen übersehen. So kam sein Kunde auf uns. Anstatt den Rechtsweg zu gehen, haben wir uns einfach bei ihm gemeldet… Wozu gleich den großen Stress (Rechtsmittel)? Holger hat es geschrieben, so einfach ist es nicht immer. Und selbst wenn es für einen glücklich ausgeht, du verlierst unglaublich viel Zeit und musst entsprechenden Aufwand betreiben.

Fazit: Es muss nicht immer die Konkurrenz sein (gut, in dem Fall doch irgendwie ;)) oder ein Plan dahinterstecken. Es kann schon die Gelegenheit reichen. Mit einem kleinen Stolperstein kann man sich ggf. Ärger ersparen.

[Assarbad]

Zitat:

Zitat von bepe (Beitrag 1466884)

Bei einem ehemaligen Arbeitgeber gab es einen Kollegen, der irgendwann gehen musste (div. Gründe aber eigentlich alles ganz friedlich). Einige Monate später meldete sich ein Kunde beim Support. Dieser Kunde war nur nicht unser Kunde.

Der Kollege hat sich den gesamten Source mitgenommen und damit selbständig gemacht. Da er nicht sehr bemüht war, den Produkt- und Firmennamen auszutauschen, hat er einige Stellen übersehen. So kam sein Kunde auf uns. Anstatt den Rechtsweg zu gehen, haben wir uns einfach bei ihm gemeldet… Wozu gleich den großen Stress (Rechtsmittel)?

Eine ähnliche Geschichte kenne ich von einem Vertriebler. Es scheint so als ob es bei Vertriebsmitarbeitern Usus ist die Kundendatenbank von einer Firma zur nächsten mitzuschleppen. Aber nicht nur die Kunden die man vielleicht bereits selbst mitgebracht hat, sondern eben alle. Bei der besagten Firma war man so clever einen unechten Kunden mit Kontaktdaten und allem drum und dran einzufügen. Und siehe da, einer der ehemaligen Vertriebler war doof genug da anzurufen. Klingt recht ähnlich. Stolperdraht ausgelegt ... in die Falle gegangen.

Zitat:

Zitat von bepe (Beitrag 1466884)

Mit einem kleinen Stolperstein kann man sich ggf. Ärger ersparen.

Ich weiß nicht. Stolpersteine sind ja ganz nett. Aber wenn ein Entwickler schon zu doof ist mit einem ordentlichen Suchwerkzeug alle Strings aufzutreiben und gleichzeitig genügend kriminelle Energie hat den Quelltext überhaupt mitzunehmen und den anschließend noch zu verwenden, kann man sich fragen ob es nicht ausreicht ne DCU in Binärform ins Repo einzuchecken (statt weiterer Verschleierung). Und selbst mit Verschleierung hat irgendjemand eben doch Zugriff auf das eigentliche Repo mit dem "Cola-Rezept" im Klartext. Wenn das einzig der Chef/Firmeneigner ist und der Ahnung von der Materie hat, geht das noch. Aber das skaliert nicht. In den meisten Firmen wird "Ahnung von der Materie" delegiert und dann verschiebt sich nur immer weiter wem du meinst mißtrauen zu müssen.

Aber was juckt mich anderer Leute Firmenphilosophie. Ich habe meine Argumente dargelegt und ob die in der gleichen Schlußfolgerung münden, welche ich ziehen würde, kann ich ohnehin nicht beeinflußen.