I'm really interested in some technical tidbits :)

Quickly looking over the code I think you use a slightly different way to achieve the r/w than qwerty - you don't misalign a pointer, correct? Can you give a short description how you do it?

I wondered how to not crash the switch when done, and you seem to simply set everything to 0 `this.bufs[i] = 0;` and that solves that issue. Could you say a few words on why that is the case?

Any information yet you want to share about the execution environment? Is there some kind of sandbox? Anything interesting you can already access, or surprisingly not access?

Edit: One more question. Did you guys get to play any BotW yet? :D

I really love the overengineering of this toolkit <3

Yeah, so the approach I took to writing the core of the exploit (control over memory, basically) was very different than any other exploit I've seen for this vulnerability. Others smashed it with a bunch of buffers, with which you'd then attempt to get an overlap. Rather than that, I make a single ArrayBuffer and then a ton (2M) of Uint32Array views into that buffer. This makes controlling memory much more stable -- we have a 99.86% hit rate within the first 3 tries, all of which are automatic.

In terms of not crashing, it really comes down to appeasing the garbage collector. If there are non-object-objects on the heap (e.g. raw pointers just sitting there), the GC will explode and the whole thing crashes. So we take great care to ensure that only real JS objects exist at any point, outside of a few critical paths (which only last a few ms at worst). This leads to an insanely stable exploit base.

We're not really talking much about the execution environment yet, but what we can say is that it's really an upgraded (potentially rewritten?) 3DS OS.

There are around 30 or so people contributing ideas and what have you to the project, or wherever we can. Those listed on the actual site are just people who committed code to the repo. A lot of us play BotW though :p.

Slightly random question, how did the group form? Have you been working together on previous consoles?

Daeken posted on an HN post regarding the Switch before launch, that's how I found it and joined. A lot of members have joined since then, mostly by invitations from people within the general 3ds communities I suppose.

EDIT: Found the comment, https://news.ycombinator.com/item?id=13675898

Actually, this one grew totally organically. I used to do console hacking many years ago, and decided I wanted to get back into it with the Switch. People just started joining up, and bringing in trusted folks with them. A comment I made on HN a month ago or so really accelerated this.

Are you guys related to /r/switchhacks on Reddit? I see it's private but I still check every day or two hoping there'll be a big announcement :)

IIRC, there are several folks from /r/switchhacks around our server. I imagine the subreddit will get big once someone drops an end-user exploit.

I really enjoyed your video https://www.youtube.com/watch?v=xkdPjbaLngE&t=0s about it! Hope you make more on it ;)

I'm up to like 62 shrines and all the memories... if that counts as some kind of metric :)

Several of the developers of PegaSwitch are watching this thread. If you have any questions, shoot!

That was amazingly quick. The Switch hasn't been out that long. Kudos!

I understand that console hackers are notoriously secretive, but what are your plan(s) in the short and long term? Fostering the eventual homebrew community? Improving upon the OS? etc.

It's insane how much progress we made in a short time. I got the core of the exploit working within 36 hours of release, and then everyone's been working super hard to make it useful and awesome. I couldn't be more proud of this team!

In terms of our plans, it's pretty simple: learn more about the system, escalate privileges where we can, and eventually be able to run our own code.

Personally, I really want Linux running. With the things we know now, we'll almost certainly have Linux as soon as the kernel is under our control.

It would be an amazing hardware platform to get some classic PC games running on (with aid of DOSBox, etc). Commander Keen and the original Doom both come to mind.

I totally agree! The hardware is so close to Tegra dev boards that if/when we break the Switch kernel, we'll likely have full-blown Linux (or Android) in no time at all. I can't wait to be able to play SNES, PC, and more on this.

While a custom OS and home-brew will be great and increase overall hardware sales, I really hope the Switch doesn't develop a reputation for vulnerability to piracy and turn away third-party game developers so soon..

I agree, very much. What I'm hoping for (and currently have no reason to think otherwise) is that they're using TrustZone to handle all the DRM, which will make piracy a huge, huge amount of work. It may also prevent us from totally owning the console, but we'll see.

We generally felt like opening this to the public because we felt enough people had "outed" the WebKit bug used specifically. So it's already going to be fixed, might as well let people play while they can.

> That was amazingly quick. The Switch hasn't been out that long. Kudos!

