[REQUEST] AMI Aptio BIOS password Advantech UNO-1372G-J (UNOB-2117MB)

[Vyse_blue]

Hello everyone,

I'm stuck on a BIOS password issue on an industrial embedded PC and would really appreciate some expert eyes on this. I've done what I can with hex editing but I think the real password check is elsewhere in the firmware, beyond my current skill level.

Hardware:

Device: Advantech UNO-1372G-J (industrial fanless PC / OPC)
Motherboard: UNOB-2117MB REV.A1, made in Taiwan, PN 19A3211703-01
CPU: Intel (embedded SoC, soldered)
Main BIOS flash chip: Winbond W25Q64JW (8MB, SOIC-8, 1.8V)

Problem:
The BIOS requires a password at boot/setup entry. Clearing CMOS (battery pull + CN36 clear-CMOS jumper + shorting battery socket V+/V-) has no effect on the password — as expected, since on these AMI Aptio boards it's stored in SPI flash rather than battery-backed CMOS.

What I've tried so far:


Dumped the main BIOS chip (W25Q64JW) via CH341A + 1.8V adapter + SOIC-8 clip. Read 3 times, MD5-verified identical each time.
Located what appears to be the AMI TSE (Total Setup Edition) password-related NVAR variables in the dump:

AMITSESetup NVAR entry (offset ~0x300281) with all-zero data (looks like a "default/empty" instance)
A second AMITSESetup NVAR entry (offset ~0x302931, size 0x68) containing non-zero data — what I assumed to be password hash material (80 bytes, structured as two overlapping ~40-byte sequences)
An OEMDEFAULTPWDSetup NVAR entry (offset ~0x302999) with a single data byte (0x04, later noticed value 0x70 depending on offset interpretation — I may have made an error here)

Tried zeroing the 64 then 80 bytes of the suspected hash data in the second AMITSESetup NVAR — reflashed, no change, password still requested.
Tried invalidating the NVAR entries entirely by changing the state byte from FF FF FF to 3C FF FF on both AMITSESetup and OEMDEFAULTPWDSetup entries — reflashed, verified the re-dump matched the written image exactly (MD5 identical), so the write itself succeeded with no write-protection issue — but the password prompt is still there.

So the chip write/erase/verify cycle works fine (no WP/lock issue), but neither approach neutralizes the actual password check. My guess is either:

The AMITSESetup varstore I found is just the general Setup form storage (all BIOS settings), not specifically the password, and the real password hash is stored/checked elsewhere (different GUID, different NVAR name, or computed by DXE/PEI driver code rather than a plain stored hash)
There's some checksum/CRC over the NVRAM volume that needs to be recalculated after modification, and an invalid checksum causes the driver to fall back to a "locked" state rather than "no password"

What I'm hoping for:


Guidance on identifying the correct NVAR GUID/variable that AMI Aptio uses for password verification, as opposed to general Setup storage
Whether AMIBCP (AMI BIOS Configuration Program) can open/patch this dump properly, since UEFITool NE reports "Stores not found" on this image
Any known quirks specific to Advantech's AMI Aptio implementation


I have the original untouched dump and full change logs for every attempt. Happy to upload the original .bin if that helps, and I can provide any additional dumps/photos of the board on request.

Thanks in advance for any pointers!