Examine & Explore

A brief list and synopsis of each finding

Xbox Live API — Pulling at Low-Hanging Fruit

The Xbox Live API spans many sub-domains, but in this case we’ll be focusing on a few endpoints in particular:

profile.xboxlive.com, achievements.xboxlive.com, gamerpics.xboxlive.com

First, addressing the profile domain, we have a few paths that we can poke at:

Prior to the patch, it was possible to intercept any legitimate profile-settings POST request by performing MITM, modifying the userSetting to any valid value within the URL path (e.g., Gamerscore), matching the body request userSetting, setting the value to any valid integer, and your Gamerscore would update in real-time.

The PreferredColor path lets you set custom colors by posting a link to the corresponding JSON based on the primaryColor. For example: https://dlassets-ssl.xboxlive.com/public/content/ppl/colors/00000.json. With this in mind, you can intercept the request and post your custom colors to any valid URL, such as: https://pastebin.com/raw/eMs8kL4S.

These colors will appear on your end, but not for others, since the code-base expects to retrieve colors from their domain. If it doesn’t, it’ll default to green for everyone else.

As for ShowUserAsAvatar, this one was useful for the sole purpose of custom gamerpics. Within the avatar editor app, particularly the original one, you're able to take a picture of your avatar. You could simply then intercept that request, and swap in your own 1080x1080 PNG — Fiddler makes this very easy to do using the Composer tool. The newer version of the avatar editor retains the same functionality, and you can perform a similar sequence for the xblcustompicassets3002 domain.

  1. Drag the stock request into the Composer
  2. Use the "Upload file..." button to select any image
  3. Issue the request
  4. Reissue the PUT request from mediahub

The main caveat with this sequence is that you seem to get one use out of the manual upload. As far as I can tell, this works by abusing the "processing window" that's taking place on the backend, given that it has to happen relatively soon after the initial-legitimate request is sent.

Note: The mediahub PUT request will return 400, but the gamerpic change still occurs.

Regarding the Achievements domain, you can intercept any achievement unlock request, and swap in the ID for any other (typically just integers 0–100). The stipulation with this is that you’re restricted to the title token, so in this case, the XTI parameter that’s assigned within the token. Tread carefully.

SSH — Mishaps of Visual Studio Deployment

Devmode application deployment via Visual Studio utilizes SSH and requires a pairing pin for Visual Studio. The pairing pin can coincidentally be used as a password to SSH into the Xbox. Using something like PuTTY will work just fine for this.

Once you have this essential shell active, you can further your reach with the help of Junctions/Symlinks. Although the privs are quite constrained, you’re at least outside of the typical AppContainer. Utilizing any location not locked down by the XRO mini-filter, you can simply run mklink with the /J switch (allowed at this level of privs), and you’re able to freely explore every SRA partition.

XVDP — Diving Into the Treasure-Trove of T:\

Upon performing a system update, Xbox Virtual Disk (Patch) files used to be exposed to the Temporary partition (T:\), under a mount point with two A/B subfolders. The first mount point would contain the actual contents of updater.xvd itself, and the second would contain each of the patch files respectively.

These mount points and its files are still easily accessible through the mountvol utility. You can either assign said mount point to an open volume-letter, or create a symlink to its volume id. Notably, since both are mounted R/O, you'll have to get creative if you wish to subvert these or their contents.

If you wish to poke at the files yourself, eratools.xvdp will be the most fruitful, and extracting its contents is made easy with tools like binwalk or unblob.

UWP Apps — Leaving the R/W Door Open

Universal Windows Platform applications used to be easily accessible through the now disabled File Explorer, and with the help of symbolic link exploitation on a removable USB.

With this, you could utilize any sort of File Explorer app to browse through volumes 0–100, and eventually find the mount point for your active application. Files & Folders in particular made this a breeze as it would resolve the sub-folder count for each volume. Since these applications were mounted R/W, you were able to completely change its contents, however you would need to have it reprovisioned. Performing a factory reset was a common way to accomplish this.

This exploration also extended to XVC applications as well, such as Dev Mode Activation, but was inconsistent in terms of dumping its contents.

Devmode Gifting — Membership Stacking & Corruption

Starting out, lets take a quick peek at what differentiates the response from a normal RETAIL call:

"Conditions": {
"$type": "Microsoft.Marketplace.Storefront.Contracts.V3.AvailabilityConditions, Microsoft.Marketplace.Storefront.Contracts",
"EndDate": "9999-11-30 23:59:59Z",
"StartDate": "2019-07-03 11:00:00Z",
"ResourceSetIds": [
"XDKS.1"
]

Prior to the “patch” of removing the gift-button on the membership page, the ResourceSetId came back to the following value: “NONRETAIL” . As you can see, they’ve changed it to XDKS.1, essentially ending up with the same result for differentiating between the two.

As a result, when one redeemed this conflicting alternate SKU membership, whether through the store or through a gifted message from the Xbox Live Service profile, it would “merge” or overlap with your RETAIL membership, effectively corrupting your existing membership, disallowing any legitimate RETAIL-SKU redemption attempts as the stack conflicted.

The major issue with this overlap is not only the fact that your membership would effectively be “bricked”, but also the gifting availability. Since the membership was free to redeem with this specific SKU, you could essentially send as many as the API would allow (within the bounds of rate-limiting), trivially phish anyone, cause general havoc, etc.

Alongside this, paired with a certain inbox application and its capabilities, one could achieve RCE, thus making the gift masquerade as the Xbox Live Service profile extremely powerful.

You effectively have two ways of resolving this conflict:

It's worth pointing out that while it's problematic if you have an existing membership, it is quite the opposite if you do not.