Newbie question ASPR 1.23 RC4 (long!)

[britedream]

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.

[JackD]

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

[britedream]

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

[JMI]

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

[JMI]

Well, the answer is an unsatisfying "that depends." 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."

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

[britedream]

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

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)

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

[britedream]

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

[britedream]

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

006204A0: FE FF FF FF-1E 00 00 00-1E 00 00 00-FE FF FF FF

at 6204A8

Regards
Wurstgote