Erfahrung mit .NET Reactor?

Guten Tag,
ich bin momentan am überlegen wie ich am besten den Code verschlüsseln könnte, um diesen vor Dissasemblern zu schützen.
Habe ein bisschen gesucht und den .NET Reactor gefunden, welcher ziemlich gut sein soll.
Nun ist meine Frage, ob vielleicht jemand hier mit diesem Sicherheits-Tool Erfahrung hat oder wie ihr ihn beurteilen würdet.
Denke wenn nicht allzuviel dagegen spricht werde ich mir dafür eine Lizenz anschaffen.

Infos zum .NET Reactor gibt es hier: http://www.eziriz.com

Vielen Dank im Voraus!

Hallo djCalypso,

vielleicht findest du in [FAQ] .net Assembly vor Disassembling schützen Antworten auf deine Frage.

herbivore

Hallo herbivore,
habe mich vorher schon damit auseinandergesetzt und einige Stunden damit verbracht zu schauen was es für kostengünstige alternativen gibt.

Bisher war dort allerdings nur eine kurze Meinung zu dem .NET Reactor von "burning snow".

Danke dennoch ^^

Hallo djCalypso,

ich kann das Tool nur empfehlen. Ich Arbeite selbst seit einem Jahr damit und bin sehr zufrieden. Der Support ist auch spitze.

Gruß
Pascal

Hallo Pascai,
gab es mit .NET Reactor denn schon einmal Probleme?
Was mich nur wundert, das ich bei Google kaum Feedback zu .NET Reactor finde.

MfG Calypso

Hallo djCalypso,

ein Problem gabe es nicht direkt. Ich wollte eine Funktion erweitert haben. Dies wurde dann umgesetzt. In einer späteren Version ging dann der Menupunkt nicht mehr. Inerhalb von 4 Stunden hatte ich eine neue Version wo der Fehler behoben war. Auch Fragen zwischendurch werden sehr schnell und ausführlich behandelt.

Gruß
Pascal

Hallo Pascal,

Danke für den Tipp !

Der .Net Reactor sieht ja Klasse aus, den werde ich mal testen. Und auch nicht so teuer.

Beim Dotfuscator Community Edition stört mich :

• Strings und Texte werden nicht verschlüsselt.
• Man kann trotzdem disassemblieren, wenn auch nicht sehr verständlich
• Bei Start per Kommandozeile kommt immer eine Meldung. Das stört besonders wenn man den mehrfach in einer Batchdatei aufruft.

Grüße Bernd

Hallo!

Weis jemand, ob man in einem mit dem .NET Reactor bearbeiteten Programm noch mit Reflection intern arbeiten kann, z.B. für PlugIns?

@ tom-essen:

Ich denke mal das man das alles im .NET Reactor einstellen kann.
Du kannst dir ja mal die Testversion auf der Webseite herunterladen und testen.

Ich war ziemlich begeistert das soweit alles klappt. Allerdings hatte ich auch so meine b edenken warum man so ein Tool kaufen sollte, welches

a) kaum bekannt ist
b) ziemlich billig
c) mehr kann wie die teuren Varianten

Aber wenn ja soweit nie Probleme auftraten werde ich mir einfach mal eine Lizenz kaufen und das ausgiebig testen 🙂

Vielen Dank nochmal an Pascai für dein Feedback.

MfG Calypso

Hallo tom-essen

Net Reactor hat einen Speziellen Modus um DLL Dateien zu Schützen.
Alle public Methoden werden aus der DLL nicht verschlüsselt, oder besser der Methodenname wird nicht verändert. Daher geht auch alles per Reflection was auf public Methoden zugreift.

Gruß
Pascal

Hallo,

nun ist doch schon eine Zeit vergangen und wollte nachfragen, wie der ein oder andere Test ausgefallen ist? Es wollten sich doch einige dieses Hilfsmittel anschauen, gibt es bereits Erfahrungsberichte?

Ist es weiterhin zu empfehlen? Ja/nein? warum, warum nicht?

