v0.4.40

v0.4.40 — the tools check prints exactly what you quoted

The contract (as requested, verbatim)

When a matching tool exists in the library, the whole output is:

Image: Lenovo P14s U2201 good.bin
ME:    15.0.55.2751 - needs FIT 15.0

Matching tool: FIT 15.0.35.1951 (Windows)

Nothing else — no library inventory, no "other tools", no unidentified-entries lines, no "(+N more)".

When there is no match

Image: Lenovo P14s U2201 good.bin
ME:    15.0.55.2751 - needs FIT 15.0

Matching tool: none

Add the CSME 15.0 System Tools folder in Settings.

So the only "extra" line is the action to take; library contents are never printed.

Notes

• The version-check probe that upgrades unidentified entries by reading the version out of the file still runs (it feeds the library identity cache); it simply never adds noise to this report.
• Windows installer signed (Ed25519 .sig); Linux tarball + macOS .dmg from CI; all-platform test matrix green (702 tests).

v0.4.39

v0.4.39 — "Tools for this image" now answers one question (matching + summary), noise removed

What was wrong

The check's contract is one question — "which Intel tool does this image need, and do I own it?" — but the report enumerated every library entry, so a large FIT collection produced a wall of rows: dozens of non-fitting builds plus unidentified copies, burying the one line that matters.

What it prints now

Image: Lenovo P14s U2201 good.bin
ME:    15.0.55.2751 - needs FIT 15.0

Matching tool: FIT 15.0.35.1951 (Windows)
In your library (not fitting): MFIT 19.0.0.1854, FIT 11.8.86.3877, FIT 12.0.85.1919, FIT 13.0.37.1556, FIT 13.30.0.1065, FIT 13.50.15.1475 (+5 more)
Unidentified library entries (ignored): 10 — FIT ×6, unidentified ×4 (no readable version; exclude them or place them elsewhere)

• identical entries are de-duplicated (a tool listed twice no longer appears twice);
• compatible rows come first; the non-fitting rest is capped at six and collapsed with "(+N more)";
• unidentified entries are summarized but never hidden — one line naming the families and count (the older "FIT (not identified)" row-by-row carpet is gone; the promise nothing disappears is kept by the count line).

Notes

• Intel-tool licensing unchanged: the app probes your own copies to say which fits the image; nothing is bundled or downloaded (FIT/MFIT are licence-protected).
• The probing fallback that upgrades an unidentified entry later (reads the version from the file, remembers the identity) is untouched.
• 702 tests green on all platforms, ruff clean; Windows installer + Linux tarball + macOS .dmg published.

v0.4.37

v0.4.37 — ME Analyzer no longer crashes on corrupted EFS; analyzer failures reported truthfully

What was actually broken (verified on your file end-to-end)

You were right — and the root cause wasn't what either of us were guessing. Running the bundled ME Analyzer directly on Lenovo P14s U2201 good.bin (CSME 15.0.55.2751, TGP-LP) crashed inside efs_anl with IndexError: list index out of range at dat_pages_final = [dat_page_all[v] for v in sys_idx_values]:

• The EFS System Page Indexes CRC-32 was invalid (0xFFFFFFFF, expected 0x6BA3BA26), i.e. the index area contains garbage (173, 73, 227, 255, 255, ...).
• MEA then sorted the data pages over garbage indexes and crashed — hiding every remaining field (Family/Version/SKU/File System State...) behind a traceback. Upstream MEA (platomav v1.312.0 r378) has the same exact code path.

What changed

1. Vendored MEA is now resilient to corrupted EFS indexes: when the Indexes CRC-32 is flagged invalid it logs "EFS System Page Indexes CRC-32 detected a corrupted index; continuing with sequential Data Page order!" and continues with sequential order so the full report survives instead of crashing.
2. Your file now analyzes fully and reports, end-to-end through the app as well:
   • Family/Version: CSE ME 15.0.55.2751 (Consumer LP, TGP-LP B), Production, Extracted, Flash Image Tool 15.0.23.1706, MEA DB name 15.0.55.2751_CON_LP_B_PRD_EXTR
   • Type: Extracted
   • File System State: Initialized (Dirty EXTR) — a donor from a machine that ran, carrying PCH serial/UUID/AMT/event-log data: on another system this risks second-boot problems and sleep failures; the supported revert is the FIT round-trip (not raw byte edits, not the HAP bit).
