Guybrush Threepwood Geschrieben 28. Januar 2008 Teilen Geschrieben 28. Januar 2008 Hat sich damit schonmal jemand beschäftigt? Das bietet mir ja die Möglichkeit bestimmte Funktionen meiner Anwendung zu verschlüsseln damit nicht irgendjemand zum Beispiel mit dem .Net Reflector hingeht und sich den Quellcode dieser Funktionen anschaut. Der Code in der Funktion wird dabei ja durch etwas in der Art public void Foo() { object[] args = new object[0]; SLMRuntime.SVMExecMethod(this, "12059b676c63429dbe218020acdc32d2", args); } [/PHP] ersetzt. Der eigentliche Code steht dann (anscheinend) verschlüsselt in einer der von SLP erstellten DLLs. Ich verstehe allerdings noch nicht so genau wie das den Quellcode vor ungewollter Einsicht schützen soll. Beim Verschlüsseln wurden bei mir 3 zusätzliche Dlls erstellt, das heißt irgendwo dadrin muss ja dann mein ursprünglicher Quellcode wahrscheinlich verschlüsselt existieren. Damit der dann wieder ausgeführt werden kann muss ja auch irgendwo der Schlüssel dazu existieren und das bedeuted doch das jemand der die Anwendung ausführen kann diese auch wieder in ihren Quellcode zerlegen können müsste. Das ganze jetzt evtl. mit etwas mehr Aufwand aber ich sehe da irgendwie das Hindernis nicht. Oder hab ich da was falsch verstanden? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Trux Geschrieben 28. Januar 2008 Teilen Geschrieben 28. Januar 2008 Naja dir frage ist nu wieviel ein Mensch mit nicht leserlichem quellcode anfangen kann... Bei "Nativen" anwendungen hast du ja auch den ausführ code, anpassung kannst du da ja auch machen - stichwort cracks. Wenn du eine "Normal" kompiliert assembly nimmst und die in den Reflector haust bekommst du ja ziemlich einfach leserlichen code. Wenn du jetzt aber hingest und sämmtliche privaten / oder sonstig nicht öffentlichen Methoden umzubenennen in zufällige buchstaben- zahlen-kombinationen. Und die Methoden noch verschachtelst ist es nichtmehr wirklich schön lesebar. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 28. Januar 2008 Autor Teilen Geschrieben 28. Januar 2008 Sry, aber ich seh gerade nicht was das mit der Fragestellung zu tun hat? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 29. Januar 2008 Teilen Geschrieben 29. Januar 2008 Wie kommst du denn darauf das diese Technik SLP heißt? SLP nennt Microsoft irgendein Lizenzmodell. Und wo hast du überhaupt die Dokumentation zu der SLM Klasse her? Ist das unterm Strich nicht das selbe wie Obfuskation? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 29. Januar 2008 Autor Teilen Geschrieben 29. Januar 2008 Du kannst damit wohl beides machen, deine Anwendung lizensieren und schützen. Software Licensing and Protection Services - Visual Studio Users Ist das unterm Strich nicht das selbe wie Obfuskation? Das ist ja die entscheidene Frage Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 29. Januar 2008 Teilen Geschrieben 29. Januar 2008 Ah, okay. Wenn ich das richtig verstehe ist das ein eigener IL Dialekt der dabei erzeugt wird. Durch Permutation wird der prinzipiell erstmal verändert und dann als verschlüsselter IL Code in der Assembly verschlüsselt. Meiner Meinung nach muss der JIT-Compiler ja trotzdem zu irgendeinem Zeitpunkt den Standard IL Code erhalten, wenn man daran kommt kann man auch wieder mit dem Reflector arbeiten. Wie sicher das wirklich ist müsste man vermutlich einen Hacker fragen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 29. Januar 2008 Autor Teilen Geschrieben 29. Januar 2008 Meiner Meinung nach muss der JIT-Compiler ja trotzdem zu irgendeinem Zeitpunkt den Standard IL Code erhalten, wenn man daran kommt kann man auch wieder mit dem Reflector arbeiten. Ja das denke ich mir halt auch das man es entweder an der Stelle abfangen kann oder das man es auf die selb e Art selbst entschlüsseln kann. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Argbeil Geschrieben 29. Januar 2008 Teilen Geschrieben 29. Januar 2008 Das Ziel solcher Projekte ist es in der Regel nur, den Aufwand massiv zu erhöhen. Du kannst auch nativ kompilierte C Programme wieder in eine Hochsprache verwandeln, aber der Aufwand ist etwas höher als bei einem obfuskatiertem IL Programm zurück. Wenn die es mit dem Code Protector (so heißt das Tool) auf ein identsiches Level kommt wäre für viele Firmen ja schon viel gewonnen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 29. Januar 2008 Autor Teilen Geschrieben 29. Januar 2008 Das Ziel solcher Projekte ist es in der Regel nur, den Aufwand massiv zu erhöhen. Du kannst auch nativ kompilierte C Programme wieder in eine Hochsprache verwandeln Ja das ist schon klar, aber bei einem IL Programm sind diese Probleme ja viel größer. Wenn du das einfach so auslieferst kannst du das ja mit einem entsprechenden Tool wieder in den Original Quellcode umwandeln, dir ein Projekt dazu erstellen lassen und hast dann am Ende genau das selbe als hättest du den gesammten Quellcode vom Hersteller bekommen. Selbst für die entsprechenden Obfuskator Tools gibt es ja entsprechende Gegentools, auch wenn ich da noch keins von ausprobiert habe... Wenn die es mit dem Code Protector (so heißt das Tool) auf ein identsiches Level kommt wäre für viele Firmen ja schon viel gewonnen. ja wenn... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.