ASPR 1.2 question
 

I've done the tutorials on Asprotect, and was excited when I found a program that i could apply the tutorials to. Using Olly and running the code until the last instruction before it starts I am presented with this code


00A60019 3100 XOR DWORD PTR DS:[EAX],EAX
00A6001B 64:8F05 00000000 POP DWORD PTR FS:[0]
00A60022 58 POP EAX
00A60023 833D D839A600 00 CMP DWORD PTR DS:[A639D8],0
00A6002A 74 14 JE SHORT 00A60040
00A6002C 6A 0C PUSH 0C
00A6002E B9 D839A600 MOV ECX,0A639D8
00A60033 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
00A60036 BA 04000000 MOV EDX,4
00A6003B E8 30C4FFFF CALL 00A5C470
00A60040 FF75 FC PUSH DWORD PTR SS:[EBP-4]
00A60043 FF75 F8 PUSH DWORD PTR SS:[EBP-8]
00A60046 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
00A60049 8338 00 CMP DWORD PTR DS:[EAX],0
00A6004C 74 02 JE SHORT 00A60050
00A6004E FF30 PUSH DWORD PTR DS:[EAX]
00A60050 FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00A60053 FF65 EC JMP DWORD PTR SS:[EBP-14] <--- THIS JUMP IS NOT IN ADDRESSED IN ANY TUTORIALS
00A60056 5F POP EDI
00A60057 5E POP ESI
00A60058 5B POP EBX
00A60059 8BE5 MOV ESP,EBP
00A6005B 5D POP EBP
00A6005C C3 RETN

Anyway i tried two ways, One i nop'ed the jump and traced which killed my prog and the other way i followed the jump which dropped me into the main thread and then i traced and found the OEP, Its is the same as the Entry point so I'm assuming there are no stolen bytes. Mind you i have not rebuilt the program successfully. I already unpacked it using asprstripper just for reference that my OEP was correct. So now I'm working on rebuilding the import tables now. even though

00A60056 5F POP EDI
00A60057 5E POP ESI
00A60058 5B POP EBX

Looks very suspicious in reference to everything i read on stolen bytes. I however put a breakpoint on them and ran the code and the program never ran that address? I'm just curious as to what the jump is for? when nothing i read ever mentioned it, They only said that there were two RET's that i had to execute before tracing.

gabri3l:

You need to review R@dier's tut, found here:

http://www.exetools.com/forum/showthread.php?t=3594

Now, if you look at the first graphic, you will find a section of code that looks remarkably like yours, except that it has an extra RETN where I indicate:

00A60019 3100 XOR DWORD PTR DS:[EAX],EAX
00A6001B 64:8F05 00000000 POP DWORD PTR FS:[0]
00A60022 58 POP EAX
00A60023 833D D839A600 00 CMP DWORD PTR DS:[A639D8],0
00A6002A 74 14 JE SHORT 00A60040
00A6002C 6A 0C PUSH 0C
00A6002E B9 D839A600 MOV ECX,0A639D8
00A60033 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
00A60036 BA 04000000 MOV EDX,4
00A6003B E8 30C4FFFF CALL 00A5C470
00A60040 FF75 FC PUSH DWORD PTR SS:[EBP-4]
00A60043 FF75 F8 PUSH DWORD PTR SS:[EBP-8]
00A60046 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C]
00A60049 8338 00 CMP DWORD PTR DS:[EAX],0
00A6004C 74 02 JE SHORT 00A60050
00A6004E FF30 PUSH DWORD PTR DS:[EAX]
00A60050 FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00A60053 FF65 EC JMP DWORD PTR SS:[EBP-14] <--- THIS JUMP IS NOT IN ADDRESSED IN ANY TUTORIALS
ADDRESS RETN <-----------------------
00A60056 5F POP EDI
00A60057 5E POP ESI
00A60058 5B POP EBX
00A60059 8BE5 MOV ESP,EBP
00A6005B 5D POP EBP
00A6005C C3 RETN

In R@dier's tut he says to mark the "last" RETN with F2 THEN hit Shift+F9, one more time, which takes you to the RETN.

THEN you are supposed to go to the Memory window [you can click the "M" button at the top of Olly or ALT M] and highlight the ".code" section of your target. Then Right Click and choose "Set Memory Breakpoint on Access." You then go back to the CPU window and hit CTRL+F11. You are now at the EIP, somewhere in the 00400000+ range. Here you should do a CTRL +A to "Analyse" code.

To determine how many stolen bytes you may need, also follow the tut and look in the stack window. Sitting at the EIP [after your CTRL+F11] you should have something which looks like:

