Hello all,

I am trying to unpack some prog (some url). Loading it in PEID gives me that it's packed with the following protector:

ASProtect 1.23 RC4 Registered -> Alexey Solodovnikov

I tried CASPR on it, but to no avail. Then I decided to dump it manually, loaded it in OllyDBG and pressed F9, only to get a messagebox telling me that it cannot run when a debugger is present.
Now, I don't know much about ASProtect, but last time I unpacked something ASProtected, it did NOT have debugger protection.
This leads me to think that there's more to it than only ASProtect, only I can't quite figure out what or how to get rid of it.

Any help is appreciated,
- Fahr

Well Shit...........

2 IN 2 DAYS

I don't believe it yet another link to software

Fahr read the FAQS as Woodman says THE BIG RED LETTERS before you post anything

/hobferret

My bad indeed, I thought it would be rewritten to hxxp://, since I've seen that in some other posts and it seems to be ok...

Anyways, I edited it. Hope it's ok now.

- Fahr

OK Fahr

I ain't admin but now you have gotten rid of the link e.t.c. Do a search on the board for either ASPR or Olly and all will become clear

I will just give you one tip and that is set a breakpoint on IsDebuggerPresent and when you stop F7 3lines down and look at address where 01 is stored, press spacebar and change it to 00. That will rid you of your problem

If you need more help make sure you post what you have done so far, else you will be flamed as a lamer

There are hundreds of posts regarding ASPR here so in reality you should be able to figure out what is going on!!!

/hobferret

Hobferret; thanks for the tip, I should have thought of that myself - it runs like a charm now in OllyDBG

The next problem presents itself, though, I made a good dump (or at least, I think so). Here's what I did;

1) I pressed shift-F9 till the prog started; a total of 30 times.
2) I reset the prog, reran and pressed shift-F9 29 times.
3) I put a breakpoint on the RETN, pressed shift-F9.
4) I executed an TC EIP<900000 and landed in an obscure (wrongly disassembled) section.
5) I pressed F8 once and landed in something that looks like the OEP, it starts like this:

PUSH EBP <--- I landed here
MOV EBP, ESP
MOV EAX, DWORD PTR SS:[EBP+8]
TEST EAX, EAX

Looks like an entrypoint to me, also, it appears that no bytes were stolen! Double bonus.
Anyways, at this point I left OllyDBG to hang on PUSH EBP and dumped the process fully with LordPE. So far, so good. Then I ran the process normally, opened ImpRec, opened the process, clicked 'IAT Autosearch' and it came up with 'Could not find anything at this OEP! :-('.
So now I'm stuck with that :P I don't know enough about IAT to manually rebuild it. I could learn, of course, but that would take a lot of time, which I don't quite have atm :S. So is there some other way to do this? I mean; ImpRec SHOULD have no problem with this program... I tried to find Revirgin, but can't seem to find a downloadable anywhere

Thanks,
- Fahr

Fahr

I think you are trying to run before you can walk

It does not look like the EIP to me anyways

If you are using that location as the EIP it's quite obvious why Imprec can't find anything good. I know what you have done wrong but read the following line.

Look for LaBBa's "Step by Step" ASProtect Final tut, can't remember where it is now but I have seen it somewhere coz I D/L it

If you get hold of that and read, study and inwardky digest, you will see where you are going wrong

It is most likely the best tut for ASPR around, old LaBBa did some good work there, it's especially useful for newbies. Like he describes it, it is a step by step tutorial.

Regards

/hobferret

Use the "Search" button in the top bar of the Forums and enter "LaBBa" without the quote marks and you will find what you are looking for.

Regards,

Hey JMI

Told you my brain cells were dying

As soon as I saw it I remembered where it was

http://www.woodmann.com/forum/showthread.php?t=5304&page=3&pp=15

Regards

/hobferret

You have no "brain cell" excuse better than mine.

My cells have been dying for alot longer than yours.

Regards,

JMI M8

I doubt it, I was fighting in the civil war under General Stephen D. Lee but I managed to survive at least till now

Regards

/hobferret

I WAS following that tut, but then I saw the snippet which I thought was an entry point and dumped there - completely discarding the tut

Now I did what LaBBa said, after my initial F8, I once more ran the TC. I land in a bunch of code which does not at all resemble LaBBa's example code, not even remotely. It's completely not disassembled properly, it's a giant row of DB [blah] lines. I can read past that, but the raw bytes also don't resemble LaBBa's example code :S
I dumped the process anyways, but then, according to his tut, I have to dump it again after the RET (C3). As I said; my code is complete gibberish and there's no RET to be seen in a LOOONG time...
Add to that that ImpRec still can't find anything with IAT Autosearch, and that doesn't have anything to do with WHERE I dump it either; the exefile has it's EP set to 1000, and ImpRec just can't find anything there, neither when I run the process outside the debugger, nor when I run it IN the debugger. LaBBa's tut never mentions changing the EP in ImpRec. It just states; hit AutoSearch and let magic happen - well, apprently not for this program :S

Also - his tut is for ASPR 1.23 - this program is packed with ASPR 1.24... I don't know if it matters, but I'm starting to think it does...

Thanks,
- Fahr

Fahr

Hold on a minute your first post stated that it was packed with ASProtect 1.23 RC4 Registered

Now then after what you just said I don't know what is going on

PM the Prog name and D/L link and I will have a look, tomorrow most likely, have a wedding to attend today

Regards

/hobferret

Forgot to say that the EP of 1000 is very probably incorrect, the EP of all ASPR's is 1000 - Are you at that address when you dump the target??

If you use the dump plugin in Olly that usually sets the correct EP and have you looked at the run trace to see if there are any REP STOS etc in there, if so you have stolen bytes.

/hobferret

Crud, my mistake - I don't know where the ASPR 1.24 comes from, but it is indeed packed with ASPR 1.23 RC4... I don't know why I suddenly thought it was ASPR 1.24... how bizarre

Anyways, I managed to make the code more readable hitting 'analysis -> analyze code', so I am able to recognize sections from LaBBa's tut now! Should have thought of that before (I don't do Olly too often...).

Next problem; when I'm on the code snippet after the second trace, the tut says I have to press F8 till the retn and then after the retn I am supposed to jump to some other code snippet. I pressed F8 till after the retn, but the 'code snippet' I get into is utter and complete gibberish. No matter how often I press 'analyze code', it just doesn't improve... I don't think this snippet is where I should be...

For reference, the final address and code I end up on is this;

00635A6B . FFA1 CCAC6300 JMP DWORD PTR DS:[ECX+63ACCC]

I'll PM you the URL and program name. Thanks a lot already! This one really has me puzzled...

Have fun at the wedding

Thanks,
- Fahr

Hi Fahr

Had a quick look at your prog and it does work if you follow LaBBa's ideas

There are stolen bytes so you have to FIND THEM use LaBBa's idea once again.

One tip the IAT starts @ 23E21C [+400000]

Hope this helps you!

Regards

/hobferret

Thanks! I think this will help me a lot Using that IAT start address, I can just use ImpRec, can't I?

Thanks,
- Fahr

Ok, 2 questions if I may;

1) How did you find that IAT RVA? I would like to know for future reference
2) According to LaBBa's tut I should get 8 invalid IAT entries (of course, this depends on the program), but I get 84 (!)... Am I missing something here? I cut out all the high numbers. Trying to fix some (viewing hex) results in a 'read error'. Can I treat the ones with 'read error' as being invalid as well?

Thanks,
- Fahr

Fahr

If you look at the code where you first land in Olly - after the trace you will see the address reference for at least 1 of the IAT's, can't remember which one coz I have deleted it. I did keep the Imprec txt file

The IAT is as follows:-

1 0023E21C kernel32.dll
1 0023E2D0 kernel32.dll

1 0023E2D8 user32.dll
1 0023E2E4 user32.dll

1 0023E2EC advapi32.dll
1 0023E2F4 advapi32.dll

1 0023E2FC oleaut32.dll
1 0023E304 oleaut32.dll

1 0023E30C kernel32.dll
1 0023E318 kernel32.dll