"We'd like to thank the amazing rockstars at Google and Apple for making WebKit what it is today and following through on their mission to provide millions of people access to otherwise restricting environments. Without your lack of hard work and due diligence, WebKit would be a tied down, secure enclave that would not allow for consumers to exercise their constitutional rights."

Obviously Improving the OS is at least one of the advantages of being able to access everything. Can't see why a NTR styled system couldn't be done for the Switch as well.

It would most likely be much easier to accomplish once we have full access to the system, and hopefully could be branched out much more than what the 3DS does.

Hi devs, nice work. That was quick.

First and foremost: Of the devs that are following along this thread, who has spent the most time playing BOTW? Real question.

Another one: Why do you think Nintendo failed learn their lesson the first and second times?

I don't know that any of us have really spent too much time with it. I played for about 5 minutes and got frustrated, haha.

In terms of failing to learn their lesson, I think that it actually remains to be seen, to an extent. They failed by including an old WebKit bug, but the bigger failure was outsourcing their browser code in whole; that makes patching things so, so much harder. We'll see how bad the other layers are, but we've barely scratched the surface there.

They didn't exactly fail to learn lessons. They definately did. But it's a learn by experience thing. You can't learn from a mistake you don't know you made. And hackers aren't going to break through the window when the door's unlocked. So until they patch the easy stuff, the hard stuff will never be exploited. Live and learn I guess.

I don't believe Nintendo "failed to learn their lesson" the first time (I'd assume Wii) or second time (3DS?) I believe they were just dismissive of a lot of the things, because they were inexperienced. I still believe they are pretty inexperienced as it stands with a few of the things that they have done recently.

Awesome work. Have you guys looked into potential differences between the captive browser applet and the share applet, which opens when you try to share an image from your album to Facebook? The share applet is locked down to what seems to be a whitelist of URLs it can access.

I noticed on the share applet, there is a JavaScript object: window.nx that exposes some internal functions. However, I have had no luck actually calling those functions. If you want to know more about this, I can show you how I execute JavaScript on it and give you a list of window.nx functions

Yeah, so they're shared codebases (obviously), but they have some different stuff enabled. There's actually more in window.nx than is exposed even with the share applet, but no one has really dug too deep into it yet. I'm fairly certain there's a function to call to enable everything, but given our full access to the process, there's not much incentive there.

That said, I know there are a couple JS projects aiming to build a kind of 'debugger' into the web applets; might help them to know what you know!

How could I take something like PegaSwitch and use it to attack my "smart" TV? (It's running an old webkit, too)

You'd have to customize the exploit to the point where you basically need to start from scratch. All of the interesting stuff we have (from getting the stack pointer, to our insane JOP/ROP chain for native function calls) is specific to the Switch, and specific to the exact binary we're running in the context of. That said, the core of the exploit (sploitcore.setup/allocBuffers) probably wouldn't be too hard to port.

I've seen "it's the 3DS OS, but maybe rewritten" several times now.

I'm interested to learn more about this. Not for any practical use (well, maybe hacked Pokémon), but just to understand the choice. I naively figured this would be locked-down Android, but it's neat to see that it's FreeBSD + something.

Well, it's definitely not FreeBSD -- that much I can say for certain. As far as any of us can tell, that's solely the network stack. I honestly expected Linux with a custom userspace on top of it, and was quite surprised to see them continue with the custom kernel thing.

We're not talking much about details of the lower levels yet (frankly, we just don't know enough to confidently do so, even if we wanted to put it all out there), but it's almost certainly a fork or (partial?) rewrite.

Let me assure you, hacked Pokémon is an extremely practical use.

This may be a joke, but it actually can be very useful. Save backups, sharing cartridges/games among family members, etc.

My 6-year-old son accidentally threw away his event Munchlax in Pokemon Sun, which led me down the path of installing a full custom firmware on my 3DS and using PokeHex to restore the event card and get Munchlax back. He went from depressed to ecstatic. Now we can both have saves on our Pokemon games and he loves to show me how to get past gyms and other stuff. Great bonding experience.

A little bit further down this path, it's been amazing to be able to play classics like Super Mario Sunshine with real GameCube controllers and updated 4K textures via Dolphin. It looks like a brand new game, and again, my son loves hearing about how I played through it 15 years ago on the original GameCube. We just went on a short trip and we were able to play Super Smash Brothers Brawl on my laptop during the flight.

