Nimble

A 9-sample static-analysis set (zip password infected, AES — so 7z or pyzipper) spanning C/C++ ELFs, a .NET PE, JARs, a Swift binary and a Nim binary. Every sample hides its config in the same HCFG container, which is worth learning once because it shows up again (see Bridge Troll).

Start with the ELFs. readelf flags a section a compiler would never emit, and since the binary isn't stripped the symbol name gives the game away:

$ readelf -SW day2.elf | grep hcfg
  [17] .hcfg    PROGBITS   ...
$ readelf -sW day2.elf | grep -i config
   _ZL11config_blob   OBJECT   379   17      # demangles to a static "config_blob"

Dump it and the shape is obvious — a magic value, then bytes mostly in the 0x40–0x5f range with a lot of 0x13 (the fingerprint of printable text XOR'd with one byte):

$ readelf -x .hcfg day2.elf
  48 43 46 47 01 31 6f 01 00 aa 49 61 4a 13 52 50 ...

Breaking the 12-byte header apart:

bytes	meaning
48 43 46 47	magic HCFG
01	version
31	XOR key = 0x31
6f 01	length, little-endian = 0x016f = 367
00 aa 49 61	CRC32, little-endian = 0x6149aa00

You don't even need the header to get the key — a one-byte XOR over JSON always starts with {, so the first encrypted byte XOR 0x7b gives it: 0x4a ^ 0x7b = 0x31. XOR the payload with 0x31 and it's clean JSON, and the CRC32 of the result matches the header exactly — that's how you know the decode is right and not just plausible:

{"campaign":"BR02-000","domain":"node-000.day02.example.invalid","ipv4":"198.51.100.40","url":"https://node-000.day02.example.invalid/api/BR02-000","mutex":"Global\\HuntressBR02_000",...}

import zlib
d = open("day2.elf","rb").read()
i = d.find(b"HCFG")
key = d[i+5]
n   = int.from_bytes(d[i+6:i+8], "little")
crc = int.from_bytes(d[i+8:i+12], "little")
p   = bytes(b ^ key for b in d[i+12:i+12+n])
assert zlib.crc32(p) == crc          # decode confirmed
print(p.decode())

The only thing that changes per day is where the blob lives — raw in the binary, a Base64 constant in a Java class, inside the Swift data section, or a Nim string literal sitting next to a raw[0..3] == "HCFG" assert. The .NET PE (d03) is the odd one out: readelf won't touch it, but objdump -p shows the CLR runtime header and the lone mscoree.dll!_CorExeMain import, so it's managed code. Open it in ILSpy/dnSpyEx and the config is a 379-byte array that prints in decimal as 72, 67, 70, 71, 1, 65, 111, 1, ... — that's HCFG, version 1, key 65 (0x41) — decoded with the exact same loop. Day 1 also had a recover_code symbol that was just mov eax, 0x1fa4 ; ret → 8100. All solved statically — nothing ever executed.