Unpacks ok here as well with Olly 1.10c.
Made a small bytechange to be able to register with any name/serial.
Lemme know if you need cracking help later on.

Hi,

Here are my notes.
@SvensK, I found Olly 1.10c. crashed when I tried to undo my nops
after I hit "-" then hi-lighted the nops and as soon as I right clicked olly would fall over. I tried it several times and had no luck.
so I reverted back to original. 1.10b (step 2)

If you can test it on your machine using he method in my notes it would be appreciated to see if it is just my setup thats faulty

@JMI my debugger setting are as at when I unpacked this target although some may be un-necessary all you really need is
Ignore memory access violations in KERNEL32 to be checked.
and all wil work fine

I was playing with Arma before doing this target ;p
thus the current settings


Best Wishes
R@dier

To Svensk:

I have problem with ollydbg 1.10c crashing, r u using windows xp.


Thanks.

@R@dier: You are right, latest olly crashes as soon as I right-click that BP'ed call.

The reason I didn't encounter this earlier is coz I went straight for the OEP and dumped there, then fixed imports with ImpRec with the aspr2 plugin.

@britedream: Yup, I use WindowsXP and as you can see my Olly 1.10c crashed as well :(

Edit: Btw, size of IAT is actually 674.

Hi all
@britedream, I am using winxp sp1 as well

@SvensK oops you are right it is 674 and not 678 my bad :D
thanks.


Best Wishes

R@dier

britedream and R@dier:

Man, one shouldn't try to write analysis of issues at 2:00 AM after getting very little sleep for a couple of days. Reading my last post after a few hours sleep, I wonder how I could have written "00A60019-00A6005C and/or 00A10671 and 00A10019" were within the code range of "00401000 to 00499000." Somehow, even though I typed 00A1 or 00A6, my tired brain read them as 0041 and 0046. (No excuse sir, hadn't even had anything to drink.)

That said, I've made sure my exceptions were set the same as yours, either with or without the other exceptions marked besides the "ignore" kernel32. I'd had the kernel32 box checked already. Using your "search," I easily located the two calls and BP'd on that location, continued pressing SHIFT+F9 until it broke there. Then, just for a test, I moved up in the display and put a BP on 00A10019 (recognizing, this time it was actually an "A" and not a "4" :D ) and went back to pressing SHIFT+F9 (without NOPing the Call you indicated) just to see if the program would break in what we all knew should have been the "last" excption. I still never reached it.

For some reason, I'm still ending up at 00A111D3 and the routine which leads to the error message, even though I'm still using exactly the same method of attack which worked perfectly on a couple of other ASPR targets. In case it was something you didn't mention, the only plugins I have installed at the moment are the command line and bar, hide debugger, and Ollydump, although, at the moment I don't see why that would make a difference. As soon as I get a chance, I'll try Britedream's new script and/or single stepping from that Call to see if I can find where it goes "wrong".

As I said before, for me the "strange" thing here is that at the moment my tracing is getting misdirected by something I haven't figured out yet. I knew what the last exception was supposed to look like and can even find it in the code. I just haven't yet been able to make my Olly get there. But, after all, trying to solve these challenges is why we do this in the first place. :D

Thanks for the information. It confirms there is something "strange" going on in my setup that you all are not experiencing.

Regards,

I really appreciate the help from everyone! Good to know that I'm not the only one with crashing problems. I have also experienced the right click problem in olly 10.0c when using XP.

@R@dier: I have been able to build an executable file. Thank you very much for your notes I was able to confirm that I was not making a mistake anywhere. However, Have i missed something in my code? When I try to repack Asprotect says it is already protected and w32dasm will dissasemble but give me a warning that it is not in a PE file format. Does this happen to you as well? Should I try learning how to clean up my code after its unpacked?

@JMI: I post at work and at home, at work using olly on NT my errors are in the 00A6 range and at home on XP my exceptions are in the 00A1 range. Sorry for the confusion. As well as R@ider my only setting is to Ignore memory access violations in KERNEL32. However, PEID also gave me an incorrect OEP of 47CB16. I placed a breakpoint on your address and followed through with my exceptions until that point. However once i break on the code and press F9 again to continue running. The program terminates itself with an Access violation when executing [F7A69B78], Debugged program was unable to process exception and then I was able to get your messagebox "Dont know how to continue because memory at... " by pressing F9 again. going to mess with olly and see if i can make it break there on purpose without the breakpoint.

