[unpackme] PEP 5.0.0

[SHADOW_UA]

Here is a new challenge for you guys, this time it is protected with private exe protector 5.0.0

PEP_UnpackME_5.0.0.zip

[White]

Hi,Nice unpackme.

 

Found IAT Redirection VA :

0F0172EF      75 07          jnz short 0F0172F8

Mod 'jnz' to 'jmp' then you will get all real API Addr.

 

And the next  is rebuilding its resource structure.

[Raham]

Unpacked.

Unpacked.rar

[evlncrn8]

nicely done raham...

though, is the rediculous image size (on the crackme) actually correct? or (as im guessing) is it some silly anti dump thing?

[Raham]

nicely done raham...

though, is the rediculous image size (on the crackme) actually correct? or (as im guessing) is it some silly anti dump thing?

 

 

=> As you guessed, the anti dump is not effective, and its useless also in PE Structure

Edited October 8, 2014 by Raham

[xSRTsect]

I think the purpose with the gigantic imagesize on the pe is so that the memory needed to allocate the image is much bigger and hence to slow down your  debugger - proves effective here as it is so annoying that every single operation on the debugger is so slow.

 

(http://puu.sh/c4ls1/9d80220c9d.png)

Edited October 8, 2014 by xSRTsect

[kuazi GA]

Licensing system have change??

[GIV]

I think the purpose with the gigantic imagesize on the pe is so that the memory needed to allocate the image is much bigger and hence to slow down your  debugger - proves effective here as it is so annoying that every single operation on the debugger is so slow.

 

(http://puu.sh/c4ls1/9d80220c9d.png)

I do the following.

Find OEP witch is not obfuscated.

Restore all imports.

Next i see that resources are messed up.

I have almost no idea if resource rebuilding but i will search.

I saw also that the process have a TLS callback.

[xSRTsect]

But can you actually debugg that thing ? I have even thought about reducing the size of section #2 but then I thought that the use of memory could be fragmented - thats what I would do.

[GIV]

After some minutes my Olly responds and run the thing.

You can see the near OEP call in the stack.

[xSRTsect]

Anyway - if you are running into trouble dumping the actual file theres a trick you can do, it worked with me, that is you can patch (on the fly patch - otherwise you will be caught by PEP crc check for anti corrupted file) all sections to read/write so that when ollydump tries to dump the file it won't tell you it can't access the memory. But there seem to be some imports coming from the dll, at first I thought these were emulations from standard system api calls but they seem to be chunks of actual code in the dll, so I have no clue.

Edited October 10, 2014 by xSRTsect

[SmilingWolf]

MUPed and sections' VirtualSize reduced to the bare minimum for great (debugging) justice!

Tested on Win7 x64 (real) and Win XP SP3 (VBox).

UnpackME_MUPed.7z

[xSRTsect]

but how do you guys deal with the imports that are called from the dll?

[GIV]

With some help by SimilingWolf witch en light me on resources here is my dump.

 

UnpackME_dump_SCY_res.7z

[EvOlUtIoN]

Here is my unpacked. https://www.sendspace.com/file/xmf73c

Should be like original except for the rsrc section which is not rebased.

Edited October 16, 2014 by EvOlUtIoN

[kalach]

thanks

https://www.sendspace.com/file/xmf73c

[xSRTsect]

hooo sorry kalach, I thought you were submitting a new solution :/

Edited October 18, 2014 by xSRTsect

[GIV]

About CRC.

It depends on what method of unpack is used, what imports fixing tool is used etc. Even if a byte is changed regarding another file the CRC is different.

Edited October 19, 2014 by GIV