ADDRESS $-FF25 18E36300 JMP DWORD PTR DS:[ADDRESS]

Now another R@dier reported trick (don't know who started this 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 did not remove the Analysis, you will probably have no entries or only one entry. If you did remove the Analysis, you will probably have one entry or two.

If you Double click on the last address [or the only one if Analysis Removed], it will open the CPU window again at that location. This may be kind of tricky, because if it's at an odd address, and if you scroll up, the view shifts to an even address. [In OllyDBG you can move the display up or down, one bit at a time by using the CTRL + up or down arrow.] Generally your Stolen Bytes go right above this address and you can count the number of total bytes which need to be placed there.

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 of the TRACE Window, 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. Look into the Command Window side, opposite the ESP, which is immediately above the highlited EBP.

Here you may need some basic understanding of start-up code for various compilers, but in general, the Stolen Bytes you need are "limited" by the amount of "empty" space available above the ADDRESS you found in the bottom call in the STACK Window [look at the example in R@dier's tut if this isn't clear]. It would be a good idea to start a file of "Stolen Byte" Sequences you see in the tuts and in your efforts and save them for use at this point, as described by R@dier.

Now in figuring out what the Stolen Bytes might be, you must remember that [at the moment] the last "stolen" instruction seems to usually be:

MOVE EAX, target,ADDRESS

This ADDRESS is generally to be found in "either" the EAX or EBX register, when the program first breaks in the EIP, after executing the proper number of SHIFT+F9's and the CTRL+F11 described in R@dier's tut.

So, knowing that your "last" Stolen Byte group is probably:

MOVE EAX, target,[the address shown in "either" EAX or EBX when break at EIP] or B8 ADDRESS [and remember the address is reversed, if the ADDRESS is 0063516C, it would be written in as B8 6C516300]. So this sequence takes 5 BYTES of the available space.

Since you did not identify your target, this is a general approach, not necessarily specific for the target you are working on, but it should be generally correct.

Regards,

Thank you for the response. I've been working on this for the past few days. And been getting a little turned around on it. I have made a dump that will load the program but my import table is all screwed up so any menu function etc... will crash the prog, I was using ImportREC to do the IAT but I think it may take a little more of a hands on approach because it just will not rebuild properly.

I have come to the conclusion that there are no stolen bytes. The trace confirms it as does ASPRstripper. (honestly, a little dissapointed i was hoping to work with stolen bytes when i saw the three pops) I suppose where you indicated a RET, since there are no stolen bytes I immediately JMP rather than returning and stealing bytes. I could not figure out why I was not hitting any returns after my last exception. And getting curious because none of my dumps seemed to work correctly. Thank you JMI for the help.

gabri3l:

Have you downloaded R@dier's tut I mentioned and tried to follow his directions on rebuilding the IAT? There are many tuts on the net descussing rebuilding the IAT. There are also several good reference which discuss some of the routines ASPR renames. One can use the patterns of some of these routines to determine the name of the API. Here is one list, which is contributed by hobferret, over on the Woodmann Forum, and LaBBA. They give patterns of some which get moved or confused. Remember addresses are dependent on which OS you are using. Here's that list.

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

LaBBa's tut: ASPR 1.23 Unpacking "Step-By-Step" has methods of resolving APIs with Olly. One thing to remember is that it would be unusual to find an API from a different DLL among listings for a particular DLL. By that, I mean, you won't see user32.dll listings in the middle of kernel32.dll.

One recent thread here described the process in this sequence:

11) Loaded Imprec v1.6f
12) Selected DVDIdle Pro as Active Process
13) Pressed IAT Auto Search
14) Pressed Get Imports (left all values at default)
15) Pressed Show Invalid
16) Right clicked on invalid and selected: Trace Level 1 (disasm)
17) Pressed Show Invalid again
18) Right clicked on invalid and selected: Plugin Tracers-> aspr2

You can find the aspr2 tracer here:

http://www.exetools.com/forum/showthread.php?t=3594&page=2

If you post your target, I may have time to take a look to confirm your information.

Regards,

The program is sagebrush's recallpro v1.3. Its an interesting program, in version 1.2 if you were running XP it had a bug that would delete your license information from the registry when you closed it. It just took a quick NOP to the call and it worked perfectly after that. Well it turns out that they still didn't fix the problem for version 1.3. Though they did decide to start packing it. I was finally able to get the IAT to work. The R@ider tut helped me out. I had ollydump rebuilding the Imports by default. One thing that had me confused was in labbas, r@diers, and MrBarby's tutorial they all say to increase the size when using Imprecf. I was getting frustrated because I was finding a lot of imports to fix. and a good amount of them were ADD [EAX], AL. By keeping the size about the same and Using both the ASPR2 tracer (Thank you by the way) and the 1.2 tracer I was able to get a working IAT. I know I must have done something incorrectly because when i try and repack it ASprotect says that it is already packed. and i get a message in w32dasm about pe file not in windows format but it runs! and I can debug it now and get rid of that registry call.

