Hi Kayaker:
Can you give me some tips on how to get a clean dump before rebuild IT??? I always nop those asprotect hooks in proggy, but it seems to be useless, what's the reason?
Best Regards!

Hi,

It's kinda hard to give any definitive answer to your problem, partly because from your post I'm not sure exactly *what* your problem is The 1st step of course is dumping at the right OEP and making sure you've got the correct IAT start and length. There's been plenty of posts/tuts on this. Seems that every app uses a different weekly version of Asprotect as well, heh, so there's no tried and true method of finding the OEP dump location either.

I'm not giving anything away here by saying that there are usually some unresolved entries in the IAT after running Revirgin. Used to be there was only 1 or 2 and these were actually redirected GetProcAddress calls and you could just edit these entries yourself before generating the IT. Even then the program was likely to crash because of some other redirected non-API call that tried to access a value in Asprotect memory. Sometimes these could simply be replaced with GetVersion (nothing pushed, essentially acted as a RET), or nopped out, but sometimes you needed to be a bit more creative and actually return some address or other.

I've seen a few apps though that some unresolved entries were something other than GetProcAddress, or there's just some other reason for it crashing that Revirgin has no chance at solving. For these you need to trace each problem area yourself in the packed app and figure out what the code is *supposed* to be looking for/doing and determine how to fix this in the unpacked app. I've seen a couple where if you nop out the call to the registration nag it runs fine.

So really, assuming you've dumped at the right location and Revirgin behaved reasonably well, most of the problems can only be gleaned by getting your hands dirty in the packed file and carefully tracing the problem areas. Not sure what other advice I can give, hope this helps.

Regards,
Kayaker

Hi Kayaker
For most situation, I can find the right eop, and get a correct IAT,but the dumped file was still crashed, I think maybe I can Get a clean dump before Asprotect set it's flags or let Asprotect set flags first then run our dumped proggy(modify eop), so the key problem is to find the right eip of asprotect begin setting its flags. Have you some advice?
regards!

Hi,

I'm not sure that in most cases modifying the way Asprotect unpacks will result in a better dump, if this is what you mean. Sometimes you see it jump back into program code and move a flag or address into a location, or modify a bit of code, maybe just inserting a C3 RET. I've tried a few times to R FL Z a jump in Asprotect to avoid going back into program code, but all that happened was when the code was finally executed, instead of finding, say an Asprotect address in a certain memory location (which would cause a crash), it found instead FFFFFFFF, which caused a crash anyway.

One notable exception to this I've seen was discussed in the Chameleon Clock thread a while back, where there was quite a bit of stuff happening in a jump back into program code (code modified + registry calls). The solution there *was* to bypass this jump during Asprotect unpacking and redirect the OEP to call the initialization code later. I'm not sure if this was a deliberate implementation of Asprotect or just the way the program was set up and how it came out in the unpacking.

If Asprotect sets any flags or addresses that are within the Asprotect memory range, any program code accessing these memory addresses in the unpacked file is going to fail anyway. So modifying this kind of flag call during unpacking won't really make a difference. Damned if you do, damned if you don't kind of situation.

I haven't really touched Asprotect for a while, so I don't know if it's gotten any trickier. Maybe someone else has some better insights into this problem.

Kayaker