britedream,

I did not patch any code to fix ASPR expiration, just data. This is the way ASPR does it except that it points to registration name in ASPR.

Patch
620484 to F0 3F 61 00
and
613FF0 to 45 76 65 72 79 6F 6E 65 (Everyone)
and the proggie thinks it's registered.

You now get "Registered to: Everyone" in about box.

JackD

That is cool Jackd.
I sent him the dump without any patch, except the one for option.

britedream,

I've checked it with peid, it reports "Borland Delphi 6.0 - 7.0" as compiler (so no protector any more) and OEP is 213654 as expected. Since I'm on Win2k I had to change RestoreLastError to SetLastError with a hex editor, but it won't run. Maybe it has something to do with that change I had to make, but if I got it right, this change (Rest.LastError - > SetLastError) is necessary, since Win2k don't know RestLastError.
In Olly, I get some access violations, first one at 404f5f...

I suppose I did someting wrong, but don't know what...
Any hint?

Regards
Wurstgote

may be you can send it to Jackd if he has windows xp, if that is alright with him

Wurstgote,

Working IAT on w2k.

JackD

Thanks for that one,

but I've got a stupid question (please remember, I'm completely new to this stuff ;) ):
Is it acceptable to use the IAT with britedream's fixed dump or do I need a clean dump from OEP?

Regards
Wurstgote

If you want I can send you my raw dump without iat fix.

That would be nice!

Thanks,
Wurstgote

Wurstgote,

If you read my last PM, you know I gave you a bad email address but I have PM'd you the correct one. So, I haven't got britedream's dump and can't say for sure but it should work on both. Britedream PM'd me his ASPR fix and it should not effect your program operation. It's always good to start with a fresh dump if in question.

I am on w2k like you so you should try the C3 patch I listed above. It may be that XP handles Britedream's patch differently and so it works for him.

JackD

JackD,

there seems to be some problem concerning your mailbox. Please check your PM.

Regards
Wurstgote

File sent

Thanks, file received.

Started the original app in Olly, got to OEP and tried to fix your dump with JackD's IAT with ImpRec.
Same problem as before: Access violation at 404f5f.
But for a very short time a window pops up... May it be the problem Satyric0n mentioned before?

Regards
Wurstgote

I think you need windows xp to test

Wurstgote,

It's a FREE mailbox, can't expect much. File size is the problem. Try zipping dump maybe if you want to retry?

JackD

JackD,

problem is, file is already zipped. Tomorrow I'll put it on a http server. You can download it from there. As soon as it's there, I will send you a PM.

Regards
Wurstgote

Wurstgote,

I think I was able to replicate what you're getting. I believe the problem is the dump you are using came after ASPR processed its 'dips'.

ASPR processes 'dips' before reaching the OEP that modify addresses to point to ASPR at 620484, 62048C, 620494, 620498, and 62049C.

data BEFORE ASPR dips
00620480: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00
00620490: 00 8D 40 00-F4 85 57 00-20 86 57 00-20 86 57 00
006204A0: 00 00 00 00-FE FF FF FF-FE FF FF FF-00 00 00 00
006204B0: FE FF FF FF-FE FF FF FF-00 8D 40 00-00 00 8B C0

data AFTER ASPR dips
00620480: 00 00 00 00-61 38 60 01-00 00 00 00-FC 1E 63 01
00620490: 00 8D 40 00-08 1C 61 01-A4 1B 61 01-D8 1B 61 01
006204A0: FE FF FF FF-1E 00 00 00-1E 00 00 00-FE FF FF FF
006204B0: 00 00 00 00-00 00 00 00-00 8D 40 00-00 00 8B C0

data that WORKS
00620480: 00 00 00 00-F0 3F 61 00-00 00 00 00-00 00 00 00
00620490: 00 8D 40 00-F4 85 57 00-20 86 57 00-20 86 57 00
006204A0: FE FF FF FF-1E 00 00 00-1E 00 00 00-FE FF FF FF
006204B0: 00 00 00 00-00 00 00 00-00 8D 40 00-00 00 8B C0

MUST put something here for pointer in data that WORKS
00613FF0: 45 76 65 72-79 6F 6E 65-00 00 00 00-00 00 00 00

You still need to apply C3 at 57890C.

JackD

JackD,

wow, you're right: Your "data AFTER ASPR dips" exactly match those in my dump :)
Now I wonder, regarding the behaviour of the dumped app, where's the difference between your version and mine? The only one I recognize is that yours show in the "About" dialog that the app is registered to "Everyone" (due to
00620480: 00 00 00 00-F0 3F 61 00-00 00 00 00-00 00 00 00
and
0613FF0: 45 76 65 72-79 6F 6E 65-00 00 00 00-00 00 00 00)
while mine shows some trash.
Despite of that (little) difference, both versions behave the same (as far as I've found out).
I'm sure there must be something else, but I can't figure it out.
Do you mind to explain, please?

Regards
Wurstgote

Wurstgote,

I guess I'm not sure just what problem(s) you have at this point. Maybe your resource section, but I just don't know. If you can post your dump for download, I'll check it out.

JackD

JackD,

I would like to put my dump on my homepage for download, but it seems my provider is messing around with his system, so at the moment, I've got no ftp access to transfer the file... Perhaps it will work again later.
But could you please tell me at what point I need to dump the app? I've dumped it at the first time eip<900000 (it's at a jump back to ASPR code) and if I got you right, ASPR has already processed the dips (by the way... what are those dips?).

