The level 1 challenge was a binary that asked for input and, if your input was correct, printed out an e-mail address you could use to get the level 2 binary. The Khallenge is a contest of speed, so the first person to get to and beat level 3 wins. Unfortunately, I solved level 1 after the contest ended and the level 2 and 3 binaries aren’t online yet, so no prizes and no info on those.

The first thing I did was open the binary is a disassembler and try to get a general feel for it. This would help me develop an attack strategy. In IDA, you can easily identify that your input is being XOR’d almost a dozen times and with a global variable somewhere. It quickly overwhelmed me, so I took out a pen and paper and started writing things down. I also had lots of problems identifying exact addresses and byte offsets in IDA (I haven’t used it much before), so I switched to Immunity Debugger at this point.

The first set of instructions your input needs to pass through are at addresses
69001081 to 6900108F, and it turns out they are a compiler-optimized strlen function. Pseudocode for these addresses looks like this:

if(strlen(input) != 4)
    fail();
else
    ...

The XORs start immediately after this check. After staring at it for a while, you will figure out that your input is being used as a key to decrypt a global variable located at 0×690030D0. This global variable becomes the answer e-mail. I wrote out the encrypted e-mail in a column and mapped the XOR’d input bytes to it. Here is that table (encompasses addresses 69001095 to 690010F6):

e-mail @ 0x690030D4		input @ 69003100
e-mail[0]: 0x07		XOR	input[0]
e-mail[1]: 0x2E		XOR	input[1]
e-mail[2]: 0x35		XOR	input[2]
e-mail[3]: 0x29		XOR	input[3]
e-mail[4]: 0x70		XOR	input[0]
e-mail[5]: 0x20		XOR	input[1]
e-mail[6]: 0x76		XOR	input[2]
e-mail[7]: 0x68		XOR	input[3]

After all the XOR’s, the application starts to check the final values of 4 select bytes in the e-mail buffer.

e-mail[4]: 0x70		XOR	input[0] == 0x32
e-mail[1]: 0x2E		XOR	input[1] == 0x61
e-mail[6]: 0x76		XOR	input[2] == 0x30
e-mail[3]: 0x29		XOR	input[3] == 0x79

If you do the XOR in reverse, you can find out the input they are looking for:

0x70	XOR	0x32 = input[0] = 0x42 = B
0x2E	XOR	0x61 = input[1] = 0x4F = O
0x76	XOR	0x30 = input[2] = 0x46 = F
0x29	XOR	0x79 = input[3] = 0x50 = P

Run the executable, put BOFP into the prompt, all the XORs happen, all the checks pass, and the e-mail buffer decrypts to “Easy2o08.” Done!

Thanks again Aleksey and Phn1x!

First though, a [paraphrased] summary of the discussion thus far:

Dan F: Why not extend the ISA of the CPU to offload crypto operations to an ASIC or a special part of the CPU? To avoid slowing down the CPU you’d need to widen the issue and decode/dispatch or add another word if it’s VLIW. Op fusion might come to your rescue in a future ISA, too.

Mike P: Good thing MacBooks get nice and hot . Why not add a register for the encryption key that gets wiped with the last bit of power in the CPU?

Me: Can’t we just encrypt all of RAM too? Lots of consumer computers have TPMs with crypto-coprocessors already. Wait a minute, we’d need to shove one on the same bus as the RAM and CPU and where would we store those keys? D’oh! Oh and Dan F, IBM beat you to it.

Dan F: I wonder what affect this has on power consumption and overall throughput?

Computer forensics people have been getting physical memory dumps for years and what about malicious root-owned processes? The threat has always been there. Hasn’t anyone been aware of the threats and developed any countermeasures?

I picked up the Secure Programming Cookbook to look for answers. Here are excerpts from recipes I found that might be applicable to this debate. Since Ed’s code reads through memory and tries to pick out things that looks like keys, maybe you can obfuscate them to look like something else?

DISCLAIMER: I’ve never dumped the contents of memory and inspected it, I’ve never written crypto that handled keys securely, I didn’t test any of these countermeasures, and so on. This is all baseless conjecture.

Recipe 4.13 – Managing Key Material Securely
Securely erase keys are soon as you have finished using them. Use the spc_memzero function from Recipe 13.2 or SecureZeroMemory() if you’re using a new version of Windows.

Recipe 12.4 – Performing Bit and Byte Obfuscation
Use the Obcode library by Pawel Krawcykz. The size of variables are inflated eightfold and the library provides many standard byte and integer operations.

