Introducing **ESP32-BinForge**, a compact tool for working with ESP32 firmware `.bin` files. It enables **post-build customization** of firmware without recompiling or relinking — useful for embedding assets, configuration data, or personalizing devices after compilation.

**Key Features:**

* Inject user data into a reserved region of the firmware image
* Automatically regenerates CRCs to detect whether the reserved blob has been modified
* Examine firmware segments: flash mode, chip type, entry address, load addresses, file offsets, sizes, CRC checks, and SHA-256 presence
* Includes PlatformIO and Arduino examples for easy testing and integration
* **Cross-platform CLI**: Integrate BinForge into scripts, CI pipelines, or automated firmware workflows across Windows, macOS, and Linux

**Important note about the CRC:**

* The CRC only indicates whether the reserved blob has been modified.
* It does **not** validate firmware integrity or other segments.
* The contents of the reserved region are entirely user-defined.

**Demo / Example:**  
The included demo shows **serial number and licensee injection** post-build. The screenshots attached illustrate the terminal output: the leftmost image shows the compiled firmware without modification, and the adjacent windows show the results after BinForge processing.

Additionally, there’s a screenshot of the **BinForge GUI** dumping firmware image details.

**Use Cases:**

* Embed ROM-resident assets like logos, tables, or game images
* Generate multiple firmware variants from a single base image (branding, region-specific config, etc.)
* Repair CRCs after manual or automated binary edits
* Support emulation or retro firmware projects by embedding game data directly into binaries

**Scope & Compatibility:**

* ESP32, ESP32-S2, S3, C2–C61, H2–H4, P4, S31
* Single reserved data blob per image (minimum 32 bytes)
* Operates on unencrypted firmware (encryption must be applied afterward)

**Notes / Limitations:**

* SHA-256 is currently disabled for modified images; regeneration planned for future releases
* Users must ensure injected data fits within the reserved region
* BinForge does not interpret blob contents or enforce correctness beyond CRC detection

**Repo:** [https://github.com/Mr-PauI/ESP32-BinForge](https://github.com/Mr-PauI/ESP32-BinForge)

I’m keen to get feedback from the embedded community. If you’re experimenting with **post-build firmware customization**, BinForge can save time, reduce rebuilds, and help manage device personalization efficiently.

BinForge – Post-Build ESP32 Firmware Tool & Framework for Injecting Data