mirror of
https://github.com/morluto/rea.git
synced 2026-11-03 13:26:10 +00:00
Entrpi
e6d0618979
* feat(artifacts): inventory and extract ESP32 firmware images ESP32-family app and bootloader images (magic 0xE9) had no reader, so open_binary refused OTA downloads, app partitions and bootloaders. Add the esp-image container format behind inspect_artifact and extract_artifact. A pure decoder reads each byte once and keeps only fixed-size fields. Derived facts cover the chip, from a table cited to ESP-IDF v6.1; segment classification as ESP-IDF's should_map and should_load; checksum and appended SHA-256 results; app and bootloader descriptors; Secure Boot v2 signature blocks, observed and unverified; and undescribed trailing byte ranges. Truncation and undescribed bytes make coverage unknown. ESP8266 images are refused with a specific reason, and ciphertext stays unrecognized. Add the format to every target, Evidence, snapshot, live-summary and artifact vocabulary, document it, and add an optional verify:esp-images lane that compares esptool-built images with esptool image-info and espsecure signature-info-v2. Refs #3615 * test(artifacts): run the ESP image lane on esptool v5.6.0 The lane compared descriptor fields only when esptool image-info printed one, so a descriptor that REA reports and esptool does not print passed without comparison. Compare the descriptor kind in both directions. Record that the lane passed for all 13 images with esptool and espsecure v5.6.0, the version the layout facts cite, as well as with 4.12.0. * refactor(artifacts): define ESP image layout sizes once The decoder and the derived facts each defined the segment-header, appended-digest and flash-sector sizes, the erased-byte scan and the offset formatter. Define them once with the other fixed-layout structures and import them in both places. The signature slot count is the one constant that drives the slot scan. Correct the observedEnd comment: it is the end of the last chunk read. * fix(artifacts): report ESP-IDF's segment length limit by chip ESP-IDF's verify_segment_header rejects a segment of 16 MiB or more unless the chip maps flash through 32-bit cache addresses (SOC_SPI_MEM_SUPPORT_CACHE_32BIT_ADDR_MAP: ESP32-S3, P4, C5, C61, H4 and S31 in v6.1). Record that capability in the chip table and add a limitation for such segments; unknown chips get none. `loaded` repeats should_load. It does not mean the bootloader accepts the segment: verify_load_addresses still rejects one outside the chip's RAM, which REA does not model. Say so in the docs, the skill reference and the inventory limitation. * test(artifacts): check ESP lane tools first and verify extraction The lane started work before checking its tools, so a missing RISC-V target, ld.lld, esptool or espsecure surfaced as a raw spawn or command error. Check each one before building and name the variable to set. Warn when esptool is not v5.6.0, the release the layout facts cite. Assert each segment's class for the ESP32-C3 app, its variants and the bootloader, as the Xtensa image already did. Extract the app and the signed image through the CLI and compare every file with the bytes at esptool's segment offsets or in the appended signature sector; the source's SHA-256 must be unchanged and equal the reported root_sha256. * docs(artifacts): state what the ESP image lane does not establish The Verification section listed the lane's checks but not its gaps: only ESP32-C3 and ESP32 images come from a real producer, no real project build, OTA download or flash dump is inspected, no signature is verified, and the lane does not run in CI. Record the timing of the final lane run on esptool v5.6.0. * fix(artifacts): compare ESP segment declarations Segment entries hash only their data, so compare_artifacts reported a segment that moved to another load address with the same bytes as unchanged; only the image itself changed. Compare each segment's load_addr and data_len as its declaration, as Node SEA and PyInstaller members are compared, and count a changed declaration as a metadata change, also when content is unavailable. Header offsets are layout and the classification is derived, so neither is compared. * test(artifacts): run ESP lane commands as owned process trees The lane ran its tools through execFile. A timeout killed only the direct child, so a linker or assembler that Clang or GCC had started could keep running while the lane removed its workspace. Run every command through createVerifierCommands, check the tools inside withVerifierCleanup, and remove the workspace only after commands.close() has stopped every tree; a failed close keeps the workspace. Only a nonzero exit now counts as a refusal or an expected esptool failure; timeouts and spawn failures propagate. Supervising each command roughly doubles the lane's run time. * test(artifacts): cancel ESP decoding after its first decoded chunk The cancellation test requested cancel or close on setImmediate, which can land while the file is still being opened and checked, so it never showed that decoding had started. It also passed against a reader that ignored both requests while decoding. Acknowledge the decoder's first chunk, then cancel or close, join the operation, and assert that no later chunk reaches the decoder and that the reader ends closed. * docs(artifacts): record which ESP metadata comparison ignores Segments are compared by their declaration. The image's and the signature blocks' format_metadata are not: every field comes from their own bytes, which content comparison already covers, and a block's image_digest_matches follows the image's content. * feat(artifacts): inventory and extract ESP flash layouts A whole-flash dump of an ESP32-family chip was read as its bootloader image, with the partition table, apps and data left as undescribed bytes, or refused when it began with erased flash. Read it as an esp-flash-image container instead. The partition table is decoded as esp_partition_table_verify accepts it and is found at the caller's partition_table_offset, at the default 0x8000, or by scanning 0x1000-aligned sectors for a table whose MD5 verifies, which the inventory reports as derived. The bootloader is located at its chip's ROM bootloader offset. Each partition is an entry with its declaration in flat format_metadata; the bootloader and app partitions carry ESP image facts from the existing streaming decoder; the otadata records are reported with a selection derived without rollback or anti-rollback, and the running partition stays unknown. One unreadable partition does not hide the others, and extraction writes every partition, nvs_keys included, as ordinary data. Flash layouts are detected before single ESP images. The scan runs only when an ESP image sits at a ROM bootloader offset, and is refused when a bootloader at another chip's offset shows that the dump does not start at flash address 0. open_binary gains flash_offset and partition_table_offset, which require format esp-flash-image and are part of the snapshot target identity; the CLI takes them with --target-format esp-flash-image. Comparison treats a partition's label, type, subtype, range and flags as its declaration. * test(artifacts): verify ESP flash layouts with gen_esp32part, merge-bin and otatool Add the optional verify:esp-flash lane. It builds default and relocated partition tables with ESP-IDF's gen_esp32part.py, assembles dumps with esptool merge-bin, including one written from flash 0x1000, and writes OTA records with otatool through flash_file_tool.py, which replaces parttool's esptool calls with reads and writes of the dump file. It compares REA's bootloader and app facts with esptool image-info, every partition with gen_esp32part.py's decoding of the extracted table, and the OTA records and derived slot with otatool read_otadata after each switch. It also checks extracted bytes and source integrity, the scan and caller table offsets, flash_offset on the 0x1000 dump, a corrupted app beside valid partitions and a truncated dump. ESP32 linker scripts place the conformance bootloader and app in ESP32 address ranges. * fix(artifacts): read ESP flash layouts as the bootloader does Read the partition table as bootloader_utility_load_partition_table does: the last factory, otadata and same-subtype OTA declaration wins, and a limitation names repeats. Plan each otadata record within its partition and the dump. An otadata partition smaller than two sectors selects none, the bootloader's INVALID_INDEX; a record the dump lacks leaves the selection unknown while the other record stays reported. The fallbacks follow the bootloader's indexes: ota_0-fallback and factory-fallback name no partition when the table declares none, and the assumptions add GPIO holds and deep-sleep wake. Refuse a dump whose bootloader contradicts its origin before the default table offset is tried, whether flash_offset was omitted or given, and keep the ESP image reader's ESP8266 refusal. A table never lies inside the located bootloader image, so single app images are no longer scanned. An explicit esp-flash-image selection is decided before other container signatures, and the native commands' --target-format no longer takes it. Say when no bootloader confirms the default origin. Exempt the primary bootloader and partition_table entries of ESP-IDF 5.3 from placement limits, report every region inside a longer one, and name partitions by index when labels repeat ignoring case. Keep an undecodable label's bytes in label_hex and compare them. Word undescribed ranges as starting at a byte that is not erased, and treat a short erased region as erased. Add an MCP compare_artifacts test for partition declarations, reader identity and close tests, scan edge cases, the 0x2000 ROM offset and a literal otatool CRC. * test(artifacts): verify ESP primary layout entries and the otadata fallback Build a table with the primary bootloader and partition_table entries that gen_esp32part.py fills from --primary-bootloader-offset, and check that REA reads it with complete coverage, no overlap or misplacement limitation, and a table that agrees with gen_esp32part's decoding. Erase the otadata with otatool after the slot switches and check the records against read_otadata and the factory fallback. * fix(artifacts): keep ESP flash coverage complete for a dump cut short An esptool merge-bin dump ends after the last part it wrote, usually inside its last partition. Such a partition made the layout's coverage unknown, so artifact comparison of two merge-bin dumps reported every unchanged partition as unknown. The partition table names every partition whatever the file's length, so a partition cut short or left out by the end of the file hides no entry. As the ESP image reader does for a cut-short segment, its entry holds the bytes the file has and an entry limitation gives the declared size; a partition with no bytes stays in partitions_outside_dump. Coverage stays complete unless undescribed bytes remain or no bootloader is located. An MCP compare_artifacts test of two dumps that end inside ota_0 now classifies every partition, and fails on the old rule. * fix(artifacts): report written bytes in ESP partitions, erased slots included An app slot is erased for ESP-IDF's bootloader when its image header bytes are erased flash, and REA reported only that status. A slot can still hold data further in: a dump read from a device held a complete older app image 1 MiB into an OTA slot reported as erased, with no limitation. Each partition entry now records where the bytes the dump holds are written, relative to the partition: written_offset, the first byte that is not 0xFF, written_end, just past the last, and written_bytes, how many are not 0xFF. They are null for a partition outside the dump. The status stays erased, which is the bootloader's view, and a limitation names an erased app slot that holds written bytes and says they are not read as an image. The reader reads every partition byte once more to find them. * fix(artifacts): derive the ESP boot selection for every partition table The boot selection lived inside otadata, so a table without an otadata partition, the common factory-only layout, had none. ESP-IDF's bootloader_utility_get_selected_boot_partition returns the factory index when the table declares no otadata partition. Move it to a top-level boot_selection that every layout has. Its basis names the bootloader's branch: otadata, factory-fallback and ota_0-fallback from the records, no-otadata for a table without otadata, none for the bootloader's INVALID_INDEX, and unknown when the dump lacks a record the bootloader reads, which replaces the null selection. running_partition moves with it, and otadata keeps its partition index and records. The assumptions name what each branch leaves out: no records assumption without otadata, and none for none or unknown. The real-tool lane checks no-otadata on a table gen_esp32part built without otadata. * fix(artifacts): say when an ESP image is a flash dump read from 0x1000 An ESP32 dump read from flash 0x1000, as read-flash 0x1000 or merge-bin --target-offset 0x1000 writes it, opened automatically as its bootloader image with a megabyte of undescribed bytes and no next probe. The flash reader refuses that origin, but nothing told an agent which flash_offset to pass. espFlashDumpOrigin owns the inference: an image of a chip whose ROM loads the bootloader from flash R, at file offset F, is the bootloader of a dump read from R - F when a partition table sits where that origin puts 0x8000. The ESP image reader asks it for a non-app image at file offset 0, so the result does not depend on how the reader was created, and records flash_dump {flash_offset, table_file_offset}, null otherwise, with a limitation that says to reopen the file as esp-flash-image with that flash_offset. inspect_artifact proposes the same open_binary call as a next probe, and the flash reader's misplaced-origin refusal names the offset. * perf(artifacts): summarize nested ESP images in the flash layout summary view The summary view returned an ESP flash layout's root facts whole, so each app partition and the bootloader carried every segment and signature block, about half of a dump's summary. The summary view now gives each nested image a summary instead of its facts: status, chip, entry point, segment count, load ranges (each mapped, loaded or unclassified segment's address and declared length), the checksum and appended SHA-256 statuses, coverage and limitations. Complete detail keeps the full facts, every segment included, and the retained Evidence is unchanged. On a 16 MiB device dump the summary's root falls from 5,141 to 2,657 bytes, and the summary Evidence from 10,038 to 7,554. * test(artifacts): expect the misplaced image the ESP bootloader search reports8a748d3ccadded misplacedImage to the bootloader search, which the locator uses to name the origin a misplaced bootloader implies, but one test still compared the search result without it. Expect the image's chip and file offset, and no image for an unknown chip. * fix(artifacts): give every ESP partition from the dump's start an entry Afterecbc1a772kept coverage complete for a dump cut short, a partition wholly past the end of the file still had no entry, only a partitions_outside_dump row. Comparing a merge-bin dump with a full device read then reported that partition as added or removed, as if one table did not declare it. Every partition from the dump's first byte on is now an entry holding the bytes the file has: none for one past the end, with a limitation saying the file holds none of its bytes, no image facts and null written fields. partitions_outside_dump keeps only partitions that begin before the dump's first byte, and coverage is unknown when one does, since it has no entry. Two dumps that lack the same partition now compare it as unchanged, and a dump against a longer one reports the partition as changed; an MCP test of a merge-bin dump against a full one checks that no path is added or removed. Unlike the ESP image reader, which marks a truncated image's coverage unknown because later segments and signature blocks may be hidden, the flash reader can list every partition from the table whatever the file's length; only the entry limitation follows the image reader. * fix(artifacts): select no ESP app from a partition table the bootloader rejects boot_selection followed bootloader_utility_get_selected_boot_partition but not the table check before it. For a table whose MD5 does not match, or that has a second MD5 entry, esp_partition_table_verify fails, the bootloader selects no app and resets. REA still derived a slot from the otadata records, although the table's own limitation said the bootloader rejects it. The selection now has basis none, with no assumptions, for a table the decoder marks invalid. It also follows two more branches of the bootloader: an otadata partition at offset 0, which the bootloader takes for none, selects the factory index as no-otadata, and a table without an OTA app selects its fallback even when the dump lacks a record, since the bootloader then ignores the records. The bootloader also rejects a table whose partitions end past the flash size in its header. REA does not model that check; the format guide says so. * fix(artifacts): require the ESP dump origin's table to follow the image espFlashDumpOrigin named a later flash origin whenever a partition table decoded where that origin puts 0x8000. Bytes inside the image's own segments could be read that way, so an ESP32 bootloader whose segment data held table-shaped bytes at file offset 0x7000 was reported as a dump read from 0x1000. The table must now start at or after the image's end, the rule the locator already applies to the default table. The ESP image reader passes the image_end it decoded, or the file size for a truncated image; the flash reader's refusal passes the end of the misplaced image's segments. The bootloader search drops its misplaced flag, which only restated misplacedImage, and the next probe formats offsets with offsetText. Reader tests cover the 0x1000 and 0x2000 ROM offsets, a standalone bootloader, bytes that begin like a table, an app with a table at 0x7000 and a table inside a segment; without the boundary check, three of them fail. * fix(artifacts): give the ESP flash summary its own kind and each image's identity The summary view's ESP flash root kept kind esp-flash-image, so a consumer bound to kind could not tell an image's summary from its full facts, and the advertised schema held two objects with the same kind const. It is now esp-flash-image-summary. The per-image summary also dropped the descriptor, which is what tells two app slots apart, and named each image only by its partition index, which the summary view, having no entry rows, could not resolve. Each nested image now carries its entry path from the layout plan, in both views. The summary adds the descriptor kind with its identifying fields (an app's project_name, version, idf_ver, secure_version and app_elf_sha256; a bootloader's version, idf_ver and secure_version), the signature block count and each load range's classification. Its enums and fields derive from the schemas that own them. An MCP test reads a dump with an app in ota_0 and an erased ota_1 that holds older bytes: it checks both summaries, that the summary's inventory Evidence is the one the complete view returns with full facts, and the erased slot's written range. * test(artifacts): cover cancel and close during the ESP written-bytes scan The written-bytes pass reads every byte of each partition the dump holds, checking that the reader is open before each chunk, but only app decoding had a cancellation and close test. A data partition, which only that pass reads, now holds 9 MiB; once the scan has examined its first chunk, a cancel rejects preparation with the caller's reason and a close with unavailable, and the scan examines no further chunk. The erased-slot test now asserts the whole set of erased-slot limitations, so factory, ota_0 and nvs, which the bootloader reads or which are not app slots, are shown to have none. * docs(artifacts): re-time the ESP flash lane and state only observed causes The lane ran again after its assertions changed; both esptool runs passed, and the timed run's figures replace the earlier ones. The erased-slot paragraph no longer names a cause for the older bytes, which REA cannot observe, and the skill reference states that every table has a boot_selection in its own sentence, with the none basis for a table the bootloader rejects. * fix(artifacts): retire ESP flash members as the ESP image reader does #7498's maintainer commits made the ESP image reader keep a member owned until its consumer closes it, retire fully buffered bytes when cancellation arrives after production, and refuse to finish an inventory paused across close. The ESP flash reader was copied from the earlier reader. Main's shared stored-member lifecycle cases failed two of eight against it: a paused inventory completed after close, and buffered member bytes stayed readable after cancellation. Give the flash reader the same lifecycle and run the shared cases against it. * docs(artifacts): re-time the ESP flash lane after merging main The lane passed again with esptool v5.6.0 and 4.12.0 on the merge of upstream main. Record the v5.6.0 run's time and peak resident set. * fix(artifacts): read ESP image Evidence recorded before flash_dump The flash layout work made `flash_dump` a required field of the `esp-image` root metadata. Evidence recorded before it has no such field, so newer REA rejected records that were valid when they were made: `compare_artifacts` and `inspect_analysis_view` reported `evidence_integrity_mismatch` for them. The field is now optional when read. A record without it parses as it is, so the graph digest it commits to still matches; nothing fills the field in. The image reader still writes it for every image, and the inspection probe reads a missing field as no hint. A regression test recommits an image inventory without the field and passes it inline to `compare_artifacts` and `inspect_analysis_view`. Against a server built with the required field, `compare_artifacts` rejects it. * fix(artifacts): stop the ESP flash gap scan when the reader closes The scan for the first written byte in each undescribed gap checked only the caller's signal. `close()` marks the reader closed and waits for preparation, so it waited while the rest of a long erased gap was read. The gap scan now takes the reader's open check, as the written-bytes scan and the image decoder do, and checks it before each chunk. Tests cancel or close the reader after the scan's first chunk of a 9 MiB erased gap and confirm that no later chunk is examined. * fix(artifacts): name ESP partitions with Windows device labels by index The safe-label rule accepted labels such as `NUL`, `con` or `COM1`, so extraction wrote `partitions/NUL.bin`. Windows reserves those names before any extension, and ordinary Windows tools cannot use such a file. A label that is a Windows device name (`CON`, `PRN`, `AUX`, `NUL`, `COM0`-`COM9` and `LPT0`-`LPT9`, any case, alone or before a dot) now takes the existing index fallback. The partition metadata and the entry's source path keep the label. * fix(artifacts): read ESP flash partitions' written bytes in one pass Each partition got its own scan of the bytes the dump holds, so partitions declared over the same bytes read them again and again. Overlaps only add limitations, so a crafted table reached this normally: 94 overlapping partitions over a 32 MiB dump would examine about 3 GiB before the first entry. The reader now reads the bytes the partitions cover once. Partition boundaries cut them into segments; one pass counts each segment's written bytes and bounds, and each partition's extent is the sum of the segments inside it. Every partition keeps its own declaration, extent and limitations. The pass checks the reader's open state before each chunk, as the per-partition scan did. A test declares 60 partitions over one MiB, 40 over all of it and 20 over its first half, and checks each partition's extent and the overlap limitations. The reader reads 1,113,256 bytes of the 1,114,112-byte dump; one scan per partition read 52,493,480. * test(artifacts): fail the ESP lanes on failed commands and refusals `otatool` turned a nonzero exit into returned text, which its callers discarded, and `inspect()` returned `{ refused }`, which the flash lane never checked. A failed command then surfaced later as a slot assertion, an output-parser error or a TypeError, hiding its cause. Commands the lanes need to succeed now reject with the output they exited with: `otatool` and `inspect()` do so through a shared `failedCommand`. An expected refusal is opt-in: `refusal()` returns REA's output and fails the lane when REA opens the file. The ESP image lane's two ESP8266 cases use it. Checked by calling `otatool` on a file without a table, `inspect()` on a file REA refuses and `refusal()` on a file REA opens; each rejects with its cause. * fix(artifacts): require a partition entry in an ESP partition table The decoder counted the slot, not the partitions, so a lone MD5 entry over the empty prefix, followed by the terminator, decoded as a table with no partitions. Default and caller-selected detection then accepted that empty layout, although the guide requires one partition. A table now needs one partition entry before its terminator. An MD5 entry alone is refused as `entry 1 at 0x20 ends the table before any partition entry`. The cases cover the decoder and both automatic and caller-selected location. * fix(artifacts): decode an image shared by ESP app partitions once Each app partition got its own decode, so app partitions declared over the same bytes decoded and hashed the same image again and again, the same pattern the written-bytes scan had. With 60 app partitions over one 960 KiB image the reader read 64,029,736 bytes of a 1,114,112-byte dump. Regions with the same file range now share one decode; each keeps its own copy of the facts. Partitions with different ranges still decode separately, because truncation can change the facts: at most one decode per partition the table holds, each within its partition. A test declares 60 app partitions over one image, 40 holding all of it and 20 cutting it short, and expects three decodes: the bootloader, the whole image and the cut one. The 60-partition dump now reads 2,161,864 bytes, as a dump with one app partition does.
334 lines
20 KiB
Markdown
334 lines
20 KiB
Markdown
# ESP images
|
|
|
|
REA reads ESP32-family firmware images through `inspect-artifact` /
|
|
`inspect_artifact` and `extract-artifact` / `extract_artifact`. OTA downloads,
|
|
app partitions and second-stage bootloaders are all ESP images. Reading is
|
|
static: no esptool, device or flash access is needed, and no code is run or
|
|
disassembled.
|
|
|
|
```sh
|
|
rea inspect-artifact ./firmware.bin --json
|
|
rea inspect-artifact ./ota.bin --detail summary --evidence_output evidence.json --json
|
|
rea extract-artifact ./firmware.bin --json
|
|
```
|
|
|
|
For MCP, open the file with `open_binary`, then call `inspect_artifact`. The
|
|
summary's `root_format_metadata` holds the image facts. Use its
|
|
`parent_evidence_id` with `inspect_analysis_view` to select segment rows.
|
|
`extract_artifact` writes one file per segment and per signature block.
|
|
|
|
For agent sessions, advertise the `session,artifact,application` tool families
|
|
and consider setting both `REA_MCP_INPUT_SCHEMA_PROFILE` and
|
|
`REA_MCP_OUTPUT_SCHEMA_PROFILE` to `compact`. The output profile bounds each
|
|
advertised output schema to 4,096 bytes by relaxing nested client validation;
|
|
REA still validates complete results against the canonical contracts. Pair
|
|
this with retained summaries and selected inventory views to limit the context
|
|
needed for one question. See [MCP contracts](mcp-contracts.md) for the profiles
|
|
and their client compatibility tradeoffs.
|
|
|
|
The layout facts follow ESP-IDF v6.1 (`esp_app_format.h`, `esp_app_desc.h`,
|
|
`esp_bootloader_desc.h`, `esp_image_format.c`, the ROM `secure_boot.h`
|
|
headers and `docs/en/security/secure-boot-v2.rst`) and esptool v5.6.0
|
|
(`bin_image.py`, `cmds.py`, `loader.py`, espsecure).
|
|
|
|
## Recognition
|
|
|
|
The container format is `esp-image`. A file is an ESP image when its bytes
|
|
show all of these; the file name does not matter:
|
|
|
|
- magic `0xE9` at offset 0 and 1 to 16 segments. A count of 0 is valid but
|
|
loads nothing, and accepting it would admit x86 programs that begin
|
|
`E9 00`;
|
|
- a flash mode and flash speed code that ESP-IDF's enums define;
|
|
- a `hash_appended` byte of 0 or 1, as esptool requires;
|
|
- when the file holds the first segment header, a segment length that is a
|
|
multiple of 4.
|
|
|
|
Later segments, the checksum and the digest are integrity facts. A truncated
|
|
download is still an ESP image, with its integrity reported as unavailable.
|
|
|
|
| Input | Outcome |
|
|
| --------------------------------------------------- | ---------------------------------------------------------------- |
|
|
| ESP8266 image (v1 or v3): same magic, 8-byte header | Refused: "ESP8266 firmware images are not supported…" |
|
|
| Flash-encrypted image (ciphertext) | Not recognized: the bytes carry no magic. Unknown, not malformed |
|
|
| ESP8266 v2 image (magic `0xEA`) | Not recognized |
|
|
|
|
An ESP8266 image has its first segment header at offset 8, and that segment
|
|
loads into ESP8266 DRAM, IRAM (Arduino's eboot links at `0x4010F000`) or the
|
|
IROM flash window, where v3 and Arduino app images begin. In an ESP32-family
|
|
header the same bytes hold `wp_pin` and the drive settings, which esptool and
|
|
ESP-IDF write as `0xEE` and zeros. Inside another container, an ESP8266 image
|
|
is classified as a plain file.
|
|
|
|
Recognition cannot exclude every file that starts with an x86 near jump
|
|
(`0xE9`), such as a DOS `.com` program. An explicit `--target-format dos-com`
|
|
or `raw-binary` selection skips ESP recognition.
|
|
|
|
## Image facts
|
|
|
|
Root `format_metadata` has `kind: "esp-image"`:
|
|
|
|
| Field | Label | Meaning |
|
|
| ------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------- |
|
|
| `header` | observed | Every `esp_image_header_t` field, with ESP-IDF's names, for example `entry_addr`, `chip_id`, `min_chip_rev_full` |
|
|
| `chip` | derived | `target`, `isa` and the table's `source` (`ESP-IDF v6.1`) from `chip_id`; `null` for an ID the table lacks |
|
|
| `checksum` | derived | `offset`, `stored`, `computed` and `status`: `valid`, `invalid` or `unavailable` |
|
|
| `appended_sha256` | derived | The digest `hash_appended` adds: `offset`, `stored`, `computed` and `status`, including `not-appended` |
|
|
| `image_end` | derived | End of the checksum block and any appended digest; `null` when the file ends before it |
|
|
| `signature_sector_offset` | derived | The Secure Boot v2 signature sector, when it holds at least one valid block |
|
|
| `undescribed_trailing` | derived | Byte ranges after the image that nothing describes; empty when every byte is described |
|
|
| `descriptor` | observed | `esp_app_desc_t` or `esp_bootloader_desc_t` fields, with ESP-IDF's names, and the descriptor's file `offset` |
|
|
|
|
The descriptor's `kind`, derived from its magic, classifies the image as an
|
|
`app` or a `bootloader`. Without a descriptor the role is unknown.
|
|
|
|
The ISA comes from `chip_id`, never from the series letter: ESP32-S31 is
|
|
RISC-V. The chip table covers every `esp_chip_id_t` in ESP-IDF v6.1:
|
|
|
|
| `chip_id` | Target | ISA | `chip_id` | Target | ISA |
|
|
| --------- | --------- | ------ | --------- | ---------- | ----- |
|
|
| `0x0000` | `esp32` | xtensa | `0x0012` | `esp32p4` | riscv |
|
|
| `0x0002` | `esp32s2` | xtensa | `0x0014` | `esp32c61` | riscv |
|
|
| `0x0005` | `esp32c3` | riscv | `0x0017` | `esp32c5` | riscv |
|
|
| `0x0009` | `esp32s3` | xtensa | `0x0019` | `esp32h21` | riscv |
|
|
| `0x000C` | `esp32c2` | riscv | `0x001C` | `esp32h4` | riscv |
|
|
| `0x000D` | `esp32c6` | riscv | `0x0020` | `esp32s31` | riscv |
|
|
| `0x0010` | `esp32h2` | riscv | | | |
|
|
|
|
Other IDs, for example esptool v5.6.0's ESP32-E22 (`0x1F`), have `chip: null`
|
|
and unclassified segments.
|
|
|
|
**Integrity.** The checksum is the XOR of every segment data byte, seeded with
|
|
`0xEF`, in the last byte of the next 16-byte block. The appended SHA-256 covers
|
|
every byte through the checksum. Both are facts, not admission rules: a
|
|
mismatch is reported with a limitation and the segments stay readable.
|
|
|
|
**Descriptors.** Both descriptors begin segment 0: ESP-IDF's bootloader reads
|
|
the app descriptor there, and esptool places the bootloader descriptor there.
|
|
Strings stop at the first NUL and are omitted, with a limitation, when they
|
|
are not valid UTF-8. The bootloader descriptor's magic is a single byte
|
|
(`0x50`), so its reserved bytes, which ESP-IDF zero-fills, must also be zero.
|
|
A `--ram-only-header` image puts RAM segments first, so its app descriptor is
|
|
not in segment 0 and its role is unknown. `mmu_page_size` keeps ESP-IDF's
|
|
name and value: the MMU page size as a base-2 logarithm, as
|
|
`esp_app_desc_t` declares it, so `16` means 64 KiB. It is `0` in images built
|
|
before ESP-IDF v5.4. `spi_flash_mode` is the next byte, which ESP-IDF v6.1
|
|
names, kept as stored and not interpreted; releases that reserve it leave it
|
|
`0`. A file can end inside the app descriptor: every field it holds in full
|
|
is kept, a field it cuts off is `null`, and `observed_length` gives the
|
|
descriptor bytes the file holds. The segment's truncation is reported as usual.
|
|
|
|
## Segments
|
|
|
|
Each header-declared segment is one entry named `segment-<index>.bin`, for
|
|
example `segment-00.bin`, so two builds pair segments by position. Its
|
|
`source_location` is the segment data in the image file. `format_metadata`
|
|
(`esp-image-segment`) records `index`, `load_addr`, `data_len`,
|
|
`header_offset` and `classification`.
|
|
|
|
`classification` follows ESP-IDF's bootloader (`should_map` and
|
|
`should_load` in `esp_image_format.c`) on a cold boot:
|
|
|
|
| Value | Meaning |
|
|
| ------------ | ------------------------------------------------------------------------------------------------- |
|
|
| `mapped` | Inside the chip's IROM, DROM or, where the MMU is per memory type, PSRAM range (`soc.h`) |
|
|
| `loaded` | `should_load` selects it: not mapped, at or above `0x10000000`. RAM ranges are not checked |
|
|
| `not-loaded` | Below `0x10000000`: the padding segments esptool writes at address 0, including `--secure-pad-v2` |
|
|
| `unknown` | The chip is unknown, or the mapping depends on the bootloader's MMU page size |
|
|
|
|
`loaded` does not mean the bootloader accepts the segment. Before loading,
|
|
ESP-IDF's `verify_load_addresses` rejects the image when a loaded segment is
|
|
not entirely in the chip's DRAM, IRAM, RTC memory or SPM, or overlaps the
|
|
bootloader's own stack, data or loader code. For example, an ESP32-C6
|
|
segment at `0x43000000` is `loaded` here and rejected there. REA models no
|
|
RAM ranges.
|
|
|
|
Padding segments are inventoried and extractable, but are never load regions.
|
|
When waking from deep sleep, ESP-IDF also skips RTC-memory segments; that
|
|
runtime case is not modelled. ESP32-C6 and ESP32-H2 map flash from
|
|
`0x42000000` through 256 pages of the bootloader's configured MMU page size,
|
|
which no image records. The app descriptor's page size describes the app's
|
|
build, not the bootloader's. With page sizes from 8 KiB (which the hardware
|
|
supports and esptool builds for) to 64 KiB, segments from `0x42200000` to
|
|
`0x43000000` are `unknown`. Ranges follow ESP-IDF's `should_map`, not esptool's
|
|
wider placement ranges.
|
|
|
|
A segment cut short by the end of the file is the bytes the file holds, with
|
|
an entry limitation that gives the declared length.
|
|
|
|
Artifact comparison uses each segment's `load_addr` and `data_len` as its
|
|
declaration, so a segment that moves with unchanged bytes is `changed` in
|
|
`metadata`. Segments pair by index: inserting or removing one shifts the
|
|
paths of the segments after it. Header offsets and `classification` are not
|
|
compared; the image's own change covers the header and chip. The image's and
|
|
the signature blocks' `format_metadata` carry no declaration: their fields
|
|
come from their own bytes, which content comparison covers, and a block's
|
|
`image_digest_matches` follows the image's content.
|
|
|
|
## Secure Boot v2 signatures
|
|
|
|
A signature sector starts at the next 4 KiB boundary after the image and
|
|
holds up to three 1216-byte slots. A slot holds a block when it has the `0xE7`
|
|
magic and a matching CRC32 at offset 1196, the rule ESP-IDF and espsecure
|
|
apply. Each slot is examined independently, so an erased or damaged slot does
|
|
not hide a later block. Each block is an entry, `signature-block-<slot>.bin`,
|
|
with `esp-image-signature-block` metadata:
|
|
|
|
| Field | Meaning |
|
|
| ---------------------------------- | ------------------------------------------------------------------------- |
|
|
| `index`, `version`, `scheme` | Slot 0 to 2, version byte, and `rsa` (`0x02`) or `ecdsa` (`0x03`) |
|
|
| `sha_version`, `curve_id` | For ECDSA, the third byte (0 is SHA-256, 1 SHA-384) and the curve ID byte |
|
|
| `digest_algorithm`, `image_digest` | The digest the block records |
|
|
| `image_digest_matches` | Whether it equals the digest of every byte before the sector |
|
|
| `public_key_sha256` | SHA-256 of the block's public key, the value eFuse key digests hold |
|
|
| `signature_status` | Always `unverified` |
|
|
|
|
Signatures are observed, not verified: REA checks no public key, signature or
|
|
eFuse. `public_key_sha256` is the digest espsecure `signature-info-v2`
|
|
prints, so it can be compared with `espefuse summary`. An unknown version or
|
|
`sha_version` leaves the layout-dependent fields `null`. A slot with the magic
|
|
but no matching CRC32 is not a block: it is reported in a limitation, whether
|
|
or not another slot holds a block, and its bytes are undescribed. Secure Boot
|
|
v1 signatures are not decoded.
|
|
|
|
## Coverage and limitations
|
|
|
|
Bytes after the image are described when they are erased flash (`0xFF`) or a
|
|
signature sector's blocks; erased slots and slack in that sector count as
|
|
erased flash. Every other byte is in `undescribed_trailing`.
|
|
|
|
| Situation | Outcome |
|
|
| ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
|
|
| Segment data or a segment header beyond the end of the file | Truncation limitation; checksum and SHA-256 `unavailable`; coverage `unknown` |
|
|
| File ends before the checksum or the appended digest | That status is `unavailable`, with a limitation; coverage `unknown`, since a signature sector could follow |
|
|
| Checksum or SHA-256 mismatch | `invalid`, with a limitation; coverage is unchanged |
|
|
| Erased flash after the image that runs past the three slots | Described; no limitation |
|
|
| Erased flash that ends before the three slots are complete | Limitation; coverage `unknown`, since a signed image cut there would have lost its sector |
|
|
| A signature sector the file cuts short | Limitation; coverage `unknown` |
|
|
| Any other bytes after the image | Ranges in `undescribed_trailing`, a limitation, and coverage `unknown` |
|
|
| Segment length that is not a multiple of 4 | Limitation: ESP-IDF rejects such an image |
|
|
| Segment of 16 MiB or more, except on chips with 32-bit cache addresses | Limitation: ESP-IDF rejects such an image |
|
|
|
|
ESP32-S3, ESP32-P4, ESP32-C5, ESP32-C61, ESP32-H4 and ESP32-S31 map flash
|
|
through 32-bit cache addresses (`SOC_SPI_MEM_SUPPORT_CACHE_32BIT_ADDR_MAP`), so
|
|
ESP-IDF sets no 16 MiB segment limit for them. For an unknown chip the limit
|
|
is not applied.
|
|
|
|
Undescribed bytes include other flash contents such as an app partition's
|
|
stale data, a Secure Boot v1 signature, and the flash segments that esptool
|
|
`--ram-only-header` writes after the checksum without counting them. REA
|
|
reports their ranges and does not guess their structure. In the padding, in a
|
|
sector without a valid block, in the sector's slack and after the sector, the
|
|
first byte that is not erased starts a range to the end of that region. A
|
|
slot that is neither a block nor erased is reported whole. Adjacent ranges
|
|
are merged.
|
|
|
|
A whole-flash dump whose partition table REA finds is read as an
|
|
[ESP flash image](esp-flash-image.md). Without one, a dump of a chip whose
|
|
bootloader is at offset 0, such as ESP32-C3 or ESP32-S3, is recognized as that
|
|
bootloader image, and the partition table, apps and data follow as
|
|
undescribed bytes.
|
|
|
|
A dump read from a later flash address, such as an ESP32 dump read from
|
|
`0x1000` with `read-flash 0x1000 …` or `merge-bin --target-offset 0x1000`,
|
|
opens as its bootloader image. REA says so when the file shows it: the image
|
|
at file offset 0 is not an app, its chip's ROM loads the bootloader from a
|
|
later address (`0x1000` for ESP32 and S2, `0x2000` for C5, H4, P4 and S31),
|
|
and a partition table sits where that origin puts `0x8000` (file offset
|
|
`0x7000` for `0x1000`), after the image ends. Then `flash_dump` records
|
|
`flash_offset` and
|
|
`table_file_offset`, a limitation says to reopen the file with
|
|
`format: "esp-flash-image"` and that `flash_offset`, and `inspect_artifact`
|
|
lists the same `open_binary` call as a next probe. `flash_dump` is null for
|
|
every other image. Evidence that REA recorded before it reported the field
|
|
omits it; REA still reads and compares such Evidence, and the omission says
|
|
nothing about where the file was read from.
|
|
|
|
## Limits
|
|
|
|
An image has at most 16 segments and 3 signature blocks. Decoding reads each
|
|
byte once and retains only fixed-size fields. It reads through erased flash to
|
|
find the first byte that is not erased, and stops there. There is no
|
|
file-size limit.
|
|
|
|
## Analyzing a segment
|
|
|
|
Inventory does not disassemble code or build a memory map. `open_binary`
|
|
admits neither RISC-V nor Xtensa as a raw-binary architecture, so a segment
|
|
cannot yet be opened as a raw image. Each segment's `source_location` and
|
|
`load_addr` give the file offset and address to map it at by hand, for
|
|
example with the Rizin tool's `om` command.
|
|
|
|
## Verification
|
|
|
|
Synthetic fixtures with computed checksums, digests and CRCs cover
|
|
recognition, ESP8266 layouts, the ESP32, ESP32-C3, ESP32-C6 and ESP32-P4
|
|
memory maps, truncation at each structure, integrity mismatches, erased and
|
|
undescribed trailing bytes, signature slots including damaged and unknown
|
|
layouts, and the refusals. CLI and stdio MCP tests exercise the same artifact
|
|
provider and advertised schemas.
|
|
|
|
The optional real lane builds ELF files from source, converts them with
|
|
esptool and compares REA's facts with `esptool image-info`:
|
|
|
|
```sh
|
|
REA_RISCV_CLANG=/path/to/clang REA_RISCV_LLD=/path/to/ld.lld \
|
|
REA_ESPTOOL_PYTHON=/path/to/python-with-esptool \
|
|
npm run verify:esp-images
|
|
```
|
|
|
|
It needs a Clang with the RISC-V target, `ld.lld` and a Python that can run
|
|
`esptool` and `espsecure`. It checks each tool before building anything and
|
|
names the variable to set when one is missing, and it warns when esptool is
|
|
not v5.6.0, the version whose sources the layout facts cite. It builds an
|
|
ESP32-C3 app, the same app with `--dont-append-digest`, `--secure-pad-v2`,
|
|
`--ram-only-header` and `--pad-to-size`, a bootloader, and ESP8266 v1 and v3
|
|
images. It then checks:
|
|
|
|
- entry point, chip ID, each segment's length, address and header offset,
|
|
checksum, digest and descriptor fields against `image-info`;
|
|
- each segment's classification in the app, its variants and the
|
|
bootloader, whose linker scripts fix every section's region, including the
|
|
`not-loaded` padding that `--secure-pad-v2` adds;
|
|
- after signing with RSA-3072 and appending ECDSA P-256 and P-384 blocks,
|
|
each block's `public_key_sha256` against espsecure `signature-info-v2`,
|
|
and that its recorded digest matches;
|
|
- extraction of the app and the signed image: each segment file equals the
|
|
bytes after esptool's segment header offset, each signature block equals
|
|
its slot in the sector espsecure appended, and the source's SHA-256 is
|
|
unchanged and equals the reported `root_sha256`;
|
|
- the `--pad-to-size` erased tail is described; the `--ram-only-header`
|
|
flash segments are undescribed;
|
|
- a flipped checksum, a flipped digest byte, a truncated segment (where
|
|
`image-info` stops with "End of file reading segment"), and both ESP8266
|
|
refusals.
|
|
|
|
`REA_XTENSA_ESP32_GCC` adds an ESP32 (Xtensa) app built with Espressif's
|
|
`xtensa-esp32-elf-gcc`. Without it the report marks that image as skipped.
|
|
|
|
Each command runs as a process tree owned by the shared verifier command
|
|
owner, so a timeout also stops the linker or assembler a compiler driver
|
|
starts. The lane removes its workspace only after every tree has stopped and
|
|
keeps it when that cleanup cannot be confirmed.
|
|
|
|
The lane ran on macOS arm64 with Node 24.22.1, Homebrew Clang and LLD 21.1.8,
|
|
and `xtensa-esp32-elf-gcc` 14.2.0 (crosstool-NG esp-14.2.0_20251107), once
|
|
with esptool and espsecure v5.6.0 and once with 4.12.0. All checks passed for
|
|
all 13 images in both runs. With v5.6.0 the complete run, including the builds
|
|
and every esptool call, took 21.7 s elapsed, 16.9 s user CPU and 6.1 s system
|
|
CPU under `/usr/bin/time -l` with warm caches. The largest single process
|
|
peaked at a 253 MiB resident set; the combined peak of all processes was not
|
|
measured.
|
|
|
|
The lane does not establish:
|
|
|
|
- the other chips: only ESP32-C3 (RISC-V) and ESP32 (Xtensa) images come
|
|
from a real producer; the other rows of the chip table are checked against
|
|
the ESP-IDF v6.1 headers by reading them;
|
|
- images from a real ESP-IDF project build, an OTA download or a device's
|
|
flash, none of which it inspects;
|
|
- that a signature is valid: it compares digests, and nothing verifies a
|
|
signature.
|
|
|
|
It does not run in CI.
|