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.


10 comments:

Unknown said...

hi alberto, babel is cool!! can i contact u by email? i'm very instered in using phoenix framework. thx

Alberto Ferrazzoli said...

Yes you can.
My email is alberto.ferrazzoli@gmail.com

Frank Gennaro said...

I get the following error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'phx, Version=0.64.30627.0, Culture=neutral, PublicKeyToken=31bf
3856ad364e35' or one of its dependencies. The system cannot find the file specified.
File name: 'phx, Version=0.64.30627.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
at ?.Main(String[] args)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Alberto Ferrazzoli said...

It seem that you had not installed the right version of Phoenix framework.

Frank Gennaro said...

You are absolutely correct! I figured that out moments after I posted my comment. Also I apologize for the previous comment which does not belong here. On another note, someday I will visited Italy, the birth place of my grandparents. Thank you for the Babel project.

grimskog62 said...

I'm all for the changes you outline for version 1.4.

It would be great to have some rules file example, or default that fixes the enum issue you address.

I've been using the babel for quite some time and are very happy with. It is just that every now and then I run into a problem which is diffifult to resolve, and at times forces me to NOT obfuscate the code. This is more common when I use the obfuscated assembly on Vista x64. I guess I have to dig further into the documentation...

Alberto Ferrazzoli said...

Ok I'll try to update the Wiki page at

http://code.google.com/p/babelobfuscator/wiki/BabelRules

With more rules.

Anyway there is an open issue with 64 bit operating systems see:

http://code.google.com/p/babelobfuscator/issues/detail?id=8

may be you found the same problem.

Bye.

Unknown said...

Hi Alberto, I was the one that reported that issue about 64 bit compatibility. I would have to say that it would be very important in my case to have 64 bit functionality because of the nature of the code that I am obfuscating. I re-host the Windows Workflow Foundation designer in my application, and it uses an internal .NET compiler to output stand-alone workflow executable files. Unfortunately, the .NET class does not allow me to specify a target platform for the build, so if it's built on a 64 bit OS, it will output a 64 bit assembly. Since the dlls that it references are all obfuscated using babel, they are references in WOW64 mode, and therefore do not work. My option would be to use 'corflags' on the resulting assembly, but that's very clunky and I don't even know if I can redistribute corflags.

Secondly, having all obfuscated dlls run in 32 bit mode kind of defeats any performance gains that one could get being able to use 64 bit mode.

Hopefully I've made my case...I'm voting for 64 bit compatibility to be in the next release :) Have a good holiday, and thanks for working on such a great product!

Alberto Ferrazzoli said...

Hello Nathaniel,
Yes issue 8 the one that make me losing sleep :).
I am joking. Good work Nathaniel and thank you again for your help and time.

Ok 64 bit compatibility is the most important issue at the moment.
As I wrote in the original post, this incompatibility seem to be originated by the invalid IL opcodes inserted by babel to hide the inner method opcodes.

First of all I think that this kind of obfuscation is weak (but sometime useful) and does not add to much to the IL scrambling performed by the software.

In the next version of babel this feature will not be removed completely. Instead I have added the possibility to switch it off.
So if you compile for 64 bit as well as 32 bit targets you have just to turn it off.

The command line option that turn off bad IL opcode injection is now named:

--[no]invalidopcodes
Emit invalid opcodes (default: enabled)

As you can see it is enabled by default.
So any time you compile for 64bit you need to add to the babel command line the switch

--noinvalidopcodes

What is your opinion about this option?
Do you like it?

Now, I am writing a set of helper classes that allow me to generate easily managed types within Phoenix. This because I want to add in babel some ready made string encryption methods.
This task is not easy and will take me a lot of time.
The agent feature is ready and it will be the most important feature for the next release. Hope you like it.

Thank you for all, and have a you a Wonderful Christmas time.

Bye.

Unknown said...

Thanks Alberto, I think that the solution will be good. As long as a typical amateur using Reflector or other such tool can't view the code, I'm cool with it. I can't be too paranoid about it, as I'm well aware that if someone really wants to read my code, they will find a way to do it. :) Thanks again!