You remember the Duqu font related exploit and shell code in the dropper? Yes, that’s the exploit that was recently used in many exploit kits.
First of all, this is a kernel level exploit, it should be kept in mind while checking code.
The original dropper had a decryptor for the stage1 of shell code:
void __fastcall sub_1500(int a1, int a2)
{
int v2; // eax@2
int v3; // ecx@2
int v4; // eax@5
int i; // eax@5
if ( !dword_14FC )
{
v2 = 0;
dword_14FC = 1;
v3 = (unsigned __int8)dword_14F8;
while ( v2 != dword_14F8 )
{
LOBYTE(a2) = v2 ^ *((_BYTE *)sub_17C + v2) ^ v3;
*((_BYTE *)sub_17C + v2) = a2;
a2 = (unsigned __int8)a2;
++v2;
v3 ^= a2;
}
v4 = sub_158C(v2, a2, v3);
sub_17C(v4 - (_DWORD)sub_17C);
for ( i = 0; i != dword_14F8; ++i )
*((_BYTE *)sub_17C + i) = 0;
}
}
It’s not a complicated obfustation/crypto, the interesting thing is that it is not like the ones for Flame. The most similar thing is Stuxnet’s modules’s crypto, maybe later discussed.
The next level is still obfuscated. ntoskrnl.exe function calls are stored in a table by hash of the function call name, just like calls are obfuscated in other parts of Duqu. This is not unusal, but shows specific care on the module.
The hash-function relation table is costructed like under:
seg000:00001043 mov [esi+10h], eax
seg000:00001046 jz loc_11B2
seg000:0000104C push ecx
seg000:0000104D push ecx
seg000:0000104E push 0BF5CA508h ; ExAllocatePool, hash:bf5ca508
seg000:00001053 push edi
seg000:00001054 call sub_7FD
seg000:00001059 add esp, 10h
seg000:0000105C test eax, eax
seg000:0000105E mov [esi+14h], eax
seg000:00001061 jz loc_11B2
seg000:00001067 push edx
seg000:00001068 push edx
seg000:00001069 push 2973E9CCh ; export name: ExFreePool, hash:2973e9cc
seg000:0000106E push edi
seg000:0000106F call sub_7FD
seg000:00001074 add esp, 10h
seg000:00001077 test eax, eax
seg000:00001079 mov [esi+18h], eax
Note the constants 2973ECCh and similar. These are identifiers of ntoskrnl.exe exports (specific functions).
The hash calculation is done like this:
for ( i = 0; ; i += 7 * i * i + 12 * v8 + 17 * v8 * v8 )
{
v8 = (_BYTE *)v3;
if ( !(_BYTE *)v3 )
break;
++v3;
}
It’s not like encryption/obfuscation code for FLame. Maybe the exploit creators also provided this stage to the customers.
Based on this code function calls in the exploit can be recovered. And still, this is just one step among others to fully understand how original Duqu dropper worked…
A few sample values for hashes based on the function described above:
export name: AlpcInitializeMessageAttribute, hash:f8ab4ead
export name: CcCanIWrite, hash:c833f901
export name: CcCoherencyFlushAndPurgeCache, hash:41ab559d
export name: CcCopyRead, hash:99b1f488
export name: CcCopyWrite, hash:96bc06d5
export name: CcCopyWriteWontFlush, hash:210fdfb4
export name: CcDeferWrite, hash:038897a1
export name: CcFastCopyRead, hash:1e3c8f5c
export name: CcFastCopyWrite, hash:c1874039
export name: CcFastMdlReadWait, hash:2eea7438
export name: CcFlushCache, hash:0a30abdd
export name: CcGetDirtyPages, hash:cc24ab45
export name: CcGetFileObjectFromBcb, hash:8244f064
export name: CcGetFileObjectFromSectionPtrs, hash:9406fe99
… possibly TBC…