ASPR 1.2 question

[gabri3l]

Thank you guys for the help. Good advice JMI! i have about 2 pages of notes just trying to unpack this program. (and a few more notes on a taco bell napkin) . Hopefully I will be able to figure out what I'm doing wrong so i can move on and compare them to another program.

Time willing, I hope to get a better unpack and rebuild of the program. And maybe work on cleaning the code up. I must have missed something if asprotect says that it is still packed. On Woodmanns forum there was some info on cleaning up an ASprotect unpack. I've bookmarked it to refer back to. Much Thanks Ferrari for your plugins folder. I only had aspr 1.2 and aspr2 did not even know there was one for aspr 1.23. And for the britedream tut. When im done working on this program I feel a target with stolen bytes calling me.

One good thing is that I feel like I'm getting a better idea of whats actually going on rather than just blindly following a tutorial.

[JMI]

gabri3l:

I have a question for you. I was not able to find a copy of v1.3 of the target because it's been replaced with v1.3a. Attempting to follow the code in OllyDBG it seems strange because the code for the SEH and exceptions all occur in what is listed as the main code section of the file. By this I mean that from the initial start at 0040100 all of the exception code takes place in the 00400000 range, while most ASPR files I've looked at in Olly have had these routines in a far distant address, well out of the 00400000 range of the target ".code" section. Although PEiD identifies this as ASPR I'm wondering if that is really true, considering that your version still identified ASPR even after you removed it.

Using the F9 and SHIFT+F9 technique I am eventually raising the following messagebox:

"Don't know how to step because memory at address XXXXXXXX is not readable.Try to change EIP or pass exception to program"

and one can't set a "breakpoint on entry" to the ".code" section, because it is already IN THE CODE SECTION.

I have found discussion of such a message and possible workaround on the OllyDBG Forum here:

http://ollydbg.win32asmcommunity.net/index.php?action=vthread&forum=1&topic=612

But haven't had time to work through it yet. Still learning Olly's traits and settings.

Does your v1.3 have it's exceptions within the 00400000 range, or does it leap off into a far address with the first or second F9/SHIFT+F9?

Regards,

[gabri3l]

JMI, I just checked and you are right 1.3a is the version I'm using as well. Though all my exceptions occur outside of the code section. all in the 00AXXXXX range.

Exceptions:
00A10671 <-- First exception
...25 exceptions later...
00A10019 <--Last exception

I set a breakpoint on: 00A10053: JMP Dword PTR SS:[EBP-14]
Step into the jump And begin my trace
I get the entry point: 0047ED5F

I'm using XP SP1 on my home comp and NT on my work comp both give me exceptions outside the programs address range. After pressing F9 to start the program I press Shift+F9 twenty six more times to end on the last instruction. That may drop you to the equivalent of the code in my first post.
In HAVOK's paper in codebreakers he talked about how ASPR would jump to your .code section and then jump right back out again to make it harder to find the OEP. But as the exceptions are occuring inside the code I'm lost. I'll read up on it and see if its mentioned anywhere.


But yes I was confused as to why i keep getting an already packed error. However i use stripper to dump it and it gave me the following

03:52:15 - asprotect detected..
Image Base :00400000
03:52:15 - dumping victim..
03:52:15 - processing import table..
ImportAddressTable RVA :000990f8 - kernel32.dll
ImportAddressTable RVA :00099378 - user32.dll
ImportAddressTable RVA :00099024 - gdi32.dll
ImportAddressTable RVA :00099000 - advapi32.dll
ImportAddressTable RVA :0009936c - shell32.dll
ImportAddressTable RVA :0009932c - msacm32.dll
ImportAddressTable RVA :000995cc - winmm.dll
ImportAddressTable RVA :000995bc - version.dll
03:52:16 - fixing import table..
ImportAddress RVA :00099224 - kernel32.dll!LockResource
ImportAddress RVA :00099234 - kernel32.dll!GetCurrentProcessId
ImportAddress RVA :00099258 - kernel32.dll!FreeResource
ImportAddress RVA :0009925c - kernel32.dll!GetModuleHandleA
ImportAddress RVA :00099284 - kernel32.dll!GetCurrentProcess
ImportAddress RVA :0009929c - kernel32.dll!GetVersion
ImportAddress RVA :000992f4 - kernel32.dll!GetCommandLineA
ImportAddress RVA :000993d0 - user32.dll!DialogBoxParamA
03:52:18 - no stolen bytes are found..
EntryPoint RVA :0007ed5f
03:52:18 - saving unpacked file..
03:52:18 - file was unpacked successful..
03:52:18 - done..

A perfect unpack... Now if I could only do that.

Just a thought: Maybe my problem lies not in my dump or my IAT but rather my resulting file structure. My unpack will run, but there may be garbage in there thats throwing both w32dasm and asprotect off. I'll try and study up on my PE structures tomorrow.

