# MS DirectShow MPEG2 (msvidctl.dll) worm was fired out!

Internet is under attack, the Chinese worm hits, disease is spreading fast, the number of infected machines is grown rapidly. it’s a new outbreak!

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:

$shell-codes_locator_v3.exe stream.bin
+DETECTED FSTENV-based encoder @ 000002ABh
+KRNL32 BASE ADDR PEB FINDER @ 00000319h
XOR key: B9 8E A9 13 (13A98EB9h)
#GREEN

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.

FSTENV-based encoder recognized by my shell-code locator

FSTENV-based encoder recognized by my shell-code locator

Tags: , , ,  

5 Comments

  1. good job! your locator works very good, but what about obfuscated/morphed code. Unfortunately I spent a lot of time with morphed code and it is getting more and more a big problem….

  2. I wrote a deobfuscator in the past for a company who does not allow me to reveal its name, it was x86/x86-64 deobfuscator (extended to support ARMle). McAfee is interested in JavaScript deobfuscator and our team is working on it, but nobody is interested in x86/x86-64 deobfuscator. what’s a pity! yeah, it handles morphed code too, recognizing viruses and cares about CPU and memory resources, because it’s oriented on IPS and steam processing, where we don’t even know what we’re dealing with — maybe it’s MPEG or machine code…

  3. I was analysing some emulators (for my company) and they are drivers in kernel mode, Win, and very good obfuscated. Entropy level do not show something strange – usual code. I have done some dummy DLLs like ntoskrnl.exe for user
    mode and then unpack them in Olly. But what I saw was incredible: one usefull command follow 20-30 garbage commands, but not easy to understand: highly sophisticated use of stack and registers.

    Hackers use Open Source crypt libraries for RSA/ECC in obfuscated form, and they are getting more and more difficult to defeat. And morphing engine is obfuscated new in next exe.
    I suspect x86/x86-64 deobfuscator will become more important. After some new viruses companies will wakeup :)

  4. well, to write a new deobfuscator that “normalizes” code and produces very high-quality code I need about 3 people who knows C and about 3 months of free time to work on it. these people are supposed to be professionals, so, they probably would ask for $10,000/month or about. thus, the cost of the project is ~$100k plus my small finger fee :) it’s not big money, but nobody is ready to pay. and nobody is ready to work just for fun, because just a few people in the world really need this tool – the deobfuscator. so, it’s a problem how to sell it. of course, it could be used internally. it would save millions dollars to a security company who develops it, since reversers will reverse malware much faster (time means money). but I don’t know a company who would be interested in it. well, maybe not a tool, maybe a technology (a set of tricks) how to clean-up code with existing tools and simple “helpers” written in C for a few days. well, I’m planning describe how to disassemble highly obfuscated programs in my new book. also, blog-posts are planned as well. thank you for your interest!

  5. I valuate your work very much! Your shell detector seem to be gorgeous!
    Drop me some words in private, I would like to provide you some obfuscated samples per email, this code made me crazy :-)
    Probably some interesting stuff for future your book.

Leave a comment

Comments are closed.