[Segmentation Fault]

Feel free to check out my other work or follow me on social media in the links below.

[shinyquagsire23]

Apple Vision Pro has the same effective resolution as Quest 3…Sometimes? And there's not much app devs can do about it, yet.

Preface

This article is a partial-rebuttal/partial-confirmation to KGOnTech’s Apple Vision Pro’s Optics Blurrier & Lower Contrast than Meta Quest 3, prompted by RoadToVR’s Quest 3 Has Higher Effective Resolution, So Why Does Everyone Think Vision Pro Looks Best? which cites KGOnTech. I suppose it’s a bit late, but it’s taken me a while to really get a good intuition for how visionOS renders frames, because there is a metric shitton of nuance and it’s unfortunately very, very easy to make mistakes when trying to quantify things.

This post is divided into two parts: Variable Rasterization Rate (VRR) and how visionOS renders frames (including hard numbers for internal render resolutions and such), and a testbench demonstrating why photographing the visual clarity of Vision Pro (and probably future eye tracked headsets) may be more difficult than a DSLR pointed into the lenses (and how to detect the pitfalls if you try!)

I'd also like to briefly note, I am first and foremost an ARM64 simp, then a VR simp. Apple just happens to make the ARM64 VR headset with the best specs right now so it’s been fun to experiment with it, but I do also have a Quest 3.

tl;dr: See the bottom of the post for a tl;dr.

Part 1: An Apple VRR Primer

When everything is a memory bandwidth problem, Variable Rasterization Rate (VRR) is a great hammer

VR rendering is fundamentally a real-time task, and a lot of effort goes into ensuring that applications render at the display refresh rate. On the Meta Quest 3 and on PC, applications tend to manage timing expectations by lowering the render target resolution, often on-the-fly. On Vision Pro, both GPU compute and memory bandwidth is fundamentally controlled by the OS through VRR.

Variable rasterization rate rendering operates on the following key ideas:

Reducing the amount of fragments rastered, which reduces computation costs as well as the number of texture sampler reads. As a bonus, scene textures in low-rasterization-rate areas can also use mipmaps to avoid aliasing and further reduce sampling bandwidth.

Reducing the number of render texture writes by letting the compositor handle blending later

Reducing the number of render layer texture reads when the compositor unwarps the VRR texture

By contrast, techniques like variable rate shading only get the first benefit, but miss out on 2. and 3. above. And to clarify, an Apple VRR texture visibly compresses periphery detail in the texture itself—the center of the texture is always the fovea, or where the user is looking.

From https://developer.oculus.com/blog/how-does-oculus-link-work-the-architecture-pipeline-and-aadt-explained/. VRR operates on the same principle–the details of the dinosaur in the center are more important, so the texture physically has more space dedicated to the fovea.

On visionOS, every (on-screen) framebuffer is 1920x1824. The only exception to this rule is when capturing recordings with Reality Composer Pro, in which case the framebuffer textures become 3840x7360 (the width doubles, and the height quadruples). However, Apple has an additional ace up its sleeve with VRR: The rasterization rate map doesn’t have to cover the entire texture. Apple can dynamically adjust the resolution of every application in the OS on-the-fly, individually, without even swapping textures or viewports.

Notably, the Reality Composer Pro non-foveated captures don’t actually render at 40PPD, they actually render at an unfoveated 20PPD, and entire swathes of the 3840x7360 texture go completely unused.

