Lenovo IdeaPad Gaming 3 15ARH05 BIOS Research

From a failed keyboard shortcut to a reverse-engineered, runtime EFI menu reveal

Download USB image · Create the USB · Advanced option inventory · Photo gallery · Research walkthrough

I did not begin with an unlocked BIOS or even with proof that this laptop had an Advanced menu. I only wanted to answer one question: does the Lenovo IdeaPad Gaming 3 15ARH05 contain the same hidden firmware controls reported on other Lenovo models?

Several reports suggested that combinations such as Fn+R+N could reveal extra BIOS pages. Those sequences worked on some later Lenovo generations, but repeated attempts did nothing on this specific 15ARH05. The ordinary setup interface gave no indication that an Advanced form existed at all.

Rather than assume that the menu was absent, I wanted evidence from the firmware itself. That turned a failed keyboard experiment into a reverse-engineering project: recover the update image, locate the Setup Utility, decode its IFR, prove whether a hidden form set existed, determine what controlled its visibility, and finally test that finding on the physical machine.

The effective trigger was therefore not a secret keyboard combination. It was the runtime visibility state used by Lenovo's InsydeH2O form browser. The USB EFI approach patches that state from hidden (0) to shown (1) for the relevant form-set GUIDs, then opens the Setup Utility in the same boot session.

The physical-test gallery is the final proof: the hidden pages are present and can be exposed on this machine. This confirms menu visibility only; it does not establish that changing any exposed value is safe.

The fastest route is the latest ready-to-write USB image. Every release is built automatically from the pinned EDK II and SREP commits, contains one artifact per tracked BIOS profile, and includes SHA-256 checksums. It does not contain Lenovo firmware.

The complete, beginner-friendly procedure is in SREP USB Creation and Boot Guide. It covers:

1. building the tested SREP revision or verifying an existing binary;
2. creating a GPT/FAT32 USB drive on Windows or Linux;
3. installing BOOTX64.EFI and the tracked configuration;
4. disabling Secure Boot and launching the USB in UEFI mode;
5. confirming the hidden menus, exiting without saving, and preserving SREP.log.

Want to reproduce the release locally? The same guide includes a latest-stable EDK II build using edk2-stable202605. The repository applies the required SREP compatibility patch automatically and produces a ready-to-write .img.xz. This EDK II/SREP source combination has completed a real-hardware boot test on the documented 15ARH05; every rebuilt artifact should still be tried in observation-only mode before changing or saving firmware settings.

The machine used for the investigation reports:

The version difference is important. Structures found in the FCCN21WW update must not be assumed to have identical addresses, byte patterns, module names, or variable semantics in the installed FCCN19WW firmware.

Only original documentation, scripts, and experimental text configurations are intended to be tracked. Lenovo/Insyde executables, firmware images, extracted modules, variable dumps, logs, third-party source trees, and build products are local research artifacts excluded by .gitignore.

.
├── README.md
├── profiles/
│   └── lenovo-15arh05-fccn/
│       ├── profile.json
│       ├── SREP_Config.cfg
│       └── README.txt
├── strategies/
│   └── insyde-h2o-formset-visibility.json
├── .github/workflows/
│   └── build-usb-image.yml
├── docs/
│   ├── ADVANCED_OPTIONS.md
│   ├── BIOS_PROFILES.md
│   ├── SCREENSHOTS.md
│   └── USB_GUIDE.md
├── patches/
│   └── srep-edk2-stable202605.patch
├── screenshots/
│   └── 47 optimized physical-test photographs
└── scripts/
    ├── build_srep_latest.sh
    ├── extract_reset_image.py
    ├── profile_tool.py
    └── package_srep_usb.sh

The paths used later in this document for firmware and extraction output describe the local analysis workspace. Those files are deliberately not part of the Git repository and must be produced from a legitimately obtained Lenovo update.

Once the keyboard shortcuts had failed, the official update package became the only reliable way to answer whether the menu existed on this firmware family. The first objective was therefore to recover a form that could be inspected without modifying or flashing the laptop.

The starting point was the official Lenovo BIOS Update for Windows 10 (64-bit) — IdeaPad Gaming 3 15ARH05 download page. The Windows BIOS updater obtained from that page was saved locally as artifacts/vendor/update-package/fccn21ww.exe:

A normal 7-Zip extraction produced artifacts/vendor/outer-installer/[0], but that 7,286,304-byte file had near-maximum entropy and was not directly usable. The useful payload was instead captured by running the official installer under Wine and monitoring its temporary files:

inotifywait -m -r \
  -e create,close_write,moved_to,delete \
  "$WINEPREFIX/drive_c/users" /tmp

wine artifacts/vendor/update-package/fccn21ww.exe

During execution, the installer staged a decrypted inner executable. It was preserved as artifacts/vendor/update-package/FCCN21WW.exe:

Extracting that file with 7-Zip recovered the Insyde flashing package in artifacts/vendor/inner-package/, including H2OFFT-W.exe, its drivers, platform.ini, BiosImageProc.dll, and BIOS.fd.

