I've just taken another look at the latest version of one of my rarely used proggies now it's increased by a few versions, and found that PEID states its now protected with the above.

Strange thing is, it has the "Debugger detected, please remove" blah blah etc, so it's clearly a new version, but I found it much easier to unpack than the old version?!

Loaded the program into Ollydbg, patched the byte in FS to avoid debugger detection, told Olly to ignore certain exceptions and let the program run as normal. Finding nothing fancy there, I told Olly to pause the program, and then dumped it to disk. Not wanting to trace through the code looking for the iat and oep, I just looked for a IAT signature, zeroed the obvious bogus entries in between the iat thunks, and imprec fixed it with no problems. Found the OEP within 5 minutes using IDA (by looking for a code sequence). Fixed OEP and it ran.

Now, I never found any stolen oep bytes, but the program runs the same as the packed one, which I find strange. I expected to at least replace the bytes by the normal ones found in the compiler startup stub. In the old version of the program, there was both bytes missing and multiple dips into the code from aspr itself before oep. Now there seems to be nothing?!

Anyone else played with this version of ASPR?

Hi Squidge

What rarely used program are you talking about??

/hobferret

Well, I prefer not to state the name of the target unless someone asks, but since your asking

[Edit by JMI: Name of Target deleted because of following post with target specific code. Bother Squide or LaBBA by PM if you want it, not because Squidge did something specifically wrong, but because of what Labba did which follows.]

well i saw that its kinda nice..

in my way of finding the OEP by setting an TC i got to here :

0040C5D2 |. 74 2B JE SHORT 0040C5FF
0040C5D4 |. 8038 5C CMP BYTE PTR DS:[EAX],5C
0040C5D7 |. 75 02 JNZ SHORT 0040C5DB
0040C5D9 |. 40 INC EAX
0040C5DA |. C3 RETN

so i traced and after the RET i got to here :

0040C79D |. 53 PUSH EBX ; /pHandle
0040C79E |. 6A 01 PUSH 1 ; |Access = KEY_QUERY_VALUE
0040C7A0 |. 6A 00 PUSH 0 ; |Reserved = 0
0040C7A2 |. 50 PUSH EAX ; |Subkey
0040C7A3 |. 68 01000080 PUSH 80000001 ; |hKey = HKEY_CURRENT_USER
0040C7A8 |. 2E:FF15 000241>CALL DWORD PTR CS:[410200] ; \RegOpenKeyExA
0040C7AF |. 89C3 MOV EBX,EAX
0040C7B1 |. 85C0 TEST EAX,EAX
0040C7B3 |. 74 10 JE SHORT 0040C7C5
0040C7B5 |. 85DB TEST EBX,EBX
0040C7B7 |. 75 47 JNZ SHORT 0040C800
0040C7B9 |. B8 01000000 MOV EAX,1
0040C7BE |. 83C4 08 ADD ESP,8
0040C7C1 |. 5F POP EDI
0040C7C2 |. 5E POP ESI
0040C7C3 |. 59 POP ECX
0040C7C4 |. C3 RETN
0040C7C5 |> 8D4424 04 LEA EAX,DWORD PTR SS:[ESP+4]
0040C7C9 |. 50 PUSH EAX ; /pBufSize
0040C7CA |. 56 PUSH ESI ; |Buffer
0040C7CB |. 53 PUSH EBX ; |pValueType
0040C7CC |. 53 PUSH EBX ; |Reserved
0040C7CD |. 57 PUSH EDI ; |ValueName
0040C7CE |. 8B4C24 14 MOV ECX,DWORD PTR SS:[ESP+14] ; |
0040C7D2 |. BA 04000000 MOV EDX,4 ; |
0040C7D7 |. 51 PUSH ECX ; |hKey
0040C7D8 |. 895424 1C MOV DWORD PTR SS:[ESP+1C],EDX ; |
0040C7DC |. 2E:FF15 040241>CALL DWORD PTR CS:[410204] ; \RegQueryValueExA
0040C7E3 |. 8B3424 MOV ESI,DWORD PTR SS:[ESP]
0040C7E6 |. 56 PUSH ESI ; /hKey
0040C7E7 |. 89C3 MOV EBX,EAX ; |
0040C7E9 |. 2E:FF15 F40141>CALL DWORD PTR CS:[4101F4] ; \RegCloseKey
0040C7F0 |. 85DB TEST EBX,EBX
0040C7F2 |. 75 0C JNZ SHORT 0040C800
0040C7F4 |. B8 01000000 MOV EAX,1
0040C7F9 |. 83C4 08 ADD ESP,8
0040C7FC |. 5F POP EDI
0040C7FD |. 5E POP ESI
0040C7FE |. 59 POP ECX
0040C7FF |. C3 RETN