1 0023E320 advapi32.dll
1 0023E340 advapi32.dll

1 0023E348 kernel32.dll
1 0023E4EC kernel32.dll

1 0023E4F4 version.dll
1 0023E4FC version.dll

1 0023E504 gdi32.dll
1 0023E698 gdi32.dll

1 0023E6A0 user32.dll
1 0023E9AC user32.dll

1 0023E9B4 ole32.dll
1 0023E9B8 ole32.dll

1 0023E9C0 kernel32.dll

1 0023E9C8 oleaut32.dll
1 0023E9FC oleaut32.dll

1 0023EA04 ole32.dll
1 0023EA24 ole32.dll

1 0023EA2C oleaut32.dll
1 0023EA38 oleaut32.dll

1 0023EA40 comctl32.dll
1 0023EA9C comctl32.dll

1 0023EAA4 winspool.drv
1 0023EAB0 winspool.drv

1 0023EAB8 shell32.dll
1 0023EAD0 shell32.dll

1 0023EAD8 comdlg32.dll
1 0023EAE8 comdlg32.dll

1 0023EAF0 winmm.dll

1 0023EAF8 gdi32.dll

1 0023EB00 kernel32.dll

1 0023EB08 ace32.dll
1 0023ED94 ace32.dll

If there are some you cannot resolve for yourself, search the board there is info here if you look for it

Regards

/hobferret

Ok, thanks for the explanation

I already have the IAT and deleted the wrong entries. Now I have 7 more unresolved entries to fix (I already fixed a lot), I think I'll manage

Is there any way of knowing if I fixed the other entries correctly? Or will I only find out once the app crashes?

Thanks,
- Fahr

Fahr

You will most likely find out if it crashes

I assume you have found the STOLEN BYTES OK

If not just as another tip it's written in Borland Delphi

As I said B4 there is info on the board regarding unresolved pointers so you should be able to manage it

You can always click on SHOW SUSPECT that will give you a good idea of what's wrong M8

Regards

/hobferret

I didn't even look for the stolen bytes yet, I figured I'd first fix the IAT

I know it was written in Delphi - the RCData full of TForms kinda gives it away (I program Delphi at work, so I should know )

And what am I supposed to do with Show Suspect? It only shows me some duplicate entries which are apparently faulty... doesn't solve much... or did you mean it can help me track potential problems?

Thanks,
- Fahr

One more thing; I tried searching this board on any and all combinations of "ImpRec, Unresolved, IAT" but I wasn't really able to find anything worthwhile. I did find some mentions of an Emul plugin, which I can't seem to find anywhere...

Another tutorial on Aspr I read states:



somehow, I don't think that's a good idea

I THINK I managed to fix some (if not most) of the unresolved calls, but as I said, 7 (or 8, after a new trace) remain unresolved. LaBBa says I should EXECUTE them and see what the results are... this bit has me a bit puzzled - HOW do I execute them? Just breakpoint them in Olly and run the app? I might never find the option in the app which calls to that API...

Thanks,
- Fahr

Fahr

Here is a list of some of the unresolved calls, one's I have made notes of and some from LaBBa's tut

Aspr notes V1.4??

Redirected calls which cannot be auto resolved!

44B717 6513C4
6513C4 55 PUSH EBP
6513C5 8BEC MOV EBP,ESP
6513C7 5D POP ESP
6513C8 C20400 RET 04
Becomes Kernel32!FreeResource

44B724 65139C
65139C 6A00 PUSH 00
65139E E8B53DFFFF CALL Kernel32!GMHA
6513A3 FF35E46C6500 PUSH DWORD [00656CE4]
6513A9 58 POP EAX
6513AA 8B05F46C6500 MOV EAX, [00656CF4]
6513B0 C3 RET
Becomes Kernel32!GetCommandLineA

44B730 651388
651388 A1E86C6500 MOV EAX, [00656CE8]
65138D C3 RET
Becomes Kernel32!GetCurrentProcess

44B760 65133C
65133C Look it’s GetModuleHandleA
Becomes Kernel32!GetModuleHandleA

44B770 650EE8
650EE8/F0E GetProcAddress
Becomes Kernel32!GetProcAddress

