BitMono: an open source obfuscator for .NET and Mono

An obfuscator that started in the Mono scene

BitMono is described as a free, open-source C# obfuscator that was initially designed and intended mainly for Mono, and the README then says plainly that you are free to use it for any .NET app, but be careful, because some protections work on .NET Framework, some on .NET, some on Mono and some on the Unity Engine only.

That sentence is the most important thing in the documentation, because it describes a protection library rather than a single product. There is no single mode that covers every runtime. A protection that pokes at a Mono-specific behaviour is either inert or harmful on a plain .NET target, and the person configuring it has to know which runtime the output will run on. The topics on the repository confirm the spread: dotnet, dotnet-framework, dotnet-obfuscator, dotnet-protector, mono, mono-obfuscator, unity, unity-mono, unity2d and unity3d.

The licence is MIT and the primary language is C#. The homepage is bitmono.dev and the documentation is published at docs.bitmono.dev, with a readthedocs badge in the README pointing at the latest build of it.

For most readers the audience is a Unity or Mono modder, or a .NET developer who wants the same tool the modding scene has been using, without a commercial licence attached.

AsmResolver replaced dnlib, and the engine is meant to be extended

Two technical decisions define the project, and both were reversals.

The first is the assembly library. BitMono uses AsmResolver instead of dnlib, which we used in the past, for handling assemblies. That is a rewrite of the layer that reads and rewrites the .NET metadata, and switching it means every protection has to be re-expressed against the new API. For a user the visible effect is that the tool's internals have moved on from the library that most .NET tooling and modding code is built around.

The second is the dependency injection container. BitMono is built using dependency injection with a lightweight custom container based on MinIoC, and Autofac was used in the past.

Both of those reversals point at the same thing, which is the second half of the project's identity. You can also use BitMono as an engine to build custom obfuscators. The protections are not a monolith, they are components in a container, and the README describes the codebase as following the latest C# best practices.

That is why the plugin mechanism exists and why it is listed as a feature rather than buried. Plugins are dropped into a plugins folder with no rebuild required, and the linked guide is a developer guide rather than a user guide. If you want a protection that is not in the list, the intended path is to write one and drop it in, rather than to fork the project.

What the reverser sees after obfuscation

The README has a section titled how your app will look since BitMono obfuscation, and it lists the symptoms in a few words. The app looks like a C++ application but is an actual C# application. Decompilers can crash when analyzing types. Decompilers can be broken. The IL code is broken. Types are invisible. And there is no code.

That list is the intended result rather than an accident, and it is what makes the tool effective against the tools in the Usability section, which the README says BitMono breaks using just one packer. The named list is dnSpy, dnlib, AsmResolver, MonoCecil, ILSpy, PEBear, DetectItEasy, CFF Explorer, and, as the README puts it, perhaps some dumpers, and many many more.

Breaking a decompiler is a blunt instrument, and it is worth being clear about what it buys you. It raises the effort of an analyst and can stop casual inspection, but a determined reverser with a debugger and enough time can generally recover the logic of a managed assembly, because the metadata has to remain loadable for the runtime to execute it. The protections listed under AntiDecompiler, AntiDebugBreakpoints, AntiDe4dot and AntiILdasm are the anti-analysis half of the set, and the renaming and encoding protections are the obfuscation half.

The README's own framing is worth keeping in mind. If you will add more protection to the file, I think it would seem like total magic. The project is not presenting obfuscation as invulnerability, and a sensible evaluation treats it as a cost increase rather than as protection of the intellectual property itself.

The protection list is long and the plugin folder is the extension point

The Features list is long enough to be worth grouping.

The encoding and obfuscation protections include StringsEncryption, UnmanagedString, BitDotNet, BitMethodDotnet, LocalVariableEncoding and DotNetHook. The naming ones are FullRenamer and NoNamespaces. The anti-analysis ones are AntiDebugBreakpoints, AntiDecompiler, BitDecompiler, which the README describes as a fixed version of BitDotNet for newer Unity versions, BitTimeDateStamp, BitMono, BillionNops, AntiDe4dot and AntiILdasm. And there are the code-level ones, CallToCalli and ObjectReturnType.

Several of these are marked as based on or based and improved on existing protections, which tells you where they came from and that they are the community's own accumulated tricks rather than novel research.

The last entry in the list is the one that matters for anyone who wants to go further: and you can integrate existing or make own feature. The plugins mechanism follows it, with the note that you drop your own protections in a plugins folder with no rebuild required.

For a Unity developer the practical effect is that the same tool covers a Mono build and a modern Unity build, with BitDecompiler existing specifically because BitDotNet stopped working on newer Unity versions. That is the pattern to expect from a tool whose target is a moving runtime.

Four installation routes, from a CLI to a Unity package

