Tried unpacking DVDIdle Pro - AsProtect
 

I'm pretty new to cracking on Intel machines...

I went thru Tag & Rename tutorial and everything worked perfectly.

However, I tried to apply the same concept with DVDIdle Pro.

Running Ollydbg, I loaded in DVDIdle Pro 3.38 and answered NO to analyzing.
Hit F9 and received an exception.
Pressed SHITF+F9 - 26 times until I reached the following:

see pic: dvdi_olly2.jpg

I set a bp at the RETN

Pressed SHIFT+F9 one more time.

Pressed ALT+M and right clicked DVDIdle code -> Break on memory access.
Hit CTRL+F11 to run a trace

I ended up here (see pic): dvdi_olly1.jpg

From here nothing looked the same...nothing was on the stack.

I tried VIEW->TRACE, HIGHLIGHT EPB (show ESP enabled with log command on)

This is what I saw (missing bytes?) see pic: dvdi_olly.jpg

If these are the missing bytes...where do I put them? There are quite a bit of "00" above the address shown in pic: dvdi_olly1.jpg

Any help would be appreciated...

-Malt

Great Job
 

Hi Maltese,

Well first i want to congratz you with your first post which is way above the first post of other members on this forum ;)

you have indeed found the right stolen bytes which you showed in dvdi_olly.jpg. Again you are right you have to put the stolen bytes on the zero's in picture dvdi_olly1.jpg. I took a quick look at the 3.39 version and that have 45 stolen bytes. I assume that the 3.38 version regarding your trace will have 38 stolen bytes (you'll have to count the zero bytes)

PUSH EBP
MOV EBP,ESP
PUSH -1
PUSH 425FA0
PUSH 41EF10
MOV EAX,DWORD PTR FS:[0]
PUSH EAX
MOV DWORD PTR FS:[0],ESP
SUB ESP,58
PUSH EBX
PUSH ESI
PUSH EDI
MOV DWORD PTR SS:[EBP-18],ESP

Regards, Lownoise

Thank you lownoise for the kind response.

I installed version 3.39 DVDIdle Pro and followed the same steps as the original post.

When I performed View-Trace (SHOW ESP & LOG COMMAND)

This is what I saw (see pic): dvdi_olly3.jpg

Unfortunately the AsProtect tutorial does not go indepth as to how many bytes and which exact ones are the stolen ones.

***EDITED*** removed reference to picture #4 since it was incorrect...to not hog up space on server


If this was a mistake, how do I make sense of what is stolen and what is not?

Thanks,

-Malt

Hi,
Did u read britedreams tutorial on stolen bytes. One of them is here.
http://www.exetools.com/forum/showthread.php?t=3654&page=1

Very nice tuts :)

Regards,

Thanks,

I dl'd the tut by Britedream. Please let me try to figure this one out first. If I need help I hope I can ask. But I need to learn this...just giving the answer won't help me in the future...

Looking at the tut now.

Thanks again!

-Malt

Alright,

I looked through the Tutorial from BriteDream regarding ASProtect and understanding stolen bytes and trying to apply it to DVDIdle Pro 3.39

I noticed right off the bat that 3.38 is different than 3.39. PEiD .7b reports the same protection for both versions.

After the CTRL+11 trace in Ollydbg, I can see that I need to fill 45 bytes (above the bp from trace). Confirmed by lownoise.

In my post above is a picture of VIEW->RUN TRACE (dvdi_olly3.jpg).

Everytime I see stolen bytes (in RUN TRACE) tutorials, it seems that PUSH EBX is first. In this case it does not appear to be PUSH EBX, but MOV EBP,ESP

I tried to continue figuring the rest of the code to fill 45 bytes exactly, I ended up with 1 byte left at 00 which needs filled.

I did this starting at location: 41EFE6

0041EFE6 8BEC MOV EBP,ESP
0041EFE8 6A FF PUSH -1
0041EFEA 68 A05F4200 PUSH DVDIdleP.00425FA0
0041EFEF 68 40EF4100 PUSH DVDIdleP.0041EF40
0041EFF4 2BE2 SUB ESP,EDX
0041EFF6 890424 MOV DWORD PTR SS:[ESP],EAX
0041EFF9 64:8925 00000000 MOV DWORD PTR FS:[0],ESP
0041F000 83EC 68 SUB ESP,68
0041F003 2BE2 SUB ESP,EDX
0041F005 891C24 MOV DWORD PTR SS:[ESP],EBX
0041F008 2BE2 SUB ESP,EDX
0041F00A 893424 MOV DWORD PTR SS:[ESP],ESI
0041F00D 2BE2 SUB ESP,EDX
0041F00F 893C24 MOV DWORD PTR SS:[ESP],EDI
0041F012 00 <===


