re-dotnet
by Heretek-RE
README.md
# re-dotnet
MCP server for .NET assembly analysis. Vendor-neutral wrapper around [AsmResolver](https://github.com/Washi1337/AsmResolver) (PE + .NET metadata) and [ICSharpCode.Decompiler / ILSpy](https://github.com/icsharpcode/ILSpy) (C# decompiler).
## Why
The other RE-AI MCP servers (`re-lief`, `re-rizin`, `re-capa`) handle native PE, ELF, MachO, DEX, ART, OAT — but **none of them read the .NET CLI header** or the ECMA-335 metadata tables. A `MonoLauncher`-style launcher that ships its payload as a managed .NET assembly is invisible to those tools; the import hash is empty, the strings table is uninformative, and rizin only sees native wrapper code.
`re-dotnet` fills that gap. It enumerates TypeDef / MethodDef / FieldDef, walks the #US string heap, and decompiles a single class or method to C# on demand.
## Architecture
The MCP server itself is pure Python. The heavy lifting is done by a small .NET 10 CLI binary, `re-dotnet-cli`, built from `src/re_dotnet/dotnet/Re.Dotnet.Cli/`:
```
Claude Code (MCP stdio)
│
▼
re-dotnet server (Python, this directory)
│ subprocess.run(...)
▼
re-dotnet-cli (self-contained .NET 10 binary, single-file publish)
│
├─ AsmResolver 6.x (PE + .NET metadata, obfuscation-robust)
└─ ICSharpCode.Decompiler 9.x (C# decompiler)
```
The subprocess boundary is intentional:
- **No `pythonnet`.** `pythonnet` is a fragile ABI bridge that breaks on every Python minor. Process isolation is robust.
- **No Mono.** .NET 10 is the only supported runtime.
- **Single-file publish.** The CLI is a self-contained binary; no `dotnet --info` dance, no `DOTNET_ROOT` env vars, no GAC.
The Python wrapper locates the binary via this fallback chain (see `runner.py`):
1. `$RE_DOTNET_CLI_PATH` (escape hatch for tests)
2. `<server>/bin/re-dotnet-cli` (install.sh default)
3. The dev build under `src/re_dotnet/dotnet/.../bin/`
4. `re-dotnet-cli` on `$PATH`
## Tools
| Tool | What it does |
|---|---|
| `check_dotnet` | Health check — return .NET runtime + AsmResolver + Decompiler versions |
| `parse_assembly` | Enumerate TypeDef rows; return assembly header + one row per type |
| `decompile_type` | Decompile a single class to C# via ILSpy |
| `decompile_method` | Decompile a single method to C# via ILSpy |
| `list_strings` | Walk field-default constant strings (the #US heap subset) |
| `get_entry_point` | Return the managed entry point (`<Module>::.cctor` or `Main`) |
## Install
`./install.sh` builds the .NET CLI via `dotnet publish` and copies the resulting binary to `servers/re-dotnet/bin/`.
To build standalone:
```bash
cd servers/re-dotnet/src/re_dotnet/dotnet/Re.Dotnet.Cli
dotnet publish -c Release -o ../../../../bin
```
To run:
```bash
re-dotnet # stdio transport (default for MCP)
python -m re_dotnet # equivalent
```
## Requirements
- .NET 10 SDK or runtime (`dotnet --version` ≥ 10.0)
- 2 GB disk for the .NET SDK + the self-contained binary
## Deobfuscation notes
The ILSpy decompiler produces clean C# for **non-obfuscated** assemblies. For binaries that have been through commercial obfuscation (control-flow flattening, string encryption, JIT-hooking), the decompiler will surface `Unable to decompile ...` errors. The remediation path is to run the .NET deobfuscator first (the OSS `de4dot` shells out, GPL-3.0 — the RE-AI plugin keeps it process-isolated so the plugin's own distribution stays clean) and then re-run `decompile_type` / `decompile_method` on the cleaned output.
## Pairing with `re-leak-scan`
A .NET-style launcher that calls out to telemetry endpoints (Sentry, Logstash, Confluence, Google Drive) will have those URLs as field-default constants. Run `re-leak-scan` (T2.2) on the assembly, or call `list_strings` here and pipe the output through a regex filter for the four endpoint families.
TDQS
A4.2/5.0
Scored across 11 tools
Disambiguation5/5
All tools have clearly distinct purposes—from runtime checks to assembly parsing, decompilation, and obfuscation detection. No overlapping functionality.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., decompile_method, get_fields), with only minor variations like run_il_simplification. Overall consistent and readable.
Tool Count5/5
11 tools is an ideal size for a domain-specific reverse engineering server—comprehensive without being overwhelming.
Completeness5/5
The tool surface covers assembly metadata, method/field enumeration, decompilation, protection analysis, anti-debug scanning, string extraction, and IL simplification—no obvious gaps for .NET analysis.
Maintenance
ActivityStale
ResponsivenessSyncing