[CodeRipper]

DeployLX CodeVeil 3.2 unpacking challenge

Intro:
With DeployLX CodeVeil you can encrypt your .NET applications and DLLs. DeployLX CodeVeil adds native code to the assembly to decrypt the assembly just before the .NET runtime needs access to the data. The decoder includes anti-debugging, anti-tracing, modification tracking, and various other advanced techniques to prevent unauthorized access and modification of your assemblies. Veiled assemblies can be used just like any other assembly - no third party dll is required with your distribution! Don't want encryption? No problem, DeployLX CodeVeil still includes the best obfuscation techniques without adding any additional runtime requirements.

DeployLX CodeVeil 3.x Feature Summary
* Encrypt your Software and prevent unauthorized users from viewing or modifying your assemblies.
* Any .NET Project including Windows Applications, ASP.NET Controls and Sites, Windows Services, EXEs or DLLs.
* Industry Leading Obfuscation using multi-assembly usage analysis to maximize the reduction of meta-data and increase confusion.
* Anti-Reflection technology to frustrate tools like ILDASM and Reflector.
* Runtime Protection including anti-debugging, anti-memory dumping, anti-tracing and anti-profiling.
* Tamper-Resistence makes it extremely difficult for hackers to modify the assembly and remove licensing and other restrictions.
* String and Resource Encryption to protect your sensitive data.
* Integrated MSBuild Tasks make it easy to integrate CodeVeil into your automated build process.


Level: hard

Rules: Solutions must be a deprotected and working standalone executable of the original executable.
This is only an unpacking challenge.

You must provide details of how you did it.

Good luck!

Attached File(s)

•  CV_3.2.unpackme.zip (28.93K)
  Number of downloads: 188

[high6]

Probably gonna wait to do this, if you have been following the chatbox. I am having trouble with detours 1.5 right now .

[EvOlUtIoN]

Why unprotected? It is not packed, or i'm going wrong?

[CodeRipper]

Is protected.
If you try to dissasemble some methods you will see that have no body - MSIL is encryted.

[Kurapica]

UFO made a great progress on this and soon there will be an update.
I was working on the new smartassembly version which seems alittle harder than before, some good news is coming.

[RapiD]

Kurapica, on Jun 3 2009, 04:34 PM, said:

UFO made a great progress on this and soon there will be an update.
I was working on the new smartassembly version which seems alittle harder than before, some good news is coming.

I have gotten somewhat far in terms of disassembly. If you rename all the methods, it will open right, but method bodies are still encrypted. Still not the way I would go, it defiantly seems that by decryption of the PE, just about most of it can be recovered. In some of my test unpackme's, even with encrypted methods and method bodies, i decided NOT to encrypt strings, and I found the names for all functions that I put in.

I am still having issues with running mine on a 64-bit system though. No matter what I tried editing every PE, it still errors with a 32-bit system check. I believe that is a part of DeployLx however, if it were mere incomatibility errors with the dll's, it would have simply produced run-time errors. Therefore what I did is I ran it in a virtual environment using a 32-bit copy of Windows XP within my 64-bit copy of Win7.

Still interested in whatever related research there might be. Personally I would rather look into this rather than smartassembly 4.0, as following namespaces and method bodies seems viable.

[Kurapica]

@ CodeRipper : Can you send me the original file ? I need it for more analysis

[RapiD]

Kurapica, on Jun 3 2009, 06:57 PM, said:

@ CodeRipper : Can you send me the original file ? I need it for more analysis

Would it actually be possible to just post a link to the file here? Also, what protection settings were used for this file?

[Kurapica]

CodeRipper : did you use the full version of DeployLX CodeVeil 3.2 when you packed this exe ?

[CodeRipper]

@Kurapica:
No, I've used the trial version.
I don't have the full version.

This post has been edited by CodeRipper: 04 June 2009 - 06:07 PM

[Ufo-Pu55y]

Here's just a small PoC:  CV_3.2.unpackme_unfinished_.rar (17.25K)
Number of downloads: 62
Don't try to run it ofc, coz it won't. Tho you can already browse it in Reflector
and all strings are decrypted. Things like restoring resources and cleaning sh!t code are
still to be done...

Started on coding a msil lib some months ago, in order to easily unpack cheap protections like this one.
You are on the wrong way actually. You don't need to hook CompileMethod or anything else.
It's of no interest how it looks in memory. Everything can (has to be) done statically.
And no - there is no MSIL encryption. They simply split all methods from their method headers
and place them at the end of the .text section. Requires a lib which is able to restore stuff like that,
like I started to code one. Maybe I'll continue and finish soon, but got other interests atm :\
On the other side I wanted to see a real target protected with a newer version first -
because I'm not sure, if this is not the trial version only, which leaves the MSIL naked.

