ASPR not full tut

[britedream]

Hi Labba !
Thanks for the effort you put into this tut.,it is nice tut. but
I would like to add slightly a shorter approach.At the point
where it says "It's time now to set a trace...":

1- ALT+M , and choose "set memory breakpoint on access"

2- Shif+F9,will break on program code,press K on toolbar

3- double click on the second address u see there.

4- this is the place u should be dumping from, also u

see the place where stolen bytes should be placed.

for freeresource or lockresource you should be able
to determine from names above and below.

Britedream.

Hi Labba and britedream !

Thanks for your the effort you create this great tut and advise.

However, I couldn't get the correct unpacked executable file with this tut. Maybe I don't have GOOD Brain for understanding this.

I have tried with same example(SystemCleaner 4.91d).

My final targets are DropToCD and Recordius those are CD/DVD burning application. But I can't pass the TUT course.

English is not first language for me. So maybe I've misunderstood tut procedure.

If you have a chance to update tut, would you please explain procedure step by step with number(as like britedream's reply)?

Thanks and regards,
HotPepper

I have apply this tut to DropToCD, but I got a strange thing. After unpacked, unpacked file does not run correctly. NOT crash... Process is just terminated without any error.

What should I do?

And, in this program, stolen bytes is not 11 or 14 bytes. I believe that is 12 bytes.

Thanks,

HotPepper

that target has an old trick, checking if app was unpacked...
look for exceptions after OEP... try olly...

and, if you didn't succeed with the target that belongs to the tut, then the knowledge in that tut will not be enough for you, certainly not if you tackle an unrellated target.
/Manko

Originally posted by HotPepper
I have apply this tut to DropToCD, but I got a strange thing. After unpacked, unpacked file does not run correctly. NOT crash... Process is just terminated without any error.

What should I do?

And, in this program, stolen bytes is not 11 or 14 bytes. I believe that is 12 bytes.

Thanks,

HotPepper

If the app was writtein in C++ Builder or Delphi, this generally happens if you dump too late; you may need to dump a bit earlier. If it was compiled with something else, it is probably like Manko said.

I will download this and see if I can get it to work. Which DropToCD is it you are trying to unpack? DataCD or AudioCD? And which version? (Meaning, for DataCD there is 2.0 and 2.0 beta 3, and for AudioCD there is 1.0 and 1.1 beta 2)

[britedream]

Hi HotPePPer!
The info for DropToCd(Audio)
Oep=5647dc
stolenbytes=55 8B EC 83 C4 F0 53 B8 84 41 56 00

IATrva=7bf190 size~900
the stolen bytes are not erased so when u stop at address
5647e8 go to ecx and follow to dump, change dump pane
from hex to disassemble, go up one or two lines then
u see all your stolen bytes.

britedream, can you try your hand at DropToCD DataCD 2.0? I was able to do AudioCD easily, but I am having some problems with DataCD that I cannot find a way around. I found OEP and stolen bytes easily; OEP = 585465, stolen bytes = 55 8B EC 83 C4 EC B8 DC 4D 58 00. I think the problem is some SEH, but I can't get around it. Maybe it is easy and I am missing something obvious, I don't know. Anyway, if you have time, please try DataCD.

Hi!

Satyricon, my good man!
Have you no trust in me? As I said it IS a common trick with ASPR. Have you never seen it?

Anyway... When you have unpacked it as normal, run it with Olly and make sure it is set to record/pause at all exceptions...
You will notice it will break twice on the same address... Reverse it!

(Too be honest, I just used my app as normal to get this address... Can't unpack every file every time...)

Ohh, and yes, delphi will often do exceptions, but you can see if that is the case... code/address will be quite different usually...

Just get the address of that exception and do the work...

cya

/Manko

Hi!

Hehe... SORRY! There were more tricks perhaps... must examine further tomorrow... maybe just tired? ...

CYA!

/Manko

Manko, I do trust you! But, I don't think this program is so simple... I have seen exceptions in AsProtected programs before that are simply testing to see if certain APIs (usually emulated kernel32 functions) are writeable, and those are easy to get around. Indeed, there is one of those in this application (and that is what you saw in your asprdebugger). But, there is more here than just that. I have done all the usual things, but it still doesn't work.

Debugging packed program, you see internal exception 0EEDFADE raised four times total, two before messagebox displaying remaining number of trial days, two after the messagebox. Debugging unpacked program, you see the exception SIX times total, three before messagebox code (messagebox no longer pops up for some reason), three after messagebox code. So it seems there was some other SEH in place here, so that the exception was only raised 4 times instead of 6 in the packed code...

What happens is, when you run the program (while packed), you see the application in the taskbar for 3 or so seconds, then after those 3 seconds, the program's form pops up. When unpacked, you still see the application in the taskbar for those three seconds, but once the three seconds have elapsed, instead of the form popping up, the application just closes. It looks like the program (which appears to be written in C++ Builder) terminates early from some loop in TApplication->Run, maybe a message handling loop?.

Hi All,

Thanks for all of you reply the messages.

I mean a DropToCD DataCD 2.0 final. It is using the ASProtect 1.23 RC4 for pack.

I will try again with all of advise from yours.

Thanks,

Hi All,

I am sorry if I'm bother you with these.....

I just download 'Recordius 1.03b'. And try to unpack, but I can't.

Yes, I am BEGINNER~!. However I have really GOOD time to learn about unpacking from this board.

Here is what I did...

DropToCD(Data) 2.0 , Recordius 1.02b
- Stripper V203 can remove the trial limits from registry, so I can use over 7 days.

- PE-ID can scan the version of ASPR and searched OEP (even that is not correct!)

- ASPRdbgr 1.0 can found IATrva and found OEP

- with the Olly, I can found OEP of DropToCD but not Recordius

Recordius 1.03b
- Stripper V203 can remove the trial limits, but invoke the error when try the unpack. After remove the trial limit, I can not run the app because app invoke the Protection Error 0000001

- PE-ID can scan OEP and ASPR version.

- ASPRdbgr 1.0 can not found IATrva and OEP, just finished run.

- with the Olly, I found the dumping point(but I am sure because that is not similar with TUT), but I can not trace for finding OEP because trace get a error after several F8.

Thanks,
HotPepper

[britedream]

to Hotpepper
the asprotect in recordius 1.03 is new breed to me so
with only 13 tries it will be hard to know it,we should check
it in a program with no such limit.however I think I found the
signature bytes .
mov edi,[starting address for erasing]
move ecx,285e ;this will change in some programs,but as far as
yours it is 285e=# of bytes to erase
rep stos byte ptr es:[edi] ; erase
popfd
pop edi
pop ecx
retn
these last 4 bytes you can use as signature
p.s.
ollydbg isn't working well with it,and ds3 isn't functioning in
my pc.

[britedream]

Hi satyricon!
with only 13 tries I think it will be wise to try to find the
location to disable try limit each time u run the original, then it would be easy to go to the original
prog. to check errors and correct them.otherwise u will come
to the limit soon .
regards!

britedream,
DataCD stupidly stores the number of times it has been executed in some hashed data in registry. After executing it only once, I exported that registry key, and by importing that registry key now, I can reset the number of executions. So, the 13 execution limit does not matter! Effectively, all that is left is the 7 day limit.

BUT...

I know exactly where in code it checks the number of executions and days elapsed. It is very easy to bypass, I think. Try looking at the subroutine at RVA 57D590-57D603. That is the procedure that generates the messagebox. In that routine, check for calls to 573640 (routine that returns number of days total and number of days remaining) and 5736A4 (routine that returns number of executions total and number of executions remaining). Those routines can easily be patched, allowing you to run the program as many times as you want.

With that information, I would greatly appreciate if you could try your hand at unpacking it. You seem very competent, much moreso than myself, and I am greatly interested in what else needs to be done to get this application to work correctly. Thanks!