New Asprotect?

[hobgoblin]

I just found this one at the RCE forum. The poster asked for people to try to unpack it, so I figured I could post it here (without stepping on someones toes). Anybody capable of unpacking it?

yes i can... and i just did

93k -> 1MB

and i see whoever protected it did not use the EP redirection. wouldn't have mattered tho.

Please keep in mind that this will only work on my machine, or possibly only on the OS in which I unpacked it. As it contains the aspr envelope attached to the dump, I will not post it for possible security reasons, nor do I recommend anyone posting their own dump with the aspr envelope attached.

---edit---
oops, forgot to trim down the size of my aspr envelope had a bunch of 00's.
once trimmed is only 229k. i'm not uploading another jpg. just thought i'd clear that up.

[Computer_Angel]

this "unpackme" is protected with asprotect 1.31 beta, and the poster not using the option hide OEP (to make it unpack easier? ).
I've see nothing in your picture, just a lordpe screen.
With lordpe i can dump it too, but can't fix the IAT, any ideal ?

i'm not posting the file cuz it contains the aspr envelope, which could possible contain other info. but if you must know here is the unpacked oep:

00401000 > 6A 00 PUSH 0
00401002 E8 C1030000 CALL 004013C8
00401007 A3 C0314000 MOV DWORD PTR DS:[4031C0],EAX
0040100C 6A 00 PUSH 0
0040100E 68 2B104000 PUSH 0040102B
00401013 6A 00 PUSH 0
00401015 68 00304000 PUSH 00403000 ; ASCII "MainDialog"
0040101A FF35 C0314000 PUSH DWORD PTR DS:[4031C0]
00401020 E8 73030000 CALL 00401398
00401025 50 PUSH EAX
00401026 E8 97030000 CALL 004013C2 ; JMP to kernel32.ExitProcess
0040102B 55 PUSH EBP
0040102C 8BEC MOV EBP,ESP
0040102E 817D 0C 10010000 CMP DWORD PTR SS:[EBP+C],110
00401035 0F85 8E000000 JNZ 004010C9
0040103B FF75 08 PUSH DWORD PTR SS:[EBP+8]
0040103E 8F05 C4314000 POP DWORD PTR DS:[4031C4]
00401044 51 PUSH ECX
00401045 33C9 XOR ECX,ECX
00401047 51 PUSH ECX
00401048 8D81 28304000 LEA EAX,DWORD PTR DS:[ECX+403028]
0040104E 50 PUSH EAX
0040104F 6A 00 PUSH 0
00401051 68 43010000 PUSH 143
00401056 68 B80B0000 PUSH 0BB8
0040105B FF75 08 PUSH DWORD PTR SS:[EBP+8]
0040105E E8 4D030000 CALL 004013B0
00401063 59 POP ECX
00401064 83C1 05 ADD ECX,5
00401067 81F9 9B000000 CMP ECX,9B
0040106D ^ 75 D8 JNZ SHORT 00401047
0040106F 59 POP ECX
00401070 6A 00 PUSH 0
00401072 6A 00 PUSH 0
00401074 68 4E010000 PUSH 14E
00401079 68 B80B0000 PUSH 0BB8
0040107E FF75 08 PUSH DWORD PTR SS:[EBP+8]

I showed the lordpe screenshot to show it running and the size of the process.

[Computer_Angel]

hi,
unpack is easy, but do you try to fixed iat yet ?
This prog is small, and not contain many api, so you can solve it easily, but think when there's a lot of api, at that time, what can we do now

[hobgoblin]

Hi guys,
Why don't you guys in a few words explain how you unpacked it and fixed the iat?

regards,

Originally Posted by hobgoblin

Hi guys,
Why don't you guys in a few words explain how you unpacked it and fixed the iat?

regards,

To keep it as few words as possible, I'll simply explain the method by which you can unpack and run this version. If you're not familiar with aspr or the pe file format then the following will not help you.

Get to OEP as usual, break on many exceptions and jump over the last exception and RET which will eventually lead you to EP. Then you can dump, that's the easy part. Then what you must do is dump the ASPR envelope from memory and attach it to your dump. I have seen regular sized apps with big import tables and at the moment I have no way of fixing or creating and iat. Once you've attached your ASPR to your dump you need to fix the import table to point to the proper thunks.

That's the extreme basic way of doing it

There are things you can do to change the ASPR envelope's native address, etc. Plus lots of cleaner ways to rebuild your pe. But that right there is the basic idea.

Also note that this approach will only allow the dump to run on your machine or possibly only the same os. It's definitely not a cross-platform solution with a generic iat/import table. But it works nonetheless.

One other thing to mention. Since this version does not use the native iat to point to system apis or redirected apis it will be quite a task to create an iat and that, really, is the only stumbling block for a more 'pure' solution. The other things such as obfuscated redirected functions are quite a bit tougher with this version, but that can always be resolved by simply attaching the obfuscated code somewhere and redirecting the jump/call to it.

I hope that answers some questions

i cant get it to run in ollydebug... passed a lot of exceptions but after a
while and "illegal instruction" windows box pops up and my process is killed...

i then set olly options to ingore most exceptions and restarted... it loads nicely and i get the debugge detect msgbox... and then it crashes i cant even click ok ... isdebuggerpresent plug did not help

[hobgoblin]

Thank you for your input. It's a good starting point for further investigation.:-)

regards,

[britedream]

As I indicated in my earlier post that I would look for unpacking the beta through traditional way, the key to this is to correct the code calls and jumps to asprotect area, the good news is the I found the locations that will correct calls and jumps, the only problem is time, I need to test it and unpack it through this method.I did run a program that I protected with the correction in place and it ran fine , which means these corrections are good.I did test this also on the unpackmenow, and it corrected all calls and jumps that I could see, but due to lack of time I couldn't pursue any further, but I will do that on the weekend if time permit.

regards.

[Computer_Angel]

it detect debugger, but you can easily bypass it by using IsDebuggerPresent plugin.
I also use the get api call in Imprec, try to make valid range from 401000 to 401fff to get the emulate api. That's way i did, but the weak point is i must correct every emulate api ---> It's so bad because there're alot of them.

[hobgoblin]

Hi britedream,
I'm looking foreward to learn about your solution.

BTW, has anyone found a program protected by this new version?

[Darren]

why not find the part in the unpacker that cycles through all the imports and patches the calls in the app with addresses of the redirected api in the envolope section, make a little ollyscript to capture the true api address and use ollyscript to put in correct api address and then use imprec tool to search for call [xxxxxx] and rebuild u a import that directly patches the calls,
or capture the table out of memory aspr uses to create these redirected calls
and build your own tool to build imports section and fix the call [xxxxxx] to point to a new IAT

- Darren

Originally Posted by hobgoblin

BTW, has anyone found a program protected by this new version?

WhereIsIt 3.59

I also look forward to hearing more about true iat direction fixing from britedream. From my observation, it appears that there is never an 'original' call structure that is then overwritten. It only seems that there are some basic distance bytes that are then calc'd and overwritten to the direct calls/jumps to the aspr env. If you have found something else that's truly be amazing.

[Darren]

this is the internal import table i mean, aspr steps through this and decodes as it goes, patching the calls and jumps to the envolope. on my machine the address of the code that does this is 0xc1550a. its possible to hijack this code with a little ollyscript and avoid it pointing calls to envolope code but to the real api addresses in memory, also i suspect with a few tweaks to the script it should be possible to make the script create an IAT and all the patched jumps/calls will be pointing to this new IAT, then its a case of sniffing out any emulated api and fixing them up manually

- Darren