lg Lion

Hallöchen,

also ich habe mich letzten Monat auch dazu entschieden, den .NET Reactor zu kaufen.
Bisher konnte ich auch nichts daran beklagen - im Gegenteil.

Zu dem Preis findest du solche Software in diesem Segment nicht, und der kann (was ich brauche) alles.

Auch das Visual Studio-Plugin macht es einem einfach, in einem Projekt automatisch mehrere Assemblys zu obfuscaten, zu signieren und und und...

Für die verschiedenen Typen (DLL, Anwendung...) bietet der Reactor auch eigene Konfigurationen an.

Zusätzlich sind noch tools wie

• Stack Trace Obfuscator ("entschlüsseln" von Trace-Meldungen aus Fehlern)
• Lizenzsystem (mit / ohne Aktivierungszeugs)
• ShareIt Modulgenerator
• NecroBit verschlüsselung (wenn ich mich recht erinnere wird die Assembly in ner Nativen Windows-EXE verschlüsselt, also kommt man mit nem Disassembler nicht mehr so schnell ran)

enthalten.

Alles in allem - kann ich von mir behaupten - ein super tool!

Mfg,
Daniel

Aber wahrscheinlich demnächst überflüssig.

www.microsoft.com/SLPS/downloads.aspx

Zumal , wie mir soeben bestätigt wurde, im MSDN Premium eine Basic Lizenz enthalten ist.

Klingt erstmal nicht schlecht. Wird aber erst dann interessant, wenn man MSDN Premium hat und/oder der Preis für das Tool stimmt.

Insofern kann ich, auch ein begeisterter .NET Reactor Besitzer, mich erstmal entspannt zurücklehnen.

Ich habe heute mal die Shareware-Version von .NET Reactor getestet, habe allerdings ein paar Fragen dazu. Vielleicht kann mir hier jemand weiterhelfen?

1. Zur Shareware-Version: Sehe ich das richtig, dass die Shareware-Version den vollen Funktionsumfang zur lizensierten Version hat, nur mit dem Unterschied, dass Registrierungs-Aufforderungen eingeblendet werden ("Nagware") und dass es keinen offiziellen Support gibt?

2. Ich habe versucht, meine "obfuscierte" Anwendungsdatei mit Reflector zu öffnen, aber es kam nur eine Fehlermeldung. Soweit, so zufriedenstellend. Aber kann ich mir dadurch sicher sein, dass Passwort-Strings nicht mehr ausgelesen werden können, und dass andere, mir unbekannte Programme, meinen Quelltext nicht wieder herstellen können?

Ansonsten macht .NET Reactor auf mich einen viel versprechenden Eindruck. In Hoffnung auf Antwort,

Jack

was für eine Shareware Version?

Die 5.1.0.0 ist doch frei 🤔

was für eine Shareware Version?

Die 5.1.0.0 ist doch frei 🤔

...Wo siehst du eine Version 5.1.0.0? Auf www.eziriz.com ist die höchste Version 3.7.1.0 und bei "Type" steht "Demo/NagScreen". Meine Frage bezieht sich auf dieses "Demo/NagScreen".

edit: Ach, jetzt sehe ich, was du meinst. Du sprichst vom .NET Reflector, hier geht es aber um den .NET Reactor. 🙂

edit2: OK, mit der unregistrierten Reactor-Version wird beim Start eines "obfuscierten" Programm ein Hinweis eingeblendet, dass ein unregistriertes .NET Reactor verwendet wurde.

edit: Ach, jetzt sehe ich, was du meinst. Du sprichst vom .NET Reflector, hier geht es aber um den .NET Reactor. 🙂

oh, sorry hab mich verlesen 8o

Hi,

2. Ich habe versucht, meine "obfuscierte" Anwendungsdatei mit Reflector zu öffnen, aber es kam nur eine Fehlermeldung. Soweit, so zufriedenstellend. Aber kann ich mir dadurch sicher sein, dass Passwort-Strings nicht mehr ausgelesen werden können, und dass andere, mir unbekannte Programme, meinen Quelltext nicht wieder herstellen können?

