FinitHicDeo: A CTF Built Around Protocol Behaviour

Challenge overview

FinitHicDeo is a downloadable CTF machine I created with Nachiket Rathod. I wanted a lab that encouraged research into protocol behavior, including HTTP request smuggling, alongside a programming task.

The VulnHub entry describes the VM and provides the download. The GitHub repository contains the original introduction and a Google Drive download link.

My original post introduced the challenge rather than documenting a complete solve. I keep that distinction here. The notes below explain the themes and how I approach the lab; they do not claim an unrecorded foothold or flag.

Set up the machine

I import the VM into a compatible hypervisor and place it on an isolated lab network with my testing machine. The published machine uses DHCP, so I find its assigned address rather than relying on an address from someone else's walkthrough.

I take a snapshot before beginning. That gives me a known starting point if an experiment changes application state or breaks a service.

Recon

I start by identifying the services exposed by the imported machine. In the following command, LAB_VM_IP must be replaced with the address assigned inside my isolated lab:

nmap -sV -oN finithicdeo-services.txt LAB_VM_IP

The default scan is an initial inventory, not proof that every port has been checked. I follow up based on what the machine exposes and what the challenge requires.

For a web service, I save a normal request and response before testing parser behavior. For a custom TCP service, I record the greeting, prompts, delimiters, and connection behavior. Those details tell me what a script needs to send and receive.

Foothold

The original notes mention a Bulls and Cows-style guessing task handled through a Python socket connection. A useful client needs more than a loop that sends guesses. It needs to understand the service's actual message format.

I first establish whether the secret uses digits or words, whether symbols can repeat, and how the response distinguishes a correct position from a correct symbol in the wrong position. I do not assume those rules from the game's name.

For a solver, I would keep a candidate set and remove entries that disagree with each response. Before automating guesses, I would verify the scoring logic against a few manually understood cases.

A TCP read can return part of a message or several messages together. I therefore buffer received bytes until the protocol's delimiter or length condition is met. Assuming one recv() equals one response is an easy way to build a solver that works intermittently.

Escalation or solve

The other theme in the original post is HTTP request smuggling involving Gunicorn. The important question is how components decide where a request ends.

A reproducible demonstration needs the actual deployment: server versions, any intermediary, the exact bytes sent, and evidence that components disagree about request boundaries. Naming Gunicorn alone does not identify an affected version or prove a vulnerability.

I keep the programming task and request-smuggling task separate until the evidence establishes how they connect. The original post did not document their order, so I do not invent a chain between them.

For a completed solve, I would preserve each transition: the observation, the successful action, and the new access or information it provided. That makes the reasoning easier to follow than a collection of final commands.

Flag

The original notes did not include a flag, its location, or a final verification step.

Dead ends and lessons

I do not have a recorded list of failed attempts from the original run. The useful habits I would carry into a fresh attempt are straightforward: capture the protocol before writing the solver, test one framing hypothesis at a time, and keep the VM's versions with the evidence.

The point of this machine is to make me explain why an input changes a service's behavior. That explanation is the part worth keeping after the challenge is finished.