zypherion-technologies/unconfuserexEin ConfuserEx2 Deobfuscator mit Unterstützung für Anti-Tamper, Compressor, Constants, Control Flow und Resource Recovery.
Verbesserter Fork von UnconfuserEx mit verbesserter Unterstützung für moderne ConfuserEx2-Varianten, Anti-Tamper-Wiederherstellung, Compressor-Entfernung, Kontrollfluss-Wiederherstellung und Ressourcenrekonstruktion.
https://github.com/user-attachments/assets/de2c7fd9-6736-4f39-83c0-3c25aa9c1f24
Wenn du jemals mit Malware-Beispielen gearbeitet hast, sind einige davon mit ConfuserEx verschleiert, und ich habe einige öffentliche Deobfuskatoren gegen die neueste Version ausprobiert, aber es funktionierte einfach nicht, also habe ich beschlossen, einen öffentlichen zu forken, der gegen diese neueste Version funktioniert hat, und ihn einfach an meine Bedürfnisse anzupassen.
Dieses Repository ist ein Fork von MadMin3r/UnconfuserEx. Auch ihm gebührt Anerkennung. Das ursprüngliche Projekt hat den schwierigen Teil der Erstellung eines fokussierten ConfuserEx2-Deobfuskatoren übernommen, der tatsächlich echte Schutzmaßnahmen entfernen konnte.
Das ist es, was dieses Projekt tut. Es führt eine Liste von Entfernern in einer festgelegten Reihenfolge aus, schreibt Methodenkörper/Ressourcen/Metadaten neu, wo es möglich ist, und gibt eine neue Assembly aus. Wichtig ist die Reihenfolge. Compressor und Anti-Tamper müssen früh passieren, weil der Rest des Moduls möglicherweise noch nicht einmal echtes IL ist.
Die Upstream-Version war bereits nützlich, aber immer wieder traten einige Fälle auf.
Einer davon war der LZMA-Pfad. Manche Samples liefern Bytes, die wie die Konstanten-/Ressourcen-Payload aussehen, aber die LZMA-Eigenschaften sind Unsinn. Wenn man das direkt in den Decoder gibt, erhält man lächerliche Dictionary-Größen und schließlich Ausnahmen, weil die Array-Dimensionen den unterstützten Bereich überschreiten. Daher überprüft diese Version die Eigenschaften, begrenzt die Dictionary-Größe, begrenzt die unkomprimierte Größe und bricht ab, bevor der Decoder etwas Unmögliches alloziert.
LZMA properties => CE FD 62 5F 9F
Invalid LZMA properties byte 0xCE or unreasonable dictionary size
Konstanten hatten ein weiteres dummes, aber reales Problem. Ein Großteil des Auflösercodes erwartet, dass die ID, die vor dem Getter-Aufruf steht, ein ldc.i4 ist. Manchmal ist es aber nicht mehr eine einzelne Anweisung. Es ist ein kleiner arithmetischer Ausdruck.
ldc.i4 0x1234
ldc.i4 0x55
xor
call string <const getter>(int32)
Der ursprüngliche Fork sieht xor, ruft GetLdcI4Value() auf und stirbt, weil xor offensichtlich kein Integer-Load ist. Diese Version geht zurück über die kleine arithmetische Sequenz, emuliert den Stack, reduziert sie auf ein einziges ldc.i4 und lässt dann den normalen Auflöser weitermachen.
Anstatt dies als eine völlig andere Konstantenschutzart zu behandeln, wird daraus:
ldc.i4 0x1261
call string <const getter>(int32)
Dann kann der vorhandene normale/x86-Konstantenauflöser seine Arbeit tun.
Der Kontrollfluss war eher mittelmäßig
Der Switch-Entferner kann die normale ConfuserEx-Switch-Dispatcher-Form verarbeiten. Er durchläuft Blöcke, stellt das nächste Ziel wieder her, löscht tote Blöcke und gibt einen sinnvollen Methodenkörper aus. Es gibt jedoch Samples, bei denen nur ein Teil der Methode verstanden wird. Wenn man eine halbe Methode mutiert und dann feststellt, dass sie immer noch verschleiert ist, ist die Ausgabe schlimmer als nutzlos, weil man jetzt kaputtes IL hat und keine saubere Möglichkeit, nachzuvollziehen, was passiert ist.
Daher erstellt diese Version eine Momentaufnahme des Methodenkörpers, bevor sie ihn anfasst:
instructions
exception handlers
Wenn die Deobfuskation fehlschlägt oder die Methode danach immer noch verschleiert aussieht, wird der ursprüngliche Körper wiederhergestellt. Das Log kann weiterhin sagen „Diese Methode wurde nicht gelöst“, aber die Assembly wird nicht stillschweigend korrumpiert, nur weil eine Methode einen seltsamen Dispatcher hatte.
Jump-/Trampolin-Kontrollfluss hat ebenfalls einen eigenen Durchlauf bekommen. Manche Methoden haben keine Switch-Dispatcher, sondern kleine Branch-Trampoline, die aneinandergereiht sind, bis der echte Block erreicht ist. Diese werden jetzt erkannt und gefaltet, anstatt vom reinen Switch-Pfad ignoriert zu werden.
Der Compressor-Entferner ist der Teil, der vor allen anderen ausgeführt werden muss.
ConfuserEx-Compressor-Stubs behalten normalerweise die echte Assembly komprimiert, booten einen kleinen Lader, dekomprimieren die Payload und laden sie zur Laufzeit.
Der Entferner findet die Lader-Form, extrahiert die eingebettete Payload, dekomprimiert sie und tauscht das Modul gegen die echte Assembly aus. Normale und kompakte Compressor-Layouts werden beide behandelt.
[+] Compressor detected
[+] Extracted compressed module payload
[+] Decompressed real module
[+] Continuing pipeline on unpacked assembly
Anti-Tamper hat jetzt zwei Pfade.
Normaler/dynamischer Anti-Tamper entschlüsselt Methodenkörper aus geschützten Abschnitten und schreibt die wiederhergestellten Körper zurück in das Modul. JIT-Anti-Tamper ist nerviger, weil die Körper erst materialisiert werden sollen, wenn die Laufzeit danach fragt.
Die grobe Form ist:
find init
extract keys
find encrypted JIT body section
derive per method key
read body
write CilBody back
Dies ist immer noch musterbasierend. Wenn sich der Stub genug geändert hat, wird es das natürlich übersehen.
Ressourcen werden ähnlich wie Konstanten behandelt: Finde den verschlüsselten Ressourcen-Blob, stelle den Schlüssel/die Verschlüsselungsform wieder her, entschlüssele, dekomprimiere falls nötig und setze die Ressourcen dort hin, wo normale .NET-Tools sie erwarten.
Es gibt auch einen optionalen Pfad zur Rekonstruktion eingebetteter PEs. Einige geschützte Samples tragen eine verwaltete PE in einer Ressource. Wenn die Rekonstruktion aktiviert ist, versucht der Entferner, auch diese Payload zu parsen und neu zu schreiben, anstatt eine deobfuskierte äußere Assembly mit einer unberührten inneren zu hinterlassen.
UnConfuserEx.exe sample.exe sample.clean.exe --rebuild-embedded-pe
Verwende das, wenn du weißt, dass das Sample eine weitere verwaltete Assembly in Ressourcen versteckt. Wenn die Payload keine verwaltete PE ist, sollte der Rekonstruktionspfad sie in Ruhe lassen.
Baue es:
dotnet build .\UnConfuserEx.sln -c Release
Führe es aus:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe
Oder gib einen expliziten Ausgabepfad an:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe .\protected.clean.exe
Wenn du keinen Ausgabepfad angibst, wird neben der Eingabe eine Datei mit dem Zusatz -deobfuscated im Namen erstellt.
Für eingebettete verwaltete Payloads:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe .\protected.clean.exe --rebuild-embedded-pe
Dies ist die aktuelle Unterstützungsliste. Es bedeutet nicht, dass jeder mögliche ConfuserEx-Fork funktioniert. Es bedeutet, dass dies die Formen sind, nach denen die Pipeline zu suchen weiß.
Es gibt wahrscheinlich noch mehr im Code versteckt, das ich vergessen habe aufzulisten xD.
Die nützlichen Logs sind die, die dir sagen, welche Stufe fehlgeschlagen ist, nicht nur, dass die Ausgabe nicht lief.
Beispiel für einen Konstantenpfad, der repariert wurde:
Constants detected, attempting to remove
Found 3 constant getter(s)
Detected constant decryption type is Dynamic
Decompressed constants blob to 18492 byte(s)
Resolving getter <Module>::???????? as String with 41 call site method(s)
Removed all instances of getter <Module>::????????
Beispiel für eine Kontrollfluss-Methode, die absichtlich in Ruhe gelassen wird:
Removing obfuscation from method System.Void Example::Run()
Method System.Void Example::Run() still appears obfuscated after deobfuscation -- left original body intact
Removed obfuscation from 42 methods. Failed to remove from 0 methods. 1 methods left untouched
Das zweite Log ist nicht perfekt, aber es ist ZUMINDEST ehrlich.
Ein benutzerdefinierter ConfuserEx-Fork, der jede Helfer-Form ändert.
Ein Konstanten-Getter, der seine ID durch ein vollständiges Kontrollfluss-Chaos berechnet, anstatt durch einen kleinen Stack-Ausdruck.
Ein Kontrollfluss-Graph, bei dem der Dispatcher von Laufzeitwerten abhängt, die der statische Emulator nicht kennt.
Native Helfer, die tatsächliche Laufzeitausführung benötigen, anstatt IL-Emulation.
Assemblies, die bereits kaputt waren, bevor sie verschleiert wurden.
JIT-Anti-Tamper-Varianten mit einem anderen Layout des verschlüsselten Körpers.
Wenn du möchtest, dass ein Problem nützlich ist, füge genügend Daten zur Reproduktion bei.
Entferne die Dateiendungen von Samples, bevor du sie hochlädst.
Archive alles zusammen und füge dies hinzu:
Command:
UnConfuserEx.exe <target> <optional output>
Failure stage:
- compressor
- anti tamper
- constants
- control flow
- resources
- writing output
- runtime after deobfuscation
Expected result:
Actual result:
Console output:
Archive link:
Notes / investigation:
Wenn du nur „funktioniert nicht“ schickst, wird die Antwort wahrscheinlich „ja“ sein.
Kleine, fokussierte Korrekturen sind besser als große Umschreibungen.
Wenn du Unterstützung für eine neue Schutzform hinzufügst, halte es auf den Entferner beschränkt, dem es gehört. Wenn du ein Fallback-Verhalten hinzufügst, stelle sicher, dass ein Fehler die Ausgabe-Assembly nicht korrumpiert. Wenn du den Kontrollfluss anfasst, gehe davon aus, dass das seltsame Sample, das du repariert hast, nicht das einzige seltsame Sample ist, das existiert :DDD.
Mache das Tool nur NICHT schwieriger zu debuggen.
Dieses Projekt basiert auf MadMin3r/UnconfuserEx.
Das ursprüngliche Projekt stellte die Grundlage und den Großteil der zentralen Deobfuskations-Pipeline bereit. Dieser Fork konzentriert sich auf die Verbesserung der Zuverlässigkeit, die Unterstützung zusätzlicher Schutzvarianten und die Behandlung von Grenzfällen, die in echten Beispielen beobachtet wurden.
Dieses Projekt begann als praktisches Reverse-Engineering-Werkzeug, nicht als Software-Engineering-Übung. Der Fokus lag immer darauf, geschützte Assemblies zuverlässig wiederherzustellen, anstatt perfekte Codequalität zu haben.
Dieses Tool ist für autorisierte Malware-Analyse, Reverse Engineering, Software-Wiederherstellung, Interoperabilität und Bildungsforschung bestimmt.
Benutzer sind dafür verantwortlich, geltende Gesetze einzuhalten und alle erforderlichen Genehmigungen einzuholen, bevor sie Software oder Systeme analysieren, darauf zugreifen oder sie verarbeiten.
Zypherion Technologies autorisiert keine unrechtmäßige Nutzung dieses Tools und lehnt jegliche Haftung für Missbrauch durch Dritte ab.
Nichts in diesem Repository oder auf www.zypherion.tech ist Rechtsberatung.