Regards
Wurstgote

Wurstgote, can you go on IRC to send me the file?

Regards

Satyric0n,

sure. Just a few minutes, I'm now at a different computer so I'll have to install mIRC again...

Regards

britedream:

I have tried your dump (Wurstgote sent it to me), and indeed it does work perfectly on WinXP (though not on Win2k). But, it only works while you keep the ASPR sections after the .rsrc section on the file.

If you read the beginning of this thread, you will see that Wurstgote and I have made an excercise of getting rid of all the sections after the .rsrc section: .data, .adata, and .mackt (removing this by having ImpRec put the imports in the section at 22A000 instead of in a new section).

Once I remove these sections from your dump (the .data section, specifically), your fix at 578911 for Options no longer works, and I must do the same thing as I did in my dump to get it working.

So my question is: does your method of fixing these problems work also if you remove the sections after .rsrc?

Regards,
Satyric0n

Hi,
I didn't follow all the post , it is a long one, but for removing the section I didn't see any need for removing those sections so I did not try your method,I am working on too many things at the same time, once I get a chance I will check it. you know this target is very strange in many ways, I think it uses the protected dlls as loader of some sort. your method would be clearer if you were to use normal target.

Regards.

As a rule, when I manually unpack ASProtected apps, I always remove the ASPR sections (.data and .adata in this case), and put the imports in the original .idata section (22A000 in this case) instead of in a new section (.mackt) as ImpRec does by default. I do this because these sections seem to me to be entirely unnecessary, and only waste space by making the exe bigger.

Having done that, this app's behavior seems (to me) to be consistent with every other ASPR'd app I have ever dealt with. I was able to unpack it without problems, it's just that my methods of doing so seem to be much different than yours.

If you get a chance to try it, I would be interested to see if your method of fixing the dumped file works with these sections removed.

Regards,
Satyric0n

Ok I will try to do that, but to test this today
I copied a dump of an old version of this target which starts normaly at oep , and replace the current version, when I run it , it no longer runs from the oep, but from inside asprotect.

Oh , I must congratulate you on the patience you have , I admit I don't have that at all, I just finsh reading some of your post, it is a nice method but it seems too long to endure at least for me. but I like your tricks anyway, I will try to use them some time.

All,

Part of the resources are in the dumped ASPR .data.
A clean, working, .rsrc section attached.

Britedream,

The 2 dlls are just ASPR'd dlls and as far as I can tell, other than being required by Resbldr, have nothing to do with it.

JackD

JackD,

Yes, I had no problem relocating the resources in .data into .rsrc. Also the TLS table needs to be relocated back to .rdata, and you need to strip relocation out of the PE before getting rid of the .data section.

This is all fairly easy, and it has been part of my unpacking process for ASPR'd programs for a long time now.

The problem is that britedream's fix for the Options problem does not seem to work with .data gone. I already have a fix for the Options problem (and always use this fix for ASPR apps, and have never had problems with it), but I am always curious to see whether a better method can be found, which is why I am eager to see how britedream's method works. :)

Regards,
Satyric0n

To Jackd:
That was my observation when I replaced my new dump with the old one, I didn't have the time to trace them, eventhough it is easy to do. so i f you are sure based on tracing that is fine ,but if it is your hunch then it would be nice if you have time to explore it.

JackD,

could you please explain those 'dips' you've mentioned? I think you've dumped your app at a different point than I did, but where is this point exactly?
Your unpacked app seems to be registered to "Everyone". Is it really registered, or is that only the string displayed when you open the "About" window?
I don't know if you've got some time to play with the app, but you can test your registration status by double clicking on "Dialog" on the left side of the app main window, then go to "Tools->Link to Exe...".
What happens?

Thanks in advance
Wurstgote

Wurstgote:

I have not played with your target, but there has been much written about various techniques used by ASPR to attempt to foil the efforts of the "honest crackers." One of those techniques is the process of setting points in the original program that attempt to jump off into parts of the ASPR code or, sometime, might even move part of the original code into the area of the ASPR code. Generally these are called "dips" but often they send the program off to addresses usually "above" the normal code range of the original exe, into the code range where ASPR is/was found.

The point of the exercise is that when you remove the ASPR wrapper around the exe, by dumping, you might no longer have access to these "dips" or they might have changed or moved necessary data and, unless you dump at the right time or fix the reference in the exe,which send the program off looking at these locations, you will get an error and your program will not work correctly. I believe, generally, that is what is being discussed.

Regards,

JMI,

thanks for your help!
More or less, dips are nothing else than still existing references to deleted ASPR code/data?

Basically, I've got the dumped file up and running... no more exceptions and stuff. But it's still unregistered. JackD's post suggests that his method (read: dumped somewhere else) produces a real registered app.
So I wonder, if
a) I've understood JackD's post correctly and
b) if a)== true, where do I have to dump and what do I have to do.

