« previous 1 2 3 4 next »

heise Security UK: Any particular issues you focussed on?

Alex Eckelberry: We found that the problem with malware these days is that these malware writers they are compressing these files, but they're using customised open source compression systems, some proprietary, some just taking UPX and modifying it, but they're making these compressed files which are getting, increasingly, almost impossible to detect. They're making them so that they're polymorphically compressed so every time you download it, they re-compress it and just switch a few bytes here and there. So what you have is armies of people at Trend Micro and all these companies literally writing un-packers all day long, that's what they're doing ... you have to write basically a special un-packer for each one of these things. So it's a huge arms race going on and it's going on right now and that's why people say "Well signatures are dead" ... So this is a huge problem, what you do then is, you could just do standard CPU emulation, which would actually take the executable and execute it at the CPU level. Basically design a fake CPU, that you would run it through and then you would see the instructions coming out.

hS: But that would be detectable by the malware writers because they could do a time attack on it?

AE: Exactly, they could do any number of things; one of the things they do, for example, spinning up a loop and let it sit there for, say 60 times 70 times, at that point the emulator is just going to crap out, it just doesn't know what to do, it's a software based emulator, you can have all the op codes you need to try to make this thing think it's in an actual real environment, but you're going to crap out.

So a lot of very advanced research going on in the AV world has been to do with a new technology called dynamic translation, It looks at the executable and it sees all this stuff here and it picks out the largest code chunks, picks these out and recompiles them into a new executable, then runs that through the emulator. So if the guy spins up a loop, you may not even care about that; you can take the ultimate end result of that loop, and recompile into a new application and then run it through the emulator.

hS: So you are assembling a binary with the detectors censored out?

AE: Yes, yes. I'm not going to paint it as a panacea, because we still have an arms race, but it is a dramatic difference. The problem is that as you're doing this recompile you take a performance hit, but the difference is when you run it through the emulation.

hS: You don't have the slowdown because you've got rid of all the stuff that's going to sit there going "lets chew CPU"?

AE: That's right, your basic bottleneck, so, with this technique, we run about 400 mips versus 10mips. I mean we have tons of other things we do, we have heuristics, we have signatures, this is a whole pipeline, you run pipelines from least expensive to most expensive, with DT at the end. So now we run the DT and then try to emulate it, see what the hell it is, so it's only hassles at the very, very end. In most cases we don't even DT stuff. The difference is that this is very useful for stuff that we don't know what the hell it is.

Next: Beyond CPU emulation

« previous 1 2 3 4 next »