5 ms·

Its usually all you get if you are reverse engineering someone else's executable or firmware image.

by jdblair 9y ago

haberman 9y ago
But they leave symbols in? They don't strip those also?
- sillysaurus3 9y ago
  Indeed. If you start Emacs on OSX and run `symbols Emacs`, you get a lot of info: 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... So why not strip these? Well, you can't. But the reason is interesting. Most programs run by using shared libraries, and these libraries need to provide a standard API that other programs can use. Hence the function names. Which of course is exactly the info that a hypothetical bad guy needs to make sense of the program. 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.
  - anfractuosity 9y ago
    Heh, that's interesting regarding using the MAC address as the encryption key. 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.
    - sillysaurus3 9y ago
      Yes, exactly. If this kind of thing interests you, this article about Flame is absolutely fascinating: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_flamer_newsforyou.pdf 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.
- deleted 9y ago
  [deleted]
- kbwt 9y ago
  Linux programs are notorious for containing a lot of symbol information and the toolchain doesn't exactly make it easy to get rid of them. To start with, you have to compile executables with '-fdefault-visibility=hidden'. Otherwise, strip cannot remove the symbols defined in the executable because it's assumed that another executable might want to load your executable as a shared object and import its functions/global variables. 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.

Its usually all you get if you are reverse engineering someone else's executable or firmware image.

haberman 9y ago

But they leave symbols in? They don't strip those also?

sillysaurus3 9y ago
Indeed. If you start Emacs on OSX and run `symbols Emacs`, you get a lot of info: 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... So why not strip these? Well, you can't. But the reason is interesting. Most programs run by using shared libraries, and these libraries need to provide a standard API that other programs can use. Hence the function names. Which of course is exactly the info that a hypothetical bad guy needs to make sense of the program. 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.
- anfractuosity 9y ago
  Heh, that's interesting regarding using the MAC address as the encryption key. 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.
  - sillysaurus3 9y ago
    Yes, exactly. If this kind of thing interests you, this article about Flame is absolutely fascinating: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_flamer_newsforyou.pdf 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.
deleted 9y ago
[deleted]
kbwt 9y ago
Linux programs are notorious for containing a lot of symbol information and the toolchain doesn't exactly make it easy to get rid of them. To start with, you have to compile executables with '-fdefault-visibility=hidden'. Otherwise, strip cannot remove the symbols defined in the executable because it's assumed that another executable might want to load your executable as a shared object and import its functions/global variables. 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.