again i traced after the RET i got to here :

0040733C 00 DB 00
0040733D 00 DB 00
0040733E 00 DB 00
0040733F 00 DB 00
00407340 00 DB 00
00407341 00 DB 00
00407342 00 DB 00
00407343 00 DB 00
00407344 00 DB 00
00407345 00 DB 00
00407346 00 DB 00
00407347 00 DB 00
00407348 00 DB 00
00407349 00 DB 00
0040734A 00 DB 00
0040734B 00 DB 00
0040734C 00 DB 00
0040734D . E8 3A540000 CALL 0040C78C
00407352 . 85C0 TEST EAX,EAX
00407354 . 0F84 9F000000 JE 004073F9
0040735A > 6A 00 PUSH 0

i got to : 00407352 . 85C0 TEST EAX,EAX
but if u scroll up u will see where is all the missing bytes should be ..

so the REAL OEP should be at : 0040733C

now we can see that we have : 17 stolen bytes ..

where are the stolen bytes ?? well in this board it was already spoken about ..
u can reload the Olly and instad of putting an TC command we can set a trace on a command :
REP STOS BYTE PTR ES:[EDI]

this command clears the stolen bytes before it make the jump to the fake OEP

by pressing Ctrl+T (in menu its : Debug->Set Condition)
there is and options : "Command is one of"

and then after pressing ok we need to press Ctrl+F11 to start tracing .. we will stop at more then 1 place that has this commad but we need this kind of structure :

009D575B F3:AA REP STOS BYTE PTR ES:[EDI]
009D575D 9D POPFD
009D575E 5F POP EDI
009D575F 59 POP ECX
009D5760 C3 RETN

now.. if u will look at the : "Run Trace" window u could see :

009D5C9F 68 D2C54000 PUSH 40C5D2
009D5CA4 68 4A579D00 PUSH 9D574A
009D5CA9 C3 RETN
009D574A EB 01 JMP SHORT 009D574D
009D574D 51 PUSH ECX
009D574E 57 PUSH EDI
009D574F 9C PUSHFD
009D5750 FC CLD
009D5751 BF 8E579D00 MOV EDI,9D578E
009D5756 B9 5E140000 MOV ECX,145E
009D575B F3:AA REP STOS BYTE PTR ES:[EDI]
009D575D 9D POPFD
009D575E 5F POP EDI
009D575F 59 POP ECX
009D5760 C3 RETN

those two line :
009D5C9F 68 D2C54000 PUSH 40C5D2 <-- The Fake OEP
009D5CA4 68 4A579D00 PUSH 9D574A<-- To return to clears the bytes
009D5CA9 C3 RETN

all the code that is responsible for excuting/emulating the real Stolen Bytes is attached to this post

all that i know about those lil thing is this :

when u see :
MOV DWORD PTR SS:[ESP+4],EAX

it's realy like : PUSH EAX
i'm sure that there are alot of other things like so .. but didn't have time to take a deeper look.. (no time..)

hope that some one will continue this ..

Best Regards , LaBBa

Labba:

You have violated the rules against posting target specifically identified code. It was problem enough when Squidge posted the name of the program in his response to hobferret, but he posted no code at all and only described a generic issue with a possible new version of the protector.

You, however, not only posted target specific code, you also left it laced with the actual name of the program within your posted code snippet. This was a clear violation of our rules here and COMPLETELY UNNECESSARY. I have edited both your and Squidge's posts to remove all references to the name of the target.

Your presentation of the material would have been just as informative an explaination of the tracing process WITHOUT including the name of the target in front of each of your "jump" instructions. Without the target specific information, it serves as a generic approach to the protection, rather than a step by step method of "cracking" this particular software.

This is EXACTLY the type of posting that draws complaints to our host about our Forum and threatens our continued existence. We simply can not tolerate these types of problems. You know better. Make sure that you follow this rule in the future so we do not have to take any other action.

