Simply send pull requests to https://github.com/XboxOneResearch/wiki
The bootslot is determined based on whether or not your console was started in Developer Mode or Retail, which will set the target bootslot for booting up. In practice, there are two slots - known as Bootslot "A" and "B" - with a third slot, Bootslot "C", being reserved for use on internal devkits and their potentially unique update process. Dev Mode is mostly seperated from Retail mode. The Windows registry is built up dynamically into memory for each mode, the SystemOS partition (system.xvd) is mounted read-only from the flash, and settings are separated into settings.xvd and settings-devkit.xvd. It is important to note that developer mode and retail share very little to nothing with regards to their user or configurable files. It is configured at the lowest level by the hypervisor, which determines what your console can and cannot do.
As the console is built with security in mind, the OS layers are separated in sandboxes. The system used is known as ''Hydra'' and is supposedly based on HyperV - with 80% of code written specifically for the use on the Xbox One gaming console. The base operating system is HostOS, which runs drivers to interact with the hardware and communicate with other OS layers to exchange data and commands. SystemOS or TitleOS/GameOS prepare data to render and interact with the user.
Correct. As briefly mentioned above, the Xbox One/Series platform makes use of multiple virtual machines and a Hyper-V fork. HostOS, the smallest of the operating systems with around a 90MB footprint, runs the Xbox Virtual Machines and interfaces directly with the hardware and hypervisor. Next is SystemOS, which runs all applications, such as the dashboard and guide, but also UWP games like Minecraft through expanded resources. In the case of XDK/GameCore games, HostOS starts the ERA VM and SystemOS starts several proxy related programs to handle passing controller inputs and video/audio. For XDK games, the legacy TitleOS is then booted on the ERA VM, while GC games use GameOS (once called GameCoreOS). It should be noted that all Xbox operating systems outside of SystemOS make use of the LNM Kernel fork.
YES! Basically every single thing is logged and transmitted to telemetry servers. In Dev Mode, it appears to be possible to deactivate those services manually. The telemetry data sent in developer mode will be more intense than in retail, due to the nature of capturing as much data in regards to the tool usage. However, being in a preview program will also increase the data being sent. The following script can be employed with an Administrator account in DevMode to disable and delete the telemetry services: https://github.com/xboxoneresearch/XboxDevModeBatchScripts/blob/main/removetelemetry.bat
Not a target of this project! While this is not in our own priorities, this will be subject to a future console exploit.
Named pipes / special kernel broker drivers are used to push data between the OS layers. ... The Xbox One is known to currently use a driver common on all OS VMs known as "XVIO" which appears to use shared memory ring buffers to communicate between the host and guest virtual machines.
The possibility of "escaping" the UWP sandbox that's originally targeted at homebrew developers is tempting and of course delivers a bigger potential for developers to port applications more easily. However, as the rendering is done in a non-Win32-conforming way, it is also a challenge to achieve displaying such Win32 GUI applications. See XboxUI for further info. Traditional Win32 rendering is very unlikely to be possible on SystemOS. Like Windows IoT, the System VM makes use of the win32kmin.sys windowing driver rather than the full win32k.sys or win32kfull.sys employed by Client and Desktop, which doesn't support rendering more than one window at a time. Microsoft has tricks to supplement this (which can be seen in cases of the guide and dash being open, etc.), however they are not known at this time.
Getting the keys to the kingdom is a topic that requires much more information and skills. The Xbox One uses the AMD Platform Security Processor (aka PSP), which appears to be designed specifically for Xbox-based security and other features, which initialises the boot chain and stores the key(s) in the fuses. However, it also appears that there might be certain content keys stored in the System Kernel Memory and also Host Kernel Memory, but this is hard to determine without comprehensive tools. Keys are are stored in "keyslots" and are loaded depending on the bootslot / bootmode. This means booting to developer mode just loads the developer keyslot, so retail keys won't be loaded and are not accessible for decryption.
There are at least two keyslots as far as we know:
- Retail (Green)
- Development (Red)
Note: There are currently two sets of Red keys, one of which is no longer used. The result of this split was likely a number of sensitive leaks over the years.
Different keys are used for the following purposes:
- Bootloader encryption
- Operating system container encryption (ODK / Offline distribution keys)
- Games / apps (CIK / Content integrity keys)
There are at least two major certificates utilized for generic usage: a Console certificate and a Boot capability certificate. Of course they are signed with an RSA key and therefore cannot be modified. For further info see Certificates.
A power glitch hack that made hacking the Xbox 360 feasible for the public was an unforseen technique that led to breaking the secure boot chain of trust Info. You could say that the designers of the console were not aware of this possibility. Obviously, techniques and mitigations evolved since that time, so it is a lot harder to pull off such an attack on the modern Xbox One console. It is expected to have a lot of mitigations implemented (for example: timing checks, excessive data validity checks, etc.)
Edge, while being a privileged UWP process, still runs in the usual UWP sandbox. Additionally, it is only allowed to communicate with the internet or local network if a valid Xbox Live connection is detected. This means that the operated console has to be running the latest mandatory system update - exploitation cannot happen offline / undetected.
This indicates that your SystemOS has bugchecked, and HostOS is in the process of making an encrypted crash dump before rebooting the VM. If you don't want to wait for the process to complete, unplugging and replugging your console to interrupt the process will not harm it.