Guardship disassembles your .NET code and then compiles the MSIL code of your executable into native unmanaged application by generating two pieces: 1. Start module [Your_App_Name].com; 2. Library [Your_App_Name].lib
Your applications (WinForms, WPF, etc.) that target the .NET Framework are compiled to intermediate language (IL). At run time, the just-in-time (JIT) compiler translates the IL to native code. Guardship translates your .NET executable to native code to make it hidden. When you run the protected executable it has all features and functionalities of managed application performing in PC memory. But .NET assembly browsers and decompilers will not be able to read your protected .NET executables.
Why does Guardship convert to unmanaged executable?
There are a few disassemblers for decompiling unmanaged executables written in ASM, C, or C++. However none of them will manage to produce readable enough code to worth the effort. You will spend more time trying to read the decompiled source with assembler blocks inside, than writing the same-functioning application from scratch.
In fact, any executable module can be disassembled and explored. The easiness with which a decipherer can reverse-engineer your application source code depends on how complete metadata about the app's source code presents inside the exe module. May the decipherer figure out the original class names, methods, work flows, structures, etc.? A compiler basically compacts app's source code, transforming the output into a format which is much compliant to machine runtime execution. It could be a native machine code or IL byte code that is treated by CLR intermediate runtime. However, by and large, a lot of information about your application source code (debugging, comments, etc.) is simply can be lost during the compact compilation.
Comments