Exactly... Remember ASProtect's kernel32 emulation "protection"? This is one way it is used. ASPR's data is writable, so this wouldnt throw an exception if ASPR were still protecting the app. Kernel32, however, is not writable, so as soon as you remove it, lots of little exceptions like this pop up.

Again, standard procedure for ASPR, so once you know about it and what it's doing, it's easy to take care of.

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

[QUOTE]Originally posted by Wurstgote
[B]It's me again ;)

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

-----------------------------------

you should bp 578911 in the orignal and follow the [40781e] to find the correct value.

on your pc 578911 is the correct address for code that I changed in my earlier post.

@ SatyricOn:
Of course you're right... I don't know what I've thought when I did this change. Ok, it was late and I was tired;)
I see. And again: learned something new:)
Perhaps you're right, but till now I couldn't figure out how to use ResourceHacker for that kind of task. I'll try to google another resource editor. Perhaps I'll find an appropriate one!

@ britedream:
Your help is much appreciated, but I'm not sure if I understand you:
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

well , if they were the same you wouldn't have an error, but address 40781e is pointing to an asprotect address which is not there in the dump once you unacked asprotect, so this is why you are having the error,but the asprotect address which
is pointed to by 40781e in the original is
pointing to an address , this address is
what you need to put in eax.

And I see even I still have things to learn on this subject. Thank you britedream. :)

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

Regards,
Satyric0n

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?

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 :D.

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,
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... :rolleyes: 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

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:
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

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??

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?

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

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.

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?

I am runnig 2.1.0.0, I will download your version and see. (good thing you brought that up).

regards.

Hi,
I didn't think it would make any difference, nevertheless I went and downloaded version 2.1.0.3, I did unpack
it , and without checking in the original, I went to address 578911 and change it to
mov eax, 62a43c as I suggested to you
and it runs as sweet as it can be. so the problem is at your end , may be from your dump.
btw ,I always think giving the program what it needs is better than nopping.

the protection in this version rendered all
my script worthless , it has layers after layers of asprotect protection. it was very usfull discussion , it made me discover this type of protection., which I am going to edit all my scripts to deal with it.

Regards!

Thanks, britedream :)
I think you're right... your dump must somehow look different than SatyricOn's and mine. Could you please tell me where exactly you've dumped the app?

Regards
Wursgote

Wurstgote, please check your PM.

Regards

I dumped at the oep, I will be happy to send you my dump along with my iat, for you to compare where you went wrong.

Please do. :) I woud appreciate it very much.

Regards

just however interested should send me pm with his email or just post it.and I will send it.
regards.

I have PMed you with info to my FTP, to which you can upload your dump of the app, if you would please. :)

Regards,
Satyric0n

I have the un edit dump, and one where I
edit the expiretion check, to prevent it from expiring which one you prefer.

The unedited dump will be sufficient, just so I can see what changes you made related to the problem going into Options.

Thanks

I keep getting tcp error, but may be do to my slow dialup, I will be getting dsl today so I will try to send it to you , if it fails then I will upload to exetool ftp.

Also, make sure you have Passive Mode turned on in your FTP client.

britedream,

I tried your patch at 578911 and it does run "sweet as it can be" until you select the "Options" function. At that point, it jumps to exception code that exits the program. This section of code is strictly a check to see if ASPR is still there and is otherwise not needed. At 57890c, replace 55 with C3 and everything will run "sweet as it can be".

I am having a problem with the 2 ASPR'd dlls. Unpacking them is not critical to overall funtionality of Resbldr but I was trying just for exercise. I have them both unpacked and the iat fixed, but neither of them will load. I get an "initialization error code" that normally indicates a bad PE but I don't think so. There must be a ASPR check or a chksum check that I can't find. I've seen this on other ASPR'd dlls and can't find the problem. Do you know where this check is?

JackD

my dear JackD the patch at address 578911 is for option problem,and it works 100%. the progam doesn't need any fix other than this.
note: you are having the same problem as they are , this is why I am trying to upload my unpacked dump.

britedream,

I think I'm getting the same problem that Wurstgote and Satyric0n are. Maybe your ASPR expiration patch is making the difference. Does you ASPR expiration patch involve an exception routine? Does your unedited dump and your patched dump behave the same way when you patch 578911?

I know you are real busy, but have you had a chance to look at either of the dll's?

JackD

the patch for expiretion has nothing to do
with it, the program runs fine without the patch, just the one for option. I am just having hard time to upload it due to my slow dialup connection, could I sent it to u as mail, and you can send it to others.

To Wurstgot
I have sent you through aol the file, check
it with pied the protecter and oep, run it
and select option, go to 578911 and see my path, check string resources. and
let us hear from you.

britedream,

I PM'd you my email.

Satyric0n needs to PM me his FTP and I can upload.

JackD

I realy appreciate your help Jackd, put I aleady send it to Wurstgot , thanks anyway.

I've got the file.
So if anybody else is interested, please drop me a PM with your email address

Regards
Wurstgote