Obfuscation with mixed images.

[TheBerk]

Hi, I've been looking into obfuscation with mixed code (native c++ and managed c++), from what I've found native c++ doesn't need to be obfuscated much since its compiled into machine language, but managed c++ is compiled into a intermediate language which is very easily reversed compiled. Does anyone know what a mixed language program is compiled into? And if its compiled into the intermediate language does anyone have any recommendations for a quality obfuscator which handles mixed images? Thanks!

Also, I apologize if this is the wrong forum from this.

[TheCPUWizard]

Hi, I've been looking into obfuscation with mixed code (native c++ and managed c++), from what I've found native c++ doesn't need to be obfuscated much since its compiled into machine language, but managed c++ is compiled into a intermediate language which is very easily reversed compiled. Does anyone know what a mixed language program is compiled into? And if its compiled into the intermediate language does anyone have any recommendations for a quality obfuscator which handles mixed images? Thanks!

Also, I apologize if this is the wrong forum from this.

It is complied into a mixture of native code and IL.

There are two things that make reverse engineering of managed code a bit easier than native C++

1) There is a wealth of MetaData available. This is necessary to support things such as reflection which are not possible with native code.

2) Many of the optimizations performed by a neative C++ compilerer are deferred until the IL is compiled to native code [JIT]. Thus the structure of IL is generally more straight forward.

Obsfucation worked by a number of techniques....

First is the replacing of identifiers with "meaningless" names. Functionally this is equivilant to having to reverse engineeer a program written in a (human) language that one does not understand. This does not change security, in any significant way, but it potentially does break legitimate use cases [especially in "library" type situations.

Second is the modification of the MSIL. This breaks reverse-compilers from recognizing the sequences, and generating source level code. Unfortunately it also (not always but often enough) can introduce side-effects as the JIT compiler also may not recognize certain constructs and may generater less than ideal native code.

"Security by Obscurity" is a fallacy. On a regular basis I am contracted by clients with a real (legitimate, legal and moral) need to reverse engineer code given only the executable. For C++ programs specifically, if I can determine the compiler used (which I normally can), then the optimized constructs that it is known to use can be accounted for fairly easily, and functional equivilant source be generated fairly quickly (cleaning it up to make it a sustainable source is a larger project).

My company decided to follow the lead of Microsoft and many other vendors to NOT obsfucate commercial assemblies. After a careful analysis (for our customer base/market) the cost/benefit ratio simply was not there....

Getting back to the original...In a mixed assembly, there is no significant difference between what is generated vs what you would have with two asssemblies (one 100% native, the other 100% managed).

[darwen]

I don't obfuscate assemblies on a regular basis either and none of the companies I've worked for every have.

If I do really need to obfuscate an assembly (for instance one containing license key reading code) I encrypt it (using native code) and save it to a file.

Then on loading of the application explicitly load the file, decrypt it to a byte array (using a native C++ routine) and load it into memory (using Assembly.LoadFrom).

This doesn't work for mixed-mode assemblies, only verifyable ones, but if I'm writing a mixed mode assembly and don't want users to see some sections of the code I simply write these sections as native C++ and hey presto ! It's as unreadable as any usual C++ app.

Darwen.

[TheCPUWizard]

This doesn't work for mixed-mode assemblies, only verifyable ones, but if I'm writing a mixed mode assembly and don't want users to see some sections of the code I simply write these sections as native C++ and hey presto ! It's as unreadable as any usual C++ app.

That only works if you take additional steps to prevent analysis once the assembly is loaded into memory. (I wish I had $100 for every time I saw a similar approach, attached a debugger to the running executable, and presto had everything I needed....)

[Lindley]

Ideally license-key reading code should make use of algorithmically secure approaches such as RSA encryption, rather than trying to hide the executable instructions themselves.

[darwen]

Ideally license-key reading code should make use of algorithmically secure approaches such as RSA encryption, rather than trying to hide the executable instructions themselves


True, but what happens if you store the encryption keys in .NET code (or even native C++) ? You can disassemble/decompile, get the keys and then hack away.

For this reason I tend to programatically generate encryption keys by an algorithm which will always produce the same result - no constants are then held in the binary which can be picked up by viewing in a binary editor.


I wish I had $100 for every time I saw a similar approach, attached a debugger to the running executable, and presto had everything I needed....)


A good reason for turning debug info (compile & link) off in C++ release builds... it's on by default in VS2005 (grrr).

I also tend to mark my native C++ code with #pragma managed(off) etc clauses to prevent the C++/CLI compiler thinking "oh I can turn this into managed code, so I will !"

Anyway no method is 100% safe...

Darwen.

[TheCPUWizard]

Until security is implemented internal to the CPU, any software that is deployed to machines where you do not have strict administrative control will be insecure.

This is one place where server based computing provides capabilities that simply can not be accomplished using client hardware (in the sense of a general purpose Windows/Mac/Linux system)

[darwen]

I agree 100%.

I feel like I'm going back in time, back to when I used to work on a VT100 dumb terminal with all the computing power of a blade of grass connecting to a Sun server which kept going down all the time...

...I'm not quite old enough to remember punch cards.

I wonder if the authors of Crysis considered writing a serverside only version to prevent copying ?

Darwen.

[darwen]

Actually aren't we running the risk of the net developing its own intelligence, then deciding to nuke humankind out of existance ?

Oh sorry, that's the plot for The Terminator.

Darwen.

[TheBerk]

Wow, lots of information here, guys! Thank you very much for the help, this answered a lot of my question!

But now I'm worried about SkyNet...