9 ms·
Yes, in two ways. First, it's often useful to target malware or other systems by the common packer code they use. This doesn't require deobfuscating anything.
by NateLawson 11y ago
Yes, in two ways. First, it's often useful to target malware or other systems by the common packer code they use. This doesn't require deobfuscating anything.
More interestingly, the matching algorithms we developed are by design resistant to many common obfuscation schemes. For example, Proguard renames variables and functions, as well as discarding dead code. But other aspects of the code that we index, including control flow structures and data references survive. We've designed our matching engine to apply a combination of all these factors to be resilient to changes in subsets of them.
Compilation is one of the simplest forms of "obfuscation", so started with dealing with different levels of optimization discarding code or changing the opcodes.
If a program is self-decrypting, then we have to apply standard unpacking techniques to get back to a reasonable format before ingesting it. Nothing magic there.
- munin 11y agoWhat if the obfuscation removes the ability to construct a control flow graph, but is not self-decrypting?
- NateLawson 11y agoWe depend on a huge number of program features so CFG alone isn't enough to throw it off (data references, function layout, linker behavior, and much more are included in our matching). You're right that, at some point, you've destroyed enough of the features that matching will fail. For that case, you'll always need targeted techniques, such as for virtualizing obfuscators. Since there's a big performance loss when you use them, almost no legitimate mobile apps are willing to pay the battery and speed loss.