PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Dot Net Obfuscator

hadez16
2017-08-08, 21:32:38
Moin!

Welchen freien obfuscator könnt ihr für DotNet/C# empfehlen?
Ich habe Obfuscar ausprobiert...mit allen möglichen Settings gesetzt.

Dennoch sehe ich mit ILSpy noch die Hauptroutine meines Konsolenprogramms.

Oder gibt es andere gute Tipps?

Danke!
Monger
2017-08-08, 22:14:31
Ich frag mal umgekehrt: Was ist denn dein Ziel? Quasi ein Kopierschutz?

Ich fürchte es gibt gute Gründe, warum es kaum Obfuskatoren für .Net gibt. Alles was du nicht mehr verstehen kannst, kann die CLR auch nicht mehr verstehen. Die IL ist halt eine High-level Sprache.
Ganon
2017-08-08, 22:41:16
Obfuscator bringen bei den Sprachen nicht so viel, da dank Reflection-Fähigkeiten bestimmte Sachen bestehen bleiben müssen. Dazu gibt's für jeden Obfuscator im Prinzip auch irgendwo den passenden Deobfuscator.
hadez16
2017-08-09, 11:50:18
string input = global::*.*.*(Process.GetProcessesByName(. ()).First<Process>());

Match match = Regex.Match(input, . ());

bool flag2 = !(match.Value == string.Empty);

if (flag2)
{
File.Move(text + . (), text + . () + match.Value);
}


Soviel sieht man noch nachdem Obfuscar drüber ist via ILSpy...also viel ist ja wirklich verschleiert...aber der grundsätzliche Ablauf....Process...Regex.Match...File.Move....erkennt man alles noch.

Ich kenne mich damit nicht gut aus....geht das denn nicht anders?
Narolf
2017-08-09, 16:39:24
[...]

Soviel sieht man noch nachdem Obfuscar drüber ist via ILSpy...also viel ist ja wirklich verschleiert...aber der grundsätzliche Ablauf....Process...Regex.Match...File.Move....erkennt man alles noch.

Ich kenne mich damit nicht gut aus....geht das denn nicht anders?
Naja, Regex.Match&Co sind API-Calls der StandardLib, da ist nichts mehr mit obfuscaten, weil du die StandardLib nicht selber kompilierst.

Man könnte eventuell noch versuchen den Code in verschiedenen Klassen zu verteilen, damit der Algorithmus nicht komplett in einer Methode ist, aber komplett verschleiern geht halt nicht, der Computer muss das Programm schließlich noch korrekt ausführen können.

Wenn es jemand darauf anlegt wird er/sie da mit genügend Zeit trotzdem durchsteigen. Um mal ein Beispiel zu geben, die ersten Minecraft-Mods wurden erstellt, indem die Leute hingegangen sind und die ganze Minecraft-Java-Binary (ist auch Obfuscated) dekompiliert und Teile umgeschrieben/erweitert haben.
Monger
2017-08-09, 16:57:38
Wie gesagt, wozu willst du denn obfuscaten? Vielleicht gibt es ja andere Lösungen für dein Problem
Exxtreme
2017-08-09, 17:29:06
Der Bytecode lässt sich immer in einen äquivalenten Sourcecode dekompilieren. Ein Obfuscator ist deshalb so sinnvoll wie Schlangenöl oder Lichtnahrung. Ein "funktionierender" Obfuscator würde dafür sorgen, dass das Proramm nicht mehr startet weil die .NET-Laufzeitumgebung das auch nicht mehr versteht. :D

Und von "Algorithmen auf mehrere Methoden zerteilen" würde ich die Finger lassen. Das kann schnell zu subtilen Bugs führen.
hadez16
2017-08-09, 18:11:22
Wie gesagt, wozu willst du denn obfuscaten? Vielleicht gibt es ja andere Lösungen für dein Problem

Ja sorry, ich will lediglich, dass niemand die von mir angewandte Logik (recht einfach) zurückverfolgen kann.

Dass da eine do-while Schleife ist, in der ein File.Copy gemacht wird, ist eigentlich schon recht viel Info um die grundsätzliche Logik zu erkennen.

Ich versuche mal das in mehrere Klassen aufzuteilen...
PatkIllA
2017-08-09, 18:25:51
du kannst das ja in ein native dll packen und per pinvoke aufrufen. Dann muss man schon mit dem Disassembler dran.
Im Grunde klingt das aber alles über. Wenn jemand das unbedingt will kriegt er das auch hin.
RLZ
2017-08-09, 18:46:30
Ich kenne mich damit nicht gut aus....geht das denn nicht anders?
Man könnte den "kritischen Quellcode" in einen Webservice auslagern. :freak:
Narolf
2017-08-09, 21:19:39
Und von "Algorithmen auf mehrere Methoden zerteilen" würde ich die Finger lassen. Das kann schnell zu subtilen Bugs führen.
War auch nicht als Empfehlung meinerseits zu verstehen, persönlich sehe ich solche Vorhaben als Perlen vor die Säue an. Man muss nur zu den Kopierschutzmaßnahmen bei Computerspielen schauen, da wird sehr viel Zeit und Geld rein gesteckt und trotzdem werden die Dinger früher oder später geknackt.

