hi.. like i saied this is the OllyDbg tut about how to
unpack aspr 1.3x

if anyone can find in olly a better way to find the stolen bytes
plz post here...

Not bad

I like your use of the trace/run trace feature, but do note that different versions of asprotect have a different amount of exceptions. It's safe to do multi-pass - in the first you find how many exceptions there are and in the second you can just do one less.

Other than that, It seems quite an informative tut, although I must admit to only read like ever 3rd word or so

yea i know that but as i saied .. the last one is alwes with the same writing ..
Xor
jmp
pop

etc...

Hi, Labbas!

Actually, the very last one, will not have a "eb 01" after the xor-thingie...

I'm guessing it was a typo?

NICE tut regardless!

Maybe you even taught Squidge a new trick? ;P

/Manko

He did indeed

I never thought about using the tracer built into Olly for unpacking AsProtect apps, but the again I just prefer writing my own app instead of learning how to use someone elses

well the hole command line of Olly is wierd !
i first tried to write like this :

TC IF(EIP>400000&&EIP<900000)

but it didn't work !

the hole command line method of Olly should change like that TRW2000 done.. they know that ppl are regular to SoftIce and they make it as easy as possible for ppl and show a more nice example with a BP command(in TrW2000 BP is also a trace command)

so plz .. if some one could make the Olly Command line more user friendly , it will be great !

LaBBa,

This is a nice tutorial! It's nice to find all the bits and pieces of unpacking asprotect in one neat package. The explanation of the stolen bytes was very well done!

On step 2, OllyDbg is breaking because of a memory access violation, not because it's loading a new module.

You didn't mention the three entries in the IAT that point to aspr functions. These need to be manually traced in the original program.

btw, a newer version is on their web site. (perhaps this is why you didn't mention those functions; they weren't in the old version?)

oh, I do have a recommendation for finding the stolen bytes! Set a trace condition where the command matches "REP STOS BYTE PTR ES:[EDI]" (use this instead of the eip<900000 condition). This will get you the missing bytes and also the OEP (just continue tracing a little further!)

btw, you can set trace conditions via the GUI instead of using the command line plugin. It's more user-friendly.

xybyer :
well u seem to have more expriance with aspr in olly then i do
so plz .. if u or anyone else that have spare time plz do a tut with more explanation that i (lame me) did..

don't think for a moment that i know how to use Olly !
i just wanted to lern how to use Olly so i just writed a tut about
my lerning about unpacking in Olly...
i'm kinda New at this Olly thingy...

A few random observations from my own adventures with Ollydbg on this project. First, thanks to LaBBa for getting me interested enough in his tutorial that I finally installed Ollydbg and tried it on this target. I do note a few points which seem to differ with his tut, but do not know whether they may be the result of the fact that he appears to be using XP and I am using Win2kSP3.

First a comment on xybyre suggestion to use "REP STOS BYTE PTR ES:[EDI]" as the trace condition. I tried using this condition and after more than 1 hour on my 2.5 ghz P4, it was still "tracing" and hadn't reached the "rep stos" point yet. Was much faster to use the EIP<900000.

Having reached that point and noted that EAX was 57e318, I decided to start the program and Olly again and this time trace until "EAX==0057e318". Again, this was very quick and it disclosed the code immediately below the:

012C532C 60 PUSHAD <--- Returns to here
012C532D 9C PUSHFD
012C532E FC CLD
012C532F BF 42532C01 MOV EDI,12C5342
012C5334 B9 53010000 MOV ECX,153
012C5339 F3:AA REP STOS BYTE PTR ES:[EDI]
012C533B 9D POPFD
012C533C 61 POPAD
012C533D -E9 19972BFF JMP 0057EA5B

which was erased by the REP STOS BYTE PTR ES:[EDI]. That code is:

012C5342 03C3 ADD EAX,EBX
012C5344 BB 0B000000 MOV EBX,0B
012C5349 0BDB OR EBX,EBX
012C534B 75 02 JNZ SHORT 012C534F
012C534D 50 PUSH EAX
012C534E C3 RETN
012C534F E8 00000000 CALL 012C5354
012C5354 5D POP EBP
012C5355 81ED E27F4900 SUB EBP,497FE2
012C535B 8D8D D07F4900 LEA ECX,DWORD PTR SS:[EBP+497FD0]
012C5361 2BC1 SUB EAX,ECX
012C5363 8985 CC7F4900 MOV DWORD PTR SS:[EBP+497FCC],EAX
012C5369 8D85 BA7F4900 LEA EAX,DWORD PTR SS:[EBP+497FBA]
012C536F 8D8D 23804900 LEA ECX,DWORD PTR SS:[EBP+498023]
012C5375 03CB ADD ECX,EBX
012C5377 8941 01 MOV DWORD PTR DS:[ECX+1],EAX
012C537A 8D85 D07F4900 LEA EAX,DWORD PTR SS:[EBP+497FD0]
012C5380 8D8D BE7F4900 LEA ECX,DWORD PTR SS:[EBP+497FBE]
012C5386 8901 MOV DWORD PTR DS:[ECX],EAX
012C5388 B8 53010000 MOV EAX,153
012C538D 8D8D C37F4900 LEA ECX,DWORD PTR SS:[EBP+497FC3]
012C5393 8901 MOV DWORD PTR DS:[ECX],EAX
012C5395 55 PUSH EBP
012C5396 8BEC MOV EBP,ESP
012C5398 83C4 F0 ADD ESP,-10
012C539B B8 18E35700 MOV EAX,57E318 <------
012C53A0 68 2C532C01 PUSH 12C532C
012C53A5 C3 RETN

You will notice that the third instruction from the bottom is the one that puts "57e318" into EAX, then pushes the address of the PUSHAD above, and returns. It then erases this subroutine.

I also noted a difference on the "stolen bytes" from what LaBBa reported, and again I don't know if this is a result of my OS. Using the search for "PUSH EBX, PUSH ESI, PUSH EDI" I arrived at:

012C8989 51 PUSH ECX
012C898A 51 PUSH ECX
012C898B 83EC 10 SUB ESP,10
012C898E 53 PUSH EBX
012C898F 56 PUSH ESI
012C8990 57 PUSH EDI
012C8991 64:A1 18000000 MOV EAX,DWORD PTR FS:[18]

While LaBBa reported his "stolen bytes" as "55,8b,ec,83,ec,54" + the MOV EAX 57e318 (or "b8 18 e3 57 00", mine appear to be as shown above plus the MOV EAX 57e318. If anyone has an explaination, I would be interested. I am still studying the program to see if it will search again after finding the first instance of the search criteria. For those of you who might not know, because you didn't bother to search, there is an Ollydbg forum where there is alot of information on how to make the program work. I'm busy reading my way through when I have some spare time for playing.

Regards.

i was wrong u ARE RIGHT !!

GooD JOB !

Next Time Write a tut for us

JMI,

hmm... that's odd. I just tried it again, and it takes 7 minutes on my P3 1.13 Ghz laptop (512 MB RAM, running in the background while I'm reading this forum). Did you bypass the two loops after the final exception (as described in the tut)?

Tight loops make a big difference when tracing. When it takes too long, you can pause the program (F12) and step through the code to make sure it's not in a loop. If it's in a loop, just run past the end of the loop (F4 on the next instruction) and continue tracing (alt-F11). This can speed up tracing when you are impatient.

I installed v 4.89 build 112. I wonder if that's making a difference? The stolen bytes for this version are different as well.

LaBBa,

Please don't get defensive because of our comments/suggestions. You wrote a very good tutorial, and we were only trying to point out some things you could change to make it better. It takes a lot of knowledge, time, and effort to write a tutorial, so we greatly appreciate your contribution.

xybyre:

I don't think LaBBa was being defensive, note the smilie face. I certainly wasn't criticising his work because I wasn't sure whether or not the difference in the "stolen bytes" was the result of the different OS used or not. I don't see how he could have extracted the code he shows in the tut and it be "incorrect" unless there are more than one place where the "PUSH EBX, PUSH ESI, PUSH EDI" appears. I don't yet know how to do a "search again" in Ollydbg or whether or not it is even possible.

It is possible that I was too quick when I reloaded the target and reset Ollydbg before I tried the trace with "REP STOS BYTE PTR ES:[EDI]". I'll check it again when I have time. Also I used the Command-line rather than the GUI condition trace, and that might make the difference. For me the program "never" stopped "tracing" before I simply stopped after about an hour, but as I stated, this is my own first attempts with Ollydbg and I'm still "learning the ropes."

I was working with v 4.89 build 110, like LaBBA, but have downloaded build 112 for "testing" later, when time permits.
By the way, using Imprec 4.2+ I got 27 "unresolved" API's, many fewer than with the older version LaBBa used, which is available by SEARCHING the net.

Regards.

When I searched for "PUSH EBX, PUSH ESI, PUSH EDI", I got many matches (you can press "ctrl-L" to search again). I'm not sure if it's possible to retrieve the stolen bytes that way, though. Aren't they written only once, executed, and then overwritten? If so, then a search through memory after reaching OEP wouldn't find them. Then again, I'm not too familiar with this protection, so I'm probably wrong.

There are two options for tracing via the GUI: "trace into" and "trace over". I believe the "TC" command does a "trace into", since "trace over" would skip over all function calls.

