Resetting an Early 2011 MacBook Pro firmware password with a CH341B

I bought an Early 2011 MacBook Pro on OLX, listed as broken. It turned out to power on, but there was another problem: it had an EFI firmware password.

The laptop came without an SSD or HDD, so there was no previous owner's disk or data to recover. I wanted to get the machine usable again.

That turned into a small hardware project involving a CH341B programmer, an in-circuit clip, flashrom, and a Python script. After reflashing the firmware, the password was gone and I was able to boot macOS.

The hardware and the starting point

My machine was a 15-inch Early 2011 MacBook Pro with a Macronix MX25L6406E flash chip. Its capacity is 8 MiB, or 8,388,608 bytes.

I used a CH341B programmer and an in-circuit clip, so I didn't desolder the chip. For chip access and connection details, I followed this existing EFI firmware-password removal guide. The underlying technique isn't my discovery; my contribution was documenting my setup and adding a small helper for modifying the dump.

I didn't photograph the process before putting the laptop back together, so this is a write-up of my repair, not a complete board-level connection guide. Before connecting a programmer, check the chip's voltage requirements, the programmer's actual supply and signal levels, clip orientation, and the board's power-isolation requirements. A similar-looking programmer or logic board isn't enough to establish compatibility.

Read first, keep the original

Using flashrom on macOS, I read the chip twice:

sudo flashrom -p ch341a_spi \
  -c "MX25L6406E/MX25L6408E" -r dump1.bin

sudo flashrom -p ch341a_spi \
  -c "MX25L6406E/MX25L6408E" -r dump2.bin

The programmer was a CH341B, although flashrom's programmer option is named ch341a_spi.

Then I compared the dumps and kept an original copy:

cmp dump1.bin dump2.bin
shasum -a 256 dump1.bin dump2.bin
cp dump1.bin original.bin

cmp produces no output when the files match. The hashes provide another easy comparison. If the reads differ, stop and investigate before modifying anything.

Matching reads are a useful check, not proof that everything is correct. A consistently bad connection can still produce repeatable output. The expected file size and plausible contents matter too. Keep a separate private backup of the original, beyond the working directory.

Replace bytes, don't delete them

The modification concerns regions identified by the $SVS signature. The important practical detail is that the firmware image must keep its layout: removing bytes shifts everything that follows.

The helper in my gist replaces the selected bytes with 0xFF instead. The output stays the same size as the input.

python3 patch_svs.py dump1.bin modified.bin

The script checks for an 8 MiB input, locates the signatures, prints the proposed ranges and surrounding bytes, and asks for confirmation before creating the output.

There is a limitation worth making explicit: it finds the end of each region by looking for the next run of eight 0xFF bytes. That's a heuristic, not a full parser for the firmware format. The script also processes every matching signature it finds.

So don't treat it as a universal MacBook password-reset tool. Review the reported ranges for the specific image, check that the output size is unchanged, and inspect the differences before writing anything back. An unchanged size alone doesn't prove the modification is correct.

Also, use distinct input and output files. The current helper doesn't prevent you from choosing the original as the output, which would overwrite it.

Flashing and the result

Once the modified image was ready, I reflashed the chip. The write command in my notes is:

sudo flashrom -p ch341a_spi -V \
  -c "MX25L6406E/MX25L6408E" -w modified.bin

Flashrom normally verifies the contents after writing unless verification is disabled. The uppercase -V enables verbose output; it isn't the verification switch.

Writing firmware is the destructive part of this process. Keep the original available and remember that restoring it still depends on being able to communicate reliably with the chip.

In my case, reflashing removed the firmware password and I could boot macOS. That's the result I verified, rather than a claim that every function of the laptop was tested afterward.

What this applies to

This worked on my Early 2011 machine. I haven't established compatibility with other models or firmware revisions. It isn't an Activation Lock bypass or a way to decrypt FileVault-protected data.

Apple's documented procedure for a forgotten Intel Mac firmware password is an in-person service appointment with proof of purchase. The procedure above is an independent hardware-repair approach for a machine I purchased, not Apple's supported recovery workflow.

I've kept the commands and Python helper in this gist. If you're working on a similar repair, the useful starting point is an original dump you can trust, a backup you haven't overwritten, and a clear understanding of what the script proposes to change.

Cover photo: © Raimond Spekking / CC BY-SA 4.0 (via Wikimedia Commons). Reference photograph; not my repair.