Basically I started with MOV EBP,ESP
ommited JMP, LEA, ADD, XOR

How do you determine where the stolen bytes end?

Any ideas lownoise? I wanted to try this on my own before the answer was provided.

Thanks for taking the time to help me!

-Malt

Britedream,

So it should always start with push EBP?

Also if I have 45 bytes with 00, which represents where the stolen bytes go, they should all be filled correct?

for all the startup code that has mov ebp,esp , yes; your hint to the start of the stolen is the first encounter of ebp== esp, which is the second byte of your stolen, so push ebp should be the first.

now for the end of your stolen,please read all my three tut, regarding this. you should pay attention to the address pushed to the stack ,which either be a return address or address that you are at, from which you can determine the last of your stolen.(please look lownoise post, it has the correct stolen bytes).

note:
what you see in the trace is the excution of your stolen bytes, and sometimes part of the code after the stolen , inside the asprotect, so don't copy all you see in the trace as stolen. learn from my three tut how you determine that.

for the location of your oep and the place of your stolen, look at the k option on toolbar, double click on the last address you see there, if there is no address, then the place for oep and stolen is right above where you are, provided there is no anyalsis has been done,if anyalsis is done then remove anyalsis by right clicking on the cpu pane and selecting anyalsis->remove anyalsis; option.

Britedream,

Thank you for your patience and assistance. I appreciate it very much! :)

Ok, part of this is my fault... since I am new to assembly on IA32.

Looking at the beginning of unpacked programs I see a pattern of how a program is executed [normally]

This is what I learned:

PUSH EBP
MOV EBP,ESP
PUSH -1
PUSH some value
PUSH some value
MOVE EAX, DWORD PTR FS:[0]
PUSH EAX
MOV DWORD PTR FS:[0],ESP
SUB ESP,58
PUSH EBX
PUSH ESI
PUSH EDI
MOV DWORD PTR SS:[EBP-18],ESP
CALL ..... Kernal32.Get.Version

I have confimed that since version DVDIdle Pro 3.22 and up, there are 45 bytes of "00" (where stolen bytes go). Do these need to be filled completely (ALL 45)?

Looking in the STACK window (K), there is nothing in the stack window... so the bytes go above the address where the CTRL+F11 trace stops.

I looked at Raider's tutorial regarding Tag & Rename 3.06, and your tutorial Britedream: concepts by britedream. If I read you correctly you have 3 tutorials? I found one with the help of Ferrari's post (Thanks).

Following your one tutorial that I have "concepts", it is a bit difficult to follow because I'm trying to implement them with an unknown (dvdidle pro).

So trying to combine what I saw in dvdi_olly3.jpg in my earlier post:

I should have something like:

PUSH EBP
MOV EBP,ESP
PUSH -1
PUSH 425FA0
PUSH 41EF40
MOVE EAX, DWORD PTR FS:[0]
PUSH EAX
SUB ESP,EDX
MOV DWORD PTR SS:[ESP],EAX
MOV DWORD PTR FS:[0],ESP
SUB ESP,68
PUSH EBX
PUSH ESI
PUSH EDI
MOV DWORD PTR SS:[EBP-18],ESP
-----------------------------------
CALL ..... Kernal32.Get.Version

This is not correct....but I'm trying my best to get it together.

P.S. I say NO to analyzing with Olly with AsProtect programs as per Raider's Tutorial with Tag & Rename...

I will download the target and look at it.

Explanation of the stolen bytes
 

Malt,

Hope this info helps you and makes sense


When you start working on recovering stolen bytes you've to know some assembly and a basic knowlegde how the startup code from some compilers looks like
Asprotect tries to hide the stolenbytes with the use of some garbage code and emulating stolenbytes
If you know which compiler is used it will make your recovering of the stolen bytes much more easy, also knowing how many stolenbytes to recover will help you
I don't know fore sure but it looks like asprotect has some "templates" for the compilers thas are most used (delphi, visual c++, etc..)
For your app the compiler is ms visual c++ 6.0 . asprotect "hides" the stolenbytes for a c++ 6.0 app with garbarge code and emulating the stolenbytes.
Remember that for each app garbage code and stolenbytes are different!!!

