Still need help with Asprotect

[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.

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.

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.

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