FirmwareFlow

简体中文

FirmwareFlow is a Tauri desktop application for visually designing firmware packaging workflows and exporting standalone CMake projects or executables.

用户指南 · User Guide

Visual Workflow

1. Start from a template

Create an empty project or select a built-in firmware, security, AES, or DLL workflow template. Templates include practical sample binaries and test keys so the generated project can be exercised immediately.

2. Configure the workflow

Connect processing steps on the canvas and edit the selected step in the inspector. FirmwareFlow validates inputs, outputs, links, and required parameters while you work.

3. Generate the output

Export a standalone CMake source project for manual compilation, or build a ready-to-run executable with the selected toolchain.

Development

npm install
npm run tauri:dev

The repository includes the generic C project skeleton under template/. Generated projects statically compile the required firmware editing implementation from that template.

Build Environment

Generate first asks whether to export a source project or build an executable. Source Project exports src/, core/, CMake files, the helper batch file, and workflow.ffc for manual compilation. Executable builds with CMake and Ninja, then keeps only the workflow executable, helper batch file, and workflow.ffc.

The startup Toolchain page lets the user choose one of these environments. OpenSSL is always supplied by the application resources and does not require a separate user path:

• System: use CMake, Ninja, and GCC already available on the machine.
• Bundled: prepare the offline subset shipped with the app on first use.
• Custom: select the cmake.exe, ninja.exe, and gcc.exe paths separately.

The bundled payload is the default build environment for new installations. It is a curated build subset, not a complete MSYS2 installation, and currently contains CMake 3.26.4, Ninja 1.11.1, MSYS2 MinGW64 GCC 15.2.0, and OpenSSL 3.6.0. The Toolchain page provides links to the official CMake, Ninja, MSYS2, and OpenSSL websites.

The offline payload is staged under src-tauri/toolchain/. Packaging includes one toolchain.zip archive plus its manifest and README, so the installer does not have to create thousands of compiler files. The archive is extracted into the application data directory only the first time Bundled is selected, then the prepared directory is reused. The OpenSSL subset is also packaged as a direct resource for System and Custom selections.

The binary toolchain archive is intentionally not stored in Git. Normal development and npm run tauri:build do not require it. Before creating an installer, stage it from locally installed upstream tools; tauri:bundle enables the additional release resource configuration:

.\scripts\stage-offline-toolchain.ps1
npm run tauri:bundle

Build the desktop executable with:

npm run tauri:build

Installer packaging is available through npm run tauri:bundle when the local WiX/installer toolchain is ready.

Workflow

• Drag a step from the left rail into the canvas.
• Connect steps to define execution order.
• Select a step to edit its parameters in the right inspector.
• Use Generate to export a CMake source project or build an executable package.
• Use Share Copy to export an .ffc file without local absolute paths or literal keys.
• Save or load .ffc project files from the toolbar. The file content remains JSON.

The current step library includes fill, crc, delete, sha256, sha256-bin, ECC256 signing, RSA PKCS#1 v1.5 signing, RSA-PSS signing, RSA PKCS#1 v1.5 verification, RSA-PSS verification, signature embedding, AES-CMAC, HMAC-SHA256, AES-CTR, AES-CBC, AES-ECB, insert, and merge.

Crypto step notes:

• AES-CMAC and HMAC-SHA256 calculate over an image range and produce binary artifacts.
• AES-CTR consumes raw binary bytes and produces raw binary bytes.
• AES-CBC and AES-ECB consume block-aligned binary bytes and use no padding.
• AES keys and AES-CTR IV use hex text; AES keys must be 16, 24, or 32 bytes and AES-CTR IV must be 16 bytes.
• ECC256 Sign uses prime256v1 with SHA-256 and outputs a fixed 64-byte big-endian raw r || s signature.
• Embed Signature writes signature bytes at the start of a reserved image region and pads the remaining region with the configured fill byte; it does not verify the signature automatically.