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 ?