[unpackme] ExeCryptor 2.4.1 UnpackMe 2009

[LCF-AT]

Hello,

nice work SunBeam. First your file dosen´t run.But this you mean with this right "Don't expect it to run, I'll explain "

0054D350 >  60                PUSHAD
0054D351    6A 40             PUSH 40
0054D353    68 00300000       PUSH 3000
0054D358    68 00301300       PUSH 133000
0054D35D    68 00B04129       PUSH 2941B000
0054D362    FF15 C4B04B00     CALL DWORD PTR DS:[4BB0C4]  <---- NO API
0054D368    B9 00301300       MOV ECX,133000
0054D36D    BE 00B04100       MOV ESI,41B000
0054D372    BF 00B04129       MOV EDI,2941B000
0054D377    F3:A4             REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
0054D379    61                POPAD
0054D37A    68 00194000       PUSH 401900
0054D37F    C3                RETN
------------------------
APIs not there so I just added the names.
004BB0B4  7C80B741  GetModuleHandleA
004BB0B8  7C801D7B  LoadLibraryA
004BB0BC  7C80AE40  GetProcAddress
004BB0C0  7C81CB12  ExitProcess
004BB0C4  7C809AF1  VirtualAlloc
004BB0C8  7C809B84  VirtualFree

Ok after this fix I tried your file with your explanation.I come till the here..

2949BEE5 55 PUSH EBP
2949BEE6 8BEC MOV EBP,ESP <-- we step over this line with F7

Now set HWBP on access in ESP or EBP / before I removed the access violation hook in Olly.

Now I break in a access violation...

EAX 7C8308B5 <-------- NO API
ECX 0012FF80
EDX 294AABD4
EBX 7FFDF000
ESP 0012FF70
EBP 0012FFBC
ESI 77C42D7E GDI32.77C42D7E
EDI 00000000
EIP 7C8308B5  <-------- NO API
-----------------
0012FF70   294B6EED  RETURN to 294B6EED from 2941F64B
0012FF74   00000000
0012FF78   FFFFFFFF
0012FF7C   00000000
0012FF80   00000000

So here is the first problem so on your system its the 7C8308B5 CreateEventA API which is for me 77E537DE.After this comes the next one CreateThread.

7C8308B5  CreateEventA  77E537DE <-- For me
7C8106D7  CreateThread  77E5AC37 <-- For me

So did I understand you wrong or where is the problem?

greetz

[ahmadmansoor]

@LCF-AT : my friend the problem not form SUNBeam .. the problem came from ImpRec it self ... I have try this before .

I have unpacked some files before and when fix IAT by ImpRec ...

then when I trying it on different PC ( maybe different OS - like form XP SP2 to XP SP3 or Vista or Win 7 - and specially Win 7 ) I find that IAT not work and the file Crash .I open it with Olly and find that all IAt not be loaded in the file !!! ..

so I have fix this problem by use CHimpREC It work very fine , if u want to be sure of what I say ,let SunBeam fix Iat by CHimpREC .. then u can check his unpacked file ..

@SunBeam : I think ur unpacked file could work ...I hope u fix Iat problem to check it .

Thanks for ur nice work

note :

@LCF-At : look at this address at SunBeam unpacked file.

004BB0C4 7C809AF1 ٌڑ€|

as u see it has a value which could be consider as API address (in his PC ).

if we suppose that he didn't fix Iat the value could be like this :

004BB0C4 00C09AF0 ٌڑ€|

I hope u got the Idea.

Edited April 18, 2010 by ahmadmansoor

[SunBeam]

Yeah, my bad. I fixed IAT with ImpREC and forgot to update the CALL to the newly VirtualAlloc-appointed API :-) Change:

0054D362	FF15 C4B04B00 CALL DWORD PTR DS:[4BB0C4] 	; kernel32.VirtualAlloc

to

0054D362	FF15 30444000 CALL DWORD PTR DS:[404430] 	; kernel32.VirtualAlloc

Posting more in a giffy..

Edited April 18, 2010 by SunBeam

[LCF-AT]

So the normal IAT by SunBeam is ok so it was just the few others wich I have post above.So its also clear that you can just fix the IAT on one place and also just one time.If you have some more Imports on a other place then you can just add them as single Imports.For me I just always use ImpRec and had also no problems till now.

