Tasmota Vault

The brief

A farm gateway was retired during a vault-key rotation. Its flash still holds a sealed record, and the recovery lab preserved a short broker session. Recover the record the gateway could authenticate. The gateway uses official ESP32 Tasmota firmware with a custom Berry agent. Analyze both the flash image and the MQTT traffic.

• tasmota_vault.zip, 56 MB

In short

A retired ESP32 Tasmota gateway left a sealed record in its flash. Its key comes from a flash secret and a rotation nonce that only arrived over MQTT. The lab rebuilt the file system and the TCP stream, and only one pairing made the AES-GCM tag verify.

Half a key in each file

A retired farm gateway left a 4 MB flash dump and a 2,688 byte MQTT capture. The sealed record sits in flash, but its key needs a value that only ever arrived over the network.

Only four blocks were custom

The firmware matched the official Tasmota image byte for byte. What remained were four LittleFS blocks behind a partition labelled spiffs. Read by hand, they hold a Berry script, a device id, a keyring and a 74 byte sealed record.

The script holds the recipe

The lab disassembled the 1,464 byte Berry bytecode. On each rotation message it takes that epoch's 32 byte secret, mixes in the device id and the message's 32 byte nonce through HMAC-SHA256, and opens the record with AES-GCM.

The real message came in pieces

The lab rebuilt the TCP stream by sequence number. Packet 12 is a retained epoch 7 message, old state replayed to a new subscriber. The live epoch 8 message spans packets 18, 19 and 21, and packet 20 repeats 19.

The tag picks one pairing

Three keyring epochs and two nonces make six candidate keys. Only the epoch 8 secret with the live epoch 8 nonce makes the GCM tag verify, and the 46 byte plaintext is the flag.

The insight

The flash secret was never the key alone. It needed the live nonce from the wire, and the GCM tag proved which of six pairings the gateway could open.

The flag

hiCTF{b3rry_r0t4t10n_c94934d76344ab1151e03afd}