Hello everyone!

First let me say that I have searched both this forum and with google and found nothing that I find useful.

What I usually do: Run the ASPR-prog and count the exceptions. Then reload it and run it lastExceptionsCount-1 times. Then but a break-on-access on the section that is marked code in Olly (I have tried the other sections too.)
Then trace until Olly stops.

Why I can't do it with this program: The packed program throws alot of exceptions itself when it starts (atleast I suspect it does) and I can't really find the end of the ASPR and the beginning of the program.

Other alternatives 1: I have tried to run the program and just stop it. Write down the VA and then reload it, put a HBP on memory write on that VA to get where the ASPR writes to the file. Nothing useful found. It writes alot of times to the code and I don't seems to find where the OEP is written.

Other alternatives 2: I have tried to use the BPX GetVersion trick but I can't get any good code from it.

Other alternatives 3: I even tried some ASPR-unpackers but they all failed (AsprDbgr, Stripper,Caspr)

So my question is this: Does anyone know any other alternative to find the OEP of ASPR?

PS. I'm a newbie and I have only used Olly so far. DS
PS2. I'm not asking anyone to unpack it for me, this is NOT an unpack-request DS2.

try peid

Just put a BPX after about 25 exceptions. Then put the breakpoint on the memory access. Thru experimentation, asprotect jumps to OEP after 25 or 26 exceptions (at least it used to). You can at least dump after 25 exceptions.

-nt20

Hi nt20

I have been messing around with aspr and found some progs that will not dump correctly - they run @ addresses in range of 138XXXX - you can't find the hex values anywhere in the dump - I'm assumin the base is 400000 and the offset F8XXXX but still can't find anything - anyone any ideas

/hobferret

guys, long time not played with asspr.
who knows, where is newest?

I have a similar situation that doesn't seem to be covered in any of the tuts (or I'm not understanding them).
In my case the main, unpacked program is based at 400000 but these high addresses are ASPR's redirected calls into Kernel32 functions - eg GetVersionA, EnterCriticalSection.
I started "fixing" these by manually altering the JMPS into these routines ( held at 4xxxxx) into the appropriate BFxxxxxx addresses that corresponded to the desired Kernel32 function.
This worked well for a while, but then I came up against a problem that I couldn't resolve - the program starts to reference values in ASPR'd gotton storage at addresses around 8xxxxxx that contained values critical to execution that had been set BEFORE control is passed to the OEP.
I'm speaking as a newbie, and only recounting my own experiences, so please don't shoot me for my ignorance.
Regards, Len

It really would be beneficial for you to read ASPR's user manual. It can give you valuable insights as to what it is doing. For example, a software author can choose to give ASPR some callback functions, which are similar to what you describe, functions in which ASPR will call before running your program. Also, functions can be encrypted and then the program can call to ASPR to decrypt them on the fly.

One thing that is good to remember with reversing is to gather as much information about your target (in this case, the protection), BEFORE starting to truly reverse it. For example, are there any documentations for that protector on the app? Or is there an SDK for the app, or for the protection? These can all give you valuable clues as to a good point of attack. You must think laterally, not linearly.

-nt20

nikolatesla20: Nop, after 25 exceptions I'm still in ASPR and alot och Access violations.

I have tied Peid and I manged to unpack it (it said so) but the file is not unpacked.

But thanks to all who answered, I will keep on working on this one.

Here some important points:
1. Run the prog in Olly and ignore all the exception. You found that:
_ The check debugger routine (IsDebuggerPresent)
_ The prog can't run smoothly in olly because of some exceptions.

How to unpack:
1. Use plugin IsDebuggerPresent to hide from the check routine. After several Shift-F9, you'll stop here:
01343EE4 3100 XOR DWORD PTR DS:[EAX],EAX <--- stop here
01343EE6 64:8F05 00000000 POP DWORD PTR FS:[0]
01343EED 58 POP EAX
01343EEE 833D B47E3401 00 CMP DWORD PTR DS:[1347EB4],0
01343EF5 74 14 JE SHORT 01343F0B
01343EF7 6A 0C PUSH 0C
01343EF9 B9 B47E3401 MOV ECX,1347EB4
01343EFE 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
01343F01 BA 04000000 MOV EDX,4
01343F06 E8 0DD1FFFF CALL 01341018
01343F0B FF75 FC PUSH DWORD PTR SS:[EBP-4]
01343F0E FF75 F8 PUSH DWORD PTR SS:[EBP-8]
01343F11 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
01343F14 8338 00 CMP DWORD PTR DS:[EAX],0
01343F17 74 02 JE SHORT 01343F1B
01343F19 FF30 PUSH DWORD PTR DS:[EAX]
01343F1B FF75 F0 PUSH DWORD PTR SS:[EBP-10]
01343F1E FF75 EC PUSH DWORD PTR SS:[EBP-14]
01343F21 C3 RETN