44B7A0 651358
651358 6A00 PUSH 00
65135A E8F93DFFFF CALL Kernel32!GMHA
65135F FF35E46C6500 PUSH DWORD [00656CE4]
651365 58 POP EAX
651366 C3 RET
Becomes Kernel32!GetCommandLineA

44B7D4 6513B4
6513B4 55 PUSH EBP
6513B5 8BEC MOV EBP,ESP
6513B7 8B05F46C6500 MOV EAX, [00656CF4]
6513BD B84508 MOV EAX, [EBP+08]
6513C0 5D POP EBP
6513C1 C20400 RET 04
Becomes Kernel32!LockResource

4753F8 - ED13D0
EDI3D0 6A00 PUSH 00
ED13D2 CALLKernel32!GMHA
ED13D7 FF35E86CED00 PUSH WORD [00ED6CE8]
ED13DD 58 POP EAX
ED13DE 8B05F86CED00 MOV EAX, [00ED6CF8]
ED13E4 C3 RET
Becomes Kernel32!GetCommandLineA

4573FC - ED13C0
ED13C0 55 PUSH EBP
ED13C1 8BEC MOV EBP,ESP
ED13C3 CALLKernel32!GetVersion
ED13C8 A1F46CED00 MOV EAX, [00ED6CF4]
ED13CD 5D POP EBP
ED13CE C3 RET
Becomes Kernel32!GetVersion

457444 - EE9E24
EE9E24 52 PUSH EDX
EE9E25 68369507C0 PUSH WORD [C0079536]
EE9E2A C3 RET
Becomes Kernel32!GlobalUnlock

475464 - ED13B8
ED13B8 A1EC6CED00 MOV EAX, [00ED6CEC]
ED13BD C3 RET
Becomes Kernel32!GetCurrentProcess

4754D0 - ED0EF0
ED0EF0\\ED0FI6
CALL Kernel32!GetProcAddress
RET 08
Becomes Kernel32!GetProcAddress

475518 - ED1360
ED1360\\ED1384
CALL Hernel32!GMHA
RET 04
Becomes Kernel32!GetModuleHandleA

LaBBa explanation!

PUSH EBP
MOV EBP,ESP
MOV EAX,[FF7E24] // DWORD VALUE 001522398
POP EBP
RETN4
EITHER LOCK RESOURCE or FREERESOURCE

PUSH DWORD PTR DS:[FF7E14]
POP EAX
RET
GET VERSION

PUSH EBP
MOV EBP,ESP
MOV EAX,DWORD PTR DS:[FF7E24]
MOV EAX,DWORD PTR SS:[EBP+8]
POP EBP
RETN4
EITHER LOCKRESOURCE or FREERESOURCE

MOV EAX,DWORD PTR DS:[FF7E20]
RETN
GETCURRENTPROCESSID

MOV EAX,DWORD PTR DS:[FF7E18]
RETN
GETCURRENTPROCESS - GETCURRENTPROCESSID works too!

PUSH EBP
MOV EBP,ESP
MOV EAX,DWORD PTR DS:[FF7E24]
POP EBP
RETN4
EITHER LOCKRESOURCE or FREERESOURCE

Another thing regarding execute them - First I am a relative newcomer to Olly but in SICE you would just do a "dd address" of IAT then set a BPX on what location that address refered to. i.e. if say 654320==01234567 then set BPX on 01234567. The prog will stop at that address all you need to do then is TRACE thru till you find the correct API

There must be a way to do the same in Olly, I suppose you would set a break on memory execution, but I am not sure, like I said Olly is a whole new world to me. Maybe someone else on the board can direct you in the right direction

Just one other thing, if you get a read error when you look at the code in Imprec, make sure the prog has not crashed out. Sometimes when you do an auto trace the prog has gone so you will get a read error if there is nowt there to grab

Regards

/hobferret

hobferret:

Sorry for the delay in commenting on your successfully becoming the oldest living person in these United States and having lived well past your 140th year. Quite an accomplishment.