I used Revirgin 1.5.1 to rebuild the imports. It got everything except for GetModuleHandleA (if I remember correctly) and those other three you have to manually trace.

Hey!

Nice tutorial LaBBa.
It misses some more explainations though.
you say for example to use : TC EIP < 900000 or something
but you don't explain why.

A newbie might want to know why you selected this command and why it works. I think the idea is to teach them how it works, and so, they will be able to make such nice tutorials themselves a bit later.

Just beeing critical, and its not meant to be harsh.
But for you other tutorials, please add more explainatations on why you do / try things so the others will be able to think the good way, when they encounter a new protector.

Thanks for making tutorials on olly though

HopCode!

On further reflection:

After reading xybyre's reply and now knowing how to search again (Ctrl+L; and it helps to read the Quick Start list of "menu functions" before one starts, Duh!) I also found many instances containing the "PUSH EBX, PUSH ESI, PUSH EDI" series. I believe the problem was in the assumption, taken from LaBBa's Tut, that this string would indicate one of the forms of "stolen bytes" described as his "way" number 2, which was described as:
Stolen+Bytes_1
Stolen+Bytes_2
Stolen+Bytes_3
PUSH EBX
PUSH ESI
PUSH EDI
. . . .
. . . .
. . . .
REPZ STOSB
POPFD
POPAD
JMP_TO_OEP

Based upon the code that was contained in the subroutine erased by the "REPZ STOSB" target, this appears to be an incorrect assumption. Most of the instances of "PUSH EBX, PUSH ESI, PUSH EDI" in this target appear to be connected to API's, if one looks a little further down in the code below them.

I believe the "Stolen_Bytes" are contained in the bottom section of the subroutine which is erased by the "REPZ STOSB" and, interestingly, LaBBa had this information correctly identified for his discussion of an earlier version of this target, found in http://www.woodmann.net/forum/showthread.php?threadid=4576

There he reported, for v4.88 build 106, that:

in ASPR Striper XP 1.25 it says :
"Found 0bh stolen bytes"

i found also 0bh stolen bytes...

55,8b --- 2
ec,83,c4,f0 --- 4
b8,8c,bd,57,00 --- 5
-----------------------------------
total == 11 == 0Bh
. . . . . . . . . . . . . . . . .

You will notice that his first 6 bytes are:
55 PUSH EBP
8BEC MOV EBP,ESP
83C4 F0 ADD ESP,-10

Followed by the address "Moved" into EAX:

b8 8cbd5700 MOV EAX 0057bd8c

For v 4.89 build 110, only the address "Moved" into EAX changed to 57E318, so the instruction changes to:

B8 18E35700

[remember the address is shown in the hex listing (and in the hex editor) "reversed" byte by byte.
0057E318 is in the file as "18E35700"]

Put these together and you get:

55 PUSH EBP
8BEC MOV EBP,ESP
83C4 F0 ADD ESP,-10
B8 18E35700 MOV EAX 0057e318

Which just happens to be the code I found by tracing until EAX==57e318, shown above in my prior post as:

012C5395 55 PUSH EBP
012C5396 8BEC MOV EBP,ESP
012C5398 83C4 F0 ADD ESP,-10
012C539B B8 18E35700 MOV EAX,57E318 <------

So I believe that these are the correct "stolen_bytes", which when put with the POPFD, POPAD, JMP_to_OEP becomes:

55 PUSH EBP
8BEC MOV EBP,ESP
83C4 F0 ADD ESP,-10
B8 18E35700 MOV EAX 0057e318
9D POPFD
61 POPAD
-E9 19972BFF JMP 0057EA5B

We appear to have a "convenient" hole in the file, of 11 bytes (B hex) before address 57EA5B in which to put "55,8B,EC,83,C4,F0,B8,18,E3,57,00" and then, as LaBBa says, we have to adjust the OEP back these 11 (B hex) bytes to
57EA50 and our "stolen_bytes" should be back in place.

Tomorrow, I'll check the build 112, to see if the "stolen_bytes" are the same and whether the MOV EAX address and OEP are changed again, which I suspect will be true.

So, again, the technique for finding these "stolen_bytes" is to follow LaBBa's steps to get to the OEP and write down the address shown in EAX (in this case 0057E318). Then close the target and Ollydbg, restart the target, restart Ollydbg, follow LaBBa's steps to the end, except, instead of tracing to EIP<900000 (which is a search for code outside of the usual range of the ASPR wrapper, use EAX==[value_found_in_EAX], which in this build was 0057E318.

This will give you the "erased" code section shown in my prior post here (at least for this build) and should give you the code until this procedure of hiding the stolen_bytes is changed.

Regards.