Xbox 360 Architecture

The Xbox 360 was subject to the same needs and fashions that the PlayStation 3 went through. So the former offers many services, including online gaming (through Xbox Live), a digital marketplace, media player, file system explorer (albeit extremely simple) and other utilities.

Overview

The Operating System of the Xbox 360 is a collection of bare-metal utilities and userland applications tightly squashed together to fit into 16 MB of NAND. Just like the PlayStation 3, Microsoft built their OS to provide multimedia and networking (i.e. multi-player) capabilities, plus the ability to play games and secure the system from external intrusion.

That being said, the system contains a few core components that take care of the low-level area of this console (hardware access, security and resource management). The rest is composed of applications (i.e. the splash animation, the interactive shell called 'Dashboard' and the game itself) and user data (i.e. game saves, user profile, network settings).

A tumultuous progress

Throughout the life of this console, I noticed a more chaotic evolution than its competitor, which involved constant re-branding and radical redesigns of the user interface. I presume Microsoft was trying to shift from one target audience to another. So, to understand this section better, I've organised its evolution into these periods:

• The multimedia hub era (2005-2008): as the first home console to debut in the 7th generation, high-definition graphics, Xbox Live (online platform) and HD movies were the main selling points. And in the case you got bored with them, you could resort to buying accessories (i.e. the remote controller, the headset, the HD DVD reader) to 'enhance' your experience.
• The competitive era (2008-2011): with the PlayStation 3 and the Wii now occupying store space, Microsoft found itself in need to aggressively compete for the consumer's attention. First, a new system update called 'New Xbox Experience' overhauled the old interface to increase user personalisation (i.e. 3D avatars) and enhance the social aspect of this console. Meanwhile, a new 'killer app' lands in the form of a physical accessory: Kinect. Nobody knows its outcome, yet it proves a very engaging topic of conversation.
• The cloud era (2011-2013): as all the previous enthusiasm slowly dissipates, Microsoft simplified its user interface to align with its other platforms (Windows 8 and Windows Phone 7) and provided users with the chance to move their local data to the cloud (a.k.a Microsoft's servers). In the process, third-party advertising became more prominent in the user interface (possibly to increase their source of income). Nonetheless, users are now expecting the successor of the Xbox 360.
• The capitulation (2014 onwards): with the new successor (Xbox One) reaching the stores, Microsoft dedicated minimum efforts to their (now old) console. Users will only receive system updates in the form of bug fixes.

A recallable security design

If you recall my deconstruction of the PlayStation 3's operating system, the latter was divided into three areas:

• The Hypervisor, which has complete control of the hardware.
• The Kernel, interfacing user programs (mostly games) with the hypervisor, and in doing so it provides an extra layer of protection.
• The user space, encompassing all programs executing on top of the kernel, including games and other apps (i.e. the shell and media player).

This design is correlated to the PPU's privilege levels (affecting both Cell and Xenon) which prevents 'casual' applications, like games, from accessing sensitive resources, such as decryption keys.

IBM enacted three privileges (instead of just two) to allow multiple operating systems running at the same time. With this idea, each OS would only live under the two lowest levels while the highest level would be reserved for the program supervising all operating systems. In practice, the PlayStation 3 and Xbox 360 only require a single operating system (except for OtherOS, but that was quickly scrapped). Consequently, Sony and Microsoft designed a hypervisor that enforces their respective security model and performs memory management tasks. Conversely, the architectural differences between Cell and Xenon led to very distinct implementations of hypervisors, so each is subject to unique flaws and strengths.

Diagram showing how the components of the Xbox operating system fit in Xenon's privilege levels.

The most notable difference between the security model of the Xbox 360 and the PlayStation 3, is that the former runs both the Kernel and user-space programs under the same privilege mode (the second level) . So, all critical tasks rest within Hypervisor, which enjoys extra acceleration from the hardware side (I'll explain more about it in the 'Anti-piracy' section).

Architecture

Let's take a deep dive at the operating system's main components, note this doesn't include the boot loaders, but for that, I've dedicated a separate section. For now, we'll check the components that reside in memory after the console boots up.

The Hypervisor

The Hypervisor is an incredibly small program that only occupies 128 KB . Furthermore, by being assigned the highest privilege level available, it's tasked with:

• Preventing programs from accessing areas beyond the permitted boundaries.
• Combined with the use of page tables, it restricts which areas of memory can be executed by the CPU. This technique is called Write Xor Execute or 'W^X'.
• Encrypting executable code.
• Refusing to load executables that aren't signed by Microsoft.
• Protecting memory data from being tampered with. This is done by encrypting the data in main RAM and decrypting it just after the CPU fetches it from L2 cache.
  • This is a complex but interesting feature which is explained further in the 'Anti-piracy' section.

The hypervisor is operated through the use of 'system calls' , external programs invoke these to request functions from the hypervisor. Though whether the hypervisor complies or not is a matter of the program's accreditations.

The Kernel

Since the Hypervisor focuses on bare-metal services, an extra layer of abstraction is added in the form of a Kernel. The latter also resides in memory but gets assigned a lower privilege level. The main job of the Kernel is to expose routines that userland programs can benefit from, for instance:

• Device drivers: in essence, I/O is interfaced by the Kernel so programs are not hard-coded to specific hardware (resulting in platform-dependent code), which would prevent old games from working on late Xbox 360 revisions.
• File system management: a file system defines how data is organised in a physical medium, the Xbox 360 supports many types of media and the Kernel implements various file systems for each one. This enables programs to manipulate persistent storage using files and directories and not raw sectors.
• Bootstrapping core applications: once the Kernel is up and running, it makes sure that the user interface and other executables are running, allowing the user to interact with the console.
• Thread scheduling: remember the previous paragraph about programming styles? Well, the thread scheduler is found here. Furthermore, the scheduler implements preemptive multitasking as its method for alternating between threads and avoiding jams.
  • To balance performance across all running services, the scheduler applies some constraints. For instance, the fourth hardware thread is reserved for the audio pipeline and software downloads; and the second hardware thread is prioritised for concurrent file system operations.

To work, the kernel reserves 32 MB from main RAM to allocate all of its resources.

The User land

Userland programs encompass any executable running on top of the kernel. These are found in the form of a special container called Xbox EXecutable or 'XEX' ; and follow a similar structure to the traditional EXE container used by Windows - albeit tailored to the specifications of the Xbox 360. The most important difference is that XEX's executable code follows the PowerPC ISA binary structure (instead of x86) and it must be encrypted to run (the code is signed with Microsoft's private keys and the headers/meta-data store a hash to prevent tampering).

From the boot animation to the game itself, everything is a distinct XEX file. Some are automatically loaded by the Kernel (the boot animation and the interactive shell) and others by the user (the game, the media player, etc) using the shell. When the user or the Kernel request to run a XEX, the Kernel copies it to main memory and the Hypervisor checks its signature, re-encrypts it, marks the area as 'executable' and finally instructs the CPU to run it .

While this console doesn't provide any fancy multitasking between games (which is not a priority for a console, in my opinion), the Kernel still takes the aforementioned 32 MB of main RAM as its working area. This is what makes it possible to open the Xbox Guide (that popup menu that shows up after pressing the 'Xbox logo' button on the controller) and/or play music mid-game. To switch between full-screen applications, the Xbox Guide contains an entry to return to the dashboard (loading it up again) so the user can select another program.

Finally, all user data is grouped into a virtual Profile. Thus, the Kernel runs another program called 'XAM' which provides profile-related services (achievements tracking, avatar selector, save data storage) . A new profile is set up upon powering the console for the first time and there can be more than one profile stored.

Backwards compatibility

As a compelling side note, the Xbox 360 can run a considerable subset of games belonging to the previous Xbox (to avoid confusion, let's call it the 'classic' one). This was done through pure and hard software emulation and, while it didn't provide the same degree of compatibility of the CECHA PS3 revision, I believe the methods were more clever, cost-effective and consistent.

The emulator was called 'FU' (found as xefu.xex) and it could only be installed in the Hard Drive, residing next to other optional assets for the operating system. FU loads every time the user booted up a classic Xbox game into the Xbox 360. However, for an 'enjoyable experience', FU only proceeds with the emulation if the game is listed in its local whitelist, where Microsoft tracks which games are deemed 'playable'. As more system updates were released, more games were added to the whitelist.

Michael Brundage, one of the authors of FU, described the development process as 'probably the hardest technical challenge of my career' and also mentions 'how inefficient most standard libraries are, especially at math.' .

Storage medium

Now that we've seen the structure of the OS, let's now check how information is scattered across this console. You'll soon find that there's an abundance of media available, and Microsoft had to devise different file systems and protocols to keep the security integrity in place.

Boot ROM

Here lies the most critical and fragile program of this console. Similarly to the PlayStation 3 (again, both share IBM technology), the Xenon hides 32 KB ROM that stores the first stage of the boot loader, along with Microsoft's RSA public keys and SHA-1 hashes used to decrypt and validate further boot stages, respectively .

This area happens to be unencrypted, as the security system is not set up yet and the CPU only understands unencrypted machine code, but it's not a concern for Microsoft since the boot ROM is sealed within the CPU die and the public key can't be used against the system. Although, being a 'ROM' also means that this code can't be patched after it leaves the factory.

In any case, the boot ROM is only executed once after the console is powered on.

Internal NAND

The NAND chip

In the motherboard of every Xbox 360, you'll find a NAND Flash chip. This is what Microsoft uses to store :

• The remaining boot loaders after boot ROM.
• The Hypervisor and Kernel.
• System updates (in the form of delta patches for the Hypervisor and Kernel).
• Userland programs (i.e the splash screen, dashboard, XAM/profile manager, media player, etc).
• Console-unique information like serial number, region and unique encryption keys used for a variety of operations. This area is also known as the 'Keyvault'.
• Configuration data read by the System Management Controller (that tiny computer inside the Southbridge) which includes calibrations for thermal control. This is also referred to as 'config block'.

All of this data is encrypted in a multitude of ways. The majority uses Microsoft's private key combined with others, which makes it quasi impossible to tamper with, in theory!

Contrarily to the PS3, Microsoft managed to fit all of this in a smaller 16 MB chip, although some revisions from 2008 and 2009 featured 256 MB and 512 MB NAND chips . This wasn't a breaking change, however, as the extra space was partitioned and treated as a Memory Unit instead.

Memory Units and HDDs

Memory Units, the least expensive storage medium. Although, they only work with Xbox 360 revisions before 2010.

External HDD. Sold as a separate accessory and bundled with 'premium' editions. Inside the case there is a conventional 2.5" hard disk connected to a data & power adapter.

Internal HDD, an alternative packaging for the Slim models (2010). The case is fitted into a hidden slot and doesn't require any type of adapter (its only purpose is to prevent wobbling).

If you place the console in a vertical position, on the front you'll see two 'Memory Unit' slots. On the top of it, you'll find a modified SATA socket for a hard drive (only fits those encased and sold by Microsoft). Both of these media are optional and used as mass storage devices.

Upon fitting any of them, the Xbox 360 initialises it and adds a multitude of partitions. Though it doesn't write a master partition table! It turns out the locations (offsets) of each partition are already hard-coded into the Kernel and all partitions - except the one storing user data - are fixed in size. Additionally, every partition uses proprietary and undocumented filesystems (recall that this is coming from the company that co-authored FAT, NTFS and exFAT), including one called 'FAT Xbox' (FATX) for generic data and 'Secure Transacted File System' (STFS) for caching purposes .

As long as there's space, either medium can store user profiles, game saves, downloaded games (initially called 'arcades') and downloadable content (DLCs). Only the HDD can store the Xbox classic emulator (the console automatically downloads it after a classic disc game is inserted).

Microsoft sold Memory Units of up to 512 MB and hard drives of up to 500 GB . You may think "Well, what if I swap the hard drive inside the case for a bigger one?" but that's been predicted, as all hard drives sold by Microsoft embed a Security Sector partition that prevents users from using third-party hard drives . This block encodes unique properties of the hard drive (serial number, model number, size, etc) that the Kernel compares with the hard drive's metadata, along with a bitmap of Microsoft's logo (to mitigate distribution with the use of trademark laws) and an RSA signature (to prevent third-parties from crafting their own security sector) . Although, some users eventually found workarounds by manually overriding the hard drive's metadata .

External USB

Typical USB stick .

In April 2010, Microsoft conceded to the invasion of the cheapo USB sticks (which already conquered every household) and released a software update that allowed to use USB drives in the Xbox 360, as a method for expanding storage space.

USB drives can store most of the content located in hard drives (including games) except the Xbox classic emulator. It's fair to say that the theoretical bandwidth of USB 2.0 (480 Mbit/sec or 60 MB/sec) is no match for the internal SATA I protocol (1.5 Gbit/sec or 187.5 MB/sec), but having an extra storage option is always appreciated.

Behind the scenes, USBs are formatted with the popular FAT32 filesystem. Now, the Kernel also adds a hidden folder storing blobs that contain FATX-structured data , which is where Xbox 360-related data resides. This design enables the console to maintain its security requirements within an 'insecure' medium, albeit at the cost of only accessing up to 16 GB from the USB drive .

Boot process

Okay, so you've seen how this system works, how it's structured and where it's stored. But, there's still a missing piece, how do you go from 'nothing' (off state) to a 'Hypervisor running an encrypted Kernel loading up executables signed by Microsoft'? That's what the boot loader is for, and there are many, many stages in this system.

Multicore chaos

Before we begin, we need to address something fundamental. With homogeneous multi-core CPUs, all cores are entitled to 'own' the system, but this would only lead to chaos, so only one is tasked with directing the rest. The leader is commonly called 'master core' while the rest are named 'slave core' or just 'core'.

Outside the Xbox world, this hierarchy is sometimes found hardwired into the chip, while other architectures need manual intervention. For instance:

• On ARMv7, all cores wake up at the same time and look for the same reset vector (0x00000000). Thus, the program, now running multiple times, must make each CPU query its mpidr register to identify what type of CPU (master or slave) it's running from. After this, it can take appropriate action (i.e. give orders or wait for commands) .
• With x86, the first core is the master one. Thus, the first core starts at 0xFFF00000 while the other cores are 'asleep'. The master then sends an interrupt to the neighbouring cores with an arbitrary address directing them where to start execution.

In the case of PowerPC, well... it's a tricky situation because Xenon was a custom order and not part of IBM's PowerPC 2.02 spec. But by looking at some low-level homebrew source code for this console , I presume the boot handling is similar to x86.

Boot procedure

With all being said, I will now describe what the Xbox 360 does after the user presses the power button.

First things first, the reset vector of the master core appears to be 0x80000200.00000000 , this points to a secret location within the CPU: the aforementioned 32 KB of BootROM, where the first stage of the boot process is located.

For the sake of completion, there will be a tiny mention of a special device called 'eFuse'. This is another storage medium similar to ROM or RAM, but with distinct physical qualities. I'll talk more about it in the 'Anti-piracy' section to avoid overwhelming you, so for now, just remember those basic facts.

Without further ado, here is how the boot chain works. It all begins with the boot ROM and proceeds as follows :

1. 1BL (as in '1st Boot Loader'): The master core is instructed to fetch the next stage (called 'CB') from NAND into the internal SRAM. CB is found encrypted with the RC4 algorithm. So, the CPU derives a decryption key using a key stored in 1BL and another stored in the header of CB. Once decrypted, the CPU checks its validity by hashing the decrypted area and comparing the resulting hash with another stored in CB. The latter also uses Microsoft's public RSA key, stored in the internal ROM, for validating the hash. Finally, if the whole process completes without problems, the CPU continues execution at CB, otherwise, the CPU triggers a POST error and the Xbox 360 starts flashing red lights.
   • This process involves a combination of many cyphers, such as HMAC, SHA-1 and ROT.
2. 2BL or CB: The CPU, now executing from the internal SRAM, queries the eFuses to check that the version of CB running matches the one written on the eFuses. Then, it initialises most of the hardware. Finally, the CPU proceeds to fetch another block from NAND called 'CD' onto main RAM and repeats similar decryption and verification tasks 1BL did, this time using another key derived from the 'CPU key' (stored in the eFuses). If everything goes well, the next stage proceeds.
   • In later software updates, this process was split into two bootloaders (named CB_A and CB_B) to mitigate faults that were exploited to execute homebrew (more details in the 'Anti-piracy' section).
3. 4BL or CD: This is another decryption stage, albeit closer to the actual payload. This time, the CPU fetches yet-another block called CE, which goes through familiar verification processes (involving RSA checks) and it's subsequently decompressed in main RAM. Once unpacked, the CPU finds itself in front of the Kernel and the Hypervisor. But it's not over yet, I'm afraid, as the CPU must now fetch system updates to apply to these two programs, a process known as CF. Before continuing, however, CD orders to compare the number of updates installed against a designated counter in the eFuses block. This is done to prevent downgrades.
   • The decompression algorithm used is called 'LZX Delta' and it's authored by Microsoft.
4. CF: This stage takes care of fetching update blocks stored on NAND, these are decrypted and decompressed with LZX as well. Once they are ready, they are applied to the kernel and the hypervisor residing on main RAM. Once all updates are done, CF returns to CD.
5. CD (upon return): Now that everything is set, the CPU is redirected to the Hypervisor in main RAM.
6. Hypervisor: This program takes over the hardware and then redirects execution to the Kernel, which in turn loads up the Splash animation and the Dashboard.
7. The user is now in control.

Updatability

I guess it's no news for you, but yeah, this console has an updatable operating system.

Though, it may surprise you that no matter the revision, all consoles ship with the same initial kernel (version 2.0.1888) from 2005 . What happens is that the software updater installs 'update packets' in NAND, in the form of delta patches, and these are applied during boot, as you've seen in the previous section.

Old Xbox interface from 2005 installing an update (bye bye Blades).

Updates can be fetched from Xbox Live (as an online download), through a retail game, by burning a conventional CD (that's how we shared files before the 2010s); or through a USB stick. A typical update will install the aforementioned patches for the hypervisor and kernel, but it will override userland files like the dashboard. Finally, to prevent rolling back, the updater will finish by blowing an eFuse so, from now on, the Xbox will only be able to boot the updated version of the system.

Updates don't usually require extra storage. However, when Microsoft released the 'NXE' update in 2008, the updater also installed static resources onto the Hard Drive (mainly themes and assets for the new 3D avatars) as NAND wasn't big enough. This led Microsoft to increase the size of NAND in further revisions of the motherboard to bundle up to 512 MB of NAND, and later include internal memory units of up to 4 GB instead. You would only find these enhancements on hard-drive-less models.

Interactive shell

I think it's time to take a break from so much theory and go over the different graphical interfaces that this console underwent. I know this is an article about computer architecture, but user interfaces are as important as all the fancy hardware we've been discussing. Also, user interface patterns go hand in hand with my interest in hardware!

In the following paragraphs, you may sense that I'm very critical of each interface, but I think it's important to correctly identify the strength and flaws of each design so we can understand the reasoning behind its next iteration.

The 'Blades' dashboard (2005)

The home screen, the controls are shown on the centre, while the horizontal edges indicates the existence of other blades to navigate to.

List of games installed, previously downloaded from the Xbox Live Arcade (a digital marketplace). Notice how this is a full-screen view, as there wasn't enough space on the previous type of screen.

Settings menu.

Storage menu, enabling the user to delete or copy user-only content. Notice how it removes the other blades indicators to reclaim a bit more screen space.

A simple avatar selector screen.

Pressing the guide button (a.k.a Xbox logo on the controller) for a long period would bring in the 'Xbox Guide', a popup menu offering various shortcuts.

The first iteration of the user interface, now an element of nostalgia for some, was the Blades dashboard. Here, each group of services (game, multimedia, settings, etc) is organised into different overlapping layers called 'blades'. All share the same hierarchy level and focus, meaning the user can only open one blade/category at a time. To navigate around, the user must swap between blades and interact with the actionable controls placed.

In my opinion, this style reminds me of one of those brochures with eye-catching foldable designs (in fact, the manual that came with the console replicated this). Furthermore, the design language (typography, colour palette and blur effects) is somewhat relatable to Windows XP and its Media Center pack, even the first iterations of Windows Longhorn exhibit common traits.

Windows Longhorn, Build 4015 (2003) . Before it became Windows Vista, Microsoft had experimented with many types of UI patterns and colours. This build, in particular, seems to share small peculiarities with the Blades design.

The Media Center app, included with Windows XP Media Center Edition (2005). This edition of Windows XP bundles an extra set of apps that target the TV, as opposed to the PC.

Truth be told, the overall design was strongly compromised to comply with both 4:3 and 16:9 aspect ratios, without being able to take advantage of the latter. The organisation of elements wasn't very consistent either, as some views, like the Xbox Guide, felt like all controls had to be squashed into a small space. The most limiting aspect, in my opinion, is the fact the indicators for navigation (list of available blades) were always shown on both edges of the screen. This consumed useful space for the opened blade. Thus, exceptional navigation segues had to be used to move away from the home screen hierarchy and reclaim full-screen space, at the cost of adding more inconsistency to the user interface.

Nevertheless, this is the GUI that gave this console an identity, and it's obvious that it targeted the 'young' audience group, which worked fine for a few years.

The 'New Xbox Experience' (2008)

The new home menu. Notice how the user can't see all elements available unless he/she scrolls.

As the Xbox Live expands its repertoire, many types of applications can now be installed (not only arcades anymore).

The settings menu keeps the same layout but inherits a new colour palette.

The storage menu and its similar palette update. In this example, a custom background has been set by the user.

2D avatars are still available, though users are now encouraged to define their own 3D avatar too. This will be used by games (à la Nintendo's Mii).

As a nice tribute, the new guide menu resembles the old Blades design, which also helps provide more and better-organised shortcuts.

As Microsoft expanded its catalogue of services and features, the navigation pattern of the blades turned into a liability (as it constrained the number of navigation screens on the top hierarchy) and the lack of available space became apparent in later software updates. In 2008, Microsoft released a revamped Dashboard interface called New Xbox Experience (NXE) which focused on 'infinite scrolling' patterns to offer a wider selection of services on the front page. It also incorporated other elements like a glossy filter and 3D transitions recently popularised by Windows Vista and the new range of Windows Live applications.

Windows Vista (2007). Showing the use of the iconic 'Flip 3D' to switch between windows.

Windows Live Mail during 2008 , featuring a Vista-like theme with glossy effects.

With the new design, screens could now enjoy full-screen space without being conditioned by the hierarchical level they were placed in. Curiously enough, the navigation layout is very similar to what Sony designed with XMB, where vertical arrows change category and horizontal arrows navigate through the elements of the same category.

The 'Kinect' update (2010)

The new home screen built for Kinect controls. Notice how the container at the bottom right corner indicates what Kinect is capturing at the moment.

The Game Library gets a brighter colour scheme.

The Settings menu with minor changes applied.

The same goes for the Storage menu.

3D avatars get some enhancements as well.

The Guide menu goes through a minimalistic phase.

With the arrival of Kinect, Microsoft had to adapt the Dashboard to remove its dependency on the controller. As part of the update, the designers replaced the glossy touch with faded greens and greys. The 3D aero-like touches were also succeeded by typical zoom-in animations. This coincides with the arrival of Windows 7 and its modest reduction of visual effects.

Windows 7 (2009). Showing the new 'Aero Peek' to preview minimised windows.

Windows Live Mail during 2011 , part of a desktop suite called 'Windows Essentials'.

I don't think there's anything else to mention apart from the fact it only lasted a year before being replaced by a considerably more radical redesign.

The 'Metro' revamp (2011)

The new home screen, where news, advertisements and applications share equivalents amount of screen space. Some types of information (like adverts) are granted more space than what the user would agree.

The new app selector resembles a retail shelf.

The Settings menu hasn't changed much.

The same applies for the Storage menu.

It seems the minimalistic phase is here to stay.

The year 2010 saw the debut of Windows Phone 7 and a new type of interface called Metro, whose style now relies on solid colours and white silhouettes. Due to its versatile design, Microsoft envisioned porting Metro to all of its platforms, which became a reality the following year with the arrival of Windows 8 and a new update for the Xbox 360. Though the degree of adoption varied drastically between device, the Xbox 360 enjoyed a mostly unified implementation of Metro (unlike Windows 8, where the majority of applications still relied on the 'classic' design).

Promotional screens of Windows Phone 7 (2010), showing the new Home screen, the contacts app (featuring the new 'Panorama' layout) and the lock screen.

The most significant changes lie in the home screen, which has reverted its two-dimensional navigation style for a new multi-row distribution called 'Panorama'. The latter borrows similar navigation patterns to the old Blades dashboard, except the new layout does not repeat the same mistakes. Icons now take prevalence over labels, and their uniform shapes lead to a more apathetic composition. But hey, at least the layout is now consistent across all home screen views (although I must confess I miss the unpredictability of previous eras).