in diesem Fall ist ja Standardmäßig die "NecroBit" Verschlüsselung aktiv, die die .NET - Assembly in eine Win32 Exe "packt".

NecroBit is a powerful protection technology which completely stops decompilation. NecroBit replaces the CIL code within methods with encrypted native code. This way it is not possible to decompile/reverse engineer your method source code.

Daher kann dein Quelltext nicht mehr wiederhergestellt werden, da es ja keine .NET Assembly mehr ist, die ausgelesen oder disassembliert werden könnte.

Wenn du auf alle Fälle sicher gehen willst, kannst du ja in den Verschlüsselungs-Einstellungen noch explizit die String-Verschlüsselung und Codeverschleierung aktivieren, falls nicht schon geschehen.

Dann sollten auch Strings sicher sein.

Vg,
Daniel

Hallo!

Sehe ich das richtig, dass man den .NET Reactor aus Deutschland nur per Kreditkarte kaufen kann, obwohl PayPal, (Auslands-)Überweisung, ... angeboten werden?

Gibt's das nur über den Hersteller?

Da die aus deutschland sind, solltest Du da vielleicht mal direkt nachfragen.

http://www.eziriz.com/contactus.htm

Hallo!

@FZelle:
Danke für den Tipp, das hatte ich gar nicht gesehen.
Habe aber mittlerweile per Karte eines Bekannten bestellt, nach weniger als 1min. war die Lizenz-Datei per Mail gekommen.

Hallo,

ich hatte das schon in einem anderen Thread erwähnt, ich kann euch vom .Net Reactor nur abraten. Ich habe ca eine halbe stunde gebraucht um an den Quellcode einer .Net Reactor geschützten Anwendung zu kommen. Und ich bin kein professioneller Reverser oder so.

Gruß Kalleberlin.

PS: Wer mir nicht glaubt, kann mir gerne eine geschützte Assembly schicken 😁

@Kalleberlin:

Kannst du uns auch verraten wie du das angestellt hast? Die Aussage alleine langt mir persönlich nicht.

Hallo burning snow,

mit einem Debugger + anderen,kleinen nützlichen Tools. Das ich hier jetzt keine ausführliche Anleitung hinschreibe, verstehst Du sicherlich 🙂

Gruß Kalleberlin

Hallo Kalleberlin,

Das ich hier jetzt keine ausführliche Anleitung hinschreibe, verstehst Du sicherlich 🙂

Die Schutzeinstellungen des .Net Reactors könntest Du aber mitteilen?

Die Schutzeinstellungen sind nicht relevant (soweit ich das weiss, bin wie gesagt da nicht unbedingt der Profi 😉 ). Das .Net Reactor "so einfach" zu decompilen geht, liegt einfach daran das die Anwendung nach dem starten ungeschützt im speicher liegt. Das ist (.Net Reactor) prinzip bedingt. Andere Obfuscatoren / Packer gehen da ein schritt weiter.

Gruß Kalleberlin

Die Schutzeinstellungen sind nicht relevant

Interessant - danke für die Ergänzung.

Die Schutzeinstellungen sind nicht relevant (soweit ich das weiss, bin wie gesagt da nicht unbedingt der Profi 😉 ). Das .Net Reactor "so einfach" zu decompilen geht, liegt einfach daran das die Anwendung nach dem starten ungeschützt im speicher liegt. Das ist (.Net Reactor) prinzip bedingt. Andere Obfuscatoren / Packer gehen da ein schritt weiter.

Gruß Kalleberlin

Inwiefern gehen andere Obfuscatoren da weiter? Bzw. welche anderen gehen da weiter?

Die Dotfuscator Com edition z.B. ist da besser.

@Kalleberlin:
Irgendwie kann ich nicht nachvollziehen, in wie weit du den Schutz des .Net Reactors umgangen hast. Ich möchte keine Anleitung o.ä., aber meinst du nun damit, dass du an das reine .Net Assembly gekommen bist? Denn der .Net Reactor verwurschtelt ja wie alle anderen Obfuscatoren den IL-Code, und das wirst du ja nicht wiederhergestellt haben ...