Regards.

hmm ..

well .. we always do post here parts of codes .. it's strange to me that as u say "broken the rules" ..

i know that posting a way of how To Crack and app is not ok .. but posting parts of code that only talking about how to Unpack the APP and not Cracking it ... i don't see anything wrong with it ..

but if u say that we need not to do this then ok .. this won't happen again..


best regards , LaBBa .

Strange, the OEP is obtained using IDA Pro on the target was 4073F9, but the program works just as well as the packed version. However, looking at the 33C address, I see the 17 stolen bytes, so obviously these bytes are not critical in this application, but they are stolen by the protector.

Aha, I see the difference now. In the packed version, they setup a timer and disable the "Start" button, and this is done in the original OEP. In the OEP I found using IDA, this timer is not setup, so the buttons are enabled instantly.

Ah well, I prefer it this way

Still wondering why they are using "RC4 Demo" though, surely a demo is something that is not registered?!

My continuing theory is that, although most seem to freak out about stolen bytes,....they are not necessary at all. It's a worthless trick because most programs will run without those bytes anyway.

Basically, it's a feature that should have gotten more testing as to its effectiveness. Hi Alexy

-nt20

Greetings!
Forget about the stolen bytes and tell me about the call at 40734d
that has been bypassed and nothing happened??

LaBBA:

Since you did not seem to get the point of my message, I'll try one more time. The issue is not that you posted CODE. You notice that I did not delete your post, which still contails CODE. The POINT is that it no longer identifies a specific TARGET, which is commercial software.

Squidge stated that the "unpacked" TARGET runs fine and gave generic instructions for fixing the IAT and bypassing some of the protections tricks. Therefore, with THIS TARGET, unpacking and finding the "real" OEP equals essentially removing the protection and having an operating commercial TARGET.

With the NAME of the TARGET and Squidge's statements, anyone would have had an almost cookie-cutter method of circumventing the protection on that specific TARGET by unpacking it using the steps you outlined. That is what we want to avoid.

It is the simple difference between stating "here is what this version of the PROTECTOR is doing with stolen bytes," which doesn't identify ANY TARGET and "you can follow these steps and you will get to the REAL OEP of THIS TARGET." One focuses on the "methods" of the protector and the other appears to focus on the "TARGET."

Generic analysis of protection systems does not seem to draw attacks made to our host and TARGET SPECIFIC CODE DOES. It's that simple.

If you identify a specific TARGET, you should not post code that will allow someone else to make that TARGET operate without the protector. If you want to identify a version of the protector and describe what the code is doing, anyone wishing to apply that method to a commercial TARGET still has to determine that the TARGET uses that version of the protector and apply the generic approach themselves. There is a difference and I hope you see it now.

Regards,

Niko,

I usually find in Aspr'd proggies that the original program was compiled with MSVC++ or other such compiler, and so the first bytes that are stolen are part of the compiler stub that is the same on every compiled app anyway, so just replace those bytes and see if it works, rather than run around trying to find them. This seems to work in at least 90% of cases. In other cases, you find the stolen bytes equal to not much more than "GetModuleHandleA" and a bit of error checking

hello everybody,

i am examine a aspro protected app. peid identifies it as "ASprotect 1.23 RC4 Demo", so i assume iam in the right thread )

Iam trying to recover the stolen bytes and got really frustrated, because none on the known technics lead me to the right spot.

heres a trace :

004E7E64 0000 ADD BYTE PTR DS:[EAX],AL
004E7E66 0000 ADD BYTE PTR DS:[EAX],AL
004E7E68 0000 ADD BYTE PTR DS:[EAX],AL
004E7E6A 0000 ADD BYTE PTR DS:[EAX],AL
004E7E6C 0000 ADD BYTE PTR DS:[EAX],AL
004E7E6E 0000 ADD BYTE PTR DS:[EAX],AL
004E7E70 E8 F3EBF1FF CALL xxxx.00406A68
...

00406A68 53 PUSH EBX
00406A69 8BD8 MOV EBX,EAX
00406A6B 33C0 XOR EAX,EAX
00406A6D A3 10274F00 MOV DWORD PTR DS:[4F2710],EAX
00406A72 6A 00 PUSH 0
00406A74 E8 2BFFFFFF CALL xxxx.004069A4

