Newbie question ASPR 1.23 RC4 (long!)

[britedream]

Originally posted by Wurstgote
It's me again

I'm sorry, but the first problem has to stay unfixed for some time. I've got no tool at hand (ehhh... except my hands and brain, and both are as fast as a dead cat) to relocate the resources in the .data section, so for the moment, I'll leave those resources where they are.
Nevertheless I've managed to make the "Options" menu available.
First I've tried to follow britedreams suggestions, but either his ideas were way beyond my head or Win XP behaves different than Win 2K.; so I had to do it on my own.
I've loaded the dumped app into Olly and let it run. As soon as I try to access the "Options" in the "Tools" menu, Olly pops up with an access violation at 57891e.
The code around looks like this:

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

So I've put a breakpoint on 578911 and single-stepped through the code. At 57891E, the code doesn't make any sense to me... Changing data in kernel32.dll wouldn't work, so I've changed
0057891E |. POP DWORD PTR DS:[EBX]
to
0057891E |. POP DWORD PTR DS:[EAX]
and everything's okay.
Next I'll have to code that small app I've mentioned, just to see if I can get rid of that problem at startup you've talked about

Regards
Wurstgote

this is what you posted:
00578911 |. MOV EAX,DWORD PTR DS:[40781E] ;<&kernel32.GetModuleHandleA>

so 40781e point to the kernel32 address which start with 77xxxxx , and not to 62a4c3 as you mentioned. please make a note of it.
regards.

Thanks again for your friendly help and sorry to bother you again, but I'm trying hard to get things straight

1 PUSH EBP
2 MOV EBP,ESP
3 PUSH ECX
4 PUSH EBX
5 MOV EAX,DWORD PTR DS:[40781E] ;<&kernel32.getModuleHandleA>
6 MOV EBX,DWORD PTR DS:[EAX]
7 PUSH DWORD PTR DS:[EBX]
8 MOV DWORD PTR SS:[EBP-4],EBX
9 POP DWORD PTR DS:[EBX]
10 MOV EAX,DWORD PTR SS:[EBP-4]
11 POP EBX
12 POP ECX
13 POP EBP
14 RETN

If I got it right, this subroutine accomplishes two tasks.
It's main purpose is to load EAX and ECX with the address of kernel32.GetMOduleHandleA. In case of the original app EAX doesn't get the real address of GetModuleHandle, but instead the wrapper provided by ASPR. This is done by lines 5, 6, 8 and 10. Line 8 overwrites ECX's stack value, so the POP in line 12 gives ECX the same value as EAX. The second purpose is to test if the app is still running with the ASPR code. This is done by lines 7 and 9. It's simply a test if the GetModuleHandle code is writable, which is true for the original app (since line 9 writes to ASPR code), but false for the dumped exe - therefor the access violation.
Is that correct so far?

I suppose laziness is what prompted me to solve this by NOPping those instructions (since that seems to fix the problem acceptably), instead of following through and finding out what I was supposed to do...

Here I'm in trouble again... What's wrong with this approach? Since it only erases the writing test and leaves everything else alone it should be quite ok... I suppose
Could you please elaborate on this?

Regards
Wurstgote

Haha.. Wow, okay, I think some of us got things confused somewhere along the thread here. I think britedream did first (no offence ), then I did, and it was only Wurstgote who had things straight the whole time .

After rereading the thread, and redumping the app, I believe britedream's misunderstanding came from the comment on the instruction at 578911: ;<&kernel32.GetModuleHandleA>

I think britedream thought that [40781E] pointed directly to kernel32.GetModuleHandleA, which is at 77E7AD86, and so his suggestion was to make the instruction MOV EAX, 62A43C so that EAX would contain the same value in the dumped exe as in the original packed exe (since in the original packed exe, [40781E] pointed to 62A43C).

But, britedream my friend, [40781E] does indeed still point to 62A43C. 62A43C used to be a thunk to ASPR's emulated GetModuleHandleA function. But, 62A43C is now (after rebuilding the imports) a thunk jumping to GetModuleHandleA, thus Olly's offending (though not erroneous, as "&" was referring to a jump to the address of (as & is used in C) GetModuleHandleA) comment. So as Worstgote said,

I've compared the value of [40781E] in the original file with that in the dumped one. Both are the same. So, basically, it should make no difference if I replace

00578911 MOV EAX,DWORD PTR DS:[40781E] ; [40781E] contains 62A43C

with

00578911 MOV EAX,62A43C

Worstgote, in this, you are absolutely correct!

As to my own confusion, I can only attribute it to tiredness and maybe too much alcohol . Meaning, I have no real excuse... What I had been alluding to in my post about my laziness was that if changing the value in EAX really had fixed things, it would have been a cleaner solution (in my opinion) than NOPping those two instructions.

That all having been said, I believe my solution to NOP the instructions at 578919 and 57891E is still the best solution to this particular problem.

Also, Worstgote, your analysis of the code looks to me to be 100% correct. But, you already knew it was.

