New Asprotect?

[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.

Originally Posted by bollygud

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.

GetModuleFileNameA ???

hehe, duh!

thanks. my brain is a little fried

Hi all,

On the last exception you will see anti softice sice too .
hmm still need time to find why the iat is not able to resolve using revirgin or imprec....

Regards

[Darren]

because an IAT isnt used, aspr engine patches calls/jumps in the user code directly

i managed to make a working dump and found OEP for whereisit? 3.60 ... but can't fix IAT ..has anyone been able to find a solution for this?