I decided to target the Xpaj virus because it's an polymorphic file infector, which means that it is not easily to detected with plain signatures. Please note that I'm just focusing on the detection of Xpaj via bytecode signatures, not on Xpaj itself which was already thoroughly reviewed and explained. Pic.2: Same file as above, but infected with Xpajįor the scope of this blog post, it suffices to say that Xpaj is a file infector targeting 32-bit Windows executables and DLLs which employs entry-point obfuscation (EPO) capabilities in order to make the detection harder.
In particular, the virus code hijacks a few API calls in the. text section of the file, diverting them to its own routine. text section and consists of a series of small chunks of code connected by jumps. The only thing this preliminary block of code does is compute the code address for the next stage and jump to it. The actual viral code, as well as the overwritten blocks, are stored, in encrypted form, inside the data section. From now on I'll just focus on the Xpaj detection, or rather, the detection of a rather simplified version of it in order to keep this blog post small and readable.
The geeks can find the full source code here. Let's start with a look at the virus entry point code: #Clamxav free registration full# While these are technically enough bytes to create a signature based on the opcodes, such a signature would be a really bad idea.
What we have there, in fact, is just a pretty standard function entry point.Īfter that we have some optional trash (do nothing) code, and then the virus saves the content of 3 random registers, which will be clobbered later by both the virus code and the trash engine too. So far we can still get away with a signature that makes use of a wildcard, however we still don't have much: stack allocation and 3 registers saved.
Next, we've got the trash engine in all its glory, and eventually we reach a function call. The trash code may or may not jump to another chunk of code.