Cold Beacon

The brief

Evidence tag IR-2231-A, pulled off a workstation mid-engagement. One file, no other artifacts recovered, no notes from the box owner. It expects one argument: ./cold-beacon KEY. With the right key it prints the config it was carrying, otherwise it just says it's sealed. Linux x86-64 ELF.

• cold-beacon.zip, 17 KB

In short

Cold Beacon checks a 24 byte key against 23 byte rules stored as tables. The rules chain together and leave 981 valid keys. A SHA-256 digest of the config, stored in the sample, picks the one real key, and the config it unseals is the flag.

One file that stays sealed

The sample is a stripped 40 KB Linux program written in Nim. It takes one key and prints the config it carries, or config sealed. Even that message is stored XORed with 0x5A, so no readable text gives it away.

23 rules in three tables

The key check reads three tables. One holds 23 expected values, one the key bytes each rule uses and one the operation, from the XOR, sum or product of a pair to the sum or XOR of six bytes.

Sums that chain along the key

Thirteen rules add neighbouring bytes, such as byte 9 plus byte 10 giving 0xa8. They form three chains along the key, so three free bytes decide the rest through the other rules.

981 keys pass every rule

Trying every value of the three free bytes leaves 981 keys that satisfy all 23 rules. The check alone cannot tell them apart.

The digest picks one

The config is 47 encrypted bytes. Its keystream is SHA-256 over the key's own hash and a counter, and the plaintext must match a SHA-256 digest stored in the file. Exactly one of the 981 keys passes.

The key that unseals it

The key is C0ldB34c0n::unl0ck::7a3f. Given to the original sample, it prints the config instead of config sealed, and the config is the flag. The whole solve took five minutes.

The insight

Byte rules that chain together left only three free bytes, and a stored digest of the plaintext then named the one real key.

The flag

hiCTF{c0ld_b34c0n_cfg_uns34l3d_fr0m_th3_s4mpl3}