Newbie question ASPR 1.23 RC4 (long!)

[britedream]

I see you having hard time, this target isn't a hard one, I did unpack it for a member req. just use my script "asproep"

to go to the oep, write your stolen bytes,
then right click on the first one , choose
orign here, dump, and fix iat, target
should be running, but if u try to choose
an option it will exit. so u have to change
address 5788b9 to read mov eax,62a43c
in stead of mov eax, dword ptr ds:[40701e]. this is on windows xp. it will
run fine after that.

regards.

britedream: Your input, as always is greatly appreciated (I still consider you the master of ASProtect, after all it was you who taught me ), but I think Wurstgote's excercise here is more for learning purposes than to simply get the app unpacked and be done with it. And for learning purposes, what better way is there than to do everything manually?

last aspr section .adata is mostly 1000h size empty section.
i yet not meet any prog, which uses this section.

Hmmm... this section's raw size is too big to put it somewhere inside a zero block. What should I do now?

Remember, all sections after .rsrc (including .adata and .data) should be deleted entirely (after you have relocated any useful data out of them.. hint, hint).

Okay. As for this one I could try to put it at raw location 226000 since there's enough space.

This would not be good.. The BSS section is used at runtime by Delphi (remember that data morphing again?), so your import table would be overwritten at runtime. Which wouldn't be a good thing.... Keep trying

FYI, the DATA section is for initialized data, the BSS section is for uninitialized data (namely, the data is initialized at runtime).

I see you having hard time, this target isn't a hard one, I did unpack it for a member req. just use my script "asproep"

Oh, the app is unpacked and running
As SatyricOn proposed, I'm now trying to "clean up" the unpacked exe to make it smaller. Not really necessary, I know, but nevertheless a good way to get some practice!

but if u try to choose an option it will exit

Hmmm... you're right about that
So I'll have to see if I can fix that.

Regards
Wurstgote

Originally posted by Wurstgote
Hmmm... you're right about that
So I'll have to see if I can fix that.

See this thread for a previous discussion on that type of problem:

http://www.exetools.com/forum/showthread.php?s=&threadid=2441

It is just another aspect of ASProtect's protection; once you know about it, you take it for granted that it will happen, and it is easy to fix.

Regards,
Satyric0n

[britedream]

To Satyric0n !
Great pleasure to hear from a nice friend,please forgive my ignorance,I thought he is having hard time, so I tried to help.

@ britedream:
You turned my attention to another aspect of ASPR, thanks for that! Later I will have a look at the thread mentioned by SatyricOn.

@ SatyricOn:

Remember, all sections after .rsrc (including .adata and .data) should be deleted entirely

Yes, I know. I'm afraid this will be another long, long evening... *sigh*

after you have relocated any useful data out of them.. hint, hint

Hmmm... so the first thing I should do is figuring out what data is needed and what data is trash.
So far I know that the data in .mackt is needed since it contains the IAT. That mean I need to find a way to store the IAT entries somewhere else.

This would not be good.. The BSS section is used at runtime by Delphi (remember that data morphing again?), so your import table would be overwritten at runtime. Which wouldn't be a good thing....

Perhaps my explanation of what to do with .mackt was kind of rubbish (sorry for that, English is not my native language )
I thought of using only the _disk_ space at offset 226000 to store the .mackt part, but without changing the virtual offset of the .mackt section. While loading the app, the loader would see that the section located at file-offset 22600 should go to VA 313000 in memory, so the section at VA 22600 isn't occupied and Delphi can use it for whatever it wants.

FYI, the DATA section is for initialized data, the BSS section is for uninitialized data (namely, the data is initialized at runtime).

Ahh... good thing to know Thanks!

Regards
Wurstgote

Originally posted by Wurstgote
I thought of using only the _disk_ space at offset 226000 to store the .mackt part, but without changing the virtual offset of the .mackt section. While loading the app, the loader would see that the section located at file-offset 22600 should go to VA 313000 in memory, so the section at VA 22600 isn't occupied and Delphi can use it for whatever it wants.

