|
|
#1
08-03-2008, 21:38
|
|||
|
|||
|
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;
}
}
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 
|
|
#2
08-04-2008, 10:00
|
|||
|
|||
|
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.
|
|
#3
08-07-2008, 14:50
|
|||
|
|||
|
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.
|
|
#4
08-07-2008, 18:39
|
|||
|
|||
|
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.
|
 |
| Tags |
| sentinel, spro, unshell |
|
|
Linear Mode