3. A crashed/unreadable analyzer is now reported truthfully: the ME Clean report previously fell back to "Unconfigured (RGN)" wording when the analyzer had failed to read the image — that was my earlier mistake and it is fixed: a failed analyzer run now states File System State: could not be read — <reason> and never invents RGN/EXTR/Initialized labeling.

Signed release

• BIOSRecoverySuite-Setup-0.4.37.exe + .sig (Ed25519, verified against the app's embedded public key), Linux tarball and macOS .dmg from CI.
• Also vendored-MEA license-compatible (BSD-2-Clause-Patent); fix documented in docs/RESEARCH.md with the exact code semantics for future maintainers.

v0.4.36

v0.4.36 — File System State (RGN / EXTR / Dirty EXTR) understood and integrated into ME Clean

What the states mean (researched from ME Analyzer source, the Win-Raid cleaning guide, the RGN-vs-EXTR thread and an independent CSME 16+ write-up — cross-checked before integrating)

• Unconfigured (RGN) — Intel stock factory image, never configured by any OEM. Never flash RGN as-is: it must first be configured for the target system via Intel Flash Image Tool (FIT). A donor dump reading RGN is not a usable donor.
• Configured (EXTR) — Type A donor: OEM settings applied via FIT, NOT bound to any machine's hardware identifiers. The donor state you want for a clean deployment on another system.
• Initialized (Dirty EXTR) — Type B donor: dumped from a machine that ran; carries PCH serial / UUID / AMT config / event logs. On another system this risks second-boot problems and sleep failures; the supported revert is the FIT round-trip, not raw byte edits and not the HAP bit.
• Field absent (CSME ≤ 10) — ME Analyzer only supplies it for CSME 11+; a dumped-from-running-machine region is then treated as Initialized (Dirty EXTR) by default, and the report says so instead of guessing.

Integration into the app

• ME Cleaner now reads the state via the bundled ME Analyzer and prints File System State: <value> in every clean report, with state-specific, guide-accurate advice (and the CSME ≤ 10 no-field case stated explicitly).
• ANSI colour codes coming out of the analyzer are stripped so the state word is clean.
• The label mapping is a single source of truth shared by the ME Info page and the ME Cleaner (adds the parenthetical forms users quote).
• docs/RESEARCH.md carries the four-source reference with quotes.

Ship notes

• Signed Windows installer BIOSRecoverySuite-Setup-0.4.36.exe (Ed25519 .sig); Linux tarball and macOS .dmg continue to build from CI on all three platforms. Suite: 692 tests green, ruff clean.

v0.4.35

v0.4.35 — Linux & macOS support, ME-clean reporting made verifiable, UEFI LZMA decode hardened

Platform support

• CI now builds and tests on Linux (tarball) and macOS (Apple Silicon .dmg) in addition to Windows:
  • BIOSRecoverySuite-linux-x64-<v>.tar.gz — unpack and run ./BIOSRecoverySuite
  • BIOSRecoverySuite-macos-arm64-<v>.dmg
  • Windows keeps the signed Setup.exe (Ed25519 .sig) and portable.zip.
• Test suite now runs on Linux (3.10/3.11/3.12) and macOS (3.12); the CI release flow is race-safe (release is created once, all platforms upload in parallel; tag/version enforced before any build).

ME Cleaner: what a CSME 11+ "CSE LT" clean really is (and what the report states)

For engines that ship the $CPD manifest layout (CSME 11+, incl. the CSME 15 Tiger Lake code in Lenovo P14s/T14 Gen 2–4), partition-level ME removal does not exist: the FPT lists no FTPR at all, and me_cleaner itself exits with "FTPR header not found" on such images. The app's MeCleaner therefore performs the exact same operation as me_cleaner's own gen-3 HAP path — and now says so precisely:

• Cleaned Size keeps the region size (nothing is truncated; LT engines cannot be partition-cleaned);
• the report names the one and only changed byte and bit: bit 16 of PCHSTRP0 (the flash-strap dword at FPSBA), byte-identical in location and effect to me_cleaner's HAP write;
• if you run a clean and the report shows anything less, that is an app bug; if it shows exactly that one-bit change, that is the full, proper ME clean for this engine generation.
  (Reference analysis and me_cleaner source comparison are in docs/RESEARCH.md.)

UEFI LZMA sections: hardened decode path

• LZMA-ALONE payloads are now decoded (and re-emitted) the way the firmware's own LzmaDecode does: props/lc/lp/pb + dictionary size read from the header, EOS marker accepted, declared output size from ALONE header bytes 5..12 — matching EDK2's LzmaDecompress.c.
• Host-side strict lzma.decompress() is no longer used on LZMA sections in the app (its tolerance for "declared size + EOS tail" differs per liblzma build); the shipped payload format remains exactly the one the platform firmware accepts when flashing.
• Oversized/under-decodable streams stay bounded per the previous audit (a stream that cannot finish inside the limit is treated as opaque, not crashed through).

Notes

• 685 tests, ruff clean; CI green on all three platforms.
• The Windows installer is signed (Ed25519, .sig).

v0.4.31

v0.4.31

v0.4.30

v0.4.30: ME info shows the full engine detail

What was wrong

"ME info" reported six fields: version, type, generation, offset, size and the
partition list. Everything else an engine dump carries — release, SKU, SVN/VCN,
OEM configuration, FWUpdate support, file system state, FIT version — was not
shown, even though the suite already ships the analyzer that decodes it.

What changed

The ME Region page now shows the detail set, in the analyzer's own order:

Family: CSE ME
Version: 16.1.25.1991
Release: Production
Type: Extracted
SKU: Consumer H
Chipset: Unknown
TCB SVN: 1
ARB SVN: 4
VCN: 14
Production Ready: Yes
OEM Configuration: Yes
FWUpdate Support: No
Date: 2022-08-29
File System State: Initialized
Size: 0x3DA000
Flash Image Tool: 16.1.25.1991
MEA Database Name: 16.1.25.1991_CON_H_X_PRD_EXTR
Generation: GEN3
Offset: 0x3000

Partitions:
  PSVN: offset 0x3400, size 0x200
  ...

• The values are the analyzer's answers, not a second decoder. The bundled
  analyzer produces a JSON report; the page prints one labelled line per field
  from it, so the numbers match a full analyzer run exactly.
• Nothing is guessed. A field the analyzer did not decode is left out, and an
  undecidable one stays Unknown (see the note on Chipset below).
• If the analyzer cannot read the image, the page keeps the old six lines and
  adds one sentence saying so; a packaging problem (a missing analyzer
  dependency) and an unreadable image are reported differently.
• The "ME Analyzer" menu action now shows the same labelled fields instead of
  the tail of its ASCII tables.
• Partition names no longer carry padding spaces in the display.

Note on Chipset for the dump you sent

Chipset: Unknown is correct for this image, not a gap in the app: its chipset
initialization table (mphytbl) is present but empty, so the chipset name cannot
be derived from the file itself. The analyzer prints Unknown for the same
reason. Its MEA Database Name ends in _X_ for the same reason (unknown
stepping), while Chipset Support: ADP/RPP comes from the image's own manifests.

Verification

• 675 tests pass; ruff clean. CI: Linux tests on 3.10, 3.11 and 3.12, plus the
  Windows build, all pass.
• New tests cover: the exact field set and order, independent firmware (PMC,
  PCHC, PHY) never mistaken for the engine, unknown values omitted instead of
  guessed, N/A kept as a real answer, several engines labelled separately, the
  unreadable-image path, the missing-dependency path, the timeout path, a broken
  analyzer never breaking the page, and the page rendering both the detailed and
  the fallback output.
• The frozen-app path was exercised end to end: the packaged dispatch
  (--mea-child) wrote the report and the fields matched the unpackaged run.
• FIT/MFIT tool identification is unchanged and still passes its tests.

Downloads (SHA-256 from the GitHub release API)

• BIOSRecoverySuite-portable-0.4.30.zip: sha256:8fb462caa317b8e5bbf26484118c81d256e91cf2ffd096652acc1492e0eefaa9
• BIOSRecoverySuite-Setup-0.4.30.exe: sha256:054d77185d35621abdc9cbc1d121e94372ce77ddc2becc5a2893719dfa3617e5
• BIOSRecoverySuite-Setup-0.4.30.exe.sig: sha256:f39758ae1a2b65706ca87b531c44c9ffb2e412006bd8240ecd3ddf02b49d3042

The installer is signed with the suite's Ed25519 release key (unchanged since
v0.4.24); the updater verifies the .sig and falls back to the SHA-256 above
over HTTPS when the key does not match.

v0.4.29

v0.4.29: every FIT/MFIT tool is found, and the check result is short

Why the tool was still missed

Detection relied on running the tool with -h and reading its output. That fails for
two real cases:

• MFIT (CSME 15/16) is a GUI build. With -h it prints nothing to the console and
  waits, so the probe timed out and the import refused the file. The tool never
  reached the library, so "Check Tools" could never see it.
• The check hid what it did not know. It listed only tools that had already been
  identified, so an unidentified file that was scanned was silently left out.

Both are fixed.

What changed

• Identity is read from the file itself. Both FIT and MFIT carry their banner and
  their FileVersion inside the executable (as UTF-16 on Windows). The app now reads
  those bytes, so nothing is executed, a GUI tool cannot hang the check, and a Windows
  .exe is identified the same way anywhere. -h is used only when the file does not
  state a version.
• Nothing is dropped. Tools are imported whether or not they were already
  identified, and a program whose version cannot be read is kept and listed as
  "not identified" instead of being refused.
• More file names are recognised, including Flash Image Tool.exe, FIT*.exe,
  MFIT*.exe and FITC*.exe.
• "Check Tools For This Image" is short. It now prints the image, the ME version
  with the tool it needs, the matching tool, and any other tools found. No paths, no
  confidence notes, no explanation text.

