Zitat von cprogrammer
Als Assemly existiert eine
AgileDotNetRTPro.dll, welche mit dem ursprünglichen Projekt nix zu tun hat.
Die letzte static Methode wurde hinzugefügt.
Und das verstehst, wenn Du Dir einfach 5 Min das Zeug des Herstellers durchliest: das ist ein durch den Obfuscator erstellter Code-Container, damit Du nicht an den originalen Source Code kommst.
Da Du hier offenbar versuchst ein kommerzielles Produkt zu Reverse-Engineeren, was in der EU verboten ist, und nicht nur für Dich sondern leider auch für myCSharp unschöne Folgen haben kann, mache ich hier dicht.
Nochmal zurück zum Dotfuscator:
Was hast Du alles public und internal?
Ein Obfuscator kann natürlich nur das verändern, worüber er auch die volle Kontrolle hat.
Alles, was von außen erreichbar bleiben muss (z.B. public oder protected in public class) muss auch genau so erreichbar bleiben, wie Du es bei der Arbeit vorgesehen hast, entsprechend wird der Obfuscator nichts daran ändern.
Wenn Du also alles public hast, dann wird auch nichts an diesen Membern geändert.
Zitat von cprogrammer
Quasi eine Art synamisches Linken übers Internet.
Das ist Quatsch, weil Dir das nichts bringt ausser das Problem zu verschleiern.
Die DLL ist weiterhin physikalisch verfügbar und damit auslesbar. Aufwand ohne Nutzen.
Die einzige Möglichkeit eines Schutzes ist, dass die Anwendung nicht verteilt wird.
Ein Benefit von Web-Applikations über HTTP: der Nutzer hat niemals Zugriff auf die App.
Alles andere: nicht möglich.
Ist das machbar ?
Aber Fragen mit "ist xyz machbar" sind ohnehin Käse. Alles ist machbar, alles nur eine Frage des Aufwands respektive Budgets.
Ganz ehrlich: die aller meisten Leute überschätzen die Bedeutung ihres Quellcodes.
Ich seh Firmen, die Code von Open Source Projekten übernehmen und dann extra einen Obfuscator drüber laufen lassen, weil es ach so wichtig sei.
Kann man verstehen bei fundamentalen Algorithmen, den nativ umzusetzen.
Aber nicht bei 0815 Code.
Nein, das geht nicht - das ist die Natur der Sache von Runtimes wie .NET oder Java, die Zwischensprachen - im Falle von .NET ILCode - verwenden.
Egal welchen Obfuscator Du nutzt - alles kann zurück geholt werden.
Passt Dir das nicht, dann musst Du auf native Programmierung wie zB C
oder C++
(nicht C++.NET
) wechseln.
Oder Du schaust Dir .NET Native AOT an (was noch nicht stable ist).
Dieses Thema kommt mehrmals im Jahr hier im Forum zum Schein.
Verwende die Suchfunktion für mehr Infos - mit gleichem Ergebnis wie in meiner Antwort hier.
Habe bei google leider keinen passenden Beitrag gefunden.
Schwer das zu glauben, bei einfachsten Suchbegriffen 🙂Google Suche nach ".net license protection"
Davon abgesehen gab es auch schon dutzende Themen hier im Forum dazu.
Zusätzlich: Forumsuche nach "Obfuscator"
Primär geht es mir nur darum, dass sich die Datei nur öffnen lassen soll, wenn die korrekte licence Datei im Projektordner hinterlegt ist.
Eine Exe lässt sich immer starten; das wirst Du nicht verhindern können.
Eine License-Validierung beendet dann aber wieder den Prozess.
Der Anwendungsordner wäre ohnehin auch der falsche Platz dafür, denn ein Nicht-Admin hat keine Schreibrechte im Programm-Verzeichnis; kann also auch keine Lizenz dort als Datei ablegen.
Das Thema Obfuscation kommt hier im Forum alle halbe Jahr hoch und zeigt immer wieder: lohnt sich nicht. Hättest einfach ein paar Sekunden in die Suche stecken können 🙂Forumsuche nach "Obfuscator"
Mittlerweile gibt so gute Deobfuscators, dass jegliche Obfuscation mit sehr hoher Qualität aufgelöst werden kann.
Derjenige, der weiß, wie man an den ILCode kommt, der nimmt einfach nen Open Source Tool und hat in wenigen Minuten C# Code.
Die einzige wirklich sichere Variante ist ein nativer Weg, zB. mit Rust, C++ oder .NET Native (das seit .NET Core 3 (maßgeblich) über den sogenannten Ready to Run Weg funktioniert).
https://docs.microsoft.com/de-de/dotnet/core/deploying/ready-to-run
Abgesehen, dass das mit dem Deobfuscator nicht korrekt ist bringst Du nun "Kopierschutz" ins Spiel, von dem bisher nie die Rede war.
Das Thema Obfuscation jegliche Art wurde im gesamten Internet (und auch hier) schon hundert mal durchgekaut.
Der Thread ist fünf Jahre alt (und den Thread auszugraben macht auch wenig sinn) und wir haben zig weitere Thread zu dem Thema.
Es gibt keine technologische Änderung - abgesehen vom noch nicht vollständig verfügbaren .NET Native - sodass sich am Grundproblem von IL und den Tools drum herum nichts geändert hat.
Es wurde alles zum Thema Obfuscation - was es bringt und es es nicht bringt - gesagt 😃
Das Thema wurde ungefähr 42986423490324234 mal besprochen - und das vorsichtig geschätzt.
Bitte wenigstens 10 Sekunden die Forensuche oder Google verwenden. Wenigstens 10 Sekunden.
Beim Suchbegriff obfuscator hier im Forum findest Du über 150 Threads dazu.
Das Fazit ist: gar nicht.
Schutz vor Deobfuscation
[FAQ] DB-Password/Kennwort/Connection-String sicher speichern
Wenn Du ConnectionStrings brauchst, dann scheint es schon ein grundlegender Fehler bzgl. Architektur zu sein, dass die Anwendung direkt auf einen Datenbankserver zugreift und nicht über eine Server-Anwendung (zB ein REST-Service) dazwischen.
Eine solche Server-Anwendung wäre dann auch für eine individuelle Authentifizierung des Benutzers zuständig. Sowas sollte niemals die Datenbank übernehmen. Dafür ist sie nicht da; das kann sie auch nicht.
Das Prinzip dahinter ist eine ganz normale Client Server Architektur.
Nur, dass bei euch wohl der Server nur physikalisch und nicht als Anwendung vorhanden ist.
Schon gefühlte 1000 mal im Forum besprochen
[FAQ] NET Assembly vor Disassembling schützen (Obfuscator)
Alles zu diesem Thema wurde bereits behandelt - bitte in Zukunft die Forensuche nutzen.
Forumssuche nach Obfuscator
[FAQ] NET Assembly vor Disassembling schützen (Obfuscator)
Und hier hat sich nichts geändert die letzte Zeit.
PS: beim Thema Lizenzierung kann man niemals mit gutem Gewissen von "sicher" sprechen.
Habe die .NET Native Preview vor etlichen Monaten mal ausprobiert und weiß, das es irgendwann für Desktop-Anwendungen erscheinen soll, allerdings glaube ich das das noch lange dauern wird. Ich hoffe allerdings das du Recht hast und .NET Native sehr bald kommt. Bis dahin brauche ich aber trotzdem noch einen Obfuscator wie beschrieben.
Wir nutzen bei uns https://babelfor.net und hatten noch keine Probleme.
Ich denke gerade ein Obfuscator sollte sein Geld wert sein, wenn man ihn schon einsetzen will (selbiges gilt für ein AuthentiCode-Zertifikat).
Hallo zusammen,
ich suche einen guten Obfuscator, der verwendete dlls in meine exe hineinpacken kann und dabei den ganzen Code verschleiert. Ich benutze schon einige Zeit den Confuser (https://confuser.codeplex.com/). Die Verschleierung ist super, allerdings erkennen einige AntiVirusprogramme meine Programme fälschlicherweise immer als Virus an (Auch mit Einstellung Minimum). Unter anderem mit dieser Seite getestet https://www.virustotal.com/de/. Selbst ein komplett neu erstelltes Programm ohne eigenen Code wird nach der Kompilierung+Verschleierung als Virus erkannt. Ich habe auch schon eine Menge andere Obfuscatoren ausprobiert wie z.B. den .NET Reactor oder SmartAssembly. Leider haben alle das gleiche Problem. Die Viren die erkannt werden und welche AntiVirusprogramme erkennen variiert nur. Bin schon ziemlich am verzweifeln. Solche Assemblys mag ich echt ungern anbieten, aber komplett ohne Schutz möchte ich diese auch nicht anbieten. Lieber hätte ich eine kostenlose Variante, aber wenn es nur eine kommerzielle Variante tut, dann geht das auch in Ordnung. Hoffe ihr könnt mir helfen. Vielen Dank im Voraus.
Mfg,
PsyPath
ich könnte mir vorstellen, dass man die .NET Compiler Platform Roslyn nutzen könnte, um selbst einen Quellcode-Obfuscator zu erstellen.
Mit Roslyn könnte man sowas sehr leicht umsetzen. Identifier umbenennen, whitespaces entfernen, unnötige Klammern hinzufügen, konstante Ausdrücke verkomplizieren, vielleicht noch schön hässliche gotos einfügen sollten sehr einfach sein
Hallo cyntonix,
ich könnte mir vorstellen, dass man die .NET Compiler Platform Roslyn nutzen könnte, um selbst einen Quellcode-Obfuscator zu erstellen. Denn ...
The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs. It enables building code analysis tools with the same APIs that are used by Visual Studio.
Wobei ich es - was die Verschleierung generell angeht, egal auf welcher Ebene - die Meinung meiner Vorredner teile, dass dies nicht viel bringt. Das Thema Obfuscation ist so alt wie .NET und - in allen wesentlichen Aspekten - in den aus der FAQ [FAQ] NET Assembly vor Disassembling schützen (Obfuscator) verlinkten Threads behandelt, auch was Sinn- und Unsinn sowie die Grenzen angeht.
Nur so am Rande: Bei der Obfuscation von Assemblies ist es immerhin möglich, den IL-Code (häppchenweise) so zu verändern, dass es kein passenden C# Konstrukt mehr gibt, dss diesem IL-Code-Häppchen direkt (d.h. ohne Compileroptimierungen) entspricht (Beispiel: Swap von zwei Variablen durch über den Stack ohne explizite Variable, in IL geht das, lässt sich aber nicht direkt in C# ausdrücken, siehe Modhinweis in Das Programmier-Spiel: nette Übungsaufgaben für zwischendurch). Bei der Obfuscation von Quellcode ist diese Möglichkeit per se nicht gegeben.
herbivore
Vielleicht bin ich zu blöd...
Welchen zusätzlichen Schutz versprichst du dir davon?
Ob du den Source randomized oder ob der Obfuscator das Assembly randomized kommt doch unterm Strich auf das gleiche raus?
Mir ist bekannt dass es keinen 100% Schutz gibt. Dennoch möchte ich es jemand schwer machen, der den Code verändern möchte.
Bezüglich Referenzen:
Hier gibt es kein Problem, da alles wie beschrieben in einer Datei vorhanden sein muss.
Es würde mir reichen wenn alle Variablen und Methoden umbenannt werden, aber wie gesagt, können die aufgelistet Obfuscator die nur auf DLLs bzw. EXE.
Naja ein Obfuscator funktioniert ja so, dass er zB eine Methode umbenennt und auch dahingehend alle Referenzen, die diese Methode nutzen.
Der Name ergibt sich aus einem Zufallsmuster.
Wie soll nun eine einzelne Datei verschleiert werden, wenn dann die Konsumenten die Referenzen auf eine Methode nicht mehr finden können, einfach weil der Name nun irgendwas ist?
Sinn macht es also in diesem Fall nur, dass die Methode und die Klasse die gleichen Namen haben und nur die jeweiligen Inhalte verschleiert werden.
Da frag ich mich aber wiederum: das ist doch binnen Minuten selbst mit menschlicher Kraft wieder auf lesbaren Code zu bringen.
Davon abgesehen, dass 99% aller Obfuscators schon lange geknackt sind und es schon lange Software gibt, die verschleierten Code lesbar machen:
was erhoffst Du Dir durch das verschleiern einer einzelnen Datei?
Hallo Zusammen,
ich suche einen Obfuscator welcher die Sourcedateien verändert.
Ich habe schon einige getestet (List of obfuscators for .NET), leider gehen diese davon aus, dass eine DLL oder EXE geschützt wird.
Hintergrund:
Die Dateien werden in einem Programm als API-Erweiterungen geladen. Hier ist es nur möglich eine *.cs-Datei zu laden.
Ich habe auch schon getestet eine DLL zu kompilieren und diese dann zu obfuscaten, danach das Decompilat zu laden, aber hier klappt auch was nicht, da in dotPeek einige Issues angezeigt werden.
Hat jemand Tipps bzw. einen möglich Workflow?
Danke im Voraus.
Hallo Community,
Ich bin gerade dabei eine Schadsoftware zu untersuchen die einen besonderen Trick drauf hat und um den eigentlichen Kern des Codes vor den Augen anderer zu verbergen.
Grob gesagt führt die Malware ein festes byte Array mit das bösärtigen Code enthält. Dieses wird nun in einen Speicherbereich kopiert wird der vorher mittels der API Funktion VirtualAlloc reserviert wurde. Anschliessend wird sich ein Methodenzeiger auf den Speicherbereich besorgt und ausgeführt.
Das ganze sieht in etwa wie folgt aus.
public delegate void CallerDelegate();
private static void Main()
{
byte[] fixedArray = new byte[]{11,24,13,4,6,...} // 4274 insgesamt
IntPtr handleMemory = VirtualAlloc(IntPtr.Zero, 65536u, 4096u, 64u);
Marshal.Copy(fixedArray, 0, handleMemory, 4274);
CallerDelegate malicousMethod = (CallerDelegate)
Marshal.GetDelegateForFunctionPointer(intPtr, typeof(CallerDelegate));
malicousMethod(); // das wars...
}
(Natürlicht nicht der Originalcode, dieser enthält jede Menge Nebelkerzen und wurde durch einen Obfuscator geschickt.)
Mir gelingt es derzeit nicht den Code im fixen byte Array lesbar zu machen. Ich gehe dabei im Moment davon aus das es sich um nativen IL Code handelt der mittels der Methode MethodBody.GetILAsByteArray in ein byte Array gewandelt wurde. (Evtl. ist diese Annahme jedoch falsch?) Diese Byte Sequenz in irgendeiner Form zurück zu transformieren(egal in was, IL String, AST, MethodInfo, etc.) ist jedoch scheinbar unmöglich. Die gängigen Decompiler schlucken nur ganze Assemblies, die Framework Methoden brauchen mitgelieferte Typeninformationen und Mono.Cecil ist dazu scheinbar auch nicht in der Lage. Sieht noch jemand einen Weg wie ich den Inhalt dieses byte Arrays freilegen kann ohne einen ganz neuen Dissambler zu schreiben?
Hallo Ayke,
hast du mal gesucht hier im Forum?
[FAQ] NET Assembly vor Disassembling schützen (Obfuscator)
Wenn du etwas anders meinst, als in der FAQ behandelt, sag bitte dem Team Bescheid. Da das sonst [Hinweis] Wie poste ich richtig? Punkt 1.1 betrifft, ist hier zu.
Gruss
Coffeebean
Ich hole den Thread mal wieder raus, weil ich kürzlich eine tolle Alternative zur Obfuscation gefunden habe: http://www.infralution.com/netencryptor.html
Das Produkt wurde hier Erfahrungen mit dem Infralution NetEncryptor (Obfuscator) auch schonmal angesprochen. Ich habe mir es kürzlich gekauft und konnte bisher keinerlei Probleme feststellen.
Damit werden .NET Reflector, ILSpy und Konsorten nutzlos 😃
Bitte in Zukunft die (Foren)suche verwenden ([Hinweis] Wie poste ich richtig? 1.1).
Wir hatten erst vor wenigen Tagen das gleiche Thema - und alles läuft aufs selbe Ergebnis raus: Wie vor dem Decompilen schützen?
[FAQ] NET Assembly vor Disassembling schützen (Obfuscator)
Und zur Passwortsache hilft ebenfalls die FAQ: [FAQ] DB-Password/Kennwort/Connection-String sicher speichern
X-Mal hier diskutiert worden.
Lösung: Geht nicht, erschwert nur den Aufwand, aktuell beste Lösung und zudem Opensource ->Confuser 1.9
Schutz vor Deobfuscation
WinRT Codesicherheit: Kann der "Quellcode" wie bei .NET angesehen werden? Welche Obfuscatoren gibts?
Obfuscator gesucht
Hey FabianVelbert,
Nutzt ihr einen Obfuscator?
DLL File erstellen und vor Einsicht in den Code schützen
Schutz vor Deobfuscation
und und und...
es gibt keine Möglichkeit sich zu schützen.
Gruss
Coffeebean
Danke für deinen Tipp. Ich werde mich dann mal näher mit "Obfuscator" beschäftigen. Mich wundert es nur, dass die Softwarehersteller bisher wohl noch nichts Schlaues entwickelt haben, um ihren Quellcode z.B. zu verschlüsseln. Wenn ich das richtig verstehe, kann man unter mehr oder weniger hohem Aufwand den Quellcode wieder lesbar machen, oder?
Das ursprüngliche Problem habe ich jetzt auch lösen können. Der Grund, warum mir keine Konsole angezeigt wurde, war der Eintrag CompilerOptions = "/t:winexe" bei CompilerParameters. Den Eintrag habe ich mal auskommentiert und es wurde alles angezeigt. Die Begründung hierfür fehlt mir zwar noch, da laut msdn "/t:winexe" dazu dient, ein Windows Programm zu erstellen, aber ich nehme es jetzt mal so hin.
Gruß
Hallo Schwarzwälder,
Ich versuche dadurch mein eigentliches Programm vor Reverse Engineering zu schützen.
sowas hatte ich mir schon gedacht. Normalerweise braucht man keine Angst vor Reverse Engineering zu haben, siehe die vielen ausführlichen Diskussionen in [FAQ] NET Assembly vor Disassembling schützen (Obfuscator).
Wenn du dein Programm vor unberechtigter Weitergabe schützen möchtest, schau dir mal Software mit Registrierungsschlüssel schützen. Das ist zwar auch nicht sicher gegen Profis, aber wir du sagtest, gegen die Leuten, die nicht so viel Ahnung davon haben, schon.
herbivore
Hallo theYoRecords, hallo zusammen,
ich stimme Abt zu, dass wir das Thema "obfuscation, wie sinnvoll es ist und welcher wohl der beste Obfuscator ist" nicht noch mal durchkauen sollten und bitte alle darum, sich daran zu halten.
Das Thema Deobfuscation ist aus meiner Sicht allerdings noch recht neu und wurde auf myCSharp.de bisher wohl nur in WinRT Codesicherheit: Kann der "Quellcode" wie bei .NET angesehen werden? Welche Obfuscatoren gibts? und auch dort nur am Rande behandelt.
Praktisch kenne ich mich damit leider nicht aus und weiß nicht, wie gut Deobfuscatoren tatsächlich arbeiten. Aber Grundsätzlich ist klar, dass auch der beste Obfuscatior am Ende nur CIL-Code erzeugen kann und daher eine Umkehrung in einem gewissen Maße immer möglich sein wird. Die Frage ist, wie gut menschenlesbar das Ergebnis ist. Die meisten Obsfucatoren werden möglichst viel Information, die ein Mensch zum Verständnis des Codes benötigt, also z.B. Variablennamen, möglichst rückstandsfrei entfernen. Und was weg ist, ist weg. Aus meiner Sicht kann ein Deobfuscator nur weniger kryptische Namen verwenden, aber nicht die Originalnamen wieder herstellen.
Manche Namen können allerdings nicht entfernt werden, ohne die Schnittstelle einer Assembly nach außen zu verändern. Diese Namen muss ein Deobfuscator gar nicht wiederherstellen, sondern die waren ja nie weg.
herbivore
Hallo,
Es gibt schon unzählige Threads zum Thema obfuscation, wie sinnvoll es ist und welcher wohl der beste Obfuscator ist.. Aber hier mal was anderes:
Gibt es eine Möglichkeit Programme aufzuhalten, die sich ums Gegenteil kümmern?
Ich habe vor ein Paar Tagen den Confuser kennengelernt, der an sich ein sehr guter Obfuscator zu sein scheint. Heute musste ich leider feststellen, dass es da ja z.b. NETDeob gibt, wodurch das ja alles noch weniger Sinn hat.
Mir war klar, dass obfuscation kein wirklicher Schutz ist. Aber dass 1 Klick reicht ist ja wirklich nicht mehr lustig..
Kennt jenand eine Möglichkeit so einer automatisierten Umkehrung vorzubeugen?
Hallo Let it Burn,
(hier im Forum wurde des Öfteren darüber gesprochen)
siehe [FAQ] NET Assembly vor Disassembling schützen (Obfuscator).
Allerdings gibt Kaspersky bei MethodInfo.Invoke eine Heuristik-Warnung aus
Wirklich alleine durch das MethodInfo.Invoke? Oder daher, dass Method.Invoke für Code aufgerufen wird, der (verschlüsselt) aus den Ressourcen geladen wurde?
Kann man das irgendwie verhindern, weil sonst jeder denkt, dass das ein Virus wäre?
Ich denke, dass man das nicht verhindern kann, denn du programmierst damit nunmal ein Verhalten, dass auch bei Schadsoftware verbreitet ist. Und solange du das tust, musst du immer damit rechnen, dass die Heuristikprüfung von Anti-Viren-Programmen Alarm schlägt. Selbst wenn du durch einen Trick den Alarm von Kaspersky verhindern könntest, könntest du dir nicht sicher sein, bei dem nächsten Virenprüfer (nach dem nächsten Update) alles unbeanstandet durchläuft.
herbivore
Guten Morgen zusammen,
ich habe 23 Produkte installiert und getestet. Dabei sind kostenlose- und pflichtige Produkte. Die bisher hier genannten Produkte sind teils gar nicht mehr kostenlos. Deshalb hab ich mich entschieden meine vier tägige Arbeit hier mal kurz zu posten.
Für mich war wichtig, dass die Lizenz nicht mehr als 150 Euro kostet. Jedoch ursprünglich war ich auf der Suche nach einem kostelosen Tool, ich habe es ja auch gefunden 😃.
Ich habe für mich folgende Kiterien angelegt:
Ich möchte darauf hinweisen, dass die Informationen sich nur auf meine Tests beziehen. Andere können evt. andere Erfahrungen berichten! Ich möchte auch keine Software abwerten sondern nur berichten! Ich möchte hier auch keine Werbung machen!
Alle Assemblies habe ich mit dem .NET Reflector 8.0 angeschaut und beurteilt.
Yano: Freeware; Stack Trace Verschlüsselung und Entschlüsselung vorhanden (sehr komfortabel); Quellcodeveränderung gut -> ist mein Favorit!
Rummage: Freeware; Stack Trace Verschlüsselung vorhanden jedoch keine Entschlüsselung - Mapping Datei wird jedoch erstellt; Quellcodeveränderung gut (Umbennenung in bekannte Wörter)
Eazfuscator.NET: Preis 399 Dollar; Stack Trace Verschlüsselung und Entschlüsselung vorhanden; Quellcodeveränderung teilweise OK
Babel: Preis 115 bis 245 Euro; Stack Trace Verschlüsselung vorhanden, Entschlüsselung ging bei mir nicht, evt. in der Vollversion; Quellcodeveränderung gut
Devextras Obfusasm: Preis 300 Dollar; Stack Trace Verschlüsselung vorhanden, Entschlüsselung ging bei mir nicht; Quellcodeveränderung gut
ILprotector: Freeware; keine Stack Trace Verschlüsselung vorhanden somit auch keine Stack Trace Entschlüsselung vorhanden; Quellcodeveränderung gut
Phoenix Protector: Freeware; keine Stack Trace Entschlüsselung vorhanden - keine Mapping Datei vorhanden; Quellcodeveränderung gut; Laut Entwickler wird das Produkt leider auch nicht mehr weiterentwickelt!
SmartAssembly: Preis 645 - 945 Euro, Stack Trace Verschlüsselung und Entschlüsselung vorhanden; Quellcodeveränderung gut
SharpObfuscator: Freeware; Stack Trace Verschlüsselung vorhanden jedoch keine Entschlüsselung - Mapping Datei wird jedoch erstellt; Quellcodeveränderung schlecht
SkaterLight: Freeware (es gibt auch eine Kostenpflichtige); Stürz beim Verwenden des Infotabs ab; Es werden nicht alle Klassen angezeigt zum bearbeitren
Cryptoobfuscator for net: Preis 149 Dollar (für meine Anforderungen muss es 299 - 399 Dollar sein); Stack Trace Verschlüsselung und Entschlüsselung vorhanden; Quellcodeveränderung gut
CodeFort Free: Preis 149 Euro; Stack Trace Verschlüsselung vorhanden Entschlüsselung ging bei mir nicht; Quellcodeveränderung gut
Confuser: Open Source; Stack Trace Verschlüsselung vorhansen aber keine Stack Trace Entschlüsselung; Stack Trace Veränderung in chinesisch, daher Coding für E-Mail Versand "nicht" möglich
dotnetspin: Freeware; keine Stack Trace Verschlüsselung und Entschlüsselung vorhanden; Quellcodeveränderung zu gering
Dotnet Reactor: Preis 145 Euro; Hat bei mir nach der Obfuskation ewig gedauert bis meine App geladen war.
dotNetProtector: Preis 300 Dollar; Reine Konsolenanwendung
DYAMAR Protector: Preis ca 190 Dollar; Nach Obfuskation wurde meine Anwendung vom Arvira als Virus erkannt 😃
The Enigma Protector: Preis 149 Dollar; Sehr umfangreich mit vielen Funktionen außerhalb der Obfuskation
Macrobject Obfuscator.Net: Preis 199 Dollar; Stack Trace Verschlüsselung vorhanden jedoch Entschlüsselung; Quellcodeveränderung gut
Manco Obfuscator: Preis 74,95 bis X Dollar; Verursacht bei mir einen Fehler beim Einlesen der App
NetObf-Protector: Apllikationsprache für mich nicht lesbar 😃
OrangeHeap: Freeware; Stack Trace Verschlüsselung vorhanden jedoch keine Entschlüsselung - Mapping Datei wird jedoch erstellt; Quellcodeveränderung Ok; Jedoch führen manche Optionen dazu, dass meine App nicht mehr geht
remobjects: Freeware; Reine KonsolenAnwendung
Hier noch eine Liste posten aus einem anderen Forum
.NET Protectors / Packers List, .NET code protection and obfuscators
Ich hoffe, dass hilft auch Anderen, denn die Suche nach dem richtigen Tool ist wirklich VIEL Arbeit!
Grüße
Es gibt eigentlich schon genügend Beiträge dazu im Forum.
Z.B. Suche Freeware Obfuscator. Oder allgemein [FAQ] NET Assembly vor Disassembling schützen (Obfuscator).
Es gibt eigentlich schon genügend Beiträge dazu im Forum. Und wie gesagt: das Feature, das du suchst, hat eigentlich jeder Obfuscator. Wenn du solche Features wie die Stack-Rück-Entschlüsselung haben willst, mußt du eben dafür bezahlen.
Christian
ich geb dir Recht, in einem Forum dort hätte ich gerne gepostet, aber auf der Seite ntcore.com gibt es kein Forum, oder übersehe ich es?
Keine Ahnung.
Zu SmartAssembly folgende Frage. Ist das nicht auch ein Obfuscator Tool.
Ja, aber es ist ein kommerzielles Tool, keine Freeware.
Hallo Christian,
ich geb dir Recht, in einem Forum dort hätte ich gerne gepostet, aber auf der Seite ntcore.com gibt es kein Forum, oder übersehe ich es?
Zu SmartAssembly folgende Frage. Ist das nicht auch ein Obfuscator Tool. Zumindest lese ich das so. Na, ich schau es mir gleich mal an.
Grüße
Hallo,
ich bin gerade auf der Suche nach einem Obfuscator Freeware Tool und bin durch das Forum auf Phoenix Protector gestoßen. Der funktioniert auch, jedoch nur wenn ich die Ressourcen wie Bilder usw. ausschließe, aber das ist nicht das Problem. Mein Problem ist folgendes:
Ist es möglich ab einer bestimmten Stelle im Quelltext zu sagen, dass die Obfuscator nicht mehr angewendet werden soll. Hintergrund ist, dass ich in meinem Programm ein Funktion habe, die es dem Benutzer ermöglicht die Fehler/Exceptions die auftreten per E-Mail an mich zu versenden (wenn sie das möchten). Der Fehler wird dann aber auch unleserlich an mich versendet, weil in den Fehler die Methoden usw. einen unleserlichen Namen erhalten. Das heißt es sieht dann wie folgt aus.
"?1?.?41?: bei ?1?.?75?.?791?(List`1[] ?1009?, XmlDocument ?1006?, Double ?1010?, Int32 ?1011?)"
Ich weiß die Anfrage hört sich komisch an. Wahrscheinlich geht es auch nicht, weil das Assembly ja "verschlüsselt"/unkenntlich wird und die Exception daher gar nicht die original Namen kennen kann. Ist dem so?
Grüße und Danke
Hallo!
Im Prinzip gefällt mir Codefort sehr gut. Ich habe wirklich viele gratis Obfuscator ausprobiert (alle die ich finden konnte, und ich habe lange gesucht), und Codefort war eindeutig der beste von allen.
Hallo neo,
neu in .NET 4.5 ist die SecureString -Klasse. Zwar bietet die Klasse nur bedingt Schutz und eignet sich nur für Texte, dennoch besser als nichts.
Wie schon meine Vorposten sagen, gibt es wenig effektive Möglichkeiten sich vor Manipulationen zu schützen, weil generell alles manipulierbar ist. Den Angreifenden Hürden zu stellen ist wohl das beste Mittel. Weiteres findest du in [FAQ] NET Assembly vor Disassembling schützen (Obfuscator).
Neben Obfuscatoren gibt es noch Packing. Stichwort: .NETZ.
zero_x
Ich nutze jetzt den "Crypto Obfuscator For .Net" von LogicNP Software.
Damit funktioniert es gut und meine App wurde erfolgreich zertifiziert und in den Shop gestellt.
Es geht mir bei dieser App nicht um Business-Logic oder um Daten.
Es geht um von mir programmierte Benutzersteuerelemente und bestimmte Algorithmen.
Es ist mir klar, dass es wieder in einigermaßen brauchbaren Code wandeln kann, aber ich möchte durch Obfuscator verhindern, dass meine App mit einem etwas anderem Aussehen und einem anderen Namen eine Woche später mehrfach in dem Store landet.
Es ist keine sehr komplexe App, aber etwas Programmieraufwand steckt schon drin.
Den Code in klarer Form zu lassen wäre Wahnsinn.
Auf nem Event neulich hat nen MS Guru gesagt, dass es voellig sinnfrei ist irgendwelches Geld oder Aufwaende in ein Obfuscator zu setzen.
Wenn man Business-Logik vor anderen wirklich schuetzen will, ist der einzige Weg, einen WebService zu konsumieren.
Es gibt einfach zuviel gute Tools, die einen verschleierten Code innerhalb weniger Sekunden brauchbar zurueckwandelt.
Hallo el_vital,
ich will sicher nicht vereiteln, dass noch jemand von seinen Erfahrungen berichtet. Immer her damit!
Auf der anderen Seite vermute ich, dass solche Erfahrungen noch so dünn gesät sind, dass sich vielleicht keiner findet, der davon berichten kann. Deshalb lass mich sagen, dass wenn auf einer Webseite steht, dass der Obfuscator für WinRT geeignet ist, ich dies als Zusicherung dieser Eigenschaft verstehen würde und sich der Händler aus meiner Sicht nicht darauf zurückziehen kann, dass dies nur als unverbindliche Werbeaussage zu verstehen gewesen wäre. Nach deutschem Recht würde dann ein wesentlicher Sachmangel vorliegen, der den Händler aus meiner Sicht auf Wunsch des Kunden zur Rücknahme des Produkts und Erstattung des Kaufpreises verpflichten würde.
Du kannst natürlich versuchen, dir die Eignung des Produkts für die Verwendung im Zusammenhang mit dem Windows App Store vorher vom Händler verbindlich bestätigen zu lassen.
Wichtig: Ich habe extra immer Händler geschrieben, weil der nach deutschem Recht der Vertragspartner und damit in der Pflicht ist. Natürlich kann man auch beim Hersteller nachfragen, nur ist fraglich, in wieweit eine Aussage/Auskunft des Herstellers den Händler verpflichtet. Der ist eigentlich nur für seine eigenen Aussagen und die Aussagen des Herstellers, die er übernimmt oder sich auf andere Weise zu eigen macht, verantwortlich.
herbivore
Mit einer Demo-Version behandelte App reiche ich doch nicht bei MS ein.
Ich würde gerne Erfahrungen von Leuten hören die bereits ein Obfuscator bei einer eingereichten Windows Store App erfolgreich genutzt haben.
Und ich habe bei keinem der Hersteller auf der Webseite genaue Informationen zu deren Programmen im Bezug auf WinRT gefunden. Höhstens Werbetexte, dass es jetzt auch mit WinRT funktioniert. Mehr leider nicht.
Wie soll mir der Link helfen? Dort wird nicht erwähnt mit welchem Obfuscator es funktioniert.
Bevor ich jetzt 200$ und mehr für einen obfuscator ausgebe, würde ich gerne sicher sein, dass der auch wirklich mit WinRt funktioniert und ob behandelte Apps durch die Kontrolle von Microsoft durchkommen.
Hat schon jemand einen obfuscator erfolgreich bei WinRT Apps benutzt?
Ich möchte eine App einrechen. Aber davor möchte ich es mit einem Obfuscator bearbeiten. Noch gibt es nicht viele Informationen dazu. Weder bei den Entwicklern von den Obfuscators, noch allgemein im Netz.
Und selbst da ist es heutzutage auch recht einfach da etwas zu patchen.
Wenn man SW erstellt die Hacker benutzen, kann man es ehsofort sein lassen solche sachen einzubauen, hat man normale Kunden reichen die std mechanismen.
Meine Motivation ist erstmal einen minimal Schutz vor Codemanipulation herzustellen
Und ansonsten hatten wir das Thema hier schon (gefühlte) tausend Mal.
[FAQ] NET Assembly vor Disassembling schützen (Obfuscator)
Ich habe heute mein Babel-Lizenzupgrade auf 6.0.0 erhalten, welches Support für WinRT bietet. Fertig war die Version wohl schon seit ein paar Tagen, die Lizenzupgrades wurden aber erst jetzt verteilt. Es gibt damit also schon den ersten (wohl auch ein paar mehr) Obfuscator, der WinRT unterstützt. Ausprobiert habe ich das, mangels Testgerät, allerdings noch nicht.
WTF?
Supports some popular obfuscators
Deobfuscates control flow
Cross-assembly symbol renaming
Decrypts strings
Decrypts resources
Dumps embedded assemblies
Dumps encrypted methods
Deobfuscated files are runnable
Removes other obfuscator junk
Supports pure managed .NET files only
Fixes peverify errors created by the obfuscator
100% Open Source
Wenn es solche Tools gibt, kann man sich ja wirklich die Mühe sparen, seine Assemblys zu obfuszieren.
Christian
de4dot: .NET deobfuscator and unpacker
Die gängigen Obfuscatoren werden damit 1 click reversed , auch das oben genannte Babel.
Momentan bietet confuser die beste Sicherheit, aber es ist auch nur eine Frage der Zeit bis das mit 1 click Tools umgangen wird.
mfg iSliver
edit:/
It currently supports the following .NET obfuscators:
Babel.NET
CliSecure / Agile.NET
CodeFort
CodeVeil
CodeWall
Crypto Obfuscator
DeepSea
Dotfuscator
Eazfuscator.NET
Goliath.NET
ILProtector
MPRESS
.NET Reactor
MaxtoCode
Rummage
Skater.NET
SmartAssembly
Spices.Net
Xenocode