ReVault! Compromised by Your Secure SoC... with Philippe Laulheret

Topic & premise

• The session discusses ReVault!, a set of research findings showing how a Dell “ControlVault” Secure SoC (Broadcom-based, with an RTOS/secure storage model) can be compromised despite the presence of secure boot / encrypted firmware storage.
• The core claim is that multiple weaknesses across firmware trust boundaries, key handling, boot-chain behavior, and host↔SoC command marshalling enable:
  • Decryption of application firmware
  • Arbitrary memory corruption
  • Code execution on the SoC
  • Persistent firmware modification
  • Potential host (Windows) compromise via Windows services/APIs

Speaker background / research approach (source: Philippe)

• Philippe Laulheret (Cisco Talos) describes work involving:
  • Vendor reporting via coordinated disclosure
  • Publishing detection rules and writeups
  • Sharing practical reversing assets when possible (e.g., IDA workflows, scripts)

What ControlVault is (product/architecture details)

• ControlVault is present in many Dell business laptops (e.g., Latitude/Precision lines).
• Hardware/software stack includes:
  • A Broadcom secure chip (example given: Broadcom 58202)
  • Encrypted flash storage for secrets
  • A real-time OS (mentioned as AR/RTOS; slides describe an RTOS layer)
  • Windows/Linux user/kernel APIs to communicate with the device
• Versions:
  • ControlVault 1/2/3 over time; the talk focuses on ControlVault 3 (and notes newer variants were also vulnerable)

Key reverse-engineering insight: debug symbols leaked for Linux driver

• A major enabler: a Linux shared object/library used to talk to the device contains debug symbols.
• This allows:
  • Importing binaries into IDA with much better symbol resolution
  • Viewing/understanding firmware command sets and interfaces
• Philippe demonstrates:
  • Importing with IDA and exploring:
    • exported functions matching command calls
    • local types and command dispatch definitions
  • Exporting IDA-generated artifacts (though not perfectly reusable across instances)

Initial “attack surface” selection methodology

• Philippe looks for “red flags” such as:
  • Missing ASLR on certain components/services on the host side (easier exploitation)
  • Signs of technical debt (reducing modern mitigations)
• He distinguishes manual reversing vs. fuzzing teams—he prefers manual reversing, especially for encrypted/obscure targets.

Communication model (host <-> firmware) and command interface

• Firmware exposes a command system where host code ultimately sends USB packets to the chip.
• Windows side:
  • Uses a kernel driver and then userland APIs (functions matching the “CV_*” naming pattern)
  • Calls include workflows like:
    • open session
    • send command
    • close session
• Firmware side:
  • A manager/dispatcher receives USB packets, extracts commands, and calls corresponding firmware functions.
• Demonstration:
  • Using symbol information and a small Python script, Philippe calls a function like “get system version” directly against the firmware.

Firmware security model: encrypted app vs. unencrypted boot image

• Broadcom secure boot concepts are discussed:
  • SBI = Secure Boot Image (a boot-room/loader extension loaded by the chip boot ROM)
  • SBI loads/decrypts application firmware.
• Critical research finding:
  • The application firmware is encrypted, but the SBI that loads it is not encrypted.
  • Reverse-engineering SBI reveals how firmware decryption works.

Decrypting firmware: what was done

• Philippe identifies strings like “upgrade decryption failed” and traces the decryption path in SBI.
• He reverse-engineers:
  • Where default key material is involved
  • How the IV/initialization vector is derived (described as nonstandard/messy)
  • How firmware update commands deliver encrypted blobs that SBI decrypts/validates
• Result:
  • Ability to decrypt the main application firmware and analyze internal command handlers.

Major exploitation theme #1: session/heap weakness → arbitrary free

Vulnerability concept (heap corruption via session forging)

• Firmware manages “sessions” backed by heap memory.
• CV_open returns a “handle” corresponding to a pointer/address in firmware heap.
• CV_close is expected to validate the handle, but validation is weak:
  • It checks whether the memory address lies in the right heap range
  • And whether a session tag (e.g., “SCSS”) exists at the beginning

Exploit idea

• If attacker-controlled heap data can be written, attackers can:
  • Forge a fake session object by writing the correct session tag at the beginning of a heap buffer
  • Call CV_close so it frees memory that was never a real session → arbitrary free / heap metadata corruption

How attacker-controlled heap data is obtained

• A command like “CV_create object” places data on the firmware heap (less control over metadata, but enough to forge/shape the heap).
• A helper like “CV_get random” acts as a “session oracle”:
  • It returns different error codes depending on whether the address/session guess looks valid
  • Helps locate the forged object within the heap range

Major exploitation theme #2: stack overflow via object copy (firmware R/W + stack smash)