Press Shift-F7 and now use the method of ricardo, set breakpoint on memory access at the code section. Press F9..and boom you will be at the OEP:

006833BA FF15 1C737F00 CALL DWORD PTR DS:[7F731C] <---- stop here
006833C0 33D2 XOR EDX,EDX
006833C2 8AD4 MOV DL,AH
006833C4 8915 18F39300 MOV DWORD PTR DS:[93F318],EDX
006833CA 8BC8 MOV ECX,EAX
006833CC 81E1 FF000000 AND ECX,0FF
006833D2 890D 14F39300 MOV DWORD PTR DS:[93F314],ECX
006833D8 C1E1 08 SHL ECX,8
006833DB 03CA ADD ECX,EDX

So 006833BA will be the Temp OEP. Now you can dump and fix IAT for it.

2. Stolen bytes:
Look above a little, you'll see alot of 0 bytes:
00683393 C3 RETN
00683394 0000 ADD BYTE PTR DS:[EAX],AL
00683396 0000 ADD BYTE PTR DS:[EAX],AL
00683398 0000 ADD BYTE PTR DS:[EAX],AL
0068339A 0000 ADD BYTE PTR DS:[EAX],AL
0068339C 0000 ADD BYTE PTR DS:[EAX],AL
0068339E 0000 ADD BYTE PTR DS:[EAX],AL
006833A0 0000 ADD BYTE PTR DS:[EAX],AL
006833A2 0000 ADD BYTE PTR DS:[EAX],AL
006833A4 0000 ADD BYTE PTR DS:[EAX],AL
006833A6 0000 ADD BYTE PTR DS:[EAX],AL
006833A8 0000 ADD BYTE PTR DS:[EAX],AL
006833AA 0000 ADD BYTE PTR DS:[EAX],AL
006833AC 0000 ADD BYTE PTR DS:[EAX],AL
006833AE 0000 ADD BYTE PTR DS:[EAX],AL
006833B0 0000 ADD BYTE PTR DS:[EAX],AL
006833B2 0000 ADD BYTE PTR DS:[EAX],AL
006833B4 0000 ADD BYTE PTR DS:[EAX],AL
006833B6 0000 ADD BYTE PTR DS:[EAX],AL
006833B8 0000 ADD BYTE PTR DS:[EAX],AL

with a little trick, you 'll find that stolen bytes is:
00683394 > 55 PUSH EBP
00683395 8BEC MOV EBP,ESP
00683397 6A FF PUSH -1
00683399 68 D8858900 PUSH dumped_1.008985D8
0068339E 68 84BD6800 PUSH dumped_1.0068BD84
006833A3 64:A1 00000000 MOV EAX,DWORD PTR FS:[0]
006833A9 50 PUSH EAX
006833AA 64:8925 00000000 MOV DWORD PTR FS:[0],ESP
006833B1 83EC 58 SUB ESP,58
006833B4 53 PUSH EBX
006833B5 56 PUSH ESI
006833B6 57 PUSH EDI
006833B7 8965 E8 MOV DWORD PTR SS:[EBP-18],ESP

fixed it, and run, now it done.

you can contact me via Y!M: Computer_Angel_viruses

this trick was discussed a long time ago in another thread...

read faq+manu

Thanks everyone for your answers!

I now know what I did wrong, I pushed Shift + F9 to many times, I thought I was in the ASPR code and missed the OEP. But I have now corrected everything and my baby is up and running! The only ploblem now is that I couldn't find the stolen bytes manually and had to use BiteDreams (excellent) script for Olly.

/Harding

this DivxPlayer seems protected with not last asspr;
here i did for you some job:

exceptions count: 1Dh(29)
first instruction in code_seg: 6833BAh
ripped bytes: 26h;
ripped+pseudo-ed OEP bytes dump;

after last exception trace manually until POPAD restores start state;
then soon stats ripped oep;

Now you: restore OEP bytes. (home work)

Thanks Eval but I have already got it up and running.
But I didn't know about the POPAD trick, I will try that.

/Harding