New Project Wizard
7-section wizard for creating a new hardware assessment project.
Creating a New Project
The New Project wizard (/new_project) walks you through defining every aspect of a hardware security assessment. It uses progressive reveal — each section appears only after the previous section’s required fields are filled. A validation panel at the bottom lists missing required fields, and the Create Project button remains disabled until all requirements are met.
On submission, Gauntlet creates a CLIENT_DEVICE.yaml file in your chosen directory, registers the project in projects.json, and builds the output directory structure that Gearbox expects.
To edit an existing project, use Edit Project from the home page — the same form loads pre-populated with all current values. Adding or removing subdevices/interfaces automatically cleans up stale progress entries.
Section 1 — Target Directory
The server-side filesystem path where the project will be created. Gauntlet creates a subdirectory structure here for the YAML config and all output files.
| Field | Required | Description |
|---|---|---|
| Project Parent Directory | Yes | Full server-side filesystem path (e.g. /clients/acme). A subdirectory will be created here for the project YAML and output. If left blank on create, Gauntlet auto-builds a structured path: <clients_base>/<client_short>/<year>/gearbox/<client_short>_<timestamp>/. |
Section 2 — Client Information
Identifies the client organization for the assessment. These values appear in reports and determine directory naming.
| Field | Required | Description |
|---|---|---|
| Client Full Name | Yes | The client organization’s full legal name (e.g. Acme Corporation). Used in report headers and project metadata. |
| Client Short Name | Yes | Abbreviated identifier, max 12 characters (e.g. ACME). Used in directory paths, filenames, and the project YAML. Becomes editable after Client Full Name is entered. |
Section 3 — Consultant Information
Identifies the security consultant performing the assessment. Fields enable progressively as you fill them.
| Field | Required | Description |
|---|---|---|
| Consultant Name | Yes | Full name of the lead consultant. |
| Title | Yes | Job title (e.g. Senior Security Engineer). Enables after Name is entered. |
| Consultant Email | Yes | Professional email address. Enables after Title is entered. |
Section 4 — Client Point of Contact
The client’s designated contact person for the engagement.
| Field | Required | Description |
|---|---|---|
| POC Name | Yes | Client point-of-contact name. |
| POC Phone | No | Phone number. Enables after POC Name is entered. |
| POC Email | Yes | Email address. Enables after POC Name is entered. |
Section 5 — Assessment Dates & Version
| Field | Required | Description |
|---|---|---|
| Year | Yes | Engagement year (defaults to current year). Used in the project directory path structure. |
| Report Version | No | Version identifier for the assessment report (defaults to 1.0). Useful when re-assessing the same device. |
| Start Date | Yes | Assessment start date in MM/DD/YYYY format. |
| End Date | Yes | Assessment end date in MM/DD/YYYY format. |
Section 6 — Device Under Test
Identifies the physical hardware device being assessed.
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | Descriptive name of the device (e.g. Industrial Control Unit, Patient Monitor, Access Control Panel). |
| Model Number | Yes | Manufacturer’s model/part number (e.g. ICU-3000-A). Enables after Device Name. |
| Software Version | Yes | Current firmware or software version running on the device (e.g. v2.4.1). Enables after Model Number. |
Section 7 — Sub-Devices & Interfaces
This is the most complex and important section. It defines the physical structure of the device under test, which determines exactly what Gearbox will test and how evidence is organized.
The hierarchy is: Device → Sub-Devices → Interface Types → Instances
Sub-Devices
A sub-device is a distinct physical component of the device (e.g. Main Board, Display Panel, Sensor Module, Power Supply Unit). Select the number of sub-devices (1–10) from the dropdown, and a form group appears for each one. Each sub-device needs a descriptive name.
Interface Types
For each sub-device, a checkbox grid of 19 interface types is shown. Check the types that the sub-device has. Checking a type reveals its instance configuration.
Each interface type determines which Gearbox test modules run against it. For example, checking Ethernet enables 20+ modules (discovery, port scanning, vulnerability scanning, SSL/SSH analysis, SMB/NFS enumeration), while checking USB enables HID testing, power analysis, and Bash Bunny assessment.
| Interface Type | Test Focus |
|---|---|
| Ethernet | Full network security: discovery, port scan, banner grab, web, SSL, SSH, SMB, NFS, FTP, Nessus, nuclei, responder, traffic capture |
| USB | HID keyboard/mouse injection, USB power analysis, Bash Bunny payload execution |
| Ethernet_tap | Passive traffic capture during running, boot, and shutdown states |
| HDMI / DVI / SDI / DP | EDID analysis, DDC/CI capabilities, HDCP verification, CEC command injection |
| RCA / Aux | Audio/video input and output assessment |
| Zigbee | Zigbee packet sniffing and flood testing |
| Bluetooth | Bluetooth Classic and BLE assessment |
| DB9 | Serial protocol detection and CAN bus assessment |
| WiFi | WiFi wireless security assessment |
| SubGHz | Sub-GHz radio (315/433/868/915 MHz) testing |
| UWB / SmartCard / ZWave / LoRa | Protocol-specific RF and contact assessments |
| RFID | RFID sniffing and replay attack testing |
Instances
Each interface type on a sub-device can have multiple instances — these represent physical ports or connection points. For example, an Ethernet interface might have instances for Front Panel RJ45 and Rear Panel RJ45.
Each instance needs:
- Instance Name — an identifier (e.g.
eth0,usb_left,can_bus) - Location — physical location description (e.g. Front panel left, Rear USB-A Port 1)
Instance keys are automatically derived from the location field and are used in the output directory structure. Gauntlet auto-migrates placeholder instance names to human-readable ones on first load.
Creating the Project
When all required fields are valid, the Create Project button becomes active. On submission:
- A
CLIENT_DEVICE.yamlis written to the target directory - The output directory structure is created (subdevice → interface → instance → module folders)
- The project is registered in
projects.json - You’re redirected to the project dashboard
The YAML file is what Gearbox reads at launch time to know what device structure to test.