I was following the process from BADCAPS but it turned out to be more involved than the usual “run the auto-patcher and flash” recipe, because this particular BIOS (GMET91WW, a 2021 build) enforces an RSA signature check on the patched image and refuses to boot otherwise. This post documents the full procedure that worked.

The hardware

Lenovo ThinkPad T540p
└── BIOS flash: MX25L3273E  (4 MiB, SOIC-8 SPI NOR)
        └── CH341A USB SPI programmer + SOIC-8 clip

The board connection CH341A and the SOIC-8 clip

The T540p is a Haswell-era machine, it carries an 8 MiB chip (MX25L6405 family) and the proper BIOS one 4 MiB MX25L3273E. Either way, the procedure is the same — you just need the right chip definition.

Chips on board, the BIOS is the right one

The plan

1. Dump the BIOS chip with flashrom
2. Verify the dump (multiple reads, identical hashes)
3. Patch the dump with the Lenovo BIOS auto-patcher (injects two DXE drivers)
4. Re-sign the modified BIOS so the machine actually boots it
5. Flash the signed image and trigger the unlock challenge
6. Restore the original BIOS

Most guides stop at step 3 and 5. The signature step in between is what makes the difference on newer BIOS builds.

Dumping the chip

A SOIC-8 clip sits on top of the chip without desoldering. The CH341A talks to it over SPI, and flashrom drives the whole thing:

Listing chips found

Check if we identified the correct chip

sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi -r t540p_original.bin

The chip is small enough that the clip is finicky. Read it three times and confirm the hashes match before touching anything:

sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi -r t540p_original_b2.bin
sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi -r t540p_original_b3.bin
sha256sum t540p_original*.bin

That verified dump is the single recovery path if anything goes wrong later — keep it somewhere safe.

Patching the BIOS

The Lenovo auto-patcher from the Badcaps forum community (lenovo-bios-autopatcher) does the heavy lifting: it replaces two DXE drivers in the firmware image (BootOption.ffs and LenovoTranslateService.ffs). On boot, the modified translation service presents a password challenge instead of a hard lock, which lets you generate a one-time unlock code.

cd lenovo-bios-autopatcher
./autopatch /path/to/t540p_original.bin

This produces t540p_original_PATCHED.bin. On its own, though, this image would not boot on my machine — it black-screened every time.

The black-screen trap: Insyde H2O RSA signature

ThinkPads of this era use an Insyde H2O firmware. Starting around certain BIOS builds, the firmware carries an RSA-signed block called TCPABIOS that stores a SHA1 checksum for the main firmware volume. When the auto-patcher injects the two DXE drivers, the volume bytes change, the SHA1 no longer matches what TCPABIOS records, and the BIOS treats the image as tampered.

On older BIOS builds the machine just beeps five times and continues. On the newer GMET91WW build it hard-stops with a black screen.

This is where the AI just simplifies so much our life, if I had to do this manually it would have taken ages, lots of trial and error. So lets use AI for what it is really usefull I started this with a local model (Qwen3.6-35B-A3B) running on my Mac M1, it worked really well, but has there was a lot of trial and error even on AI side, I switched to deepseek-flash-v4 and it went fast and smooth.

The fix is to re-sign the modified image with a new RSA key and swap the corresponding public key into the image. The signature scheme is:

• TCPABIOS block stores the volume checksum and is itself RSA-signed (e = 3, 1024-bit)
• The signing input is 0x00 * 108 + SHA1(block_data)
• The 128-byte signature follows a FF FF 83 separator
• The public key lives at a fixed offset in the same NVRAM region

It wrote a small tool (resign_bios.py) that does all of this automatically:

python3 resign_bios.py t540p_original_PATCHED.bin

This generates a fresh RSA keypair, updates the volume checksum in TCPABIOS, re-signs both TCPABIOS and TCPABBLK, and replaces the public key in the image. The output is t540p_original_PATCHED_SIGNED.bin, which boots cleanly.

Flashing and triggering the unlock

Flash the signed image:

sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi -w t540p_original_PATCHED_SIGNED.bin

