Posted October 7, 201410 yr 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
October 8, 201410 yr Hi,Nice unpackme. Found IAT Redirection VA : 0F0172EF 75 07 jnz short 0F0172F8Mod 'jnz' to 'jmp' then you will get all real API Addr. And the next is rebuilding its resource structure.
October 8, 201410 yr 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?
October 8, 201410 yr 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, 201410 yr by Raham
October 8, 201410 yr 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, 201410 yr by xSRTsect
October 9, 201410 yr 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.
October 9, 201410 yr 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.
October 9, 201410 yr After some minutes my Olly responds and run the thing.You can see the near OEP call in the stack.
October 10, 201410 yr 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, 201410 yr by xSRTsect
October 11, 201410 yr 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
October 14, 201410 yr With some help by SimilingWolf witch en light me on resources here is my dump. UnpackME_dump_SCY_res.7z
October 16, 201410 yr Here is my unpacked. https://www.sendspace.com/file/xmf73cShould be like original except for the rsrc section which is not rebased. Edited October 16, 201410 yr by EvOlUtIoN
October 18, 201410 yr hooo sorry kalach, I thought you were submitting a new solution :/ Edited October 18, 201410 yr by xSRTsect
October 19, 201410 yr 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, 201410 yr by GIV
Create an account or sign in to comment