Another .NET packer

[SystemeD]

Hi all,
Surfing on the web I found another .NET packer and I began to unpack it. Full and demo versions of the protector are packed by itself so I started from there.
I suggest you to unpack demo version because it's the same thing as the full one except that you can avoid license check. You can find it here:
hxxp://dotnetprotector.pvlog.com/

I have dumped the exe and all the other assemblies loaded at runtime in the following way:

1 - Hardware breakpoint in Olly at PEFile::Create in mscorwks.dll

2 - Once there, dump using the Dumper feature of IsDebuggerPresent plugin for Olly, with the value at esp+4 as start address and the one at esp+8 for size

Now the problem: everything works till the .cctor() method of a dll called "dotNetProtector.Special.dll" is called. There I receive a NullReference Object Error from the CLR.
I think that the problem is due to the fact that probably the packer loader sets something before calling the main exe, so removing it leaves some objects not instatiated. Any suggestion on what to do?
Thanks.

[peleon]

Hello SystemeD,

I was looking to this packer but also got stuck. Well, mainly because i'm a really .NET newbie

I saw that the packer injects native code in the loader and also the COM directory is set to null.

I set a breakpoint when mscorwks.dll was called the first time and the COM directory was still null. How could this be possible? I mean, in the COM directory the assemblies are stored....do you know how and where the original COM directory is created.

Thanks.

In .Net assemblies are stored in %WINDIR%\assembly\ and the Runtime is in %WINDIR%\Microsoft.Net\Framework\version.xxx.xxx\ so it's not neccesary to call some API to get the COM directory (so it still seems to be null).There are simple methods and namespaces in .Net like Environment.GetEnvironmentVariable to retrieve the assemblies directory and "hardcoded" it in the .dll/.exe.Not that linking of .dll and assemblies can also be done on the fly in .Net while the .exe is running..

I'm going to have a look at it too and let you know if i find something.

[peleon]

Thanks rumor for the explanation.

I don't know if I explained well (probably I explained bad ) or I misunderstood your answer

In the PE header you can find valid entries for the COM directory and size of COM directory. I was wondering if the protector makes that entry NULL, how can the .NET protected application starts?

Do you think that it's loaded by the "protector's loader" before the protected target takes control? Because MSCORWKS.DLL (or any main .NET DLL) needs to know where the original data of the COM directory is located, right?

It should be great if we know how to "intercept" the loading of that COM directory, so we get the original data in the COM directory.

Thanks

Well, one main difference in PE Header between Win32 and .NET assemblies (.exe files), is the COM Directory and some metadata fields.Only .Net assemblies need the COM Directory.Why for?That's the way .Net Runtime recognizes this assembly as managed code.If it's a C++ with managed .Net extensions, only the extensions used are managed code..The rest of the file is pure Win32, so the COM Directory is null.Before loading MSCORWKS.DLL it MUST load MSCOREE.DLL.
Note that MSCOREE is the main runtime dll of the framework(s) even if multiple versions are installed.

Unfortunately i haven't look at it yet to have a better view of the protector..

[SystemeD]

Hi,
Finally I solved the last problems with this packer, so, for those who tried to unpack it, here is my way to do the job.
To let the things as simple as possible I used both the full and demo versions of the packer (demo for all the dlls and retail for the exe). What I did is Unpack/Crack/Repack (with demo version)/Repack (with full version):

1 - Write a little script for OllyScript to dump all the runtime loaded Assemblies. Be careful to the version of OllyScript plugin because the original 0.92 has a bug in DM (dump memory) command. You can skip this step and dump all by yourself without problem, but if you code a little script, it could be useful for other .NET apps too. The script will look like this (surely better than mine! ), and you can place hwbp where you prefer, the important thing is to retrieve information on the offset and the size of the assembly that is going to be loaded.

var addr
var size
var prefix
var name
var index

mov prefix, "c:\dump"
mov index, 1
bphws 7930e27c, "x"
eob dump
run

dump:
mov addr, esp

mov size, esp
add size, 4

mov name, prefix
add name, index
add index, 1
dm [addr], [size], name
run

2 - Load the packer demo version in Olly and launch the script. Protect something activating all the feature (it's important for dumping all the assemblies of the packer).

3 - Now you must obtain the full version exe. So you must crack it and let it run at least one time. A simple way to do that is to start it with Olly and let it show the not-licensed messagebox. Search for the following "sequence of commands":

MOV EAX,ESI
POP ESI                                  
RETN
XOR EAX,EAX
POP ESI                                  
RETN

There is a je right before. It's the good/bad boy jump. So place an hwbp on the je and restart the app. When Olly breaks change the je destination and run the previous script. You will have a dump of some dlls and also of the packer full version. Remember to backup the demo version dumps before restarting the script.

4 - Open the dumps in an assembly viewer and rename the dumps with their original names. There will be an exe (the full version protector) and the other are all the dlls (you can take them from demo or full version). Now you have a full unpacked version but if try to use it, it would crash because the AppDomain misses some information setted up by the loader. So what can we do? Easy, let's pack it again with the demo version!

5 - Start demo version and protect the full unpacked exe. You will see that it loads some extern assemblies needed to let the packer work.

6 - Now, if you try to use the full version (protected by you), everything would work fine. So why we need another step? Because we protected the full unpacked version with the demo version. This means that in few days our full version won't work anymore. So what can we do?

7 - Easy, let's protect the full unpacked version again, but this time using the full version of the packer (obtained at the previous step), before it expires and voil¨¤, job done!