That's an interesting idea. I've never seen a PE header with sections set up non-sequentially like that, so I'm not positive it would work, but interesting nontheless.

There is still a solution you haven't thought of yet, though, that I think is best solution (if only because it is more conventional than your idea ).

If you feel you have exhausted your thoughts on this subject, I will explain it also. But, I like the way you think about the situation (most people wouldn't bother), as you come up with some very creative ideas.

Regards,
Satyric0n

I've never seen a PE header with sections set up non-sequentially like that, so I'm not positive it would work, but interesting nontheless.

I've experimented a little with this, but as yet it won't work...
Perhaps you're right and sections need to be in linear order inside PE files. Tomorrow I'll take a closer look!

There is still a solution you haven't thought of yet, though, that I think is best solution (if only because it is more conventional than your idea

I'm sure there is, but at the moment my brain seems to run in standby mode. Perhaps I can figure it out after a good night's sleep

If you feel you have exhausted your thoughts on this subject, I will explain it also

That's very kind of you, but I feel that I should spend some more time on this... Perhaps you could give me just another hint, to put my thoughts in the right direction

Have a good night (or day, in case you're on the other side of the world)
Wurstgote

I've never seen a PE header with sections set up non-sequentially like that, so I'm not positive it would work, but interesting nontheless

In my last post I've stated that something like this, according to some experiments, perhaps doesn't work.
I was wrong
I've made an error when recalculating some resulting offsets, but after fixing that stuff, everything runs fine. So it's definitely not necessary for the sections to stay in sequential order inside the file.
Although it may be an interesting thing, it's kind of pointless. As you've reminded me a few posts above, the goal should be to completely delete the unnecessary sections, not simply shifting them around. And if the point would be just to reduce filesize, it's enough to set the raw size of sections containing only zeros to zero.
I suspect that after wading through knee-deep hex-editing stuff I've reached the same point where I had started
So it's time to rethink the matter!

Regards
Wurstgote

In my last post I've stated that something like this, according to some experiments, perhaps doesn't work.
I was wrong
I've made an error when recalculating some resulting offsets, but after fixing that stuff, everything runs fine. So it's definitely not necessary for the sections to stay in sequential order inside the file.

Good to know! Maybe someday that little factoid will present the perfect solution to some problem that's stumping me...

Perhaps you could give me just another hint, to put my thoughts in the right direction

Well, for right now, I'd take things one step at a time: ignore the .mackt section and do that last, for now first focus on removing the .adata and then the .data sections. To this end, I will point out that PE editors (such as LordPE) will be a big help, as they can do deadlistings of the addresses (VOffsets) of items in the PE header, and make finding all items in a certain address range much easier.

Also, recall now my descriptions of these sections:

.data -- this section is named randomly by ASProtect, and holds ASPR's IAT, some redirected resources, etc
.adata -- this section is used as in-memory data storage by ASPR

Regards

Well, for right now, I'd take things one step at a time: ignore the .mackt section and do that last

Too late for that - I've managed to relocate the IAT
So the .mackt section is completely gone!
But, man, that was tedious work!
First, I've examined the .mackt part at 313000.
It starts with a bunch of IMAGE_IMPORT_DESCRIPTORs, with everything but Name and FirstThunk zeroed. Name points again to the .mackt section, while FirstThunk points to section 22a000.
So I took a look there: The RVAs in FirstThunk lead to RVAs pointing to IMAGE_IMPORT_BY_NAMEs, which are again located in the 313000 section. Next I fired up a hex editor and changed all pointers to Names in .mackt, so that they point now to corresponding addresses in 22B000 space. After that I've copied the whole .mackt stuff to 22B000, overwriting the data there.
Next step was to change all RVAs that pointed to IMAGE_IMPORT_BY_NAMEs to point to the 22B000 area.
Then I only had to fix the "Import Table" directory entry to the new value 22B000 and delete the .mackt section.
And guess what? Yes, Sir, it works!

But I hope there's an easier and less error prone way to do this?

So, on to the next section-killing adventure, and thank again for guiding me through this stuff

Regards
Wurstgote

UPDATE: .adata send to hell

Too late for that - I've managed to relocate the IAT

Wow! Good job. But you're right, there's a much easier way to do it. If it took that much work every time, I certainly don't think I'd bother! I'll explain an easier way shortly.

UPDATE: .adata send to hell

.adata is certainly the easier of the 2, as you can just erase it with no further work! .data will be a little trickier to do correctly, as you can do about half of what you need to do and it will appear to work correctly. But, if you don't do the other half, multithreaded apps (hint) can start working very... strangely.

Regards

Ok, here's the easy way to be rid of the .mackt section:

As I said earlier, the section at 22A000 is called .idata, and was the original IAT/import table before packing, but ASProtect makes it unusable. So, we can use that section again for the new imports, with very little work.

In ImpRec, you see a groupbox called New Import Infos, and in there, there is a checkbox called Add new section, which is checked by default. If you uncheck that, you can now set the RVA that you want the imports to be written to. So, we first try putting 22A000 in there, and hit Fix Dump. We get a warning saying that the IAT will be overwritten if we continue. This doesn't look good , but lets continue anyway. Continue to fix dump, then go into LordPE or PE Tools or whatever, and change the location of the import table to 22A000 and the size of the import table to the size that ImpRec tells us it is. But, when we try to run the app, it doesn't work .

Ok, we need a new approach. If you click on options in ImpRec, we see quite a few things we can configure. One groupbox in particular looks interesting, New Imports. In there is an option called Create New IAT. Well, if we create a new IAT, it wont matter if we overwrite the old one, does it? So lets check that and hit OK. Still with Add new section unchecked and 22A000 put in the RVA box, lets hit fix dump again. This time we don't get a warning, looking good... It takes a while, then is done giving us a "success" status. When we go to fix the import table size and location in LordPE, we see that ImpRec has already fixed these things for us. Good! Let's try to run it. Unfortunately, that doesn't work either.

But that doesn't mean we aren't on the right track. Actually, we did exactly the right thing, but there's one thing ImpRec doesn't do for us that we still need to do manually (it seems to me this is either a bug in ImpRec, or a feature that should really be added..). Before we fix dump, we need to go zero out the contents of the entire .idata section. What is happening, is that ImpRec is overwriting the portions it needs to, but leaving garbage data in the remainder of the section.

So, in our dumped file before running ImpRec, lets open it in WinHex (or your hex editor of choice), go to 22A000, select the size of that section, and fill the whole section with 00s. In WinHex, you can do this by hitting Ctrl+L, and with Fill With Hex Values selected, leave in 00 as the value, and hit OK. Once that's done, save the file, and go back to ImpRec. With Create New IAT still checked, and Add New Section still unchecked, and 22A000 still in the RVA, do fix dump. Once again, it takes a while, and once its done, we see in LordPE that the import table location and size has been fixed for us just like last time. But unlike last time, when we try to run the exe, it works!

So, that wasn't so bad. By just clearing the .idata section before running ImpRec, and running ImpRec with the right options, we can be rid of the unnecessary .mackt section. Definately much easier than correcting all the imports by hand, no?

Regards,
Satyric0n

And again: Kotaus!
I'll try it at soon as possible...

At the moment I'm stuck with .data.
Okay. It contains 8 bytes for the relocation table at 2EA9C4 and the following 20 bytes are the TLS directory. My plan was to put those 28 bytes to the empty section at 22E000 and then change the directory entries for Relocation and TlsTable with LordPE.
After saving, the app runs, but if I try to delete the .data section - BOOM! - nothing...
I've checked the single fields in the TLS for references on addresses in the .data range, but nada.
So I suppose that .data contains some more information I need to relocate. But what may that be?

Regards
Wurstgote