AW: Source Code verschlüsseln
Zitat:
|
AW: Source Code verschlüsseln
Zitat:
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. |
AW: Source Code verschlüsseln
Zitat:
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:
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:
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:
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:
Zitat:
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:) |
AW: Source Code verschlüsseln
Zitat:
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. |
AW: Source Code verschlüsseln
Zitat:
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:... |
AW: Source Code verschlüsseln
Die Frage des Te war:
Zitat:
|
AW: Source Code verschlüsseln
Um das Ganze mal abzukürzen:
|
AW: Source Code verschlüsseln
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:
...:cat:... |
AW: Source Code verschlüsseln
Zitat:
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:
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:
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:
|
AW: Source Code verschlüsseln
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz