Ghost in RAM

The brief

We pulled a RAM image from a Linux box that had been acting strange, steady CPU. The box has since been wiped, so this image is all that's left. Something was hiding in there, and it took a secret to the grave. Bring it back.

• ghost-in-ram.zip, 1.6 GB

In short

A Linux memory image hid a tiny bytecode machine that had encrypted a 30 byte secret with a seeded keystream and wiped the plaintext. The seed, the program and the ciphertext were all still in memory, next to two planted decoy flags.

Two gigabytes of raw memory

The only evidence is a 2 GB memory image of a Kali Linux box on kernel 7.0.12, too new for any ready-made analysis profile. The lab mapped its four memory segments itself and searched the raw bytes.

Four flags, all of them bait

The flag format shows up four times. Two copies of hiCTF{stop_here} sit in a note claiming the analysis is complete, two of hiCTF{d3bug_m3} in a fake thumbnail config. The lab set all four aside.

A tiny machine under the bait

The stop_here note sits inside a structure tagged GVM1. Its header names a seed, 0x6f2e1a53, then 91 bytes of bytecode, a 30 byte buffer of zeros and 30 bytes of ciphertext.

The loop inside the bytecode

The lab worked out the 14 opcodes and read the program. It steps a linear congruential generator, state times 0x41C64E6D plus 0x3039, and XORs each plaintext byte with the top byte of the state.

XOR runs both ways

The plaintext was wiped, but the same seed gives the same keystream. The lab ran the bytecode on the ciphertext in its own interpreter, and after 457 instructions it halted on 30 printable bytes, the flag.

The insight

The secret was wiped, but its encryptor stayed in memory with the seed beside the ciphertext. A XOR keystream applied twice gives the plaintext back.

The flag

hiCTF{gh0st_pr0c3ss_rng_pwn3d}