Das endergebnis ist eine Assembly im Reflector die man lesen kann, mit methoden namen etc. pp.

Wenn ihr mir nicht glaubt - kein Ding. Ich wollte lediglich darauf hinweisen das .Net Reactor definitiv keine sichere Lösung darstellt, wenn ein unerfahrener "Reverser" so schnell und so leicht an den Code kommt.

Ich zieh mir das ja nicht aus den Fingern. Ein wenig googeln, ein wenig lesen und schon geht das.

Gruß Kalleberlin

Das ich dir nich glaube, habe ich nicht gesagt. ich kann es mir nur schlecht Vorstellen, da der .Net Reactor genauso wie der Dotfuscator die Namen der Funktionen/Variablen durch ein Buchstaben- und Zahlenwirrwarr ersetzt, und wie man daraus irgendwas Sinnvolles herausbekommen kann ist mir schleierhaft.

Das ich dir nich glaube, habe ich nicht gesagt. ich kann es mir nur schlecht Vorstellen, da der .Net Reactor genauso wie der Dotfuscator die Namen der Funktionen/Variablen durch ein Buchstaben- und Zahlenwirrwarr ersetzt, und wie man daraus irgendwas Sinnvolles herausbekommen kann ist mir schleierhaft.

Ausser die String-Verschlüsselung / Verschleierung ist im Reactor deaktiviert 🙂

Wobei dann auch "Die Schutzeinstellungen sind nicht relevant" nicht zutrifft 😉

Soweit ich weiß kann der Dotfuscator in der Com Edition NUR die String-Verschleierung, oder? Daher sollte es bei dem ja dann auch so einfach sein 😉

Wer Passwörter etc. als Klartext in einer Anwendung deklariert ist selbst Schuld, wenn diese dann zu Mißbrauchszwecken benutzt werden. Also ist die Stringverschlüsselung nicht sonderlich relevant.
Ein Obfuscator hat, wenn ich das Prinzip richtig verstanden habe, die primäre Aufgabe den Programmablauf für den Menschen schwer nachvollziehbar zu machen, dadurch werden Funktions- und Variablennamen durch einen Buchstaben- Zahlensalat ersetzt, was die Funktionalität des Programmes aber nicht einschränkt.
Der Dotfuscator kann in der Com.-Edition nur das Verschleiern der Funtionnamen und der Variablen, für alles andere wie Stringverschlüsselung etc. muss man Bezahlen 🙂

Ich hab im Anhang kurz ne Exe-Datei (gepackt) angehängt...
Ist nur ein Simples Windows-Fenster, in deren Klasse 3 String-Variablen sind, welche im Konstruktur gesetzt werden.

@Kalleberlin
Mich würde interessieren, ob man da an die Variablennamen der 3 Strings sowie den Inhalt der Strings wirklich rankommt.
Kannst du das mal kurz versuchen? 😉

Hab die EXE mitm .NET Reactor (Stringverschlüsselung An, NecroBit An, Programmverschleierung An) geschützt.

Hallo robbyrc,

ich schätze mal die Strings heissen so:

"vmz1934"
"blabla"
"12345"

Ich hab jetzt mal auf die Uhr geschaut. Dauer ca 7 min.

Ich muss aber fairer weise sagen das die Methoden namen noch nicht ganz korrekt waren, was beim letzten Test aber noch gestimmt hat. Ich glaube als ich das das erste mal getest habe, war das Version3.6. Welche hast Du verwendet?

Gruß Kalleberlin.

Stimmt 😉

Daaaas is jetzt nicht so gut dass das doch so fix geht.
Ich habs mit Version 3.7 "geschützt" 😉

Wie gesagt, ich hab von der Materie nicht wirklich ein Plan. Jemand der das regelmässig macht, und wirklich in der Materie steckt, lacht sich über solche "Verschleierungs methoden" schlapp.

