Exetools - Sentinel Manual Unpacking Question

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - Sentinel Manual Unpacking Question (https://forum.exetools.com/showthread.php?t=11759)

Sentinel Manual Unpacking Question

Hi,

I'm trying to decrypt code section of an sentinel shell protected PE Exe file.

I have read Cyberheg Tutorial "Braking the shell" form CrackZ site

hxxp://www.woodmann.com/crackz/Tutorials/Cyberheg4.htm

as he mentioned in his document, decryption routine is like this in c

Code:

do

{

        tResponse += (((tResponse << 4) + tResponse) >> 9) ^ (tResponse << 5);

        *(lpUnCryptedBuffer) = *(lpCryptedBuffer) ^ tResponse;

        Sum += *(lpUnCryptedBuffer);

        tResponse ^= Sum;

        ++lpCryptedBuffer;

        ++lpUnCryptedBuffer;

        --iCounter;

} while ((iCounter+1) != 0);

As I learned from his tutorial, we need to find current response which is a DWORD.

First Encrypted DWORD of my code section is: 0x3698ECAA and I know that it will be 0x00000000 when decrypted.

so I should look for a initial Reponse which make 0x3698ECAA in next Response and after xoring it with first DWORD, decrypted result will become 0x00000000.

to find initial response I made a simple code to bruteforce it, here is my code:

Code:

uint result;

for (uint tResponse = 0; tResponse < 0xffffffff; tResponse++)

{

    result = tResponse + ((((tResponse << 4) + tResponse) >> 9) ^ (tResponse << 5));

    if (result == 0x3698ecaa)

    {

        // I found the right initial response

        break;

    }

}

but it will not find any valid response.

decryption block in my target is looks like this:

Code:

00F990B4                 align 10h

00F990C0                 mov     ecx, [esp+8]

00F990C4                 xor     eax, eax

00F990C6                 shr     ecx, 2

00F990C9                 mov     edx, ecx

00F990CB                 dec     ecx

00F990CC                 test    edx, edx

00F990CE                 jz      short locret_F99108

00F990D0                 mov     edx, [esp+4]

00F990D4                 push    ebx

00F990D5                 push    esi

00F990D6                 lea     esi, [ecx+1]

00F990D9                 mov     ecx, [esp+14h]

00F990DD                 push    edi

00F990DE

00F990DE loc_F990DE:                             ; CODE XREF: _0000007:00F99103j

00F990DE                 mov     edi, ecx

00F990E0                 mov     ebx, ecx

00F990E2                 shl     edi, 4

00F990E5                 add     edi, ecx

00F990E7                 add     edx, 4

00F990EA                 shr     edi, 9

00F990ED                 shl     ebx, 5

00F990F0                 xor     edi, ebx

00F990F2                 add     ecx, edi

00F990F4                 mov     edi, [edx-4]

00F990F7                 xor     edi, ecx

00F990F9                 mov     ebx, edi

00F990FB                 mov     [edx-4], edi

00F990FE                 add     eax, ebx

00F99100                 xor     ecx, eax

00F99102                 dec     esi

00F99103                 jnz     short loc_F990DE

00F99105                 pop     edi

00F99106                 pop     esi

00F99107                 pop     ebx

00F99108

00F99108 locret_F99108:                          ; CODE XREF: _0000007:00F990CEj

00F99108                 retn    0Ch

An I missing a point regarding CyberHeg tutorial ?
or is there anything else I should mention ?

-ByteXorer

cyberhegs tutorial is actually based on kashmirs work with dvd maestro a long time ago. The key to both approaches is simple, that the 2nd dword is always valid due to a flaw in the design of the algorithm. Essentially the second dword always decrypts correctly. So make sure the 2nd dword is consistant with the section beginning of the first dword you are assuming to be 00000000. I would double check the 0000000 assumption based on looking at the data in the 2nd dword. i.e if you see some opcodes in the 2nd dword its very possible your first dword might not be what you think it is due to a incorrect assumpting. Your bruteforce looks approach looks fine (i cannot guarantee the code i didnt analyze), but the jist of the idea is just bruteforce the 32bit range while monitoring some chosen dword of your assumption. Also, one note, make sure the algorithm in C matches the algorithm in asm, I recall they had changed the algorithm slightly at some point, so you might be using a ready made algorithm which does not match your asm. Although, at a glance it looks correct. Good luck.

Thanks Sabor,

You were right, My assumption was wrong, I made right assumption for 3rd DWORD and it works fine. ! I got my target fully unshelled and it's working.

After decrypting 2 encrypted sections of sentinel ( code and data sections)
I made a simple search tool to find begining of first import descriptor in import table. and then I put the address in import Directory entry and also set currect address in IAT.

Then I found Original entry point by looking for a pattern I had from trial version of my target ( which was not protected by shell ) and set in header, and now the target runs well.

I would like to know

If OEM or Import table begining address are stored somewhere in sentinel sections ? or they come from dongle memory?
because it may not be possible to have OEP pattern, or import table begining address by scanning whole import section.

as I remember from long time ago, when I was developing my generic senitnel unsheller for sentinel shell ML-5.1 and ML-5.2 (SSUNSHL), these values could be found in memory while program runs with dongle attached.
but now the target will not run with sentinel shell without dongle, so I can not find those values on memory.

good work. last time i did a sent shell i left the wrapper intact and while in memory i patched in the proper dword (solved it seperately), this way the wrapper would pretend the dongle was actually inserted. After I did this I pretended it was a normal application and set a breakpoint on the decrypted code section; the first hit I got was obviously the oep. Many good unpacking masters simply dump the targets and look for the oep by hand, this is not uncommon, then go back and work from there. Regarding the iat, i recall it being very gay. I think 99% of iat is intact just like 2 apis are faked, which are easily traced. You can do a thread search on this forum or woodmann for those apis and find them. I do not recall entirely but it is would not dumb to assume that the queries which decrypt the code sections pretty much finish off the shell packer. I highly doubt any more queries related to the packing/iat are used after you get to oep aside from those 2 faked apis (or was it 1?). Have fun.