#1
|
|||
|
|||
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 |
#2
|
|||
|
|||
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 Last edited by Satyric0n; 02-10-2004 at 21:43. |
#3
|
|||
|
|||
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 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 |
#4
|
||||
|
||||
Quote:
Quote:
Quote:
Quote:
Regards, Satyric0n Last edited by Satyric0n; 02-10-2004 at 23:38. |
#5
|
|||
|
|||
Quote:
|
#6
|
|||
|
|||
Quote:
Quote:
It looks as if exactly those two functions caused the problem: After deleting them, everything run fines! No more access violations Again: Thanks a lot! If you could spare some more time, would you please explain why I had to dump at 4072DC? Greets Wurstgote |
#7
|
|||
|
|||
Quote:
In the meantime, you should look into trying to remove those three extra sections. It makes good practice. Regards, Satyric0n |
#8
|
|||
|
|||
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 |
#9
|
|||
|
|||
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 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 |
#10
|
|||
|
|||
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] 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 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 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, 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 Last edited by Satyric0n; 02-11-2004 at 07:00. |
#11
|
|||
|
|||
Quote:
|
#12
|
|||
|
|||
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 |
#13
|
|||
|
|||
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 Satyric0n Last edited by Satyric0n; 02-11-2004 at 20:14. |
#14
|
|||
|
|||
last aspr section .adata is mostly 1000h size empty section.
i yet not meet any prog, which uses this section. |
#15
|
||||
|
||||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
one newbie question | SubzEro | General Discussion | 7 | 03-12-2015 06:05 |
ASPR, ARMA question | sgdt | General Discussion | 3 | 04-09-2006 03:38 |
ASPR 1.2 question | gabri3l | General Discussion | 42 | 05-01-2004 15:09 |
a newbie question about CRC32 | abccc | General Discussion | 13 | 04-23-2004 03:13 |
"newbie" question for crackers ;) | newbie007 | General Discussion | 4 | 10-07-2003 04:46 |