Ok lets look to your trace log

00986A2A Main MOV DWORD PTR SS:[ESP],EBP
00986A2E Main MOV EBP,ESP ; EBP=0012FFC0
00986A30 Main PUSH -1 ; ESP=0012FFBC
00986A32 Main PUSH 425FA0 ; ESP=0012FFB8
00986A37 Main PUSH 41EF40 ; ESP=0012FFB4
00986A3C Main MOV EAX,DWORD PTR FS:[0] ; EAX=0098548C
00986A42 Main JMP SHORT 00986A45
00986A45 Main LEA ESP,DWORD PTR SS:[ESP-15] ; ESP=0012FF9F
00986A49 Main ADD WORD PTR DS:[986A52],0E57B ; FL=CP
00986A52 Main JMP SHORT 00986A56
00986A56 Main LEA ESP,DWORD PTR SS:[ESP+EDX+11] ; ESP=801102B4
00986A5A Main SUB ESP,EDX ; FL=O, ESP=0012FFB0
00986A5C Main XOR WORD PTR DS:[986A66],0A641 ; FL=P
00986A65 Main JMP SHORT 00986A6A
00986A6A Main MOV DWORD PTR SS:[ESP],EAX
00986A6E Main MOV DWORD PTR FS:[0],ESP
00986A75 Main SUB ESP,68 ; FL=PA, ESP=0012FF48
00986A78 Main JMP SHORT 00986A7B
00986A7B Main LEA ESP,DWORD PTR SS:[ESP-15] ; ESP=0012FF33
00986A7F Main ADD WORD PTR DS:[986A88],0E57B ; FL=CP
00986A88 Main JMP SHORT 00986A8C
00986A8C Main LEA ESP,DWORD PTR SS:[ESP+EDX+11] ; ESP=80110248
00986A90 Main SUB ESP,EDX ; FL=PO, ESP=0012FF44
00986A92 Main XOR WORD PTR DS:[986A9C],0A641 ; FL=P
00986A9B Main JMP SHORT 00986AA0
00986AA0 Main MOV DWORD PTR SS:[ESP],EBX
00986AA4 Main JMP SHORT 00986AA7
00986AA7 Main LEA ESP,DWORD PTR SS:[ESP-15] ; ESP=0012FF2F
00986AAB Main ADD WORD PTR DS:[986AB4],0E57B ; FL=CP
00986AB4 Main JMP SHORT 00986AB8
00986AB8 Main LEA ESP,DWORD PTR SS:[ESP+EDX+11] ; ESP=80110244
00986ABC Main SUB ESP,EDX ; FL=O, ESP=0012FF40
00986ABE Main XOR WORD PTR DS:[986AC8],0A641 ; FL=P
00986AC7 Main JMP SHORT 00986ACC
00986ACC Main MOV DWORD PTR SS:[ESP],ESI
00986AD0 Main JMP SHORT 00986AD3
00986AD3 Main LEA ESP,DWORD PTR SS:[ESP-15] ; ESP=0012FF2B
00986AD7 Main ADD WORD PTR DS:[986AE0],0E57B ; FL=CP
00986AE0 Main JMP SHORT 00986AE4
00986AE4 Main LEA ESP,DWORD PTR SS:[ESP+EDX+11] ; ESP=80110240
00986AE8 Main SUB ESP,EDX ; FL=PAO, ESP=0012FF3C
00986AEA Main XOR WORD PTR DS:[986AF4],0A641 ; FL=P
00986AF3 Main JMP SHORT 00986AF8
00986AF8 Main MOV DWORD PTR SS:[ESP],EDI
00986AFC Main MOV DWORD PTR SS:[EBP-18],ESP
00986AFF Main XOR EBX,EBX ; FL=PZ, EBX=00000000
00986B01 Main MOV DWORD PTR SS:[EBP-4],EBX
00986B04 Main PUSH 2 ; ESP=0012FF38

[Garbage Code]

When you found the ebp==esp look down in your trace log for paterns of instructions
In you trace log we see a patern like

LEA ESP,
ADD WORD PTR DS:
JMP
LEA ESP
Sub ESP,EDX
XOR Word PTR
JMP

If we Remove the Patern of your trace we have the following instructions remaining