Recipe 12.6 – Merging Scalar Variables
Problem: Scalar variables with constant or initialized values disclose information about ranges of values.
Solution: Merge multiple scalar values into a single, larger scalar value to make simple, unrelated values appear to be a large value or bitfield.

Recipe 12.7 – Splitting Variables
Problem: Large scalar variables that cannot be merged, or that have large values that cannot easily be manipulated with a constant transform, need to be obfuscated.
Solution: You’ll have to buy the book, I can’t explain it .

Recipe 12.10 – Restructuring Arrays

• Split a one-dimensional array into multiple one-dimensional arrays
• Fold a one-dimensional array into a multi-dimensional array
• Flatten a multi-dimensional array into a single one-dimensional array
• Merge two one-dimensional arrays into a single one-dimensional array

Recipe 12.11 – Hiding Strings
See the book

I also read through all of the comments on Freedom to Tinker to look for potential solutions and bring them to light. Here are some of the more interesting comments I found:

Will Michaels said, “Full Disk Encrypting (FDE) hard drives perform the encryption in hardware directly on the hard drive, using a key that never leaves the drive. Such FDE drives are protected against this attack on off-drive encryption.”

Laszlo Hars said, “…However, it has been recommended for ages that encryption keys are never stored in RAM. They have to stay in a locked part of the processor cache. It was not because of the chilled-RAM effects, but because of virtual memory (swap file), or hibernation. The OS might write any info from RAM to disk, where an attacker can find it later. It is surprising that BitLocker does not follow this practice. TrueCrypt is known to be weak both in the choice of algorithms and their implementation (an example is their recent choice to implement the IEEE P1619 encryption standard meant for completely different type of applications)….”

Brad Templeton said, “Sorry, Ed, I’ve been hearing about this technique since the 90s. It’s not new. Rumor is that spooks have been using it for some time. Here’s an old message board thread a quick Google search found.

Laszlo Hars said, “The real issue revealed by the paper is not weaknesses in disk encryption software, but a cheap way to go around DRM, and code privacy. You run the protected code, like a DVD player or a game in one PC, freeze and move the RAM to another machine (can be the same one rebooted to DOS), where you can analyze the memory at your leisure. You can disassemble protected code, find media keys, etc. It is simpler and cheaper than using high speed, logic analyzers on memory lines.”

Justin Wells said, “…Even were the disk encryption key problem resolved somehow the attacker could still use this technique to recover data the user had thought was secure. Recovering the key simply allows the attacker to recover ALL the data, rather than only the data in RAM….”

and, “The “key stored in CPU” used to encrypt RAM, or used to encrypt the disk key stored in RAM, need be nothing more than some randomized values in a few registers that are then preserved. All access to the encrypted data would then make use of the randomized values. The randomized memory encryption key stored in the CPU can be recreated on every boot of the system–there is no need to preserve it over time. Its purpose is simply to make memory unreadable.”

Christopher said, “You’re right, some common platforms use a hardware assist to look in the page tables. IA-64 can turn off hardware assistance, so that a TLB miss raises an exception rather than turning to the page table-handling hardware, but the vanilla IA-32 needs its page tables loaded in memory, and as you point out, the TLB isn’t designed for recovering values stored in it.

Of course, if we’re talking about IA-64 or x86_64, we’ve got a lot of registers available to us, we might be able to hold four of them aside with a modified compiler, but that also assumes you can ensure these registers won’t get pushed to the stack on an interrupt request, or cleared by a context change.

OK, registers, TLB, cache. Is there anywhere else a person can find 256 bits of volatile storage on the die of a modern CPU? Hardware performance counters? You can read those, but I don’t know if you can write them, or turn off their updating.

Anonymous pointed out, “I saw something similar to this presented at Black Hat DC last year. Except they were semantically rebuilding the memory image to extract the TrueCrypt keys. link“

Todd said, “…Also no one has mentioned graphics card memory! OUCH! While there may not be tons of useful data there, it is conceivable that a illegitimate user could cull the image(s) of recent used documents….”

Andreas said, “Some processor architectures, like the SPARC architecture for example, provide general registers that are not saved onto the stack (e.g. %g1 to %g7 in case of SPARC) and support multiple register sets, including one exclusively for the operating system. On these architectures it would be feasible to keep the key permantly in registers which would never be copied into memory.”

Richard L. Enison claimed to have a patent on storing encryption keys in hardware. sigh.

You’re welcome for reading that entire thread for you, and yes, this is how I spend my weekends.

EDIT: I saw that Nate Lawson of Root Labs entered the discussion today with a post on his blog. He seems to agree with Dan F that adding crypto the processor is the best long term solution but he also suggests things FDE developers can do in the meantime.