Example result for a CSME 16 image:

Image: your_dump.bin
ME:    16.1.25.1991 - needs MFIT 16.1

Matching tool: MFIT 16.1.25.2053 (Windows)
Other tools:   FIT 11.8.86.3877, FIT 15.40.16.2534

• Removed the "Mark as FIT/MFIT manually" button and the duplicated probe code.

Verification

• 660 tests pass; ruff clean. CI: Linux tests on 3.10/3.11/3.12 and the Windows
  build all pass.
• New tests cover: a Windows GUI tool identified from its bytes while being
  non-executable (so it provably never ran), the exact fit.exe -h banner, a BIOS
  image never identified as a tool, a tool that is listed but not hidden when its
  version is unknown, and the short check output.

Note on the dump you sent

The 32 MB image analysed earlier reports ME 16.1.25.1991 and no structural problems;
its own ME region uses the CSE LT layout, so partition cleaning does not apply to it
and only the HAP soft-disable is available.

Downloads (SHA-256 from the GitHub release API)

• BIOSRecoverySuite-portable-0.4.29.zip: sha256:3c19686979378b6b93a6a3e1e7f89a23113f3ac660a2a0b4263dec1709567c97
• BIOSRecoverySuite-Setup-0.4.29.exe: sha256:5d4e3c68cac779f8b000e8b042baed3c28ebae88a50b1c16ead06571c192ee73
• BIOSRecoverySuite-Setup-0.4.29.exe.sig: sha256:affdf2eb78f8f6a84dcb0c53a9aa016dd8002173e03f9eeef6043de0c46b093a

v0.4.28

v0.4.28: fix FIT detection for 'press any key' tools

Fix

• FIT tool detection fixed. The tool prints "Press any key to continue" at the end, which caused the subprocess to hang. Now sends a newline to dismiss the prompt and captures partial output on timeout.

Verification

• Full test suite: 653 passed. Lint clean.
• CI: all passing (Linux + Windows build).

Downloads (SHA-256 from the GitHub release API)

• BIOSRecoverySuite-portable-0.4.28.zip: sha256:a441b8e461fa8d04d21d44c3542e006070fbdc7b7324c92b7c944f653536c45a
• BIOSRecoverySuite-Setup-0.4.28.exe: sha256:d72baab137ef1f01c0bda7f35a8fd06628e998eb2c2c26a5ed3f501054cf6f51
• BIOSRecoverySuite-Setup-0.4.28.exe.sig: sha256:63872685567c49aad22267f4325b8930eacabc7bed8267d636c52196ae630a4f

v0.4.26

v0.4.26: improve FIT tool detection

Fixes

• FIT tool detection improved. The probe now adds the tool's directory to PATH, tries both -h and --help, runs from the tool's directory, and includes the tool's actual output in the error message when detection fails.
• Probe timeout increased from 20 to 30 seconds.

Verification

• Full test suite: 653 passed. Lint clean.
• CI: all passing (Linux + Windows build).

Downloads (SHA-256 from the GitHub release API)

• BIOSRecoverySuite-portable-0.4.26.zip: sha256:6914658514b2abe50941cb9f13738f25a29ff9d6282ec59225ad4d0ef9aa3859
• BIOSRecoverySuite-Setup-0.4.26.exe: sha256:3a93a2e0115b9b5cab1651fcf080fb180050f598d162943981e946fc188bc7db
• BIOSRecoverySuite-Setup-0.4.26.exe.sig: sha256:4e1fc17e990a430cdddbac95e5ba5f9cd56f1176f65d5f84dc3af124fb411ad9