Skip to content

Nebula.NET

How it works

A tour of Nebula.NET’s protection transforms and how they keep your app’s behavior intact.

Nebula rewrites the IL (intermediate language) inside your assemblies using several independent transforms. You can enable or tune each one from the configuration.

Identifier renaming

Types, methods, fields and parameters are renamed to short, meaningless identifiers. Nebula preserves anything that must keep its name to work:

  • Public API surface (when preservePublicApi is on).
  • Reflection and serialization targets it can detect.
  • Names referenced by XAML, DI containers and similar.

Control-flow flattening

Instead of leaving your method’s logic in readable order, Nebula rewrites eligible methods into a dispatcher-driven state machine — a while (true) { switch (state) { … } } loop where each original basic block becomes a case. A decompiler can no longer show your original structure. Methods with exception handlers are handled conservatively to preserve correctness.

String encryption

Literal strings are encrypted at build time with a fresh per-build key and decrypted at runtime by an inlined routine with an unbranded name — so the decryptor doesn’t advertise which tool produced it.

Anti-tamper & anti-debug

Optional runtime guards detect a modified assembly or an attached debugger. You choose the reaction: throw, exit, or invoke your own callback method.

Resource & metadata hardening

Embedded resources can be encrypted, and metadata that leaks intent can be stripped or obscured.

Correctness

The point of an obfuscator is to change how code reads, never how it runs. Every transform is validated across .NET Framework 4.8 and .NET 6/8/9/10 in an automated suite that compares the protected output’s behavior against the original. Output verification also runs as part of each protect job by default (verifyOutput).

Obfuscation raises the cost of reverse engineering — it isn’t a guarantee. Combine it with licensing, signing and good release hygiene for defense in depth.