$ cat writeup.md…
$ cat writeup.md…
alfactf
Task: a Verilog keypad/display module stored typed text in one 64-byte buffer but exposed only a transformed 64-byte display blob. Solution: simulate the keypad, recognize a white-box AES-128 ECB core in the Verilog tables, recover the key, and decrypt each reversed 16-byte block.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
В модном коворкинге есть две зоны — «Нищета» и «Покой». Доступ решает аппаратный модуль. Один человек ввёл флаг задачи на клавиатуре, а после завершения на дисплее остался 64-байтный hex-blob.
The archive contained a Verilog design and a Python/cocotb interface for a keypad-driven display module. We were given the 64-byte blob shown after someone typed the real flag and had to recover the original plaintext.
Given output:
71 80 dd 08 6c 43 37 6b 3c a8 e2 68 6d 0a 97 9b f8 23 b9 66 6a b9 92 d3 cd ad 80 cf e8 5a ed 1f c5 c4 6c 60 c0 a3 a5 c9 11 a1 d1 98 f1 83 53 95 53 e4 b9 7c 16 5f c4 3b a3 f5 1e 12 53 1f ea ca
The supplied files immediately suggested a hardware-reversing task rather than a normal software crackme:
peace.v was the synthesized Verilog design.peace.py was a cocotb TUI that let us press keys and view the display.The first key observation was that the display buffer was not a plain echo of the typed text. Even with empty input, the internal output area already contained nonzero bytes. That ruled out a direct framebuffer copy and strongly suggested some fixed transform or whitening stage.
Before reversing the crypto-like core, it was useful to understand how text entered the device.
By driving the keypad in simulation, the text entry logic turned out to be old-phone multi-tap input:
...
$ grep --similar