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
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 - 2021, Jelsoft Enterprises Ltd.