1

I was reading the CIA leaked documents on wikileaks, I saw in their "best practices" section that it was advised to encrypt all strings and config information and to de-crypt in memory when needed.

I was wondering how this works. I understand how to on the fly decrypt and the rationale behind having config strings in your program encrypted; so that anyone trying to reverse engineer the program cant see any meaningful strings.

But how do you store the key? if this is an autonomous virus, the key to decrypt those strings and config data has to be also stored in the program? how do you store the key so that the program can use it, but a reverse engineer will not find it?

Unless of course I have misunderstood the type of program that would employ this practice.

Anders
  • 64,406
  • 24
  • 178
  • 215
uhsl_m
  • 113
  • 3

1 Answers1

0

You are right that the key will always have to be availabe to the program that uses on-the-fly decryption of some of it's parts. There is no way around that, which means that this is the kind of security that protects you against your little sister, but not against a determined attacker (paraphrasing Schneier here). It's impossible to keep a capable attacker from finding the key.

For viruses, encryption is useful for another reason: Virus scanners scan for specific patterns, and if you encrpyt large parts of the virus, using randomly generated keys, much of the pattern matching becomes useless. The only thing left to match against is often the initialization code and the decryption function, and there are tricks to change the binary fingerprint of these parts, as well.

The way this could work is that when a virus infects a new system, it creates a copy of itself, but uses a different encryption key and shuffles around various parts of the decryption function and init code, so the copied virus doesn't look like the original at all.

What you read might be related to that: If you encrypt config strings, it becomes much harder to simply grep for a string to detect a specific program. But it's hard to tell without a reference to the document you mention.

Out of Band
  • 9,150
  • 1
  • 21
  • 30
  • I will find the wikileaks link for you, I assume posting that kind of information is not against the terms of this site? I assume not since it is an information security community, but you never know. – uhsl_m Mar 10 '17 at 12:37
  • Here is the link. https://wikileaks.org/ciav7p1/cms/page_14587109.html. The item is question is the very first "directive" in the table. – uhsl_m Mar 10 '17 at 13:32
  • I'd like to add two things to your answer: First, it is possible for the context of the application to provide the decryption key. A famous example (I can't remember the name on top of my head) was a malware that had two stage: a propagation and loader and a payload. The loader use a HMAC of some of the local system's properties (system name, I guess) as key to try to decrypt the payload. It was designed to target a very specific machine and, as far as I know, no one could ever sucessfully decode it. – Stephane Mar 10 '17 at 15:08
  • A second thing is that storing a key in binary format inside your EXE makes it harder to extract it. – Stephane Mar 10 '17 at 15:09
  • Reading the link you provided, it's as I thought - they want to obfuscate/encrypt so their malware is harder to detect and analyze. Just "harder", not "impossible". But @Stephane raises an interesting point - if you attack a very specific system, building the key from context might work, and you'd only be able to decrypt on the targeted system. Smart! – Out of Band Mar 10 '17 at 16:16
  • That's all very interesting. So its just to add another hurdle to analysis rather than making analysis impossible. – uhsl_m Mar 13 '17 at 09:53