Disconnect the programmer completely, then boot.

1. At the Lenovo splash, press F1 to enter BIOS setup
2. At the supervisor password prompt, type any character and press Enter
3. Reboot, enter BIOS again, type the same character
4. The screen shows a Hardware ID
5. Press Enter, then press Spacebar twice

On many guides, this is where an unlock code appears. On GMET91WW the machine instead reported “TPM written” — meaning the password was cleared directly without issuing a code. Either way, write down whatever the BIOS displays.

Restoring the original BIOS

Once the unlock routine is done, flash the verified original dump back:

sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi -w t540p_original.bin
sudo flashrom -c "MX25L3233F/MX25L3273E" -p ch341a_spi --verify t540p_original.bin

Then power on. If an unlock code was issued, enter BIOS and press F9 to restore factory defaults, entering the code when prompted. On my unit the password was simply gone after the “TPM written” pass.

Gotchas

• The clip is the weak link. Erase failures at a fixed sector almost always mean marginal contact on one of the address lines — reads still work, but writes fail. Reseat the clip firmly and clean the pads.
• Chip auto-detection lies. Running flashrom without -c sometimes reported an 8 MiB MX25L6405-family chip (a neighbouring part or marginal contact). Always pass -c "MX25L3233F/MX25L3273E" explicitly.
• The NVRAM volume patch is not needed here. The auto-patcher ships a 1 MiB NVRAM volume file; this BIOS uses a 408 KiB NVRAM, so that step correctly reports “not found”. Leave the NVRAM alone — the DXE injection plus re-sign is what does the work.
• Backup first. The original dump is the only way back. I kept three verified copies before patching.

Summary

Removing a forgotten supervisor password from a ThinkPad T540p is very doable with a CH341A programmer and a SOIC-8 clip.

The straightforward recipe is: dump → verify → auto-patch → flash → unlock → restore. On newer BIOS builds you additionally have to re-sign the patched image, because the Insyde H2O firmware verifies an RSA signature over the firmware volumes. Once I added that step, the machine booted, presented the unlock challenge, and the password was gone in one pass.

The whole procedure, including the re-signing tool and step-by-step workflow, is available in my lenovo-bios-unlock repository.

Disclaimer: This work was done purely for research and to recover from a problem caused by an official Lenovo BIOS update, on my own hardware. It is not intended to facilitate bypassing security on equipment you do not own, and it should not be used for any illegal purpose.

Disclaimer: I use AI as a productivity tool. For a senior engineer, AI is incredibly powerful as one can focus on the solution design and conceptualization and leave the boring part that is implementation to the AI.

The official installation documentation targets Linux, but NetBox itself is a Python/Django application backed by PostgreSQL and Redis. With a few FreeBSD-specific adjustments it runs cleanly inside a jail.

Architecture

FreeBSD 15.1-RELEASE host
│
└── netbox VNET jail
    │
    ├── nginx          :80
    │    └── Gunicorn  127.0.0.1:8001
    │         └── NetBox
    │
    ├── PostgreSQL 17
    ├── Redis
    └── NetBox RQ worker

Everything runs natively in one jail using normal FreeBSD services.

Why a jail?

• Native FreeBSD deployment without Docker
• No Linux VM just for NetBox
• PostgreSQL, Redis and nginx come from normal FreeBSD packages
• ZFS snapshots make rollback easy
• VNET gives the jail its own LAN address
• The application can be managed with standard service commands

Creating the jail

Create a VNET jail on the FreeBSD host. Adjust the address and interface for your network:

bastille create -V netbox 15.1-RELEASE 192.168.2.55/24 vtnet0

Before starting PostgreSQL, give the jail private System V IPC namespaces:

bastille config netbox set sysvmsg new
bastille config netbox set sysvsem new
bastille config netbox set sysvshm new
bastille restart netbox

Without these settings PostgreSQL initdb fails with:

FATAL: could not create shared memory segment: Function not implemented
DETAIL: Failed system call was shmget(...)

Enter the jail:

bastille console netbox

Installing NetBox

The bootstrap script installs the full stack:

fetch https://codeberg.org/dkade/BSD/raw/branch/main/FreeBSD/netbox/install_netbox_freebsd.sh
chmod +x install_netbox_freebsd.sh

NETBOX_HOST=netbox.home.lan \
NETBOX_IP=192.168.2.55 \
./install_netbox_freebsd.sh

The current script is pinned to NetBox 4.6.1 and installs:

• Python 3.12
• PostgreSQL 17
• Redis
• Gunicorn
• nginx

NetBox itself lives under:

/usr/local/netbox/
├── src/
├── venv/
└── gunicorn.py

The installer creates native FreeBSD services for:

netbox
netbox_rq

and enables the standard services:

postgresql
redis
nginx

FreeBSD service handling

This was the main FreeBSD-specific part.

A first implementation used:

daemon
└── su
    └── gunicorn

It started successfully, but stop and restart could hang because the FreeBSD service framework was tracking a supervisor process instead of the actual Gunicorn master.

The working version lets Gunicorn daemonize itself and maintain:

/var/run/netbox/netbox.pid

The rc.d script then signals the real Gunicorn master directly.

The RQ worker uses the same principle and stores its real PID at:

/var/run/netbox/netbox-rq.pid

This gives normal FreeBSD behaviour:

service netbox start
service netbox stop
service netbox restart
service netbox status

service netbox_rq start
service netbox_rq restart
service netbox_rq status

nginx

nginx listens on port 80 and proxies to Gunicorn on localhost:

client
  |
  v
nginx :80
  |
  v
Gunicorn 127.0.0.1:8001
  |
  v
NetBox

The generated configuration lives at:

/usr/local/etc/nginx/conf.d/netbox.conf

Creating the administrator

After installation:

cd /usr/local/netbox/src/netbox

su -m netbox -c \
  '/usr/local/netbox/venv/bin/python manage.py createsuperuser'

Then open the hostname or jail IP in a browser.

ALLOWED_HOSTS and CSRF

Django validates both request hosts and POST origins.

The installer adds the configured hostname and optional jail IP to:

ALLOWED_HOSTS = [
    'netbox.home.lan',
    '192.168.2.55',
    'localhost',
    '127.0.0.1',
]

CSRF_TRUSTED_ORIGINS = [
    'http://netbox.home.lan',
    'http://192.168.2.55',
]

If the origin is missing, the UI can load normally but login fails with:

Forbidden (403)
CSRF verification failed. Request aborted.

If HTTPS is added later, add the matching https:// origin as well.

Checking the stack

service netbox status
service netbox_rq status
service postgresql status
service redis status
service nginx status

Gunicorn should only listen on localhost:

sockstat -4 -l | grep 8001

nginx should listen on port 80:

sockstat -4 -l | grep ':80'

Upgrading

Before upgrading I would take a ZFS snapshot and dump PostgreSQL:

pg_dump -U netbox -h 127.0.0.1 netbox > /root/netbox.sql

Then stop the application:

service netbox_rq stop
service netbox stop

For now the installer intentionally stays pinned to a known working NetBox release rather than automatically following the latest tag. A separate upgrade script can later handle release download, Python dependency updates, migrations, static file collection and service restart.

Gotchas

• System V IPC: PostgreSQL needs sysvmsg=new, sysvsem=new and sysvshm=new in the Bastille jail.
• Service user shell: /bin/sh avoids the su and user-environment problems we hit with /usr/sbin/nologin.
• Gunicorn 26 runtime path: set XDG_RUNTIME_DIR=/var/run/netbox so its control socket is created in a directory owned by the NetBox user.
• Avoid daemon -> su -> gunicorn: startup works, but signal propagation makes stop/restart unreliable.
• Track the real RQ worker PID: the same supervisor problem applies to the background worker.
• CSRF matters: any hostname or IP used in the browser must be represented in the Django host/origin configuration.
• Static docs directory: release archives may omit project-static/docs; creating it avoids Django’s static-files warning.
• FreeBSD is not NetBox’s officially documented installation target: future upgrades may need extra ports/packages when Python dependencies change.

Summary

NetBox runs well natively inside a Bastille VNET jail once the service supervision and PostgreSQL IPC details are handled.

The final stack is simple:

FreeBSD jail
├── nginx
├── NetBox / Gunicorn
├── NetBox RQ
├── PostgreSQL
└── Redis

No Docker, no Linux VM, and the whole application behaves like a normal FreeBSD service.

Disclaimer: I use AI as a productivity tool. For a senior engineer, AI is incredibly powerful as one can focus on the solution design and conceptualization and leave the boring part that is implementation to the AI.

The official Wiki.js release targets Linux, but there is one important catch: it ships a prebuilt Linux sqlite3 native module. On FreeBSD this needs to be rebuilt locally before Wiki.js will start.

This post covers a simple Wiki.js 2.5.314 installation on FreeBSD 15.1 using SQLite, Node.js 24, and a native rc.d service.

Setup

The jail is a normal FreeBSD 15.1-RELEASE jail with its own IP on the LAN.

FreeBSD 15.1-RELEASE Host
│
└── wiki jail
    └── Wiki.js :3000

No Docker or Linux emulation is needed. Wiki.js itself runs natively under FreeBSD Node.js.

Why a jail?

• Native FreeBSD deployment without Docker
• No Linux VM just for Wiki.js
• Node.js, npm and SQLite come from normal FreeBSD packages
• ZFS snapshots make rollback easy
• VNET gives the jail its own LAN address
• The application can be managed with standard service commands

Installing Wiki.js

I created a small bootstrap script which handles the whole installation.

Inside the jail as root:

fetch https://codeberg.org/dkade/BSD/raw/branch/main/FreeBSD/wikijs/install-wikijs-freebsd-15.1.sh
chmod +x install-wikijs-freebsd-15.1.sh
./install-wikijs-freebsd-15.1.sh

The script installs:

node24
npm-node24
python311
gmake
pkgconf
sqlite3
ca_root_nss

It then downloads Wiki.js 2.5.314 and extracts it under:

/usr/local/wikijs

A dedicated wikijs user is created to run the service instead of running Wiki.js as root.

The SQLite FreeBSD gotcha

The official Wiki.js release includes its node_modules, including a prebuilt sqlite3 native module.

Trying to start it directly on FreeBSD results in errors such as:

Shared object "libc.musl-x86_64.so.1" not found,
required by "node_sqlite3.node"

Running ldd makes the problem obvious:

ldd /usr/local/wikijs/node_modules/sqlite3/build/Release/node_sqlite3.node

returns:

not a FreeBSD ELF shared object

The bundled module is a Linux/musl binary, so it cannot be used natively on FreeBSD.

The solution is to rebuild only the SQLite native module:

cd /usr/local/wikijs

rm -rf node_modules/sqlite3/build

env \
  npm_config_python=/usr/local/bin/python3.11 \
  npm_config_build_from_source=true \
  MAKE=gmake \
  npm rebuild sqlite3

Python 3.11 is used because the version of node-gyp bundled with Wiki.js 2.5.x still depends on Python’s old distutils module, which was removed in Python 3.12.

After the rebuild:

file node_modules/sqlite3/build/Release/node_sqlite3.node

should identify it as a FreeBSD ELF shared object.

Test it directly:

node -e "const s=require('sqlite3'); console.log(s.VERSION); console.log('sqlite3 OK')"

Configuration

Wiki.js uses:

/usr/local/wikijs/config.yml

For a simple SQLite setup:

port: 3000

db:
  type: sqlite
  storage: /usr/local/wikijs/data/wiki.db

Make sure the database directory is writable by the Wiki.js user:

mkdir -p /usr/local/wikijs/data
chown -R wikijs:wikijs /usr/local/wikijs

FreeBSD rc.d service

The installer creates:

/usr/local/etc/rc.d/wikijs

Wiki.js is started using FreeBSD’s daemon(8) and Node.js:

/usr/local/bin/node /usr/local/wikijs/server

The service is enabled with:

sysrc wikijs_enable=YES

Start it:

service wikijs start

Check the status:

service wikijs status

Restart it:

service wikijs restart

Logs are written to:

/var/log/wikijs.log

so they can be followed with:

tail -f /var/log/wikijs.log

Once running, Wiki.js is available at:

http://<jail-ip>:3000

The first connection opens the Wiki.js setup wizard.

Upgrading

Before upgrading, take a ZFS snapshot or at least back up:

/usr/local/wikijs/config.yml
/usr/local/wikijs/data/

After replacing the Wiki.js application files with a newer release, rebuild the SQLite module again:

cd /usr/local/wikijs

env \
  npm_config_python=/usr/local/bin/python3.11 \
  npm_config_build_from_source=true \
  MAKE=gmake \
  npm rebuild sqlite3

Then restart Wiki.js:

service wikijs restart

Avoid blindly running:

npm update

or:

npm audit fix --force

inside the Wiki.js application tree. Wiki.js ships with a specific dependency set and changing package versions independently can break the application.

Gotchas

• SQLite native module: the bundled node_sqlite3.node is Linux/musl and must be rebuilt for FreeBSD.
• Python version: use Python 3.11 when rebuilding with the older bundled node-gyp.
• Node.js: Wiki.js 2.5.314 runs correctly with the FreeBSD node24 package.
• Do not copy old node_modules: when upgrading, use a clean Wiki.js release tree and preserve only your configuration and database.
• rc.d PID tracking: when using daemon(8), set procname to /usr/local/bin/node so service wikijs status correctly detects the running process.

Summary

Wiki.js runs cleanly inside a FreeBSD 15.1 jail without Docker or Linux emulation.

The only non-obvious part is rebuilding the bundled SQLite native module for FreeBSD. Once that is done, Wiki.js behaves like any other native FreeBSD service: a dedicated user, an rc.d script, automatic startup, and straightforward ZFS snapshots for backups and upgrades.

The bootstrap script automates the complete process from a fresh jail.

Disclaimer: I use AI as a productivity tool. For a senior engineer, AI is incredibly powerful as one can focus on the solution design and conceptualization and leave the boring part that is implementation to the AI.

Architecture

FreeBSD 15.1-RELEASE Host
│
├── homeassistant (192.168.2.50)  — HA Core :8123
├── mosquitto    (192.168.2.52)  — MQTT broker :1883
└── zigbee2mqtt  (192.168.2.51)  — Zigbee2MQTT, Sonoff USB passthrough

All three jails are VNET on the same /24 subnet. HA Core talks to Mosquitto over MQTT, Zigbee2MQTT publishes device states to Mosquitto, and HA subscribes. Shelly devices connect directly over WiFi and are auto-discovered by HA on the LAN.

Why jails?

• Native FreeBSD — no Docker overlay, no Linux emulation
• VNET gives each jail a real IP on the LAN — devices discover HA directly
• ZFS snapshots for quick rollbacks before upgrades
• Each service in its own jail — clean isolation, restart one without affecting others

Creating the jails

bastille create -V homeassistant 15.1-RELEASE 192.168.2.50/24 vtnet0
bastille create -V mosquitto 15.1-RELEASE 192.168.2.52/24 vtnet0
bastille create -V zigbee2mqtt 15.1-RELEASE 192.168.2.51/24 vtnet0

The -V flag gives each jail a VNET interface with its own IP and routing table — they live on the same broadcast domain as the host.

HomeAssistant jail

A bootstrap script handles the full setup:

• Repository: codeberg.org/dkade/BSD
• Method: Python 3.14 virtual environment under /usr/local/etc/homeassistant/venv
• User: dedicated hass system user
• Service: FreeBSD rc.d script using daemon -u hass
• Enable: sysrc homeassistant_enable=YES

What the script does:

# Inside the jail as root
fetch https://codeberg.org/dkade/BSD/raw/branch/main/FreeBSD/install_ha_freebsd.sh
sh install_ha_freebsd.sh

It installs system packages (python314, gcc12, rust, dbus, libffi, openssl, etc.), creates a venv, and installs homeassistant along with numpy, zlib_ng, and isal for performance. The rc.d script starts HA as the hass user and listens on port 8123.

After first boot, complete the onboarding at http://192.168.2.50:8123.

Mosquitto jail

bastille console mosquitto
pkg install mosquitto
sysrc mosquitto_enable=YES
service mosquitto start

No authentication is needed on a local subnet — configure listener 1883 192.168.2.52 in /usr/local/etc/mosquitto/mosquitto.conf to bind to the jail IP.

Zigbee2MQTT jail

This jail needs access to the Sonoff Zigbee coordinator plugged into the host.

USB passthrough with devfs

On the host (/etc/devfs.rules):

[bastille_usb=101]
add path 'usbctl' mode 0660
add path 'usb/*' mode 0660
add path 'ugen*' mode 0660
add path 'cuaU*' mode 0660
add path 'ttyU*' mode 0660

Set the rule in /usr/local/bastille/jails/zigbee2mqtt/jail.conf:

devfs_ruleset = "bastille_usb";

Then find the Sonoff device:

# On the host
ls /dev/cuaU*
# /dev/cuaU0 <- this is the Sonoff

Restart the jail and you should see the device inside:

bastille restart zigbee2mqtt
bastille console zigbee2mqtt
ls /dev/cuaU*

Installing and configuring

bastille console zigbee2mqtt
pkg install node npm mosquitto-libs
npm install -g zigbee2mqtt

Create /usr/local/etc/zigbee2mqtt/configuration.yaml:

mqtt:
  server: mqtt://192.168.2.52:1883
serial:
  port: /dev/cuaU0
frontend:
  port: 8080

rc.d script at /usr/local/etc/rc.d/zigbee2mqtt to start via daemon, then sysrc zigbee2mqtt_enable=YES && service zigbee2mqtt start.

Device integration

• Shelly (WiFi): connect them to your WiFi. HA auto-discovers them via the LAN once the Shelly integration is added in the UI.
• Zigbee (Sonoff sensors, bulbs, etc.): pair through the Zigbee2MQTT frontend (http://192.168.2.51:8080). HA receives device states via MQTT auto-discovery.

Upgrading

# HA Core
bastille console homeassistant
service homeassistant stop
su -l hass -c \
  'HOME=/usr/local/etc/homeassistant PIP_CACHE_DIR=/tmp/pip-cache \
   /usr/local/etc/homeassistant/venv/bin/pip install --upgrade homeassistant'
service homeassistant start

# zigbee2mqtt
bastille console zigbee2mqtt
service zigbee2mqtt stop
npm update -g zigbee2mqtt
service zigbee2mqtt start

# mosquitto
bastille console mosquitto
pkg upgrade mosquitto
service mosquitto restart

Gotchas

• Python compilation: HA Core compiles C and Rust extensions during pip install. Make sure gcc12, rust, libffi, and openssl are installed in the jail before installing HA.
• dbus: HA Core expects D-Bus to be running (service dbus start). The rc.d script has REQUIRE: dbus, so dbus starts first.
• USB devfs: The devfs ruleset must be applied before the jail starts. Double-check the ruleset number matches in both /etc/devfs.rules and the jail config.
• VNET routing: If jails can’t reach the internet for pkg install, check that gateway_enable="YES" is set on the host and NAT/pf is configured for the VNET subnet.
• Persistent pip cache: The script sets PIP_CACHE_DIR=/tmp/pip-cache so you don’t re-download wheels on every upgrade.

Summary

Three FreeBSD jails managed with BastilleBSD running HA Core, Mosquitto, and Zigbee2MQTT — each with its own IP, rc.d service, and clean isolation. The bootstrap script at codeberg.org/dkade/BSD automates the HA jail from scratch, and the rest is just standard FreeBSD package management.

Disclaimer: I use AI as a productivity tool. For a senior engineer, AI is incredibly powerful as one can focus on the solution design and conceptualization and leave the boring part that is implementation to the AI.

Read more at -> https://aws.amazon.com/blogs/architecture/field-notes-how-olx-europe-fights-millions-of-bots-with-aws/