just a quick question for reference, when looking at what imports are in my range i look at the ptr:xxxxxxxxx and make sure that that is in my program range? And when fixing them since it will only run on my system, can you (iN theory), dump it again and rebuld the import table to give you the correct calls?

While searching for references while working on this I was able to compile a lot of tuts on using Softice and a few on revirgin for ASPR. So I think I'll give this another try using those tools now knowing that I can actually do it. I really appreciate the help. Thank you JMI

I've attached my Imprec plugins folder. In addition to excellent tutorials by LaBBA, R@dier :) you may also refer another excellent tutorial by Britedream :) on Stolen bytes.

http://grinders.withernsea.com/tutorials/britedream.rar

Regards,
ferrari :)

A solid recommendation, as I believe Britedream was the ultimate source of much of the unpacking information I have reported here. I've downloaded your target, and, time permitting, will take a quick look at the unpacking issues. May I recommend that you not only read the tuts you've downloaded, but that you start making your own set of compiled notes on features of various versions of your protector targets.

For example, you could start collecting the patterns of stolen bytes reported and discovered. You could start recording patterns of code found at or around the stolen bytes. You could start studying, from the trace, the patterns from the ASPR DLL. For example the Huge loop at the start of the program which is followed by another loop which seems to match the number of times you passed an exception with F9 and/or SHIFT+F9; that your OEP is probably sitting naked in the trace, if you only know where to look and that it probably is listed in the trace in a PUSH DWORD PTR DS:[ADDRESS] instruction a couple of instructions above the PUSHAD and PUSHFD which occur shortly before the REP STOS BYTE PTR ES:[EDI] routine to erase all the code that got you there in the first place. In other words, the run trace is worth close study because it is the track of ASPR's unfolding of the path to the OEP.

Understanding what it's doing will help with the next target and you might note the differences you discover in the general pattern. In this effort it really helps to remove all the loop code repeats, simply noting the registers going into the start of the loop and coming out.

Once you get comfortable with the unpacking, you then have to move on to the issue of whether or not their is additional code in the target which has to be changed to make it actually run fully. But for the first step, you just want to master manual unpacking and then worry about the next phase.

ferrari: I've downloaded Britedream's tut both here and from somewhere else and, for some reason, I'm not seeing the illustrations. Yours has the first two only, and the other one I downloaded didn't have any. Maybe I'm just using the wrong file to open it. It's opening in Word and it's time to try something else.

Regards,

I dowloaded the file(.doc in word XP) to check and I'm able to see all the "9" illustrations. If you still got any problems then tell me. I've extracted all the images and I'll upload the file for you if needed, otherwise I might unnecessarily increase Aaron's database ;)

Regards,
ferrari :)

Thanks for the offer ferrari, but for some reason which I can't explain at the moment, it is suddenly working. The first several times I opened it, there was only the graphics on the first page. Now, if I wait awhile, they slowly appear on the other pages as well.

Be careful of road rash out there and remember that the Diety gave you only one set of family jewels and did not intend that you use them to smash into handrails and other such solid metal objects. :D

Regards,

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.

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,

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

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,

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.

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,

VCD cutter v4.1.3
It's a single "Exe" with no setup required. I see no warning when I run it on XP. Even though My "Driver Signing option" in Mycomputer-->properties-->Hardware is enabled.
One strange finding. When I unpacked it I get that "Warning" and the program will not run(possible wrong unpacking).

Regards,

ferrari:

You are correct it is a single "exe" with no setup. :eek: Being in a hurry to check the last exception routine, I didn't pay any attention to what my eyes observed and simply clicked on it to "install" and got the warning.

But, that temporary insanity aside, I did run the exe in OllyDbg and found it's last exception routine, which certainly appears to indicate my speculation of an easy difference between the last exception routines of those with and those without stolen bytes is not the case.

VCD Cutter's last exception routine ends as do the other routines with stolen bytes:

00B32D08 FF75 F0 PUSH DWORD PTR SS:[EBP-10]
00B32D0B FF75 EC PUSH DWORD PTR SS:[EBP-14]
00B32D0E C3 RETN

so there must be some other reason for RecAllPro's last exception ending 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