Someday maybe I can share with you my military experience of invading the U.S. from a rubber raft and running an Intel Op in Fayetteville. We westerners aren't too used to those 96 degree and 98 % humidity summer days. Too bad that last Civil War Soldier's Bride died so many years ago. Must be lonely now. May 10th is not too far away and I will lift a glass in your honor on the occasion.

Regards,

excellent

He would be Robert E Lee's long lost brother ?
Ulysses called me, he wants his sword back

Woodmann

Hi JMI

Your memory is fading too, the U.S. was not in existance back then and we certainly did not have rubber rafts.

It was all blood sweat and tears back then. They were close to producing GPS guided bombs but just lacking the final part of the puzzle.

You must realize that I was only joking, I take my hat off to the many bold men on both sides who fought and lost their lives.

BTW General Stephen D. Lee was a post war college president and he knew all about Intel, just visit his grave in Columbus Mississippi and pose the question.

Finally, I would love to share the experience with someone who was involved, it would be a great honor.

And to Woody, yes he was a distant relative of Robert E. Lee

Regards

/hobferret

Fahr

It occured to me there must be a better way of finding the stolen bytes try this out

1st Set break on the old code locking API, make a note of the EAX value, hope everyone remembers it!

2nd Set conditional break on REP STOS BYTE PRT ES:[EDI]
Scroll up til you find a JMP SHORT XXXXXXXX, should be 6 lines up, make a note of the address.

3rd Restart prog, break again on the famous API, when you get to EAX make it same as noted before.

4th Set conditional break on JMP SHORT XXXXXXXX.

When prog stops take the jump this puts you into the address which REP STOS clears out, now you don't have any violations you can just trace thru it - NO PROBS!

Regards

/hobferret

I'm not exactly sure what you mean here. As I said; I haven't even tried to find the stolen bytes, so I also haven't failed yet
But I should just be able to find those bytes in the Run Trace Log, shouldn't I?

- Fahr

Ok, I have 2 more unresolved IAT entries (and some suspects, but first things first), mainly thanks to the notes hobferret posted about IAT a few posts back - thanks!

Anyways, I can't figure those 2 out... they appear to be calling to ntdll.dll, but I find that VERY hard to believe, since this program also runs on 9x/ME.
Both entries are similar, they look like this:

push ebp
mov ebp,esp
push -1
push 77F87CB0 // ~= ntdll.dll/0199/RtlDeleteCriticalSection
push 77F98191 // ~= ntdll.dll/04A3/wcstoul
mov eax,fs:[0]
push eax
mov fs:[0],esp
push ecx
push ecx
sub esp,10
push ebx
push esi
push edi
push 77F87C1E // ~= ntdll.dll/0199/RtlDeleteCriticalSection
retn

In fact, it seems like both entries are EXACTLY alike...

Can anyone tell me what this is? I can't seem to figure it out :S

Thanks,
- Fahr

hint : Here is the how the function ntdll!RtlDeleteCriticalSection looks like

Uhm thanks and nice IDA output... but I don't see how it can help me

sigh.. perhaps look harder and think a little bit?
maybe a quick search around and look at a few tutorials?

Don't get me wrong here - I don't mean I don't understand the code or whatever, I just don't get its relevance in this particular situation. This program does not run on WinNT only, so I don't think it import ntdll.dll, which leads me to believe that this API call is something entirely different from what it appears to be.
It's not that I don't get what you're hinting at - apparently there is something with that bold line in your code bit... I just don't get what you mean by POSTING it...

Flame me all you want, but I just don't get the idea...

- Fahr

ok i see... you should look at the whole Import tree overall... then guess which module is this import from... if it is a single import from a module.. it is most likely ntdll!... if it is part of lots of import from a certain module, for example kernel32.dll then it might be tricky but i doubt it honestly!!!

Just try with the obvious n see if it works...

Both entries (which are the same) are in the kernel32.dll tree. One is all the way on top, the other one is halfway... but I'm pretty sure they're both kernel32.dll imports...

I guess this makes it tricky

- Fahr

next thing you can do is BPM on that IAT address and see when it is written on.. from then on you cna backtrace to find the IAT redirection routine which will have the API name decrypted before redirection...

