Thursday, November 13, 2008

Plans for next release v.1.4

I am working on the next release of babel. That will be tagged version 1.4.
This version will improve obfuscation reliability with the new agent engine.

Babel current version 1.3 has the obfuscator engine that basically obfuscate all types, methods properties and so on according to their visibility.
With the assembly so obfuscated there is no guaranty that during execution everithing goes fine.
Most of the time a runtime exception may occurs with obfuscated types that are reflected.
For istance if you have a private enum type used to enumerate the names of properties stored into some file you may code something like:

private enum MyProperty 
{
Height,
Width,
Color
}

string[] availableProperties = Enum.GetNames(typeof(MyProperty)) ;
...

This code after obfuscation may became:

private enum a
{
a,
b,
c
}

string[] availableProperties = Enum.GetNames(typeof(a)) ;

so at the end the property names will be (a, b, c)  and the program will no run as expected.

In babel version 1.3 so you are forced to write an XML rule file with a rule that block the oobfuscation of the enum type MyProperty.

With obfuscation agent the obfuscated assembly is parsed before obfuscation and all the types that may cause problem are left out from renaming.

The agent should take care of many rules and dig also into IL code to do his job increasing the total obfuscator processing time but I think is a great feature.
 
To write  the obfuscation agent I had to change the babel obfuscator engine. This new engine is faster then the one in version 1.3 and it also fixes some bug that occurs with generic types.
These days I am debugging this new engine and after that I will start to code the agent.

Another think I like to change in v.1.4 is string encryption.
If you used babel string encryption you know that you have to provide code to encrypt and decrypt strings to the obfuscator. This is a nice feature because you can customize your encryption algorithm but have also its drawback (maybe):
You cannot encrypt strings of assemblies where the code is not avaliable (try to think a way to  overcome this limitation with babel 1.3).
So I'd like to insert a basic encryption algorith to the obfuscated assemblies that do not provide their encryption and decryption function.

Another aspect that I want to take care is 64 bit compatibility.
Recently a bug was notified about obfuscation of assembly targetin 64 bit platform (issue id 8). This bug turn out to be due to the invalid IL opcodes inserted to the beginning of every method. These bad opcodes prevent Lutz Roeder .NET Reflector (unfortunately not ILDASM) to show the method IL. But on 64 bit platform, the IL of assemblies compiled with "Any CPU" is validated by runtime before  execution, and because the obfuscated MSIL is not valid, the assembly is loaded into WOW64 subsystem. If the obfuscated assembly is a dll refereced by an executable running in full 64 bit environment, Kaboom! the application crash in a very bad way.

Now I think that this kind of IL obfuscation that break execution in 64 bit environment does not add so much to the IL scrabling performed by babel so I think that this feature should be removed in future release.
What do you think about?

Please use this blog to discuss about babel feature or about obfuscation in general.
Your post will be usefull to me to improve babel and also to other people that intend to protect their asseblies.


Tuesday, November 11, 2008

Babel Obfuscator Blog

Hi this is the new blog created to discuss about Babel Obfuscator.
Please leave here your comments about babel.

I will use this blog to give you some news about the developing status,
feature that I'd like to add, and some useful hints for get the best  from babel.

Please post post and post!

Thank you,

Bye