So, have you managed to find a resource editor yet? Also, why not install Visual Studio? Or, why do you not already have it installed? Your understanding and general knowledge of these subjects so far made me think you were already a programmer?

Regards,
Satyric0n

[britedream]

my correction is valid and his assumtion is wrong,value in dump and orignal aren't the same. please, look at the code again: in your dump, the error
came from trying to write to the kernel at
mov dword ptr ss:[ebp-4],ebx. I thought from his post that error came from trying
to write to an area which wasn't there, but after rechecking the original, i found that the error even more serious. so forgive me but you are both wrong
when you assumed that the pointing code in the original and the dump are the same.

britedream, I'm afraid I don't understand what you're saying. In my dump the error comes from the instruction at 57891E: POP DWORD PTR DS:[EBX]

The flow of logic in my dump is as follows:

00578911 |. MOV EAX,DWORD PTR DS:[40781E] ; Moves 62A43C into EAX
00578917 |. MOV EBX,DWORD PTR DS:[EAX]    ; Moves 77E7AD86 (address of kernel32.GetModuleHandleA) into EBX; before dumping, this is instead the address of ASPR's emulation of GetModuleHandleA
00578919 |. PUSH DWORD PTR DS:[EBX]       ; Pushes 04247C83 onto the stack (CMP DWORD PTR SS:[ESP+4],0 is instruction at 77E7AD86)
0057891B |. MOV DWORD PTR SS:[EBP-4],EBX  ; Moves 77E7AD86 to [EBP-4], which will be the data that POPs into ECX
0057891E |. POP DWORD PTR DS:[EBX]        ; Tries to POP 04247C83 back to 77E7AD86; throws exception because data in kernel32 is not writable; does not throw an exception before unpacking, because ASPR's code is writable
00578920 |. MOV EAX,DWORD PTR SS:[EBP-4]  ; Moves 77E7AD86 to EAX

Because the instructions at 578919 and 57891E do not do anything functional, merely are ASRP checks to see if that kernel32 code is writable, my suggestion was just to NOP them out.

Maybe I just do not understand what you are suggesting to change the code to? Which instructions are you saying should be changed to fix this problem?

Regards,
Satyric0n

[britedream]

sorry for the wrong line but it is the line after that as you indicated creating the exception, but my point is that your assumtion of 62a4c3 willn't make any difference is wrong.

I'm sorry, but I still don't understand what you're getting at...

Assuming the following is the code before fixing this problem, what are you saying the code should be after fixing this problem??

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

[britedream]

this is part of what he posted, and all my
replies are relating to this one and what came after that relating to it.

I've compared the value of [40781E] in the original file with that in the dumped one. Both are the same. So, basically, it should make no difference if I replace

00578911 MOV EAX,DWORD PTR DS:[40781E] ; [40781E] contains 62A43C

with

00578911 MOV EAX,62A43C

Could you please explain what I'm getting wrong here?

Regards
Wurstgote

With that statement, I have to completely agree with Wurstgote. If the effect of the instruction at 578911 is to move the value 62A43C into EAX, what difference does it make whether it gets that value from [40781E] or from a DWORD constant? Meaning, EAX = 62A43C is always EAX = 62A43C, regardless of how 62A43C is obtained.

The instructions following 578911 certainly don't know the difference.. They only know that EAX has the value 62A43C, and that's all they care about.

Maybe this will solve some of the confusion: what is the value at [40781E] on your dump? Meaning, after executing the instruction MOV EAX,DWORD PTR DS:[40781E], what value does EAX hold on your dump?

[britedream]

well, if you like to know if it makes a difference
or not , choose the opton before correction and after applying the correction I mentioned.
regards.

I can tell you for sure that on my dump, it made no difference at all; I got the same exception at 57891E as I did when it was moving [40781E] to EAX. After all, since both the original code and your suggested change moves 62A43C to EAX, EBX gets the value 77E7AD86 either way, and so 57891E tries to POP/write to kernel32 either way.

Maybe you and I produced different dumps?? I don't know what else could cause your changing the instruction at 578911 to MOV EAX,62A43C to fix the access violation..?

Regards

[britedream]

how can that be?
but 62a4c4 doesn't have the value 77xxxxx,it has FF1c64 in the original and my dump.

Hmmm...

First off, 62A4C4? My copy has [40781E] pointing to 62A43C, not 62A4C4..

In my original, 62A43C points to 01261C64 (ASPR's emulated/wrapped GetModuleHandleA code).

And in my dump after using ImpRec to fix IAT, 62A43C points to kernel32.GetModuleHandleA (77E7AD86 on my computer).

You must be running a different build/version than Wurstgote and I? I am running v2.1.0.3.

If you are running v2.1.0.3 also, I will redownload and reinstall the latest version from SiComponents to make sure we have the same copy running.

[britedream]

sorry it is typing error it is 62a43c an pointing to FF1c64

Originally posted by britedream
sorry it is typing error it is 62a43c an pointing to FF1c64

Ok

Still, for me, 62A43C points to 01261C64 in the original exe and 77E7AD86 in my dumped exe.

What version of Resbldr2.exe do you have?