00986A2A Main MOV DWORD PTR SS:[ESP],EBP
00986A2E Main MOV EBP,ESP ; EBP=0012FFC0 ==This is the hint for the stolen bytes ebp=esp
00986A30 Main PUSH -1 ; ESP=0012FFBC
00986A32 Main PUSH 425FA0 ; ESP=0012FFB8
00986A37 Main PUSH 41EF40 ; ESP=0012FFB4
00986A3C Main MOV EAX,DWORD PTR FS:[0] ; EAX=0098548C
00986A42 Main JMP SHORT 00986A45
00986A6A Main MOV DWORD PTR SS:[ESP],EAX
00986A6E Main MOV DWORD PTR FS:[0],ESP
00986A75 Main SUB ESP,68 ; FL=PA, ESP=0012FF48
00986A78 Main JMP SHORT 00986A7B
00986AA0 Main MOV DWORD PTR SS:[ESP],EBX
00986AA4 Main JMP SHORT 00986AA7
00986ACC Main MOV DWORD PTR SS:[ESP],ESI
00986AD0 Main JMP SHORT 00986AD3
00986AF8 Main MOV DWORD PTR SS:[ESP],EDI
00986AFC Main MOV DWORD PTR SS:[EBP-18],ESP
00986AFF Main XOR EBX,EBX ; FL=PZ, EBX=00000000
00986B01 Main MOV DWORD PTR SS:[EBP-4],EBX
00986B04 Main PUSH 2 ; ESP=0012FF38


[Emulating Stolen Bytes]

Remember that Asprotect emulates instructions look at the first line

00986A2A Main MOV DWORD PTR SS:[ESP],EBP

If you know some assembly you know that ths instructions is the same as a Push Ebp

Knowing this and applying this to the trace log and removing the JMP instructions and comments our trace looks like this


00986A2A Main Push EBP
00986A2E Main MOV EBP,ESP
00986A30 Main PUSH -1
00986A32 Main PUSH 425FA0
00986A37 Main PUSH 41EF40
00986A3C Main MOV EAX,DWORD PTR FS:[0]
00986A6A Main Push EAX
00986A6E Main MOV DWORD PTR FS:[0],ESP
00986A75 Main SUB ESP,68
00986AA0 Main Push EBX
00986ACC Main Push ESI
00986AF8 Main Push EDI
00986AFC Main MOV DWORD PTR SS:[EBP-18],ESP
00986AFF Main XOR EBX,EBX
00986B01 Main MOV DWORD PTR SS:[EBP-4],EBX
00986B04 Main PUSH 2

And that are your stolenbytes

Hope this make sense for you

Regards Lownoise

0041EFE6 55 PUSH EBP
0041EFE7 8BEC MOV EBP,ESP
0041EFE9 6A FF PUSH -1
0041EFEB 68 A05F4200 PUSH DVDIdleP.00425FA0
0041EFF0 68 40EF4100 PUSH DVDIdleP.0041EF40 ; JMP to MSVCRT._except_handler3
0041EFF5 64:A1 00000000 MOV EAX,DWORD PTR FS:[0]
0041EFFB 50 PUSH EAX
0041EFFC 64:8925 0000000>MOV DWORD PTR FS:[0],ESP
0041F003 83EC 68 SUB ESP,68
0041F006 53 PUSH EBX
0041F007 56 PUSH ESI
0041F008 57 PUSH EDI
0041F009 8965 E8 MOV DWORD PTR SS:[EBP-18],ESP
0041F00C 33DB XOR EBX,EBX
0041F00E 895D FC MOV DWORD PTR SS:[EBP-4],EBX
0041F011 6A 02 PUSH 2

this is the correct stolen.

for the stack everything follow my tut. except 12ffbc == 00000000 instead of ffffffff, but if you folllow the code ,it was there but just over written by:
mov dword ptr ss:[ebp-4],ebx; the ebp== 12ffc0 if you substract 4 from it, you will end up at 12ffbc, where ebx with value of 0 moved to it.

learn to use the stack with the trace, not the trace alone.

sorry I relied on lownoise first finding and it was wrong.

Hmm, lots of imports the aspr2 plugin can't handle on this one...

Thank You both Lownoise & Britedream.

So now I understand why the PEiD shows compiler. I must see how a normal program compiled with that particular brand compiler has it's startup code. Got it.

Since there is nothing in the "K" (STACK) window, I do not need a JMP I just fill in the 45 blank "00" bytes with the stolen bytes. Got it.

