FallWire CTF Autumn Circuit 2026
qualifier board online

FallWire CTF 2026

A 36-hour low-level security contest built around reversing, exploitation, forensics, protocol work, and one hardware track that usually ruins somebody’s weekend.

View hardware main Browse categories Read rules
17–19 Oct Contest window, UTC
27 tasks Across six tracks
fwctf{} Flag format
event brief

Competition overview

FallWire is run as a mixed online qualifier with remote infrastructure and isolated challenge instances. Times are shown in UTC. Challenge text is intentionally terse where discovery is part of the task.

Format Jeopardy

Individual tasks grouped by category. Dynamic scoring is disabled for the hardware main.

Window 36 hours

Starts 2026-10-17 09:00 UTC and closes 2026-10-18 21:00 UTC.

Teams Up to 4

Shared accounts are blocked. One flag submission per team account.

Contact #fallwire-help

Use Discord for infra issues only. Challenge hints are posted publicly.

board

Challenge categories

The hardware track has one main task this year. It is intentionally longer than the rest of the board, with a separate review queue for suspected unintended solutions.

web

Web

Three tasks covering parser mistakes, session edges, and a deliberately unpleasant template chain.

3 tasks850 pts
crypto

Crypto

Small primitives, bad composition, and a final task that rewards reading the implementation twice.

4 tasks1,100 pts
pwn

Pwn

Linux userspace exploitation with one kernel-adjacent warmup and no artificial proof-of-work gates.

5 tasks1,450 pts
rev

Reverse

Native binaries, a small VM, and one Windows service that is friendlier than it first appears.

6 tasks1,500 pts
forensics

Forensics

Disk images, memory snapshots, and a packet capture where the obvious protocol is a distraction.

8 tasks1,300 pts
hardware / main

The call of the fall

Main hardware challenge. DMA board, Windows target, driver validation, and one file worth reaching.

1 task500 ptsHard
hardware main

Challenge details

This is the official public page for the hardware category’s main challenge. All device activity must remain inside the supplied lab environment.

Hardware Hard 500 pts Main challenge HW-500

The call of the fall

A practical firmware-and-host-validation challenge built around a supplied Enigma-x1 v3 75T board and a Windows target that does not trust unfamiliar hardware.

Scope notice: this challenge is designed for a closed CTF lab. The page intentionally avoids real-world bypass instructions, production evasion details, or hardware-use guidance outside the contest instance.

Description

You got your hands on a DMA card.

Nothing exotic in the lab crate this year: the supplied board is an Enigma-x1 v3 75T. It is compact, common enough to have predictable quirks, and loud enough that the default image is not going to survive close inspection.

The target is a Windows host running a custom kernel driver. The driver watches the device as it appears, records how it behaves during initialization, and keeps enough state to notice when the story changes later. If the card looks inconsistent, the driver disables the device and the instance has to be reset.

The endpoints, operator workstation, and exact deployment path are not the interesting part. The problem is narrower: understand how the board presents itself to the host, understand what the driver is willing to accept, and produce lab firmware that stays boring for long enough to complete the objective.

Default firmware fails immediately. The winning solution is not about speed; it is about consistency.

Goal

Retrieve the flag from the target system:

root.txt

Provided files

File Purpose Notes
enigma_x1_v3_75t_board_notes.zip Board notes, pinout references, expected lab setup, and known-good boot observations. Read first. It includes only challenge-scoped information.
firmware_template.tar.zst Build skeleton and placeholder firmware image used by the challenge. The template is incomplete by design.
driver_observations.txt Sanitized notes from the organizer’s test runs against the Windows driver. No direct bypass is documented.
target_manifest.json Instance metadata and reset behavior for the isolated target host. Generated per team at launch.
boot_trace_00.sal Reference capture from a failed default-firmware boot attempt. Useful for comparing early initialization behavior.

Environment

  • Target: isolated Windows host provisioned per team.
  • Device: Enigma-x1 v3 75T board supplied inside the lab profile.
  • Protection: custom kernel driver that validates attached hardware during and after initialization.
  • Reset: automatic when the driver disables the device or when the team requests a clean instance.
  • Flag location: root.txt on the target system.

What the driver checks

The driver is not magic, and it is not meant to be treated as a black box forever. The public challenge page does not list its exact decision logic, but participants should expect it to compare the story the device tells at enumeration time with the story it continues to tell while the host is running.

The supplied notes and traces are enough to reason about:

  • Identity and descriptor consistency.
  • Initialization order and timing at a high level.
  • Capability reporting and follow-up behavior.
  • Whether the board behaves like the same device across the full boot path.

Submission

Submit the exact flag string. The platform accepts one submission every 60 seconds per team for this task. Flags are single-use per team and are regenerated when an instance is reprovisioned.

fwctf{example_format_not_the_flag}

Hints

Hint 1 — released at T+6h Start with the first moment the host learns what the device claims to be.
Hint 2 — released at T+12h The driver does not need a complete model. One contradiction can be enough.
Hint 3 — released at T+24h A boring device does not become interesting after the first successful handshake.

Organizer notes

This task was written to reward patient comparison work, careful lab notes, and small, well-tested changes. Large rewrites tend to make failures harder to explain. If the device is killed, save the trace before resetting the instance.

Unintended solutions are allowed only when they remain within the challenge VM and the supplied hardware profile. Attacks against the scoreboard, provisioning API, organizers, other teams, or any third-party hardware are out of scope.

standings

Hardware track snapshot

The static page ships with a sample standings block. Replace these rows with live data or remove the section when connecting to a scoreboard backend.

1 maple bushardware / rev 2,740 pts 12 solves
2 cold resetpwn / hardware 2,310 pts 10 solves
3 leftpad labsweb / crypto 2,180 pts 11 solves
4 irq pendinghardware / forensics 1,960 pts 8 solves
policy

Rules and scope

These rules are written for the public page so participants can cite a single location when asking whether an action is allowed.

Allowed

  • Reverse engineering and modifying files provided with this challenge.
  • Interacting with your assigned challenge instance and supplied lab profile.
  • Capturing logs, traces, and crash output from your own instance.
  • Publishing write-ups after the event embargo lifts.

Not allowed

  • Attacking the CTF platform, scoreboard, account system, or provisioning service.
  • Interfering with other teams, organizers, or unrelated third-party systems.
  • Using this challenge as authorization to test real machines or real production drivers.
  • Sharing flags, private instance files, or unpublished hints during the contest.

Flag format

fwctf{...}

Disclosure and write-ups

The write-up embargo ends 24 hours after the scoreboard closes. Please keep challenge-specific binaries, traces, and private instance data out of public repositories until the archive package is published.