Regards
Wurstgote

Well, the answer is an unsatisfying "that depends." :p If you go back and look at JackD's post on the previous page, you will see he wrote:

ASPR processes 'dips' before reaching the OEP that modify addresses to point to ASPR at 620484, 62048C, 620494, 620498, and 62049C.

data BEFORE ASPR dips
00620480: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00
00620490: 00 8D 40 00-F4 85 57 00-20 86 57 00-20 86 57 00
006204A0: 00 00 00 00-FE FF FF FF-FE FF FF FF-00 00 00 00
006204B0: FE FF FF FF-FE FF FF FF-00 8D 40 00-00 00 8B C0

data AFTER ASPR dips
00620480: 00 00 00 00-61 38 60 01-00 00 00 00-FC 1E 63 01
00620490: 00 8D 40 00-08 1C 61 01-A4 1B 61 01-D8 1B 61 01
006204A0: FE FF FF FF-1E 00 00 00-1E 00 00 00-FE FF FF FF
006204B0: 00 00 00 00-00 00 00 00-00 8D 40 00-00 00 8B C0

data that WORKS
00620480: 00 00 00 00-F0 3F 61 00-00 00 00 00-00 00 00 00
00620490: 00 8D 40 00-F4 85 57 00-20 86 57 00-20 86 57 00
006204A0: FE FF FF FF-1E 00 00 00-1E 00 00 00-FE FF FF FF
006204B0: 00 00 00 00-00 00 00 00-00 8D 40 00-00 00 8B C0

If you look closely at the last two lines of the first listing "Before ASPR Dips" and compare them to the last two lines of "after ASPR Dips" you should notice that during the "dip" ASPR overwrote some of the code "during" the dip. The code there "before" the dip will not work, and the code "after" the dip will (according to JackD's Data that Works statement.)

What this tells you is that if you dumped the exe "before" that dip occurred, the code is never "fixed" and the program will NOT run correctly. Therefore, you have to make sure that ASPR has finished "dipping" before you dump. This is one of the ways ASPR attempt to catch the unwary who fail to dump at the correct place.

So in this case, it is NOT letting the "dip" occur which appears to be the problem. I seem to recall reading that there was a time when the "opposite" condition was found, meaning some necessary data was moved by ASPR and unpacking the exe without ASPR left jumps to ASPR code which no longer existed. Afterall it is Alexy's job to try to stay ahead of the rest of us and sometimes he recycles things previously used and ignored for a while.

And, yes, he and/or his troops do read these types of Forums to find out what is being said about his product. He has even posted on the Woodman Forum a couple of times. :)

You can search "dips" on the Woodman Forum and find some discussion of these issues there, some from +Splaj who delights is unwinding the twists and turns of these programs, and discusses when there were "double dips." :cool:

Regards,

I think I've got it. Thanks for your explanation
Next I'll have to take a closer look at Woodmann's forum ;)

Regards
Wurstgote

To Wurestgote
if you are wondering about registration, at address 578685 mov edx, dword ptr ds:[620484],the value 620484 is point to an address make sure this addres point to anything except zeroes. (this is what I understood from the post)

how to find the first address:
this is what i did:
1- view memory, choose the region right after the code region.

2- search for binary 0000000061, you will see the address of the popad go to it,set bp memory on access at the popad,run

3- first stop is only compare , so f9, will
stop at the address above (578685).
regards.

Hi britedream,
I first thought that JackD's way would indeed give a full registered app... but that's not the case ;)
I've figured that one out. But: if the address you mention points to something containing zeros, it's not a problem. The app still runs fine, but the "Register..." part in the "Help" menu is enabled and when you take a look at the "About" box you'll see that you are still in trial mode.
If the above mentioned address points to an ASCII string, the "Register..." part is no longer there and the About box shows said string as the name of the registered user. But in fact the app is still unregistered since some of it's functions produce a "Function only available for registered users" message.
But since I only wanted to unpack and not crack it, that's no problem with me :)

About the part on how to find the first address: I think I've found a straighter way to get there...
Assuming the data at 00620480 and afterwards is the same as "data AFTER ASPR dips" (which was true for my dump), simply start the app in Olly and try to open the "About" box. Olly pops up with an access violation. Looking at the stack you'll see the ret address of the call to the function that produces the violation. Go to this address and you're two or three lines below 578685.

Regards
Wurstgote

what I posted for finding the address is
generic way, since we have different os, could you please till me what option showed you that his method isn't working.

note:I don't have any dips in my dump, and I get no access violation errors when I open about.

You could try this: Start the app, on the left side double click on Dialog - an empty dialog template is shown in the main area. Now go to "Tools->Edit as Text". I suppose you'll see a message box pop up. It's possible that it doesn't show any text (due to patching the data), but basically it's an "trial version can't use this feature" message.

Regards
Wurstgote

thanks for the reply, I think you have apoint, regarding fully registered but this may prevent the target from expiring, I didn't try it , you could try to forward date and see.

You're right about that. The trial won't expire any more since the number of days the trial still works is fixed here
at 6204A8 ;)

Regards
Wurstgote