artifacts/vendor/inner-package/BIOS.fd is not a raw flash dump. It is a 64-bit EFI executable containing the flash driver, firmware payload, configuration, and certificate data.

Its large .reloc section contains markers such as $_IFLASH_DRV_IMG, $_IFLASH_BIOSIMG, and $_IFLASH_INI_IMG. The section and embedded driver were recovered with:

objcopy --dump-section .reloc=artifacts/extracted/iflash/reloc.raw \
  artifacts/vendor/inner-package/BIOS.fd

dd if=artifacts/extracted/iflash/reloc.raw \
  of=artifacts/extracted/iflash/IFLASH_DRV_IMG.efi \
  bs=1 skip=$((0x78)) count=$((0x11380e8)) status=progress

The firmware payload starts at offset 0x129940 inside the recovered IFLASH driver:

dd if=artifacts/extracted/iflash/IFLASH_DRV_IMG.efi \
  of=artifacts/extracted/iflash/firmware_payload.bin \
  bs=1 skip=$((0x129940))

The resulting payload is 16,835,040 bytes with SHA-256 e8c78392bd193f9d3fbe38223a0d1d7638cd3e882b3db4deb98fd55e8527fd18. Inside it, $_IFLASH_BIOSIMG is at offset 448 and the raw 16 MiB image begins at offset 0x1D8:

dd if=artifacts/extracted/iflash/firmware_payload.bin \
  of=artifacts/firmware/FCCN21WW-update-16MiB.rom \
  bs=1 skip=$((0x1d8)) count=$((0x1000000))

artifacts/firmware/FCCN21WW-update-16MiB.rom is exactly 16,777,216 bytes and has SHA-256 988209aea6660cf774d79a785ea3dcea98fb48a519c709715733c254320d10a8.

This is the complete 16 MiB image distributed by the updater, but not necessarily a complete backup of the physical laptop. Serial numbers, UUIDs, calibration data, NVRAM state, and other board-specific information may only exist in the machine's SPI flash. The embedded-controller firmware may also reside on a separate device.

The ROM contains an AMD Platform Security Processor directory. PSPTool 3.6 stops on this image with a strict key-store assertion:

assert unknown_constants == (1, 2)

For read-only listing and extraction, Python's assertion-disabled mode allowed the parser to continue:

.venv/bin/python -O .venv/bin/psptool \
  artifacts/firmware/FCCN21WW-update-16MiB.rom
.venv/bin/python -O .venv/bin/psptool \
  -X -n -u -o artifacts/extracted/psp \
  artifacts/firmware/FCCN21WW-update-16MiB.rom

This recovered PSP boot and recovery components, trusted OS and trustlets, SMU and MP2 firmware, APCB data, PSP NVRAM/NV data, microcode, VBIOS preload, DMCU, security policy/key material, and the compressed BIOS reset/copy image.

Using python -O suppresses every Python assertion. It is acceptable here only as an explicitly understood parser workaround for read-only analysis. It must not be used with PSPTool's replacement command (-R) or any firmware-writing workflow.

The reset/copy entry is located at flash offset 0xF20000; its zlib stream begins at 0xF20100. The repository script can reproduce the extraction:

python3 scripts/extract_reset_image.py \
  artifacts/firmware/FCCN21WW-update-16MiB.rom \
  artifacts/extracted/psp/BIOS_RESET_3M.bin

It produced:

Its final reset-vector bytes are:

90 90 e9 eb e7 00 00 00 fb 00 00 00 00 00 b0 09

Mapping the update ROM directly as a conventional PC BIOS does not work because the last bytes of the 16 MiB image are erased (FF). On the real AMD platform, the PSP performs verification and preparation before the x86 reset stage runs.

The decompressed 3 MiB reset image does execute in QEMU. With an EPYC CPU model, execution starts at 0xFFFFFFF0, jumps to 0xFFFFE7E0, performs AMD-specific PCI configuration accesses, detects incompatible virtual hardware, and requests a hard reset by writing 0x06 to I/O port 0xCF9:

mov al, 0x06
mov dx, 0x0cf9
out dx, al

With -no-reboot, QEMU exits; without it, the VM continually resets. This is not evidence that the extracted image is broken. QEMU's Q35 platform does not model the Renoir PSP, Lenovo board chipset configuration, embedded controller, GPIOs, or the other devices expected by this firmware. Relevant traces are retained in artifacts/logs/qemu-execution.log and artifacts/logs/qemu-reset-image.log.

The extracted Setup Utility contains the ordinary Home, Information, Configuration, Power, Security, Boot, and Exit form sets, plus a separate form set titled Advanced.

The useful IFR output is:

artifacts/extracted/uefi/SetupUtility.3.0.Advanced.en-US.uefi.ifr.txt

The .3.4 paired dumps contain mismatched string packages; in particular, SetupUtility.3.4.AdvanceMenu.en-US.uefi.ifr.txt has an invalid title mapping and must not be used as the authoritative option inventory.

The recovered Advanced form set is:

There is no top-level IFR SuppressIf surrounding the Advanced form set. This ruled out the simplest explanation: one obvious SystemConfig byte directly controlling the whole menu from inside the IFR.

The relevant visibility mechanism lives in H2OFormBrowserDxe. Its form list pairs a form-set GUID with a 32-bit shown/hidden field. In the patch patterns, the GUID is followed by 00000000 when hidden; replacing it with 01000000 changes that entry to shown. The successful physical test confirmed that this visibility field is the effective runtime trigger on the tested environment.

This distinction matters. The discovery was not a guessed NVRAM offset and it was not another keyboard shortcut. It provided a narrow runtime patch target that could be tested without writing a modified image to SPI flash.

The IFR also contains disabled, unnamed numeric questions at SystemConfig offsets 0x79, 0x80, and 0x81, and at AdvanceConfig offsets 0x00 through 0x07. Their purpose is unknown. They are not evidence of an unlock byte and must not be modified speculatively.

See docs/ADVANCED_OPTIONS.md for the complete option inventory recovered from the correct IFR file.

The commonly reported Fn+R+N sequence was tried repeatedly without any visible effect. Public reports of this sequence working often concern later Lenovo 15ACH6/ARH7 generations; reports for the 15ARH05 are inconsistent. It is not a confirmed unlock method for this firmware.

Smokeless Runtime EFI Patcher (SREP) tag 0.1.4c was built from source because the upstream repository did not provide a current release asset. The build used:

The resulting x86-64 EFI executable is 16,640 bytes with SHA-256 79c46eb5fdb37ceb0aff7dcafa385c3f2cf018538f6e82704081242a714529da.

A GPT-partitioned FAT32 USB drive was prepared with:

EFI/BOOT/BOOTX64.EFI
SREP_Config.cfg

I used SREP as the runtime patch engine and designed the USB boot flow around the discovered form-browser visibility mechanism. The tested configuration is in the lenovo-15arh05-fccn profile. It uses the combined Lenovo form-set patterns documented upstream for AMD PBS, AMD CBS, Power, and Advanced, then launches SetupUtilityApp in the same boot session.

Profiles keep compatibility claims separate from hashes of the exact files used as research evidence. See the BIOS profile system for adding and validating other models or firmware families.

The reusable GUID + uint32 visibility mechanism is modeled separately as an InsydeH2O strategy. This allows other vendors and models to reuse the renderer without implying that the FCCN targets or GUIDs are universally compatible.

For the end-to-end build, USB preparation, boot, verification, and log-recovery procedure, follow the SREP USB Creation and Boot Guide.

The first prototype used only the Advanced GUID pattern and launched SetupUtility. Its saved SREP log proves that the application and configuration loaded, but reports No Patter Found. Entering the regular F2 setup after that boot could not show a runtime patch because the patched environment was no longer active.

That failure clarified two requirements: use the combined visibility patterns and open the firmware's SetupUtilityApp before leaving the patched boot environment. The rebuilt USB therefore used the combined form-set configuration and launched SetupUtilityApp in the same boot session. This attempt succeeded on the test laptop running FCCN19WW: the hidden Advanced, AMD PBS, and AMD CBS menu entries became visible and their pages rendered correctly. The result is documented in the physical-test gallery.

This confirms a runtime menu reveal, not a permanent unlock. The patch is applied in memory for that boot path; the firmware image on SPI flash was not modified. The photographs also do not establish that changing any exposed setting is safe.

1. Preserve the successful run's SREP.log and record every module load, pattern-match, patch, and execution result alongside the photographs.
2. Re-run the procedure once without saving changes to confirm repeatability and document the exact boot sequence.
3. Obtain the exact FCCN19WW update package or, preferably, two identical reads from the laptop's physical SPI flash.
4. Extract H2OFormBrowserDxe and SetupUtilityApp from that exact firmware and confirm the UI section names and Advanced GUID pattern.
5. Compare the installed FCCN19WW IFR against the existing FCCN21WW inventory before associating photographed controls with variable offsets.
6. Keep further runtime sessions observation-only and exit without saving.
7. Before changing any firmware setting, prepare a verified hardware recovery path and preserve the original board-specific flash contents.

For a physical SPI backup, identify the flash chip and voltage first, use the correct adapter, make at least two independent reads, compare their hashes, and keep immutable copies. Also determine whether the embedded controller has a separate flash device.

Do not experiment casually with display routing (Hybrid Graphics, dGPU/iGPU), SATA/RAID or PCIe GPP configuration, PSP/fTPM/Secure Boot state, SVM/SMM locks, memory timings and voltage, clocks or thermal limits, or the unnamed AdvanceConfig fields. A public report for this laptop family describes a no-display failure after changing graphics-related hidden settings.

• Lenovo BIOS Update for Windows 10 (64-bit) — IdeaPad Gaming 3 15ARH05
• PSPTool
• Smokeless Runtime EFI Patcher
• flashrom classic CLI documentation
• Reddit community discussion and follow-up
• 15ARH05 hidden-setting brick report