Gruß Kalleberlin

Deshalb hatte ich ja auch weiter oben die MS Lösung gezeigt.

Wenn man da nur Die codeprotection benötigt, sind es "nur" €500,-, wenn
man nicht sowieso schon ein msdn Abo hat.

Und das ist derzeit nicht zu knacken.

Edit:
Sehe gerade, MS hat den Preis auf €750,- erhöht.
Und das gild auch "nur" für die version mit maximal 5 Routinen.
Aber das reicht i.a. aus, denn wie ein Propertyzugriff erfolgen soll, brauch niemand
zu schützen.
Aber wir schützen damit dann eine Routine die unsere Verschlüsselung initialisiert.

Und das ist derzeit nicht zu knacken.

👅

Hallo,

ich kann da Kalleberlin was die Sicherheit des Reactors betrifft leider nur zustimmen.

Allerdings hängt die Schutzwirkung schon ein wenig von den Einstellungen ab. Die Obfuscation an sich (so rudimentär sie verglichen mit Konkurenzprodukten evtl. sein mag) wurde bei meinen Versuchen nicht entfernt. Sie stellt in meinen Augen aber auch kein allzu großes Hindernis mehr dar. Die Strings hingegen scheinen auch im Speicher steht's in unverschlüsselter Form vorzuliegen und sind daher leicht lesbar (nur im Application Mode).

Was zumindest Crackversuche erschweren kann ist

a) Die eigenen Assemblies mit einem starken Namen zu schützen und

b) Im Reactor die Option "Strong Name Removal Protection" zu aktivieren

Dadurch sollte es schwieriger sein den Starken Namen zu entfernen und somit auch die Assembly zu verändern.

Die wichtigste Einstellung aber ist Application vs. Library Mode. Ich denke mal alle Assemblies die du getestet hast, Kalleberlin, waren im Application-Mode geschützt?

Dieser Schutz ist bis zur Obfuscation wie schon angesprochen, relativ leicht zu umgehen.

Beim Library Mode ist das jedoch nicht der Fall. Hier scheint seitens des Reactors wesentlich mehr zu geschehen und es werden meines Erachtens nach tiefgreifendere Veränderung an der zu schützenden Assembly vorgenommen (necroBit unbedingt aktivieren).

Diese lässt sich später zwar bspw. im Reflector öffnen, sorgt dort jedoch beim öffnen der Methoden für Programmfehler.
Auch mit Dile, also auf msil Ebene, ist der Inhalt der Methoden verkrüppelt oder nicht mehr vorhanden.

Der Library Mode ist zwar eigentlich für Libraries gedacht, es spricht jedoch nichts dagegen ihn auch für Programme einzusetzen (wie es der Programmautor im übrigen auch tut).

Nun kann man sich natürlich fragen, warum es den Application Mode überhaupt gibt...

Was aber viel wichtiger ist, ist die Frage wie sicher denn nun der Library Mode wirklich ist. Auf den ersten Blick wirkt er nicht schlecht.

Kann einer von euch mehr dazu sagen (insbesondere Kalleberlin)?

Gruß gurgel

@Kalleberlin:

Schonmal angeschaut?

Wer Passwörter etc. als Klartext in einer Anwendung deklariert ist selbst Schuld

Ich weiß bis heute nicht, wie man das bei einer Verbindung zu einer festgelegten Datenbank sonst machen soll...

Der Library Mode ist zwar eigentlich für Libraries gedacht, es spricht jedoch nichts dagegen ihn auch für Programme einzusetzen (wie es der Programmautor im übrigen auch tut).

Kann ich also jetzt mein Datenbankpasswort im Quelltext im Klartext abspeichern? 🙂

Jack

Wer Passwörter etc. als Klartext in einer Anwendung deklariert ist selbst Schuld
Ich weiß bis heute nicht, wie man das bei einer Verbindung zu einer festgelegten Datenbank sonst machen soll...

