# de4dotEx

**Repository Path**: lankii/de4dotEx

## Basic Information

- **Project Name**: de4dotEx
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: GPL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-09-22
- **Last Updated**: 2026-09-22

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

de4dotEx
===========

de4dotEx is an open source (GPLv3) .NET deobfuscator and unpacker written in C#.
The project is a fork of [de4dot](https://github.com/de4dot/de4dot) and contains fixes and additions made in various different forks over the years. 
It will try its best to restore a packed and obfuscated assembly to almost the original assembly.
Most of the obfuscation can be completely restored (e.g., string encryption), but symbol renaming is impossible to restore since the original names aren't (usually) part of the obfuscated assembly.

It uses [dnlib](https://github.com/0xd4d/dnlib/) to read and write assemblies.

***WARNING***: `de4dot` uses `BinaryFormatter` in some backends (`BabelNET` and `CodeVeil`).
Code obfuscated with these obfuscators (or the one, that tricks `de4dot` to detect so) will cause execution of arbitrary code during deobfuscation. For example it may be possible to write code tracking attempts of applying `de4dot`.
A more proper solution is needed for deobfuscating such binaries, such as a completely own parser doing the deserialization safely.
Read https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide for more info.

Binaries
========

Get binaries from the build server [![](https://github.com/GDATAAdvancedAnalytics/de4dotEx/workflows/CI%20build/badge.svg)](https://github.com/GDATAAdvancedAnalytics/de4dotEx/actions).

Docker & MCP Server Support
===========================

de4dotEx now has fully integrated **Docker containerization** and native **Model Context Protocol (MCP)** server support:

* **Docker Container:** Build a single container to run de4dotEx natively, as a local stdio MCP server, or as an HTTP Web API microservice. See the [Docker Containerization](#docker-containerization) section below for build and run instructions.
* **MCP Server:** Integrate de4dotEx directly with AI assistants like Claude Desktop, Cursor, or Windsurf to programmatically deobfuscate binaries. See the [Native C# MCP Server](#native-c-mcp-server) section below for configuration instructions.

It's FREE but there's NO SUPPORT
================================

There's no support. Don't email me if you can't use it or if it fails to deobfuscate a file obfuscated with an updated obfuscator.

Instead, try to update de4dot yourself. It's a lot easier than you think. If you can't, search the Internet and you should find a couple of forums where you can ask your question.

Features
========

Here's a pseudo random list of the things it will do depending on what obfuscator was used to obfuscate an assembly:

* Inline methods. Some obfuscators move small parts of a method to another static method and calls it.
* Decrypt strings statically or dynamically
* Decrypt other constants. Some obfuscators can also encrypt other constants, such as all integers, all doubles, etc.
* Decrypt methods statically or dynamically
* Remove proxy methods. Many obfuscators replace most/all call instructions with a call to a delegate. This delegate in turn calls the real method.
* Rename symbols. Even though most symbols can't be restored, it will rename them to human readable strings. Sometimes, some of the original names can be restored, though.
* Devirtualize virtualized code
* Decrypt resources. Many obfuscators have an option to encrypt .NET resources.
* Decrypt embedded files. Many obfuscators have an option to embed and possibly encrypt/compress other assemblies.
* Remove tamper detection code
* Remove anti-debug code
* Control flow deobfuscation. Many obfuscators modify the IL code so it looks like spaghetti code making it very difficult to understand the code.
* Restore class fields. Some obfuscators can move fields from one class to some other obfuscator created class.
* Convert a PE exe to a .NET exe. Some obfuscators wrap a .NET assembly inside a Win32 PE so a .NET decompiler can't read the file.
* Removes most/all junk classes added by the obfuscator.
* Fixes some peverify errors. Many of the obfuscators are buggy and create unverifiable code by mistake.
* Restore the types of method parameters and fields

Supported obfuscators/packers
=============================

* Agile.NET (aka CliSecure)
* Babel.NET
* CodeFort
* CodeVeil
* CodeWall
* Confuser
* ConfuserEx - Merged from https://github.com/ViRb3/de4dot-cex , [read the full README by @ViRb3](README-CEx.md) for more info. You may need a native library for [BeaEngine](https://github.com/BeaEngine/beaengine) (version `5.3.0`) for your platform to use the corresponding functionality! If you use another version you may need to recompile with the updated [C# bindings](https://github.com/BeaEngine/beaengine/tree/master/headers/C%23%20headers).
* CryptoObfuscator
* DeepSea Obfuscator
* Dotfuscator
* .NET Reactor
* DoubleZero - Merged from https://github.com/gkucherin/de4dot
* Eazfuscator.NET
* Goliath.NET
* ILProtector
* MaxtoCode
* MPRESS
* Phoenix Protector - by [TheProxy @ tuts4you](https://forum.tuts4you.com/topic/37111-c-phoneix-protector-de4dot-code/)
* Rummage
* Skater.NET
* SmartAssembly
* Spices.Net
* VirtualGuard - Merged from https://github.com/mrT4ntr4/de4dot-vg , [read the full README by @mrT4ntr4](README-vg.md) for more info
* Xenocode

Some of the above obfuscators are rarely used (eg. Goliath.NET), so they have had much less testing. Help me out by reporting bugs or problems you find.

Warning
=======

Sometimes the obfuscated assembly and all its dependencies are loaded into memory for execution. Use a safe sandbox environment if you suspect the assembly or assemblies to be malware.

Even if the current version of de4dot doesn't load a certain assembly into memory for execution, a future version might.

How to use de4dot
=================

N00b users
----------

Drag and drop the file(s) onto de4dot.exe and wait a few seconds.

Deobfuscate more than one file at a time
----------------------------------------

When more than one assembly has been obfuscated, it's very likely that you must deobfuscate them all at the same time unless you disable symbol renaming. The reason is that if assembly A has a reference to class C in assembly B, and you rename symbols only in assembly B, then class C could be renamed to eg. Class0 but the reference in assembly A still references a class called C in assembly B. If you deobfuscate both assemblies at the same time, all references will also be updated.

Find all obfuscated files and deobfuscate them
----------------------------------------------

The following command line will deobfuscate all assemblies that have been obfuscated by a supported obfuscator and save the assemblies to `c:\output`

    de4dot -r c:\input -ru -ro c:\output

`-r` means recursive search. `-ru` means it should ignore unknown files. `-ro` means it should place the output files in the following directory. Typically, you'd first copy `c:\input` to `c:\output`, and then run the command. That way all the files will be in `c:\output`, even non-assemblies and non-processed assemblies. When de4dot is finished, you'd just double click the main assembly in `c:\output` and it should hopefully start.

Detect obfuscator
-----------------

Use the `-d` option to detect the obfuscator without deobfuscating any assembly.

Find all .NET assemblies and detect obfuscator. If it's an unsupported obfuscator or if it's not obfuscated, it will print "Unknown obfuscator".

    de4dot -d -r c:\input

Same as above except that it will only show which files have been obfuscated by a supported obfuscator.

    de4dot -d -r c:\input -ru

Detect obfuscator

    de4dot -d file1.dll file2.dll file3.dll

Preserving metadata tokens
--------------------------

Sometimes in rare cases, you'd want to preserve the metadata tokens. Use `--preserve-tokens` or `--preserve-table`. Also consider using `--keep-types` since it won't remove any types and methods added by the obfuscator. Another useful option is `--dont-create-params`. If used, the renamer won't create Param rows for method parameters that don't have a Param row. That way the ParamPtr table won't be added to your assemblies. Peverify has a bug and doesn't support it (you'll see lots of "errors").

The #Strings, #US and #Blob heaps can also be preserved by using `--preserve-strings`, `--preserve-us`, and `--preserve-blob` respectively. Of these three, `--preserve-us` is the most useful one since `ldstr` instruction and `module.ResolveString()` directly reference the #US heap.

`--preserve-sig-data` should be used if the obfuscator adds extra data at the end of signatures that it uses for its own purpose, eg. as decryption keys. Confuser is one obfuscator that does this.

`--preserve-tokens` preserves all important tokens but will also enable `--preserve-us`, `--preserve-blob` and `--preserve-sig-data`.

If it's detected as an unknown (unsupported) obfuscator (or if you force it with `-p un`), all tokens are preserved, including the #US heap and any extra data at the end of signatures. Also, no obfuscator types, fields or methods are removed.

Preserve all important tokens, #US, #Blob, extra sig data.

    de4dot --preserve-tokens file1.dll

Preserve all important tokens, #US, #Blob, extra sig data and don't remove types/fields added by the obfuscator

    de4dot --keep-types --preserve-tokens file1.dll

Preserve all important tokens, #US, #Blob, extra sig data and don't create extra Param rows to prevent the ParamPtr table from being created.

    de4dot --dont-create-params --preserve-tokens file1.dll

Preserve all important tokens except the Param tokens.

    de4dot --preserve-table all,-pd file1.dll

Dynamically decrypting strings
------------------------------

Although `de4dot` supports a lot of obfuscators, there's still some it doesn't support. To decrypt strings, you'll first need to figure out which method or methods decrypt strings. To get the method token of these string decrypters, you can use ILDASM with the 'show metadata tokens' option enabled. A method token is a 32-bit number and begins with 06, eg. 06012345.

This command will load assembly file1.dll into memory by calling `Assembly.Load()`. When it detects calls to the two string decrypters (06012345 and 060ABCDE), it will call them by creating a dynamic method, and save the result (the decrypted string). The call to the string decrypter will be removed and the decrypted string will be in its place.

    de4dot file1.dll --strtyp delegate --strtok 06012345 --strtok 060ABCDE

Since the assembly is loaded and executed, make sure you run this in a sandbox if you suspect the file to be malware.

Forcing detection of a certain obfuscator
-----------------------------------------

`de4dot` isn't perfect. If it fails to detect an obfuscator, you can use the `-p` option to force it to assume it's been obfuscated by it.

Force SmartAssembly

    de4dot file1.dll -p sa

Force unsupported obfuscator

    de4dot file1.dll -p un

For other obfuscator types, see the help screen.

Disabling symbol renaming
-------------------------

Renaming symbols isn't as easy as renaming A to B when reflection is involved. `de4dot` currently doesn't support renaming XAML so if you suspect that it uses WPF (or if it's a Silverlight app) you should disable renaming if the assembly fails to run.

    de4dot --dont-rename file1.dll file2.dll

`--keep-names` can also be used to tell `de4dot` not to rename certain symbols, eg. "don't rename fields".

Rename everything that should be renamed except properties, events and methods.

    de4dot --keep-names pem file1.dll

Using a different rename regex
------------------------------

The default regexes should be enough, except possibly the one that is used when an unsupported obfuscator is detected. To see all default regexes, start `de4dot` without any arguments and it will list all options and all default values.

Eg., currently the following is the default regex used when Dotfuscator is detected

    !^[a-z][a-z0-9]{0,2}$&!^A_[0-9]+$&^[\u2E80-\u9FFFa-zA-Z_<{$][\u2E80-\u9FFFa-zA-Z_0-9<>{}$.`-]*$

As you can see, it's not just one regex, it's more than one. Each one is separated by `&` and each regex can be negated by using `!` in front of it. To show it more clearly, these regexes are used:

    (negated) ^[a-z][a-z0-9]{0,2}$
    (negated) ^A_[0-9]+$
    ^[\u2E80-\u9FFFa-zA-Z_<{$][\u2E80-\u9FFFa-zA-Z_0-9<>{}$.`-]*$

To change the regex(es), you must know the short type name of the obfuscator (see help screen). Eg. it's `sa` if it's SmartAssembly, and `un` if it's an unsupported/unknown obfuscator. The option to use is `--TYPE-name` (eg. `--sa-name` for SmartAssembly and `--un-name` for unknown/unsupported obfuscators):

    de4dot --un-name "^[a-zA-Z]\w*$" file1.dll

Other options
-------------

Start `de4dot` without any arguments and it will show all options.


Docker Containerization
=======================

de4dotEx includes built-in cross-platform Docker containerization. You can build a single, lightweight container and run it in three different modes: as a standard command-line utility, as an HTTP Web API microservice, or as a containerized Stdio MCP server.

We offer two different Docker strategies depending on your needs:
1. **Strategy A (Native .NET 8.0 - Recommended):** Extremely fast, lightweight, and cross-platform. It automatically compiles the native C++ `BeaEngine` disassembler library inside the container so that advanced ConfuserEx deobfuscation works natively on Linux and macOS (ARM64/x64).
2. **Strategy B (Wine + .NET Framework 4.8):** Emulates a full Windows environment to support dynamic JIT-hook protectors (like ILProtector and Agile.NET) which rely on Windows-native memory APIs (`VirtualAlloc`, `VirtualProtect`).

Strategy A: Native .NET 8.0 Linux Container (Recommended)
--------------------------------------------------------

### 1. Build the Native Image
Execute the following command in the root folder of the repository:
```bash
docker build -t de4dotex -f Dockerfile .
```

### 2. Run the Native Image
The container has an intelligent, unified entrypoint script that automatically routes execution depending on the arguments you pass:

#### A. Run as standard de4dot CLI:
```bash
# Run help
docker run --rm de4dotex --help

# Deobfuscate an assembly in your current directory (mounts pwd to /work)
docker run --rm -v "$(pwd):/work" -w /work de4dotex MyObfuscatedApp.exe -o CleanApp.exe
```

#### B. Run as containerized HTTP Web API (on port 8080):
Start the container in the background to spin up a high-performance HTTP microservice:
```bash
# Start the HTTP Microservice in background
docker run -d -p 8080:8080 --name de4dotex-api de4dotex --mcp --http

# Upload an obfuscated file and download the cleaned output
curl -F "file=@MyObfuscatedApp.dll" http://localhost:8080/deobfuscate -o CleanApp.dll

# Upload with custom native flags (e.g. preserve tokens, decrypt string delegates)
curl -F "file=@MyObfuscatedApp.dll" \
     -F "options=--preserve-tokens -str delegate" \
     http://localhost:8080/deobfuscate -o CleanApp.dll
```

You can also use our convenient test script **`test_api.sh`** to automatically perform the upload and save the processed output next to the original file, appending `_cleaned` (e.g. `App.dll` -> `App_cleaned.dll`):
```bash
# Basic usage:
./test_api.sh MyObfuscatedApp.dll

# Usage with custom flags:
./test_api.sh MyObfuscatedApp.dll "--preserve-tokens -str delegate"
```

#### C. Run as containerized Stdio MCP server (for AI clients):
To run the containerized MCP server directly via Claude Desktop or Cursor, configure your MCP client configuration as follows:
```json
{
  "mcpServers": {
    "de4dotex-docker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "de4dotex",
        "--mcp"
      ]
    }
  }
}
```
*(The `-i` flag is required to keep standard input open so the JSON-RPC streams can communicate securely.)*


Strategy B: Wine-based Container (Full Windows Compatibility)
------------------------------------------------------------

This strategy configures a headless Wine environment on Ubuntu, installs the official .NET Framework runtime via `winetricks`, and executes the Windows `.NET Framework 4.8` assemblies under Wine.

**Fully Automated Build:**
Unlike older setups, this container uses a **multi-stage build** with a **Mono SDK** builder stage (`mono:6.12.0`) to automatically restore and compile the `.NET Framework 4.8` solution (`de4dot.netframework.sln`) inside the container. **You do not need to install .NET Framework or compile anything locally on your host machine!**

### 1. Build the Wine Image
Simply run this command to restore, compile, and package the complete Wine-compatible image:
```bash
docker build -t de4dotex-wine -f Dockerfile.wine .
```

### 2. Run the Wine Image
Run the container using Wine. A virtual framebuffer (`Xvfb`) is configured automatically in the background to handle Wine's GUI requirements in headless environments.
```bash
# Run help
docker run --rm de4dotex-wine --help

# Deobfuscate an assembly requiring dynamic JIT-hook decryption (e.g. ILProtector, Agile.NET)
docker run --rm -v "$(pwd):/work" de4dotex-wine MyProtectedApp.dll -o DecryptedApp.dll
```


Docker Troubleshooting & Tips
-----------------------------

### Apple Silicon / ARM64 Mac Hosts (M1 / M2 / M3)
* **Strategy A (Native):** Runs flawlessly on ARM64 hosts. Docker automatically targets ARM64 and compiles .NET 8.0 and BeaEngine natively for your CPU architecture.
* **Strategy B (Wine):** Because Strategy B installs standard x86 `.NET Framework 4.8` components, you **MUST** force Docker to build and run the image targeting the Intel platform (`linux/amd64`). Docker Desktop on macOS will automatically translate the CPU instructions using Rosetta 2 / QEMU:
  ```bash
  # Build on ARM64 Mac using Intel emulation:
  DOCKER_BUILDKIT=0 docker build --platform linux/amd64 -t de4dotex-wine -f Dockerfile.wine .

  # Run on ARM64 Mac using Intel emulation:
  docker run --platform linux/amd64 --rm -v "$(pwd):/work" de4dotex-wine MyProtectedApp.dll
  ```

### Docker BuildKit / Buildx Errors (Legacy Builder Warnings)
If you get a warning saying `DEPRECATED: The legacy builder is deprecated` or an error saying `BuildKit is enabled but the buildx component is missing or broken`, you can easily resolve this:
* **Workaround 1 (Fastest):** Prefix your build command with `DOCKER_BUILDKIT=0` to temporarily bypass BuildKit:
  ```bash
  DOCKER_BUILDKIT=0 docker build -t de4dotex -f Dockerfile .
  ```
* **Workaround 2 (Recommended for macOS):** If you are on macOS and have Homebrew, install and register the missing `buildx` component:
  ```bash
  brew install docker-buildx
  mkdir -p ~/.docker/cli-plugins
  ln -sfn $(brew --prefix)/opt/docker-buildx/bin/docker-buildx ~/.docker/cli-plugins/docker-buildx
  ```

### Globalization/Localization Issues
* Both images are configured with native globalization components (`libicu`). If you encounter encoding issues with non-ASCII or obfuscated class/method names, make sure your terminal and volume directories are UTF-8 compliant.


Native C# MCP Server
====================

de4dotEx includes a native **Model Context Protocol (MCP)** server built on **.NET 8.0**. 

By running de4dotEx as an MCP server, you can connect it directly to AI assistants (such as **Claude Desktop**, **Cursor IDE**, **Windsurf**, or the **VS Code MCP Client**). This allows the AI agent to programmatically and automatically deobfuscate .NET assemblies (EXE and DLL) inside directories it is analyzing!

Exposed MCP Tools
-----------------

### `deobfuscate`
Deobfuscate and unpack a .NET assembly (EXE or DLL) using de4dotEx.

**Arguments:**
* `file_path` (string, **required**): The absolute file path of the .NET assembly to deobfuscate.
* `output_path` (string, *optional*): Custom file path where the cleaned assembly should be written.
* `options` (string, *optional*): Additional CLI options to pass to the engine (e.g. `"--preserve-tokens"` or `"-str delegate"`).

How to Build the MCP Server
---------------------------

You can build the MCP server using the standard `dotnet` CLI:
```bash
dotnet publish -c Release -f net8.0 -o ./publish-net8.0-mcp de4dot.mcp
```
After building, the published files (including the binary and its dependencies) will be placed in the `./publish-net8.0-mcp/` directory.

How to Configure Your AI Client
-------------------------------

To add de4dotEx to your AI assistant, register it in your client's MCP configuration file (typically `claude_desktop_config.json` for Claude Desktop).

### 1. Claude Desktop Configuration
Open your Claude Desktop configuration file:
* **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
* **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`

Add the following block under the `mcpServers` object:
```json
{
  "mcpServers": {
    "de4dotex": {
      "command": "dotnet",
      "args": [
        "/absolute/path/to/de4dotEx/publish-net8.0-mcp/de4dot.mcp.dll"
      ]
    }
  }
}
```
*(Make sure to replace `/absolute/path/to/de4dotEx/` with the actual absolute path to your cloned repository.)*

### 2. Cursor IDE Configuration
1. Open Cursor Settings -> **Features** -> **MCP**.
2. Click **+ Add New MCP Server**.
3. Name: `de4dotex`
4. Type: `stdio`
5. Command: `dotnet /absolute/path/to/de4dotEx/publish-net8.0-mcp/de4dot.mcp.dll`
}