Tried unpacking DVDIdle Pro - AsProtect

[MaRKuS-DJM]

Originally Posted by Kyrios

Is there any way to decrypt without having to register? IF there was a blacky serial, how can we do with it?

maybe you can use asload and let it run registered. You can debug it, set BP on CreateProcess and then debug the program while asload does his register-job and then dump the program fully registered & decrypted

[Kyrios]

maybe you can use asload and let it run registered

No, i wanna know how to do it by hand. Afterall, i've tried several ASPRed programs, but always fails. Pstrip, elcor, and articons for instance.

BR,
kyrios

[MaRKuS-DJM]

powerstrip uses some heavy checks... it's not so easy. i don't know where these checks are located

La La La La La La..... tracing into AsProtect code... watching it load, erase, load, erase code.... getting closer... will report when I get to the serial# code

-Malt

Hi!

Nah... Pstrip is not so very difficult... Look at the dips... there's a very useful clue! (Not THE solution, just a VERY important clue...)
And then you run it in olly and when it gives an exception (NOT the OEEDFEED) you examine that code, get to understand it and patch it.
This piece of code that throws the exception is quite common in aspr-targets...

/Manko

Originally Posted by MaRKuS-DJM

powerstrip uses some heavy checks... it's not so easy. i don't know where these checks are located

HEY!

I believe I found the solution... the problem is I'm tired and have to get up for work at 5am.

Right before the: XOR DWORD PTR DS:[EAX],EAX

is always: MOV DWORD PTR FS:[EAX],ESP

keeping this in mind I did this:

DEBUG->SET CONDITION
CHECK -> COMMAND IS ONE OF
and enter into the box: MOV DWORD PTR FS:[EAX],ESP
CLICK OK (to exit Set Condition Window)

To save on a lengthy trace at the very start I did a Hardware BP at address: 9741A1 ( MOV DWORD PTR FS:[EAX],ESP ).

I did a NOP on the XOR[EAX],EAX and then continued with CTRL+F11 (trace) till the next one... and the next....

Now I need to do this till I get to the SEH XOR[EAX],EAX @ address 974350 which should be the area before the Registry is read for the "Key".

I will confirm this tomorrow unless someone else out there does it first

Please let me know if this is correct/incorrect.

Just a reminder that on my system during this session my first SEH error address is at 9741A4, then 973AC1, then 973B09... there are too many to list... you get the idea.

Nite!

[upb]

btw, is there only one seh handler function that it uses or many ?
if there is only 1, you could just nop out the portion that clears the hardware breakpoints in the CONTEXT struct.

I "believe" that because AsProtect decrypts runs, clears stack, clears memory, decrypts over cleared memory, *repeat* that just NOPing the SEH Handler function won't work.

There are 27 Memory Access Violations all occuring in different places in memory. That would be to easy to just NOP one call for the SEH handler. I just can't imagine Alexey allowing something like that.

I will try my trace in a few hours when I finish work and report back.

-Malt