NETReactorSlayer unpacks .NET Reactor binaries back to IL

What the tool takes apart

NETReactorSlayer is described as an open source, GPLv3 licensed deobfuscator and unpacker for Eziriz .NET Reactor, the commercial .NET protection and obfuscation product. The topic tags name the territory it works in: deobfuscator, unpacker, reverse engineering, dotnet, dotnet-reactor and dnlib. The distinction between the two words in the description is worth keeping. Unpacking means undoing the packing layer, so the assembly loads and its IL is readable, while deobfuscation means undoing the transformations applied to the code, so the logic is analysable. A tool that does both is doing the work a reverse engineer would otherwise do by hand, and the payoff is that the output can be loaded into a decompiler or a disassembler as an ordinary .NET program rather than a protected blob.

A GUI and a CLI over one core

The repository ships two front ends. The GUI is the `NETReactorSlayer.GUI` project, and the command line is in `NETReactor.CLI` and `NETReactorSlayer-x64.CLI`, with the README showing screenshots of each. The shared work lives in `NETReactorSlayer.Core`, and there is a separate `NETReactorSlayer.De4dot` project, which is where the de4dot integration lives. That is the layout to look at when you want to understand the tool, because the core is the part that knows about .NET Reactor and the two front ends are thin. The `NETReactorSlayerCommon.props` file at the root holds the shared build properties, the solution is `NETReactorSlayer.sln`, and the build is driven by a `build.ps1` PowerShell script, with a `Libs/` directory holding the third party binaries the project depends on and a `NuGet.Config` for the package sources. The binaries themselves are published on the GitHub releases page, and the wiki holds the guides.

Three libraries do the heavy lifting

The credits section names the dependencies precisely, and they tell you how the unpacking works. dnlib is the .NET metadata and IL library that most .NET reversing tools are built on, and it is what lets the tool read and rewrite an assembly at the IL level. de4dot.blocks is the deobfuscation engine from the de4dot project, contributing the blocks that undo the specific obfuscation patterns. And Harmony is the runtime patching library, used to hook the .NET Reactor loader in memory so the protected assembly can be observed while it initialises rather than after. Taking those three together, the strategy is the standard one for this class of protection: let the protected code run under instrumentation, capture the real IL as it is decrypted and the anti-tamper checks are satisfied, and then write a clean assembly out.

The project has had no release since 2022

The release history is where the practical caveat sits. The most recent tags are v6.4.0.0 from December 2022, v6.0.0.0 from October 2022 and v5.0.0.0 from September 2022, each tagged with the .NET Reactor version it corresponds to, so the numbering tracks the protected product rather than the tool. The last push to the master branch was on 2026-09-12, so the source is being touched, but the published binaries in the releases page are from the end of 2022. For a tool whose job is to keep up with a commercial product, that gap matters, and it is the reason to check the wiki and the changelog for which .NET Reactor versions the current build actually handles before you plan around it. The licence is GPLv3 with the file in the repository root, and the project takes donations through a Sellix page.

Where this fits in a workflow

The useful way to think about NETReactorSlayer is as one stage in a pipeline rather than a terminal answer. The output of the unpacker is an assembly with readable IL, which is what you need to feed into a decompiler, into a static analysis tool, or into a diff against the original source if you happen to have it. That is why the tool ships a GUI at all: the interactive path lets you step through the stages and see which layer the sample was using, which is information you want when you are triaging a set of samples rather than unpacking one known file. The de4dot integration exists because the protection and the obfuscation are separate concerns, and the same sample may use both. The practical workflow, then, is unpack, then deobfuscate, then analyse, and the value of the tool is that the first two steps are automated.

Editorial conclusion

Adopt NETReactorSlayer if you need to analyse a .NET Reactor protected assembly, whether for malware analysis, for auditing your own protected build, or for interoperability work, since it handles the protection layers and hands back IL. Do not adopt it to strip protection from someone else's commercial software, because the licence is GPLv3 and the legal position of reversing a protection scheme is not settled. Verify first which .NET Reactor version your sample uses, since the tool is version sensitive, and check the wiki for the supported combinations before you rely on the output.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. SychicBoy/NETReactorSlayer on GitHub