Skater .NET Obfuscator is the powerful tool to protect .NET Core 3.x (3.0 and later) projects

Starting from version 3.0 the .NET Core SDK includes support for Windows Forms desktop applications and now .NET Core received more updates compared to full .NET Framework.

There is Windows Forms .NET Core UI framework for building Windows desktop applications in the .NET Core 3.0 presented. WinForms is a User Interface framework for developing Windows desktop applications. It is a .NET wrapper over Windows UI DLLs, such as User32, GDI+, and so on. It also includes visual controls and other similar functions that are unique to Windows Forms desktop applications.

To test how Skater obfuscator helps to protect .NET Core WinForms app, first we need to create new .NET Core Windows Forms desktop application.

To test how Skater Obfuscator protects WinForms .NET Core assemblies open Visual Studio 2019 (or later) and create new Windows Forms .NET Core project.

Let’s name the project as WindowsFormsNETCore3. We are pretty fed up by the names like ‘HelloWorld!’ and so on. You can get the attached project’s source code. To further test Skater obfuscator functionality, we have added some dummy classes, methods, and properties into the Form1.cs.

Just to remind you: the main .NET Core idea is to compile a Windows Forms app and then run it under any system. Not Windows only.

The .NET Core actual application is a dll library. Its .NET source code as any other .NET framework code is compiled into CIL/MSIL. .NET Core dll assembly contains code which the Common Language Runtime (CLR) executes. It can be disassembled (read ‘hacked’:) by anybody else. We still need to protect that kind of .NET assemblies by obfuscating them.

Skater supports .NET Core 3.0 projects where the publish output is a DLL file (Framework-dependent deployment). When the publish output is an EXE file that calls .NET Core DLL (Self-contained deployment) the final DLL has to be obfuscated as well. There are two types of .NET Core apps can be built:

Framework-dependent deployment. As the name implies, framework-dependent deployment (FDD) relies on the presence of a shared system-wide version of .NET Core on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example, dotnet app.dll runs an application named app.

Self-contained deployment. Unlike FDD, a self-contained deployment (SCD) doesn't rely on the presence of shared components on the target system. All components, including both the .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.

The .NET Core WinForms app development is following the Self-Contained Deployment (SCD) concept.

Let’s take a look at what the final binaries were compiled in the output folder of the WindowsFormsNETCore3 project.

You can see two main assemblies presented inside the output folder:

WindowsFormsNETCore3.exe

WindowsFormsNETCore3.dll

This pair of files represents the .NET Core Self-Contained Deployment (SCD) concept.

The final output for that Windows Forms app includes the WindowsFormsNETCore3.exe executable, which is a renamed version of the platform-specific .NET Core host, and the WindowsFormsNETCore3.dll library file, which is the actual application. Roughly saying, the WindowsFormsNETCore3.exe executable is the app’s starter with necessary predefined .NET Core utilities compiled inside the exe. Ideally the exe file is cross-platform executable. The executable is binary file compiled in machine codes. This file is undecompilable and do not need to be obfuscated.

So let’s concentrate on WindowsFormsNETCore3.dll assembly protection.

Take a look what we got after the WindowsFormsNETCore3.dll .NET Core app decompilation:

We can see the non-protected "Hello .NET Core 3.0!" string in the decompiler's interface. Decompilation tools can decompile a .NET assembly directly back to a high-level language like C#, VB .NET, or C++. We are ready now to obfuscate the sample WindowsFormsNETCore3.dll .NET Core app by using Skater .NET Obfuscator. In Skater .NET Obfuscator open WindowsFormsNETCore3 app.

Skater immediately identifies the WindowsFormsNETCore3.dll is .NET Core assembly:

Now you can adjust WindowsFormsNETCore3.dll app obfuscation settings and run its protection process. After all, you need to check what the output of the Skater obfuscation and how WindowsFormsNETCore3.dll app is protected. When you run the obfuscated app (run the WindowsFormsNETCore3.exe) it produces the same result. Take a look what changed inside the simple program. We need to run the decompiler again against the new obfuscated dll and it will give us the following decompilation result:

The "Hello .NET Core 3.0!" string has been allocated by Skater into a public variable then it was encrypted. We can pretty easily spot the encrypted string inside that decompiled script. Should this make it pretty obvious that our code is protected? Is it not simply too easy to decrypt the safe .NET Core source code? Almost. An absolute hacker still can choose a password for the encrypted string and decompile it.

Conclusion

No matter what we do, if our code is placed at the end-user's PC/Mac/Phone, it is not safe. As long as the code is placed at the end-user, all we can do is to make it as unwieldy as possible to get to the original source code, with any luck avoiding most hacker's deciphering attempts.