Newbie question ASPR 1.23 RC4 (long!)
 

Hi all,

after reading a lot of tutorials and threads here and at woodmann about the above mentioned packer I've decided to try to unpack one prog on my own (Resource Builder 2.1 that you can download at
hxxp://www.sicomponents.com) and failed completely.
It would be very nice if someone could check the steps I've taken so far:

1. When loading the prog with Olly, it becomes clear that two packed DLLs are used. To get to the entry point of the exe I've used arz's anti-debug+lastex script. I've ended up at address 401000.

2. After another go with that script I've got to
016139EC XOR DWORD PTR DS:[EAX],EAX
016139EE POP DWORD PTR FS:[0]
016139F5 POP EAX
016139F6 CMP DWORD PTR DS:[1617EB0],0
and put a BP on the next RETN; SHIFT-F9 got me there.

3. I've done a conditional trace with TC EIP<900000 and ended
at
004072DC JMP DWORD PTR DS:[62A31C]
004072E2 MOV EAX,EAX
F8 took me back to the ASPR code; after another TC EIP<900000 I've landed her:
004073B1 MOV DWORD PTR DS:[626668],EAX
004073B6 MOV EAX,DWORD PTR DS:[626668]
004073BB MOV DWORD PTR DS:[6140D0],EAX
004073C0 XOR EAX,EAX
004073C2 MOV DWORD PTR DS:[6140D4],EAX
004073C7 XOR EAX,EAX
004073C9 MOV DWORD PTR DS:[6140D8],EAX
004073CE CALL app.00407394
004073D3 MOV EDX,app.006140CC
004073D8 MOV EAX,EBX
004073DA CALL Resbldr2.00404A04
004073DF POP EBX
004073E0 RETN
According to Labba's tut the value of EAX after execution of 4073D8 is important to reconstruct the stolen bytes, because that's the value EAX needs (here it's 612D9C).
The RETN takes me to the fake OEP at 613664.

4. Now I've dumped the app with ProcDump.

5. I started ImpRec, selected the running app, did an IATAutoSearch, changed the resulting RVA size to 1000, got the imports and fixed some of them with AutoTrace. There were still a lot of invalid ones. I've fixed those that pointed to ASPR code manually and the rest (pointing to invalid code) were killed with cut thunks (the resulting tree is attached below). Now the dump from 4. was fixed.

6. Next hunting for stolen bytes: I've tried it the Labba way (at the end of 2. do a TC REP STOS BYTE PTR ES:[EDI] to get to the place where the stolen bytes are erased, replace the command with JMP EDI and F8/NOP violations till you get to something like
PUSH EBP; MOV EBP,ESP <- start of stolen bytes) but that didn't work, cause I always end up at a JMP that sends me to Nirvana.
What I did instead was logging the first trace in 3. The resulting run log ends with a lot of REP STOS BYTE PTR ES:[EDI], but just before those you can find the erased code, which is marked by Olly.
So I've ended up with
PUSH EBP
MOV EBP,ESP
SUB ESP,0x10
MOV EAX,app.612D9C (from 3.)
Those stolen bytes (all in all 11) were put just before the call at 61365F; the OEP should then be 613654.
I've fixed the OEP with LordPE's PE Editor and hoped everything was fine... but nada!
Evidently something went utterly wrong. But what??

Would be nice if someone of you experts could give me a hand on this one...

Thanks in advance
Wurstgote

Re: Newbie question ASPR 1.23 RC4 (long!)
 

You had 99% of it right. What you did wrong was dump it in the wrong place.

This is funny to me, because when I was first learning to unpack ASProtect (ASProtect was the first packer I learned to unpack manually, I skipped UPX and other easy ones to go straight for the good stuff ;)), I did the exact same thing, and it kicked my ass for like 2 days.

For this app, dump at 4072DC. (I use LordPE to dump, though I suppose it doesn't make any difference.) Your OEP is correct, your stolen bytes are correct, and assuming your IAT is correct, you should be good to go. I have attached my IAT just in case.

Assuming that works for you, now we come to the important part: do you understand why you need to dump at 4072DC? If not, I will explain it.

Also, for fun with ASProtect, there are 2 things you can do after unpacking to do a more efficient/thorough job. After fixing the IAT with ImpRec, open the resulting file in a PE editor, and look at the list of sections. You will see 2 or 3 unnecessary sections: 1 or 2 from ASProtect (called .adata and such), and 1 from ImpRec called .mackt. These are unnecessary and just make the file bigger, but there is something of a trick to getting rid of them all. Doing so will make the resulting file smaller, and more like (if not identical to) the original file pre-packing. Your final resulting file should not have these 2 or 3 extra sections, if you want unpack thoroughly. After removing these, rebuild PE using PE Tools to remove slack space, and you will have a perfect unpack. Again, this just makes the resulting file smaller, and isn't really necessary, but sometimes it's fun to be extra thorough.

Regards,
Satyric0n

First... thanks a lot for your fast help!

I've compared your tree with mine; there are a few differences: Since I'm running Win2K I can't use RestoreLastError, so I replaced it with SetLastError; next I've got two more imports in my tree; one is FreeLibrary at 22ADE0 and RtlFreeHeap at 22AE20, but that should give no problems... at least I hope so :)

For why to dump when address 4072DC is reached I can only guess. Since the JMP there takes me back to ASPR code I could imagine that some of the code that the unpacked app needs for execution is manipulated by ASPR in some way, so if I dump later I dump this manipulated code. Am I on the right way?

In any case I did a second dump at 4072DC, fixed IAT and OEP and entered the stolen bytes.
Nevertheless the app refuses to run :confused:
So, up again in Olly and singlestepping through the code a while I encounter an access violation: EBX should store some value but in fact it's zeroed. Is it possible that I've missed some stolen bytes or do I have to NOP the call to that part of code?

Thanks again
Wurstgote

These are due to the fact that you're running Win2k then, I would guess; I'm running XP SP1. So maybe your IAT is wrong, maybe not, I have no way to verify.

Erm... No. ;) But, I'll explain further after you get this dump working.

To make sure I understand you, by "a second dump" do you mean you started again from scratch (using packed exe), or you redumped starting from your previous nonworking dump?

At what address are you getting this access violation?

Regards,
Satyric0n

Upon reviewing the IAT, these definately should not be here, just by the fact that their location is far past the table. I'm not sure if having these in would cause the dump to fail, but you had better remove them regardless.

Yep, that's right. I've started again from scratch.
I think you're right. I'll kill them as fast as possible!

It looks as if exactly those two functions caused the problem: After deleting them, everything run fines! No more access violations :D
Again: Thanks a lot!
If you could spare some more time, would you please explain why I had to dump at 4072DC?

Greets
Wurstgote

Yes, I will. It will take me a while to write up, though. Mostly losts of commenting and pasting code.

In the meantime, you should look into trying to remove those three extra sections. It makes good practice. ;)

Regards,
Satyric0n

Kotaus to you, Sir, I really appreciate your more than valuable help!

I'm not quite sure if it will be fun, but I'll give it a try and start fiddling about those extra sections...

Greetings
Wurstgote

Sorry to waste your time, but here I go again...;)
The first thing that I've tried out to get rid of dispensable sections was to open the unpacked app in a hex editor and take a look at the different sections as indicated by ROffset in the PE Editor of LordPE.
By this way I've found out that for example .adata contains no 'real' data but instead it consists of 4096 (=0x1000) zeros (that's exactly its virtual and raw size). I think, because of this, the whole section can be deleted. So I've wiped the corresponding section header and adjusted the next section's (.mackt) ROffset from 313000 to 312000. With the hex editor I've erased the afore mentioned 4096 bytes and safed the resulting file.
Next I've opened the resulting file again with PE Editor and changed SizeOfImage from 316000 to 315000, hoping that would do the trick.

Guess what? It didn't work :rolleyes:

Perhaps it's time to have a closer look at how a PE file really works and try to fix things only in a hex editor :)

Greetings
Wurstgote

Ok, basically the idea when you dump the process is to dump while as close as possible to the OEP. Let's trace through the code from OEP (before dumping) and see what the first piece of code we can dump at is. We start here:
Following the CALL at 61365F, we come to the following procedure:
Ah! We see the CALL at 4073AC lands at 4072DC, which is the first place we land at with the TC EIP<900000 you ran earlier (all the code we saw before coming to 4072DC was emulated/implemented in some fashion by ASProtect, including usage of the stolen bytes). When you were dumping at 613664 before, you were dumping much farther from OEP than 4072DC, because you don't get to 613664 until all the code in this procedure executes and returns (which a run trace shows as totaling 332335 instructions, not counting system code... No small amount!). In fact, the code in this subroutine does some data morphing (using the data block between 612D9C (note a key part of our stolen bytes) and 61364C), and doing that before dumping causes the dumped exe to fail. But, it's Delphi code doing the morphing (standard code for any Delphi program), not ASProtect code like you thought. Lets investigate this a little further... Lets follow the call at 4073AC:
The data at/surrounding 62A31C is actually a thunk in the import table. Before fixing the IAT, this jumps to 1261C64 (you will see where it jumps to after fixing the IAT in a minute..), which as you had said earlier, is ASProtect code. Let's follow it, and we see this procedure:
So, it does some stuff, then calls 12551B8, which as Olly noted, is a thunk jumping to 77E7AD86, which is in GetModuleHandleA. Well, one of the protection mechanisms ASProtect uses is kernel32 function emulation. Basically, certain kernel32 functions in the IAT are redirected into ASProtect code which has some arbitrary instructions then turns around and calls the kernel32 function itself.

So, at 4073AC and 4072DC, though it looks like some ASProtect code is getting called, really, it is just GetModuleHandleA getting called.

Now do you understand why you need to dump at 4072DC? :)

Regards,
Satyric0n

Note that there are three extra sections in this particular app (assuming you have fixed the IAT using ImpRec in the normal manner): .data, .adata, and .mackt. In other words, everything after the resource section (this has been the case in every ASPR'd app I have seen).

Yep, I think I've got it; really good explanation by the way. Thanks!
Okay. I can see those three sections.
Lord PE gives me the following section table

ROffset
001000 => Code
214000
226000 => 0x4000 zeros in file
22A000
22E000 => 0x1000 zeros in file
22F000 => 0x1000 zeros in file
230000
231000 => 0x21000 zeros in file
252000 (.rsrc)
2EA000 (.data)
312000 (.adata) => 0x1000 zeros in file
313000 (.mackt) => contains IAT

Now I'm not sure about those zero sections. Would it be possible to delete them? I imagine this: Delete, for example, those 0x4000 bytes at ROffset 226000, so file size decreases by 0x4000.
The NumberOfSections becomes 11 instead of 12 and all ROffsets of the sections that come after the deleted one must be decreased by 0x4000.
Would the PE loader be able to load the resulting file correctly?
I don't know, because the 0x4000 bytes in memory at VA ImageBase+0x226000 are no longe initialized with zeros; this part of memory isn't even covered by the section table anymore.
I think I should conduct some experiments... :)

Regards
Wurstgote

All of the sections up until 2EA000 were created by the Delphi compiler, so I would leave them there (remember that data morphing? Delphi is probably filling those sections with data in memory).

But, since they're not holding anything physically on disk (and are essentially just wasting space, as you noted), what you can do is leave the section headers in the PE header, delete their physical storage in the file (such that RSize is 0), and set their RSize to 0 in the section header. This way they do not take up any physical size on disk, but still exist in memory when the app runs (consuming VSize KB in memory) so the Delphi code can access them like it needs to.

The good news is, you dont have to do this yourself. A good PE Rebuild process (like the one in PE Tools) will detect that a section is all 00s, and do this exact thing for you. So leave those alone, and since it is best to do a Rebuild PE once you're done editing the file anyway, just let PE Tools do all the work. The only sections you need to worry about are the ones after .rsrc.

But I'm glad you brought this up, it shows that you are thinking about what you're doing, and not just blindly following someone else's tutorial/instructions. :)

FYI, those sections are:
Regards,
Satyric0n

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

I've just tried this out - works like a charm (of course after updating the other section's ROffset)!
Till it gets boring I'll try it manually - I enjoy the "WOW! IT WORK'S!" feeling :)
Okay. As for this one I could try to put it at raw location 226000 since there's enough space.
Hmmm... this section's raw size is too big to put it somewhere inside a zero block. What should I do now?
All in all I should be able to reduce the file size by nearly 160000 bytes, perhaps some more when fiddling with the alignment.
So... here we go!

Thanks again
Wurstgote

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? ;)

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).

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).

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!
Hmmm... you're right about that :(
So I'll have to see if I can fix that.

Regards
Wurstgote

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

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:
Yes, I know. I'm afraid this will be another long, long evening... *sigh*
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.
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.
Ahh... good thing to know;) Thanks!

Regards
Wurstgote

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 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!
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 ;)
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

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 :rolleyes:
So it's time to rethink the matter!

Regards
Wurstgote

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

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:Regards

Too late for that - I've managed to relocate the IAT :D
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 :D

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. ;)

:) .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

Remember, the things that ASProtect relocates, it usually corrupts (such as the IAT), but those things did have an appropriate position in the file before being packed (again, like how the imports should go in the .idata section). 22E000 would not be the appropriate place for both relocation and the TlsTable (if either of them; I'm stil not sure what the 22E000 section is for), then, since they were in seperate sections before being packed.

Also, keep in mind that when a section is all 00s, it is probably uninitialized data (such as BSS), and anything you put there will be overwritten at runtime.

Regards

Okay, I've tried something else.

1. Relocation table: Taking a look at 2EA9C4, it seems clear that the relocation table is empty, since there is only the header of the fix-up block (manipulated by ASPR?). I pushed that part to 231000, since there should be the original rel. table. After that I've fixed the directory table entry to 231000. No problem.

2. Thread Locale Storage: Examining addr 2ea9cc (place of TLS directory), I've found the following data:
Raw Data Start: 62F000 (- base = 22F000 => empty section)
-"- End : 62F01C
Index : 6140C4 (some zeros inside of .data)
Callbacks : 630010 (-base = 230010; hmmm... looks interesting, since at 630000 there's an exact copy of the TLS at 2ea9cc...)
Size of Zerofill : 0
Characteristics: 0

First I've simply tried to transfer those 24 bytes to 22e00 and fix the directory table entry for TlsTable accordingly. It works, as long as I don't delete the .data section :confused:

Now I've got not the slightest idea on how to proceed...
At the moment, I'm trying to find out if any code in the .data section is executed, but it doesn't look like that would happen.

So I'm afraid I'll need another hint :rolleyes:

Regards
Wurstgote

Sorry, some corrections:
Should have been DATA (according to the section names you gave me on page 1 (?) of this thread)

Errr... only one correction. I suppose I'm getting braindead ;)

This is a perfectly acceptable solution, although there is a better one yet. What you can do is change both your Relocation RVA and Size to 0, then in your PE Characteristics, set the Relocation Stripped flag. That way, you don't even need the header, and can simply delete the .reloc section's physical data and set its RSize to 0 in the section header. You might even be able to be rid of the section entirely, and wipe the section header out of the PE header, but I have never tested it; I'm always hesitant to delete sections created by the compiler, maybe I'm just too cautious... ;)

I'm not sure if this would cause problems or not, as I'm not entirely sure what the section at 22E000 is for. It certainly could work, as the thing that's causing your exe to not run after you remove the .data section is not related to TLS. Needless to say, I have a different solution than yours; not to say that mine is a better solution, but it is different. The only thing I have against your solution is my general hesitation to copy data to 00'd out sections, as those sections are usually initialized at runtime and data you put there has a tendancy to get overwritten.

This is a good observation... Run with it! ;)

Reread my description of what the .data section is. There are more things relocated in that section that the Relocation table and TLS table. :D

Regards

Hey, I've never had thought of this! But, since it's empty anyway, why not kill it completely?
Perhaps simply setting the TlsTable entry in the Directory Table to 230000?
Considering the Tls Table, I think there is nothing else to fix.
I've done that (good advice, by the way!) and I must admit that my eyes got it, but my brain must have been on holiday;)
As you've stated, ASPR also transfered some resources to the .data section...
So the first thing I've done was to study the structure of the resource tree. After I've understood what it's all about, I've used ResourceHacker to take a closer look at all the resources. By this way it became obvious that perhaps Icon Group, VersionInfo and the last resource "24" need a relocation.
So I walked the resource tree and found out that data for all three goups really is in the .data section. I've managed to relocate them back to the .rsrc section, but sweet Jesus, if I thought putting the IAT table back in place was tedious, I for sure don't know an adequate word to describe this piece of work;)

Now my question is: Do you know of any tool that I can use to browse the resource tree of an app and that shows at each node to address where this node is stored? I've tried ResHacker (doesn't work) and PE Explorer (can read all resources but doesn't show addresses; also I can't use it to "repack" the resources).

Any hint would be appreciated, since I believe that that should be the last thing to do before .data can be deleted.

Regards
Wurstgote

:D.. I do know what you mean.

Here is what I do to fix the resources:

When my exe is at the point that I want to fix the resources, I make a copy of the exe. So now I have 2 identical exes: Resbldr2.exe and CopyOfResbldr2.exe

Now, I load my first exe (Resbldr2.exe) into a resource editor (personally, I just use Visual Studio, since it does a good job and I already have it installed; so I know this process works with VS, but I can't guarantee that it will work with another resource editor), and simply delete all resources that fall in the offending section: in this case, the 3 icons, the version info, and RT_MANIFEST (what you called 24). Save that and close it, and now, .data in your first exe should have no resources in it. (It is at this point that I go and delete the .data section and wipe its section header from the PE.)

Now, open both exes in your resource editor. In your second exe (CopyOfResbldr2.exe), select all the resources that you deleted in the first exe and Copy them (standard clipboard Copy is what I'm referring to), then paste them into your first exe. Save the first one, then close both files (and now you can delete CopyOfResbldr2.exe). When VS saves the changes, it puts the new resources you've pasted in into the .rsrc section, as it should. Now you have successfully transplanted the resources from the .data section to the .rsrc section, without a lot of hassle. :)

One note, VS, when it saves the resource changes, screws up the VSize of the .rsrc section for some reason. So once I'm done I go into LordPE and fix .rsrc's VSize back to the same as RSize.

Indeed, you are correct here! Congratulations, most people wouldn't have bothered to even try these things, muchless follow through all the way (and by hand, as you did, at that) ;). I hope you learned a good bit about PE structure in the process :p.

Now, there are 2 problems left with your exe. One you will notice immediately once you remove the .data section and try to run the app. The problem you will see is much the same as the problem when you try to get into the program's Options (though the way I fixed those two problems is very dissimilar).

Lucky for you, you chose a very easy app to begin learning ASPR with. Once you get this all finished, I'll give you a link to an app that actually uses ASProtect effectively ;).

Regards,
Satyric0n

That's a pretty cool idea!
I'll give it a try as soon as possible.
Nevertheless you still have to identify those resources in the to-be-deleted section.
I'll have to think about that. There must be an easy way to accomplish that task - and if I'll have to write a small app to do it;)
Thanks! You were right: It was a lot of fun :D
Believe me: more than a bit. But only due to my more than capable teacher:)
I'll take a look at those this evening... With a cool beer or two...
Makes me curious :cool:

Regards
Wurstgote

Indeed, there is :D. This is fairly easy using LordPE. Basically, just get the offset of the section immediately following the resource section (in this case .data, offset being 2EA000). Next, go into Directories and click the ... next to Resource. For every item you click on, you can see the Selected Item RVA. Just expand all the nodes in the tree, then you can just scroll through very quickly (just holding the down arrow key basically), and look for any items with RVA of 2EA000 or higher. Most are much lower, so ones nearing or above 2EA000 tend to jump out at you. In this case, there are all the icons (including the group icons), the version information, and "24" which is really a constant representing RT_MANIFEST (typically seen in Delphi and C++Builder apps).

So, easy as this is, there is still better news: every ASProtected app I have ever seen, relocates only these exact items: Icons, Version Info, and RT_MANIFEST (if it exists). So, though I always double check to see that there aren't any others that have been relocated, I have never seen any other than these three types.

Of course, writing a small app to identify these for you (or even relocate them for you) would also be another good learning process, and maybe more fun ;).

I'd recommend a Guinness, but you live in Europe I think, and all the beers there are good :p. Here in the USA we have to buy imported beer to get anything that doesn't taste like piss.. ;)

Regards,
Satyric0n

Uahhhh... Shame on me :eek:
Perhaps next time I should play a little with the software I'm using instead of mindlessly crying for help...
Identifying AND relocating... good idea and something like this wouldn't be too hard to code I guess.
Guinness would be fine, but the bottled one you get over here in Germany is spiked (?) with carbon dioxide instead of nitrogen, so it's no more creamy at all :(
Try to get your hands on one of those hellish beverages they "produce" (don't know the word for "putting gross stuff (including strawberries!!!) in a bowl and wait one or two centuries till it freaks the hell out of any human being") in Belgium... you'll wish you would have sticked to your local stuff :D

Regards
Wurstgote

It's me again ;)
I'm sorry, but the first problem has to stay unfixed for some time. I've got no tool at hand (ehhh... except my hands and brain, and both are as fast as a dead cat;)) to relocate the resources in the .data section, so for the moment, I'll leave those resources where they are.
Nevertheless I've managed to make the "Options" menu available.
First I've tried to follow britedreams suggestions, but either his ideas were way beyond my head or Win XP behaves different than Win 2K.; so I had to do it on my own.
I've loaded the dumped app into Olly and let it run. As soon as I try to access the "Options" in the "Tools" menu, Olly pops up with an access violation at 57891e.
The code around looks like this:

0057890C /$ PUSH EBP
0057890D |. MOV EBP,ESP
0057890F |. PUSH ECX
00578910 |. PUSH EBX
00578911 |. MOV EAX,DWORD PTR DS:[40781E] ;<&kernel32.GetModuleHandleA>
00578917 |. MOV EBX,DWORD PTR DS:[EAX]
00578919 |. PUSH DWORD PTR DS:[EBX]
0057891B |. MOV DWORD PTR SS:[EBP-4],EBX
0057891E |. POP DWORD PTR DS:[EBX]
00578920 |. MOV EAX,DWORD PTR SS:[EBP-4]
00578923 |. POP EBX
00578924 |. POP ECX
00578925 |. POP EBP
00578926 \. RETN

So I've put a breakpoint on 578911 and single-stepped through the code. At 57891E, the code doesn't make any sense to me... Changing data in kernel32.dll wouldn't work, so I've changed
0057891E |. POP DWORD PTR DS:[EBX]
to
0057891E |. POP DWORD PTR DS:[EAX]
and everything's okay.
Next I'll have to code that small app I've mentioned, just to see if I can get rid of that problem at startup you've talked about

Regards
Wurstgote