Threat Research & Response Blog (Back to herm1t's home)
In July, I wrote about two of the amazing new instructions in the SSE 4.2 set: CRC32 and PCMPxSTRx. CRC32 is special because of its immediate application to obfuscated import resolution, a common technique among viruses and packers. I said "the VX guys will probably be able to take advantage of it before AV guys can". I was thinking slightly longer term than four weeks, but that's all it took. In August, the first virus appeared that makes use of the CRC32 instruction. They would have found it sooner or later, and it makes no difference in this case, but we will come back to that.
The virus writer known as herm1t, who insists that he will not run out of ideas (in response to something else that I wrote), still had to use one of mine instead (perhaps to save one of his own for later, so I remain hopeful that his store will be depleted eventually). His virus, which he calls "FortyTwo" (because of the SSE version number, nothing to do with Douglas Adams), takes the general approach that I suggested, but in a specific way that I had overlooked. I suggested that only CPUID could be used to determine if the CRC32 instruction is available on the CPU. While that is the cleanest approach, of course it can be done in a more "brute force" manner - by using an exception handler.
This idea is not new. We have even seen public code from Intel, dating back to 1990, and based on even earlier code, that uses an exception handler when determining the CPU type. The idea is that by attempting to execute CPU-specific instructions, an exception will occur if the instruction is not supported on the CPU, or the instruction will succeed if it is. It is this approach that herm1t has chosen. However, as I said, "a virus that carries dual-case code will defeat the purpose of having the modern code, since ... we can ... force whichever code path that we want". That quote had a slightly different context in the original, but the meaning is the same - we can choose to not support the instruction, and then the exception will occur as expected for an older CPU. We can thus support the instruction at our leisure. In fact, by not using CPUID, herm1t unintentionally allows us to behave correctly with no effort. The CRC32 instruction cannot be "accidently" required because there is nowhere for a Win32/Legacy-style bug to appear.
The exception handling mechanism that is available in modern operating systems is far superior to the "int 6" hardware method of the Intel CPU identification code, but as far as the use to which herm1t put it, the two are equivalent.
When the time comes that we do add support for the CRC32 instruction, we will also have to add support for all of the other SSE 4.2 instructions. Otherwise, a virus might "test" the CPU behaviour by attempting to execute all of the instructions, to see if any of them fail. To see only a few instructions succeed from a set that should be complete, is a sure sign that a CPU emulator is in control. No-one said that emulation is easy.
