4 ms·

Fun fact: The Flame virus had several layers of self-encryption. It was basically an onion, with each "layer" being encrypted executable code. The outer laye

Fun fact: The Flame virus had several layers of self-encryption. It was basically an onion, with each "layer" being encrypted executable code. The outer layer was typically the only one that was active at any given time. It would then detect some part of the system configuration (like part of the list of the installed programs) and derive a decryption key from that, and try to decrypt itself. Therefore, if(f) the system had a certain set of installed programs, then the Flame virus would decrypt its next layer successfully. That way it would avoid exposing its entire codebase to virus researchers, because the researcher's systems probably wouldn't have the correct list of installed programs. (Is there a name for this technique?) Apparently, it didn't work very well iirc. The researchers figured out how to get into all of the layers somehow, though I forget how. But the idea was clever... I wonder if something similar could work well in practice. (This isn't the same thing as what was presented in the article, of course, but it's a lot easier to accomplish in practice.)

drblast 13y ago
Anything like that is not really fundamentally different from a password, and for the program to work correctly (decrypt itself) it has to collect the password somehow. The outer layer that does this really has no defense other than obfuscation, which is difficult to do because in order to do anything useful you almost always have to interact with the system on which you're running anyway, and those interactions give away what you're doing. And if you're decrypting a program and doing something that people notice, it's a matter of time before someone is able to capture the decrypted code and work backwards from that. The decryption routine is a rather obvious place to look; does the routine check if something is decrypted properly before jumping into that code, or does it decrypt, jump, and crash if the key is wrong? If it checks, then that's the ideal place to stop the program, dump the memory, and see what's going on. If it doesn't check, you're going to have malware that's crashing all the time and fairly easy to detect for that reason. If you're trying to do something under the radar, the last thing you want is unstable malware. So yeah, traditional obfuscation is just a speed bump, and too much of it might make things detectable. The underlying problem is that the software has to DO something useful (read a file, send network packets, etc), and it's extremely hard to hide that on hardware you don't control. But like any security, depending on the goal, maybe a speed bump is good enough.
- nitrogen 13y ago
  If the malware depends on a sufficient number of system details to decrypt itself, then no amount of code analysis will help decrypt the inner layers. As you say, it's like obtaining a password, and a sufficiently strong password (or sufficiently unique set of system details) cannot even be brute forced before the heat death of the universe.
  - jjoonathan 13y ago
    If by "no amount of code analysis will help" you mean to exclude techniques such as running the damn thing on a known-vulnerable box/VM, then sure. But very few reverse engineers operate under that restriction. It's like DRM: the user must have the key, so the only security you can have lies in obfuscation.
    - jlgaddis 13y ago
      > ... such as running the damn thing on a known-vulnerable box/VM, ... But in the case of Flame, wasn't that (one of) the big problem(s)? That the researchers didn't know what, exactly, comprised a known-vulnerable host?
    - nitrogen 13y ago
      The point of the derived decryption key is that the only system that can produce the key is very likely not in the hands of security researchers.
- wglb 13y ago
  But consider that the decryption key for the outer layer is something that is unique, such as the machine key. Or the serial number of a device attached to the box. Or even the mac address of a network device. Thus, only in that particular targeted environment will the next layer be revealed. While it is true that, as you say, Anything like that is not really fundamentally different from a password, that password might require physical possession of the target machine.
  - 13y ago
legulere 13y ago
The name for this is conditional code obfuscation: http://llvm.org/pubs/2008-02-ImpedingMalwareAnalysis.html http://llvm.org/pubs/2008-02-ImpedingMalwareAnalysis.html

drblast 13y ago

Anything like that is not really fundamentally different from a password, and for the program to work correctly (decrypt itself) it has to collect the password somehow. The outer layer that does this really has no defense other than obfuscation, which is difficult to do because in order to do anything useful you almost always have to interact with the system on which you're running anyway, and those interactions give away what you're doing. And if you're decrypting a program and doing something that people notice, it's a matter of time before someone is able to capture the decrypted code and work backwards from that. The decryption routine is a rather obvious place to look; does the routine check if something is decrypted properly before jumping into that code, or does it decrypt, jump, and crash if the key is wrong? If it checks, then that's the ideal place to stop the program, dump the memory, and see what's going on. If it doesn't check, you're going to have malware that's crashing all the time and fairly easy to detect for that reason. If you're trying to do something under the radar, the last thing you want is unstable malware. So yeah, traditional obfuscation is just a speed bump, and too much of it might make things detectable. The underlying problem is that the software has to DO something useful (read a file, send network packets, etc), and it's extremely hard to hide that on hardware you don't control. But like any security, depending on the goal, maybe a speed bump is good enough.

nitrogen 13y ago
If the malware depends on a sufficient number of system details to decrypt itself, then no amount of code analysis will help decrypt the inner layers. As you say, it's like obtaining a password, and a sufficiently strong password (or sufficiently unique set of system details) cannot even be brute forced before the heat death of the universe.
- jjoonathan 13y ago
  If by "no amount of code analysis will help" you mean to exclude techniques such as running the damn thing on a known-vulnerable box/VM, then sure. But very few reverse engineers operate under that restriction. It's like DRM: the user must have the key, so the only security you can have lies in obfuscation.
  - jlgaddis 13y ago
    > ... such as running the damn thing on a known-vulnerable box/VM, ... But in the case of Flame, wasn't that (one of) the big problem(s)? That the researchers didn't know what, exactly, comprised a known-vulnerable host?
  - nitrogen 13y ago
    The point of the derived decryption key is that the only system that can produce the key is very likely not in the hands of security researchers.
wglb 13y ago
But consider that the decryption key for the outer layer is something that is unique, such as the machine key. Or the serial number of a device attached to the box. Or even the mac address of a network device. Thus, only in that particular targeted environment will the next layer be revealed. While it is true that, as you say, Anything like that is not really fundamentally different from a password, that password might require physical possession of the target machine.
- 13y ago

legulere 13y ago

The name for this is conditional code obfuscation: http://llvm.org/pubs/2008-02-ImpedingMalwareAnalysis.html http://llvm.org/pubs/2008-02-ImpedingMalwareAnalysis.html