Still need help with Asprotect

I still get the file corrupted message after the changes, here is the call stack from when I get the message now:

Call stack of main thread
Address Stack Procedure / arguments Called from Frame
0012EB0C 77D43C53 Includes 7FFE0304 user32.77D43C51 0012EB40
0012EB10 77D4B3F2 user32.WaitMessage user32.77D4B3ED 0012EB40
0012EB44 77D4D9A0 user32.77D4B265 user32.77D4D99B 0012EB40
0012EB6C 77D6AE8E user32.77D4D8EC user32.77D6AE89 0012EB68
0012EE24 77D6A911 ? user32.SoftModalMessageBox user32.77D6A90C 0012EDAC
0012EF6C 77D6AFD5 ? user32.77D6A7D7 user32.77D6AFD0 0012EEF4
0012EFC4 77D6B0BD user32.MessageBoxTimeoutW user32.77D6B0B8 0012EFC0
0012EFF8 77D6B04A ? user32.MessageBoxTimeoutA user32.77D6B045 0012EFF4
0012F018 77D6B02E ? user32.MessageBoxExA user32.77D6B029 0012F014
0012F01C 00000000 hOwner = NULL
0012F020 004109B4 Text = "File corrupted ! Please ru
0012F024 004109AC Title = "Warning"
0012F028 00001030 Style = MB_OK|MB_ICONEXCLAMATION|M
0012F02C 00000000 LanguageID = 0 (LANG_NEUTRAL)
0012F030 004109AA ? <JMP.&user32.MessageBoxA> RegDefra.004109A5
0012F034 00000000 hOwner = NULL
0012F038 004109B4 Text = "File corrupted ! Please ru
0012F03C 004109AC Title = "Warning"
0012F040 00001030 Style = MB_OK|MB_ICONEXCLAMATION|M
0012F044 00418A40 ? RegDefra.00410994 RegDefra.00418A3B

[britedream]

please do the changes as I noted, save them, run the program out side olly, if the program dosn't run , then you may have a problem with your dump.

[britedream]

To satyricon:
I have the program running fine on the info I posted.

Originally Posted by britedream

To satyricon:
I have the program running fine on the info I posted.

britedream, I am quite sure you do. But, as per our previous discussion about this in this thread, you seem to be dumping your programs in a different way/place than the rest of us do, and so your solutions to these kinds of problems do not work for the rest of us (or for me, anyway).

I am only noting that your solution does not work for me (due apparently to the different way we seem to be dumping the app), and so I am posting the solution that does work for me.

Regards,
Satyric0n

OKay Satyric0n, when I make the changes you suggest, I not only get the file corrupted message, but it comes up several times after I press ok on it, I cant think what I might have done wrong in the dumping process though, I thought I had done that bit just fine, so I guess I am screwed.
I have read your tut, but I will re-read it, but my code looks vastly different to what TweakRAM did, as illustrated in my last post, this isn't just a case of changing 4 conditional jumps to jumps.

Please look at the comment at first line.

Yes, I understood that before, that is what I tried, thanks anyway, it must be something I did wrong in the dumping, does this look right to you:

00418E78 > $ 55 PUSH EBP
00418E79 . 8BEC MOV EBP,ESP
00418E7B . 83C4 F0 ADD ESP,-10
00418E7E . B8 808D4100 MOV EAX,RegDefra.00418D80
00418E83 . E8 58C5FEFF CALL RegDefra.004053E0
00418E88 . E8 BBFDFFFF CALL RegDefra.00418C48
00418E8D . E8 CEACFEFF CALL RegDefra.00403B60

If that does, what else could be wrong, I'm sure my import table looked the same as yours you posted earlier?

I have all these references to the call for this message box:

References in RegDefra: to 00410994
Address Disassembly Comment
00410994 PUSH 1030 (Initial CPU selection)
00412D68 CALL RegDefra.00410994
00413C3E CALL RegDefra.00410994
00414569 CALL RegDefra.00410994
00415DD1 CALL RegDefra.00410994
0041680B CALL RegDefra.00410994
00416AD1 CALL RegDefra.00410994
00416FD0 CALL RegDefra.00410994
004176B6 CALL RegDefra.00410994
004176EA CALL RegDefra.00410994
004181C3 CALL RegDefra.00410994
00418A3B CALL RegDefra.00410994
00418C70 CALL RegDefra.00410994
00418CA6 CALL RegDefra.00410994
00418CDC CALL RegDefra.00410994
00418D0F CALL RegDefra.00410994
00418D42 CALL RegDefra.00410994

And a lot of the code where the calls are made look like this, with unconditional jumps above the call, but the one just above the call usually calls up 00410094 anyway, I've traced them earlier in trying to figure it out.

00418A34 . EB 0F JMP SHORT RegDefra.00418A45
00418A36 .^E9 11ABFEFF JMP RegDefra.0040354C
00418A3B . E8 547FFFFF CALL RegDefra.00410994
00418A40 . E8 E7ACFEFF CALL RegDefra.0040372C

[britedream]

00410454 $ C3 RETN <-------- This the byte I did changed from 55 to c3.
00410455 . 8BEC MOV EBP,ESP
00410457 . 51 PUSH ECX
00410458 . 53 PUSH EBX
00410459 . 8B05 0E564000 MOV EAX,DWORD PTR DS:[40560E] ; <&kernel32.GetModuleHandleA>
0041045F . 8B18 MOV EBX,DWORD PTR DS:[EAX]
00410461 . FF33 PUSH DWORD PTR DS:[EBX]
00410463 . 895D FC MOV DWORD PTR SS:[EBP-4],EBX
00410466 . 8F03 POP DWORD PTR DS:[EBX] ; 0012FFB4
00410468 . 8B45 FC MOV EAX,DWORD PTR SS:[EBP-4]
0041046B . 5B POP EBX ; 0012FFB4
0041046C . 59 POP ECX ; 0012FFB4
0041046D . 5D POP EBP ; 0012FFB4
0041046E . C3 RETN

Please look at the comment at first line.

[britedream]

TO Satyricon:

this code snipet is exactly the same as the one you insisted on nopping the call to it, in our last disagreement, and there is no difference between nopping the call or
chaning the first byte to "retn" in this snipet.

Originally Posted by britedream

TO Satyricon:

this code snipet is exactly the same as the one you insisted on nopping the call to it, in our last disagreement, and there is no difference between nopping the call or
chaning the first byte to "retn" in this snipet.

I agree that there is no difference between those two things, but I don't think I have ever said to NOP the CALL to this procedure. My solution to this procedure has always been to NOP the PUSH and POP in the middle of the procedure. The procedure I was saying to NOP the CALL to in our previous discussion was the procedure that raised the 0EEDFADE exception.

Either way, I have only been saying what I do to get the dump working; if what I do is not relevant or is incorrect, or there is simply a better solution, then just ignore me.

Regards,
Satyric0n

[britedream]

this is the snippet:

Originally Posted by Wurstgote

It's me again



0057890C /$ PUSH EBP
0057890D |. MOV EBP,ESP
0057890F |. PUSH ECX
00578910 |. PUSH EBX
00578911 |. MOV EAX,DWORD PTR DS:[40781E] ;<&kernel32.GetModuleHandleA>
00578917 |. MOV EBX,DWORD PTR DS:[EAX]
00578919 |. PUSH DWORD PTR DS:[EBX]
0057891B |. MOV DWORD PTR SS:[EBP-4],EBX
0057891E |. POP DWORD PTR DS:[EBX]
00578920 |. MOV EAX,DWORD PTR SS:[EBP-4]
00578923 |. POP EBX
00578924 |. POP ECX
00578925 |. POP EBP
00578926 \. RETN

Regards
Wurstgote

please forgive my memory, this was your solution.

Originally Posted by Satyric0n

Hmm. This is not acceptable.. This would move whatever data was [EBX] to [EAX], overwriting whatever was there already (the value in EBX, at this point), which may be something critical (like an IAT entry). Standard procedure here is just to NOP the instructions at 578919 and 57891E.


I use Visual Studio, but a small app like ResHack or something should do the trick, too. That's a fairly small download, I think. Any resource editor should work; there are many out there, and most are free.

Regards,

Satyric0n

now by nopping the 578919 and 57891e, you rendered the snippet useless,
pop ebx,pop ecx, pop ebp, are restoring what is pushed at the beginning,eax is xored right after retun, so by changing push ebp, to return is equal in effect to your nopping.
and I see no differnce between what I did ,and your nopping.

regards.

[britedream]

popeyfan ,

did you do the test I told you, run target outside olly. the startup codes look ok
to me , but I don't have the same va so the value to move to eax, I will not be able to say if it is the right one or not. btw, are you runnig windows xp.
can you send me your dump I will check it for you.
regrads.

Originally Posted by britedream

pop ebx,pop ecx, pop ebp, are restoring what is pushed at the beginning,eax is xored right after retun, so by changing push ebp, to return is equal in effect to your nopping.
and I see no differnce between what I did ,and your nopping.

regards.

I admit that I never looked at the code CALLing 57890C in that example, so I was unaware that EAX was XORed immediately after the procedure returned. So, my assumption that the value in EAX was important was incorrect.

Also, upon rereading what you first posted here, when you said 'so change 55 "push ebp", to c3 " retn"', for some reason I thought you were referring to the instruction at 410419, not the one at 41040C. Hence my comments about corrupting the stack (which now turn out are entirely irrelevant)...

Sorry, my misunderstanding, my fault. Maybe I should slow down when reading next time, so I don't get confused so easily and throw off the whole thread.

Regards,
Satyric0n