Another method is disassemble your dump.exe in IDA and see when it is called... if it is never called it might be bogus...

Also, check if your Import are alphabetically sorted ... if so it makes your job a hell lot easier...

Fahr

I think you will find that these calls are actually to Kernal32.dll - with the same routine

You will NOT find the stolen bytes in the run trace, you have to do it by tracing, hence the post about a better way of doing it

Regards

/hobferret

BTW I ain't suggested that you have failed M8

I DID IT!! I UNPACKED IT! - well, kind of anyways. Following LaBBa's FINAL tut, I was able to work it (before, I only found the first one he posted and didn't bother to read thru the thread - DOH.).

Lots of thanks to Hobferret for his help with the IAT, couldn't have done it without you
Lots of thanks to all the other people for having a nearly ENDLESS patience with me and my n00bishness

One more thing, though. The app runs fine as far as I could see, but when I CLOSE it, it gives me an access violation. Running is no prob, closing is. It says 'Runtime error 216 at 00403B36'.

Here's what I've found;
OEP is at 635A5B

Stolen bytes:
PUSH EBP
MOV EBP,ESP
SUB ESP,10
PUSH EBX
MOV EAX, 63516C

I know that hobferret mentioned something about PUSH EBX... would it run better if I removed it and moved the OEP up by one?

Thanks again to all!

- Fahr

Ok, I went ahead and did it already - without the push ebx, it runs fine

No more errors or access violations or anything. But can anyone please explain me WHY? I DID find PUSH EBX as one of the stolen bytes...

Thanks,
- Fahr

Fahr

Glad to see you got it working

Like I said however I am still not really sure if there is one more - a PUSH EBX - may be missing but unlikely because the extra push should cause it to crash somewhere - which it obviously did

Regards

/hobferret

Obviously indeed, but I still don't know why that extra push is there in the first place...

Oh well, it works I'm already busy on ACTUALLY cracking the thing. I'm thinking of writing a complete tut covering unpacking and cracking this particular target... I'll be sure to mention you in the thanks

- Fahr

Fahr

To be honest I don't know either, maybe it's part of ASPR code obfuscation

It always helps if you know what the prog was compiled with, that way you have a better idea of how the stack frame is created

BTW did yoy try the code locking idea of getting the stolen bytes, darn site easier as there are no exceptions because the code has not been executed

Regards

/hobferret

To be honest, I didn't quite get what you meant by the code locking API and how to figure those bytes
I used LaBBa's method, NOP-ing all the exceptions on my way and tracing thru the code like that...

- Fahr

Fahr

Have a look at this thread

http://woodmann.com/forum/showthread.php?t=4936

Regards

/hobferret

Hmm... interresting... by why GetSystemTime? And is that EAX value he mentiones the EAX value I will need for the stolen bytes? (mov eax, [something])?

Thanks,
- Fahr

Ok M8

Read my post on page2 of this thread and all will become clear

Regards

/hobferret

So GetSystemTime is the code locking API? And tracing thru it will also give me the EAX value? I'll check it out...

One more thing, at the end of page 1 you say the IAT begins at 23E21C. I am retracing my steps to write a tut, but I just can't find 23E21C :S. So far the closest IAT address I came acros was 23A61C - a difference of 3C00! So can you please tell me how you find that IAT address? Cuz I'm still in the dark...

Thanks,
- Fahr

Fahr

If you look at Page1 you will see that I posted this:-

One tip the IAT starts @ 23E21C [+400000]

That means if you are looking for it in a debugger it will be 63E21C, I can't look again coz I have deleted the prog, not of much use to me

You must have found it someway because you have gotten it working

Regards

/hobferret

I know that, of course. I also found 63A61C instead of 23A61C. I just don't get how you found that real IAT entry.
When I fill out the OEP in ImpRec, it comes up with 23A61C for the RVA. Obviously, this is not correct...
And I didn't find the REAL RVA myself, I used the info you gave me.

- Fahr

Fahr

Your in luck, I have been searching thru my notes and still have the info on this prog

Finding the IAT in Olly