...

004069A4 -FF25 B0424F00 JMP DWORD PTR DS:[4F42B0]

...

00DD1C64 55 PUSH EBP
00DD1C65 8BEC MOV EBP,ESP
00DD1C67 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
00DD1C6A 85C0 TEST EAX,EAX
00DD1C6C 75 13 JNZ SHORT 00DD1C81
00DD1C6E 813D A47ADD00 00>CMP DWORD PTR DS:[DD7AA4],400000 ; ASCII "MZP"
00DD1C78 75 07 JNZ SHORT 00DD1C81
00DD1C7A A1 A47ADD00 MOV EAX,DWORD PTR DS:[DD7AA4]
00DD1C7F EB 06 JMP SHORT 00DD1C87
00DD1C81 50 PUSH EAX
00DD1C82 E8 3135FFFF CALL 00DC51B8 ; JMP to kernel32.GetModuleHandleA
00DD1C87 5D POP EBP
00DD1C88 C2 0400 RETN 4

...

00406A79 A3 18274F00 MOV DWORD PTR DS:[4F2718],EAX
00406A7E A1 18274F00 MOV EAX,DWORD PTR DS:[4F2718]
00406A83 A3 94804E00 MOV DWORD PTR DS:[4E8094],EAX
00406A88 33C0 XOR EAX,EAX
00406A8A A3 98804E00 MOV DWORD PTR DS:[4E8098],EAX
00406A8F 33C0 XOR EAX,EAX
00406A91 A3 9C804E00 MOV DWORD PTR DS:[4E809C],EAX
00406A96 E8 C1FFFFFF CALL xxxx.00406A5C
00406A9B BA 90804E00 MOV EDX,xxxxx.004E8090
00406AA0 8BC3 MOV EAX,EBX ; EAX == 004E7B7C
00406AA2 E8 91D8FFFF CALL xxxxx.00404338
00406AA7 5B POP EBX
00406AA8 C3 RETN

...

004E7E75 8B1D 7C144F00 MOV EBX,DWORD PTR DS:[4F147C] ; xxxxx.004F2C3C
004E7E7B 8B03 MOV EAX,DWORD PTR DS:[EBX]
004E7E7D E8 EA15F8FF CALL xxxxx.0046946C
004E7E82 8B03 MOV EAX,DWORD PTR DS:[EBX]

...

so, oep should be somewhere in the "zeroed area" around 4E7E68.
hmm, i thought about setting a memory bp on write access there, restart the app and examine when it writes the data there and secondly overwrites the original "staring bytes".
i breaked here:

....
00DC262B F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
00DC262D 89C1 MOV ECX,EAX
00DC262F 83E1 03 AND ECX,3
00DC2632 F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
00DC2634 5F POP EDI
00DC2635 5E POP ESI
00DC2636 C3 RETN

memory at esi:

004E7E68 00 00 00 00 00 00 00 00 ........
004E7E70 E8 F3 EB F1 FF 8B 1D 7C èóëñÿ‹|
004E7E78 14 4F 00 8B 03 E8 EA 15 O.‹èê
004E7E80 F8 FF 8B 03 BA 0C 7F 4E øÿ‹º.N
004E7E88 00 E8 EA 11 F8 FF 8B 03 .èêøÿ‹
004E7E90 83 C0 50 E8 B8 C7 F1 FF ƒÀPè¸Çñÿ
004E7E98 8B 0D 7C 13 4F 00 8B 03 ‹.|O.‹

surprisingly there was no other write access to that memory location.
this means that the opcodes from 004E7E70, E8F3EBF1FF
(or CALL xxxx.00406A68) are not modified anymore....

...?? could this be? is there nothing overwritten, no real stolen bytes?

anymore any ideas? i got crazy

Leave me your URL. I played recently with something that PeId identify as ASPR1.23 Demo. That has stolen-mutated bytes, and I think it is the same version as you all described here.

Here is URL if you wanna see:
hxxp://www.3planesoft.com/files/castle.exe

Manko's debugger handles it (enough to be done manualy in shortest time).
It is not enough to find stolen-mutated bytes, there is another trick to reconstruct those bytes. I mean not to reconstruct them literaly, but to make application working.

Zilot