re-managed

Managed code reverse engineering (.NET / Java / scripts)

Complete workflow

1. Identify the runtime (decompiling without first determining the type is the biggest waste):
   • PE file：file output contains "Mono/.Net assembly", PE optional header data directory entry 15 (COM Descriptor / CLI header) is non-zero, import mscoree.dll → .NET assembly → [[re-dotnet]] (capability:bytecode-parser）
   • jar/war/class：unzip -p app.jar META-INF/MANIFEST.MF see Main-Class, class file magic number CAFEBABE → Java bytecode → [[re-java]] (capability:bytecode-parser）
   • scripts/macros：shebang（#!/usr/bin/pwsh）、-EncodedCommand / IEX(PowerShell), OLE document (file shows "Composite Document") embedded VBA,eval( / fromCharCode(JavaScript) → [[re-script-deob]] (capability:deobfuscation）
   • If unsure, start with [[re-triage]] (capability:triage) for preliminary reconnaissance (file/hash/entropy/strings); do not guess based on the extension
2. Decompile: follow the identification result to [[re-dotnet]] (capability:bytecode-parser) / [[re-java]] (capability:bytecode-parser) / [[re-script-deob]] (capability:deobfuscation), first restore the target logic into readable code
3. Deobfuscate: each atomic skill contains the corresponding approach — de4dot (ConfuserEx/SmartAssembly), obfuscation identification + string decryption (ProGuard/Allatori), layer-by-layer decoding (scripts/macros); for samples mixed with native components (native stub / JNI), route deobfuscation to [[re-deobfuscate]] (capability:deobfuscation）
4. Malicious scenarios (phishing macros, downloader scripts, malicious .NET/Java samples): route to [[re-malware]] (capability:malware-behavior、document-malware、evasion-analysis、key-extraction、threat-intel) gateway — default sandbox → behavior analysis → C2/protocol → IOC/report; the decompilation and restoration results are fed back to [[re-malware]] (capability:malware-behavior、document-malware、evasion-analysis、key-extraction、threat-intel) as static evidence for use

When to use which atomic skill (selection tree)

Branch by runtime:

• PE and confirmed .NET metadata (CLI header / mscoree) → [[re-dotnet]] (capability:bytecode-parser; dnSpy/ILSpy decompilation, de4dot deobfuscation)
• jar / war / class (Java bytecode) → [[re-java]] (capability:bytecode-parser; CFR/JD-GUI, javap, unpacking hardened apps)
• .ps1 / .docm / .xlsm / .js / .jse / .hta (scripts or macros) → [[re-script-deob]] (capability:deobfuscation; layer-by-layer decoding, dynamic execution defaults to sandbox)
• Python-packaged samples (.exe with PyInstaller/PyArmor characteristics / .pyc / python packaging) → [[re-python]] (capability:bytecode-parser; pyinstxtractor unpacking, PyArmor-Unpacker, pyc decompilation; pure script obfuscation routes to [[re-script-deob]] (capability:deobfuscation））
• .wasm / WebAssembly modules (web/Node-side payloads) → [[re-wasm]] (capability:web-assembly; WABT section parsing, wasm-decompile decompilation, DevTools/wasmtime dynamic)
• AI model related → [[re-ai-triage]] (capability:triage) triage: model files (.onnx/.safetensors/.pt) → [[re-ai-model]] (capability:ai-model-analysis; format identification, weight extraction, file-level watermarking; unknown pkl isolated by default); API only → [[re-ai-attack]] (capability:ai-model-analysis; behavior-layer assessment, guard authorization preconditions)
• EVM contract bytecode (.bin / hex) → [[re-blockchain]] (capabilities:blockchain-analysis; ABI recovery, panoramix decompilation, vulnerability analysis)
• Browser extensions (crx/xpi/zip extension files) → [[re-browser-ext]] (capabilities:browser-extension; permission auditing / malicious behavior / deobfuscation)
• Electron packaged applications (resources/app.asar) → [[re-electron]] (capabilities:electron-analysis; asar unpacking, V8 bytecode boundaries, CDP dynamic debugging)
• Java Card / SIM (CAP files) → [[re-javacard]] (capabilities:bytecode-parser; 12-component parsing, process(APDU) dispatch recovery)
• Android DEX → not this gateway—forward to [[re-mobile]] (capabilities:dex-parser、jni-analysis、frida-instrumentation、mobile-forensics; [[re-apk]] (capabilities:dex-parser)), with Java native logic returning to [[re-java]] (capabilities:bytecode-parser）
• PE downloaded via script-invoked native only → dynamic side follows [[re-malware]] (capabilities:malware-behavior、document-malware、evasion-analysis、key-extraction、threat-intel), static side returns to [[re-binary-core]] (capabilities:decompilation、debugging、memory-dump、elf-parser、pe-parser、macho-parser）

Cross-domain federation

• .NET/Java malicious samples: [[re-malware]] → this gateway (dotnet / java decompilation recovery) → back to [[re-malware]] (behavior verification + IOC)
• Malicious scripts/macros: [[re-malware]] → [[re-sandbox]] (dynamic) → [[re-script-deob]] (static payload restoration)
• Base [[re-binary-core]]: initial survey ([[re-triage]]), native portions of mixed programs (format parsing / [[re-ghidra]] decompilation), deep obfuscation restoration ([[re-deobfuscate]])
• This gateway is called by [[re-analyze]]'s triage ".NET/Java/script samples" path
• "Code in data" branch: AI models ([[re-ai-triage]] → [[re-ai-model]] file layer / [[re-ai-attack]] behavior layer; embedded code goes to [[re-binary-core]]), EVM contract bytecode ([[re-blockchain]], vulnerability side connects to [[re-vuln]])

Common pitfalls and traps

• Guessing the runtime by extension/imports: PE imports mscoree.dll are not necessarily pure managed (mixed mode / obfuscator disguise), Jars may embed native libraries—first confirm per workflow step 1 (CLI header / manifest / magic numbers) before choosing a skill
• .NET self-contained single-file / Java fat jar analyzed directly without unpacking: a single file bundles IL + runtime into a native host, fat jar classes are in BOOT-INF/lib—unpack first ([[re-dotnet]] / [[re-java]] have corresponding steps), otherwise decompilation output is empty/messy
• Underestimating the number of obfuscation layers: finding another layer after restoring one is the norm—verify layer by layer, archive each layer, don't try to do it all in one step
• Dynamic execution without a sandbox: scripts/macros/VBA may be downloaders, may persist—all dynamic execution defaults to a sandbox ([[re-analyze/platform-tips]] highest principle), static decoding may be exempt
• Confusing hardening with obfuscation: Java hardening (Virbox, etc.) is a "shell", de4dot can't handle it—first determine "shell or obfuscation", for shells follow the [[re-anti-analysis]] approach (unpack first, then decompile)
• Bytenode bytecode bound to ABI: symptom—host Node fails to load JSC; cause—Bytenode bytecode is bound to a specific V8/Node ABI; countermeasure—use the sample's bundled Electron in RunAsNode mode (ELECTRON_RUN_AS_NODE=1) to execute, without launching the business GUI
• Registration surface ≠ execution surface: Phenomenon — enumerating handlers cannot prove the data flow; cause — registration existing does not equal path execution; countermeasure — first enumerate the IPC/preload registration surface, then for high-risk handlers call them with mock fixtures and capture side effects (URL receiving/downloading/decompression/spawn parameters), forming a closed evidence loop
• Five-tuple forensics of the update chain: Phenomenon — evidence for the update process is incomplete; cause — chain nodes are scattered; countermeasure — follow source URL → downloader → archive path → extractor → executable each node saves a hash and timestamp
• Signature status has four states: Phenomenon — judgment of dual-signed DLLs is ambiguous; cause — each signature status may differ; countermeasure —signtool verify /pa /all /v check each signature individually (existence/validity period/timestamp/trust verification reported separately)
• Static capability ≠ executed: Phenomenon — native strings/imports show high-privilege capabilities; cause — imports are clues, not evidence; countermeasure — capability descriptions combined with xref/call chains, report in separate columns "conditional capability" and "observed behavior" (Source: reverse-skill field-journal, MIT)