Cursory Assessment of the Oculus Quest 2

PROBLEM

Standalone VR headsets like the Oculus Quest 2 are full Android computers — packed with cameras, microphones, motion sensors, and persistent storage — which makes them a rich attack and forensic surface. But that surface was largely unmapped. Before you can ask whether a device is exploitable, you have to know what it's actually made of, top to bottom.

APPROACH

A wide-breadth, stack-layered reconnaissance methodology: work every layer of the device to surface the widest set of feasible vulnerability vectors. Pre-stack OSINT (terms-of-service and privacy policies, FCC/FCCID filings, patents, and the LinkedIn/GitHub footprints of the engineers who built it); hardware (teardown photos cross-referenced with chip spec-sheets to build a component inventory); firmware (dump-and-emulate paths via JTAG/test pads, QEMU, binwalk); communications (Wi-Fi 6, Bluetooth 5.0, and the Link/AirLink streaming tether); operating system (a Meta-modified Android 10 on the Linux kernel, with its public kernel repo); and applications (the SDK and SideQuest sideloading). The framing idea: every design is carved from a limited space of the possible, so the negative space — the overlooked — is where the bugs live.

EXECUTION

I wrote the paper while in the latter half of my grad program. A new professor had started at the school; he was doing a data forensics class. Basically, how does law interact with code/computers? A lot of it was questionably CS, more like a Legal+IT class. But during it, I had to figure out a term paper. At the time, VR was still fairly hot. I got curious about RE, and more broadly INFOSEC. I made diagrams and sat down for hours thinking about all possible sources of information for a given device. I realized the OSI model was decent, but there were persons and legal docs surrounding a given device that could also elicit info. From a reverse engineering class I took late undergrad, I knew how to get dumps, and there I had also done partial development of my personal model. I had used privacy policy and terms of use for an APK+device to guess at what a device/the surrounding org was also up to, which was some sort of cryptocurrency scheme. It was a cool discovery.

For this paper, I focused on the Oculus Quest 2, and broadened my reading to FCC docs. It turns out that all devices with wireless emissions in the US have FCC records, and depending on how the manufacturer filed, the devices could have chips exposed by visuals from wireless testing. I also was able to do some spelunking on the public repo for the device, a legally required thing for Meta. Legally required because the OQ2 uses Android 10 as a base. Through leakage in the commit history, I was able to piece together parts of the build chain unique to the project. Through searching LinkedIn, I was able to target/identify people who worked on the project, and see what other tech they had worked on. It was a fun exercise, and at the end of the day, while the paper is mediocre, I learned a lot about sourcing different parts of information to form a coherent picture. This echoed what I learned in my first year of grad school while doing government work, that even disparate and small bits of info, for an outside actor, can help them fill in the blanks. Like a nonogram puzzle.

Some side things also surrounding that paper: I hung out with some undergrads who were super into hacking, and I learned a lot + was in the room when the group got on a Zoom call w/ the guy from the Darknet Diaries.

OUTCOME

A mapped attack surface: a chip inventory pulled from teardowns and FCC filings, an I/O inventory, and a set of concrete candidate vectors — potentially unencrypted Link/AirLink video streams, SDK-exposed motion data, the public Quest kernel repo, and OEM Bluetooth defaults. This reconnaissance became the foundation for my master's thesis on Quest 2 ransomware.

LINKS

▸ Read the paper (PDF)