Goodix 27c6:5125 (Huawei MateBook): protocol fully compatible with 51x7, but preset_psk_read fails in APP mode after flashing 5117 firmware

[ersanuensal]

Summary

Hi — opening this as a detailed field report in case it helps future work on the 5125 (or other Huawei-Goodix variants). Issue #20 was closed as not planned back in 2022 with no technical discussion; this report fills in what I found.

TL;DR: 27c6:5125 silicon appears protocol-compatible with 51x7. Chip ID register, firmware-family name, OTP, NOP/enable_chip/reset, register reads, preset_psk_read, and MCU query all work identically in both APP (factory) and IAP modes. However, after erasing the factory app firmware and flashing GF_ST411SEC_APP_12109.bin (the 51x7 target), preset_psk_read(0xbb020003) returns success=False in APP mode — even though the same command succeeded both before the flash (on factory firmware GF_ST411SEC_APP_12508) and in IAP mode after the PSK was written. The subsequent TLS handshake (request_tls_connection) then times out.

So either:

• The 5125 stores the provisioned PSK somewhere the 5117 APP firmware doesn't look, or
• The 5117 APP firmware's PSK-read command has a hardware dependency that differs on the 5125 silicon.

Hardware

• Device: Huawei MateBook (user-visible Goodix Fingerprint Device)
• USB ID (factory): 27c6:5125
• Factory firmware: GF_ST411SEC_APP_12508
• Chip ID @ sensor reg 0x0000: a2 04 25 00 (identical to 51x7)
• OTP: 64 bytes, starts with ASCII DQ2757. then binary

What was tried

All steps were driven by this repo's driver_51x7.py with widened firmware regexes and interactive confirmation prompts.

1. Read-only probes (factory firmware, PID 5125)

All of the following succeeded with sensible values:

Command	Result
nop	ack
enable_chip(True) + nop	ack
reset(True, False, 20)	success=True, number=2048
firmware_version()	GF_ST411SEC_APP_12508
read_sensor_register(0x0000, 4)	a2042500 (matches 51x7)
read_sensor_register(0x0082, 2)	8028
read_sensor_register(0x0220, 2)	880b
read_otp()	64 bytes, same across reboots
query_mcu_state(0x55, reply=True)	00003000000000002000000011200000
preset_psk_read(0xbb020003)	success=True, flags=0xbb020003, psk=c03ccf94…5013c7d9

Factory PSK hash differs from the 51x7 PMK_HASH (ba1a…2d43), as expected — the device was provisioned with a different PSK at the factory.

2. Erase → IAP → write PSK → flash

Using a forked driver_51x7 main loop with VALID_FIRMWARE = GF_ST411SEC_APP_12[0-9]{3} and IAP_FIRMWARE = MILAN_ST411SEC_IAP_12[0-9]{3} to accept our factory firmware. Each destructive step gated by explicit user confirmation.

• mcu_erase_app(0, False) → sensor re-enumerated; now reports an IAP name in the MILAN_ST411SEC_IAP_12xxx range (PID stayed at 5125 during IAP).
• preset_psk_write(0xbb010003, PSK_WHITE_BOX) in IAP → returned True.
• preset_psk_read(0xbb020003) in IAP → success=True, psk == PMK_HASH (51x7's expected hash). So the PSK write landed correctly at the IAP's PSK location.
• update_firmware(firmware/51x7/GF_ST411SEC_APP_12109.bin) (75032 bytes, CRC-32-MPEG 0x5a7e0d1d) → write_firmware loop + check_firmware passed. reset(False, True, 20) issued.
• Sensor re-enumerated at PID 5117 with firmware GF_ST411SEC_APP_12109. ✅

3. Post-flash verification (APP mode, PID 5117)

Command	Result
nop, enable_chip, nop	ack
firmware_version()	GF_ST411SEC_APP_12109 ✅
reset(True, False, 20)	success=True, number=2048 ✅
read_sensor_register(0x0000, 4)	a2042500 ✅
read_otp()	identical 64 bytes as factory ✅
upload_config_mcu(DEVICE_CONFIG)	True ✅
set_powerdown_scan_frequency(100)	True ✅
preset_psk_read(0xbb020003)	❌ success=False (returned error response, message[0] != 0x00)
request_tls_connection()	USB read timeout (device never replies)

So the flash succeeded at every layer up to and including the MCU config upload. Only PSK read and the subsequent TLS handshake fail.

I tried the same sequence a second time with the 51x0 variant (GF_ST411SEC_APP_12117.bin) — identical outcome: flash succeeds, preset_psk_read in APP mode fails the same way.

Hypothesis

The 5125 silicon persists the written PSK to a storage region that's reachable by the factory firmware's PSK subsystem (and by the IAP bootloader), but not by the 5117 APP firmware's PSK subsystem. From the chip ID match plus OTP stability, the actual sensor silicon is the same family; the difference seems to be in the secure storage layout or how the APP firmware addresses it.

Either:

1. There's a provisioning command the factory firmware knows that commits PSK to APP-mode storage which the 5117 firmware never learns about, or
2. The PSK storage offset/key material derivation differs in a way baked into the 5117 firmware image.

Current device state

After the flash, the sensor is:

• Alive, responsive to base protocol commands
• Reporting as 27c6:5117 with firmware GF_ST411SEC_APP_12109
• Unable to complete TLS handshake under either goodix-fp-dump's driver_51x7 or gulp/libfprint-1's goodix-5117-support branch (both require preset_psk_read to succeed in APP mode)
• No longer functional under Windows either — the factory PSK has been overwritten. I do not have the original factory firmware dump.

Ask

• Has anyone else here poked at 27c6:5125 or similar Huawei-Goodix variants (5130 from Add trivial preprocessor #33 looks related)?
• Is there a way to extract a raw 5125 factory firmware image from a second device, or is this something that would have to come from Goodix themselves?
• Are there known commands for committing PSK to APP-mode storage that aren't exercised by the 51x7 flow?

Happy to run more probes on this device if someone has a hypothesis to test. I've scripted the probes/flash in a way that's reproducible for future 5125 owners who want to repeat the experiment (though my current loss of Windows functionality means I'd recommend others capture a firmware dump before erasing).

Thanks for all the reverse-engineering work that got us this far.

[MrHiXl]

Hi! I have the same device (27c6:5125, Honor MagicBook 15 BMH-WDX9) and just captured USB traffic between the Windows Goodix driver and the sensor during fingerprint enrollment using USBPcap.
The capture contains the full initialization sequence including what appears to be fingerprint image data (7753-byte packets). I have not flashed anything — the device is still on factory firmware.
The pcap file is attached in my related issue: #63
Hope it helps with the PSK investigation. Let me know if you need additional captures (e.g. separate enrollment vs verification sessions).

[MrHiXl]

Additional device info (read-only, no flashing)

Wrote a simple read-only script to query device info without touching firmware or PSK.

Firmware: GF_ST411SEC_APP_12508
PSK read success: True
PSK flags: 0xbb020003
PSK hash: 8c16b44620196f40d255951bd5585683e029a7d2a7a7704f2d350dffb4681105

Note: firmware version confirms this is a distinct chip from 5117 (GF_ST411SEC_APP_125xx vs GF_ST411SEC_APP_121xx). PSK hash is also different from the 5117 default (ba1a86...), so flashing run_5117.py directly would likely erase factory PSK and brick the device — as happened in #61.