The Getting Started section is short, because the README says the full usage and installation guides live in the docs. The quick start is three steps: download from releases, run BitMono.CLI and follow the prompts, and optionally see the how to use guide.

The installation options are the interesting part, because they cover four different workflows.

For command line use there are pre-built executables on GitHub Releases, or the .NET Global Tool installed with `dotnet tool install --global BitMono.GlobalTool`.

1. Download from [releases][bitmono_releases]
2. Run `BitMono.CLI` and follow the prompts
3. (optional) See the [How To Use guide][bitmono_docs] for detailed instructions

For Unity there are three more. Unity 2018-2019 (Legacy) uses a .unitypackage downloaded from the releases and imported through Assets, then Import Package, then Custom Package. Unity 2020 and later, which the README marks as recommended, uses a .tgz UPM package added through Window, then Package Manager, then +, then Add package from tarball. And for development there is a Git URL, https://github.com/sunnamed434/BitMono.git#vX.Y.Z, added through the Package Manager's Add package from git URL.

That last form is the one to note. Pinning the tag in the URL is what makes a Unity project reproducible, since a branch reference would move under you.

The NuGet path exists too, and the README starts to describe it for users who hit dependency resolution issues, but the text is cut off there.

Obfuscation as a build step, in MSBuild or in a pipeline

The two integration options are the ones that matter for a shipping product, because they make obfuscation a property of the build rather than a manual step someone can forget.

The MSBuild integration works by adding one package reference to the .csproj, and then building in Release:

- `dotnet add package BitMono.Integration` (then set `<PrivateAssets>all</PrivateAssets>` on the reference) and build in `Release`.

The README notes you then set PrivateAssets to all on the reference, and configure it with the usual protections.json, criticals.json and obfuscation.json files next to your .csproj. No separate tool run is needed.

The GitHub Actions route does not touch the source or the csproj at all. You build, then point the action at the artifact:

- uses: actions/setup-dotnet@v5
  with: { dotnet-version: 9.x }
- run: dotnet build -c Release
- uses: sunnamed434/[email protected]   # pin the latest release tag (see Releases)
  with:
    file: bin/Release/net9.0/MyApp.dll
    preset: Maximum
    # version: 0.43.0   # optional: pin the obfuscator too (default: latest) for byte-stable builds

Two details in that snippet matter for reproducibility. The action is versioned by the repository's git tags and ships from its first tagged release onward, so the tag you pin is the wrapper version. And the version input pins the obfuscator itself, with the README's comment that doing so is optional but gives byte-stable builds, since the default is to use the latest release.

The action inputs map one to one onto the CLI arguments: file, output, libraries, protections, preset, no-watermark, no-logo, strong-name-key, config files, version and extra-args. So if you prefer the global tool in a pipeline, the README gives the equivalent as two lines, installing BitMono.GlobalTool and then running bitmono.console with -f pointing at the built assembly and --preset Maximum.

A browser version, a crackme gallery, and a monthly release line

Two things sit outside the usual CLI story. The first is the web version at bitmono.dev, where the README says no install is needed: you drop a.dll or.exe at the site, pick your protections, and download it back obfuscated, with the same engine running on the web. The privacy claim is specific, that your upload is wiped the instant it is obfuscated and the result the instant it is downloaded, and nothing is kept.

That claim is worth testing against your own policy rather than taking on trust, because it is a server-side statement about a service the project does not control the implementation of. The upload is a compiled binary, so what it contains is your code.

The second is the crackmes gallery hosted on the same site, described as a gallery of BitMono-obfuscated.NET reverse-engineering challenges where you can submit your own, crack others, write it up and climb the leaderboard. It is a neat way to measure how far the protections actually push an analyst, and it is also a way to find the weak spots.

The project itself is moving steadily. The recent releases are 0.45.0 from 2026-09-13, 0.44.1 from 2026-07-27 and 0.44.0 from 2026-07-10, and the last push was on 2026-10-22. The licence is MIT, and the repository carries the files you would expect from a project with a documentation site and a public issue process: a.readthedocs.yaml, a docs directory, a CHANGELOG.md, a SECURITY.md, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, troubleshooting.md, build.md, and an action.yml describing the pipeline inputs.

Editorial conclusion

BitMono fits a .NET or Unity developer who ships a managed binary and wants to raise the cost of casual reverse engineering without paying for a commercial protector, and it fits a tool author who wants to write protections against a ready engine. It is the wrong choice if you need a supported commercial product with a guarantee, and it is the wrong choice if you need to protect native code, since the protections here act on managed assemblies. Verify first which runtime your target actually is, because the README warns that some protections apply only to .NET Framework, some only to .NET, some only to Mono and some only to the Unity Engine, and pin both the action tag and the version input if you need byte-stable builds.

Frequently asked questions

Official sources

1. bitmono-project/BitMono on GitHub
2. License: MIT
3. Project website
4. README
5. Releases