New Asprotect?

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

well, i managed to do it, but the solution doesn't seem to fit every situation so i'll not post any real specifics yet. just wanted everyone to know that it is possible. it took a lot of rebuilding. rebuilding an iat, fixing jumps/calls, etc.

i do have one question, maybe someone can help me out. is there an api that acts the opposite of GetModuleHandleA? in other words, an api that can be feed in a number that is the modules handle, like 77000000, and it will spit out the module name? just curious, cuz something like that could help somewhat.