Still need help with Asprotect - Page 6

#76 03-22-2004, 02:29

Quote:

Originally Posted by britedream

my address is slightly different due to my pc setup, but codes look right , so change 55 "push ebp", to c3 " retn"

I am sorry, but I disagree with this advice. It seems to me that if you do this, you will corrupt the stack, as the POP EBX, POP ECX, and (most importantly) POP EBP at the end of the procedure will not be executed.

My suggestion here is to NOP two instructions:

The PUSH at 410419
The POP at 41041E

@Pompeyfan: As to understanding what this procedure is doing (this is just as important, if not more important, than merely fixing it), I describe this in my TweakRAM mini-tut. I also describe exactly how to fix this procedure in the mini-tut, which you claim to have read... So have you read it or not??

Regards,
Satyric0n

britedream · #77 03-22-2004, 02:33

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 · #78 03-22-2004, 02:37

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

#79 03-22-2004, 02:38

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

#80 03-22-2004, 02:43

Quote:

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

britedream · #81 03-22-2004, 02:49

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.

#82 03-22-2004, 02:55

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.

britedream · #83 03-22-2004, 03:01

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.

#84 03-22-2004, 03:03

Quote:

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?

#85 03-22-2004, 03:13

Quote:

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 · #86 03-22-2004, 03:55

this is the snippet:

Quote:

Originally Posted by Wurstgote

please forgive my memory, this was your solution.

Quote:

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 · #87 03-22-2004, 04:18

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.

#88 03-22-2004, 04:53

Yes, I did try running in & out of Olly, I'll email you my dumped file to check, thanks for that, very good of you.

#89 03-22-2004, 05:01

Hi, you can access it at hxxp://members.optusnet.com.au/~vincewmb/Aussiepompeyfan/RegDefrag.rar, I see I cant email you, so I uploaded it to my website.

#90 03-22-2004, 05:10

Quote:

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

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
The new asprotect 1.31	britedream	General Discussion	48	06-03-2004 17:12
Anyone can help me with this one?? ASProtect	loman	General Discussion	0	12-31-2003 16:37