Einen Obfuscator über die Sourcen vorm Kompilieren laufen lassen damit der dekompilierte Source Code nicht super sauber mit erklärenden Klassen-/Methodennamen ist, okay. Alles darüber hinaus ist vergebene Liebesmüh.

Man könnte den "kritischen Quellcode" in einen Webservice auslagern. :freak:
Lol, ich hasse es, dass das, je nach dem was man vor hat, tatsächlich funktionieren kann. So als ob nicht schon genug Anwendungen, die es nicht wirklich nötig haben, auf Web-Apps umgestellt werden und unsere Daten in die weite Welt verstreuen. :unono:
hadez16
2017-08-10, 11:19:52
Wenn ich meine Logik in eine C++ CLR App packe, ist das also nicht mehr ganz so einfach zurückzuverfolgen?

Ich schwitze jetzt schon bei dem Gedanken.
Mr. Lolman
2017-08-10, 11:29:14
.Net Native scheint das Mittel der Wahl zu sein: https://stackoverflow.com/questions/1921656/compiling-c-sharp-to-native
#44
2017-08-10, 11:32:48
Na, ob ein Disassembler jetzt die größere Hürde darstellt...
Ganon
2017-08-10, 11:40:04
Klar, unmöglich ist es nicht. Aber sofern auch alles nach Nativ kompiliert wird, ist es wesentlich komplizierter. Gerade Aufgrund von Inlining und Co. Da geht schon gut und gerne mal die ganze Struktur flöten.
Mr. Lolman
2017-08-10, 11:40:56
Ich glaub schon. Assembler muss man auch mal lesen können...
#44
2017-08-10, 11:51:01
Klar, unmöglich ist es nicht. Aber sofern auch alles nach Nativ kompiliert wird, ist es wesentlich komplizierter. Gerade Aufgrund von Inlining und Co. Da geht schon gut und gerne mal die ganze Struktur flöten.

Was bei trivialem Code (meine Annahme, nach allem was hadez16 gesagt hat) halt trotzdem nicht schwer ist...
Ich glaub schon. Assembler muss man auch mal lesen können...
Man kann auch nach C dekompilieren. (https://derevenets.com/examples.html)

Davon auszugehen, dass jemand kein C lesen kann bietet mmn. nicht so die krasse Sicherheit, wenn die Prämisse ist, dass da jemand motiviert ist an den Quellcode zu kommen.
hadez16
2017-08-10, 12:16:03
.Net Native scheint das Mittel der Wahl zu sein: https://stackoverflow.com/questions/1921656/compiling-c-sharp-to-native

Habe ich mir angesehen, danke!
Hier privat habe ich nur VS 2015 Express, und Dot Net Native scheint Windows 10 vorauszusetzen...

https://stackoverflow.com/questions/31981569/how-to-configure-net-native-in-visual-studio-2015
Exxtreme
2017-08-10, 12:46:34
Habe ich mir angesehen, danke!
Hier privat habe ich nur VS 2015 Express, und Dot Net Native scheint Windows 10 vorauszusetzen...

https://stackoverflow.com/questions/31981569/how-to-configure-net-native-in-visual-studio-2015
Hol dir die VS 2017 Community. Die entspricht in etwa der Professional und ist kostenlos für Privatanwender und Kleingewerbe.

https://www.visualstudio.com/de/downloads/
hadez16
2017-08-10, 12:53:16
Hol dir die VS 2017 Community. Die entspricht in etwa der Professional und ist kostenlos für Privatanwender und Kleingewerbe.

https://www.visualstudio.com/de/downloads/

Ah, okay, danke!
Ich weiß gerade nicht, weshalb ich das nicht direkt geladen habe.
Damit kann ich Dot Net Native kompilieren? Ich schau's mir an....

Ich habe den Versuch gestartet (ich programmiere seit 7 Jahren C#) meine Logik in ein C++ CLR zu packen. #BlutdruckOver9000
Exxtreme
2017-08-10, 12:59:17
Dot Net Native funktioniert derzeit nur bei aktuellen Windows Store Apps. Und die laufen nur mit Windows 10, ältere Windows Versionen haben das nicht.

Und C++ CLI/CLR/CLX ist nicht dazu gedacht, dass man sein Programm damit verschleiert. Ist halt eine potentielle große Fehlerquelle mehr und der Aufwand ist auch größer.
][immy
2017-08-24, 08:20:27
Dot Net Native funktioniert derzeit nur bei aktuellen Windows Store Apps. Und die laufen nur mit Windows 10, ältere Windows Versionen haben das nicht.

Und C++ CLI/CLR/CLX ist nicht dazu gedacht, dass man sein Programm damit verschleiert. Ist halt eine potentielle große Fehlerquelle mehr und der Aufwand ist auch größer.
Ist nicht eines der Probleme von .net nativ das man die Möglichkeit verliert den code auf jeder anderen Maschine mit .net auszuführen?

Grundsätzlich zu dem problem, man sollte am besten gar nicht obfuskieren. Macht eigentlich nur Probleme. Und wenn dann nur code der z.b. Für die Lizensierung verantwortlich ist. Wirklich sicher ist der code damit nicht, aber die hürde ist einfach größer.
Man könnte natürlich auch no so weit gehen den code per logic zu erzeugen, zu kompilieren und zu laden das wäre aver zu viel des guten.