Here are the results of two traces:
First setting a breakpoint on your exception and running from my the second to last exception

Address Thread Command ; Registers and comments

77FA15FC Main MOV EBX,DWORD PTR SS:[ESP] ; ECX=00000000
Single step event at 00A611C8
00A611C8 Main POP DWORD PTR FS:[0] ; ECX=0012D450
77FA15FC Main MOV EBX,DWORD PTR SS:[ESP] ; ECX=00000000
Breakpoint at 00A611D3
00A611D3 Main POP EAX

<--This is where i get the address violation just like yours-->


Now a run trace from my second to last exception to my last exception no breakpoint.

Address Thread Command ; Registers and comments

77FA15FC Main MOV EBX,DWORD PTR SS:[ESP] ; ECX=00000000
Single step event at 00A611C8
00A611C8 Main POP DWORD PTR FS:[0] ; ECX=0012D450
77FA15FC Main MOV EBX,DWORD PTR SS:[ESP] ; ECX=0012FF88, EDX=00A6117A, EBX=00A30000, ESI=00A50000, EDI=0012FF90
Access violation when writing to [00000000]
00A60019 Main XOR DWORD PTR DS:[EAX],EAX ; ECX=0012FC98



@Svensk: Did you try closing your app and opening it again after registering. :) Don't forget to fix that bug. Thank you for the offer of help. I will definately take you up on it.

OK. Let's try to get this typed without a crash. :eek:

I've rebooted my computer several times trying to get the MS Baseline Security program to load properly. Then I went back to the target and am having "different" behaviour, which mirrors what R@dier attached here, but is different than his tut on Tag&Rename, but I think I fully understand the difference.

First, the program is no longer crashing at the routine starting at 00A111D3. That's good and most likely has something to do with rebooting the computer several times. After the original F9 and 26 more SHIFT+F9s, I finally get to the 00A10019 routine we all know and love. ;) But here it still does not behave the same as R@dier's tut on Tag&Rename, so I thought I'd mention the differences, to anyone who may be following along.

When I got to 00A10019, I tried setting the F2 bp on the RETN and pressing SHIFT+F9 one more time (as described in the Tag&Rename tut), where I had expected to bring up the memory map window and place a "break on access" on the code section. However, if I bp the RETN and hit another (the 28th total F9 and) SHIFT+F9, it breaks on the RETN, but the program IS ALREADY STARTED.

If, on the other hand, I bp the RETN at 00A1005C AND set a memory break on access on the .code section of the target, and press SHIFT+F9 one more time (for a total of 27 SHIFT+F9 and one F9) the program never reaches the bp on the RETN and goes RIGHT TO THE OEP at 0047ED5F, without ever running the CTRL+F11 described by R@dier in the Tag&Rename tut and, probably as a result, the run trace is completely empty. Works the same if no bp is set on the RETN and just a break on memory access is set on the .code section of the target, as R@dier's attachment states.

This program has NO Stolen Bytes, as everyone has reported, and this fact probably explains why that last tracing step using CTRL+ F11 was not necessary, but no one has actually said so and this was the first one of the few ASPR programs I've had time to play with recently, which had no stolen bytes.

R@dier's trick of letting ASPR fix its own IAT is very useful indeed.

Since I've not seen anyone discussing the possible indicators of when there might be, and might not be "stolen bytes" I have this observation. In those targets I had time to play with which HAD stolen bytes, that last exception was in the form:

00D23D03 3100 XOR DWORD PTR DS:[EAX],EAX
00D23D05 64:8F05 00000000 POP DWORD PTR FS:[0]
00D23D0C 58 POP EAX
00D23D0D 833D BC7ED200 00 CMP DWORD PTR DS:[D27EBC],0
00D23D14 74 14 JE SHORT 00D23D2A
00D23D16 6A 0C PUSH 0C
00D23D18 B9 BC7ED200 MOV ECX,0D27EBC
00D23D1D 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
00D23D20 BA 04000000 MOV EDX,4
00D23D25 E8 E6D2FFFF CALL 00D21010
00D23D2A FF75 FC PUSH DWORD PTR SS:[EBP-4]
00D23D2D FF75 F8 PUSH DWORD PTR SS:[EBP-8]
00D23D30 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
00D23D33 8338 00 CMP DWORD PTR DS:[EAX],0
00D23D36 74 02 JE SHORT 00D23D3A
00D23D38 FF30 PUSH DWORD PTR DS:[EAX]
00D23D3A FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00D23D3D FF75 EC PUSH DWORD PTR SS:[EBP-14]
00D23D40 C3 RETN
00D23D41 5F POP EDI
00D23D42 5E POP ESI
00D23D43 5B POP EBX
00D23D44 8BE5 MOV ESP,EBP
00D23D46 5D POP EBP
00D23D47 C3 RETN

