daniellmcguire/xboxseriesPersonal research into the Xbox Series Architecture
| Field | Value |
|---|---|
| Date | March 9-12, 2026 + July 7-?, 2026 |
| Hardware | Xbox Series S (Codename: Lockhart) |
| OS Build | 26100.7010.amd64fre.xb_flt_2602ge.260212-1010 + 26100.8561.amd64fre.xb_flt_2606ge.260609-2200 |
| Access Method | Dev Mode + SSH + REST API + NTFS file share junction |
This report is a static and dynamic analysis of the Xbox Series S internal architecture, conducted entirely through Microsoft's official developer mode infrastructure. No exploits or policy violations were used; all access was within the bounds of the individual developer program.
This contains details from the highest level components used for gameplay, down to the lowest level system driver components. Most of these details are expected to be the same for the Xbox One as well.
AI was used for consistantly formatting the large initial research (over 200 analysis outputs and over 50 random notes) into this really fast. All future edits are done by hand.
If you think any point of this is unclear, underdocumented, or false feel free to DM me, or if you have any answers to my questions (in Section 12) that would be nice too. GUIDs and other common patterns are redacted in a pre-commit hook just in case I leave anything that identifies my account.
A lot of what I am working on is assumptions, so it might be inaccurate, and will change as I get more info and look into more binaries.
For reasons you might assume I will not under any circumstances share direct binaries, disassembly output, or anything considered IP of Microsoft or it's subsidiaries.
ERA = GameOS Partition
SRA = SystemOS Partition
HT = Kinect (possibly "Human Tracking"?)
Arden = Xbox Series X/S GPU Stack
NewBe = Arden shader compiler
a Host OS management of drivers exists outside the known SRA/ERA model, see trust model (Sections 4.2, 17.5). XVIO.SYS and XSraFlt.sys are loaded directly by the hypervisor (via HostOS) before Windows initializes and are absent from all accessible volumes. They cannot be tampered with even under full kernel access which is the primary security boundary.
HVCI is deliberately disabled (Section 18). IsSecureKernelRunning = 0x0 confirms the Secure Kernel (VTL1) is not running. Code integrity is load-time only, leaving a TOCTOU window once binaries are mapped. This is a deliberate performance tradeoff; the security boundary is the hypervisor partition, not in-partition memory protection.
NTFS junction exposes the full SystemOS filesystem over the network (Section 1.2). A single mklink /J command from the SSH shell maps C:\ or anything else into the Device Portal file share, making every system binary readable remotely with no additional authentication beyond the dev mode PIN.
Cross-partition architecture is nearly fully mapped (Sections 4, 14, 26-28). The ERA game partition communicates with SystemOS exclusively through hypervisor-mediated channels: XVIO ring buffers for I/O, GPA translation for shared memory, HvSocket for IPC, and ALPC port sections for zero-copy framebuffer delivery granted by a parenting "Host OS".
Deploy:\ junction bypasses local access restrictions (Section 25). The Windows Update volume is only accessible over the network share (S:\Deployment\SoftwareDistribution\) due to some descrepency somewhere (maybe xrfssvc.exe?).
Most binaries just have description strings, I didn't know this until today as I was not using Windows for anything besides the actual connection to the Console. A lot of the time its boring (e.g. XVUH, XVMCTRL) but other times it's very descriptive (e.g. Durango Virtual XVNC Bus Driver, Xbox Remote File System Service).
All testing was performed on a single retail Xbox Series S unit in developer mode. Results reflect many builds, however I will eventually diff the builds and write it up. Findings may vary across hardware revisions (Series X, Xbox One) and firmware versions. Several kernel-level surfaces were not reachable: live kernel dumps are blocked by the NoKernelDumps restriction, and the xvmctrl.sys IOCTL surface was not fully enumerated. Open questions are tracked in Section 12.
| Tool | Purpose |
|---|---|
| Windows Explorer | Xbox network share (Instructions at https://XBOX:11443/#File%20explorer > Browse) |
SSH (DevToolsUser + VS PIN) | Shell access to SystemOS |
mklink /J | NTFS junction creation to expose drives over network share |
Device Portal (https://XBOX:11443) | REST API, file browser, process list, live dumps |
dumpbin /IMPORTS, dumpbin /EXPORTS | Static analysis of PE binaries over the network share |
| Python | Script to automate REST API |
| Phasor | Scripting runtime for use on the Console (copy over network share, ran via SSH) download here |
reg query | Registry enumeration from the SSH shell |
WdApp.exe | Package manager and ERA lifecycle control (command surface enumeration) |
WdConfig.exe | Console settings API enumeration |
| ETL trace analysis | Windows Update pipeline via S:\Deployment\SoftwareDistribution\ junction |
| Live process dumps | GET /api/debug/dump/usermode/live?pid=<pid> |
| Ghidra | Analysis of COM interfaces / drivers |
| IDA Pro | Call graphs of complex DLLs and COM interfaces |
| XboxTools | My own collection of utilities for various things |
Access was established via the undocumented (officially, but there is community docs) Dev Mode SSH interface. The NTFS junction technique (Section 1.2) extended read access from the D:\DevelopmentFiles scratch space to the full C:\ system volume and all additional letter volumes. All analysis was read-only; no system settings were modified (WdConfig.exe set was not used). Xbox can run standard x86_64 Windows console binaries (compiled with /MT) directly via the SSH shell, which was used to run analysis tooling locally.
Kernel dumps were not available: the NoKernelDumps Device Portal restriction blocks them on retail dev mode. User-mode live process dumps were available and used where relevant.
Xbox Dev Mode supports Visual Studio, this uses SSH:
DevToolsUserThe Device Portal at https://XBOX:11443 exposes a hidden NTFS file share to D:\DevelopmentFiles. From the SSH shell:
mklink /J D:\DevelopmentFiles\C C:\
This creates a junction point from the developer scratch space to the system C: drive root, exposing the entire SystemOS filesystem as a readable network share at:
\\XBOX\DevelopmentFiles\C
This allows running tools like dumpbin from a PC directly against Xbox system binaries over the network.