LLM-Assisted Reverse Engineering: ThinkPad X61 Coreboot Port

A developer has successfully ported coreboot to the ThinkPad X61 using Anthropic's Claude Opus 4.6 for reverse engineering. The project, documented on the author's blog, demonstrates both the power and limitations of LLMs in firmware development.

The Challenge

The ThinkPad X61 uses a GM965 northbridge and ICH8 southbridge. While similar to the already-supported GM45/ICH9 platforms (ThinkPad X200), there are no leaked datasheets. Previous attempts using SerialICE failed to produce a working port. Manual reverse engineering would take 3-6 months.

AI-Assisted Workflow

The author downloaded the vendor Phoenix BIOS image and split it into modules using bios_extract. They gave the LLM two tools: ghidra-cli for PE32 modules (raminit code from Intel MRC) and radare2 for 16-bit real-mode code. The model identified three raminit versions in the image, likely an A/B layout with a read-only recovery copy (the top 64KB of flash is write-protected per Lenovo behavior).

Reality Check: Vibe Coding Fails

The initial claim that the LLM wrote the entire coreboot port in two prompts while at the gym was a joke. In reality, the model needed extensive hand-holding. The author listed over 20 corrections required, including:

  • GPIO mux for SMBUS on GPIO42 (only SPD or EEPROM visible)
  • DDR2 support: 533/666 MT/s, not 666/800 MT/s
  • GMCH FSB frequency read from MCHBAR, not PCI
  • Wrong register sizes (32-bit writes to 16-bit registers)
  • CAS semantics confusion between coreboot and MRC conventions
  • Multiple raminits confusing the model

Prior work by Lubomir Rintel (SerialICE traces) proved essential for debugging.

Flashing and Testing Setup

The author used the docking station's RS232 UART for serial output. Flashing required removing the board and using a clip on the SOIC8 flash chip (bottom of board). The command:

flashprog -p ch341a_spi --ifd -i bios -w build/coreboot.rom

The Intel descriptor, GBE, and ME regions were left untouched initially. The author notes it should be possible to reduce to IFD + GBE + BIOS, dropping ME entirely (similar to ich9 laptops).

Porting libgfxinit to GM965

Making libgfxinit work was straightforward due to hardware similarity with the next generation. The patch (https://review.coreboot.org/c/libgfxinit/+/91522) required only PLL clock limit adjustments and fixing the GMS register for stolen memory/GTT. The LLM converted Linux modesetting code into usable Ada in "very little time."

Upstreaming and Review

Angel Pons, a coreboot reviewer, caught multiple issues:

  • Wrong register names copied from nearby chipsets or decompiler output
  • Reserved bits treated as real bits
  • Wrong access sizes (e.g., GM965 0xa00 MCHBAR range had hallucinated register block semantics; it's actually closer to EP channel/ME stuff)
  • Timing tables indexed incorrectly
  • Bitfield semantics wrong, calculations working only by luck for tested DIMMs
  • Hardcoded ThinkPad X61 assumptions in southbridge init

The author's biggest frustration was clang-format, which caused more problems than benefits. They eventually submitted a patch to remove the clang-format config from coreboot.

Results and Future

The port works with multiple DIMM combinations. The author emphasizes that LLMs accelerated the process but couldn't replace deep platform knowledge. The project shows that LLM-assisted reverse engineering can reduce months of work to days, but "vibe reverse engineering won't be upstreamable without a real engineer anytime soon."

Technical Details

  • Platform: GM965 northbridge + ICH8 southbridge
  • Tools: bios_extract, ghidra-cli, radare2, flashprog
  • LLM: Anthropic Claude Opus 4.6
  • Coreboot patch: libgfxinit changes at review.coreboot.org/+/91522
  • Flashing: CH341A SPI programmer with SOIC8 clip

Why This Matters for Developers

LLMs can significantly speed up reverse engineering of legacy firmware, but they hallucinate register names, sizes, and semantics. Success requires deep knowledge of similar platforms and rigorous code review. This case study provides a blueprint for using LLMs in firmware development while highlighting the pitfalls.

Actionable Takeaways

  1. Use LLMs for initial extraction and code generation, but verify every register against hardware or known-good dumps.
  2. Combine multiple decompilers: ghidra for PE32 modules, radare2 for 16-bit code.
  3. Always run LLM-generated code through a domain expert reviewer.
  4. Avoid clang-format on coreboot codebases.
  5. Document every correction to build a dataset for future LLM fine-tuning.