I apologize...when I learned to crack on the Apple ][e (Don't laugh... I know you are :) ) *Hey my Algebra teacher got me started. A Push was a push. After looking at another tutorial I saw that MOV DWORD PTR SS:[ESP+number],EBP is the same as PUSH EBP. This is my failure. Now I know.

Thank you everyone for your patience... and willingness to help.

I am using Imprec now. I tried setting size to 1000 and only found 2 instances where dissasemble/hex said no data. I have to go to work... I look at it with Imprec later today after work.

I'll share with you what I find out.

Thanks again everyone!

-Malt

To svensk

the target runs on this iat:
there are only two exceptions, if you fix the first one you are registered, the second is to correct the stack.(I haven't test the program but it runs fine).

Ok, I'll check it out and thanks for the nice scripts for OllyScript btw. Saves alot of time :)

my pleasure!,

Some time it is usefull to use my script "asprsto", it will stop where we should be looking in the stack, that is 12ffc4:77e814c7(for this program), F9 few times till you are at mov ebp,esp; then follow the execution of your stolen with F8.

Nice stuff, I followed the stolen bytes during execution with your method.
Still having problems with my dumped exe though. After the trace I end up at:

0041F013 FF15 68274200 CALL DWORD PTR DS:[422768] ; MSVCRT.__set_app_type

I insert the stolen bytes and change the origin to PUSH EBP at 41EFE6 and then dump the exe with OllyDump, unchecking Rebuild Import. I load your tree in ImpRec and press Fix Dump. I load the exe in LordPE and change OEP to 1EFE6. Problem is the exe still wont run. :(

It crashes at: 0041F115 |. E8 F6020000 CALL dumpLord.0041F410

I don't remeber what the addresses for the two exceptios are, but if u run xp I will be glad to send you the running target.

Yes, please do that. Maybe I can compare the two and figure it out.

please pm with your email

target has been sent, please check your e-mail. thanks

BriteDream,

I have the same problem as Svensk (I'm running Xp Pro).

I thought to use Imprec (using Raider's tutorial on Tag&Rename 3.06), to increase the IAT SIZE to 1000? Imprec v1.6f defaults to 918 when I load my patched DVDIdlePro 3.39 (stolen bytes entered and new oep set). Then I've dumped using OllyDump and unchecking: Rebuild Import.

If I load your tree file, then select fix dump, the exe is not executable. It comes up with an exception.

I know that with Tag & rename there was one section you ran across that had ??? and you had to NOP it.

How is it that you got yours to execute and we can't get ours? Is there more patching required?

-Malt

maltese,
don't load my iat, fix yours according to mine.

please pm with your email.

BriteDream....

Does this make sense?

removed DvdIdlePro.udd and DvdIdlePro.bak (cache if you will for Olly)

1) I loaded Olly 1.10beta
2) Answered NO to analyze
3) F9, SHIFT+F9 26 times
4) ALT M
5) Left Click - code line for DvdIdle Pro
6) CTRL + F11
7) VIEW->TRACE
8) Enter Stolen Bytes
9) @ PUSH EBX (start of Stolen Bytes), I set NEW ORIGIN
10) OllyDump: uncheck Rebuild Import (saved as dump.exe)

* Left Ollydbg running after dumping to dump.exe

11) Loaded Imprec v1.6f
12) Selected DVDIdle Pro as Active Process
13) Pressed IAT Auto Search
14) Pressed Get Imports (left all values at default)
15) Pressed Show Invalid
16) Right clicked on invalid and selected: Trace Level 1 (disasm)
17) Pressed Show Invalid again
18) Right clicked on invalid and selected: Plugin Tracers-> aspr2

* It said no more pointers...see if it works

19) Clicked fix dump.... and patched the dump.exe file from Olly.

Program does not work...

Maybe my options are incorrect on Imprec???

Above the Fix Dump button I have checked: add new section (default)
In options: The only thing checked is: Process Properties (enable debug privilege XP) & Use PE Header From Disk

Did I not do something right? I noticed that Raider had a byte that was invalid in his beginning execution code so he NOP'd it. This exception appears to be happening during a Windows call.

-Malt

please read my three tutorials about stolen, then use my script "asproep" to find out the place for oep and stolen, then fix your stolen and dump from the oep.

RVA for your iat=22000 size= 918

once you get to rebuilding your iat please, let me know I will help you on that, but first get the correct stolen and the correct dump.

if there is anything you didn't understand in my tuts, please pm me.

BriteDream,

Where can I dl your 3 tutorials? I am looking forward to reading them!

Thanks

