Code protection is severe issue.

[YordanYanakiev]

The security is never sufficient. This is a fact. Yet the .NET compiled projects is practically distributed full source code for everyone which can work with a computer and can download basic decompillers. The Obfuscators and similarities which is around recently is quite not sufficient or at the best outdated. This is a severe issue, especially for wide distributing mid class applications, especially non-web across end clients. A lot of companies ( including mine ) are still preferring C++ Builder / Delphi instead of C# apps just because of this ginormous issue. I believe that .NET or at least WPF should provide ember encrypting at least during the compilation or some other approach increasing the security against decompiling of the result.

[Symbai]

I can understand your frustration and you're not alone. AOT would solve that problem (and some other) but unfortunately any attempt to make WPF AOT friendly is being ignored for years now. PRs are not getting reviewed like #6171.

[miloush]

The security is never sufficient. This is a fact.

I would disagree, different use cases have different requirements. Sometimes, no security is sufficient.

A lot of companies

That is anecdotal; you are the first in this repo to bring this up. A lot of companies also use JavaScript, with or without obfuscation.

Either way, this is most likely not the right repo to make such request, there is no point in WPF doing anything until .NET supports such feature. WPF is basically code + markup. For code, this needs to go after .NET. For markup, you can turn it into code, but even then, you can inspect the application at runtime, including walking the trees. Reflection is a fundamental feature of .NET so I wouldn't be too hopeful this would change.

I like @Symbai's observation that AOT might help here, sounds like your best bet.

[YordanYanakiev]

Great. Now the fanclub of the easy decompiling the other peoples source got triggered, and since they don't have any meaningful argument a laughingstock like JavaScript is thrown away. I really do not care who is using JavaScript and for what purpose. I care only for the scenarios where more security is required. No. AOT is not sufficient and practically means nothing. As well it should be not a big issue for .NET to switch to another bytecode VM by request, even at some cost. Even per-exe-created-VM with ember distribution will do much more than the current state. The idea is simple - for each EXE is recompiled as well the VM with on-the-fly encryption - decryption and even partiarly compiling C#->C++->direct instruction where is possible as a multiple DLLs. Reflection is not a problem if it is one direction if required to be so ( even if it is not required but used as such will still works in most scenarios ) .

[Symbai]

No. AOT is not sufficient and practically means nothing.

You say your company switches to C++ / Delphi because of that. I dont see why the code with C++ or Delphi would any better than other native code (AOT with stripped symbols). Its the same level of "protection" 🤷‍♂️

[YordanYanakiev]

No. I dont say that companies switching to C++ Builder / Delphi from C#. I am saying that companies does NOT wanna switch to C# from C++ Builder / Delphi since their code is more than protected even without additionally tools. About AOT - I am still not sure if they provide full or partial native code compilation, but knowing what's with the rest of such things - it will be partial most of the cases. I really hope I am wrong.

[Symbai]

No. I dont say that companies switching to C++ Builder / Delphi from C#

Sorry I misread

I am still not sure if they provide full or partial native code compilation

It is full native code but you can choose if you want to remain the capability of debugging like stacktrace with symbols etc.

[pchaurasia14]

As @miloush mentioned, this wouldn't be a feature for WPF specific but needs to be supported at .NET level. I'm not sure if there is anything meaningful that can be done by WPF alone.

[driver1998]

.NET NativeAOT is fully native code, which will be roughly the same as C++/Delphi in terms of decompilation or reverse engineering.

Also it is readily available for you to try out, it's only the WPF bits (and some other Windows-exclusive tech) that are not ready yet.

You can try putting critial code inside a AOT project, get that protected and use P/Invoke to call from your WPF app. (Yeah it will be similar to C++ in this regard as well, as you'll get a native DLL with C-style exports).

[YordanYanakiev]

Didn't notice that they advanced this far to be honest.

[Symbai]

it's only the WPF bits (and some other Windows-exclusive tech) that are not ready yet.

That's not true. WPF, WinUI, Winforms, MAUI, Xamarin.... literally everything (from MS) which is not a console or web application and run on a classic desktop environment is not supported. Which means as a .NET desktop app developer you don't get AOT (from MS).

You can try putting critial code inside a AOT project, get that protected and use P/Invoke to call from your WPF app

That doesn't give you anything in terms of protection. People can just easily find these calls and replace them. The whole application needs to be native code to get the same level as of a C++/Delphi.

[driver1998]

That's not true. WPF, WinUI, Winforms, MAUI, Xamarin.... literally everything (from MS) which is not a console or web application and run on a classic desktop environment is not supported.

There is some support on Winforms, and WinUI should be ready soon (let's see how long it will take to get C#/WinRT working with AOT). But overall you are right, Avalonia is more or less the only desktop framework with usable AOT support.

That doesn't give you anything in terms of protection. People can just easily find these calls and replace them. The whole application needs to be native code to get the same level as of a C++/Delphi.

For DRM purposes you are right, people can easily bypass the check by changing the managed side (Although cracks still exists with native code). I am more towards putting critial logic or algorithm there.

[lindexi]

Reference: https://github.com/NotPrab/.NET-Obfuscator

[YordanYanakiev]

Reference: https://github.com/NotPrab/.NET-Obfuscator

this is a junk. it's like whole 3 minutes of my life to get the idea inside the decompiled code. Obfuscators is more like prevention for extremally lame or lazy crackers, not a real protection, and we are speaking here about preventing the copy of the code, which could be copied and directly used even obfuscated.

[Aurumaker72]

Not only is this issue in the wrong repo, it also shows a fundamental lack of perspective.

The "security" provided by solely using C++ is nothing but security through obscurity. If you rely on it to the point of dismissing other technologies due to the lack of that security, maybe your company's threat handling model is flawed.

[lindexi]

@Aurumaker72 I totally agree with you