Let me let you in on a little inside info. McAfee has a solution, but due to the size of the company does not apply it. as a part of the former Endeavor Security Team I’m working on the shell-code locator. this is my own project here and some modules were integrated into Active Malware Protection commercial product, now renamed to NTR. and it works!!! it did catch the worm giving the green flag (means: 99% chances of invasion).
long before McAfee exposed the interest to it, the locator was demonstrated to NDS company (Jerusalem, Israel), Sec++ Group (Tel-Aviv, Israel), Sense-Post company (Pretoria, South Africa), Soft-Forum (Seoul, South Korea) and many other hackers, so, basically, it’s a collective solution. it’s not only about me and my ideas… yeah, it was my idea from the beginning, but it has been improved over the discussions, and of course it was discussed inside our company, big thanks to Alice Chang, Kun Luo, Zheng Bu, Yichong Lin, Vitaly Zaytsev and many others.
ok, lets take the shell-code locator, feed the worm to it and check out what the heuristic module says:
+DETECTED FSTENV-based encoder @ 000002ABh
+KRNL32 BASE ADDR PEB FINDER @ 00000319h
XOR key: B9 8E A9 13 (13A98EB9h)
in fast, there is an encoder and the rest of the worm is encrypted, but it does not help the worm to escape. my shell-code locator was designed to perform heuristic search inside encrypted steams, without decrypting them, without emulation and of course without brute forcing because we should care about resources and we just don’t have enough CPU power for virtualization of any kind.
well, lets load the worm into HIEW and see the encoder with your own eyes (the picture bellow). wow! indeed, the encoder is located at the same address, but… it uses another key. just look at the following code (taken from the encoder) “XOR D, [EBX+13], 0A98EB913” and compare the key with my shell-code locator outputs: 13A98EB9h.
is my locator wrong?! not at all! because A98EB913h and 13A98EB9h is the same key, just rotated by 8bit. since, XOR is a stream operation, no matter which byte is first and which is the second if the offset is given. if we apply A98EB913h at 318h offset - we get the same result.
it proofs that my shell-code locator does not look for “XOR” in order to extract the immediate DWORD, (the plain key). my shell-code locator does need in it at all. if the encoder is missed or not recognized - never mind! isn’t impressive?
however, at this moment URI decoder (Chinese worm keeps the shell-code inside an unescaped string) is still under construction (pre-pre alpha stage of development), so the worm was caught by the internal version of the shell-code locator, but it inspires me to continue working on it.