• After gaining heap control primitives, Philippe targets another command:
  • “secure bio identify”
• It copies an object into a destination buffer where the copy length comes from an object size field.
• Research observation:
  • The destination appears to be a stack variable, so an attacker-controlled length can cause a stack overflow.
• Since the attacker can’t directly set the size through the initial object-creation path, they:
  • Use heap corruption to create overlapping heap objects
  • Reinterpret fields so the “size” used for copying becomes attacker-controlled

Resulting control of execution

• This enables control of execution (within the SoC environment) using:
  • no SLR
  • ROP-like chaining on ARM
• Philippe describes deploying gadgets with IDA-assisted scripting and manual reasoning.

Key leakage demo and secure boot weaknesses: SOTP/OTP key exposure

• Once code execution is achieved, Philippe demonstrates access to SOTP read key functionality to leak keys.
• Resulting keys include per-device keys such as:
  • AES key
  • HMAC key
• These keys relate to:
  • Encrypting firmware stored in flash
  • Authenticating firmware updates (via a secure code descriptor)
• Boot-chain security conclusion:
  • The chain heavily relies on:
    • OTP fuse-derived keys and secure code descriptor integrity
    • Firmware update-time signature checking
  • Philippe argues that even if app verification isn’t directly bypassed, compromising keys/descriptors enables persistent subversion.

Persistent firmware modification (“implant”)

• Philippe uses the device’s update mechanism to flash a modified secure code descriptor and related firmware content.
• Demo details:
  • An earlier attempt failed due to endianness mistakes in flashing the descriptor structure
  • After correcting endianness, the modified device shows persistent changes (device manager shows a changed identity string)

Persistence behavior

• Survives OS reinstall
• Persists until legitimate firmware is re-flashed onto the board

Impact demo: bypass fingerprint authentication / force “always match”

• The talk includes a demo conceptually modifying firmware so fingerprint identification routines invoked during login / Windows Hello can be forced to return “yes”.
• Hardware demo:
  • A fake finger (from prior Defcon) with organic material triggers the capacitive fingerprint sensor
  • The computer unlocks immediately when touched

Impact extension: Windows compromise via deserialization/type confusion/backdoor command paths

Host-side weakness (marshalling/decapsulation trust)

• Windows host expects structured replies (TLV with encapsulation types like “length-value”).
• Firmware also indicates encapsulation type for returned data.
• Firmware can redefine the encapsulation type so the host decapsulates/allocates buffers incorrectly.
• If the host trusts returned encapsulation/size info:
  • type confusion
  • and potentially memory corruption when returned lengths don’t match expected types

Backdoor strategy example: “CV_get random”

• Philippe modifies firmware so that only when called with a special size/parameter, it returns a malicious payload instead of legitimate random data.
• The payload targets the Windows-side vulnerable deserialization path, culminating in code execution.

Additional host exploitation: system service path (Windows Hello / biometric service)

• Philippe targets a Windows biometric service (“SVC host”, Windows Hello integration).
• A Broadcom storage adapter interface is reachable from Windows when biometric hardware is present.
• Firmware backdoor returns a malicious payload for a specific object handle, corrupting Windows service stack state:
  • overflow of object header
  • enabling ROP and a reverse shell (ncAT demo)

Physical attack scenario: direct board access bypassing OS login

• An “evil maid” style scenario is described:
  • Split the internal USB connection to the ControlVault board
  • Attach another computer to interact with the device firmware/commands without OS credentials
• Conclusion:
  • Physical access alone can be sufficient to compromise and implant firmware

Mitigations (post-disclosure)

• Philippe mentions mitigations implemented by Dell/Broadcom in firmware updates:
  • Removing unused/less-needed command paths and functionality
  • Tracking valid handles to prevent the forged-session arbitrary-free approach
• Suggested user risk reduction:
  • Disable the device in Device Manager if not needed
  • Updates are pushed via Windows/driver update mechanisms (though older/unupdated devices may remain vulnerable)

Key reviews/guides/tutorial elements mentioned

• Practical reversing workflow:
  • Using IDA with symbol-rich drivers (debug symbols in Linux .so)
  • Identifying firmware decryption routines via strings and function pointers
  • Loading raw blobs in IDA by determining correct ARM load addresses (reset-vector / absolute address tables)
• Practical scripting/demo methodology:
  • Using Python bindings to call firmware commands via exported C/CV prototypes
  • Using heap/object commands to build exploitation primitives

Main speakers / sources

• Main speaker: Philippe Laulheret (Cisco Talos)
• Primary referenced systems: Dell ControlVault secure SoC (Broadcom 58202 mentioned), Cisco Talos writeups, Broadcom firmware components, Windows/Linux driver interfaces