Results 1 to 13 of 13

Thread: ASProtect 1.23 RC4 Demo

  1. #1

    ASProtect 1.23 RC4 Demo

    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?

  2. #2
    Registered User hobferret's Avatar
    Join Date
    Jul 2002
    Location
    Alien Area near Albuquerque
    Posts
    203
    Quote Originally Posted by squidge
    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.

    Hi Squidge

    What rarely used program are you talking about??

    /hobferret

  3. #3
    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.]

  4. #4
    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
    Attached Files Attached Files

  5. #5

    Violation of the Rules

    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.
    JMI

  6. #6
    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 .

  7. #7
    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?!

  8. #8
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    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

  9. #9
    Greetings!
    Forget about the stolen bytes and tell me about the call at 40734d
    that has been bypassed and nothing happened??
    Last edited by britedream; October 5th, 2003 at 11:42.

  10. #10
    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,
    JMI

  11. #11
    Quote Originally Posted by nikolatesla20
    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
    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

  12. #12
    jojojo
    Guest

    Smile strange

    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  13. #13
    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:
    http://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

Similar Threads

  1. New Hex-Rays Demo
    By Hex Blog in forum Blogs Forum
    Replies: 1
    Last Post: March 12th, 2008, 21:47
  2. Demo software
    By Signum in forum The Newbie Forum
    Replies: 13
    Last Post: May 14th, 2006, 20:33
  3. Coding Digest of the Demo Scene
    By 0xf001 in forum Off Topic
    Replies: 2
    Last Post: May 14th, 2006, 07:38
  4. Demo watermark in printout and object copy
    By MuT in forum Malware Analysis and Unpacking Forum
    Replies: 9
    Last Post: December 26th, 2004, 21:53
  5. Demo Shield reversing
    By myAvatar in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: November 28th, 2000, 23:38

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •