Exetools

Exetools (https://forum.exetools.com/index.php)
-   General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)
-   -   Newbie question ASPR 1.23 RC4 (long!) (https://forum.exetools.com/showthread.php?t=3397)

Wurstgote 02-10-2004 20:06

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

Satyric0n 02-10-2004 21:29

Re: Newbie question ASPR 1.23 RC4 (long!)
 
1 Attachment(s)
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

Wurstgote 02-10-2004 23:00

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

Satyric0n 02-10-2004 23:13

Quote:

I've compared your tree with mine; there are a few differences
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.

Quote:

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?
Erm... No. ;) But, I'll explain further after you get this dump working.

Quote:

In any case I did a second dump at 4072DC, fixed IAT and OEP and entered the stolen bytes.
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?

Quote:

I encounter an access violation: EBX should store some value but in fact it's zeroed.
At what address are you getting this access violation?

Regards,
Satyric0n

Satyric0n 02-10-2004 23:19

Quote:

next I've got two more imports in my tree; one is FreeLibrary at 22ADE0 and RtlFreeHeap at 22AE20
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.

Wurstgote 02-11-2004 01:08

Quote:

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?
Yep, that's right. I've started again from scratch.
Quote:

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

Satyric0n 02-11-2004 01:14

Quote:

If you could spare some more time, would you please explain why I had to dump at 4072DC?
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

Wurstgote 02-11-2004 01:39

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

Wurstgote 02-11-2004 06:20

Sorry to waste your time, but here I go again...;)
Quote:

In the meantime, you should look into trying to remove those three extra sections. It makes good practice.
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

Satyric0n 02-11-2004 06:47

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

00613654  . 55            PUSH EBP
00613655  . 8BEC          MOV EBP,ESP
00613657  . 83EC 10        SUB ESP,10
0061365A  . B8 9C2D6100    MOV EAX,Resbldr2.00612D9C
0061365F  . E8 3C3DDFFF    CALL Resbldr2.004073A0
00613664  . 33C0          XOR EAX,EAX
00613666  . 55            PUSH EBP
00613667  . 68 B6366100    PUSH Resbldr2.006136B6
0061366C  . 64:FF30        PUSH DWORD PTR FS:[EAX]

Following the CALL at 61365F, we come to the following procedure:
Code:

004073A0  /$ 53            PUSH EBX
004073A1  |. 8BD8          MOV EBX,EAX
004073A3  |. 33C0          XOR EAX,EAX
004073A5  |. A3 C4406100    MOV DWORD PTR DS:[6140C4],EAX
004073AA  |. 6A 00          PUSH 0
004073AC  |. E8 2BFFFFFF    CALL Resbldr2.004072DC
004073B1  |. A3 68666200    MOV DWORD PTR DS:[626668],EAX
004073B6  |. A1 68666200    MOV EAX,DWORD PTR DS:[626668]
004073BB  |. A3 D0406100    MOV DWORD PTR DS:[6140D0],EAX
004073C0  |. 33C0          XOR EAX,EAX
004073C2  |. A3 D4406100    MOV DWORD PTR DS:[6140D4],EAX
004073C7  |. 33C0          XOR EAX,EAX
004073C9  |. A3 D8406100    MOV DWORD PTR DS:[6140D8],EAX
004073CE  |. E8 C1FFFFFF    CALL Resbldr2.00407394
004073D3  |. BA CC406100    MOV EDX,Resbldr2.006140CC
004073D8  |. 8BC3          MOV EAX,EBX
004073DA  |. E8 25D6FFFF    CALL Resbldr2.00404A04
004073DF  |. 5B            POP EBX
004073E0  \. C3            RETN

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

004072DC  $-FF25 1CA36200    JMP DWORD PTR DS:[62A31C]
004072E2    8BC0            MOV EAX,EAX
004072E4  $-FF25 18A36200    JMP DWORD PTR DS:[62A318]
004072EA    8BC0            MOV EAX,EAX
004072EC  $-FF25 14A36200    JMP DWORD PTR DS:[62A314]
004072F2    8BC0            MOV EAX,EAX
004072F4  $-FF25 10A36200    JMP DWORD PTR DS:[62A310]
004072FA    8BC0            MOV EAX,EAX

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

01261C64  55                        PUSH EBP
01261C65  8BEC                      MOV EBP,ESP
01261C67  8B45 08                  MOV EAX,DWORD PTR SS:[EBP+8]
01261C6A  85C0                      TEST EAX,EAX
01261C6C  75 13                    JNZ SHORT 01261C81
01261C6E  813D A47A2601 00004000    CMP DWORD PTR DS:[1267AA4],400000        ; ASCII "MZP"
01261C78  75 07                    JNZ SHORT 01261C81
01261C7A  A1 A47A2601              MOV EAX,DWORD PTR DS:[1267AA4]
01261C7F  EB 06                    JMP SHORT 01261C87
01261C81  50                        PUSH EAX
01261C82  E8 3135FFFF              CALL 012551B8                            ; JMP to kernel32.GetModuleHandleA
01261C87  5D                        POP EBP
01261C88  C2 0400                  RETN 4

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

Satyric0n 02-11-2004 07:08

Quote:

Originally posted by Wurstgote
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:

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

Wurstgote 02-11-2004 19:49

Quote:

Now do you understand why you need to dump at 4072DC?
Yep, I think I've got it; really good explanation by the way. Thanks!
Quote:

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

Satyric0n 02-11-2004 20:02

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

001000 CODE
214000 DATA
226000 BSS
22A000 .idata (original, but ruined by ASPR, import table)
22E000 ?? -- either this is .tls
22F000 ?? -- or this is .tls, I'm not sure which
230000 .rdata
231000 .reloc
252000 .rsrc
2EA000 .data -- this section is named randomly by ASProtect, and holds ASPR's IAT, some redirected resources, etc
312000 .adata -- this section is used as in-memory data storage by ASPR
313000 .mackt -- as you said, holds the new IAT created by ImpRec

Regards,
Satyric0n

evaluator 02-11-2004 22:08

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

Wurstgote 02-11-2004 22:10

Quote:

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.
I've just tried this out - works like a charm (of course after updating the other section's ROffset)!
Quote:

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
Till it gets boring I'll try it manually - I enjoy the "WOW! IT WORK'S!" feeling :)
Quote:

313000 .mackt -- as you said, holds the new IAT created by ImpRec
Okay. As for this one I could try to put it at raw location 226000 since there's enough space.
Quote:

2EA000 .data -- this section is named randomly by ASProtect
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


All times are GMT +8. The time now is 17:53.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX