A little project of mine has been to write a complete code pervertor that would actually modify the opcodes of an executable, to perform equivalent operations but using different opcodes. This would be the ultimate method of "crypting" a file, since the executable in memory would still remain unique and undetected.

I therefore set about creating an engine that modifies the code with equivalent operations.

For instance,

mov EAX, 5;

is equivalent to:

push 5; pop EAX;

so I developed a library of equivalent operations for every x86 instruction commonly used. The engine will:

1) disassemble each instruction in a section of code;
2) select a random equivalent operation;
3) calculate extra space required to fit new equivalent operations and insert space in code;
4) assemble the equivalent operations.
5) scan entire code section looking for jmp's, jcc's, call's and adjusting the address they reference to allow for the extra space inserted in step 3.

Now, this actually has been done before. Zombie wrote code pervertor which could achieve this but only for instructions that have an equivalent instruction of equal size in bytes when assembled. I will be taking this to the next level.

The engine is currently mid-way through development and uses ollydbg's disassembler engine to perform the tedious task of disassembling each instruction.

While it's not complete, here's how it is working on a stub used in a program called Code Crypter that I wrote a while back.

the table view makes it easy to see how it is mutating each opcode. This was using a very limited library of equivalent opcodes for testing purposes.

The big problem at moment is handling things like JMP EAX. I have to use a little stub to adjust for code movement, which is not quite working yet.

The encrpytion process is recursive and pretty slow. It takes about 30 minutes to fully mutate a typical 100k executable. This is because each time it swaps an opcode for an equivalent sequence of opcodes, it must adjust all the JXX, JMP, CALL's in the code, for the padded space added by inserting the new code.

Hopefully I will get some time to work on this again soon.

Tibbar.

I've promised I would explain why you cannot trust Anti-Virus software.

As this is a long topic, I will spread the tutorial over several blog entries, when I have time to spend here.

To understand how to defeat AV, you first need to understand how they work.

The key principle that has underpinned virus detection for the last 10 years, is to recognise viri not by their behaviour, but through a digital signature of their code.

Let me explain this more carefully... the AV program has probably around 100,000 files to scan on a typical hard drive. It's a very slow process to check each file in detail, so what AV do is to have a database of signatures (each signature is a piece of binary code that uniquely identifies the virus), and they simply check each file for a known signature.

This is much quicker than actually trying to determine what a particular executable's behaviour is.

Many AV can also do "heuristic" scanning. This sounds rather clever, but in fact it is not! Usually this means the AV will flag near matches to signatures as well, when performing the scan.

Finally, many AV will perform a "memory scan". This sounds like they are scanning the memory of each running process for known virus signatures. The truth is somewhat different - most AV "memory scans" are actually doing the following:

1) enumerate all running process names
2) for each process, scan the disk image of the process for known virus signatures.

only one or two products actually perform a real memory scan (none of the mainstream AV do a real memory scan).

Ok, so what we now know is that to defeat AV, the malware needs to be free of any bytes of code that match known virus signatures.

This means there are several options open to the hacker. She can:

a) write her own malware from scratch, which will be new and unknown to AV

b) use a "packer / crypter" to alter the binary image on disk, so that AV cannot match any signatures to the "packed / crypted" file.

c) use a code perversion engine, that will substitute equivalent opcodes for each opcode used in the executable's code. This is an extremely complex process and no public tools exist to achieve this fully (I have been working on this, but the tool is not complete). Z0mbie wrote a basic perversion tool some time back. His comments about it are:

Almost all trojans and viruses are detected using simple signatures. Which means that simple crc is calculated on the entire file, or on some parts of the code being checked.

There are thousands of simple signatures already stored in the antiviral databases. Each signature is equivalent to hours of an aver's work.

Using simple length disassembler and some simple rules, it is possible to analyze an arbitrary executable file and change some instructions in it, so that it will run the same as before, but file's checksum will be changed.

This means that antivirus will no longer be able to identify these files by using the previous checksums.

A tool called "Code Pervertor" was written some years ago. It can analyze a PE file and swap a few equivalent instructions, such as "test eax, eax" with "or eax, eax" and vice versa.

Another similar process is "diversification", which means the random changing of some data offsets within all system DLLs and services. Diversification complicates exploitation based on fixed address usage and will probably soon be implemented as a security measure.

Now imagine that some worm "perverted" and "diversified" all executable files it found on a machines over the net. It is likely that the same vulnerable machines will also contain trojans. So when all these trojans become unique, what avers will do?

There are two methods of detecting such a modified files.

First method is to modify files before analyzing, the same as "code pervertors" do, but without the randomization. For example, if some instructions can be interchanged with each other, perform one-way changes only, for example replace all "or eax, eax" with "test eax, eax", but not vice versa.

This method has tons of negative aspects: there can be many different methods of file modification, but some of them can be irreversible.

The second method consists of re-writing all checksum algorithms and recalculating all the signatures. The new checksum algorithm should become invariant to simple modifications such as swapping equal or interchangable instructions with each other.

This method is something like image recognition, where the new algorithm can return an equal result for many different data inputs.

This method also has a serious disadvantage. If someone introduced a new file modification method, the checksum algorithm will have to be once again changed and all the antiviral signatures recalculated.

A few hundred infected machines with automatic "pervertors" will catch all the new just-released worms and viruses and modify 'em "on the fly", automatically spawning new variants.

Option c) if ever achieved will render all AV absolutely useless. Scary eh?

Option a) is a reasonable choice, but our hacker may not have the necessary skills to write all the nasty tools she needs, and also once they are released in the wild, AV will eventually put signatures on them, which will mean she has wasted her time coding them.

This leaves option b) as the best solution to defeating AV at the current time.

Now, what exactly do I mean by packing / crypting?

Essentially, the technique involves taking all the code and data from an executable file, and applying an encryption algorithm to it, to ensure no signatures can be matched on it.

The new "packed / crypted" executable will include the encrypted data and code from the original executable, plus a "stub". The "stub" is a piece of code that can decrypt and reconstruct the original executable dynamically at runtime.

This means that on disk, the crypted executable is undetected to AV scanners, but once it is executed, it will behave and appear exactly like the original file.

A packer is exactly the same as a crypter, except that instead of using an encryption algorithm, it uses a compression algorithm. This makes the file both undetected and much smaller in size.

This all sounds pretty bad from the AV perspective. Fortuntely, in practice, the number of crypters and packers available on public sites is quite small. The AV firms analyse packers and crypters that they find, and alter the AV signatures to detect files that are packer / crypted using known packers / crypters. Some AV will include a decryption algorithm in their scanners, so they can find out what lies beneath!

Now, for some bad news... It is surprisingly easy to create your own crypter, and most private hacking groups have made their own custom crypters or packers.

One public crypter that beat most AV for a period of over a year, was morphine from www.hxdef.org. This is quite an advanced crypter, but given the resources available to AV firms, I was shocked how slowly they responded.

Let me reinforce this point. All private packers or crypters are undetected to AV. This means malware will not be detected by AV scanners, when using private packers or crypters.

So you should never trust you AV when it tells you a file is clean. If that file comes from an untrusted source be very suspicious. Use run as limited user if you must execute it. Also consider using a virtual machine and try using online scanners like http://www.virustotal.com to perform multi-scans against all AV engines - these tend to catch more things, than a single AV.

Next blog will tell you how to write you own crypter...