These experiences really underscore the power and importance of hacking communities. I'd love to see modifications to the legal structures to keep emulation, hacking, and modding communities out of the legal grey area and allow them to more fully flesh out their products. Their work is a vastly understated boon to our cultural heritage, and it allows it to be enjoyed and improved for generations. These people are heroes. The way we treat them is a shame.

The emulation and homebrew scene is at a crossroads now. cemu [1] is on track to earn 250k through Patreon (h/t byuu), which is a good way to get stomped on by Nintendo legal.

Open source is critical for the success of projects like Dolphin, but what do you think the emulator developers of the future are going to do when they see the cash they can earn by being secretive?

[1]: cemu.info

I just started playing with CEMU, very exciting piece of software.

I'm looking forward to a world where systems have workable emulators within several months of release, not several years. That will only bring the legal issues into more stark relief. So few of us realize that our intellectual property regime is holding back a lot of major accessibility and practicality improvements.

We need to fix it. Amazing projects like CEMU should not have to live in fear that someone is going to squash them and cause a lot of real harm just to protect someone else's bottom line.

I think emulators are great, but I'm certainly not excited by for-profit(?) proprietary emulators like CEMU.

>> which is a good way to get stomped on by Nintendo legal.

Having a pile of people running the Wii U version of Breath of the Wild on their gaming PCs will do it too:

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

I hadn't been keeping up with CEMU progress, but looking at the 1.7.3 progress preview video, it's damn impressive.

Oh, it wasn't actually a joke.

I'm one of the primary developers for PKHeX -- hacking Pokémon is a very practical use of time as far as I'm concerned.

I played super mario sunshine as a kid. Yikes, you're making me feel old :p

I played Super Mario Sunshine as an adult. Imagine how old you're making me feel :P

I have no idea what Super Mario Sunshine is... Now I feel old too.

And looking it up on the net didn't improve things... My second gaming console was an 8-bit nintendo...

1. I understand wanting to keep stuff under wraps for future use.

2. I understand that "future use" includes shiny, 6IV Arceus clones.

The PS4 uses FreeBSD too - I think a major reason is that the BSD license makes everything easier legally and prevents manufacturers from having to carefully separate and audit GPL code for compliance releases.

Idle note - my one attempt at game RE ever ended up finding GPL code in Ico for PS2 (a SCEJ game!). This fact never seemed to end up getting Team Ico in trouble.

Really? Already? Is this for the purposes of alerting Nintendo to vulnerabilities or is it just part of a quest to run "homebrew and definitely not pirated ohh no not at all" games on the Switch?

The vulnerability used is a very well-known one in WebKit from last year. Additionally, news articles about this vulnerability being present were already out there, so we saw no harm in releasing this.

I can't speak for others, but I have no intention of enabling piracy in any way; I just want Linux on it. Others will most likely abuse this for piracy at some point, which I personally find sad, but I don't control others.

The mildly unfortunate part is that you disclose the details of the exploit which only serves to allow Nintendo to patch it faster, without them having to invest the time to reverse engineer it themselves. Odds are this method of rooting won't survive the Switch's first patch release, and someone else will have to find a new loophole. If you had kept the exploit private, we may have gotten away with 2-3 patches' worth of time.

Whether the details are published by the developers of the exploit themselves or by a 3rd party, it's frustrating to see the hubris of proving one's ability to explain the exploit winning out over actually helping the users hold onto the ability to root for as long as possible.

I think you may be misunderstanding this -- greatly. The details of the exploit (that is, the part that Nintendo cares about -- the vulnerability) have been public since May of last year. The fact that the Switch is vulnerable to it (and it's being actively exploited by people) has been known by the public for at least two days. We decided to release this once the vulnerability was already going to be dead, not to accelerate its demise.

Additionally, this isn't a root, nor is it even close. This is the first stepping stone to be used by researchers to get deeper into the Switch and find new bugs. In no way will this impede the homebrew community; it will only serve to empower it.

We didn't though, a few others before us did and published GitHub repos for it already. Also, we're already in the first patch (2.0).

EDIT: Clarification, a few others already gave exploit code to use the Pegasus webkit exploit, and it's been going around the "news" sites. We just gave a prettier/easier to use implementation now that it was obvious Nintendo already saw it.

The Webkit bug used is well known and not new https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-4657

It's really Nintendo's fault for shipping an insecure version of Webkit.

The purpose can be "if there is DRM, it should be broken, so you can run whatever you want on hardware you paid for".

Of course it's not about practical reasons, since if you really need it, you can just get a normal Tegra based hardware without locks.