5 ms·
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
by 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 agoIf 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 agoIf 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 agoThe 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 agoBut 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.
- spullara 13y agoThis is an amazing idea. Someone might have been able to do this for the final code for something like Stuxnet since they knew the target software. Really brilliant.
- wglb 13y agoIt seems like with stuxnet it was a serial number from the attached hardware.
- drblast 13y agoThe point is that you'd have to read that data somehow, and likely from a user-level process, so you'd have to make some sort of system call to do that. Unless the entropy that's the input key is something ephemeral, it's only a matter of time before the key is found. And in the case of malware, you can pretty much assume that the victim/target does have physical possession of the machine.
- wglb 13y agoYes, it will be very clear from executing the code a step at a time where the key can be found (MAC address, cpu serial id, unique property from external hardware) but that does not give you the value of the key derived from that per-installation specific hardware. Yes, it is a matter of time, so long as you can run this experiment on every unique hardware environment.