CodeVeil XHEO 4.1

[visions_of_eden]

Hi,

does anybody know if v4.1 of codeveil has been already broken ?

I just started analyzing this protection and it looks quite good to me . Maybe i'm wrong since i have not much experience in debugging packed application .

The way CodeVail load its code from managed code is quite smart , now i'm stuck in bypassing anti-debug checks , but as soon as i'll made some progress i'll post it there .

Thanks .

Nicola.

[kao]

It hasn't changed that much since v3.x, so.. Yes, it's been broken.

[bball0002]

^^^ What he said. Codeveil 3.2 --> latest use the same method "encryption" tactics. Although the anti-debug is pretty good, you could just make a static unpacker.

[visions_of_eden]

Originally Posted by bball0002

you could just make a static unpacker.

That's what i would like to do (but first i need to understand how the encryption is done ).
It's my first time with .NET unpacking. I read many posts about .NET protections , and even if i agree that obfuctation /packing it's not a reliable way to protect your code , i don't agree with all saying that XHEO or other protection are totally crap . Obviously for one that has exeprience in RE those protection could seem easy to defeat , but the way the protection itself was thought it's quite smart to me. Embedding the code that does hooking / encryption in the .NET executable and then calling it from managed code it's not a bad idea , the way the protection loads itself and the anti debug tricks used are not bad .
Maybe it's just my point of view .

[kao]

If you come from x86 reversing world, .NET application protections will look really simple for you. If you've done more than one static x86 unpacker, you won't have much problems with .NET.

• In most cases, .NET protector hooks into JIT engine, decrypts IL code on the fly and passes decrypted code to original JIT engine. That's pure x86 goodness.
• String protections are usually (but not always) done in managed code. In 90% of cases they are trivial.
• Resource protection usually depends on setting unresolved resource handler (managed code). Trivial.
• Control-flow obfuscation, junk code and other obfuscation methods have the same principles for all platforms. .NET makes it even easier because of IL code must be verifiable.
• Using .cctor's to initialize protection, invalid .NET metadata, using delegates and strong name key protection are the only things that are really .NET specific.

Just to give you the idea of (lack of) complexity - static XHEO unpacker fits in 800 lines + standard libs for zlib and xxtea + library for .NET metadata processing. Yes, it's that simple.

[visions_of_eden]

Originally Posted by kao

•Using .cctor's to initialize protection, invalid .NET metadata, using delegates and strong name key protection are the only things that are really .NET specific.

Yes , sorry if i was not so specific but that's what i was talking about .
I liked the approach used by XHEO on using the .cctor to start the protection .

Obviously i agree with you that .NET being a interpreted language can't have strong protection (like flash or java for example) .

All protections used to obfuscate a .NET assembly that are at least decent comes from unmanaged x86 world .

Just a question .... to unpack XHEO did u analyze the whole packer code or just hooked the JIT to get unencrypted code ?

[kao]

Originally Posted by visions_of_eden

.NET being a interpreted language

Please, check your source of information. .NET assemblies have IL code, that's true. But it's not interpreted, it's being compiled to native code by JIT compiler and then executed.

Nitpickers corner: the statement is true for most ECMA-335 implementations. Mono has both interpreter and JIT compiler available.

Originally Posted by visions_of_eden

All protections used to obfuscate a .NET assembly that are at least decent comes from unmanaged x86 world .

{smartassembly} does not come from x86 world, yet it's among the best .NET protections. These guys are really innovative and they know what they're doing..

Originally Posted by visions_of_eden

Just a question .... to unpack XHEO did u analyze the whole packer code or just hooked the JIT to get unencrypted code ?

Hooking into JIT is not what "static unpacker" means.. I analyzed JIT hook code and all the decompression/decryption routines. To do that you don't even have to have XHEO installed, few packed files are more than enough..

[0lojz0]

Hi,

i was hopping to get some explanation about DeployLX CodeVeil 4.1 "Code Encryption" (as they call it). What i did find on my own is that this is "easy"/"silly" protection but what i didn't find is some general overview/explanation of it.

To get involved in this reversing stuff is due to selecting some sort of .NET protection for my own project - and keeping in mind that it will be hacked

When i took a quick peek in my test app & codeviel (used only code enc) it was as is already known to public, no code avalible:
- i ran it thought CLR Profiler and no luck (only bytes from fat
method header, i think)
- used Reflector to dump .cctor code (call to CallWindowProcW)
- when used IDA on user32.dll with my app.exe and BP on
CallWindowProcW it shows that API is called with pointer
to .ctor of Program class and to Main method
- ...

And here im stuck due to lack of knowledge and experience with ASM / IDA stuff. So, i kindly ask you to help me with this - just some additional explanation and some pointers to get things moving again.

Thanks in advance,
Lojz

[kao]

I'm not sure what exactly you want to achieve, so I'm kinda shooting in the dark.

There are no publicly available unpackers for XHEO. Some Jitdumpers should be able to dump original IL code. Several members of this board will unpack XHEO in matter of minutes, you can try that with a test application.

Here's general overview on how XHEO works. It might not be entirely accurate but should get you started.
1) most of XHEO engine is unmanaged x86 code. It is partially encrypted and placed inside protected executable. If you have no previous experience in unpacking stuff, this will be hard to analyze.
2) XHEO adds code to .cctor's of protected executable. That code will execute XHEO unmanaged code I mentioned above.
3) unmanaged code will hook into .NET framework JIT engine and return.
4) when protecting executable, XHEO modifies procedure header and IL code in the following way:
a) store original procedure size in a special table (I'll call it XHEOTable)
b) copy original exception handlers and IL code to XHEOTable
c) set procedure size = 0
d) replace IL code of procedure with offset of original code in the XHEOTable
5) when some procedure is about to be JIT'ed, XHEO hooks will be executed. It will look up information about original procedure code in XHEOTable, decode correct IL code and exception handlers and pass it to the original JIT engine.

If you google around for details, you should be able to find some. All JIT-hooking protections work on the same principle.

Cheers,
kao.

[0lojz0]

Hi Kao,
thanks on fast and accurate reply (right on the spot )

That was what i needed, some general explanation what is under the hood. And just to clarify: if JIT is hooked that profiler(s) will not give the right code bytes (JITCompilationStarted), because it is not yet decrypted / copied ?

Thanks,
Lojz