Hi,
I unpacked this last night without any problems except olly1.10c
kept crashing out so I had to revert back to 1.10b to unpack it successfully.
all exception were well outside the 00400000 range so I am not sure what going on with yours JMI.

I will run though it again tonight and post my notes

Best Wishes

R@dier

[JMI]

gabri3l:

Thanks for reminding me that it is ALWAYS a good idea to go back and read from the start of the thread. Had I done that, I would have discovered that you had reported Your "last exception" occurred with the routine between 00A60019-00A6005C. I had noticed then, that your code was nearly identical as that shown in the R@dier tut I described, except for the fact that his exceptions, as well as the ones I've seen in the few other ASPR targets I've tried in OllyDBG were clearly "outside" the range of the ".code" section shown in the Memory Map. R@dier's were in the range of 00D0XXXX, while, at least your last one, was in the range 00A60019-00A6005C.

Now you are confusing me by your statement that:

Exceptions:
00A10671 <-- First exception
...25 exceptions later...
00A10019 <--Last exception

There is an obvious difference between a last exception routine which starts at 00A60019 and one that starts at 00A10019 is there not?????
And my first exception was also at 00A10671. How did you lose 50000 bytes between what you first posted and today??????


In my version of the target, the Memory Map shows the .code section to begin at Address=00401000, with Size=00098000 (622592.) That suggests that any address within the range of 00401000 to 00499000 (which would include 00A60019-00A6005C and/or 00A10671 and 00A10019) where these exceptions are occurring is IN the code section shown in the Memory Map. I didn't hit any OUTSIDE that range and I have a file with the code addresses at each of the breaks on exception.

I am also running XP SP1 and I believe the same OllyDbg version R@dier just described reverting back to, although my "About" identifies it as OllyDbg v1.10(step 2), I believe that is version 1.10b.

I'm wondering if I have one of the settings wrong in Olly as I know I set several in attacking some of the other targets I finally had some time to play with, but I never got to the routine you posted in your first post, although I was watching for it.

I'm going to try your break point on 00A10053 and see if it breakes, because I'm not getting anywhere near. My last exception code is happening at:

00A111D3 58 POP EAX
00A111D4 33C0 XOR EAX,EAX
00A111D6 5A POP EDX
00A111D7 59 POP ECX
00A111D8 59 POP ECX
00A111D9 64:8910 MOV DWORD PTR FS:[EAX],EDX
00A111DC 68 0E12A100 PUSH 0A1120E
00A111E1 8D85 ACD7FFFF LEA EAX,DWORD PTR SS:[EBP-2854]
00A111E7 BA 02000000 MOV EDX,2
00A111EC E8 BF1FFFFF CALL 00A031B0
00A111F1 8D45 BC LEA EAX,DWORD PTR SS:[EBP-44]
00A111F4 E8 971FFFFF CALL 00A03190
00A111F9 8D45 C4 LEA EAX,DWORD PTR SS:[EBP-3C]
00A111FC BA 02000000 MOV EDX,2
00A11201 E8 AA1FFFFF CALL 00A031B0
00A11206 C3 RETN

which sure doesn't look correct and leads to the error message I posted below.

R@dier:

Will be happy to see your notes and would appreciate if you would include your setting in the Debugger options--->exceptions because that may be the problem here. I will be especially interested if the phrase "well outside the 00400000 range" really means something "outside" what is listed for the .code section, such something in the 00DXXXXX or 00CXXXXX perhaps. That would be very strange, and gabri3l confirms my findings that they appear to be within the .code section.

I've just retried the program in OllyDbg and after the first exception, I can scroll up and see the routine at 00A10019 and if I put a breakpoint there, or at 00A10053 I'm not reaching it and still get to the routine I posted, which starts at 00A111D3 and ends in the error message.

One small further intersting point. When I ran PEiD on the file it said the OEP was at 47CB16 (although I never got there in the code) while gabr3il found 0047ED5F. So I'm suspecting more and more it is something in my settings.

Regards,

[britedream]

Originally Posted by JMI

In my version of the target, the Memory Map shows the .code section to begin at Address=00401000, with Size=00098000 (622592.) That suggests that any address within the range of 00401000 to 00499000 (which would include 00A60019-00A6005C and/or 00A10671 and 00A10019) where these exceptions are occurring is IN the code section shown in the Memory Map. I didn't hit any OUTSIDE that range and I have a file with the code addresses at each of the breaks on exception.

1-The A6XXXX range willn't be in the code section range.

2- highmemory+0019 is the correct last exception, which is in my pc
=00A20019.

you can find that out by using my last updated script "asplex-2" for last exception.

Regards.

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

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.