After tracing you end up at 00407180 JMP DWORD PTR DS:[63E318], at this point you are in the program so this must be pointing to a valid IAT referrer.

Goto the dump screen and goto expression 0063E318. Now scroll up until you find a DWORD that is a "large" number, one that does not look like part of a dll routine.

For example 0063E218 is DCC8CC21, bear in mind that you have to reverse it, this can't be a dll! - 0063E21C is E4D3D300 reversed becomes 00D3D3E4 and looks promising!

Then scroll down til you think you are at the end of the JUMP table and that becomes the last referrer!

If in doubt use the first one in Imprec and set a length of 1000 then cut and delete the useless ones!

Dont forget you also need the EP to be correct or at least somewhere close! and away you go!

Cant be of any more help coz like I said I dont have the prog anymore and I aint going to reinstall it

Regards

/hobferret

Fahr:

Just so you don't think you have gone completely crazy, (using your target from before it was removed ) You said you:

1) I pressed shift-F9 till the prog started; a total of 30 times.
2) I reset the prog, reran and pressed shift-F9 29 times.
3) I put a breakpoint on the RETN, pressed shift-F9.
4) I executed an TC EIP<900000 and landed in an obscure (wrongly disassembled) section.

(There is another way to do this last step, besides the TC EIP<900000, which was described in R@dier's tut on tag & rename, which is:

Press Alt + M keys and bring up the memory map window
then look for the target "code" section, right click on it and choose set memory breakpoint on access. Then press CTRL + F11 and you are at the entry point of the Code section at 00407180, which is the same address you get to with the TC EIP<900000.)

Here you should do a CTRL +A to "Analyse" code. You should now be at:

00407180 $-FF25 18E36300 JMP DWORD PTR DS:[63E318]

Now at this point, the address you need for your last MOVE EAX, target,XXXXXX instruction is generally to be found in "either" EAX or EBX. In this case it's in EBX and it is the 0063516C which you later found.

Now another R@dier reported trick (don't know who started either technique): Remove the analysis. "Right Click" in the CPU window, Analysis--> Remove Analysis. Now do Alt + K to bring up the STACK window. If you didn't remove the Analysis, you will have only one entry. If you did remove the Analysis, you will have two. The second is:

Call stack of main thread, item 1
Address=0012FF8C
Stack=00635A6C
Procedure / arguments=Target.00407244
Called from=Target.00635A67

If you Double click on the 00635A67 it will open the CPU window again at that location. This one is kind of tricky, because it's at an odd address, and if you scroll up, the view shifts to an even address. Generally your Stolen Bytes go right above this address. [EDIT: In OllyDBG you can move the display up or down, one bit at a time by using the CTRL + up or down arrow.]

Now finding the Stolen Bytes can be accomplished by tooking in the Trace Window. View --> Run Trace. If you set your Debugging Options in the TRACE tab to check "Log Commands" and "Show ESP," when you open the TRACE by going to Window --> Run Trace, the window will open. Next Right Click on the window --> Highlight Register --> EBP.

Now if you scroll down to the bottom you will see alot of "REP STOS BYTE PTR ES:[EDI]" code which was used to erase the Stolen Bytes and other things. Now if you look above this section, you should have a red section in the command window. Keep looking up and you will eventually see a red highlighted EBP (Generally around 600 or less) which is identical to ESP. In this case it is: 12FFA0. Look into the Command Window opposite the ESP, which is immediately above the highlited EBP and you will see:

PUSH EBP
MOV EBP,ESP
SUB ESP,10
PREFIX REPNE: --> ; Superfluous
PREFIX REPNE:--> ; Superfluous
SUB ESP,1C --> ; Superfluous
SUB ESP,18--> ; Superfluous
JMP Short (to next instruction)-->
PUSH EBX
and you already know that the next needed instruction is:
MOV EAX, 63516C from EBX above.

Some of these techniques are discussed on the exetools forum also. Do a search there for britedream and you will get a list that generally includes the ASPR threads.

Enough for now.

Regards,

Thanks for the replies! I'll check it out and report back on my findings

Sorry for my late reply, I've been terribly busy as of late.

- Fahr