(getting this info unfortunately requires extensive debugger shenanigans–best way to do it is `b CompositorNonUI`WBVRRUpdateRasterizationRateMapsHighResolution` and then messing with the struct in register X2).

At the OS level, this is handled with the following parameters, dictated to applications by wakeboardd (the visionOS layer manager): CompositorNonUI.framework receives a minimum PPD, a maximum PPD, two gaze angle vector2s (left/right eye), and an uncertainty vector2. These parameters are then constructed into a Rasterization Rate Map which defines how many pixels are dedicated to each segment of the physical viewport, with the full dimensions being determined by the maximum PPD and the confidence.

An approximation of a VRR framebuffer in texture space, and how it relates to foveation parameters sent by wakeboardd.

As an interesting side-note, the ability for MTLRasterizationRateMap to not encompass the entire texture size currently seems to be limited to private Apple-only APIs. It truly is a bit of an ace up Apple’s sleeve.

The two VRR modes of visionOS: FFR 26PPD and DFR 40PPD

visionOS has two modes it uses when rendering layers: Fixed Foveated Rendered (FFR) 26PPD [no eye tracking], and Dynamic Foveated Rendered (DFR) 40PPD [eye-tracked]. Most notably, applications rendering an Immersive Space with Apple’s designated Metal LayerRenderer are limited to the former, and cannot reach the full resolution of the headset. The only workaround to this is to use RealityKit, which does not have any such restrictions.

I recently added an experimental 40PPD mode to ALVR which severely abuses a combination of RealityKit, DrawableQueue and CADisplayLink in order to reach the maximum possible clarity for PCVR streaming by strapping head-anchored textured quad to the user, fed by off-screen Metal texture renderer. It works fairly well! Even if figuring out the precise head pose timing manually (using CADisplayLink’s vsync callbacks) was a bit of a pain. And unfortunately you also lose Apple’s compositor anti-nausea measures like spacewarp. But it works! And it enables some interesting mixed reality applications as well, since the alpha blending works.

Currently, Metal applications are given by wakeboardd a fixed foveation ranging from 5PPD to 26PPD, and a fixed gaze angle of 0x5 deg for each eye, with ±19.7deg uncertainty. So you’ve got about 40deg of 26PPD rasterization rate, and it tapers off down to 5PPD at the very edge. In theory, this is supposed to be the same PPD as the Quest 3, but in practice since the Quest 3 supersamples slightly (as they should) and renders a uniform 26PPD, the Vision Pro looks worse at “26PPD”.

For non-Metal applications*, applications are given a dynamic foveation ranging from 5PPD to 40PPD, and a gaze angle which follows the eye. By my estimations, the uncertainty is ±8deg, so about 16deg of 40PPD quality which quickly drops off.

The two PPD modes as viewed in-headset. Note that these images are slightly cropped and not quite to-scale.

When rendering FFR 26PPD Metal applications, it should also be noted that VRR is not limited to only applications: The compositor also applies eye-tracked VRR when compositing all of the application layers into the final framebuffer. This has the benefit of reducing the number of  texture sample reads slightly, if the gaze gets updated between the application’s render time and the compositor’s render time. The disadvantage is that layers are not mipmapped and may present aliasing artifacts after compositing. You can see this by rendering a black/white pixel grid in Metal: Despite being fixed-foveated, a small square will be visible where you are looking.

(If you can’t see it you might just have to take my word on it, but there’s a slightly darker spot floating around where I was looking)

As a final note before moving into the next section, since this will be pertinent later: Because every on-screen framebuffer is 1920x1824, this also means that another way to ~see what things would look like through the FFR 26PPD mode is by simply squinting your eyes so that the eye tracking is unavailable. If you have Pointer Control on, the eye tracking cursor becomes headlocked, and all content is rendered at FFR 26PPD.

Part 2: Building a benchmark tool for a post-eye-tracking world

Peering into Apple’s foveation with mipmaps

While attempting to shoehorn an off-screen Metal renderer into RealityKit, I discovered an interesting quirk with RealityKit’s DrawableQueue API (or rather, with VRR rendering in general). If you create and render a texture with mipmaps enabled, which mipmaps are selected for sampling depends on the rasterization rate of that portion of the view. Or in simpler terms, you can see exactly where your eye is looking.

With this in mind, I’d like to present my virtual monitor benchmarking tool I’ll be using: It is a simple RealityKit application which head-mounts a 28” virtual 1080p monitor, exactly 30” away from your view. And by uploading different colors to different mipmap levels, we can examine how much texture detail is being rendered to the displays for these exact viewing conditions, as well as investigate whether it’s possible for programmers to increase clarity.

In this test, I will be using KGOnTech’s 1080p white-on-black tuff test. All of KGOnTech’s patterns can be found on their website at https://kguttag.com/test/. I uploaded to the test pattern to the DrawableQueue MTLTexture under mipmap level 0, and the remaining mipmap levels are filled with a gradient from #FFFF00 (yellow) to #FF0000 (red). So any yellow rendered to the virtual 1080p screen comes from mipmap levels less than or equal to half the resolution of the 1080p test pattern (if the test pattern was present in all mipmap levels, like it would be in most applications).

From an initial glance, it’s notable that the texture has a hazy yellow hue right off the bat, indicating it’s doing some kind of blending from lower mipmap levels. While this may partially explain why it’s difficult to get clean, crisp lines on virtual displays displaying this test pattern, the real reveal is what happens when the eye tracking fails (for example, by squinting, blinking, or pointing a camera into the Vision Pro’s lenses):

It’s all mipmaps! More precisely, it’s all mipmap level 1, or half-resolution. This isn’t surprising at all–since every framebuffer in the OS is 1920x1824, fitting a 1080p display into a fixed foveation, without it lowering to mipmaps, would more-or-less require it to take up the entire field of view.

Even more importantly, however, we know for certain that the normal 40PPD rendering mostly doesn’t use mipmaps at all in the fovea (I'll get to that ‘mostly’ in a moment). Outside of clarity losses from lens distortion, other post-processing, and aliasing from the quad being slightly askew, we should be seeing all of those pixels reaching our eye. But attempting to view it without an eye present automatically kneecaps the resolution by half. If you’re not careful, at least.

Oops, all mipmaps!

…So, which mipmap heatmap matches KGOnTech’s photos?

As much as I’d like to take a victory lap and make assumptions, I know better than to not check my work. At first glance, it does match up more with a dynamic foveation than a fixed one:

Tuff test with eye-tracked foveation. Yellow is mipmap level 1, amber is mipmap level 2. Of note, there is a yellow haze in the fovea, and 1.5 columns on both sides are completely covered in half-res/quarter-res mipmaps. I tried my best to focus on the ‘3’ in ‘34’ but it’s surprisingly difficult.

But looking closer, there does seem to be one odd discrepancy, which is that box 11 should be ~¼ res, and box 12 should be ~½ res. But in KGOnTech’s photos, box 12 and 13 look virtually identical:

Boxes 11-13 zoomed in. The leftmost column is very blurry, while the columns to the right are at least somewhat legible.

Compared against a fixed-foveated image, it does seem to slightly better match the boundaries, but I’m not entirely sure if I can confidently say that that level of blurriness (as seen in box 11) would be present, and that level of clarity seen in the other boxes would be present with only half the available resolution.

In this test, mipmap level 2 (¼ res) is designated by the color blue, which seems to seep into the edges prominently for the first and last column, and a blue haze is present over the entire image. Mipmap level 0 (full res) is not present.

I would personally guess that either the gaze confidence window was slightly wider due to the DSLR lens (which would imply a lower max PPD parameter), or the panel was slightly further than 30in from the lens view (which would imply more mipmap blending, maybe). However, we know some of the blurriness might not be optical–

Something I plan to investigate at a later time is to test whether the Quest 3, due to rendering to much larger framebuffers (or potentially, actually-supersampled framebuffers), simply has an accidental advantage in this test due to mipmap blending only kicking in at a slightly larger z distance. 1920x1824 is a pretty small framebuffer size, so it’s no wonder it’s pulling ½ res mipmaps so early on the Apple Vision. Needless to say, there might be non-optical shenanigans at play here, but I’m satisfied to know that KGOnTech likely did manage to get the eye tracking to follow a DSLR somehow. Maybe they use glint tracking or something.

Quantifying approximate effective monitor resolutions via mipmaps

One interesting thing that I think KGOnTech stumbled into (probably more intentionally than stumbling, really) is the fact that for a virtual 28” monitor 30 inches away, 1080p does genuinely seem to be right at the threshold of effective resolution on the Apple Vision Pro. For example, if I attempt to make a 28” 4k monitor, it doesn’t even try to sample at the highest texture size, it immediately drops to mipmap level 1:

The fovea is yellow, indicating the full-resolution 4K image was not sampled at all.

And if I do 1.5x 1080p (1620p?) it’s only barely using the full texture resolution and is already starting to blend lower resolution mipmaps into the fovea:

The center of the fovea is a yellow-green, indicating it’s started blending mipmaps into the full-resolution green image.

Of course, these conditions only hold if you’re emulating a 28” monitor from exactly 30 inches away. For a 1000” movie theater projector-sized panel at 4K resolution from 600in away (ie, consuming more than 45deg of your FoV), it will likely genuinely appear as if it were a 4K panel. Though interestingly, you can also see that the PPD dips significantly at the edges, just as KGOnTech reported it does.

For a 4K 1000” movie theater projector-sized screen, pixels are indeed sampled fully, except at the edge of the FoV where it visibly dips into mipmap level 1 in the fovea.

And if you juuuuust scoot that 1080p monitor 5 inches closer, the yellow haze is completely gone:

Yay, the yellow haze is gone.

Which, to be completely honest, makes a lot of sense! I believe the average movie viewing FoV (and the range where you actually get comfortable stereo overlap in the headset) is about 60 degrees anyhow, and it's likely that Apple optimized their render texture resolutions for that. And I also happen to personally keep my desktop monitors at about that distance.

Wait, do desktop streamers even use mipmapping?

As one last double-checking measure, I think it’s also worth untangling another weird bit of nuance that kinda gets lost on this discussion, which is that ideally everything would be running locally on a headset, but currently the only way to really get Excel (or whatever other apps) is by streaming it from a PC–with all the fun nuances of H264/HEVC that come with that. A more subtle nuance though is that a PC streamer app really isn’t likely to use mipmapping at all, since generating mipmaps is rather costly for a texture that is (hopefully) being updated at 60+Hz.

However, when I think of text rendering tasks, the number one task I think of is reading text in a web browser, on-headset, and in that circumstance everything is for-sure 100% mipmapped. At least I hope it is. So examining whether text and line clarity can be impacted by this seems like something that’s fair to check.

Anyway the answer is yes, textures without mipmaps have strange artifacting with foveated rendering:

1px checkerboard grid at 1080p, with mipmaps generated. It has noticeable aliasing artifacts in some places but is overall fairly uniform

1px checkerboard grid at 1080p, with no mipmaps generated. It has extremely noticeable aliasing artifacts.

I guess there’s still maybe an argument that the yellow haze being present at all likely means this particular distance and render resolution will be prone to aliasing/clarity issues, regardless of whether mipmapping is on or off.

Can we optimize for clarity?

For dynamic images, technically my RealityKitShenanigans/ALVR rendering method allows for supersampling of distantly-rendered objects. However in practice, the resolution required for 40PPD without eye-tracked VRR will thermally throttle the Vision Pro within about 15-30mins (at least in my own burn-in tests). Maybe it'd work if Apple actually ran the fans harder, lol. Edit: with the correct texture usage flags (NO .shaderWrite!!), compositing >40PPD stereo eye textures is very much doable for real applications.

For static images and your average app dev, at best I think it might be possible to sharpen or otherwise filter lower mipmap levels to ensure that the linear blurring doesn’t inadvertently reach the virtual monitor while at awkward distances.

For the most part however, it’s worth keeping in mind that mipmapping may interfere with visual clarity at some distances, but even a partially-mipmap-blended image will likely benefit from temporal information the eyes are able to gather–by virtue of not sitting exactly still and headlocked to the virtual screen. Of course, head movement isn’t uniformly random by any means, but as long as the full-resolution texture is being sampled there’s at least some kind of odds each pixel in the fovea will be sampled with some clarity within a given timespan.

Also kinda makes me wonder if dithering/feathering/blending between different mipmap levels with randomized blue noise or something (on a GPU level, or maybe at a shader level idk) would have a potential benefit of increasing perceived clarity, by allowing higher-information texture samples to pass through prominently at awkward distances with actually-random chance. Idk, I’m not really a graphics programmer.

That being said, it’s usually best to not leave clarity up to random sampling chance. But it does mean that perceptual boundaries for clarity are likely blurrier than one might guess by merely looking at still images.

Takeaways

Is Apple Vision Pro the same effective resolution as Quest 3? It definitely is if you squint enough and/or aren’t careful with how you take through-the-lens shots. It arguably is if you happen to be rendering text on a virtual 28” 1080p panel from exactly 30” away using normal UI drawing methods. The Apple Vision Pro, due to its absurdly low framebuffer resolution of 1920x1824 (and no supersampling), is especially prone to half-res mipmap levels getting partially blended into virtual monitors/windows when they are rendered, possibly resulting in blurrier text in some circumstances. It’s also highly possible that future eye-tracked headsets will not be nearly as forgiving when it comes to photographing them.

In practice, though, there are genuinely more pixels to go around on the Apple Vision Pro: Eyes and heads have a tendency to not stay still, and all of that movement means that visuals will be sampled ever so slightly differently in the fovea. I would hazard a guess that in more difficult circumstances, it would be easier to recognize poorly-sampled text on an Apple Vision as opposed to a Quest 3 in a given timespan. Unfortunately cognitive load is difficult to quantify, and going too deep into temporal vision stuff risks alerting the 1kHz UFO gang.

I’d also say the real takeaway is to ding Apple for not having better supersampling/mipmap controls. There’s entire articles going over the intricacies of different mipmapping and supersampling methods for perceptual clarity in VR, and Apple’s rendering stack for 40PPD rendering doesn’t exactly lend itself well to any such things from a developer standpoint–everything is just de-facto unusually prone to aliasing and mipmapping clarity losses. But that’s also not exactly an optical issue, so I guess I’ve managed to at least clarify that.

TL;DR

Yes, the Vision Pro can have the same effective resolution as the Quest 3 if you happen to be rendering text on a virtual 28” 1080p panel from exactly 30” away.

The Quest 3 has better layer supersampling, and the Vision Pro has basically no supersampling and a low render texture resolution prone to mipmapping weirdness, but those are entirely software-fixable. And at the end of the day it still has more pixels, which matters because not everything is high-contrast text.

Also none of those mipmapping limitations apply to PCVR streaming with ALVR’s 40PPD renderer :^)

(assuming you can get 40PPD resolution to last more than 15mins before thermal throttling) Edit: this was thankfully a skill issue

Source Code

Sources for the VRR testbench can be found on my GitHub at https://github.com/shinyquagsire23/VRRClarityTestbench. It’s not the most user-friendly but it’s MIT licensed so if someone feels like doing UI programming then go for it tbh.

Edit Notes and Numbers I Forgot

Edit (May 14 2024): The thermal throttling I experienced attempting to render a 40PPD texture was a skill issue (framebuffer compression is not applied to textures with .shaderWrite usage, so write bandwidth shot up to 80GiB/s)

Edit (May 12 2024): I misremembered the vertical Drawable resolution, it is actually 1824 and not 1840. It has been corrected in the post.

Edit (May 12 2024): I found chat logs where I mentioned the unfoveated render PPD for Reality Composer, it is 20PPD.

Edit (May 12 2024): Because I'm probably going to keep forgetting to write these numbers down:

Without foveation/VRR, 1920x1824 resolution yields 18.387PPDx19.339PPD (derived from the following error message: "layer is too big: (1984.0x1792.0) max physical allowed: (1920x1824) for gaze angle 0.000000x0.087489,0.000000x0.087489 uncertainty:19.700001,19.700001 ppd{min:19.000000,19.000000, max:19.000000,19.000000}").

The maximum full-view render texture resolution before the OS starts loading mipmaps is 4800x4560, or 45.968PPDx48.348PPD (2.5x 1920x1824)

Apple Vision has the following rectilinear view FOVs (eg, what the application actually renders): 105deg horizontal (60:45 left right) 95deg vertical (45:50 up down)

Quest 3/Pro has the following rectilinear view FOVs: 104deg horizontal (54:50 left right) 96deg vertical (42:54 up down)

[shinyquagsire23]

de_Fuse, the One True Pwn (Bypassing secure boot on the Wii U)

Background - Why Wii U?

The Wii U has had a fairly small homebrew scene, I believe in part because it currently has no commercial nor open-source modchips for facilitating early-boot code execution. While there exists a coldboot boot1 vulnerability, isfshax, it leaves a lot to be desired, and it is unfortunately not useful for recovering consoles from an unknown state, since NAND is encrypted per-console based on an OTP key. Additionally, certain SEEPROM corruptions can cause consoles to never reach boot1, resulting in unrecoverable bricks (at least without drilling through the SoC substrate).

With the news that a handful of Hynix Wii U eMMCs were starting to rapidly degrade, I decided to revisit a recurring project idea of mine: an open-source Wii U modchip. I had originally started this endeavor by glitching the Wii mini, which at the time had not been hacked, however my efforts were quickly sniped by FullMetal5’s bluebomb (which later precipitated to Wii U by GaryOderNichts as bluubomb, however it is a different vulnerability). I did, however, manage to get boot1 execution on my Wii mini in a novel way: by inserting a voltage glitch shortly after reset, before the console started executing code, OTP had been cleared to zero. More on this in a bit.

boot0 and chip provisioning, on Wii

The Wii was extremely basic in how it handled booting: ROM was somewhat expensive (for die space, but also more likely, for chip revisions), so the Wii’s boot0 simply loaded boot1 from NAND, decrypted it with a key stored in ROM, and checked that its hash matched fused values in OTP. If it matched, it booted. However, there is one special case for factory-fresh console (and apparently dev units): If the OTP hash is entirely 00s, it will run anything that is loaded from NAND. More details are available on its WiiBrew page.

boot0 and chip provisioning, on Wii U

The Wii U is significantly more sophisticated in how it boots: the boot1 Ancast image can be loaded from either NAND or the SD card, images are specific to the hardware they are signed for (NAND vs SD card), signature pubkeys are specific to dev vs retail hardware configs, and security fuses can be configured to disable encryption and sigchecks entirely:

(Tumblr probably murdered the image resolution; An SVG is available here.)

Fuses on both the Wii and Wii U are provisioned via JTAG, and JTAG is locked out via its own eFuse, which is readable via OTP registers. I haven’t figured out if fuse cutting is done before or after the chip is soldered to the motherboard.

How do eFuses work?

‘eFuses’ technically encompass a large variety of different types of PROMs. On some devices, eFuses are just EPROMs which can be reset via UV light and decapping, on other devices they are more like the name implies: literal fuses which, when enough current is pushed through them, will physically disconnect and burn in a 1 bit.

eFuse sensing typically relies on a combination of current-sensing FETs, and a multiplexed array of resistive fuses. A sense voltage is applied across the fuse, and if the current passing through the fuse meets a blown threshold it is detected as a 1, otherwise a 0. This has three implications:

In order to allow the usage of eFuses for security lockouts (JTAG), there must be an initialization sequence in which the multiplexer iterates through each fuse and stores it to registers.

If eFuses are used for security lockouts, eFuses must be read immediately after reset, before any code executes.

Current sensing requires a fixed, stable voltage. An increased voltage will increase current, because the resistance of the eFuses are fixed. This might also mean that sensing is dependent on temperature, since semiconductors’ resistance decreases with temperature.

eFuse burning has even more logistics, and typically has its own dedicated voltage rail and incantations to verify the fuse cut correctly. There’s also some eFuse patents which indicate that some eFuse designs have error correction and redundancy.

Aside: A lot of the specifics on sensing are purely speculation, because like most things in silicon, IP component details aren't even given to the chip designers, and designers especially aren't given silicon-level details for partner IP without a lot of red tape. At best I can guess based on patents, but it’s almost certain that Nintendo did not design their eFuse sensing.

How do the Wii and Wii U read eFuses?

Both the Wii and Wii U read all fuses sequentially into registers as soon as reset is deasserted. On the Wii, OTP is only one bank of 0x80 bytes, whereas on Wii U this was upgraded to 8 banks of 0x80 bytes. A counter decrements from the highest eFuse bit (0x400 on Wii, 0x2000 on Wii U) down to 0. After the counter reaches 0, the internal reset is presumably released, and the rest of the hardware begins to boot.

On Wii U, fuse bits are latched at a rate of 4 bits per 27MHz cycle following reset deassertion, and bytes are shifted into the OTP registers every other cycle.

(It’s possible that it’s not actually 4 bits per cycle, but is instead 8 bits on one cycle and 0 bits on the next while it shifts the result to the register file; it’s impossible to know which it is without a really expensive microscope.)

Developing de_Fuse and Gaining Code Execution

In 2019, I experimented with attempting to glitch boot0 on the Wii mini, a console which at the time had not been hacked. The consoles were cheap, and the Wii is extremely well documented thanks to WiiBrew and the portablizing scene. While I had intended to glitch a branch instruction, I accidentally stumbled onto a more interesting vulnerability: One which left the OTP eFuses entirely zeroed, reliably, by glitching a few cycles after reset. The ChipWhisperer Python and reproduction docs can be found here.

I was curious if the same exploit would work on Wii U, and after looking at boot0 more carefully, it indeed had the same exact (potential) flaw if OTP happened to read all zeroes.

The plan for gaining code execution was as follows:

Make the security level u32 read as 0xxxxxxx.

Write a decrypted payload to NAND, or alternatively, trigger SD booting by setting the UNSTBL_PWR bit on the EXI bus.

This has several benefits (and a few downsides) over glitching branches in boot0:

Corrupted SEEPROM Wii Us are now recoverable, since CRC32 fails are ignored in factory provisioning.

Both NAND and SD card payloads are loaded decrypted, and without Ancast signature+header verification (boot1 payloads can coincide with an MBR, for instance).

The downsides:

OTP cannot be dumped, because it’s 00s now. Irrecoverably bricked consoles would require an OTP donor. It turns out OTP can be dumped, by exploiting boot1 using PRSH hax. This requires that SEEPROM/NAND be in working order, however (which is most bricked Wii Us, blinking blue LED = boot1 is running).

The boot0 SD card driver does not support SDHC (and especially doesn’t support SDXC) :(

First order of business was getting boot stage visibility: Each stage in boot0 is indicated by the value written to the NDEV_LED GPIOs. To make things easier on myself, I used an iCEBreaker with one PMOD handling the NDEV_LEDs and another handling reset, glitch triggering, and EXI overrides. While I’d wanted to have a proper EXI module, I settled for counting EXI clocks and using a p-channel MOSFET to force the line high when the UNSTBL_PWR bit is being read. For GPIO monitoring, I queued values into a UART FIFO when I detected any changes. I also made sure to run the FPGA at 27MHz to allow for cycle-precise timing, matching the Wii U.

Overall, I’m quite pleased with my setup. The PMODs and standoffs made it easy to flip the console over to access testpoints.

(via https://twitter.com/ShinyQuagsire/status/1638026420931936256)

Aside: The open-source ice40 toolchains are SO nice for quick iteration, so much better than Xilinx ISE and Vivado.

Because I have commitment issues the MOSFETs I ordered would take a week to arrive (and also to make sure my reset trigger works fine) I spent some time attempting to do reset-based attacks. By holding reset and then inserting one small (<=1 clock wide) reset pulse at a swept offset, I had hoped to find any weird partial reset behavior that may exist. Success was mixed: I discovered one range early into boot which would result in a successful signature check, meaning it verified the signature and jumped to boot1, but no signs of life from boot1 itself. This will be important later.

While waiting for MOSFETs, still, I decided to experiment with reset glitches combined with undervolting. I desoldered the two inductors from the 1V line to bring in my bench power supply, and I tied the 1V PGOOD snitch signal to GND by tying the solitary leg of Q1064 to GND, so that the SMC chip would stop shutting off the regulators and blinking the power LED red.

(via https://twitter.com/ShinyQuagsire/status/1641629325614272512)

Results were mostly the same, however I also got extremely lucky: in preparation, I had already flashed my SD card with a fork of minute, which is a fork of fail0verflow’s mini (I helped work on minute in 2017 and was fairly confident it would be a good base for a boot1 replacement). To be sure my payload would work correctly, I verified it with a zeroed OTP in Wii-U-Firmware-Emulator, an LLE Wii U emulator.

By some weird stroke of luck (what I assumed at the time was just me bumping the power wire), I pressed the button I wired to reset and was greeted with my success trigger: 0x88 flashing on the debug LED GPIOs. Despite not being able to recreate the glitch, this confirmed that my theory of the Wii U being vulnerable to the same 00’d OTP vulnerability, and I figured that surely the vulnerability would be 100x more reliable with a proper MOSFET-driven brownout, since this is how I achieved 00’d eFuses on Wii mini (and the Wii mini glitch was extremely consistent).

However, once my MOSFETs had arrived and I connected them up, voltage glitching also yielded no results, at least not via sweeping offsets: To experiment with pulse widths, I had wired one of my buttons to act as a manual trigger for a reset followed by a delayed MOSFET pulse. By some act of God, I had managed to find a consistent way to trigger 00’d OTP, which exclusively worked using my pushbutton. To my horror, it even worked when I disconnected my MOSFETs entirely, and it even worked when I stopped undervolting the 1.0V line.

Attempting to Clear the Fog of War

Why did I gain code execution only via my pushbutton? Button bouncing. My pushbutton just happened to bounce with the exact timing required to trigger de_Fuse. By counting the cycles between pushbutton bounces, I found the exact reset timing which characterized my pushbutton on a successful glitch. In fact, the automated timing was so consistent that I desoldered my MOSFET trigger wire and began work on making a boot1 replacement. This is where I began the post-mortem of understanding wtf was even going on.

My initial hypothesis was waves hands vaguely harmonics and current draw. The Wii U has an extremely sudden current draw when reset is released going from ~900mA to 1.5A, so maybe jumping from a high current draw to an extremely low one would glitch the fuse sensing to read 00s, especially since my provided power was significantly lower wattage (intentionally). There’s also some debate about whether capacitors help or hurt voltage glitching by dumping large amounts of current very suddenly following a glitch pulse, which then rings on the voltage line.

(It was not anything voltage-related, though.)

To facilitate faster development on my boot1 replacement, I developed a bitbanged serial driver so that I could dump data faster. At this point I hadn’t even dumped my OTP, because I figured it must be 00s, and was therefore not super interesting.

But it wasn’t 00s, there were ~0x40 bytes of valid OTP. Everything following the valid OTP readout was 00s. This did not fit my model at all, because there were no bitflips that you’d expect in a voltage glitch; what was loaded was pristine and exact.

I began to experiment with reset timings again, to understand what could possibly cause this. What I found was even weirder: As I increased the delay of my glitch reset, less data was loaded into OTP, instead of more. I could even see exactly how much was loaded with per-cycle granularity, and with some more notes I was able to control exactly how much OTP was read from the eFuses. The duration that I held down the glitch NRST did not matter either, meaning that this was not a brownout glitch. It was too consistent to be that.

de_Fuse, the One True Pwn

(aka, the section I’m copy-pasting into the Hardware Flaws page on WiiUBrew)

In order to accommodate eFuse-based JTAG lockout (and due to other considerations), eFuse bits must be buffered into a register file immediately following NRST, before the internal reset can be released. The eFuse sense state machine latches at a rate of 4 bits per cycle, directly off the 27MHz XTALCLK. Every other rising edge, a byte is written into the register file, starting from the least significant byte of the current u32.

An internal counter is used to keep track of the remaining bytes to be read into the register file. While the eFuse register file is reset to zero with NRST, the internal counter is not: By asserting NRST after N bytes have been read, only 0x400-N bytes will be read on the subsequent boot.

By asserting NRST just before the final byte has been read (1830 cycles), all eFuses will read entirely zero, including the JTAG lockout fuse. This allows trivial, unsigned and unencrypted boot1 execution, with no SEEPROM anti-rollback.

One More Thing,

Additionally, because SRAM is not cleared on reboot, and because boot1 verifies over the encrypted payload, the boot1 key can be extracted: By asserting NRST after 176 cycles and walking the delay width down cycle-by-cycle, code execution can be used to gather 16 failed decryptions of boot1: A zerokey-decrypted boot1, and 15 others with one more byte present in its boot1 key than the last. This allows a straightforward bruteforce of the boot1 key.

For those who wish to follow along at home, I’ve provided the following worksheet: https://gist.github.com/shinyquagsire23/d42c57782ec31f9c3e74177b1e34e6d2

The bomb has been de_Fused, Counter-Terrorists Win

What Next?

All of my modchip development is open-source on Github, however it is in the early stages: It requires an FPGA, I haven’t standardized any components or schematics, frankly I haven’t even tested it on any other consoles. For booting custom firmware and de-bricking tools, a fair amount of work still has to be done, but it hopefully won’t take too long. At some point I will try and attempt to get de_Fuse working with an RP2040–my target price is $25~$35 in parts, if not lower. Collaboration is greatly welcomed.

Additional Reading

I couldn’t find a good place to mention this, but I found out I was beat to the punch on OTP eFuse readout glitching in 2019, by some other researchers looking into the Espressif ESP32: https://raelize.com/blog/espressif-systems-esp32-glitching-otp-transfer/

WiiUBrew pages which go into more detail on boot processes, what’s in OTP, etc:

https://wiiubrew.org/wiki/Hardware/OTP

https://wiiubrew.org/wiki/Boot0

https://wiiubrew.org/wiki/Boot1

https://wiiubrew.org/wiki/Ancast_image

https://wiiubrew.org/wiki/Hardware/Testpoints

Special Thanks

YvetalGriffin, for lending me their Wii U board scans so that I could follow the internal PCB traces for PGOOD.

Relys, for donating their old Wii U to me for glitching.

derrek, for answering a few questions I had about his Wii U glitching setup.

GaryOderNichts, quarky, for keeping me in the loop CFW deets, random Wii U musings

kinnay, https://github.com/kinnay/Wii-U-Firmware-Emulator

SALT peeps, gang

[shinyquagsire23]

Tying It All Together - Pwning To Own on LG phones

Last year I detailed a secure EL3 vulnerability which affected (and still affects, for devices with discontinued updates) LG Android devices. However, this vulnerability alone isn't actually all that useful for a number of reasons, the more immediate being that many phones simply do not allow writing to eMMC without root or a custom recovery. Additionally, gaining full control over all privilege levels requires draining the battery to below 0%, which while it would be possible to create a modchip that facilitated this, is impractical. To finish off my exploit chain, I would like to detail two additional vulnerabilities that I have found and utilized in my coldboot process. It's worth noting though that these vulnerabilities were reported to LG and may be patched on updated units.

Live, LAF, Love

The first exploit is an obvious necessity: In order to write the rle888 payload into the eMMC's boot graphics, I need to be able to achieve an arbitrary partition write. While exploiting Android *is* an option for this (as are hardware methods), I instead opted to attack LAF, LG's recovery/flashing component. While many Android phones in the past have used fastboot in order to flash radios and other system components to eMMC, fastboot has been completely removed on the Q710/Q720. Some phones such as the Nexus 5 actually maintain both fastboot methods and LAF, but for maximum spread, LAF is the clear target.

LAF is designed to work with LGUP, a frequently-leaked LG-internal flashing tool that allows flashing KDZ update files. While LAF in the past was able to read and write eMMC partitions without any restriction, in recent years LG has opted to sign all of their KDZ files in order to make it more difficult for things like cross-carrier flashing, version mixing/matching between partitions and other modifications to occur. Flashing is done via USB, and most of the protocol has been documented at https://github.com/Lekensteyn/lglaf.

The LAF update process largely consists of an ioctl-over-USB shim: The OPEN command is able to open a partition block device, and READ/WRTE will seek into the file and write contents. However, reading and writing are explicitly blocked until a list of partitions, their eMMC offsets, their KDZ content offsets, and their content hashes is sent via the SIGN command, all of which is hashed and signed by LG. If the contents of the partitions in the KDZ are modified, the partition list hashes will fail to verify, and modifying the hashes in the partition list will make the SIGN check fail. The private key is not stored in LGUP; KDZs are downloaded from LG's servers, signed presumably by their build servers.

So, how can we manage to activate WRTE commands, with valid partition content hashes of our arbitrary contents, if we cannot sign our own? To start, I investigated how the WRTE commands actually handled hash checking--if the partition list is sent with SIGN, then at some point the WRTE command must be able to figure out which partition the current write is for, and the current partition's contents must be buffered in RAM somewhere along with an updating SHA context, because if the SHA check fails, then it shouldn't write at all. As it turns out, most of the checks in this area were fairly solid (the write must be in the range of a partition in the list, the entire transaction is one bulk packet of the hashed size, etc). However, this led me to realize: The partition list signature is only checked once, and there is nothing stopping me from, say, sending another SIGN command.

The SIGN verification process works as follows:

The partition information is sent along with a signature in one bulk transaction.

The partition information is copied into a global .bss array from the USB buffer with a fixed size.

The partition information hash buffer is prepared: An allocation is made for N partitions and an optional string, the string being the device model (to prevent cross-flashing). The number of partitions is determined by a signed portion of the header. If the allocation fails, an error is returned.

The partition information is copied again into this allocation along with the string, and the contents are hashed. The signature is crypted with the public key and the signature hash is verified against the partition info hash. If the check fails, the global .bss array is cleared and an error is returned. If the check passes, some write threads and structs are initialized and a success value is returned.

The .bss buffer storing partition info (used by other functions) is copied to before the packet is verified

The .bss buffer is cleared when the signature mismatches, but not with this malloc fail...?

The flaw here is subtle, but not terribly difficult to notice: The number of partitions is user-controlled even though it is signed, and the partition info was copied into a global variable before verification. In all other error conditions, LAF will memset the partition information before returning an error code, however if the hashing allocation fails (ie by setting the number of partitions to -1), then the allocation will fail and an error is returned without clearing the partition information. Thus, we can fakesign our own update KDZs by

Sending a valid SIGN command, which will start the write threads

Sending a fakesigned SIGN command with the number of partitions set to -1, and all partition information set however we want. The partition information in .bss is now set without a signature being checked.

While this fakesign has the potential to hang WRTE commands while due to the number of partitions being set much larger than the global partition array, all loops when WRTE checks the partition list hashes will break once a valid partition is found. So, as long as the hash contents of the WRTE command are existent in the first few entries, it will not hang, however any writes sent that do not match will hang lafd.

Another S-EL3 vuln to wrap it all up

This might seem a bit pointless given that the former vulnerability paired with 🔋 📱❄️🥾🔓 at aboot is more than enough to unlock bootloaders, since aboot is usually the code that handles bootloader unlocking/wiping/boot image signature verification, but the downside to unlocking your bootloader is that you lose SafetyNet. To most effectively mitigate SafetyNet issues you basically need an S-EL3 exploit in order to patch Qualcomm's TrustZone to spoof a locked bootloader. While 🔋 📱❄️🥾🔓 has a vector for S-EL3 code execution via SBL1 and its charging graphic, it only triggers at extremely low battery voltages and it would be more convenient to find an alternative means to gaining S-EL3 code execution via aboot, which runs at EL2/EL1.

One of the first things I noticed when I began to look for SBL vulnerabilities, and actually the reason I looked at SBL in the first place is its crash handler. Since at least the Nexus 5, LG has shipped its "Demigod Crash Handler" which can print registers and stack information and RAM console logs from EL1 kernel, S-EL3 SBL, TrustZone, etc. I first discovered it while trying to exploit a kernel stack overflow. It also allows the user to dump memory contents over USB via its Sahara protocol which also gets used in PBL for Firehose bootstrapping.

Naturally, SBL cannot know the exact details of every execution environment it displays stack dumps for, it requires the faulting environment to store that information before warm-resetting into SBL. Consequently, this means there are portions of RAM writable by EL1 which will be later parsed at an S-EL3 execution level, and of course to make matters worse it also expects EL1 to handle the memory allocation for both the RAM console as well as for the framebuffer. These structures are also plainly visible in LG's kernel sources available in their Android OSS zips.

Above roughly shows the arbitrary write which is possible with this ramconsole parsing. The ramconsole offset is not bounds checked, so we are able to achieve an arbitrary write to a limited set of addresses based on ramconsole_offs, the limit being that the offset factors both into what you write and where you write it. However, I found that since DRAM takes up such a significant portion of the address space, it was more than enough to specifically write a function pointer to the stack. To keep the exploit as simple as possible, I chose to force console_init_maybe to return to the missing battery graphic draw routine, which then triggered 🔋 📱❄️🥾🔓 without the need to drain the battery below 1% and made loading additional payloads significantly easier.

As an interesting sidenote, this vulnerability is extremely similar to hexkyz's Wii U boot1 exploit, which also abuses warmboot behavior to take over the secondary bootloader of the Wii U's ARM boot processor. In that case, however, the Wii U encrypted its PRSH/PRST structure in RAM, and rather than displaying syslogs, it uses the structure to store boot timings and other info between IOS reboots.

For most practical usecases, this vulnerability is a bit difficult to exploit, due to SBL's text and stack differing between devices. However, S-EL3 vulnerabilities aren't all that frequently documented on Android, so I hope that it will at least be useful for anyone interested in examining Qualcomm's TrustZone components or avoiding weird SafetyNet junk.

Code for both of these exploits can be seen at https://github.com/shinyquagsire23/Q710-SIGNhax-EL3-Warmboot

[shinyquagsire23]

🔋 📱❄️🥾🔓, an EL1/EL3 coldboot vulnerability affecting 7 years of LG Android devices

I should probably preface all of this by saying that I'm not really a security professional in the sense that I don't actually do security stuff for a living; I reported this vulnerability in March and gave a 90 day delay on releasing specific details mostly just because that's A Thing That Security Researchers Do. Also the vulnerability doesn't require user interaction from coldboot so it's a bit nasty in that regard. But also this vulnerability sat around for 7 years so it could be argued that, if anything, 90 days is too long.

Anyhow jumping into things, this is a writeup documenting CVE-2020-12753, a bootloader vulnerability affecting most Qualcomm-based LG phones since the Nexus 5, all the way up to the my test device, the LG Stylo 4 Q710 (and 5 Q720), and probably others. While working on the implementation of this vulnerability I thought it was odd how few bootloader vulnerabilities for Android actually get properly documented, and given the sheer spread of affected devices of this particular vuln I thought it'd be interesting to document it in detail.

A Quick Primer on the (Qualcomm) Android Boot Process

The device I'm working with, the Stylo 4, operates on 2013-2016 variant of Qualcomm's boot sequence described at https://lineageos.org/engineering/Qualcomm-Firmware/:

- On power-on, the Primary Bootloader (PBL) initializes DRAM, eMMC, etc and then loads and verifies SBL1 (Secondary Bootloader 1) from eMMC. - SBL1 then loads and verifies the Trusted Execution Environment (TEE), aboot, and a few other bits and pieces and then jumps to the TEE, in this case Qualcomm's Secure Execution Environment (QSEE) - QSEE sets up secure EL3/EL1 (TrustZone) and jumps down to aboot (non-secure EL1) - aboot loads and verifies the Linux kernel and jumps to it

Some Android devices allow "bootloader unlocking", which allows unsigned kernels to be loaded and run. Generally this unlocking occurs via aboot, and the implementation varies from vendor to vendor, however in most cases what happens is that a fastboot command gets sent to the phone to unlock/lock the phone, and as part of Android's Verified Boot, the phone's storage is wiped on this transition. There's also some requirements on user verification so that, in theory, this unlock cannot occur without user interaction.

Additionally, with verified boot enabled, Android will use dm-verity to verify all files on the root/system partition, and SELinux is run as Enforcing.

Variants on the Boot Process, added by LG

In practice, the boot process isn't quite so simple: Vendors are able to add modifications to the boot process as they see fit. In LG's case, these differences can be summarized as follows: - Hardware bringup in SBL for charging PMICs, LEDs, and other misc hardware - Misc logging/debugging modifications - Additional TEE processes for SIM unlocking, backed by RPMB - In aboot, vendor-specific fastboot commands (or no fastboot at all in the case of my device), restrictions on unlocking via certificates, verification modifications, additional boot args for Linux, etc - Vendor-specific recoveries/flashers, LAF in the case of LG

While I initially started in a privesc from within Linux (and got ~close to getting kernel execution), Google has done a lot of work to ensure that vendors can’t mess up Android security. However, bootloaders have a lot less oversight, so going after these vendor-specific bits of hardware bringup seemed extremely opportune for errors.

Introducing: raw_resources

At an undetermined point in time (likely prior to the Nexus 5 releasing), LG added an "imgdata" partition on eMMC to store boot graphics for Download Mode, fastboot graphics, charging graphics, the unlock graphic and so on. Image data is stored RLE compressed and for each image, metadata for the image width, height, x and y position are specified. The Nexus 5’s final bootloader image, as far as I can tell, only accesses this partition from aboot; SBL1 is not affected on this device. For the curious, I have a Python3 script which can extract these images at https://gist.github.com/shinyquagsire23/ba0f6209592d50fb8e4166620228aaa5.

A few examples of Nexus 5 imgdata resources

imgdata later became raw_resources, and at an undetermined point, the same RLE decompression and metadata interpreting was copied into SBL1 for use in boot paths where the battery has discharged significantly. If the battery is discharged too far, SBL1’s pm_sbl_chg_check_weak_battery_status will display LGE_PM_NO_CHARGER for boot attempts made without a charger connected, LGE_PM_WEAK_CHARGING_ON for boot attempts with a charger connected, and LGE_PM_NO_BATERY_ANI_* for boot attempts made without a battery. A script for extracting raw_resources can be found at https://gist.github.com/shinyquagsire23/b69ca343fd2f246aee882ecb5af702bd.

A few examples of Q710 resources

On normal boot paths, aboot reads raw_resources to display the boot logo, download mode graphic, and verified boot statuses for devices which allow unlocking. In my case, the Q710/Q720 does not allow for unlocking, so this boot path is never reached on these devices. However, the graphics still exist I guess on the off chance that they allowed it to happen.

For the C inclined, the format of raw_resources can be summarized in these structs: typedef struct boot_img_header {    char magic[0x10];    uint32_t num_imgs;    uint32_t version;    char device[0x10];    uint32_t signature_offs; } boot_img_header;

typedef struct img_info {    char name[0x28];    uint32_t data_offset;    uint32_t data_size;    uint32_t width;    uint32_t height;    uint32_t offs_x;    uint32_t offs_y; } img_info;

The following calculation is performed in order to determine the output pointer to be used during decompression: bpp = 24 screen_stride = fbinfo->screen_width; fbuf_offset = offs_x + (screen_stride * offs_y); fbuf_out = (fbuf_offset * (bpp / 8)) + fbinfo->buffer;

offs_x and offs_y are not bounds checked, and fbinfo->buffer is known in SBL1 and aboot, allowing for a controlled arbitrary write in both environments.

SBL1 load_res_888rle_image Arbitrary Write

This boot path requires discharging the battery to below 0%. While this is less feasible for any practical usage, performing the arbitrary write at this point allows patching SBL1 to disable signature verification before TEE and aboot are loaded. Any of the LGE_PM_* images can be hijacked selectively for arbitrary code execution, though for my PoC I used LGE_PM_NO_CHARGER specifically because I didn't want to accidentally brick myself (or well, I didn't want to have to beep out eMMC wires on the board to unbrick).

A 32-bit x offset can be calculated for any given address divisible by 3 using the following calculation: offset_x = (((0x100000000 + target_addr) - 0x90000000) / 3) & 0xFFFFFFFF

Data written to this arbitrary address can be kept contiguous by specifying the image width to be the same as the screen width. The height should then be rounded up from the payload size to ensure all data is written properly. So really by the end, this isn't an arbitrary write so much as it is an arbitrary memcpy at Secure EL3.

aboot Arbitrary Write

The aboot arbitrary write functions identically to SBL1: Any image can be selected to perform the arbitrary write. Most notably, this includes any lglogo_image_* graphic, which is displayed by default on every boot. The framebuffer is generally fixed to address 0x90001000, which means that by using the arbitrary write to gain code execution, the original graphic which was used to obtain the arbitrary write can be written to the screen following hijacking to, in effect, make it appear as if boot flow has not been modified at all, for better or for worse.

A good question that might be raised after looking briefly at the structs earlier would be, "wait, there's a signature offset, why does any of this work if raw_resources contains a signature?" And yes, raw_resources contains a signature! But it's a useless signature because this signature is only checked in aboot while displaying verifiedboot_* images. At some point, XDA users found out that you could swap the LG boot logos over the verifiedboot_* images so that when they unlocked their devices they wouldn't have to see the AVB boot nag messages. Naturally, this defeats the point of Google's Verified Boot spec since it would potentially allow a bootloader be unlocked without the user knowing, so LG added a signature. But it’s only checked for the verified boot images.

As a minor note, unlike SBL1, aboot will also select between raw_resources_a and raw_resources_b depending on the A/B boot slot.

Practical Exploitation

I started by exploiting SBL1, partially because Secure EL3 is just cooler than nonsecure EL1, but also because the framebuffer address was more obviously seen than in aboot (though I later found the aboot framebuffer address anyhow). At this point in execution all of the hardware is initialized and no other bootloaders have been loaded, so we're basically free to patch sigchecks and control the entire phone!

As it turns out though, SBL1 takes a bit more work to actually exploit, because unlike aboot, its segments aren't set RWX. I'm not really sure why aboot has all of its segments RWX, like at that point it's more of a 'boot' than a 'secure boot' if they can't even bother to use the easiest security option available.

In any case, ROP is required briefly to bypass the MMU's NX bit. This isn't too terrible, since SBL1 actually has a routine we can jump to to disable the MMU, though it requires a bit of finnagling to get correct.

So in summary, the exploitation process goes as follows: - Flash raw_resources_a.img to eMMC (ie via kernel execution, LG LAF, soldered wires and a hardware flasher, etc). - For SBL1 hax, drain the battery to below 0%. For my Q710, I drained most of the battery by leaving the screen at max brightness with sleep disabled until the phone powered off on its own after several hours. To drain the remaining battery, I charged enough to enter LAF download mode and left it to drain with the screen on for 2-3 hours. - Hold Power and Volume Down until the phone restarts. If the phone discharged enough, the phone should restart into the payload. - The phone can be plugged in to boot into aboot and Android normally, but the payload will now execute every time the payload-injected graphic is displayed.

To exploit SBL1: - raw_resources_a is modified such that the x offset is set to 0x2801CF5C, the width to 1080, and the height to 5. This will decompress LGE_PM_NO_CHARGER (now containing the contents of payload.bin) to 0x08056E14, slightly higher than the stack pointer during decompression. - The image is decompressed and load_res_888rle_image exits. The previous LR has now been overwritten by a pointer to a Thumb-mode pop {pc} ROP slide, to account for possible offsetting error. - At the end of the ROP slide, the following ROP instruction sequence is executed:

pop {r4-r12, pc}    ; r8 is now set to SBL1_ARM_MMU_DISABLE, and r12 is now set to SBL1_THUMB_BX_R8

pop {r4-r6, lr}     ; LR is set to the payload pointer orr r12, r12, #0x1 bx r12 ; jump to SBL1_THUMB_BX_R8

bx r8 ; jump to SBL1_ARM_MMU_DISABLE with lr now set to our payload

Proof-of-Concept, and Future Plans

For those interested in experimenting, a PoC can be found here. Note that this is specifically for the LG Q710, and contains offset specific to the AMZ LG Stylo 4 (Q710ULM, 20c_00_AMZ_US_OP_1121). I'm planning on polishing things up further, however my current boot takeover involves two other vulnerabilities that I'd like to give a bit more time to make sure they're actually fixed/close to being fixed before releasing.

In the meantime I'd be interested in seeing if anyone else is interested in porting this to other LG devices, since I only own a Nexus 5, a Q710 and a Q720. As it is, these vulns will allow bootloader unlocking at a minimum on most older Qualcomm LG devices, and secure EL3 on newer ones, which should be very interesting for anyone interested in finding vulnerabilities in QSEE/similar on LG devices.

[shinyquagsire23]

Nintendo Switch Kernel Patching and Emulation - Achieving Maximum Modification Flexibility with Minimal Replacement

Ever since shofEL2 was released earlier this year it's been interesting to watch how different custom firmwares have tackled the prospect of modifying Nintendo's firmware for both homebrew and piracy applications, and as someone who hasn't really had much stake in that race I feel like it's interesting to watch how different solutions tackle different problems, but at the same time since I do have a stake in a few places (namely, Smash Bros modding, vulnerability hunting, personal projects) I ended up in a situation where I needed to sort of 'set up camp' with Nintendo's Horizon microkernel and have a comfortable working environment for modification.

Binary Patching is Weird, and Horizon makes it weirder.

Probably the biggest difficulty in Switch development I would say is iteration time, followed by a general difficulty in actually modifying anything; even just booting modified core services (ie filesystem management, service management, spl which talks to the EL0 TrustZone SPL [commonly misnomered as the security processer liaison...?], the boot service which shows boot logos and battery indications, ...) requires, at a minimum, reimplementing Nintendo's package1 implementation which boots TrustZone and patches for TrustZone to disable signatures on those services and kernel. Beyond the core services, modifying executables loaded from eMMC requires either patching Loader, patching FS, reimplementing Loader, or something else.

Unfortunately with binary patching there generally isn't a silver bullet for things, generally speaking the three methods of modifications are userland replacement, userland patching, and kernel patching. The first two are currently used for Atmosphere, but the solution I felt would be the most robust and extensible for the Nintendo Switch was kernel patching. Here's a quick rundown on the pros and cons for each method:

Userland Replacement

 - Requires rewriting an entire functionally identical executable - Often not feasible for larger services such as FS - Can easily break between firmware updates, especially if new functionality is added or services split. This makes it difficult to maintain when the OS is in active development. - Added processes can potentially leave detectable differences in execution (different PIDs, different order of init, etc) + Easier to add functionality, since you control all code + Can operate easily on multiple firmwares + Can serve as an open-source reference for closed-source code

Userland Patching

- Adding additional code and functionality can be difficult, since expanding/adding code pages isn't always feasible without good control of Loader - Finding good, searchable signatures can often be difficult - Can easily break between firmware updates, especially if functionality or compilers are tweaked + With good signatures, can withstand firmware updates which add functionality + Often has less maintenance between updates when functionality does change; patching is usually easier than writing new code + Harder to detect unless the application checks itself or others check patched applications

Kernel Patching

- Greater chance of literally anything going wrong (concurrency, cache issues, ...), harder to debug than userland - Minimal (formerly no) tooling for emulating the kernel, vs userland where Mephisto, yuzu, etc can offer assistance - Can easily break between firmware updates, and is more difficult (but not impossible) to develop a one-size-fits-all-versions patch since kernel objects change often - Easier to have adverse performance impacts with syscall hooks + Harder to detect modifications from userland; userland cannot read kernel and checking if kernel has tampered with execution state can be trickier + Updating kernel object structures can take less time than updating several rewritten services, since changes are generally only added/removed fields + Direct access to kernel objects makes more direct alterations easier (permission modification, handle injection, handle object swapping). + Direct access to hardware registers allows for UART printf regardless of initialization state and without IPC + Hooking for specific IPC commands avoids issues with userland functionality changes, and in most cases IPC commands moving to different IDs only disables functionality vs creating an unbootable system.

mooooooo, a barebones Tegra X1 emulator for Horizon

Obviously the largest hangup with kernel patching is debugging, the Switch has RAM to spare (unlike 3DS) and setting up an intercept for userland exceptions isn't impossible to do by trial and error using SMC panics/UART and a lot of patience, but for ease of use and future research I really, really wanted an emulator to experiment with the Switch kernel. I ended up building a quick-n-dirty emulator in Unicorn, and with a few processes it works rather well but it still struggles with loading Nintendo's core processes currently, but for a small and contained test environment (two processes talking to each other and kernel patches watching them), I would say I had reached my goal and it was enough to at least be able to work quickly and sanely on my intercept.

For the most part, the Switch Horizon microkernel doesn't actually use much of the Tegra MMIO; it uses some of the more obvious ARM components like GIC for interrupts, and it also has a large initialization sequence for the memory controller, but as long as interrupts are functional, timers work, MC returns some correct values and SMC return values are all correct, it boots into userland without issue.

I actually found that emulating multiple cores in Unicorn actually isn't all that difficult, provided you're using a compiled language where uc_mem_map_ptr works. Rather than messing with threads, I opted for a round-robin scheduling scheme where I run each Unicorn instance for a set number of instructions, with memory being mapped and unmapped from the running core so that any cached data gets written out before the next core has its turn. A lot of modifications/cherry-picking to Unicorn did have to be made in order to properly support interrupts, certain coprocessor registers (ie core indexes), translation tables (for uc_mem_read/uc_mem_write, vaddr->paddr translation, and just in general there were some odd issues).

Patching Horizon for Syscall MiTM

With a decent environment for modifying kernel, the next issue really just became actually bootstrapping an SVC intercept. Figuring out where exception vectors are located isn't difficult with the emulator handy, but really the issue becomes

1. Extra code has to be loaded and copied by TrustZone, along with kernel 2. New code needs to be placed in a safe location and then given memory mappings 3. Existing code needs to be modified with hooks pointing to the new code

To guide the kernel towards salvation I ended up hooking just before translation table addresses are written into coprocessor registers. This way, the payload can allocate pages and copy code from less-safe soon-to-be-condemned .bss memory for the bulk of the SVC interception code, set up those pages in the translation tables, and then patch the ARM64 SVC handler to actually jump to the new mapping. For ease of development, the mapping is given a constant address along with any hardware registers which it needs to access, as opposed to being randomized like the rest of the kernel.

In the end, patched the kernel executes as follows:

Since hashtagblessed is able to map UART, CAR and PINMUX registers into translation tables, getting communication from the right Joy-Con rail using existing BPMP-based drivers was fairly straightforward, and even without any source code to reference there's a fairly basic driver in TrustZone. Between the transition from emulation to hardware however, I had kept an SMC to print information to the console, but I ultimately ended up using UART even in emulation. On hardware, I got by using UART-B (the right Joy-Con railed) for a while, but had to switch to UART-A (internal UART lines for debugging) due to GPIO issues once HOS tried to initialize Joy-Con.

Identifying IPC Packets, Accurate Results With Simple Tools

With therainsdowninafrica loaded, hooked in and blessed, the next step is actually being able to identify specific IPC requests sent through svcSendSyncRequest, and doing this requires getting our hands dirty with kernel objects. Userland is able to utilize different kernel objects indirectly through the use of handles and system calls. Each KProcess has a handle table which maps handles to the underlying object structures, so translating handles to KObjects is simply a matter of checking the table for a given handle passed to a syscall. To access the current KProcess object which has the handle table, we can use the per-core context stored in register X18 as of 5.0.0 (prior to Horizon implementing ASLR, it was stored in a hardcoded address per-CPU) and the handle table can be accessed through the current KProcess object. Printf debugging was extremely useful while figuring out exactly how KProcess has its fields laid out since the structure changed slightly between versions, and with a bit of reversing added in it's not particularly difficult to figure out exactly where the KProcessHandleTable is at how handles are translated into objects.

Probably the most useful fields in KProcess/KThread, in our case, are the process name and title ID, the handle table, and the active thread's local storage, where all IPC packets are read from and written to. To give a quick overview on how Switch IPC generally works, services are able to register a named port to wait for communications on which can be connected to by other processes via svcConnectToNamedPort. In practice, Nintendo only uses globally-accessible named ports for their service manager, `sm:`. On a successful call to svcConnectToNamedPort, processes recieve a KClientSession handle for sm: which allows those processes to send IPC requests to the service manager to either register/unregister/connect to 'private' named ports managed by the service manager, with sm checking whether the requesting process actually has access to said service.

From a practicality standpoint, since so much communication relies on IPC the most obvious mechanism to establish is a system for hooking requests going into specific named ports, both globally accessible ones such as sm: and private ones provided by sm itself. This kinda leads into why it's important to have access to the underlying KClientSession objects as opposed to trying to track handles; mapping out exactly which KProcess' handles go to what, while also tracking where handles might be copied and moved to is an almost impossible task, however mapping specific KClientSessions to specific handlers avoids the handle copying/moving issue since the KClientSession object pointer does not change in those cases.

Additionally, many interfaces aren't actually accessible from either svcConnectToNamedPort nor sm, as is the case with fsp-srv which gives out IFileSystem handles for different storage mediums. However, by providing a generic means for mapping KClientSession objects to specific intercept handlers, you can set up a chain of handlers registering handlers. For example, intercepting a specific eMMC partition's IFile's commands would involve setting up a handler for the sm global port, and then from that handler setting up a handler for any returned fsp-srv handles, and then from the fsp-srv handler checking for the OpenBisFileSystem command for a specific partition to hook the IFileSystem to a handler, which can have its OpenFile command hooked to hook any outgoing IFile handles to a specific handler for IFiles from that eMMC partition. From that point all incoming and outgoing data from that IFile's KClientSession can be modified and tweaked.

Finally, in order to prevent issues with KProcess handle tables being exhausted, Nintendo provided virtual handle system implemented in userland for services which manage large amounts of sessions. Effectively, a central KClientSession is able to give out multiple virtual handles (with virtual handles given out by virtual interfaces) only accessible through that KClientSession handle. As such, a process can take a service such as fsp-srv and with a single handle can manage hundreds of virtual interfaces and sub-interfaces, easing handle table pressure on both the client and server ends. These handles can be accommodated for by watching for KClientSession->virtual handle conversion, and then keeping mappings for KClientSession-virtual ID pairs. And again, since copied/moved KClientSessions keep their same pointer, in the event that somehow the central handle and a bunch of domain IDs were copied to another process, they would still function correctly.

Tying it All Together

Let's take a look at what it would take to boot homebrew via hbloader utilizing only SVC interception. The key interface of interest is fsp-ldr, which offers command 0 OpenCodeFileSystem taking a TID argument and an NCA path. From a userland replacement standpoint, booting homebrew involves redirecting the returned IFileSystem to be one from the SD card rather than one from fsp-ldr, since Loader (the process accessing fsp-ldr) doesn't really do any authentication on NSOs/NPDMs, only FS does. From a kernel standpoint, we just need to watch for an IPC packet sent to fsp-ldr for that command, hook the resulting handle, and then for each OpenFile request check if an SD card file can better override it. From there, swap handles and now Loader is reading from an IFile on the SD card rather than an NCA.

Taking a few steps back, there's obviously a few things to keep in mind: Loader never actually accesses the SD card, in fact it doesn't even ask for a fsp-srv handle. Since it is a builtin service it has permissions for everything, but the issue still remains of actually making sure handles can be gotten and swapped in. As it turns out, however, calling SVC handlers from SVCs is more than possible, so if Loader sends a request to sm asking for fsp-ldr, we can send out a request for fsp-srv, initialize it, and then send out the original request without Loader even knowing.

Interestingly, the first thing Loader does with its fsp-ldr handle is it converts it into a virtual domain handle, so that all OpenCodeFileSystem handles are virtual handles. This does make working with it a little more tricky since the code filesystem and code files all operate under the same KClientSession object, but it was an issue which needed resolving anyhow. For SD card IFile sessions, it also means that we have to convert them to virtual handles and then swap both the file KClientSession handle and the file virtual handle ID, while also watching for their virtual ID to close so that we can close our handles at the same time and avoid leakage.

A few other tricks are required to properly emulate the SD redirection experience: swapping in handles isn't the only concern, it's also important to ensure that if the SD card *doesn't* have a file then that error should be returned instead, and if the SD card has a file which doesn't exist in the original IFileSystem, we still need a file handle to replace. To accomodate for this, the original FileOpen request is altered to always open "/main" and if the SD card errors, that virtual handle is closed, and otherwise the SD handles are swapped in.

The end result is, of course, the homebrew launcher being accessible off boot from the album applet:

Other Potential Thoughts for Kernel Stuff

* Process patching is as easy as hooking svcUnmapProcessMemory and patching the memory before it's unmapped from Loader. Same goes for NROs but with different SVCs, all .text ultimately passes through kernel. * Reply spoofing. IPC requests can simply return without ever calling the SVC, by having kernel write in a reply it wants the process to see. * SVC additions. I'm not personally a fan of this because it starts to introduce ABIs specific to the custom firmware, but it's possible. One of the things I'm not personally a fan of with Luma3DS was that they added a bunch of system calls in order to access things which, quite frankly, were better left managed in kernel. The kernel patches for fs_mitm also violate this. Userland processes shouldn't be messing with handle information and translation tables, i m o. That's hacky. * Virtual services and handles. Since the intercept is able to spoof anything and everything a userland process knows, it can provide fake handles which can map to a service which lies entirely in kernel space. * IPC augmentation: Since any IPC request can be hooked, it can be possible to insert requests inbetween expected ones. One interesting application might be watching for outgoing HID requests and then, on the fly, translating these requests to the protocol of another controller which also operates using HID. * IPC forwarding: similar to augmentation, packets can be forwarded to a userland process to be better handled. Unfortunately, kernel presents a lot of concurrency issues which can get really weird, especially since calling SVC handlers can schedule more threads that will run through the same code. * As currently implemented, A32 SVCs are not hooked, however this is really more an issue if you want to hook outgoing requests from A32 games like MK8, since services such as Loader will generally only operate in a 64-bit mode.

Source

Horizon emulator, https://github.com/shinyquagsire23/moooooooo

therainsdowninafrica, https://github.com/shinyquagsire23/therainsdowninafrica

[shinyquagsire23]

Nintendo and Executables, Emulation and Piracy

Edit (Nov 2 2022): This article contains some prior speculation and grumbling about Cemu, which is no longer closed source. Even prior to open sourcing, Cemu aided in documentation efforts for decaf. At the time though, contributions to WUT were solely done by decaf-emu and others.

While hanging around in the Citra and yuzu Discord servers this question (or some variant of it) has arisen several times, "Why was Cemu/yuzu able to develop so quickly?", and while there's some fairly obvious answers with regard to Cemu's actual development strategies (open-source vs closed-source, Patreon, etc) and some misconceptions with yuzu and the Switch I feel like these questions are a good opportunity to write on some of the factors which might play into acceleration in emulation development and reverse engineering efforts in general while also going over some of Nintendo's "DRM" and its relationship with emulation and piracy.

Also before anyone gets their jimmies rustled over piracy I think it goes without saying, my intentions talking about piracy in this article are not an endorsement of it, I just think the requirements and methods between Nintendo’s operating environments are interesting.

QUICK BACKSTORY

Just to give a quick rundown on credentials and I suppose to maybe give an idea on my familiarity with Nintendo stuff. I did some super basic GBA ASM hacking starting around 2010 or so but I started hacking ‘modern’ Nintendo consoles with the 3DS in late 2014 when the homebrew launcher for ninjhax was released. Somehow managed to implement a kernel exploit based on reverse-engineered Gateway code (though firmlaunchhax is relatively simple as far as exploits go), joined up with the rest of KARL3DS (later SALT), did some CFW/vuln stuff for 3DS for a bit, tried to bootstrap a polished Wii U CFW joint with SALT, TiniVi, SciresM and others (it didn’t totally flesh out but I did personally get native homebrew in a decent state via the Wii U Toolkit/WUT), joined with ReSwitched shortly after the Switch launch, later was kicked out, messed with Switch HID/Joy-Con stuff, found shofEL2 with some people independently, started a bit of a fuss with Linux stuff and Real Hackers and now I just do this stuff for fun I guess.

3DS ARCHITECTURE

Quick rundown on the 3DS: The kernel, codenamed Horizon, is a microkernel capable of handling multiple processes at once, along with threading, memory management and communication for those processes. Horizon and all 3DS games/applications run on the dual core (quad core for New 3DS systems) ARM11 processor in the SoC. Additionally, the 3DS has an ARM9 security coprocessor responsible for dealing with eMMC/gamecard protocols, filesystem access, signature verification, encryption, and other things. So if an application wants to access an encrypted content container on the SD card, it asks the FS process for content in that container, FS asks Process9 over PXI if it can get access to that container, Process9 checks permissions in the process exheader to see if permission to this container is granted, if it is Process9 will handle decryption and pass decrypted data from the container back to FS and back to the application. To throw in an additional example, if an application wants to decrypt a Mii QR code it has to scan the QR code, get the data, pass the data to the APT service process to ask for it to be decrypted, APT hands the data to PS and asks for it to be decrypted, PS asks Process9 over PXI to decrypt the data, then the data gets decrypted and it gets passed back to PS, back to APT, and then back to the process which needed a Mii QR decrypted. Granted, I might have missed a step or two in there and I've simplified things a bit, but this is effectively the way data gets passed around within their system.

APPLICATION ARCHITECTURE

The main container which holds executables on 3DS is the CXI container, which is mostly seen on the SD card and NAND under the .app file extension. For SD cards, these files are encrypted with a per-console key, and on NAND there is an encryption layer over the entire CTR OS FAT partition instead. After the first layer of crypto on the file we get to see a signature over the CXI header, the header itself which includes some metadata, ExeFS offsets and lengths, RomFS offsets and lengths, extended header offsets and lengths, and hashes over most of the remaining content such that the signature hash going over the header also covers any and all content within the container. As such, all content in this container is signed and verified.

ExeFS is the file container which contains the code binary along with the application's banner, icon, and metadata (app strings, region specifications, etc), and RomFS is the file container which contains any and all game data that isn't just compiled into the executable. These containers can be mounted by the SDK and accessed by applications depending on permissions. Going deeper into the actual code binary though, the main executable is entirely contained in the ExeFS file ".code", which is a single compiled block which contains the applications .text, .rodata, .data, and .bss. The offset and length of each of these sections is contained within the exheader pointed to in the CXI header, and stack memory is allocated at 0x10000000-<stack size specified in exheader> (stack memory for other threads, however, is usually allocated from the heap). Heap memory is mapped using system calls to 0x08000000 or 0x30000000. While ExeFS and RomFS can be accessed by most applications, the exheader can only be retrieved through the Process Manager service on the ARM9 via PXI and is mostly used by the loader service on the ARM11 and on the ARM9-side to validate permissions.

As far as actually interacting with the hardware goes, SDK code is always linked statically into the code bin, and SDK code is what actually handles heap management, filesystem mounting, and other things. For hardware and OS interaction, the 3DS uses several dozen system services running as their own processes, and the main application does IPC queries through system calls which translate the parameters and addresses between processes. To get a bit more specific, the main application will get a handle for "srv:" from a system call, and this handle will be used to get handles for other system processes, dependent on the application permissions given to the service manager which manages "srv:". If an application needs to talk to the GPU, it gets a handle for the gsp service from srv and from there will use IPC calls to ask the gsp service to send commands to the GPU hardware. If an application wants to install an application, it needs a handle for "am:u", and *if the application has permission to talk to this service*, a handle will be returned and the application can ask "am:u" to send a file handle to send IPC write requests to write CTR Installable Archives (CIAs) to so that "am:u" can handle the actual install. Side note, this allowed 3DS to create CIAs from eShop contents at runtime since CDN content was identical to what would be copied onto the SD card/NAND, albeit with a layer of crypto on top.

REVERSE ENGINEERING

The difficulty in reverse engineering, however, comes as a result of whatever being beyond the IPC layer being largely a black box: there are no symbols, if you're lucky you might get strings, but otherwise you're on your own if you want to know what command 7 in some service does. Without being able to decompile the service, you might be able to fuzz command 7 and figure out how many arguments it wants, what kind of address or handle translation it expects, etc. But at the end of the day you've only got guesswork and maybe some usage cases in the application. With access to decompiled service code, things get better, but not too much better. There are still no symbols and if you want to know what a command *actually* does you need to document a significant amount of decompiled code.

There is one exception, and it is an extremely rare exception on 3DS: 3DS *does* have support for dynamically linked libraries in the form of CROs, or CTR Relocatable Objects, stored on the application RomFS. CROs can be dynamically loaded, linked and unloaded and unlinked to and from an application's memory map at runtime. Since the ExeFS code bin is just a straight binary, a file called static.crs is stored along with CROs to describe the layout of functions in the static code bin, and optionally along with that, symbols can be described in this file. Effectively it acted as a shim for taking .code from a blob to a linkable ELF-alike, and at a basic level, CROs effectively function as ELFs except what would be every ELF section has its offset specified in the header along with the additional code signing measures which reside there. While not many games did ship with symbols, there were some big games like Pokemon Sun and Moon and Smash for 3DS which ended up shipping with a significant portion of their application’s symbols, making reverse engineering at least slightly easier. Some games like Steel Diver ended up shipping with ELF files in its RomFS which just had all symbols outright, so it's not all doom and gloom, but you're still at the mercy of software updates and what functions applications actually end up using unless you reverse things by hand in the relevant services.

EMULATION

As far as what an emulator like Citra actually emulates, it largely just emulates system calls and any IPC calls sent to other processes will be handled in high-level emulation rather than emulating the system processes on a lower level. This is slowly changing of course, because in order to emulate launchable applets such as the software keyboard, emulating multiple processes is required. The difficulty largely comes from emulating the (often strange) PICA200 GPU, along with emulating threading behavior and other syscall behavior of the 3DS kernel. Even with the wealth of reversed functionality, there are still several services with undocumented error behavior and other behaviors which have yet to be discovered.

I WANT TO PIRATE ON 3DS - WHAT ARE THE SECURITY IMPLICATIONS?

Practically, piracy on the 3DS requires full control over both the ARM9 and ARM11 cores. Because applications are bound to the signature verification on the ARM9, and also because all 3DS binaries are one solid lump of nonrelocatable code, it's not easy to pirate games even with arbitrary code execution. What specifically makes it difficult to pirate games without ARM11 kernel access (given gspwn, which allows any code to be overwritten) is being bound to the memory permissions of the application being taken over, one application might start read+write data sections at 0x120000 while another starts it at 0x240000, so it becomes a game of getting memory permissions to match (or alternatively, finding an application which sufficiently-sized sections and then statically recompiling the code to match those bounds). On top of that, all accesses to RomFS have to be remapped to another filesystem (or over network), which is possible as seen with HANS and *hax which transfers SD card file handles from applications which have access to the SD card (home menu) to other applications. Additionally, the permissions of the base application must match the to-be-pirated application, or the to-be-pirated application must have its code patched to no longer require permissions outside of the scope of the base app.

With ARM11 kernel, the issues of memory mappings are less of an issue since system calls can be granted to remap sections as appropriate or even spawn processes from scratch, and the issue of service permissions is lessened because the service manager which checks permissions can be patched to give permissions to all services. However, RomFS is still tricky to deal with and it would still require some sort of loader to set up and patch the application while avoiding the ARM9. Alternatively it is possible to install a select group of applications which came bundled on certain special-edition 3DS systems which were signed with global system keys instead of being tied to any one specific system via tickets.

With ARM9 kernel access, signature checks can be dropped entirely, allowing applications to be installed to the home menu as usual.

WII U ARCHITECTURE

With the Wii U, things get a lot less... nice. The Wii U has a quad tri-core PowerPC processor along with an ARM9 security coprocessor (sound familiar?). Cafe OS, or COS, is the main component running on the PowerPC for Wii U, and much like the Wii, IOSU (internally just called IOS) runs on the ARM component. Comparing the Wii U to the 3DS, IOS basically runs most if not all of what would be service processes on a 3DS, as far as hardware goes the PowerPC effectively only gets to talk to the GX2 GPU and the audio DSP (there's a bit more exposed than that but those are the big ones I can recall). Filesystem access, USB, Bluetooth, network drivers, input drivers, eShop/friend code/BOSS/account https protocol, etc is all handled in IOS. The PowerPC pretty much *only* handles games and applications.

COS doesn't support any real application multitasking, instead it has a single process running at once with multiple processes loaded into memory to be switched to as appropriate. The two main memory areas relevant to this are MEM2 which is used for storing executables and heap, and MEM1 which is used as video/framebuffer memory. If an application wants to "multitask" over to the Home Button Menu (HBM), it has to be waiting for a signal from ProcUI telling it that the home button has been pressed, and on that signal the application has to unload all of MEM1 and prepare its threads to wait (with the exception of Core 2, which is allowed to continue executing while multitasking in HBM, web browser, etc). If a process wants to intentionally switch over to another application, it has to ask sysapp to signal a launch which will trigger ProcUI signaling the application to close up and exit. If an application doesn't signal to ProcUI that it's ready to switch to another process, COS will just never switch to another process.

The Wii U filesystem is a lot closer to *nix in that you can mount/link different devices and folders to the filesystem. The Wii U has three main storage mediums, SLC (a dual-bank 512MB NAND on the board, with one bank used for Wii U and one for vWii), MLC (the main 16/32GB eMMC chip), and USB storage devices. IOS mounts each of these to /vol/storage_slc/, /vol/storage_mlc01/, and /vol/storage_usbXX/ respectively. Titles can either be installed as user programs which can be deleted or system programs which cannot be deleted in the settings app, and the only real difference as far as installation is that one gets installed to the `usr/title/` folder on a device and one is installed to the `sys/title/` folder. Interestingly, the main filesystem is actually accessible to the Wii U, as opposed to 3DS where applications are largely sandboxed away from the raw filesystems. There are, however, permissions checks to prevent applications from meddling with files they don't own: The Wii U filesystem has a full RWX owner/group/everyone permission system for files which specifies which files belong to what app, with groups to allow access of files to other applications or if the file can just be accessible to everyone. So if a title wants to access content from another title, it can access the file outright if it has permissions for it. For some of my GX2 programs I ended up doing a chmod to change the permission of a shader in the Health and Safety application so that I could access it without having to redistribute it in my application. So with permissions changed I could just open "/vol/storage_mlc01/sys/title/00050010/1004E100/content/shader/texture2D.gsh" directly.

APPLICATION ARCHITECTURE

A title consists primarily of three folders on the filesystem: code/, content/, and meta/, each of which gets mounted to /vol/code/, /vol/content/ and /vol/meta/ respectively so the application doesn't have to step through the actual filesystem to open its files. Ownership and group permissions for the files in these folders are set at install time, and all files in the original install content containers are extracted onto the filesystem. The running owner/group is determined by two XML files in code/: app.xml and cos.xml. app.xml specifies the OS version the application can run on (ie updater titles have the updater COS TID here), the group ID it runs with, and the SDK version it requires, the application type (update vs app), etc. cos.xml includes all of the permission masks for each IOS process group, whether the application has a JIT area, the maximum code area size, stack sizes, and other bits. So if an application wants to be able to access the SD card, it needs the appropriate permission bits set in cos.xml, or if an application wants to install other applications it needs the appropriate MCP permissions.

/vol/code/ also contains the application RPX and any additional RPLs, with the RPX being the main application and RPLs being dynamically loaded libraries. RPXs/RPLs share the same format and they are effectively ELF files with zlib compressed sections along with import/export sections for linking with other RPLs. RPLs can be loaded and linked dynamically at runtime or automatically when the RPX/RPL is loaded using .fimport_<RPL name> sections. All SDK code is held in RPLs on SLC, so most applications are either just an RPX, or an RPX with some extra libraries like webkit, curl, cairo, openssl, zlib, etc held in RPLs. As an added note, files on SLC actually end up being cached in a ramdisk by IOS to improve load times, though this was actually the reason some CFWs like Mocha ended up having to redirect /vol/system/config/system.xml to /vol/system/config/syshax.xml to prevent Haxchi bootloops, system.xml ends up getting cached too and the ramdisk is not cleared on soft reboots (this ramdisk can also cause issues in running higher/lower firmware versions with NAND/MMC->SD redirection since files from before the reboot will linger into the next COS 'session').

LET'S DIVERT A BIT - TITLE INSTALLATION AND VERIFICATION

Up to this point I haven't actually mentioned anything about title verification, and that's because it gets a bit weird on Wii U. To start, the title "package" format is similar to what you would actually see as an installed 3DS title, there's several %08x.app files, several %08x.h3 files, along with a title.tmd, title.tik, and title.cert file. The ticket and the cert end up going elsewhere on the filesystem, however title.tmd and an additional title.fst are kept in code/ to validate files. The .app files can be either encrypted with the title key encrypted in the ticket with the Wii U common key, or they can just be decrypted. 00000000.app always contains the FST which describes the files and folders stored in the rest of the .app files (a single .app can contain multiple files in the resulting title filesystem). The FST is also used on disks to specify which sectors go with which files, and the FST found on disks will match downloadable games.

The TMD contains a signed header specifying the number of contents, and a hash over the content chunks outside the header, which contains information describing each .app (is it encrypted, what type of content is it, what is the hash of the .app file). What effectively ends up happening for content verification is that any files which need to be verified get their own .app file so the hash in the TMD will match the hash of the file on the filesystem. Files which are *always* validated include anything in code/, along with select other files, and this is consistent with all applications. Were it not, you could simply replace an RPL and get code execution easily.

Since titles are kept extracted as files on filesystems instead of one big verified chunk like on 3DS, this opens some interesting potential attack vectors. The most obvious vector, and the most known, being contenthax, which allows unvalidated content in the content/ folder of titles to be modified at-will. With Haxchi, this is used to get trivial ROP in Virtual Console games which have the JIT area enabled. Some apps such as the browser also include html files, potentially opening up vectors for offline WebKit vulnerabilities (provided they're stable enough that the browser doesn't end up bricked). Additionally, applications which scan the filesystem for files are able to have files added, bypassing any potential signature checks. This doesn't, however, work for any RPX or RPL files in code/ or on SLC, since loaded RPLs always have their existence in the FST checked along with their hash in the TMD having to match. The benefit of less validation of course comes in loading speeds and better disk durability since slight errors have a lower chance of hitting code and a greater chance of hitting content which is not verified.

LOADER.ELF

Back to executables, RPL and RPX loading is done in COS by loader.elf, which is loaded on startup by the PowerPC kernel. loader.elf is pretty much the absolute bane of my existence and I really don't understand why Nintendo felt the need to include an ELF loader in kernel just to load in a much worse ELF loader, but to say the least it does an awful job of parsing RPLs. Luckily it has debug output accessible from IOS which actually specifies what it didn't like about the RPL it just tried to load. RPLs are effectively ELF files with compressed sections and import/export sections which allow them to link to other RPLs at load time. If an app wants to load functions from proc_ui.rpl, it has to include a .fimport_proc_ui section and the functions it wants to import specified in that section. If the functions don't exist, loader.elf will complain and refuse to load. If the system cannot find proc_ui.rpl in code/ or in the SLC OS libraries, it will also refuse to load.

Where RPLs become a bit of a pain point for homebrew and GCC is mostly in loader.elf; getting GCC ELFs into the RPL format is actually a fairly significant challenge. For a start, sections are expected to be written into the RPL in a particular order: Section CRCs and FileInfo are written first, then .rodata and .data, then imports/exports/symtab/strtab, then .text, and then relocation data. The list index order of sections also matters, CODE sections must be first, then DATA, then relocations, then imports, and then strtab/symtab/etc, with CRCs and FileInfo at the end. If any of these are incorrect, loader.elf will not load the RPL. Rodata must be marked as RW. Writable. There is no negotiation, it doesn't make sense, but loader.elf will refuse to load an RPL if rodata is not marked as writable. Every one of Nintendo's RPLs has .rodata marked as RW. All sections have specific alignments expected. A tempSize value is stored in FileInfo, presumably so that loader.elf knows how much RAM it needs to allocate to hold relocation data for linking. Except it doesn't use it, it just calculates the value from the section table and uses its calculated value to scrutinize your tempSize so that it can avoid loading the RPL.

As if loader.elf being extremely picky about ELF layout wasn't bad enough, Wii U's relocations are a massive pain to deal with. The Wii U does not use any sort of GOT (nor does it support it), and loader.elf only implements a limited subset of relocations: ADDR16_HA, ADDR16_LO, REL24, and ADDR32. R_PPC_RELATIVE is not supported, so for every R_PPC_RELATIVE relocation GCC generates it must to be converted to R_PPC_ADDR32 instead. Even more irritating, GCC likes to create R_PPC_RELATIVE relocations to completely different sections than the section the relocation is being operated on even though sections are supposed to be individually relocatable, so each of these relocations must also be converted to ADDR32 and either a symbol index or a memory section reference ($TEXT, $DATA) plus an addend. Even more amusingly, GCC would also create relative jump tables in .rodata (ie each entry is the distance from that .rodata address to .text), and these relative jump tables didn't even have relocations written in so rodata isn't actually able to be relocated away from text. What ends up happening is that since .rodata ends up in $DATA memory relocated completely separate from $TEXT, the calculated distances no longer are accurate. The only solution then, of course, is to lump .rodata in with .text so the relative offsets between .rodata and .text can be guaranteed.

REVERSE ENGINEERING AND EMULATION

Now that the nitty-gritty details on RPLs are out of the way, what's actually kind of interesting about Wii U as far as emulation goes resides entirely in the way Nintendo decided to set up RPLs. On 3DS, all SDK code is compiled into code.bin statically, and code.bin is always located at 0x100000 in the process map. Names and locations of SDK functions cannot be easily gained on 3DS, so the minimum option for emulation is emulating down to the IPC layer. With Wii U, all SDK code exists in RPLs, all SDK RPLs have symbols for each function which can be imported into applications, and there's basically no real IPC setup at all (except between the ARM's IOS and PPC's COS, but this is mostly handled at the SDK level and not by applications). This is a *huge* deal for emulation and a big contrast between 3DS and Wii U, because rather than having to guess what an IPC call does and what arguments it takes and dealing with translation of handles and such between processes, Wii U has every SDK function name laid out by design. The only guesswork remaining is what arguments every library function takes, and how the data actually gets handled. This also means that the likelihood of Wii U SDK materials being useful for emulation is much higher, since SDK headers would specify what arguments every RPL function takes, along with enums and struct definitions, and unfortunately without source code it's unlikely that the integrity of an emulator like CEMU can actually be gauged.

Just because I find it a bit interesting, and it's a decent contrast to Switch/3DS, the IPC interface between COS and IOS is actually an IPC shim for their ioctl interface. Every IOS service has a /dev/whatever device and the actual IPC commands themselves are your usual file operations for ioctls (open, close, read, write, seek, ioctl, etc). There's also a bit of permissions stuff so that processes can't poke interfaces they don't have permissions for but I just thought it was worth mentioning since Nintendo never really returned to this whole *nix-alike idea later on.

I WANT TO SAIL THE SEVEN SEAS ON MY WII U - WHAT ARE THE SECURITY IMPLICATIONS?

Practically, the Wii U only requires PowerPC kernel to pirate games. On 3DS this was a similar case, but Wii U handles most of services and permissions on the ARM-side in IOS, so why doesn't this cause any issues? Well, the issue comes down to the ease of relocation and skirting permissions. Much like the home menu on 3DS provides SD card access for *hax-based homebrew, on Wii U Mii Maker has SD card access in order to save QR codes to the SD card, and given PowerPC kernel access it is possible to take over this application and use that SD card access. Games such as Smash 4 also provide SD card access for screenshots. This application takeover ends up being critical as far as providing permissions goes.

The second part of Wii U piracy lies in loader.elf. While the PowerPC portion is more than capable of reading RPXs from discs/MLC/SLC itself, the reading is actually done entirely on the part of IOS's MCP process. Effectively what happens is once the permissions of the incoming application is established in IOS (these permissions being from the XML files in code/), loader.elf asks IOS for an RPX or RPL. MCP in IOS will check each of its valid RPL paths for file of that name in either SLC (for SDK RPLs) or the code/ folder, and if there is a valid RPL it begins to send it over, and loader.elf will buffer the RPL and load it. If loader.elf is compromised, this can lead to an attack where IOS loads in and believes an application like Mii Maker or Smash 4 is being loaded, but loader.elf can merely discard all the data being sent and load in its own RPX from the SD card. This RPX then runs under the context of what would have been Mii Maker or Smash 4, and because loader.elf is already compromised, mounts such as code/, content/ and meta/ can merely be avoided by patching all filesystem functions to redirect to the SD card since the applications being taken over have access to the SD card. Permissions issues can also be patched out effortlessly, since RPLs are relocatable and aren't particularly constrained. This is why loadiine is able to work by only taking over the PowerPC and not the ARM security processor.

SWITCH ARCHITECTURE

The Switch is probably the most interesting of Nintendo's modern consoles, mostly because it's the Hot New Thing but also because internally it ends up being an interesting synthesis between 3DS and Wii U ideals, usually (but not always) picking the best parts from both. To start, the Switch runs on a variant of Nintendo's Horizon microkernel, though it isn't quite the same as 3DS since it has been rewritten. Internally, it is dubbed Horizon OS, often abbreviated HOS much like Wii U's Cafe OS was COS. At the Switch's core is the Tegra X1, giving the Horizon kernel a 64-bit quad-core AArch64 processor to operate on, along with a TrustZone implementation to use for security. Much like 3DS, all hardware drivers and OS details are handled in their own separate processes, with many of the process being very similar to 3DS but, again, are rewritten. IPC in usage is similar to 3DS but the actual structure of IPC calls has been revamped and improved, with different descriptors for data going into another process, coming from another process, or for instances where data should be sent from one process and then modified and returned by the target service. Additionally, for instances where a service will require additional memory to operate or larger amounts of memory should be transferred, shared memory syscalls have been revamped to allow for different types of transfer memory and shared memory. For instance, the nvservices driver (a service which really is just a shim for NVIDIA's usual GPU drivers) requires that applications turn a chunk of its own memory into transfer memory so that a handle for that memory can be passed for nvservices to actually operate with. As such the application ultimately controls how much memory to use for graphics and all memory limitations can be placed on the application itself rather than having a complicated setup between the privileged processes, nvservices and the running application to determine allocation amounts.

As far as security goes, the critical difference between 3DS services and Switch services is that just about all of what used to be handled by 3DS Process9 has been moved into the respective services in Horizon; TrustZone works pretty much exclusively with crypto secrets and runs on the same processors as everything else (though most operations will only take place on core 3 specifically). By keeping all sensitive crypto secrets in TrustZone but allowing HOS to operate with content-specific keys, the filesystem service can utilize ARM64 crypto extensions and talk to devices directly, reducing the overall IPC overhead for faster load times and performance.

Lastly, given the recent shofEL2 vulnerability dropping, I feel it would be good to also go over the boot process of the Switch just as a general overview. TX1's boot starts on the BPMP, a small ARM7 responsible for spinning up the rest of the cores on the device. It is also responsible for managing low-power sleep modes to an extent. I'll avoid going too much into detail since https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html covers things a lot better, however you can stop reading as soon as the boot ROM jumps to the bootloader since that's where Nintendo gets funky. Nintendo's package1 is the first piece of code loaded after bootROM, and this is stored on the eMMC boot partition bank separate from the general-use 32GB partition bank. package1 is responsible for decrypting itself and checking fuses, showing error screens, loading package2 from eMMC into memory, (formerly) showing the Nintendo logo, and starting the CCPLEX 64-bit A57 processors into TrustZone which would then verify and decrypt package2 and then move to EL1 in order to execute the kernel. Because of the diversity of ARM64 processors, TrustZone also handles the PSCI v1.0 protocol responsible for power state management for shutdown, rebooting and sleeping.

APPLICATION ARCHITECTURE

Applications are primarily stored as NCA files, with files on NAND being stored outright and SD files being encrypted with a NAX wrapper (although still retaining the NCA extension). Unlike 3DS, NCAs generally only contain one type of content per archive: program code, program control data, program metadata, or program content. For content and metadata, a RomFS/PartitionFS partition will contain the contents for that NCA, and for code, a PartitionFS is used to specify individual files which are part of the NCA. All of these details are handled by the fs process and are not exposed to the running applications and services.

Similarly to Wii U, NCAs can either reside as a system app on the SYSTEM partition of eMMC or as a user app on the USER partition, though on Wii U this separation was only done via folders on each device but the idea is the same.

For code NCAs, there are two variants of program files. For services, there is a single main file and a main.npdm. For applications, there exists a main, main.npdm, rtld, sdk, and optional subsdkX files. Except for main.npdm, all of these files are NSOs. Pulling from some of the better ideas of Wii U and 3DS, NSOs specify offsets and sizes for text, data, rodata, and bss sections in one big structure up front with offset 0x4 after the NSO text section containing a pointer to what is the equivalent of an ELF's .dynamic section to specify relocations, symbol tables, and other metadata. Much like the Wii U, all SDK components reside separate from game code in the sdk NSO, which provides higher level functions and a layer of abstraction between what developers actually use and the underlying IPC calls sent out to services.

Unlike 3DS and Wii U, Switch executables run in a randomized address space, and as such are required to be able to relocate themselves and link themselves to other loaded NSOs at runtime. With SDK apps this is handled from the rtld NSO which is based on musl. Also in stark contrast to 3DS CROs, Switch NROs are also held to this expectation and unlike 3DS, doesn't require loaded code to be modified for linkink to the main executable since everything just has a GOT and can be set up with rtld. This does mean though that sections are not separately relocatable like on the Wii U since there's an expectation of having all the sections for any one NSO/NRO in the same block of addresses. Once an executable is relocated, setup typically involves asking the kernel for memory, requesting a service manager (sm:) handle and then going through the setup for filesystem access, input sharedmem, video, and so on. Like 3DS, the service manager uses ACI permissions to determine if it should give handles to processes when requested, though prior to 3.0.1 if you didn't send the initialize command it would just give you any service handle you asked for.

main.npdm handles permissions exclusively (as opposed to the 3DS where the exheader also managed code sections), and the file itself is signed individually with separate keys from the NCA. However, there is actually a slight bit of unsigned leniency: Application permissions are defined twice in the file, once in the ACID header and once again in ACI, with the ACID header being verified and ACI unverified. The ACID header defines the min/max title IDs, the maximum file permissions, the maximum service permissions, the maximum kernel permissions and a few other flags. This way Nintendo is able to sign ACIDs with the absolute maximum permissions normal applications should have and the ACI portion is only able to go up to those maximum permissions but isn’t required to actually give out those maximums. The real benefit, I’m assuming, is that development units cannot merely sign themselves higher permissions; the keys to do that remain with Nintendo at all times. As far as retail applications go it doesn’t really make that much of a difference since NCAs are already signed anyhow.

Some NCAs can, however, contain other data. Program metadata and icons get their own NCA, and update data has its own NCAs. While NCAs have their own signatures internally, their naming scheme also is a large part of their verification; each NCA is named after the hash of its contents, making verification for corruption (given a filename) as simple as hashing the file and comparing to the name. Since the NCA magic is only visible after decryption the files tend to look like garbage regardless of corruption, so hashing is a decent check. It also makes it impossible to guess an NCA’s filename on Nintendo's CDN, preventing early access of game contents until the CNMT NCA indexing all a game’s contents is updated (and the hash of *that* is given by eShop servers)

REVERSE ENGINEERING

Reverse engineering on Switch, as it turns out, is actually much easier than it was on 3DS and maybe at times is as easy as Wii U, but there are definitely areas where work is still required. On version 1.0, many services actually contained a wealth of symbols, but often times it feels like symbols aren't entirely complete, however where symbols were lacking there was usually a slew of asserts which would not only provide function names, but variable names as well.

Additionally, since the sdk NSO is a separate linked binary with its own symbols for everything an application could want to call (and since all IPC calls originate from the sdk NSO) it's much easier to isolate and document functionality. Though, it's worth noting that system applets statically link the sdk NSO into the main application in order to save space and possibly keep symbols to a minimum when reversing things like web applets.

EMULATION

Switch emulation is actually sort of interesting, similar to the 3DS there's a layer of mystery between a lot of Switch IPC calls, however since the kernel is based on and functions very similarly to that of the 3DS, it has allowed emulators like yuzu to reuse components from Citra pertaining to syscalls and (some) IPC. However since the sdk NSO is separate, it is also possible (in theory) to just hook those SDK functions and opt more for a Wii U-style emulation approach of emulating the SDK behavior. Most emulators have, however, opted for the lower-level emulation approach which is probably a good thing in the long run anyhow.

The wealth of symbols and strings found in Switch services has made reverse engineering them for emulation much easier, and the more modern GPU architecture paired with projects like nouveau has made quicker work in getting shaders decompiled and emulated as opposed to the mystery chip that was the PICA200. Contrary to popular belief, however, there is not much else about the TX1 being a “generic chip” that actually helps much with emulation, maybe with the exception of understanding some driver behavior better because of the TRM.

I WANT TO PIRATE ON SWITCH - WHAT ARE THE SECURITY IMPLICATIONS?

Practically speaking, piracy on the Switch doesn't strictly require TrustZone access at all, since it doesn't really handle all that much except for crypto secrets, and given the right vulnerabilities it's likely that even kernel isn't strictly required. Since Switch code is relocatable it's also much more flexible with where it runs, meaning that theoretically something like a JIT area could be enough, but practically there are the same restrictions as 3DS with services and RomFS. However, with Switch even a DMA vulnerability is a lot more flexible; since ASLR is in play all that is required is a larger .text section and a larger .data section, and then NSOs can just match the .data section starting points and hook the .text start and it will relocate itself to work from that location. And again, RomFS access would need redirection in order to not attempt accessing the original RomFS.

Given kernel access (or probably even just fs ROP), it's more than possible to just have fs to load game contents from the SD card as has been seen with the LayeredFS piracy (which has an uncanny resemblance to loadiine it I'm being honest). In theory it would also be possible to do this sort of MiTM for modding RomFS files from a core process (or smhax) using sm reregistration and some ROP but it would be more effort than it's worth by this point.

[shinyquagsire23]

Picking apart the Joy-Con: Heap Leaks, Bluetooth and Command Structures

Coming from our last post, we left off with the conclusion that the only real way to figure out Bluetooth would probably be to leak the at-runtime firmware being executed. From there I initially set out to attempt fishing out some data by using SPI writes to modify the firmware patches, however I was disappointed to discover some things: When writing to SPI, the firmware itself actually limits writes from 0x6000 to 0x10000, anywhere else will unfortunately be ignored entirely. My attempts to interface with the SPI were also unsuccessful due to difficulties dealing with 1.8v logic and lack of parts.

Since I couldn't just dork with code patches on the SPI flash for a while, I had to examine the attack surface of the UART/USB-HID protocol. The big commands which stood out to me were the Amiibo commands which would output a very large amount of data, the SPI read command and basically anything else which actually returned data at request, which were actually pretty scarce. Experimenting with the SPI read didn't yield much, messing with the command syntax to try reading more than 0x1C of data or trying to read from invalid locations just resulted in a normal read with nothing out of the ordinary... but what would happen if we tried to write more than we could store in the UART packet? Crafting a SPI write packet with a write size of 0xFF to some unwritten data at 0x7000 yielded some extremely interesting results when read back from the flash:

For the first 0x1C of our data it has done the expected write from the packet, in this case I sent all 00s. The rest, however, is some data leaked from the heap, with a header of BADDBADD, what looks to be an address pointer and some 02 F0 00 00 value. Following that is something fairly interesting, what vaguely looks to be a fragment of a UART packet with the 92 00 .. .. data. Some heap bits don't have that data however. The real question however is: Can we leak heap leftover from being connected over Bluetooth?

To check if this were possibly the case, I went into System Settings > amiibo > Register Owner and Nickname to get some amiibo read packets going since those packets were much larger than the usual which should have shaken the heap up a bit and got things to shuffle around. After making several heap leaks I sifted through them via scrollwheel analysis to determine any interesting patterns. Most notably, there are a few interesting things which can be seen:

Following the heap header, at 0x3C, 0x88 and 0xD4 in the GIF there are one of two types of data: The 92 00 31  .. .. packets reminiscent of the usual UART and USB-HID packets, though if it were to be UART it would be missing a header, however it does seem that there are wired packets within that heap data. Otherwise the data is... unknown, but interesting nonetheless. In some of the packets we see an XX YY value where XX tends to be 01, 10, or 11 and the second byte, in some but not all cases, seems to increment. The real significance though is the fairly limited selection of bytes: 01, 10, and 11 are all values which directly follow the initial UART header. Going off the assumption that these packets were indeed Bluetooth packets, I decided to try sending some 01 packets with my Pro Controller and what I ended up getting was... rumble. And, sure enough, I could send a few of my old test packets and I got the same extreme vibrations from my initial wired vibration tests. Taking my UART SPI read packets and cutting them down to the 01 command also worked perfectly. So with this, there is an effective model to send commands over UART, USB HID and Bluetooth HID:

The rumble bit was actually interesting because it explains some of the actual portions of packets I didn't quite understand before, and with that I feel that I can give a proper command structure for Joy-Con packets:

In this structure, the first two portions highlighted in red and green are exclusive to UART-based communications. USB HID utilizes the the green, blue and yellow sections prepended with an 80 byte, and Bluetooth HID is able to take only the blue and yellow sections alone (without any checksums). Having a clearer picture of the command structure between all three methods of communications, and also knowing a bit about the vibration and IMU enable commands which use subcommands 40 and 48 accordingly, I set out to do some fuzzing to find the LED commands. Given the wide range of subcommands already under the 01 command, I figured that the player LED enable command would be a subcommand which takes one byte, with 4 bits to select which LED is lit. Also given that SPI writes were seemingly safe, I began fuzzing and a short amount of poking later I found subcommand 0x30 with no bricks from poking randomly, thankfully. Subcommand 0x30 takes one byte, the higher nibble defines which LEDs to flash and the lower nibble defines which LEDs should be lit, as I had predicted. A few commands higher at 0x38 there was the home button LED command which illuminates the home button in a nice blue color, though the format is currently unknown to me. It seems to also take one byte and it glows in and out the slowest with an argument 0xFF, which is what I used to fuzz. The fuzzing results can be seen below:

With all of that figured out, for the most part everything needed to interface the Switch Joy-Con and Pro Controllers to a PC is known. Bluetooth does, however, still have some interesting quirks. For one, I actually found that the controllers would randomly disconnect until I sent vibration data and proper timestamps along with my packets. This is actually part of how I found out that most if not all packets going to the controllers hold vibration data, which was interesting. On hardware, vibration data only ends up being sent once every 8 input packets (for UART). Additionally, it should be possible to interface with the NFC chip, however my current results have not been successful, but as of now there's nothing stopping it from happening.

Another interesting note is that Bluetooth actually just constantly sends input packets in most of its outputs, and getting IMU data seems to require some additional commands from the usual. As far as I've seen, there are 3 different kinds of input packets which can be gotten over Bluetooth: The basic input packet given to even the OS, the extended status packet which has analog values, battery status, and other things. The final is the same input packet gotten over wired with command 1F, which also includes IMU data. The type of packet sent and the rate seems to depend on subcommand 03.

Last interesting note, but I actually ended up finding a correlation between some of the leaked heap data and some data from hedgeberg's Switch reverse engineering stream. Some UART lines under the display ribbon contained data which, by chance, also popped up in my leaked heap data shortly after the stream. Specifically, this 08 20 20 03 02 01 section of bytes at 0x44:

Those bytes definitely haven't showed up UART at all, so I'm curious if it may indeed be some kind of common command system or something else. Definitely interesting.

A few takeaways with Bluetooth done:

For the most part, the only thing that's really left at all as far as commands go is finding any commands used to update the Joy-Con firmware, in addition to the IR camera commands.

The Joy-Con firmware, while no longer immediately useful for Bluetooth, is still valuable in determining any future changes or vulnerabilities in the firmware, as such the next post will hopefully detail a method of retrieving the at-runtime firmware from the device. Knowing heap addresses might help with this.

There is still a lot of work to do as far as amiibo support and better driver support goes.

[shinyquagsire23]

Picking apart the Joy-Con: Pro Controllers, Extended HID and uinput Drivers

It's been a little while since I last continued this series of posts, and since I've made quite a bit of progress since I figured I'd do a quick post on some things.

With my hidtest utilities out in the open, getting results from other's Pro Controllers took very little time. Initially, Pro Controllers worked out of the box except they disconnected after a short bit. Additionally, sending commands to only one Joy-Con would cause the other to eventually disconnect sometimes. The solution to this ended up being an extra 80 04 HID command being required in order to keep the controller from switching over to the Bluetooth default later on. While I haven't checked exactly what this is doing, I'd hazard to guess that one of the Joy-Con pins ends up getting pushed high in order to keep UART communication. 80 05 undoes the effects of 80 04.

As an interesting note, this much progress actually enabled Switch Pro Controller support to be added to the Wii U through Maschell's HID to VPAD, definitely worth checking out here.

With Pro Controller support out of the way and a small test kit for Joy-Con, I went into dekuNukem's collection of UART logs in Nintendo_Switch_Reverse_Engineering to find some more interesting commands to investigate. Specifically, I went to check out the vibration commands since Nintendo's linear resonant actuator "HD Rumble" feature is certainly not something all that common with game controllers yet (notable controllers which do contain them include Valve's Steam Controller, the HTC Vive wands and Oculus Touch). Examining his Breath of the Wild vibration packet sample, the vibration commands were fairly obvious:

19 01 03 11 00 92 00 0a 00 00 aa e0      10 0a c2 12 4b 40 c2 12 4b 40

In this packet, the extended command header and checksum is contained in the first 12 bytes, with the extended command in this case being command 0x10. For reference, the extended command for fetching input packets was command 0x1f. To test and experiment with different packets I had implemented a replay feature into my test program and the results when given vibration packets were... disappointing. No vibration at all, the input packets returned as usual but not much else actually happened. Between having my Joy-Con connected to my Switch over Bluetooth and also connected to my computer via USB HID, I managed to find an interesting quirk with the 80 04 command mentioned earlier: By having the controller connected to a console and then quickly rushing through init (skipping higher baudrates and 80 04), it was actually possible to get the controllers to preserve an internal 'vibration enabled' state, provided I talked to the controller enough that it wouldn't disconnect from me. Using this, I was able to replay existing vibration packets and also craft my own, resulting in some very strange vibrations:

After a bit of experimentation, I eventually found that vibration packets were formatted as follows for USB HID:

80 92 00 0a 00 00 eb 01 10 TT XX YY YY YY XX ZZ ZZ ZZ

TT is a timekeeping byte, it increments from 0 to 15 forever. XX seems to control the frequency of vibration for the left and right vibration respectively. YY YY YY and ZZ ZZ ZZ seem to be three signed bytes denoting intensity in certain sides of the Joy-Con, however I'm not 100% certain. By leaving YY YY YY and ZZ ZZ ZZ set to all 01 and only increasing the frequency, the following result is gained and, for now, still resides as a simple vibration test in hidtest:

With vibration working somewhat (except for actually enabling it on our own), most of the functionality present in a left Joy-Con is workable, except for maybe setting the player number on the side. The real goal is still reversing the actual Bluetooth protocol, and with that still comes the requirement of getting some sort of real firmware to reverse. With more people being able to dump their SPI flashes without hardware modification, I did hope that there might be a few more eyes on the firmware to try and figure things out a bit. While the full code is still a mystery, there is still some interesting things to note as far as the SPI flash goes:

Depending on the age of the Joy-Con (and possibly other factors?), some Joy-Con have an older firmware at 0x10000 and others have an older one at 0x28000. Generally, both slots are filled with the exception of some Pro Controllers which only have the 0x10000 firmware slot filled. The active firmware is determined by a pointer at 0x1FFC in the SPI flash, which will point to 0x28000 if that firmware should be booted, otherwise it will be unwritten. 0x0 appears to be some sort of initial loader, containing twice a u64 magic D297E5680FF055AA to be checked at 0x1FF4 if 0x1FFC is filled with a pointer to 0x28000. The block at 0x2000 also includes the MAC of the last connected console and joystick calibration data. The block at 0x6000 contains the Joy-Con serial, type, color, and diffing between a right, left and pro controller dump, what looks to be factory joystick calibration data or something similar. The Pro Controller, interestingly, does not have a serial number and only has a body color with its buttons left unwritten. This data is also writable, more on that later.

For Joy-Con and Pro Controllers out of the box, a single byte at 0x5000 is set to 0x01 and the 0x2000 block is entirely written to 0xFF.

As nice as examining the SPI flash was, it was somewhat suggested to me by shuffle2 and others that the firmware on SPI might just be a patch over the existing firmware data, so reversing the full firmware would require the ROM of what was being patched on the Broadcom chip. Examining some of the oddities I had encountered, I'm honestly inclined to agree, if it's not a patch it's definitely something strange and having the ROM would be nice. Given some existing Pro Controller board shots previously, I noticed an abundance of test pads and ended up buying a Pro Controller to try maybe getting JTAG on it. Specifically, an array of pads next to the Broadcom chip looked pretty candid:

After fiddling with different JTAG possibilities and examining any outputs with my logic analyzer, it appeared to me that the JTAG functionality was either disabled or those pins were not JTAG at all. Also exposed on the board, however, was a 4-pin SWD header for the STM32 and what looked like another SWD header for some other chip, however I had no luck finding anything on the other end of that as well. The line of 7 throughholes, however, is also accessible from the back and contains the UART Rx, Tx and two flow control lines on the top four pins, followed by VCC, GND and a reset pin.

A bit disappointed, I decided to try getting a wired USB HID driver going for my Pro Controller. For the most part, it was fairly straightforward; uinput was able to provide a fairly straightforward interface for exposing my own custom unified controller, and by tweaking some of my existing HID test code it was possible to make a responsive userland input driver for both Pro Controllers and for two Joy-Con in a charging grip with added hotplugging support. It also passed the Super Meat Boy test with full analog controls in the charging grip and 16ms latency, or 8ms with the Pro Controller:

After several weeks of not that much progress, I realized that I really wanted to get a bit more information on potential commands so that I could maybe try getting code execution on the Broadcom chip some other way. While I do have my doubts, I also wanted some specific commands for enabling vibration, IMU data, and for writing to SPI.  As such, with some help from hedgeberg I got a small UART sniffer going using a miniSpartan6+:

Since the sniffer was able to parse the UART in realtime, I could create detailed captures of all data sent during any event. Using this, I was able to go into System Settings, calibrate my joystick, and then watch a packet get generated which wrote some data to SPI flash. The packet ended up being the command next to the SPI read command, extended command 0x01, double extended command 0x11:

19 01 03 38 00 92 00 31 00 00 1a ad      01 04 00 00 00 00 00 00 00 00       11 10 80 00 00 0b b2 a1 0a c5 40 97 a7 8d a4 f4 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This packet does a 0x0B-large write to 0x00008010 of data b2 a1 0a c5 40 97 a7 8d a4 f4 48.

To test this, I did some haphazardous writes into the 0x6000 block to change my Joy-Con color, and through this I was able to create the first pair of spice orange Joy-Con and also have some fun messing with the serial text:

Interestingly, because the console has a colored effect on the side of the screen when Joy-Con are clicked in, most of the metadata in the 0x6000 block is actually cached on the console itself. In order to clear this, Settings > Controllers > Disconnect Controllers has to be used to unpair and uncache all controllers to then show the actual updated color/serial data, which are presumably cached according to the controller MAC.

Additionally, I found out that the commands to enable vibration and IMU are called relatively soon after the metadata SPI reads called to fetch the serial, color and other settings.

19 01 03 38 00 92 00 31 00 00 ae fb      01 03 00 00 00 00 00 00 00 00      48 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 01 03 38 00 92 00 31 00 00 cb 8f      01 04 00 01 40 40 00 01 40 40      40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

For these packets, extended command 0x01, double extended command 0x48 with an argument 01 will enable vibration, or with its argument set to 00, disable vibration. Double extended command 0x40 with argument 01 enables IMU data to be sent along with input packets, occupying the large amount of what is normally zeroed data there.

Even with those bits figured out, my big UART mysteries now mostly lie in the right Joy-Con, specifically with Amiibo/NFC, the infrared camera on the bottom of the controller, home button lights and also the player LED lights present on both the left and right Joy-Con in addition to the Pro Controller. However, the home button lights and player LED lights will probably have to wait a while since those are never called over UART (though the home button lights will likely recieve an update later on which could be sniffed out). Additionally, the infrared camera's only game is 1-2 Switch which I do not own, and on top of that it requires that the controller be wireless from the Switch, which effectively leaves NFC as the only thing I can really snoop around.

After wiring up my right Joy-Con to be investigated, I ended up with a rather interesting sequence of commands. First, extended command 0x01 double extended command 0x3 is called with argument 0x31, as opposed to argument 0x30 sent on init. Additionally, extended command 0x01 double extended command 0x22 is called with argument 0x01, while it is only called on init on the right Joy-Con with argument 0x00, so I'm guessing this just enables NFC. After NFC is enabled, input packets stop getting sent, and with those commands called, extended command 0x11 double extended command 0x01 is called ~13 times with an extended command 0x01 double extended command 0x21 inbetween. The console then sends extended command 0x11 double extended command 0x02 until an Amiibo is found. To these commands, the Joy-Con responds with an input packet with an additional 0x138 bytes of NFC data attached to it (with the last byte being a sort of checksum byte it seems). This data seems to contain a status byte, a nearby NFC tag ID, and once in contact, one of two alternated portions of the full NFC tag data. After the Amiibo is scanned, NFC is disabled and the smaller input packet requests are resumed. A full console->Joy-Con packet dump can be found here.

Naturally with some packets to replay, I attempted to make this work over USB HID. After all, a USB NFC reader which doubled as a controller would be a great feature for 3DS and Wii U emulators, and it may even work with non-Amiibo NFC tags. However, there's a fairly critical issue: The STM32 firmware was never tested or meant to work with NFC packets at all. While most other packets stay within the set 0x40 byte limitation, these NFC packets extend much larger. Because most of the UART input buffers end up being 0x40 bytes on the stack, all NFC packets are truncated to just input packets (with just a fragment of the NFC extension). It might be possible to modify the STM32 firmware to allow NFC to work, however in the long run it would probably be easier to just look further into Bluetooth where it is guaranteed to work.

And with that, some things going forward:

There are definitely some limitations to snooping UART. Specifically, some things aren't even transmitted over UART at all due to not being implemented (Home Button LED) or due to game limitations (IR camera).

The STM32 also has limitations to what it can transmit and recieve, especially with NFC and probably with the IR camera as well

It may be possible to fuzz around for commands like the player LEDs or Home Button LED, but ultimately it would be easier to identify commands with an actual firmware to reverse engineer. As such, that and Bluetooth in general will be the focus with this going forward, probably.

[shinyquagsire23]

Picking apart the Joy-Con: Charging Joy-Con Grip and HID

Earlier this week I made a short post detailing some of my endeavors towards talking to Joy-Con and getting their firmware. However, as fun as it is to have my Joy-Con in pieces talking to my ESP32, I wanted a better way to conduct research with my Joy-Con.

To do this, I ended up buying a charging Joy-Con grip for about $30, a little bit costly but worthwhile if it happened to have the rail connectors I could tap into for UART (though I also had hoped when buying it, at least a little, that I could talk to the Joy-Con straight over USB) After receiving the device, I was surprised to find that it did not have a battery like I thought it would (not sure why I thought it had one), but additionally it also had USB descriptors! Looking at these descriptors, I was pleasantly surprised to see two interfaces with an input and output endpoint each, which slightly affirmed a small gamble I took hoping this would also function as a sort of HID<->UART bridge.

However, attempting to send UART packets to those endpoints yielded nothing at all. Just before I was about to take it apart and try more invasive measures, I was very pleasantly surprised to find that if I undocked or docked one of my Joy-Con, the device sent me a single packet: When it was undocked, 80 01 03, and when it was docked, a packet containing the Joy-Con MAC:

Getting this MAC would mean that the device was not only charging, but it also has to be talking UART to retrieve that MAC address. At the very least if it wasn't straight HID to UART, it was something very close.

After taking it apart, I was pleasantly surprised that had an STM32 identical to the extra STM32 chip found in the Pro Controller (which I don't have, but have seen pictures of):

Perhaps the most notable thing on this board though is the 5 throughholes on the bottom left. For a little bit of prior context, the Switch dock also has an STM32 of a slightly different variant, but in addition to this has a labeled 5-pin SWD interface on its board:

(Picture from iFixit Teardown of the Nintendo Switch)

As much as I'd like to just wire it up identically, I also didn't want to go carelessly hooking things up, because this device also happens to be 1.8v versus the dock's 3.3v (though the STM32 supports 3.3v just fine). After some probing, I found that the pinout was fairly similar but not quite identical, and with some soldering and wiring it up to an RPi (which had 3.3v logic) I had myself access to the device and debugging through OpenOCD:

After getting the firmware dumped over debug, I took it to a hex editor to poke around and found some interesting strings, notably the fact that the charging grip is able to boot into a Device Firmware Update mode. Because it’s 2017 and charging grips need that I guess:

Also as an interesting note, Kuina translates from Japanese to English as “Water Rail”, thought that was cute. The Switch already has a lot of ocean names in its software so having this added to the pile was neat.

I was also able to load it into IDA fairly painlessly (as opposed to the Joy-Con firmware which is still a big unknown for me). Finding the UART functions I wanted was as easily as finding the A1 A2 A3 A4 magic I had found before and then from there working backwards and around to find the general UART functions I would need to see. With some prodding and debug breakpoints, I also was able to find the portion of code which handles incoming HID packets, and with Hex-Rays its functionality becomes fairly clear:

From the top, it seems like there are some UART packets starting with 01 or 10 which can be sent straight over HID, but for the most part all of the custom HID work is done with the first byte as 80 followed by a second subcommand byte.

From an initial observation, I found that there were a few commands which let me just send UART straight for the most part (the main difference is that the header and checksum are handled by the grip). With some cobbled together initialization and commands, I succeeded in getting UART input packets sent... but they did not contain any button data at all, which was a bit strange:

With this portion of the firmware at least identified, I continued digging into some of the earlier 80 commands and after quite a bit of fiddling, I found a few things: First, the device initializes only both Joy-Con at once, if both are not initialized at the same time, the rest of the process fails or only works partially as seen above. This may be why this HID protocol isn't used by default with the Switch, since initialization actually takes a while and if the Joy-Con are already powered there's no real point in switching back and forth. Both Joy-Con being initialized at once may also mean that this firmware is simply half-baked and was abandoned at some point to a similar tune. 

Additionally, I found that this device is indeed able to send any UART packets desired, though it does not have fine control over the header of those packets, so if you want to get a bit crazy you'll have to flash your own firmware to the grip. That being said, the initialization process I eventually found worked consistently was as follows (with each step being sent per-Joy-Con to both HID interfaces):

Send 80 01 to get the Joy-Con MAC and/or connection status. Send 80 02 to proceed with UART handshaking procedure. Send 80 03 to switch baudrate up from 1Mbit to 3Mbit. This seems to be required to get input delay down from 24ms-32ms to 8ms-16ms. Send 80 02 again to redo handshaking over UART so that the Joy-Con don't time out and disconnect after the baudrate change.

After initialization, any UART packets can be sent. The nice thing with the UART packets being crafted by the firmware is that it clarified the functionality of certain portions of the packets. For example, the general structure of an input request packet sent over HID vs UART is as follows:

                    80 92 00 01 00 00 00 00 1F 19 01 03 08 00 92 00 01 00 00 00 2D 1F

In these packets, the only real difference is the header for UART and the checksum byte before 1F. The 92 byte can either be 92 for post-handshaking commands or 91 for pre-handshake commands. This is followed by a u16 length for the payload of the packet, 1F. For HID, the checksum is handled by the firmware so the byte there can be left 00.

As another test, I also was able to dump my right Joy-Con firmware for the first time since I could send the same UART SPI read packets as before, and was surprised to see that it was actually significantly different. With the differences though, there were some things which caught my eye that I did not see from the first time. At 0x10000, there seemed to be an early version of the firmware, with "Joy-Con (L)", "Joy-Con (R)", "Pro Controller" and "Joy-Con Charging Grip" replaced with "NintendoGamepad01", "NintendoGamepad02", "NintendoGamepad03" and "NintendoGameadp", though it seems the Bluetooth names were still Joy-Con and Pro Controller elsewhere.

With all of that done, I've also ran a few test with Bluetooth and it seems that unfortunately the HID protocol isn't a perfect match between Bluetooth and the HID wired protocol. However, it may be close, and with that I have a few guesses:

For the Joy-Con, the SPI is likely not XIP, however I have a mild suspicion that the firmwares at 0x10000 and 0x28000 may have some kind of header for dynamic loading since RAM may be limited. In dekuNukem's SPI logic dumps, I found that larger portions of the SPI were accessed after docking than just powering on, which is why I initially thought it was just XIP, but the disassembly simply doesn't make sense.

Bluetooth may have a bit more security around it just because it's used a lot more, and for the average use case, Bluetooth is simply more desirable.

Also some notable things going forward:

Since the SPI flashes are dumpable over HID with a charging Joy-Con grip, checking whether Joy-Con updates have taken place will be fairly easy from now on.

As-is, the charging Joy-Con grip is more than enough to experiment with the UART protocol. Replaying commands between Joy-Con should be more than possible, and investigating the Pro Controller should also be doable.

For anyone interested in trying out communication with your own Joy-Con and charging grip, I have uploaded my HID test program in my HID-Joy-Con-Whispering repo.

[shinyquagsire23]

Picking apart the Joy-Con: Wired Protocol and Firmware Dumping

For the past few days I've poked around a bit with the fancy new controllers that ship with the Nintendo Switch, the Joy-Con. My primary motivation in looking at these devices mostly come back to the fact that they're almost everything I wanted in my VR controller project: analog joysticks, four buttons, and grip buttons (to a degree). Position tracking aside, I think they're basically perfect for VR and have huge potential as a standard Bluetooth controller as well, with some interesting bits added in like linear resonant actuators for HD rumble, an IR camera and NFC. And while they do work out of the box as Bluetooth controllers, there is no real analog Joy-Stick values, all of the extra peripherals are still locked off, and the Joy-Con don’t send data fast enough at times, resulting in missed button presses.

Unfortunately, at least until the Switch is fully cracked open to the point where normal Bluetooth communication can be observed, the only means of communicating with the Joy-Con aside from Bluetooth is through the wired protocol present under the rails. When the Joy-Con are docked, a 10 pin connector is used for charging and data transfer as opposed to keeping Bluetooth on constantly.

Before I go too far in though, I'd like to send a huge shoutout and thanks to dekuNukem and his repository at https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering, he got much farther into Joy-Con protocol reversing before I even started, and I doubt I would have been able to get this far without some of his data since my logic analyzer is fairly weak and can't capture a whole lot at a time. However, for some simple debugging it and some wires is more than good enough to recreate his experiments and try things on my own:

The Joy-Con rails communicate wired to the console via UART, with an initial baudrate of 1000000bps (1Mb/s) and with flow control for both sending and receiving. The Joy-Con Rx and CTS lines are also inverted (possibly for easier detection?). To talk to my Joy-Con, I opted to use my ESP32 which actually supports inverted UART lines, however a bug in uart_set_line_inverse did end up causing errors regardless of the masks I sent, and it turned out to be a driver bug which nobody has encountered since inverted lines aren't used all that often.

To begin communication, an initial test packet of A1 A2 A3 A4 is sent from the Joy-Con to the console, and following this a packet requesting the device’s MAC address is sent, which it promptly returns:

Additionally, these handshaking packets can be sent repeatedly, however the final handshake command must occur before additional commands are opened. This fact at least makes while(1) debugging while tweaking UART settings possible.

Once handshaking is done, different functionality of the Joy-Con may be polled. Most notably, full input can be retrieved with analog joystick values and 6-axis values (though it seems the IMU is off by default and needs a command to enable it). Additionally, one of the first things done after initialization is reading calibration and identification values from the inbuilt Joy-Con SPI flash. For my initial test case, I wanted to try grabbing some input values before getting too crazy:

With that done and working though, my main goal in all of this is Bluetooth, and once again it's not something that can easily be observed. What can be observed, in this case, is the Joy-Con firmware which resides in the SPI flash. By using the same packet used for reading calibration and identification data from SPI, the entire SPI flash can be dumped.

Even with the SPI flash dumped, however, I am having difficulty finding any code to reverse at all. There are definitely strings to indicate that there is code, and some things almost appear to be proper Thumb code, but nothing quite makes sense or flows at all. However there are still some notable things in the firmware:

Strings for "Joy-Con (L)", "Joy-Con (R)", and "Pro Controller" exist, which seems to imply that all three share the same exact firmware (though probably with configuration blocks tweaked to identify what device it is)

A string for "Joy-Con Charging Grip" exists, possibly implying that it can (or originally was planned to?) bridge two wired Joy-Con connections into one wireless connection? Or at the very least, the grip may identify itself to Joy-Con for the console to know a charging grip is being used.

The Joy-Con serial, color, and MAC are all stored in SPI flash. It’s possible these blocks are write protected, but somehow I doubt it.

Some guesses with Bluetooth:

The protocol is probably fairly similar if not identical to the wired protocol.

The Joy-Con work, by default, as game controllers, but my guess is that there is something similar to UART where it will not display an extended set of commands until a specific handshake is done. Hopefully a firmware RE will reveal any nuances required for this...

While I won’t have my SPI flash dump uploaded with this post, I’m more than willing to send it the direction of anyone who is interested in reverse engineering it. For anyone who wants to dump their own Joy-Con, my ESP32 source can be found here.

[shinyquagsire23]

Throwback: K9Lhax by Bruteforce

Given the recent topic of OTPless k9lhax installation on N3DS, I felt it would be interesting to mention the original hardware method of executing non-enhanced k9lhax on an N3DS. For the sake of documentation, this exploit was conducted in May 2015 cooperatively between myself, WulfyStylez and Dazzozo. I ended up being the one to conduct the actual hardware exploit and bruteforce while the 3DS software process was almost entirely done by WulfyStylez and Dazzozo.

The original k9lhax method was documented on 3dbrew on March 29, 2015 as “Missing verification-block for the 9.6 keys” (the dubbed name “arm9loaderhax” only came after 32c3 at the end of the year). The idea was fairly simple: By corrupting the second keystore key, FIRM would decrypt to garbage and that garbage has the potential to execute RAM. While RAM is completely cleared on boot, a reboot via MCU i2c will not clear RAM, setting up a vector for bruteforcing.

It is also important to note the reasons to even execute a one-time k9lhax at all: For one, the 7.x and 6.x encryption keys, used for games and saves respectively, are able to be gained at this point. The 7.x key was (presumably) sold to Gateway and then eventually leaked through reverse engineering their payloads. However, the 6.x save key was not known at all and was not used by Gateway, and the only way to utilize it was by booting a firmware version over 6.x, which was not a problem since most people stuck on 9.2 anyhow by this point. Needless to say, it’s still be nice to have this key. The real reason for performing the exploit, however, was a detrimental flaw which happens to Just Work in the particular spot of execution which k9lhax yields:

All of the new keys used on the New 3DS are derived from an encrypted keystore on NAND. This includes the game and save encryption keys for New 3DS games, encryption keys for FIRMs, etc. The encryption key used to decrypt this keystore is based on the hash of each console’s OTP, and as such the encrypted keystore is unique to each console, while the actual decrypted keystore is not. While the decrypted keystore and all intermediate keys are wiped after being set into the AES hardware, the SHA registers used to calculate the OTP hash were not, which meant that k9lhax = OTP hash = decrypted keystore. This meant completely breaking all added encryption measures on the New 3DS, and in practicality, decryption of newer games and emuNAND on 9.6 and above.

To conduct this exploit, I chose to use a Raspberry Pi B, simply because it was a device which could talk eMMC and i2c from the same device. For actually writing to the New 3DS NAND I used my trusty Anker card reader, which was able to remain plugged into the USB port while not restricting read access on the N3DS. Rather, it would only cause issues with N3DS reads when the Raspberry Pi itself went to read and write, which works perfectly in this case.

To determine when to stop brute forcing, and to increase the chance of success, the payload used was a small payload designed to shut off the New 3DS and nothing more. When the N3DS was off, the NAND writes and i2c probing would no longer work, and the key which remained would work for consistent k9lhax bootstrapping.

Finding the pads for i2c on the same bus as the MCU ended up being somewhat tricky, however looking for the NFC chip on the same bus yielded two pads which ended up being the ones needed:

From there, getting i2c to work with the Raspberry Pi took just a bit of effort due to the devices I was looking for not quite correlating to the IDs on 3dbrew, however I did eventually get success:

After hooking everything up and validating i2c, I ended up with this setup:

The bruteforce itself is somewhat boring, basically just watching things increment for a while:

Eventually, the N3DS would shut off with the correct key. At about one iteration every 7-10 seconds, a successful bruteforce would happen after about 30 minutes to an hour. Once the key was gained, it was possible to consistently bootstrap into post-K9L code execution:

From this point, the OTP hash and 7.x/6.x keys could be written to SD and then the entirety of New 3DS keys could be calculated and used on other consoles. As a bonus, the OTP hash could also be used for permanent k9lhax installation via enhanced-k9lhax, no downgrade required.

[shinyquagsire23]

Making Controllers for VR from the Ground Up

Foreword

Just as a foreword, this is a project I worked on for my senior project for my final year of high school. And yes, it does look very similar to the PS Move, however the goal of the project was not to have usable controllers for VR, but rather to build a solution from the ground-up. Admittedly, the quality of the final result could have been much better, however I did accomplish my goal and I ended up learning quite a bit. It should also be noted that this project was completed in March before the Vive was released, using a DK2 on Linux.

Drafting

My initial project goal, from the beginning, was a pair of controllers for use in VR. Optimally, both hands would have their position and rotation tracked. In addition to this, I found that the most optimal input would involve at least one analog joystick for movement (since analog joysticks provide partial angles in any direction), one button per finger for binary finger input, and a few general-purpose buttons.

For position and rotation tracking, one possibility I investigated was using pure IMU-based tracking by integrating acceleration twice for position and rotational velocity once for rotation. After actually investigating this, however, it was quickly apparent that this would not work due to the lack of accuracy and relatively slow sampling rate even in modern IMUs, since an accurate position can only be gained by integrating accurate samples extremely quickly. Without quick and accurate enough sampling, the only way to use IMUs is via correction. For rotation, the accelerometer can tell the direction of gravity while the device is standing still, and a magnetometer can tell magnetic north. As such, rotational tracking is in a relatively accurate state with several known and tested fusion algorithms available. Position tracking, however, does not have much of a luxury for correction in terms of pure-IMU tracking.

My second idea ended up being similar to what Free Track does: using LEDs and a camera to determine position. Given a known distance between two LEDs, it would be possible to calculate a position. While looking into the process for this, however, I found that tracking two hands at the same time would be relatively complicated with this, in addition to it being extremely easy to block the LEDs when facing left or right relative to the camera, or if the controller itself was rotated in a direction not facing the camera. I did, however, accidentally discover a solution which would work.

Infrared Diffusion

The New 3DS's face tracking works using a camera without an IR filter, in addition to an infrared LED next to the camera in order to light the user's face in dark or nighttime environments. Experimenting with my DK2 camera, I was able to examine some of the patterns with this LED, while also being able to experiment with diffusing the infrared light into different objects, such as a green bouncy ball. To test this, I drafted a basic OpenCV script in Python which was able to detect my infrared-lit ball:

The reason infrared spheres are significant, however, lies in the properties of the sphere itself when projected onto a 2D surface: No matter what orientation the sphere is placed, it always projects into a circle. Given this, a position can be gained by tracking the X and Y position of the sphere for your position X and Y, and then the radius of the projected sphere can be used to determine a Z depth. With this in mind, I ordered a pack of styrofoam spheres on Amazon and some infrared LEDs to get an actual hardware solution going.

In the mean time, however, I still needed an actual controller, and a casing for it. To handle the IMUs, analog joysticks and buttons, I opted to use a Teensy 3.2 I bought with some other unrelated OSHPark boards I had fabricated months earlier. I also had bought two MPU-9250s for the actual motion tracking. Getting rotation from the Teensy over serial into an application ended up being relatively simple given the wealth of code and examples already open:

Once my styrofoam spheres had arrived, I began to work on actually extending my Python script into something which could actually track position. For the most part this involved doing a lot of tuning with OpenCV in order to best isolate my infrared sphere, especially in environments which may have a good amount of existing infrared light (ie incandescent lightbulbs, sunlight, etc). Once I had my sphere isolated, I spent some time figuring out my X and Y camera pixel -> real life millimeter position, and from there also figuring out the relationship between our radius to Z position, and the Z position to the X and Y position. I ended up getting some funky ratios which worked surprisingly well, however they probably aren't *really* that accurate. In my own tests, though, it seemed accurate enough, so I went with it.

Demonstration and Printing

With position tracking said and done, I also realized that as great as showing a controller is, I needed a demo. As such I opted to modify my existing DK2 port of OpenJK to communicate with my Python daemon. To get data from my Python script to OpenJK, I ended up just using memmap for some simple one-way IPC:

With a good amount going on between my Python script and OpenJK, it was time to tie everything together: I needed to actually get my microcontroller going and an enclosure made. 3D printing the controller was a whole process in itself, since I had the foolish idea that I could totally just build a printer to print this on (since I had also planned to use it for other things). Needless to say, 3D printing and tuning a 3D printer is pretty difficult, and my initial design was awful:

The main issue was that my prints would consistently lift off the bed, resulting in an inaccurate print which could not be used. The real issue though was in the model itself:

My model was extremely curvy and frankly I have no idea what I was even thinking when I designed it, although I did design it before I actually really understood the limitations of 3D printing at this level. I also happened to be extremely new to using CAD software at all, so the problems really just ended up compounding. Eventually I decided to design a version 2, which solved all the problems of my initial design: no curves, no weird bends, KISS.

Even despite the redesign however, ABS really does not work well for large prints which are vulnerable to lifting, and ordering PLA was not an option for the time frame I had to complete this. Luckily 3DHubs is a thing, and I managed to find someone with a tuned printer to print my design while I worked on the software some more.

Hacking ovrd some more

One particular issue I wanted to work on was the fact that my infrared camera also happened to be the DK2 camera, which can be quite the problem. Basically while my script can use the camera before ovrd got to it, the consequence of ovrd not being able to access it is losing position tracking of my HMD entirely, which really isn't all that friendly to end users. After some investigation I found that I could examine the memory of the ovrd process while it was running and actually steal its camera input instead:

Additional investigation eventually led me to the conclusion that this wouldn't work for several reasons: ovrd sets an extremely low exposure for the camera in order to isolate only the HMD LEDs, and also to track the LED blinking patterns for accurate HMD position tracking. While I managed to reverse engineer ovrd and force more exposure, this also happened to kill the HMD position tracking, so there really wasn't any winning. It was a neat experiment, however, and I feel like it could be useful for exposing the camera for tracking other devices, so I left the functionality in my Python script, disabled by default.

Once my 3D printed enclosure arrived, the real fun began. Assembling the actual inputs was a mess of wires, and I really regretted not working on this way earlier when having a board fabricated from OSHPark was actually an option.

The buttons I made for the back of the controller ended up having a few problems. For one, they were too large, and no amount of sanding could fix that easily since I lacked the tools to do it, and it was PLA. There was also the issue that the buttons could easily fall through into the chassis due to a mistake while designing it. However since my printer was tuned enough to print smaller objects, I printed some better fitted buttons and some small triangular stops to prevent my buttons from falling out, and as such my assembly continued:

With one half done, I took a small break from pain and worked some more on getting button, analog joystick, and IMU inputs into my Python script and on into my IPC memmap:

For my second half, I ended up using an HDMI cable to transfer all the signals I needed straight to the microcontroller, and with that I had my controller's hardware 100% done:

The main issue from here, for me was an issue of duplicating all my inputs twice, and also dealing with two IMUs and two circles to track instead of one. There was also the issue that my OpenJK tracking was a bit... subpar. The weapon model moved with the controllers on all axis, but actually aiming was just a hack which also happened to map the controller X and Y to the mouse. Luckily it was enough to get a pass from my program teacher during our check-in a few weeks before our actual presentation:

https://www.youtube.com/watch?v=EuuFkMyh3kg

After a fair bit of work, I managed to work out a good method of tracking which would prevent both controllers from being confused in the event of controllers crossing over the other or one controller moving outside of the view of the DK2 camera. I also managed to get OpenJK to actually use purely the rotation and position from my controller for the controlling of the actual gun in-game, and after tuning it enough to not fail on presentation day, my time effectively ran out and I honestly had no time to work on other demos, unfortunately. I would say that the product came out rather well, better than I had anticipated even:

Conclusion and Reflection

Making controllers for VR is hard. It really, honestly is. However, I feel like I really learned quite a bit doing this project: I used Python for a somewhat advanced application for the first time instead of just for super basic scripts. I got to use OpenCV for the first time ever, which was pretty cool. I also got to learn how 3D printers work and built my own, and I also had the opportunity to learn how to use CAD software for that.

I somewhat wish I had a bit more time to work on this (or money to improve on it now that I *do* have time). For one, doing tracking in a Python script definitely isn't optimal. It was great for the time since I could do rapid development and testing, but it really, really isn't optimal at all. My serial also was pretty awful, I really should have pushed all my data as straight binary data instead of a string, but again, time. The final product, while it does work, is pretty clunky, and could be better designed. If I had the chance to redo that, I would look into fabricating a single board so that the enclosure could be a lot smaller and more accurate. Wireless would also be nice, but I'm not 100% how handling batteries would go (the ESP32 does look like an interesting candidate for wireless and a microcontroller, although I'm not sure how latency would fare).

Since I do appreciate when people release their source, I've decided to push the final source for my project to my Github at https://github.com/shinyquagsire23/RIPVR-Controller. I would have rather maybe cleaned it up some, but lack of motivation is a bit of an issue here, since I've been busy working on preparing for university while also working with decaf-emu on their Wii U Toolkit (WUT). In any case I feel like it might end up being useful in some aspects, and if not useful at least interesting to look at.

[shinyquagsire23]

Gateway Card Cartridge Protocol

Introduction

Since the beginning of the 3DS hacking scene, Gateway provided probably, for the time, the best method (or uh, gateway) into modifying one's 3DS. I'd dare say they probably were the sole reason homebrew existed at all for the public prior to 9.2 and the release of ninjhax. Following 9.2 and their Gateway 3.0 Ultra release, while having an initially successful release and userbase influx, eventually led to their downfall due to how easily their ARM11 and ARM9 kernel exploits were able to be reverse engineered (see yifanlu's writeup about that here), as well as the nature of firmlaunchhax being that kernel access through it is extremely clean, and as a result FIRM modifications were easy to perform and relaunching a modified FIRM was trivial.

While Gateway used to be suggested for their ease of use and ease of piracy, a large portion of the 3DS development scene sees them now as a joke. They did, however, leave behind a very interesting piece of hardware: Their 3DS DRM cartridge used to load ROMs and protect their secrets. So how does it work?

Where to Look

Reversing Gateway's own payload to figure out how their cartridge IO works can, without a wealth of tools and time, be extremely difficult. Older payloads are easier to reverse than newer ones, due to newer payloads constantly layering more and more obfuscation tactics on top of what already existed. However for a more clear picture of their cartridge init sequence, Supercard's own freegame custom firmware yields an enticing opportunity to look into how the Gateway card init sequence functions.

To expand a bit on why looking at something Supercard created can assist with reversing Gateway's own card, Supercard is a company which makes DS flash cartridges, the DSTwo being their most notable cartridge. It contains its own coprocessor for the NDS to use for GBA and SNES emulation as well as for media and other purposes. They later released another iteration, the Supercard DSTwo+ which sported a much more powerful processor, more memory, and the ability to emulate Gateway's cart. With that ability, however, they initially opted to provide their cart as a stand-in replacement for Gateway's card, effectively stealing all of their work on the 3DS firmware end. Gateway fired back by bricking users who were using DSTwo+ cartridges with their firmware, and as a result Supercard forked ReiNAND into freegame and made their own firmware. This isn’t the first time this has happened, however. Several clone carts existed when Gateway was originally starting up, and they were also met with the same fate.

Since their firmware is a fork of ReiNAND (released without source despite the GPL license I might add), reversing its functionality is fairly easy since you can diff ReiNAND against their code and figure out the differences. For now though, I'll only be focusing on the gwcard init sequence.

Cartridge Init

The card init sequence starts the same as any normal CTR cartridge: Initialize NTR cart registers and initialize it as an NTR cartridge. The first step past this, however, is a very large SPI upload to the cartridge. With Supercard, a very large static buffer is fed over SPI, and after a few bytes being sent the cartridge begins to reply with its upper 5 bits yielding a 0xA0 return value. The entire upload appears to be a set of commands, and the commands differ slightly between what Supercard sends and what Gateway sends. It is possible that Supercard purposely designed their custom firmware to not work with Gateway cards, however that is an easy fix if it is the case.

Once the entire SPI blob is uploaded, a 0xA0 ntrcard command is sent to the card until it replies with 0x0 or exhausts a set number of attempts. It is possible for this to fail, I've found that depending on the situation it can take 4-5 cartridge resets, SPI blob reuploaded, and probing for life in the cart for it to work. Once its initialized it works fine, however.

Once the cart replies with 0 and alerts the 3DS that it is initialized, 128 ntrcard 0xBC commands are sent with the first request having argument 0xFFFFFFFF and the rest with argument 0x0. ntrcard and ctrcard command 0xBC changes the cartridge ID of the cart for Gateway cartridges.

After setting the cartridge ID 128 times, the cart finally transitions into 16 bit NTR mode and into CTR cartridge mode.

A Special Cartridge

Once in CTR cartridge mode, the Gateway cartridge largely functions like an actual cartridge, although it does a few things rather uniquely. Command 0xBF, normally used to read a block from the 3DS cartridge, will instead read a block from the Gateway SD card (hence why early Gateway versions required 3DS ROMs to be directly written to SD sectors). This effectively means that it is relatively simple to tie the Gateway cart into a fatfs implementation and read from the cartridge. Dealing with the cartridge init sequence in relation to fatfs can be a bit tricky with this since you need to sanity check Gateway carts vs 3DS carts, and probe for the status of the Gateway cartridge. In my own tests after implementation, I found that an SD card which would read at 152.6KB/s in the N3DS microSD slot would read at 110.5KB/s in the gwcard SD slot, which is honestly not too horrible.

The Gateway card also has some of its own commands. Earlier I mentioned command 0xBC which is used to change the cartridge ID, which is not implemented in retail cartridges (It might be in development ones though?), some other interesting cartridge commands include command 0x72 which can turn on the inbuilt RGB LED to any 24-bit color:

Conclusion

With this much research done, I thought it would be somewhat disappointing to see this piece of hardware go entirely unused. As such, I'm releasing some source files for the gwcard protocol and command set which can be used in public ARM9 payloads to experiment with the Gateway cartridge, and perhaps Supercard's cartridge as well. It would also be interesting to look at differences between various clone cartridges in their behavior to see how Gateway managed to detect clone vs legitimate cartridge. Sky3DS cartridges allegedly pass Gateway’s SPI tests, so investigating this could possibly result in methods of detecting and blocking Sky3DS cartridges from future 3DS firmwares, if Nintendo still cares about that.

Source code to my gwcard protocol implementation can be found here. Assuming the implementation of NTRCARD and CTRCARD are in line, it should Just Work. Also includes the magic SPI blobs for both Gateway and Supercard in bin form.

[shinyquagsire23]

Decrypting ORAS QR Codes

In Pokemon Omega Ruby and Alpha Sapphire, Super Secret Bases were introduced as a step up from the Ruby/Sapphire/Emerald Secret Bases for a new hardware generation, able to take advantage of the new 3DS features which did not exist with the GameBoy Advance. One of these features happened to be the front and back facing cameras, which yielded a vector for sharing secret bases via QR code. However despite the game having been released quite some time ago, it seems nobody has figured out their data format, so I decided to document this for curiosity.

On initial investigation I had to validate that the QRs were even encrypted in the first place, because there really wasn’t a whole lot of documentation about these at all. I did find a thread from a long while ago on Project Pokemon, but it didn’t really get anywhere. Taking several random QRs people had posted on the internet, it was fairly evident that the QRs were encrypted.

To investigate, I grabbed my own copy of Omega Ruby and went to scan a QR code, then using RPC dumped the encrypted and decrypted buffers for the QR data over WiFi. This was useful for knowing what the actual data was, however it didn’t serve well for actually decrypting data at-will without a running 3DS. To dig deeper, I looked at romfs:/DllSecretBaseQR.cro which led me to a subroutine at relative offset 0x1788, which seemed to handle QR decryption. One function in particular located in the main .text loaded 0x10 bytes to the stack and called another function, which I presumed was for AES or similar. Taking the possible key it loaded, I checked for possible AES modes which would fit and found that AES-CCM ended up being the one which would fit the bill. In particular, the function which has the key passed to it only decrypted data past 0x20 bytes in the input buffer, and the first 0x10 and second 0x10 were used for two things separate, which ended up being a 0xC nonce and a MAC for validation. As such, the following are clippets what you end up getting before vs after decryption:

In the first picture the 0xC nonce is clearly visible due to the 00000000 padding, and the MAC is directly under it. The output ends up being 0x218 large, 0x20 smaller than the encrypted QR size. These sizes are actively checked for when scanning the QR, otherwise it is deemed invalid.

In terms of the actual data, most of it is unknown to me at the moment. You have some utf16 strings for greetings and battle messages I presume (which are also length checked), an ID of sorts at the very beginning, and some basic diffing gave me the actual base location at 0x11C and the random people mats (I’m not really sure what they are, something with teams) with some data at 0x1BC-0x1C2.

If anyone feels like investigating the data further just find the encryption key in the ROM (a search for 0x18177B91 would yield a relevant subroutine, although the constant isn’t in the key). From there you can use this script to decrypt QR data (if you use zxing’s online interface, it’s the hex data minus the first 2.5 bytes), and this script to encrypt and turn it into a QR. You will need https://github.com/Legrandin/pycryptodome in order to encrypt/decrypt with AES-CCM and qrcode to create the QR.

[shinyquagsire23]

(v*)hax

This blog post details another savegame exploit found in VVVVVV, affectionately named (v*)hax. This post is purely for documentation, to download the exploit you can look here and for the exploit code you can check here.

The Save

The save files in VVVVVV are especially easy to pick apart, since the save files themselves are actually just XML files with a cool .vvv extension. Because of this, there are no checksums or other security measures used on them, and for the most part they are fairly straightforward in terms of modification since you also have nice tags to label what everything does. On a first load, the save will contain an unlock.vvv and a levels/ folder, in addition to this you also have levelstats.vvv, qsave.vvv for quick saves, tsave.vvv for teleporter saves, and a .vvv file for every user-made level saved in.

Exploitation

Based on a quick glance, there's plenty of possible opportunities for exploitation: strings, arrays, and the file parsing itself could be exploited. Looking again at the files available to potentially exploit, however, shows that the first file loaded by VVVVVV is unlock.vvv. This file specifies the current version of the save, what has been unlocked, best times, trinkets, and other settings. Much like level .vvv files, it also contains several flag and byte arrays:

In this instance, however, the main topic of interest is the <besttimes> tag, due to it containing a large data array which could potentially be overflowed, as well as the data itself not being binary in nature. Doing a quick fuzz by writing in 255,254,253 several times past the usual array size immediately yielded a vector for potential ROP:

The array of values is loaded into unsigned 16-bit values starting from a given address and continuing however long the array is parsed. Since the .vvv file itself is allocated to it's file size, this yields a very easy method of overflowing as much data as needed for exploitation. Even better, unlock.vvv reads to the stack. However, it reads very low on the stack, and this has one major disadvantage: the only way to control PC from a pop would be to exit the main loop, which simply doesn't happen. However, there are still plenty of pointers to manipulate within the region given. Basic fuzzing did not reveal much of anything that could give an arbitrary write, unfortunately.

Investigating the level XML loading showed they also could be overflowed into other data. Initially I had investigated level save files with the purpose of allowing the game to still be playable, however in the process I found the perfect vector for ROP: The offset in which the <worldmap> array is parsed into is within the range that the unlock.vvv can overflow. While this came at the cost of keeping the game playable, this means that unlock.vvv can overflow a perfect stack portion except for this pointer, then instead of reading the <worldmap> array into the heap, the game will read it into the stack and immediately begin ROP from the parsing function itself. Testing however revealed that the area itself is zeroed to it's proper array size (not the overflow size) before being parsed into, so the location to read into actually must be higher in the stack in order to prevent writing zeros into the stack before the actual data is read in.

Given ROP, it was somewhat trivial to load *hax, although not nearly as easy as supermysterychunkhax since there are limitations to the overflow. In this case, the size of the .text is extremely limited, however save space is plentiful, so a code payload can be copied into linear memory via ROP and then gspwned into an executable location and run, with the *hax payload also being read into memory during ROP and then loaded via the code payload.

Previous Versions and Conclusion

Looking at VVVVVV's downloadable files on Nintendo's eShop CDN revealed a v0 version which was released initially at launch, however it was quickly replaced by v1 a few months after the game launched in order to fix bugs in the game. Examining v0 for the same exploit revealed that while the game could still overflow the arrays in the .vvv files, the location on the stack of the pointers in which the level .vvv files are parsed into are higher on the stack than the portion which can be overflowed by unlock.vvv. That's not to say that v0 isn't exploitable, however the vector used in v1 will not work in v0, and because of this and the small availability window to even download v0, v0 is not supported by (v*)hax.

The fact that it only took at most 10 minutes to find an exploit in this game, however, does go to show that the security on many 3DS games can vary widely. While official Nintendo apps and first party games may implement their checks more carefully, some games will have no security at all. This can often make getting userland ROP a lot easier than it should be. Combined with a DMA exploit like gspwn, getting arbitrary code execution within almost any app is extremely simple after having exploited a previous game.

[shinyquagsire23]

supermysterychunkhax

This blog post details a savegame exploit found in Pokemon Super Mystery Dungeon, known as supermysterychunkhax. To start, I'll go ahead and say that this is purely for documentation and if you want the actual exploit itself you can look here for the code and here for a save installer 3dsx.

The Save

On an initial inspection of the save, it has four files: dungeon, game_data, game_system, and game_header. While dungeon was legible, the other files appear to be either encrypted or otherwise obfuscated, as there was no legible text or data which could be modified. Not much information on the saves is documented either, as nobody seemed to have hacked the save data at all at the time, surprisingly. After a bit of scouring though I happened upon this post, which said that the saves were actually zlib compressed. A simple Python zlib decompression script sufficed for decompression and recompression of unmodified saves.

Upon editing, however, the game fails to load, stating that the savegame was corrupted and a new one would be created. The savegame is completely wiped and started over in the event that this occurs. Given that there was some sort of checksum in the save file, I ended up contacting evandixon on Project Pokemon about this since he had done research into the save file, and he gave me this about the previous paradise-engine-based game, Pokemon Mystery Dungeon Gates To Infinity:

"GTI has an 8 bit checksum at the end of the file that's essentially the least significant byte of the sum of all the 1 bits in the file. Game_data had a little more to it that I never figured out, as if something else was added on top of it (possibly because of the larger file size), but I'd imagine that it's the same kind of thing in PSMD."

Doing a straight bit add and getting the least significant byte would not yield results, however it appeared to be a 16-bit checksum of some sort, with the bit amount shifted some and then cut to the lowest 16 bits. The amount shifted seemed to be based on the size of the file somehow. While I didn't figure that out exactly, the bitsum is able to be calculated for that size of file once the shift is found, which meant that editing the save was now possible.

Strings

Using a memory dump of the game to get an idea of how the save is actually loaded into memory yields the fact that most portions of the save are loaded at runtime as-needed, since there was not a full save image in the RAM. Rather, data is loaded into data structures throughout RAM, which could possibly be exploitable. One set of structures in particular seemed to be based on the party members/companions you can select, and overflowing the name has this result:

With some lengths the game crashes, and with some it just continues as normal. Checking the relevant code for the actual string strcpy showed that it was in fact truncated to a set length, so any crashes were most likely caused by invalid data rather than any sort of overflow.

A Wild Heap Overflow Appears!

Given that string was length checked, it was likely that several structures within the save had some sort of protection against overflowing. The compression, however, was a very possible exploitation target. Tracing back to the routine which handled save loading and decompression shows that the process for loading the save is as follows:

Unfortunately, the decompression method takes an argument which is passed to zlib to define a maximum buffer size for decompression, so creating a compressed save which would decompress past the allocation will not work. However, there is still the compressed buffer; Even despite decompression defining a set buffer size, the compressed buffer itself did not. This meant that we now have a basic heap overflow, which may or may not be exploitable at this point.

One potential issue with this overflow is that the limits had to have been set for a reason. Checking the size of the EEPROM showed that it was 0x40000 bytes large, which is fairly close to the max decompressed size. Loading a larger modified save file into a cartridge revealed it didn't fit, at least not with the other save files. Checking which file loaded first (game_header) and overflowing that file yielded a first crash on hardware:

The real question though, especially with a heap overflow, is what can you actually overwrite. This is particularly critical because just overwriting other data it doesn't necessarily make it possible to ROP, although it's possibly more leverage than before. Looking at the buffers in GDB, each allocated address is prepended with some sort of structure. Alas, it's a memchunk, with a u32 magic value, a u32 size, a u32 previous chunk and a u32 next chunk. Once again looking at the save loading routine, it would end up with a total of 2 allocated buffers after the compressed file is loaded in, and 3 allocated buffers just before decompression, with all the buffers being freed in the reverse order they were allocated:

Since the compressed savegame gets loaded after the decompressed allocation is allocated, this means that it is possible to modify its memchunk, which means that the next allocation could possibly be manipulated. Modifying the size does not yield a change in allocation, which means they must keep some parts of allocation stored elsewhere from the memchunks. Modifying the next and previous memchunk pointers is where things get interesting: upon allocating a new memory chunk it writes the address of the newly allocated memchunk at the location at the next_memchunk address, plus 8. In addition to this, the new memchunk also carries a next_memchunk+8 of the same address. Freeing, however, is different: The first free writes next_memchunk+8 to its prev_memchunk address, and the next free an interesting swap where the next_memchunk value is written to prev_memchunk+8, and prev_memchunk written to next_memchunk+8. Upon an initial inspection this dual write was not evident, and I erroneously assumed it only did the first write.

Failing ROP

Under that assumption, I had a fully arbitrary w32, meaning I could easily write to the stack and gain ROP at the second free, assuming I had a gadget to load a full ROP chain into the stack. Checking through every single instance of a memcpy to see if it could just copy the decompressed buffer to the stack, even just a little bit, yielded no results. The problem, however, was the variables given within the free after writing and reaching a stack pop:

r5 is decompressed buffer, and r8 the full size. In order to memcpy the decompressed buffer to the stack, one would need a mov r0, sp; mov r1, r5; and mov r2, r8 and then memcpy, or at least something close in execution. Even despite there being tons of memcpy instances, is not a single instance which fit this requirement. Looking for a stack pivot, out of the few that existed, yielded different results:

This stack pivot happens to work Just Right. To explain, the first line is already perfect: r3 has to be a valid value for a link register, and [sp, #0xc] just happens to be a valid return value which would also immediately begin ROP. r0 is set to r5 plus 0x210, which is within the decompressed buffer. r4, which is loaded into r2 which is loaded to r0 which is loaded from at +8 to be checked if it was 0, also happens to be a location which an abundance of 0's, resulting in sp being located at our decompressed buffer + 0x210, and the ROP immediately beginning.

Unfortunately, this plan of ROP has issues. The memory allocation and the first free actually get arbitrary writes along the way, and this actually causes issues due to it writing in random heap addresses to the stack return address, which get triggered too early causing a crash due to execution within non-executable memory. It also happens in the allocation before the data is even decompressed, which is another issue. There is, however another possible exploit: the limitation size for decompression is loaded from the stack.

So now instead of causing a heap overflow to corrupt a memchunk into writing a stack address for ROP, there can be a heap overflow corrupting a memchunk into writing a heap pointer as the maximum decompression size, and from there the decompression will overwrite the 0x1BCC allocation memchunk which yields an immediate arbitrary write on the free directly after the decompression.

Using the decompression memchunk overwrite, it is possible to write in our magic ROP gadget into a return address on the stack during the free function, in which it would stack pivot to 0x210 after the small zlib buffer, which is within the range of the decompression overflow. In Citra, this exploitation vector runs ROP without any problems, however this is due to Citra's ignorance of .text being read-only, so using the dual write on hardware would cause a write to .text, making this vector of exploitation not viable.

ROP Get and Closure

Investigating the flow after the small zlib buffer free without writing in the ROP gadget to the stack yields another interesting flaw: It jumps to a memcpy, which happens to load addresses from the stack. In actuality, this memcpy is normally only used in the event that decompression fails so that it can just load the save decompressed, however since the decompressed portion is extended over the small buffer used by zlib, it causes it to jump to this memcpy with zlib returning a failure, but with the decompression remaining successful. This memcpy normally copies the entire compressed buffer over the decompressed buffer, but using an arbitrary write it is possible to copy the entire compressed buffer over the entirety of the stack. During the memcpy it uses a function designed for larger copies which pushes and pops its variables, so gaining ROP is as easy as setting up the copy so that when it pops it goes straight into ROP:

Testing on hardware also yields a prefetch abort on some garbage stack data:

As an actual test though, you can ROP to svcExitProcess, which just looks like a normal crash except it doesn't actually touch any exception vectors. Unfortunately this isn't a good test due to it appearing the exact same as any other crash:

Using ROP, it is possible to gspwn a payload loaded from the save into the .text region of the game, allowing for an easier method of running arbitrary code, as well as *hax for homebrew. For Super Mystery Dungeon, the addresses for gspwn need to be adjusted so that the location of the .text region is known, and with a bit of tuning of gspwn, I finally got the ROP Just Right.

Having a way to run arbitrary code is useful with a 3DS in a position where it's partially bricked or for having a dedicated payload for further privilege escalation. However, a more useful payload to run (for most) would be *hax. Loading *hax's otherapp payload only requires a few parameters from the game in order to run, and the payload also fits within the compressed savegame file, which is required since game_header is large enough that it is not possible to add a payload.bin like most other *hax entrypoints are able to do. With the *hax payload in place, the exploit reaches its final product:

Gates to Infinity

Given that Super Mystery Dungeon is exploitable, one might think that the previous game is exploitable as well. However, in this case it actually isn't through this method for a few reasons: The flaw in which you can load larger-than-allocated-for files still exists, and the buffer allocated is 0x20000 large. However, save compression was actually introduced only in Super Mystery Dungeon, so that removes a lot of what makes this exploit possible. The real killing blow, however, is actually in how the game allocate memory for saves: In Super Mystery Dungeon, files are read into and decompressed within linear memory, which uses a much different (possibly custom rolled?) allocation method than the usual heap memory. In Gates to Infinity, the saves are loaded into the 0x08xxxxxx normal heap, initially towards the very end. Just based on an initial analysis, there is absolutely nothing which can be overwritten to cause an arbitrary write when launching the game. The most I was able to get was overwriting a small bit of info at the end of the heap which could only either continue as normal or svcBreak and crash. Sometimes the allocation is placed earlier in the heap at later loading points, but its possibility of exploitation, unless there's data loaded after that allocation which could be overwritten and exploited, is slim.

[shinyquagsire23]

Redirecting 3DS Input Over WiFi

A long while back I posted a video demonstrating an experiment I had done purely as a proof of concept for redirecting the 3DS input entirely over wireless. While I originally intended to port to NTR, I found myself losing interest in doing so, and unfortunately it was put on the backburner for a long while. It seemed though that every time I looked at NTR’s plugin documentation I just simply lost interest because actually going about doing it would end up taking a substantial amount of time which would be spent elsewhere. In any case, I decided to just make a short writeup of the hacks I used to make this possible. Do note that this is purely a writup of the theory of redirecting the input, not a tutorial on how to do it or how I specifically did it (there’s a few nitty gritty details in terms of actually getting the input to the 3DS over WiFi).

The basic idea I had from the beginning was this: find all the places where the input was read from, have them read from some other location (ie an unused part of .data or .bss), and then have another process handle actually giving these other locations the real inputs, either from the real 3DS hardware or over WiFi. I actually ended up having to deviate from this slightly in the end, but the original concept is still basically the same.

Initially, there were at least five main things I saw that needed redirection: The main HID buttons( ABXYLR, Start, Select, and the D-Pad), the Circle Pad, the Touch Screen, ZL and ZR, and the C-Stick. Naturally I started off with the HID buttons, since those would probably end up being the easiest. 3DBrew’s IO Registers page reveals the address 0x10146000 as being the main register used for HID input. However, this is the physical address, the address used for userland ends up being 0x1EC46000, which is the value we need to actually look for. The location where we’ll look is in the hid service process on the 3DS, the code of which can either be dumped via something similar to NTR CFW or decrypting the service NCCH off NAND (or grabbing it off CDN and decrypting it, that’s an option as well).

Code aside, searching for that register only yields two offsets, and simply replacing the HID Register’s address with your favorite spot in .data or .bss is enough to redirect that input. However now the question is, how will I even get input to this .data/.bss location? And therein lies the problems I had with NTR. The basic structure of retrieving the input normally vs having input redirected is as follows:

(Not sure how big that will turn up so here is a full res image just in case)

In the normal input process, hid will fetch the inputs of the normal HID buttons, Circle Pad, and Touchscreen, while ir will handle New 3DS inputs and Circle Pad Pro inputs such as ZL, ZR, and the C-Stick. These inputs are then either written to shared memory, or in the case of ir:rst, they can be fetched directly via a service command through IPC. In our modification, we have to have the service write it’s input elsewhere (except in the case of buttons, because those are simple enough to fetch directly from the registers through the hax process), and then this input is read from a separate hax process and then merged with inputs given to it over WiFi and written back to a separate location read by hid and ir. So we essentially have to write out input to one location, and read it from another. 

HID input was extremely easy to get done with this redirection process, because I could avoid writing out the HID input and just have the hax process read it instead. Once I had gotten inputs streaming over WiFi, I made the following video:

In this case, I ended up using a simple Python script to constantly toggle B’s input on and off, giving me that Frame Perfect Mega Spam.

The next task was Circle Pad input, which proved to be a lot more difficult than HID unfortunately. 3DBrew had no information as to where Circle Pad, Touch Screen, ZL/ZR or C-Stick input originated from in hardware, so what I ended up doing was dumping the hid process’ .data and .bss memory with my Circle Pad held to one direction, and then dumping it again with it resting and checking for differences in the memory dumped. After what was quite a lot of memory searching, I found gpio:HID command 0x00070040, which fetches both the Touch Screen and Circle Pad inputs. Since the routine which calls this command is completely isolated and not that large, I ended up rewriting it entirely and had it write the returned value to one location and had it read input from another. I also had to do some minor patches to force the Circle Pad to constantly be read (taking a guess, it probably uses interrupts to know exactly when to grab input). And with that, I had the Circle Pad and Touch Screen redirected.

Given that hooking up a Gamecube Controller to my 3DS in the first place was my original goal, I obviously needed C-Stick input. To start, I knew that the Circle Pad Pro had gotten it’s input from ir:rst since that communicates over infrared, and for the New 3DS to use it’s C-Stick in games which supported the CPP they actually ended up doing all C-Stick and ZL/ZR reads within that service. Digging through this service initially yielded little results, with no obvious service calls being used to fetch the inputs, and starting from ir:rst’s command handler just led to a rabbit hole of no results. So I ended up doing what I did for the Circle Pad: I held my C-Stick one direction to the best of my ability and dumped the memory, then left it at rest and dumped the memory again and diff’d the two dumps. Streaming the u32 reads from addresses which differed over RPC eventually showed some areas which displayed the C-Stick input, as well as the ZL/ZR button inputs, which definitely was a relief after having to scour for C-Stick input. The routine ended up being located at .text 0x10865C, and it just writes an i2c command and then reads from i2c a reply containing the c-stick and zl/zr data. So evidently, it seems they decided to expand the inputs on N3DS using an extra i2c device, kinda neat. There was also an additional function which accessed the ZL/ZR/C-Stick data at .text 0x102340, which required patching as well. Along with those two routines, the same always-updating adjustment made for the Circle Pad also had to be done for the C-Stick (although the code for both was definitely different), along with some other fixes.

With all my inputs hijacked and overriding over RPC, I then looked for a good way to pipe GameCube controller input to it. I eventually settled on modifying https://github.com/ToadKing/wii-u-gc-adapter/blob/master/old/wii-u-gc-adapter.py, which actually worked quite well. I modified it to output P1′s controller input over RPC to my 3DS, although I eventually found out that the C-Stick is rotated 45 degrees, which meant that I had to do some adjustment to the C-Stick readings from the GameCube controller before I sent it to the 3DS. However, after doing the modifications the C-Stick input works perfectly. With that, I made the following PoC video to show that streaming input over WiFi is definitely possible to do with minimal lag:

The only minor issues I ran into were disconnects between the Python script and the RPC thread, however I’ve since managed to remedy that. The main issue though is that you have to constantly stream inputs as fast as possible in order to prevent input from not always reaching the 3DS. Having a button randomly stick isn’t a pleasant experience, especially online with Smash 3DS.