Nishcheta — AlfaCTF

Short Challenge Summary

We were given peace_6ce0fda.tar.gz, containing a hardware-style keypad/display simulation. The goal was to understand how the 4x4 phone keypad fed the synthesized Verilog design and then recover the flag that occasionally appeared on the 128x64 display.

Recon / File Analysis

The useful files were:

• peace.py — a cocotb harness for interacting with the device in simulation
• peace.v — a large Yosys-generated Verilog netlist
• Dockerfile and docker-compose.yml — environment helpers

This immediately suggested that the intended path was not manual clicking alone. peace.py made simulation easy, while peace.v exposed the real behavior of the device, including the internal buffers and display writes.

The most important early observation was that several false leads existed around hidden selector logic. Instead of spending too much time guessing what hidden branch might unlock the flag, the reliable approach was to inspect what the Verilog actually wrote into the display/output pages after a committed input.

Input Model: Multi-Tap Keypad

The keypad logic uses old-phone multi-tap input. Repeated presses on one key select a specific symbol for that key's group, and the character is only useful once the tap is cleanly committed.

The character mapping needed for the solve was established from the simulation:

• 9999 -> y
• 4 -> 4
• 22 -> a
• 66 -> m

So the winning input groups were exactly:

9999
4
22
66

These four committed groups produced plaintext bytes corresponding to:

y4am

A key optimization during solving was to force the internal key-detect signals for a single cycle. That emulated one clean committed tap group, avoided timing noise from manual interaction, and made it much easier to test candidate inputs reproducibly.

Reverse-Engineering Findings in the Verilog

...