So now I have just the problem that I get the access violations in SunBeam´s unpacked file and it breaks at 7C8308B5 which is no API on my system but for SunBeam it should be the CreateEventA API.I mean I changed alraedy the VirtualAlloc address correctly before and then I tried the steps which SunBeam has postet above and also with SunBeam`s file.

@ SunBeam

So do you mean now that your Unpacked file should run on our systems or do you just mean that we have to do the same with our file?

greetz

[SunBeam]

I don't know how EXECryptor behaves when it internally uses VirtualQueryA/W or the other APIs. But once I relocated the unpacked sections, it behaves very strange (access violations). I'd try and create a mapping between in-file sections and the allocations, but I don't know how to do that.. Like, for instance @OEP -> JMP VM (allocated) -> remap to VM section in the file.. Something like that..

[SunBeam]

LOL. Condition is set via a flag :-)

294AE1A7 85C0 TEST EAX,EAX

Set breakpoint there (hardware) and see what happens when playing with EAX 0/1 :-)

[SunBeam]

Back on this thread. I know it's been two years, but man oh man does the time fly like a motherf***er :\

@LCF-AT:

In the attached file I used the initial reference of VirtualAlloc, not taking into account that the value of that pointer came from EXECryptor's IAT. When running up the file, Windows retrieves the table and fixes the references automatically (check out the raw file, you won't see that API address at that location - address 4BB0C4, offset BB0C4, but an RVA to the location in Imports Directory where the corresponding API elements reside: string to API, pointer to IA table where it should be saved after being resolved and Hint ordinal). Since I dumped the file and changed IAT, then this pointer will not be resolved by Windows loader, so I had to use the newly created one (new IAT ImpREC made).

Now, LCF pointed out that the unpacked file still dies at some point and he checked the stack to point out the issue. I started thinking - if file crashes, the that might happen due to unresolved pointers - same logic as with the above, where Windows loader didn't fix the API pointer. So, in this situation, before hitting EP, EXECryptor runs code from TLS, code which <might> resolve API pointers used later on by EC.

With that in mind, I loaded up the target and set a hardware breakpoint on write at first byte of 2941B000 section. Code in charge of unpacking the sections is here:

29543B31 E8 07FEFFFF CALL 2954393D

Set a hardware breakpoint on execution there and run up the target. We're interested in first 4 breaks (first 2 breaks will take a bit, since code runs through the high-memory EC loader, so DON'T PANIC if Olly freezes for a bit), and each time check stack to know which section was previously unpacked:

1: $ ==> > 00401000 execrypt.00401000

2: $ ==> > 00403000 ASCII "execryptClass"

3. $ ==> > 00404000 execrypt.00404000

4. $ ==> > 2941B000 execrypt.2941B000

After 2941B000 section is unpacked (at 4th break, remove HWBP on 29543B31), set up a breakpoint on write on it. Now let's find out what EC "fixes"/fills ;-) Running, I got these:

1. 294BB174 8906 MOV DWORD PTR DS:[ESI],EAX

Here, EC will run a loop which fixes the code in the whole section, mostly JMPs/CALLs with correct calculated values. As an example, check the first break:

2941B002: CALL F7B5AE06 is corrected to CALL 2949180A2

2. Remove memory breakpoint, break at 294BB181, run. Once at RETN, whole section has been processed. My posted unpacked file contains these fixes already. Next up, set the breakpoint on write again on this section, 2941B000 so we catch the fixed DWORDs. Run.

3. Breaks in order of succession:

294577A1 FF05 14AB4A29 INC DWORD PTR DS:[294AAB14]

..

29454FFE C600 C3 MOV BYTE PTR DS:[EAX],0C3

..

294B565C C600 C3 MOV BYTE PTR DS:[EAX],0C3

..

29453B0F F0:8710 LOCK XCHG DWORD PTR DS:[EAX],EDX

All the above are not to our interest.

4. Next breakpoint is:

29495063 A3 C4F24629 MOV DWORD PTR DS:[2946F2C4],EAX ; kernel32.GetModuleHandleA

Continue these breaks and map all retrieved APIs, We'll need to fix these pointers once the allocation/copy is done in unpacked file I posted. You should repeat this process untill you hit EP, which is at 2954CC91.

Also keep in mind we have to try and see if there are pointers being fixed also in other places, BEFORE hitting EP. I'm starting to wonder if I should continue the process up to the point where app hits OEP (or near OEP) and map what I got versus what I allocate/copy.

Will be back with a full listing and fixes ;-)

BR,

Sun

[SunBeam]

Well, I am a bit off above - EP is hit first, then comes the fixing. Correction would be - run the logic above till you hit OEP or near OEP, to have all fixes you need for fixing the dumped file I posted