JIEJIE.NET: a .NET obfuscator that rewrites IL rather than just renaming it

The starting point is that renaming alone was not enough

The background section of the documentation states the problem plainly. Many .NET developers worry that their software has been cracked and their copyright infringed, so they use tools to obfuscate IL code, tools such as PreEmptive dotfuscator. But sometimes that is not enough, and the author wrote JIEJIE.NET to encrypt .NET assemblies deeply and help people protect their copyright, and made the tool open source.

The author is identified as yongfu-yuan, from China, with an email address in the readme, and the project name is explained: JieJie in Chinese is a kind of transparent magic protect shield, which is the Chinese idiom for a protective barrier.

That framing tells you what kind of tool this is. A commercial obfuscator is a product with a support contract and a compatibility matrix. This is one developer publishing the implementation and the build outputs, with a GitHub issue tracker as the feedback channel. That is a legitimate and useful thing, and it is a different proposition from buying a licence.

Two newer projects from the same author are announced at the top of the readme, CAAM and WF2W, each with its own repository. The readme does not describe either of them, so there is nothing to say about them here beyond their existence, which is a hint about where the author's attention has gone.

The tool is a .NET application with two interfaces, a Windows GUI and a console interface, and both are shown in screenshots linked from the readme.

Renaming honours the Obfuscation attribute, which is the thing that makes it usable

The first feature is renaming types and members, and the detail that makes it workable is the interaction with the standard attribute. The documentation says this can make it more difficult to understand the meaning of an API, and that the effect is governed by System.Reflection.ObfuscationAttribute.

That is the crux. A rename-everything obfuscator breaks any code that looks up a member by name at run time, and the Obfuscation attribute is the standard way for a developer to say which members must keep their names. The example in the readme shows a class with several members carrying the attribute, and the readme states plainly that the attribute controls which names are preserved.

The before and after are shown side by side in the documentation. The original class has a readable member set, with the attribute marking the members to leave alone, and the obfuscated version has the same shape with the unmarked members replaced by generated names:

    public XTextParagraphFlagElement z0ZzZzbmm1mO001();
    public XTextSelection z0ZzZzbmm1mO011(int startIndex, int length);
    public void z0ZzZzbmm1mO01O();

The generated names follow a visible pattern, with a prefix and a mixed alphabet of characters, and the mapping is a bijection so the renamed members can be traced back to the originals by anyone with the original source. That is worth noting: this is obfuscation, not encryption, and the rename table is recoverable from the pattern.

The examples also show that the excluded members keep their names and their attributes are preserved in the output, and that members with the same signature can be distinguished, since the two Create methods in the original become differently named members rather than colliding.

Control flow obfuscation works on the IL, and the changelog shows why

The second feature is the one that separates this from a name mangler, and the documentation describes it in a way that reveals the mechanism. JieJie can analyse IL Code and obfuscate control flow randomly without losing any features. It can break the syntactic structure of foreach, lock and using, and hide the operation of equals and of concatenating two string values. The stated effect is that the code becomes very hard to read and that it will sometimes cause a cracking tool to error.

So the obfuscation operates on the intermediate language, not on the C# source. That is a much deeper intervention. Restructuring a foreach loop or a lock block changes the shape of the compiled code rather than just the labels on it, and hiding string concatenation removes the literal a decompiler would otherwise show.

The changelog is where this becomes concrete, and it is the most useful part of the documentation. Read as a list, it is a record of the runtime behaviours the tool has to get right. The entries include a fix for the modopt, modreq and marshal instructions and for COM interop, a fix for await calls, a fix for the SMF_GetManifestResourceNames call, a fix for a bug in LoadResourceSet, a fix for a bug in SMF_GetContent, a fix for parse string value, a fix for encryption resource, and support for Blazor WebAssembly with clean custom attributes and removed dead code, plus support for .NET 6.0.

Those are not obfuscation features. They are the specific points where rewriting IL breaks something in the runtime, and each entry tells you a class of program that this tool has already broken at least once. It is a candid list, and reading it is the fastest way to understand the project's maturity.

Resource encryption and string handling are separate features with their own bug history

Beyond the two headline features, the changelog names a set of capabilities that are each small individually and collectively cover most of what a.NET application contains.

Embedded resources are encrypted, with a fix for the encryption resource bug dated 2026-1-1, which is the most recent entry in the log. Enum values are encrypted when a method is called, and the typeof instruction is encrypted. Byte arrays and integer values are encrypted. Document comments in XML elements that have been renamed are cleaned. Hidden array definitions are supported. Multi-assembly files can be merged into a single assembly file. Properties and events that have been renamed are removed. Stack traces get more extensive translation. The support for the ldtoken method is there, and the support for the filter{} construct was added in 2022.

Several of these are about cleaning up after the fact, which is the part most obfuscators do badly. When you rename a member and the assembly has embedded resources referring to it, or a stack trace that is used for logging and analytics, or a comment that documents a now-mangled name, the result is a program that runs but produces wrong output. The entries about removed dead code, about merging assemblies and about stack trace translation are all evidence of someone fixing the seams.

The StringsSelector command argument added on 2024-10-19 belongs in the same group. The changelog gives no details beyond the argument name, so its exact behaviour is not documented here.

Taken together, the feature set describes a tool that treats a.NET assembly as a set of things that must keep working: the runtime, the interop, the resources, the reflection, the diagnostics. The first publish was on 2021-3-22, and the entry for 2021-4-2 added control flow obfuscation, with type or member rename arriving a few months later on 2021-7-20.

How you get it, and what the repository actually contains

There is no install command in the documentation, and the repository listing explains why.

The top level contains a .gitignore, a LICENSE, the README, a source directory, and a set of prebuilt outputs: a zip named jiejie.net_pub v1.2022.1.6.zip, an extracted directory jiejie.net_pub v1.2022.1.6, another directory jiejie.net_pub v1.2023.11.07, and a zip for v1.3. There are also alipay.jpg, wechat_pay.png and a donate.html, which is the usual arrangement for a project that asks for donations through Chinese payment channels.

So the distribution model is: download a published zip, or build from the source directory. There is no NuGet package, no dotnet tool install, and no documented build command in the readme.

That last point matters more than it might sound. The tool is a .NET application that rewrites assemblies, and to build it you would need the source, the right .NET SDK for the target framework, and a build procedure the documentation does not spell out. The published binaries are the practical route for anyone who just wants to obfuscate an assembly.

The version naming is also worth noting, because it is inconsistent in a way that will confuse a release history check. The recent releases are 2022-11-7 dated 2022-11-07, v1.2022.1.6 dated 2022-01-06, and v1.3 dated 2021-08-23. The changelog dates run to 2026-1-1, so the changelog has moved past the last tagged release by more than three years, and the file names in the repository follow a third pattern again with v1.2023.11.07, a date that does not correspond to any listed tag.

The project record lists the primary language as C#, the licence as GPL-2.0, and the default branch as main. The last push to the repository was on 2026-04-09 and it is not archived.

What obfuscation can and cannot buy you

It is worth being blunt about the security value here, because the tool is presented in terms of copyright protection and the mechanism is worth understanding.

What this does is make a decompiled assembly harder to read and harder to modify coherently. The renamed members carry no meaning, the control flow has been restructured so the original logic does not map onto the decompiled output, and the embedded resources and string literals are encrypted so they are not visible in a hex dump.

What this does not do is stop someone with enough time and a debugger. The rename pattern is deterministic and reversible, the runtime must still be able to execute the obfuscated code, which means the encrypted strings must be decrypted at run time, which means the decryption routine and the key are both in the assembly, and which means an attacker who sets a breakpoint on the decryption sees the plaintext. That is the general weakness of this class of tool, and the documentation does not claim otherwise, describing the tool as helping people protect their copyright rather than as a security boundary.

There is also a cost. Obfuscated code is harder to debug, and a stack trace that has been translated into meaningless names is harder to act on. If your production support process relies on exception messages to identify a failure, obfuscation works against you.

And there is a compatibility cost that lands on whoever uses your library rather than your application. A public API that has been renamed is a breaking change for every consumer. The Obfuscation attribute is the mechanism for avoiding that, and using it correctly for every type and member that any consumer might reference by name is a real maintenance task, not a one-off flag. For an application you ship and nobody links against, the cost is much lower.

So the honest summary is that this raises the effort required to read or patch your binary, and it does not create a boundary an attacker cannot cross. Whether that is worth doing depends entirely on what you are protecting and against whom.

Where JIEJIE.NET is the wrong choice

Three situations rule it out.

The first is a public library. If you ship a NuGet package that other developers reference, renaming public types and members breaks their compile, and the Obfuscation attribute means you are hand-maintaining an exclusion list that has to grow with every public API you add. The cost of getting that wrong is a broken dependency for every consumer, which is a far worse outcome than the piracy you were trying to deter.

The second is an application built on reflection, serialisation or a plugin host. Data contract serializers look up members by name, JSON and binary formatters depend on stable names, and a plugin architecture depends on a contract. Every one of those is a case where the Obfuscation attribute is the only defence, and the tool cannot infer which members are load-bearing.

The third is a team that needs a support contract. There is no commercial entity behind this, no compatibility matrix, and no promise that a future release will still handle a given framework. The changelog is a list of individual bug fixes by a single author, which is a different kind of assurance from a vendor who will tell you which .NET versions a given build supports. For an application whose continued operation depends on being able to rebuild and re-obfuscate it in two years, that difference matters.

On the version question specifically, the changelog is three years ahead of the most recent tag, and the repository holds published binaries with version names that match neither the tags nor the changelog. Anyone picking this up should establish which build they are actually running before assuming it contains the resource encryption fix dated 2026-1-1, because the readme gives no mapping between the two naming schemes.

Editorial conclusion

JIEJIE.NET fits a .NET developer shipping a closed source product who is willing to accept that their own tooling, including decompilers, will have a harder time with the result, and who wants obfuscation that goes past name mangling. It is the wrong choice if you need a maintained commercial-grade obfuscator with a support contract, and it is the wrong choice for an application that depends on reflection, serialisation or a plugin host, because every one of those depends on names and attributes surviving. Before adopting it, test the result against your own reflection-based code paths, and check the version you are using against the changelog, because the fixes listed against individual runtime calls are where the failure modes live and the most recent tagged release is from 2022.

Frequently asked questions

Official sources

1. dcsoft-yyf/JIEJIE.NET on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases