POW! Another one bites the dust.

This is the first time I see a VB6 app (VoptXP v7, http://***.vopt.com) protected with Asprotect. I thought it would be a challenge to try deprotecting it and immediately started unpacking. I found OEiP, dumped, fixed and rebuilt (OEP: 00007A54, IATRVA: 00001000, IATSize: 00000290). However, all finished in 3 minutes time. The invalid module (MSVBVM60.dll) had all its 163 functions properly seated in place after an Autotrace, leaving me nothing but pushing the fix dump button. No fun! Deprotected app runs as usual now, except complaining about an "unexpected error" which requires a little tracing, later.

The question is, how could this happen? Why didn't aspr played its usual API, DD tricks, etc., on this one? There was an aspacked asprotect.dll residing in the app's folder. However, the app runs well without it.

Did anyone have a similar experience?

Thanks.

hi , i think if you read your post again ....

...you will get the answer by ur self ...

msvbvm6.dll is NOT part of aspr repertoire like kernel32 or user32 so cannot redirect api calls ...and no D-D cos ThunkMain does everything so aspr can only 'pack' it ?

Spl/\j

OK.

So, it was a wrong choice for the author to resort to aspr. This app had a very good anti-SmartCheck trick in its previous versions, but not this time. Maybe aspr gives a sort confidence?

Yes, maybe the author should ask for a rebate and use UPX

Actually he could still use the nice registration scheme of aspr and 'block' out certain functions/features unless registered

Spl/\j