This would only be useful for binaries where you don't have corresponding source, but the binary does still have symbols. Is this a common situation?
100139190 ( 0x90) verror [FUNC, EXT...
100139220 ( 0x210) Fcommandp [FUNC, ...
100139430 ( 0xf0) Fautoload [FUNC, ...
100139520 ( 0x90) un_autoload [FUNC...
1001395b0 ( 0x80) Feval [FUNC, EXT,...
100139630 ( 0x50) record_in_backtra...
100139680 ( 0x1d0) apply_lambda [FUN...
100139850 ( 0x390) Fapply [FUNC, EXT...
100139be0 ( 0x5c0) Ffuncall [FUNC, E...
10013a1a0 ( 0x90) Frun_hooks [FUNC,...
10013a230 ( 0x1d0) run_hook_with_arg...
10013a400 ( 0x20) funcall_nil [FUNC...
10013a420 ( 0x20) Frun_hook_with_ar...
10013a440 ( 0x20) Frun_hook_with_ar...
10013a460 ( 0x30) Frun_hook_with_ar...
10013a490 ( 0x30) funcall_not [FUNC...
But it goes beyond this. You could imagine statically linking a program against all of its dependencies, then stripping all possible symbols. The thing is, there is plenty of info in the binary to make sense of the program. Strings, for example. Error messages. Every piece of data you want to show to the user is an indication of what the surrounding function is doing.
IDA Pro is pretty incredible in that situation. Each time you figure out what a function is doing, you just give it whatever name you want. IDA updates the whole interface so that it uses that name everywhere, instead of the hex address. You end up with a neat, perfectly sensible program. Entire game engines have been meticulously reverse engineered this way.
However, viruses use a crafty technique to prevent analysis. You encrypt your program like an onion. Your outer program runs, and everyone can see that. But it's carrying around a blob of functionality that was encrypted using the target's information. E.g. their MAC address, or a subset of their list of installed programs, or anything that would uniquely identify your target separately from everyone else. Any time the virus is installed anywhere, it tries to decrypt itself using this information, which only succeeds when it's installed on the target machine.
This defeats all attempts at analysis. You can't analyze what you can't decrypt.
I'm a bit confused though, how would the virus get to the target with the encrypted payload, do you mean say on another computer, the MAC address for the target computer would be utilised, then the main payload of the virus encrypted, and the virus given to the target?
It's interesting using the MAC, because if you placed it in a VM it wouldn't run, unless you used the same MAC for the VM network adapter.
If this kind of thing interests you, this article about Flame is absolutely fascinating:
http://www.symantec.com/content/en/us/enterprise/media/secur...
Hard to believe it was already almost six years ago.
> On both servers command and-control activity happens through a Web application called Newsforyou. It processes the W32.Flamer client interactions and provides a simple control panel. The control panel allows the attackers to upload packages of code to deliver to compromised clients, and download packages containing stolen client data. However, in a technique not previously seen before the uploaded and downloaded packages are encrypted, so infiltrating the command-and-control server does not reveal the code or the stolen client data. The command and-control server simply serves as a proxy for the data and the data is encrypted and decrypted offline by the attackers using keys unique to each client. This application also contains functionality to communicate with clients compromised by malware other than Flamer. The Web application was designed to be a framework for supporting different malware campaigns.
> In addition to avoiding the compromise of their operations, preventing both the uploading of rogue code and viewing of stolen data, the setup also maintains a clear distinction of roles. The roles include those responsible for setting up the server (admins), those responsible for uploading packages and downloading stolen data through the control panel (operators), and those holding the private key with the ability to decrypt the stolen data (attack coordinators). The operators themselves may actually be completely unaware of the contents in the stolen data. This is due to design of the process to use data security compartmentalization techniques, as shown in Figure 1.
> Despite these techniques, we were still able to determine that one of the servers delivered a module instructing Flamer to commit suicide and wipe itself off computers in late May 2012, an action we also witnessed through compromised honeypots.
> Finally, access to the control panel required a password which is stored as a hash. Despite brute force attempts at reversing the hash to plain text, we were unable to determine the plain text password.
The whole thing is filled with gems like that. They controlled the virus with a PHP webapp called "news for you!" presumably with a sly winky face emoji appended to the <title> tag.
I bought this book a while ago - 'Malicious Cryptography: Exposing Crytovirology' I still need to read it more thoroughly but they present some interesting ideas.
It seems to be quite easy to do something similar; especially if you're specifically targeting a single PC with a very specific configuration.
How do you ensure that the amount of entropy in the key is enough to stop a person from finding the key? Assuming the person reverse-engineering the virus already knows the key generation routine, since he has access to the binary of the virus.
Hostnames and lists of installed programs should be prone to a dictionary attack, mac addresses are not even close to having enough bytes.
https://news.ycombinator.com/item?id=15046089
It depends entirely whether you have persistent access to the target. If your target is airgapped, your only option is to know something about the target machine (i.e. have a spy on the inside) that gives you enough info to encrypt the virus. For example, they could install a special program so that it's listed in C:\Program Files, then the virus decrypts using the string "${mac_addr}${x}" for x in [list of installed programs]. So as an analyst, you won't have any idea what the magic program name was.
That technique was likely Stuxnet, not Flame, so that article might not contain any info about it. But it's amazing in its own way. If you have any other questions too, I love chatting about this stuff.
Next, if you are using any kind of library, even statically linked, changing the default visibility for your executable isn't enough to get rid of the libraries' symbols, because those were already defaulted to public when the respective library was compiled.
Also when statically linking, you probably want to compile all the libraries with '-ffunction-sections -fdata-sections' and pass '--gc-sections' to the linker to prevent bloating your executable with unused functionality.