while this target, without stolen bytes is in the form:

00A10019 3100 XOR DWORD PTR DS:[EAX],EAX <---- we are currently stopped here;
00A1001B 64:8F05 00000000 POP DWORD PTR FS:[0]
00A10022 58 POP EAX
00A10023 833D D839A100 00 CMP DWORD PTR DS:[A139D8],0
00A1002A 74 14 JE SHORT 00A10040
00A1002C 6A 0C PUSH 0C
00A1002E B9 D839A100 MOV ECX,0A139D8
00A10033 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
00A10036 BA 04000000 MOV EDX,4
00A1003B E8 30C4FFFF CALL 00A0C470
00A10040 FF75 FC PUSH DWORD PTR SS:[EBP-4]
00A10043 FF75 F8 PUSH DWORD PTR SS:[EBP-8]
00A10046 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
00A10049 8338 00 CMP DWORD PTR DS:[EAX],0
00A1004C 74 02 JE SHORT 00A10050
00A1004E FF30 PUSH DWORD PTR DS:[EAX]
00A10050 FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00A10053 FF65 EC JMP DWORD PTR SS:[EBP-14]
00A10056 5F POP EDI
00A10057 5E POP ESI
00A10058 5B POP EBX
00A10059 8BE5 MOV ESP,EBP
00A1005B 5D POP EBP
00A1005C C3 RETN

Notice the "extra" return in the first and the difference between the:

PUSH DWORD PTR SS:[EBP-14] for one with stolen bytes

vs

JMP DWORD PTR SS:[EBP-14] for one without.

Maybe one of you with more time to play can confirm whether this is a consistent pattern between these two types.

Regards,

to go to oep you don't have set bp on retn , you can set the memory bp on access on the code section while you are on the last exception, use the bp on retn only for trace.(check my last script)

2- my new signature for correcting the IAT is one byte less than my old one, which misses some times.the new one is = 8B 17 89 02 . this is more reliable

@gabri3l: Yeah, I didn't say I was done cracking it. Wasn't sure if you were only interested in unpacking it :)

Actually this is a britedream trick and yes it is truly usefull :D


Best Wishes

R@dier

Thanks R@der, but the trick isn't mine , I have read it some where long time ago

I don't really remember , then I did create a signature for it , but the later signature I just posted is more relialble.
Regards.

Can anyone confirm my observation of the difference between the last exception routine code when there are stolen bytes and when there are none? I've only seen this one target without stolen bytes. Just to recap, those I've had time to play with or have read tuts about with stolen bytes seem to have the last part of the last exception routine in the form:

00D23D38 FF30 PUSH DWORD PTR DS:[EAX]
00D23D3A FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00D23D3D FF75 EC PUSH DWORD PTR SS:[EBP-14]
00D23D40 C3 RETN
00D23D41 5F POP EDI
00D23D42 5E POP ESI
00D23D43 5B POP EBX
00D23D44 8BE5 MOV ESP,EBP
00D23D46 5D POP EBP
00D23D47 C3 RETN

and this one without stolen bytes ends with:

00A10050 FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00A10053 FF65 EC JMP DWORD PTR SS:[EBP-14]
00A10056 5F POP EDI
00A10057 5E POP ESI
00A10058 5B POP EBX
00A10059 8BE5 MOV ESP,EBP
00A1005B 5D POP EBP
00A1005C C3 RETN

Regards,

There is another target which I think or I'm sure whcih does not have stolen bytes
Target: VCD cutter. (Since it's "ASPR" too I'm posting it here. Sorry for going off topic.)

I'm free now and I'll try this "recall pro" too. Interesting discussion with JMI involved :)

Regards,
ferrari :)

ferrari:

Did you install VCD Cutter on XP? XP put up a warning that it was not approved for XP and cautioned against installing it.

Regards,