Security in .NET development
Posted 04/16/2009 at 23:34 by InvincibleNoOB
Hi,
Another article I wrote for Stealthex.org.I'd never not release something at elitepvpers that I had released somewhere else unless it's private.
//
Hello,
I pretty much failed on the task I set to myself for creating a clientless till my birthday,but I've gotten some presents from CUG and pediy that's worth to write an article about them.
Title: Security in .NET languages
1.Introduction
Security is one of the aspects people should worry about when making a commercial program.In the .NET Languages(J#,C#,VB.NET) your source is not exactly "compilled".
Its somewhere down the road between Source code and Native code.But I've got some bad news aswell in this article,not only your code can be understood,but the names of your functions,procedures,variables are also saved in that "compiled" executable.
I'll try my best to clear the situation.
When you compile an executable in a NET language using the Express editions of VisualStudio(or VisualStudio professional),the output file does not contain native code.Instead,it contains CIL(Common Intermediate language).
As I mentioned,your whole source is placed in the executable including the names of the objects you had used.
When executed,your program is being compiled by the CLR(Common Language Runtime),which turns your code(CIL) to native code.
(picture taken from wikipedia)
2. Protection
Numerious commercial tools exist for protection of .NET assemblies,but those who actually do the job are few.
Most of them(including the one integrated in MS Visual Studio - DotFuscator) offer code obfuscation,string encryption,ControlFlow obfuscation,Assembly name signing and the rest feautures just doesn't have to do anything with Protection.
Original:
Obfuscated:
Note,the strongest obfuscation declarates values with the same name as the variable name they lately use to compare each other.(for example instead "if . != 2",They declarate "int . = 2" and then "if . != ."
Naturally,its very easy once you get used to it.
We shall now compare a protected(obfuscated) .NET assembly with a native 32 bit application.
+In both cases,the code can be seen and understood lately.
+Names of functions/variables cannot be seen.
+They both can be traced with a debugger
- obfuscated .NET assembly can be decompiled,while the native 32 bit application has to be "decompiled" by hand.
Still,native application beats .NET assemblies,but this is just the start.
Again,an important note:We compared protected .NET assembly with not protected win 32 bit application.Although its not fair from moral view of point,still the win 32 bit application beats.
3. Solution
I've gotten two type of software for my birthday:
First tool - Eziriz .NET Reactor
Second tool - Xenocode PostBuild
They both have one feature that makes them best at this scene - turning CIL code into Native x86
Eziriz .NET Reactor turns your CIL code into Delphi7 executable with absolutely no difference.
As for Xenocode PostBuild,it's more powerful,but it has cons as well.It turns CIL to Visual Studio C++ v8(MS Visual studio 2005).
Once your application becomes native,you could do the same that you'd do with your win 32 bit application - use your favorite packer).
If we now compare our protected .NET assembly to protected win 32 bit application,they definitely are more equal to each other than they were in our previous comparison.
Second strong feature
Both tools can implement .NET framework runtime inside your application ,which makes it much more easier to deploy your application,but it has cons too - 15MB file.(NET v2) and 30MB(NET 3).
Third feature
That's something you can do in your win 32 bit application as well.Both protectors offer embedding of the dynamic libraries your application is using,but thats not what we need here.
Both protectors can obfuscate your code(in native meaning of the word)
4. Conclusion
Nothing is unpackable/uncrackable ,but there's always something that's better than anything else,I tried my best to give you the knowledge about that thing.
5. End.
Now I think there's no way to argue about .NET assemblies being decompiled if they are protected with the right tool.
Written by hand for Stealthex!
//
Another article I wrote for Stealthex.org.I'd never not release something at elitepvpers that I had released somewhere else unless it's private.
//
Hello,
I pretty much failed on the task I set to myself for creating a clientless till my birthday,but I've gotten some presents from CUG and pediy that's worth to write an article about them.
Title: Security in .NET languages
1.Introduction
Security is one of the aspects people should worry about when making a commercial program.In the .NET Languages(J#,C#,VB.NET) your source is not exactly "compilled".
Its somewhere down the road between Source code and Native code.But I've got some bad news aswell in this article,not only your code can be understood,but the names of your functions,procedures,variables are also saved in that "compiled" executable.
I'll try my best to clear the situation.
When you compile an executable in a NET language using the Express editions of VisualStudio(or VisualStudio professional),the output file does not contain native code.Instead,it contains CIL(Common Intermediate language).
As I mentioned,your whole source is placed in the executable including the names of the objects you had used.
When executed,your program is being compiled by the CLR(Common Language Runtime),which turns your code(CIL) to native code.
(picture taken from wikipedia)
2. Protection
Numerious commercial tools exist for protection of .NET assemblies,but those who actually do the job are few.
Most of them(including the one integrated in MS Visual Studio - DotFuscator) offer code obfuscation,string encryption,ControlFlow obfuscation,Assembly name signing and the rest feautures just doesn't have to do anything with Protection.
Original:
Code:
public static UInt16 DecryptSize(int size, byte[] packet)
{
if (size != 2)
{
return;
}
UInt16 packetSize = BitConverter.GetBytes(packet,0,2);
packetSize |= 0x8000;
return packetSize;
}
Code:
public static Uint16 .(int ., byte[] .)
{
int . = 2;
if(. != .)
{
return;
}
int . = 0;
int . = 2;
UInt16 . = BitConverter.GetBytes(.,.,.);
Uint16 . = 0x8000;
. |= .
return .;
}
Naturally,its very easy once you get used to it.
We shall now compare a protected(obfuscated) .NET assembly with a native 32 bit application.
+In both cases,the code can be seen and understood lately.
+Names of functions/variables cannot be seen.
+They both can be traced with a debugger
- obfuscated .NET assembly can be decompiled,while the native 32 bit application has to be "decompiled" by hand.
Still,native application beats .NET assemblies,but this is just the start.
Again,an important note:We compared protected .NET assembly with not protected win 32 bit application.Although its not fair from moral view of point,still the win 32 bit application beats.
3. Solution
I've gotten two type of software for my birthday:
First tool - Eziriz .NET Reactor
Second tool - Xenocode PostBuild
They both have one feature that makes them best at this scene - turning CIL code into Native x86
Eziriz .NET Reactor turns your CIL code into Delphi7 executable with absolutely no difference.
As for Xenocode PostBuild,it's more powerful,but it has cons as well.It turns CIL to Visual Studio C++ v8(MS Visual studio 2005).
Once your application becomes native,you could do the same that you'd do with your win 32 bit application - use your favorite packer).
If we now compare our protected .NET assembly to protected win 32 bit application,they definitely are more equal to each other than they were in our previous comparison.
Second strong feature
Both tools can implement .NET framework runtime inside your application ,which makes it much more easier to deploy your application,but it has cons too - 15MB file.(NET v2) and 30MB(NET 3).
Third feature
That's something you can do in your win 32 bit application as well.Both protectors offer embedding of the dynamic libraries your application is using,but thats not what we need here.
Both protectors can obfuscate your code(in native meaning of the word)
4. Conclusion
Nothing is unpackable/uncrackable ,but there's always something that's better than anything else,I tried my best to give you the knowledge about that thing.
5. End.
Now I think there's no way to argue about .NET assemblies being decompiled if they are protected with the right tool.
Written by hand for Stealthex!
//
Total Comments 0