Thanks for the quick reply with a target to check.

Regards,

vcd...
 

you will run into some anti-dump checks with that version after unpacking including a Getfilesize call but something more of a problem a bit later that causes it to crash, couldn't nail it with olly on win2000 and don't have softice option :( plus it doesn't run on win98se so I got bored.

you sure?, the 4.1.3 version I d/l a couple of days ago had no stolen bytes just the old style jmp eax to oep.

Hi Jay:

You simply misunderstood my comment. I was previously speculating on the "code" in the last exception routine.

RecAllPro was the only target I had tried which had NO stolen bytes and the "code" in its last exception routine had a

"00A10053 FF65 EC JMP DWORD PTR SS:[EBP-14],"

whereas, all the last exception routines I had seen or read in tuts seemed to have:

00B32D0B FF75 EC PUSH DWORD PTR SS:[EBP-14]

Clearly VCD Cutter has NO stolen bytes. That was a given, because it was the reason ferrari referred me to check it out.

So the phrase you quoted simply means that the routine in VCD Cutter, which has NO stolen bytes, ends with the same code as does the last exception code of targets which DO have stolen bytes.

The "stolen bytes" themselves, if they have been stolen, are not in this part of the ASPR code and are found in the section of the code which is later erased by:

MOV EDI,Starting Address of Code to be erased
MOV ECX,Number of Bytes to erase
REP STOS BYTE PTR ES:[EDI]

and would be found in the target's original "packed" code, such as this sample, from a different target:

00D3782F 55 PUSH EBP <---STOLEN BYTES
00D37830 8BEC MOV EBP,ESP <---STOLEN BYTES
00D37832 81EC 10000000 SUB ESP,10 <---STOLEN BYTES
00D37838 F2: PREFIX REPNE:
00D37839 EB 02 JMP SHORT 00D3783D
00D3783B CD 20 INT 20
00D3783D F2: PREFIX REPNE:
00D3783E EB 01 JMP SHORT 00D37841
00D37840 9A 83EC1C83 C418 CALL FAR 18C4:831CEC83
00D37841 83EC 1C SUB ESP,1C
00D37844 83C4 18 ADD ESP,18
00D37847 26:EB 02 JMP SHORT 00D3784C
00D3784A CD 20 INT 20
00D3784C 53 PUSH EBX <---STOLEN BYTES

plus the usual final addition of a MOV EAX, OEP.

Hope I made it more clear this time.

Regards,

I'm glad you noticed the same thing I did JMI. Why is that jump there? I know this program has a CRC check, do you suppose that is part of the routine. A theory that I have not yet explored. I haven't had too much time to step through this in the past few days. But I am hoping to make some time today. I will let you know if i find anything.

This may be stating the obvious, but here goes...

A "PUSH $address" followed by a RETN is functionally identical to "JMP $address". The instructions are different, but they accomplish the exact same thing, since RETN basically just does what can be thought of as "POP EIP".

If the purpose of examing the difference between the two was to try to find a pattern of some sort (i.e. the PUSH, RETN is there when there are stolen bytes, the JMP is there when there aren't), then my comment has no relevance.

But, since it appears there is no such pattern (as evidenced by the fact that the VCD app has the PUSH, RETN), the difference between the two seems irrelevant to me. Maybe ASPR just generates one or the other randomly, to try to confuse people? ;)

Regards,
Satyric0n

Hey Satyric0n:

Just because something is "obvious" doesn't mean one actually managed to "observe" it. :eek: This is at least the second time in this thread that I've been so intent on what I "thought" I was doing, I did not actually notice what was right in front of me. :D

What you said is "obviously" true, but I was so intent on "looking" for a "pattern," I completely failed to "think" about "what" the code was doing. Well Duh! Since it was the ONLY one I had ever seen like that, I was mesmerized by the possibility of discovering an identifying pattern. You know, immortality, name in lights, ticker tape parades, and all that :rolleyes: :)

Thanks for throwing that bucket of cold water on my head to wake me up. :eek: Maybe a good slap will get me to focus.

Regards and thanks. :)

And it seemed to have worked. :) I believe you may be correct. If there is a pattern then it is not very evident. I just thought it odd when this jump shows up after all the other ASPR programs i tried had returns. If someone happens to see it again in another program let me know because I still find it interesting.

Seems we needed a extra voice of reason to get us focused again. :D

just small note:
all protected targets with stolen ;acprotect,svkp,asprotect.... , the stolen bytes are excuted inside the protector by emulating it-most of the time-, and then some times erased, before it jumps to the codes in the code section.

I did run it without unpacking it and got the warning, so it must be your system.