Jump to content
Tuts 4 You

[unpackme] ExeCryptor 2.4.1 UnpackMe 2009


EvOlUtIoN

Recommended Posts

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

Link to comment
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 :blink: 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 :hug:

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 by ahmadmansoor
  • Like 1
Link to comment

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 by SunBeam
Link to comment

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

Link to comment

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

Link to comment

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

Link to comment
  • 2 years later...

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

Link to comment

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

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...