Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Go Back   Reverse Engineering Team Board > Reverse Engineering Board > .NET Reverse Engineering
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #1  
Old 02-25-2011, 09:08 AM
visions_of_eden visions_of_eden is offline
Member
 
Join Date: Nov 2010
Posts: 13
Default CodeVeil XHEO 4.1

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.
Reply With Quote
  #2  
Old 02-25-2011, 09:39 AM
kao kao is offline
Senior Member
 
Join Date: Sep 2007
Posts: 184
Default

It hasn't changed that much since v3.x, so.. Yes, it's been broken.
Reply With Quote
  #3  
Old 02-26-2011, 05:11 PM
bball0002 bball0002 is offline
Senior Member
 
Join Date: Mar 2009
Posts: 72
Default

^^^ 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.
Reply With Quote
  #4  
Old 02-28-2011, 05:59 AM
visions_of_eden visions_of_eden is offline
Member
 
Join Date: Nov 2010
Posts: 13
Default

Quote:
Originally Posted by bball0002 View Post
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 .
Reply With Quote
  #5  
Old 02-28-2011, 06:37 AM
kao kao is offline
Senior Member
 
Join Date: Sep 2007
Posts: 184
Default

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.
Reply With Quote
  #6  
Old 02-28-2011, 07:05 AM
visions_of_eden visions_of_eden is offline
Member
 
Join Date: Nov 2010
Posts: 13
Default

Quote:
Originally Posted by kao View Post
•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 ?
Reply With Quote
  #7  
Old 02-28-2011, 07:55 AM
kao kao is offline
Senior Member
 
Join Date: Sep 2007
Posts: 184
Default

Quote:
Originally Posted by visions_of_eden View Post
.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.

Quote:
Originally Posted by visions_of_eden View Post
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..

Quote:
Originally Posted by visions_of_eden View Post
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..
Reply With Quote
  #8  
Old 04-04-2011, 05:35 AM
0lojz0 0lojz0 is offline
Junior Member
 
Join Date: Apr 2011
Posts: 3
Default

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
Reply With Quote
  #9  
Old 04-04-2011, 06:13 AM
kao kao is offline
Senior Member
 
Join Date: Sep 2007
Posts: 184
Default

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.
Reply With Quote
  #10  
Old 04-04-2011, 08:04 AM
0lojz0 0lojz0 is offline
Junior Member
 
Join Date: Apr 2011
Posts: 3
Default

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
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump





Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.