Gut, dazu fällt mir momentan auch keine bessere Möglichkeit ein 🤔 Aber bei meiner Antwort dachte ich wirklich eher an Passwörter, Seriennummer etc. und nicht an ConnectionStrings 🙂

Kann ich also jetzt mein Datenbankpasswort im Quelltext im Klartext abspeichern?

Die "Sicherheit" eines solchen Vorgehens wird wohl ebenso "gut" sein, wie wenn du selbst den String in der Assembly verschlüsselt abspeicherst und zur Laufzeit entschlüsselst.
Denn: Auch .net Reactor muss irgendwo das Passwort zum entschlüsseln der Strings ablegen.

Hacker werden also an das Passwort kommen, DAUs wohl eher nicht. Natürlich hängt es auch davon ab, wie gut das Passwort "versteckt" werden kann.

MfG gurgell

ich habe mir auch den .net reactor zugelegt.

ich bin leider schon auf 2 einschränkungen gestoßen im application-modus.

• es gibt fehler, wenn man eine windows-anwendung im application-modus schützen will, die auf einen webservice zugreift.

• es gibt fehler, wenn man eine windows-anwendung im application-modus schützen will, die einen eigenen settings provider benutzt.

es gibt 2 workarounds dafür: die anwendung im library-modus schützen oder, fehlerverursachenden stellen (also zugriff auf webservice und zugriff auf settingsprovider) in Dlls auslagern und getrennt schützen.

leider sehr unbefriedigend. der hersteller hat immer noch keine lösung dafür, trotz mehrerer anfragen und detaillierter problembeschreibung.

leider sehr unbefriedigend. der hersteller hat immer noch keine lösung dafür, trotz mehrerer anfragen und detaillierter problembeschreibung.

Antworten die dir wenigstens?
Habe dort schon zwei Supportanfragen hingeschickt und nicht eine Antwort erhalten.

Beste Grüße, Max

Das "Problem" haben aber viele der andren Obfuscatoren auch.

Da Webservices usw. ja über Serialisierung arbeiten, funktioniert das ganze natürlich nicht mehr, weil

1. die Assembly durch das NecroBit verfahren keine wirkliche .NET assembly mehr ist

2. durch die Obfuscation die Bezeichner usw. ja geändert werden.

Um Problem 2 zu umgehen, gibt es bei den Settings im Projekt unter

"2. Protection Settings"
"Obfuscation Settings"

den Punkt "Obfuscate Public Types" und "Obfuscate Serializable Types".
Damit werden Typen, die öffentlich sind, z.B: für Serialisierung usw, nicht obfuskiert.

Das 1. Problem hängt halt (leider oder auch nicht leider 😉 ) mit dem Necro-BIt verfahren zusammen.

Ich habs mir auch inzwischen angewohnt, Webservices usw. in eigene DLLs auszulagern, da ich diese dann auch einfacher durchtauschen kann.

leider sehr unbefriedigend. der hersteller hat immer noch keine lösung dafür, trotz mehrerer anfragen und detaillierter problembeschreibung.
Antworten die dir wenigstens?
Habe dort schon zwei Supportanfragen hingeschickt und nicht eine Antwort erhalten.

Beste Grüße, Max

bisher hat er (scheint ne 1-mann-firma zu sein) immer innerhalb kurzer zeit geantwortet. bei meinem jetzigen problem mit dem custom-settings-provider hat er seit über 1 woche nicht geantwortet.

wann hast du ihm ne mail geschrieben? vielleicht ist er ja einfach nur verhindert, weil er im urlaub ist oder krank. bisher hat er nicht den eindruck gemacht, sich vor den problemen drücken zu wollen. der support ist eigentlich sehr gut. nur leider scheitert es immer noch an meinen beiden beschriebenen problemen. und dafür hat er noch keine befriedigende lösung.

was mich jetzt aber sehr verunsichert ist, dass das der .net reactor laut Kalleberlins aussage sehr unsicher sei. kommt man wirklich so einfach an die strings im geschützten zustand? ist der gesamte quellcode auch wieder einsehbar?