Protecting Source Code

[TonyValenti]

What is the right way to protect .NET source code? We'd like to protect data in such a way that our code is not immediately obvious to someone using a decompiler.

I've looked at obfuscators and they tend to not be reliable. I've also investigated single-file apps, but those can be extracted then easily inspected.

Any thoughts? Is there an article somewhere that talks about protecting source code?

[TonyValenti]

Also, would NativeAOT solve this?

[gfoidl]

Yep, NativeAOT would be a proper solution, as the "binaries" are in native format (ILSpy will refuse to read it).

But as you said, then it's just "not immediately obvious". To avoid reverse engineering completely just don't share your code / app. Leverage something like a server/client architecture, where the crucial code-parts are on the server side that is under your control.

Which trouble did you get from obfuscators? Or did you just read about them?
(Note: I don't like obfuscators anyway, but if there are some bugs and the tool is open source, you should file bugs there).

[TonyValenti]

@gfoidl - That is really helpful.
I generally use Obfuscar and have found it really awesome, however, it is not smart about System.Linq.Expressions and that messes us up quite a bit.

I just read that NativeAOT will be targeting console apps first. That's a bummer because my app in question is WPF.

[gfoidl]

WPF is quite reflection heavy. How should this work with NativeAOT anyway?

In general I quite often ask myself: why do people invest (soo much) time in trying to protect / obfuscate their code, when they could invest that time into (better) code 😉

I don't see any reason to obfuscate the code.
Note: I'm earning money by writing (un-obfuscated) .NET code, and think it's a misconception that only obfuscated code is protected. Intellectual properties are protected by other measures, laws, etc.

Sorry, I can't contribute more to your question / problem now.

[Clockwork-Muse]

To be more clear - the only thing NativeAOT would do is prevent ILSpy from reading it. There exist a number of native-platform decompilers, for the exact same reasons, which may provide enough information that your code isn't really any less obvious.
The gaming industry has spent probably a billion dollars in this space, and has yet to succeed.

[deeprobin]

Well, reverse-engineering something is always possible. You can only make it harder. For example by NativeAOT or any solutions that disguise your IL a bit.

However, obfuscation (almost) always brings performance disadvantages with it, unless it is only name mangling.

[En3Tho]

You can always over engineer your code so one one can understand it anyway 😉