The above schemas show how the CTX.Phage EPO virus works. As mentioned before, the virus injects the call instruction by overwriting it with a randomly found call. As the application size grows (and also the injected call range from the entry-point), it becomes increasingly difficult to find the injection of the virus. On the other hand, while using this EPO technique reduces the risk of virus execution, there are also some cases when the "call-to-virus" will not be executed at all.

At this point, let"s find a way to detect such injections such that it does not cause false alarms.

Where:

Before we go any further, let"s summarize all the information we know about the current EPO:

As the reader probably knows, we could simply search for 0xE8 bytes (call opcodes) but there is large possibility that we might find some "suspicious" call that thands in non-call instruction, for example:

As you can see, this is the push instruction, but the scanner finds the E8 byte and could consider it as a call. Unless we don"t want to build up our disassembler engine (which is very long and hard work) we need to find another way. Yes, you guessed it: we need to add a condition for the E8 byte scanning routine, remembering that the call always executes code that resides in last section! Now that everything is clear, here are the conditions we require:

Where:

A sample temp_loc calculation might look as follows:

If the temp_loc address resides somewhere between last section"s virtual address (start) and the last section"s virtual address + its virtual size, the call is marked as suspicious. Here is the short snippet from the author"s scanner:

While scanning files with this code, I haven"t seen any false alarms, so it is probably one of the best solutions or techniques one can use to find such virus injections.