AI
Control Vault — What It Is and Why It Matters
Control Vault is a secure system-on-chip built into over 100 Dell Latitude and Precision laptop models. It sits on its own daughterboard, runs a real-time OS on a Broadcom BCM58202, and manages every biometric peripheral on the machine — fingerprint reader, NFC card reader, smart card reader. Dell markets it as the Unified Secure Hub. Most users have never heard of it.
The chip has been shipping since at least 2010. Control Vault 3 arrived in 2019. Based on Philippe Laulheret’s reversing, at least one of the vulnerabilities he found traces back to the original version — which puts the potential exposure at tens of millions of devices across 15 years of production.
Recon — Extracting Architecture from Sparse Documentation
Laulheret assembled a picture of Control Vault from three sources: a GitHub repo shipping Linux host APIs compiled with debug symbols (function names, structs, and calling conventions all readable in Ghidra), a FIPS certification for the BCM58202 that named internal acronyms like SBI, and the Dell driver installer itself. That installer holds a firmware folder with SBI files in cleartext plus an encrypted blob labeled Citadel — the application firmware and the primary target.
“with 20 lines of Python, you can start interacting with this like mysterious board that’s inside your laptop” — Philippe Laulheret
Attack Surface and Missing Mitigations
From the offensive side, Control Vault presents four angles: the SBI and application firmware handling all those CV commands, the firmware update and signature-check mechanisms, the Windows-side driver and Broadcom services, and the hardware peripherals themselves.
“with 20 lines of Python, you can start interacting with this like mysterious board that’s inside your laptop” — Philippe Laulheret
The Broadcom services run without ASLR. Stack cookies appear inconsistently — present in some functions, absent in others, with no clear reason. The firmware is worse: no ASLR, no stack cookies, and read-write-execute memory regions. Get control of the instruction pointer and you can execute shellcode directly.
Decrypting the Application Firmware
The Citadel application firmware is encrypted on flash, so Laulheret started in the SBI. He loaded the secure boot image into IDA and searched for strings referencing decryption failures. Failure messages pointed straight to the upgrade flow: a three-step sequence of upgrade_start, update, and upgrade_complete. The first command sends the encrypted firmware header, which the chip decrypts using OTP keys — or hardcoded defaults if no key is provisioned. Subsequent blocks arrive with a custom IV, get decrypted, and are written to flash. The final step verifies the signature and commits.
Re-implementing that protocol against the Citadel binary produced a cleartext firmware image. With that in hand, the full CV command handler was open for analysis.
Heap and Stack Vulnerabilities in the CV Command Handler
CV open hands the session’s heap address to user land. CV close checks only that the pointer is in range and a session tag is present, so a forged tag in a user-controlled object triggers an arbitrary free. CV get random returns different error codes for valid versus invalid handles — a side-effect-free oracle for locating the planted object in the heap.
That primitive chains into a stack overflow. secure_bio_identify mem-copies an object property into a stack buffer sized by the property’s own declared length. Corrupt the heap object’s metadata, feed it to the function. No stack cookies. No ASLR.
“if you can get like control over the instruction pointer like you pretty much you’re done and you can execute code” — Philippe Laulheret
Persistent Firmware Implant and Windows SYSTEM Shell
The OTP key dump leaks the per-device AES and HMAC fuse keys. Those keys decrypt the Secure Code Descriptor, which holds the RSA key the update mechanism trusts. Forge a new SCD with your own RSA pair, sign a tampered image, and flash it. The implant survives OS reinstalls because Windows never touches the control board.
From there, two payloads: patching CV_fingerprint_identify to always return a match lets a plastic finger covered in green onion unlock Windows Hello, and the backdoored firmware overflows the WinBio adapter’s stack to spawn netcat under SVCHOST, a SYSTEM shell.
“a rogue firmware can compromise Windows” — Philippe Laulheret
Notable Quotes
with 20 lines of Python, you can start interacting with this like mysterious board that’s inside your laptop Philippe Laulheret · ▶ 8:38
if you can get like control over the instruction pointer like you pretty much you’re done and you can execute code Philippe Laulheret · ▶ 12:20
CV flash update is a function that anyone can call. And so, you have by design like an arbitrary flash write Philippe Laulheret · ▶ 24:41
you could have a permanent implant in the firmware of your control board device that way Philippe Laulheret · ▶ 27:33
a rogue firmware can compromise Windows Philippe Laulheret · ▶ 36:10
Key Takeaways
- Treat every embedded SoC on your laptop as an independent attack surface — Control Vault runs its own RTOS with no ASLR and no stack cookies.
- Chain low-severity primitives: heap arbitrary-free plus a stack overflow is enough for full firmware code execution from unprivileged user land.
- Firmware implants on auxiliary security chips survive OS reinstalls and can escalate to Windows SYSTEM, bypassing every host-based control.