ASPR 1.2 question

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,

[JMI]

ferrari:

You are correct it is a single "exe" with no setup. 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,

[Jay]

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.

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

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.

[JMI]

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,

[gabri3l]

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

[JMI]

Hey Satyric0n:

Just because something is "obvious" doesn't mean one actually managed to "observe" it. 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.

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

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

Regards and thanks.

[gabri3l]

Originally Posted by Satyric0n

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?

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.

[britedream]

Originally Posted by JMI

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

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.

[britedream]

Originally Posted by ferrari

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,

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

Regards to all at exetools forum,

peid say asprotect 1.22-1.23 beta 21,load app in olly patch debuger check,go to last exception put breakpoint at ret,olly break,but when i run trace or put breakpoint at code section nothing is happen,olly start tracing and never end. anyone have this problem?

[britedream]

some asprotected targets have antitrace loop, once it does that , F12 and set bp after jnz, F9, then control+F11 to trace again.

thanks britedream for fast and useful answer,i follow your instruction and problem is solved