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!)
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 |
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 |
Quote:
Quote:
Quote:
Quote:
Regards, Satyric0n |
Quote:
|
Quote:
Quote:
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 |
Quote:
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...;)
Quote:
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:
Code:
00613654 . 55 PUSH EBP Code:
004073A0 /$ 53 PUSH EBX Code:
004072DC $-FF25 1CA36200 JMP DWORD PTR DS:[62A31C] Code:
01261C64 55 PUSH EBP 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 |
Quote:
|
Quote:
Quote:
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: Code:
001000 CODE Satyric0n |
last aspr section .adata is mostly 1000h size empty section.
i yet not meet any prog, which uses this section. |
Quote:
Quote:
Quote:
Quote:
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