There is a category of firmware blob that does not do anything cryptographically interesting. It is not signing payloads, validating hardware attestations, or running complex state machines. It is sending a handful of serial commands to a modem and exiting. This is exactly what Lenovo’s WWAN unlock blob does, and the fact that it took reverse engineering to discover this says more about vendor incentive structures than it does about the technical complexity involved.
What the Unlock Blob Actually Does
On a range of ThinkPad models, Lenovo ships a closed-source binary that runs at boot, typically triggered by a udev rule matching the WWAN module’s USB vendor and product IDs. The binary opens a communication channel to the modem, sends an initialization or unlock sequence, and exits. The modem is then in a state where ModemManager can manage it normally.
The modem itself, depending on generation, is one of a small set of modules: the Fibocom L850-GL (Intel XMM7360 baseband, USB IDs 2cb7:0007), the Fibocom L860-GL (Intel XMM7560, 2cb7:0132), or Sierra Wireless EM-series modules on Qualcomm MDM9x chipsets. Each uses a different protocol for control: Fibocom modules primarily use MBIM (Mobile Broadband Interface Model) for data path control but expose an AT command port; Sierra Wireless modules use Qualcomm’s QMI (Qualcomm MSM Interface) over /dev/cdc-wdmX.
The unlock sequence, as reverse engineering reveals, is a short series of AT commands sent over the modem’s serial interface, typically accessible at /dev/ttyUSB2 or /dev/ttyACM0 depending on how the modem enumerates. AT commands are plain ASCII strings that have been the standard modem control interface since the Hayes Smartmodem in 1981. There is nothing proprietary about the channel.
The Communication Layer
Sending AT commands from a shell script is trivial. The modem serial port is just a character device. You can write to it with standard file operations:
exec 3<>/dev/ttyUSB2
stty -F /dev/ttyUSB2 115200 raw -echo
echo -e 'AT+CFUN=1\r' >&3
sleep 0.3
cat <&3Or with socat, which handles the bidirectional flow more cleanly and lets you set line discipline options:
printf 'AT+CFUN=1\r\n' | socat - /dev/ttyUSB2,crnl,crtscts=0,b115200The complication in real usage is not the I/O; it is timing and device ownership. ModemManager, the standard Linux modem management daemon, claims the modem’s ports on detection. If your script tries to open /dev/ttyUSB2 while ModemManager is also using it, you get Device or resource busy. The solution is to use mmcli --inhibit-device before sending commands and release it afterward, or to run the script from a udev rule that fires before ModemManager gets to the device. The Lenovo blob presumably handles this sequencing, which is one reason it runs as a udev-triggered service rather than being folded into a post-init hook.
The specific AT commands involved in WWAN unlock vary by modem. On Qualcomm Sierra Wireless modules, the unlock namespace is the AT! vendor extension:
AT!ENTERCND="A710" # enter command mode with the vendor password
AT!BAND=00 # enable all bands (removes band restrictions)
AT!RESET # apply and resetOn Fibocom modules, the sequence is different, often involving AT+CFUN state transitions and vendor-specific AT+XACT band configuration commands from Intel’s AT command set. The key point is that these are documented (partially) in vendor AT command reference manuals, many of which are available under NDA but have been leaked or independently reverse-engineered and documented in places like the ModemManager bug tracker and various ThinkPad-focused Linux wikis.
Why a Blob Exists at All
If the unlock operation is a few AT commands over a standard serial interface, why does Lenovo ship it as a binary?
Three reasons, none of them particularly satisfying.
First, modem vendors share initialization sequences under NDA. Fibocom and Sierra Wireless give Lenovo the exact commands needed to bring their modules into the correct state for Lenovo’s hardware configuration. The NDA forbids shipping those sequences in readable form. A compiled binary satisfies the letter of the agreement while giving users a functional system. The obscurity is the point, not a side effect.
Second, FCC regulations require that certain radio parameters, specifically transmit power limits and band restrictions, cannot be trivially reconfigured by end users. Shipping the unlock logic as an opaque binary provides regulatory cover: Lenovo can demonstrate to the FCC that end users cannot trivially override the configured RF parameters because the configuration mechanism is not human-readable. The FCC does not require that the mechanism be cryptographically strong, only that it not be a plaintext file. A compiled blob clears that bar.
Third, BIOS-level WWAN whitelisting means that Lenovo ThinkPads check the USB VID/PID of any inserted WWAN module against a firmware whitelist. Third-party modules with different IDs are disabled before the OS boots. The unlock blob sometimes handles re-enumeration, where the module initially presents with one USB ID and switches to another after receiving the right AT command. This modeswitch pattern is separate from the unlock itself but often bundled in the same blob because they affect the same device.
None of these justify a permanently proprietary blob in 2025. The FCC has explicit provisions for software-defined radio device authorization that could accommodate open initialization sequences. The NDA constraint is a business decision, not a technical one. And modeswitching for USB devices is already handled upstream by usb_modeswitch and has been for well over a decade.
The ModemManager Angle
The right long-term fix is not a replacement Bash script. It is having the initialization sequence upstreamed into ModemManager itself, where it would live as a plugin for the affected hardware ID, be maintained with the rest of the modem management code, and work without any additional service or udev rule.
ModemManager’s plugin architecture is exactly designed for this. A plugin in src/plugins/ subclasses MMBroadbandModem and overrides the setup or enable virtual methods to send device-specific initialization before the modem is handed to the generic management stack. The Fibocom and Sierra Wireless plugins already exist; they need the unlock sequence added to them.
The barrier is that doing this properly requires either the vendor to contribute the sequence (unlikely without open-sourcing the NDA material) or a community contributor to reverse-engineer it and submit it as a patch. The Hofstede script is evidence that the reverse engineering is tractable. The missing step is translating that into a ModemManager patch and getting it merged. Several similar patches have made it upstream over the years; the Quectel EC25 initialization quirks, for example, were contributed by community members who had done the same AT command tracing.
The Security Concern Nobody Talks About
A binary blob that runs as root at boot, opens hardware device nodes, and sends commands to radio hardware with no source code available is worth treating as an attack surface. Lenovo’s blob presumably does exactly what it advertises, but there is no way to verify this short of disassembly. The blob has network-adjacent hardware access and runs early in the boot sequence.
This is not a hypothetical. The supply chain compromise scenarios that affected enterprise hardware in other contexts all depended on opaque initialization code running with elevated privileges. A compromised WWAN unlock blob could send additional AT commands: exfiltrating the IMEI, modifying band configuration in ways that degrade security, or interacting with modem firmware in undocumented ways. The AT! command namespace on Qualcomm modems, for instance, includes commands that can modify NV storage and firmware image slots, not just band restrictions.
Replacing the blob with auditable shell code eliminates this surface entirely. The script in question is 100 lines. Every line is readable. Every command has a man page. The tradeoff is clear.
What This Pattern Tells Us
The WWAN unlock blob is a specific instance of a general pattern: vendor code that does something simple, ships as binary for contractual or regulatory reasons, and blocks open-source users from understanding their own hardware. USB modeswitch blobs, firmware loaders for Wi-Fi cards, and display panel initialization sequences all follow the same structure.
The community response, reverse engineering followed by a clean reimplementation, is also a well-established pattern. The linux-firmware repository exists because of this cycle. The xmm7360-usb-modeswitch project on GitHub covers the Intel XMM7360-based Fibocom modem’s USB initialization for exactly this reason. Each of these is a worked example of what happens when binary interfaces meet determined engineers with strace and a packet capture.
A 100-line Bash script replacing a proprietary blob is not surprising. What it illustrates is that the cost of reverse engineering simple initialization sequences is low, the benefit to Linux users is concrete and immediate, and the main obstacle to having this work upstream is the organizational friction of getting vendor-adjacent code through the contribution process. That friction is worth addressing, because a maintained ModemManager plugin serves more users and lasts longer than a shell script in someone’s blog post.