PS: They are using a modded cecil for their crap... lazy b!tches !11

This post has been edited by Ufo-Pu55y: 04 June 2009 - 06:59 PM

[CodeRipper]

@Ufo-Pu55y:

Regarding MSIL encryption I've got this crap from deveolper:
http://www.xheo.com/Blog/post/DeployLX-Cod...2-Released.aspx
Just search for keywords 'encrypts MSIL' and you will find them!

I've noticed the fact your way is easier then mine (seems that I've complicated things too much)!
My way was like this: get the IL code from the high memory area (I've talked on this under a previous post) and place the IL code after method headers (right place)! I was on the point to code something to do this for all methods.

Respect to the master!

This post has been edited by CodeRipper: 04 June 2009 - 09:13 PM

[RapiD]

Ufo-Pu55y, on Jun 4 2009, 07:57 PM, said:

Here's just a small PoC: CV_3.2.u...inished_.rar
Don't try to run it ofc, coz it won't. Tho you can already browse it in Reflector
and all strings are decrypted. Things like restoring resources and cleaning sh!t code are
still to be done...

Started on coding a msil lib some months ago, in order to easily unpack cheap protections like this one.
You are on the wrong way actually. You don't need to hook CompileMethod or anything else.
It's of no interest how it looks in memory. Everything can (has to be) done statically.
And no - there is no MSIL encryption. They simply split all methods from their method headers
and place them at the end of the .text section. Requires a lib which is able to restore stuff like that,
like I started to code one. Maybe I'll continue and finish soon, but got other interests atm :\
On the other side I wanted to see a real target protected with a newer version first -
because I'm not sure, if this is not the trial version only, which leaves the MSIL naked.

PS: They are using a modded cecil for their crap... lazy b!tches !11

Can you give some more info on how this exactly works? I am very interested in taking on DeployLx, but I am still rather new to exactly how some of these concepts work. I am assuming you used your library for that last file, is there any possibility of a tutorial or related for unpacking what you've gotten so far?

Also, do you know much about the 32-bit lock? I only have limited access to a machine running a 32-bit OS, most of the time I am using my main computer that runs Windows 7 x64. If possible, I would like to at least remove locks as well.

Thanks for the info man!


EDIT: Alright, I don't wanna break forum rules here. However if you do need a target patched with the full version, I do have one, although it is a specific application that I am trying to crack myself. I know that would be counted as a crack request, but it's there if you need something of that nature.

I have been looking into the moved MSIL code here. From what I looked at and comparing to your description of how it works, all the method bodies have indeed been moved to the end of the .text section. I did a simple search for specific opcodes that I KNEW would be in there, and they pointed to a large block concatenating the .text block (for reference, the .text block RAW Address is 0x39A00 bytes in size). However there's three questions this leads me to:

- How are these exactly pointed to? From what it looks, might be a simple common offset (code is placed in exact same order, just moved from one part in the file to another).

- WTH happened to the method headers? Each method should have a 0xC-byte header, however I checked those that I could find and they all have invalid method sizes. Not to mention the header seems to be completely seperate from the body (Yet, the method headers that I've looked through seem to be completely irrelevent to begin with).

- Some fields and related seem to have invalid names. I look through, and over a hundred fields have a name offset of 0x1884, which is blank.

This post has been edited by RapiD: 05 June 2009 - 04:09 AM

[RapiD]

I was just doing another compare. There are definite differences between the trial and full.

TRIAL: You can still reflect methods, some methods are still largely intact, does not crash reflector. I notice that any other methods simply leave empty method bodies, but nothing that shows as completely invalid.

FULL: Crashes reflector upon attempting to load any namespace. Object references are usually null which causes errors, method names and invalid method bodies crash any attempt at reflection.

BOTH: both versions seem to have the same general routine that's used. All method RVA's point to invalid Method headers. Method bodies for both versions directly concatenate the .text section, but I'm still not too sure how they're pointed.

I can get you a copy of a program protected with the FULL version, but you may count it as a crack request, so I leave it up to you if you wish to study it. Several of the files are simply libraries, with one main executable file. If you want to study these, contact me with either of the following:

AIM: rapidfeur
MSN: rapidcrasher@gmail.com


EDIT: Alright, so I did figure out a bunch more information tonight, here is what I have so far:

- Looking through the Method table, you can see many entries. There are actually mostly redundant tables, from what I can tell, these are simply .Ctor() functions. How do you know it is redundant? From what I've gathered, only the redundant Methods have a Method_Head that follows the TinyFormat format (Flag of 0x2). Therefore you could actually remove any method that has this Flag (Although I have not tried it, it should be fairly easy to do).
- Those with FatFormat flags (Flag of 0x3), regardless of whatever other flags are present, will have a resulting method_body. Example could be the following:

13 30 04 00 00 00 00 00 08 00 00 11

These method_headers are fairly intact, in fact they miss but one piece from the original functioning header, and that is the method_body_length. Concatenating each entry is some pointer that looks something like:

2A 80 9C 00

Now I know these are pointers. From what I am looking at here, it may be a CorILMethod_Sect struct that points to the Method_body.
I have been using this to calculate the offset for each resulting method body using the following formula:

Address_of_Entry_Point + Entry_Point_Size + 0x4 + Data_Size

and then to calculate CodeSize within Method_Header (For this, I am going to use N as the number of the Method_Header in the list), you take:

N_Data_Size - (N - 1)_Data_size - 0x4

Where Data_Size is still taken from CorILMethod_Sect of both Methods.


Now, I am probably wrong on some of this. Most of it I have only been able to check/verify just a few times. However I am working well into the time I usually take to sleep, so I will have to finish more research tomorrow. As for now, that is what I have been able to figure out on my own. Thanks for the lead UFO, I find this information surely useful.

Once I finish up research on how the method_bodies are sorted, I will look at what else may need to be fixed as well. As for making any sort of automated application, that is very unlikely as I am still a newbie at how exactly the PE works (I get enough of it to make my way around it fairly easily, as for actually editing and modifying it, that's a different story).


UFO-Pu55y, my bad about the file. I meant to post the link, but I wrote out the PM before I got it completely uploaded, then sent off forgetting to give you the link. Since the system won't let me PM you for another 8 hours, here is the file:
http://rapidshare.co...84567/360ke.zip

Alright, so I just started working on a program to do basic MSIL relocation. I am only having one major issue, and that is in calculating the size of method code.

This post has been edited by RapiD: 06 June 2009 - 01:02 AM

[Ufo-Pu55y]

RapiD, on Jun 5 2009, 12:20 AM, said:

Also, do you know much about the 32-bit lock? I only have limited access to a machine running a 32-bit OS, most of the time I am using my main computer that runs Windows 7 x64. If possible, I would like to at least remove locks as well.

did you mean this one ?

[MethodImpl(MethodImplOptions.NoInlining), DllImport("kernel32.dll", EntryPoint="GetModuleHandle")]
private static extern IntPtr GetModuleHandle(string lpModuleName);
internal static void CheckBitVersion(bool bUnused)
{
	IntPtr ptrKernel32 = GetModuleHandle("kernel32.dll");
	lock (typeof(object))
	{
		if (IntPtr.Size == 8)
		{
			if (Environment.UserInteractive)
			{
				MessageBox.Show(null, "This software was designed for use with 32-bit versions of Windows. "
							+ "Please contact the publisher for a compatible version.", 
							"64-bit Hosts Not Supported", MessageBoxButtons.OK, MessageBoxIcon.Hand);
				Environment.Exit(1);
			}
			throw new InvalidOperationException("This software was designed for use with 32-bit versions of Windows. "
							+ "Please contact the publisher for a compatible version.");
		}
		if (!InitNativeStub(ptrKernel32.ToInt32(), 
			Marshal.GetHINSTANCE(Assembly.GetExecutingAssembly().ManifestModule).ToInt32()))
		{
			Environment.Exit(1);
		}
	}
}

Dunno if I'm going to erase all the static CV stub stuff, but w/o CV the targets will ofc run on x64 again.
It's only needed for their native hook. As long as the target doesn't require x86 itself ofc..

This post has been edited by Ufo-Pu55y: 08 June 2009 - 07:04 PM

[RapiD]

Ya I noticed that when looking through the crackme from the original post. Never saw it when I asked because I tend to not look through it's containing namespace (usually only contains arbitrary code that's essentially the same from program to program).

[nath90]

so has anyone had any luck with this? If a program is protected by this would it be the DeployLX CodeVeil3.2.dll i need to edit first? i try to run the main exe of the program in OLLEY DEBUG but no luck . Im new to cracking an would like to know more about it.

[sirp]

ahh trying to remove CV stub let's try on 64 bit system

This post has been edited by sirp: 19 November 2009 - 10:04 AM