-Malt

please check your email

TO Svensk


"[insert the stolen bytes and change the origin to PUSH EBP at 41EFE6 and then dump the exe with OllyDump, unchecking Rebuild Import. I load your tree in ImpRec and press Fix Dump. I load the exe in LordPE and change OEP to 1EFE6. Problem is the exe still wont run. :(

It crashes at: 0041F115 |. E8 F6020000 CALL dumpLord.0041F410]"


Please Note:
1- if you have changed origin to push ebp, there is no need to use lordpe.
2- please don't load my iat, fix yours according to mine.

Arrrgghh....

Britedream, thank you for the tutorials and I can confirm your version is working... at least the greet screen comes up.

Mine always has an exception error. Looking at your tree file your size is 918..mine turns out to be 91C

either way no luck.

I confirmed the bytes you entered as stolen are entered in right where the trace dumps at. (just above 45 bytes).

I noticed that Olly reports at least one different register upon initial load (no stepping) between our versions. The first time I compared the ESI turned out to be different.

In you tutorial you mention the stolen bytes.... thanks to you and lownoise we have that. I am starting to think that I am doing something wrong with Imprec. When I compared our startup code..it looked dead on.

Are there any different settings on Olly or Imprec that you think would make a difference?

Is it the way I am dumping it with ollydump? I used your script of asprbp. to help eliminate any possible errors by me.

Here is a pic of the stolen bytes entered.... the EIP (which is now the origin) and the dump window as I prepare to dump the DVDidle Code.

-Malt

Well for me it's a little bit early, and it seems i'm missing the link in the thread that the app crashes.
I dumped the app the same way as Malt.
The iat has been fixed with asprdbg from manko. It's a little tool which dumps asprotect targets from previous versions. When the asprdbg paused after he cleans the iat open imprec enther the values given by asprdbg en press fix dump.
After that open your dumped exe in olly and fix the check in dvdidle pro for the present of asprotect.
my quick and dirty fix is online 4043AA Mov eax, dword ptr ds:[eax] if you change this to xor eax,eax your app will run fine.

lownoise

To maltese:

default options for importrec work fine. now when you select the first line of your stolen , you should right click on it and choose origin here then dump.

Thanks lownoice, that actually made my program load.

Is "Import all by Ordinal", "Rebuild Original FT" and "Create New IAT" supposed to be checked in ImpRec's Options?

Fell free to take a screen shot of your settings, so we all know how it "should" look :)

To lonoise:

Yes this is the first error I mentioned, if you fix the address to points to an address where you coded your name then this will show that it is registered to you.

To svensk and maltese,

please discard the dump file I sent you , olly didn't write the patch as it should you will notice that to goes to an empty space.

some strange things happen with this program , I will check them and let you know.

To britedream: Yes, I noticed that. But still the program is registered in your name. Weird :)

And btw the code where you entered the PUSH, is executed after the splash screen is shown.
I'm talking about the code at 401779.

Britedream,

Looks like i'm still learning everyday.
app works registered now :)

lownoise

these are the errors area I had, if you fix them it will run:

1-
004043AE /74 0F JE SHORT dvd_.004043BF
004043B0 |50 PUSH EAX
004043B1 |E8 90AB0100 CALL <JMP.&msvcrt.strlen>
004043B6 |. |85C0 TEST EAX,EAX
004043B8 |. |59 POP ECX ; dvd_.0040352D
004043B9 |. |76 04 JBE SHORT dvd_.004043BF
004043BB |. |33C0 XOR EAX,EAX
004043BD |. |40 INC EAX
004043BE |. |C3 RETN
004043BF |> \33C0 XOR EAX,EAX
004043C1 \. C3 RETN

2-
00401770 . 8975 FC MOV DWORD PTR SS:[EBP-4],ESI ; dvd_.0042C0F0
00401773 . FF35 28214200 PUSH DWORD PTR DS:[<&kernel32.CreateThre>; kernel32.CreateThread
00401779 . B8 D8A44200 MOV EAX,dvd_.0042A4D8
0040177E . FFD0 CALL NEAR EAX
00401780 . EB 0F JMP SHORT dvd_.00401791

this is what I had and fixed.

now the strange thing I found , in fixed dump at the oep which working with no problem so far, I did check the iat to see if it is well, I found out that around four addresses has been over written, so I changed importrec option from create new iat, to rebuild original, that corrected the problem. so please check the iat made by asprotect unpacker I am curious to see.