http://www.ktemkin.com/faq-fusee-gelee/

Kate has collected and answered the most common questions she's gotten regarding Fusée Gelée. Most notably she explains the three "types" of FG hacks, software, hardware (temporary) and hardware (permanent).

Enjoy!

Kate herself responded to this thread on page 26, thanks Kate!

There's a lot more here than I can easily respond to, so apologies if I miss posts or gloss over points.



This is correct-- while there likely will be software chains around for these things in the future, I don't see them as coming along as quickly as f-g. We don't have a non-coldboot exploit chain at all for 5.0.0-- and we haven't looked yet, as we've had other things to focus on and coldboot works. We do have one for 4.1.0, but it's centered around a couple of exploits that we don't want to burn-- we're hoping to use them to get an opportunity to poke around inside T214/Mariko.



I don't view you as particularly hostile, no. I don't know if challenge is generally a good thing-- sometimes you do have to accept that other people have different ethics or viewpoints from yourself and let that pass, especially if they're just doing stuff for fun-- but I don't view your post as hostile.



Jamais Vu (1.0.0 TrustZone hack) isn't my bug, but has been written up, and is just awaiting someone with the skills to have time to do a public interpretation. Déjà Vu is currently centered around the exploit I mentioned above, and we definitely want to hold onto that for as long as it's applicable. It's entirely a Switch bug, too, so I don't see it as being something that needs responsible disclosure.



For Déjà Vu, absolutely. (explained in last quote)



I don't agree that things like tweeting are ego. This is something I work on because I find it a lot of fun to hack on things, and there's definitely an aspect in which it makes me happy when seeing the results of things makes other people happy. There's also an aspect in which I hope that showing these things are possible inspires people to want to learn e.g. reverse engineering. This stuff is cool; and I want to share the excitement with others and lift them up as much as I can.

You don't have to believe me on that or like that that's my goal. I won't hold it against you if you don't.



I honestly support people updating when it makes sense; and I recognize that there's a conflict between holding back information and enabling others to make reasonable decisions about that. I don't like or feel good about secrecy, and I know it has implications. I've tried to be as clear as I can about the costs regarding updating without crossing the line into giving things away.



I think we've been pretty clear that 4.1.0 will eventually see a non-coldboot, software-only exploit with the same level of power. That's actually been posted on the ReSwitched Discord's FAQ for months, but I know the message gets skewed as its gets communicated over to other places. That's part of why I'm here, now-- I want to help clear things up.

The interactions between the operating system and the bootloader-- say on reboot-- are actually fairly limited; and knowing what any of them are is enough to point people at the particular section of bootrom that's vulnerable. That's why I'm not commenting on Fusée Gelée and how it relates to software-only solutions right now. I have said e.g. above that since there's no public way of getting the privileges necessary to run things, 4.1.0 isn't going to see a pure software solution that the public can use at the time that f-g is released. Software exploits will likely come in time; and it's possible we'll come up with things that are even easier than f-g.



I'm not sure if they'll take it seriously enough. I don't know how they are internally-- but I can't just assume they'll fail to do anything and skip disclosure. Honestly, I don't think a "security advisory" is really a bad thing, either-- there are definitely applications of Tegra chips that I and/or the public don't know about. If giving NVIDIA notice gives them time to explain exactly what's dangerous and allow their customers to remove and replace units from places where the vulnerability can cause harm, I consider that a win, and well worth delaying some public switch hacks by a few months.

I'll also say that my fear that vendors won't take the vulnerability seriously is a huge reason I'm so keen to get things out there-- and why I provided a date after which I'll tell the public what's going on that I've said was non-negotiable. I want to make sure this doesn't get hidden, and that people understand exactly what f-g can and can't accomplish, to minimize FUD while also letting people understand the actual risks are associated with using a vulnerable device.



It changes this from an exploit that's going to be usable before the affected people know it's a thing to something that people may have a chance to react to. Making the vulnerability public without disclosure really increases the odds someone is capable of using it to do bad.

I didn't really give NVIDIA a chance to sell-off stock; though. I've said publicly multiple times that there are bugs in Tegra processors well before NVIDIA reached out to me seeking disclosure. If anything, I think telling the public that these vulnerabilities exist while pursuing disclosure helps developers interested in using Tegra chips in the future ask the right question.



I've already said that while pure-software stuff is doable on 4.1.0; it'll be a wait. As far as I'm remembering, the only part of the chain that could require multiple tries to work is PegaSwitch, which is our browser-based entry point, and I haven't even tried the browser entry point that'll eventually be public to see how reliable it is. SciresM did the work to get our non-coldboot exploit working on 4.1.0; not me.



Yeah, that's hard-- especially as everyone has a different view as to how inconvenient things are. I don't know of a way to communicate this better without more details.

Incidentally, the 'inconvenience' verbiage came from SciresM and I discussing our respective views on updating. I think SciresM is more towards the opinion that people should hold back more often, where I'm more of the opinion that updating can be a good and reasonable option sometimes. The way we wound up phrasing things is a compromise between views.



(I'm going to assume this meant "on the hacking side". If not I'm not sure what hacking site you're referring to.)

Updating to latest just closes the possibility of using software exploits launched from Horizon, which can make setup more difficult. I know you'd like to know how much, but I unfortunately don't have a good way of qualifying that. As I've mentioned, if you're suffering from not being able to use your 3.0.1+ Switch, you probably do want to upgrade and just risk things being more inconvenient in the future. Worst comes to worst, if you decide you can't tolerate the inconvenience, you upgrade and then wind up having to figure out a modchip.

The downgrade protection fuses literally mean nothing to a system with f-g, which can entirely skip the downgrade check. Incidentally, SciresM actually accidentally bricked one of his systems in a way such that it was always failing the downgrade checks, and he's been able to use f-g to get that system up and running again.



I don't think that's clear at all, nor do I want to confirm or deny this. Sorry.



I think you're making a bunch of assumptions here, and that's maybe not a great idea. I'm not saying you're necessarily right or wrong; just that I don't think your assumptions are founded.



I don't think this contradicts. This is talking about vulnerabilities that aren't f-g; not because f-g doesn't work on 4.1.0, but because it's possible we may come up with vulnerabilities that are even nicer on 4.1.0 in the future.



I'm being as clear as I feel I can, and adding clarifications e.g. here where I think it helps. There will be different names for the the ways you can use f-g eventually; and I'll be fully open about everything once the summer rolls around and I'm not putting the disclosure timeline in jeopardy.



I know and have said about that this "bring your own exploit" business makes development exclusive, and that's exclusionary and I really don't like it-- I just don't see a way around it. I would love to get more developers and more perspective, and that's why my release date for f-g is tied to my disclosure timeline and not in particular to Atmosphère's release.




I've tried to point out approximately what the difficulty would be for some of the options to kind of provide this, but this is a hard thing to accomplish. In this case, providing details that are more specific really points a finger at vulnerability details, so there's not much I'm comfortable sharing. I've shared what I could-- as a data point, some of the other teams have outright stated that they think I've shared too much already and made things obvious. I don't agree or necessarily care about their opinons, but c'est la vie.



Well, this isn't the case. This has been disclosed to Nintendo, too-- as NVIDIA shares their vulnerability findings with downstream customers. It's more general malicious actors that I'd be worried about.



See above-- but I don't think I'd advise specifically updating to 4.1.0 unless that gives you enough access to the games you want.



I'm also super glad that we can do a lot of our work in the open. I hope there's a lot more of it in the future-- and I'd love to stream some of it.



I find the requirement disheartening as well, but I think this is the right way to do things, for now. I've explained my rationale above; feel free to ask questions.



I'm not sure why people are against communication, here. There were definite benefits to talking about f-g in the first place; including that it demonstrates that Tegra chips are vulnerable-- which hopefully influences buying decisions in the future and puts pressure on NVIDIA to seek as much of a fix as they can. After that there seemed to be definitely benefits to talking about more details, even in the limited sense that I'm able to. I've tried to give people more information than the nothing they would have had so they could have more of an idea whether it's be a good idea to e.g. pre-order a modchip or update their system. I know it can be frustrating to not get full disclosure, and that more information would help people to make a better or more conclusive decision, but full disclosure isn't an option until this summer. I don't think that's a reason to hold back information.



I don't have specific answers to your questions, unfortunately-- but I think it sounds like the main purpose of this Switch is as a gaming device and maybe you should upgrade and enjoy playing games with your son.



I don't think that asking for clarification is criticism. It might be rude to push me to answer something I said I wouldn't, but I don't think there's harm in answer.



I don't think I've said anything about opening the console or not. See above for my views on updating?



I'm not sure where you got this impression, or why you're confident about things enough to claim you know about the internal values or working of ReSwitched. This is also easily disprovable just from public information--Hedgeberg has tested out f-g on stream. I don't see it as great opsec to enumerate how many people have access to the vulnerability, but we've long had a policy of only giving exploit details to those who actually want to know them and are in a position where they can use them to help. This is a basic security precaution and not about trust.

I'm actually not sure how this is relevant to the broader discussion. Based on your post history, I can tell that you strongly support TX and the option they're providing, and you're welcome to that, but I think throwing around generic unfounded criticism of RS doesn't do much good and distracts from me answering community questions.



I don't think they're obviously more convenient, as they exist right now. They're both inherently however-tethered-you-consider-PegaSwitch, take a bunch of time to run, and rely on a pegaswitch entry point.



That's not correct-- everyone on a current hardware revision will be able to install and use CFW the day it's released, if they're willing to put in the effort and potentially take on some minor risk.



I'm actually not sure what you mean by this entire post? Sorry about that-- I'd love to address your ideas, but unfortunately I can't figure out your meaning.



That was about me having fun by trying to see if a DIY, cheap modchip option is reasonable. It turns out it is. As you've noted, it's not necessary on any firmware. I just really like the idea that the open exchange of knowledge -- especially when profit's not a motive -- can result in creation of neat options for the community. ^-^



Yep; that's exactly what it means.



I don't think this has been at all implied-- and you'd be hard pressed to find a way to make a solder-less Arduino option that even remotely fits in the Switch case.

I should also clarify that the DIY option isn't solderless.

If you have or are going to get the game anyway, you can. Those versions are pretty much interchangeable in the long-term.



Yep-- and it's possible at some point that we'll allow you to install Fake News without Puyo using f-g/Atmosphère. The original plan was to release Atmosphère for 1.0.0 first while we tried to figure out how to deal with Fusée Gelée, but we actually wound up with a disclosure schedule that was faster than we'd thought.

 

[guily6669]

Lol...

Well I my self don't blame Kate, SciresM and the whole reswitched team neither TX or anyone involved in Switch hacking\modding I love them all and I will simply keep waiting 4 something to be released.

Also I love their dramas too like Kate attacked TX, TX responded that she has no clue at all on how their device works lol, I always like this kind of drama .

Anyway since they are not being paid by me I just keep waiting 4 something and I have no knowledge to hack the console, I only learned C++ a few time ago made a crap car stand app and never coded again... So I would not blame or can say anything bad about any of them...

Ps: 4 now Voksi is my gaming GOD he patched a lot of pc games with multiplayer working and now our pirated games even have anti cheat protection that even the originals don't lol, biggest pirating community ever!

 

[Onibi]

Lol...

Well I my self don't blame Kate, SciresM and the whole reswitched team neither TX or anyone involved in Switch hacking\modding I love them all and I will simply keep waiting 4 something to be released.

Yea, I mean if I was a user I would also be like: "Great, free stuff. Whenever. whatever. They are the greatest for giving me free stuff. Keep it coming.". (Maybe not the "greatest" stuff - I am not big on personal cults and idols.)

But even then, I am not sure this is really benefiting users either. This (likely late) summer release date is there because nobody else can contribute. They are not doing this alone because they are the greatest and nobody else can do what they do. They are doing it alone because nobody else can run and thus develop the code on their machines.

 

[smf]

Actuality if you start to get to specific it gives pointers on where to look for other hackers, even if for the normal users it doesn't seem like it would. I mean they already know it involves the bootrom, any more specifics and you start to really give it away to any malicious parties looking for it.

I'm not talking about specifics, every question is answered like a politician.

I remember the Gamecube Phantasy Star Online homebrew launcher, which gives a benchmark for how impractical the methods people are prepared to create and that didn't require you to open the console on each coldboot.

The "you don't need"/"no dangerous modifications" answers don't answer the question, because it could mean you don't need it if you use a method that is chronically impractical and to achieve the effects most people are expecting in a usable way is going to need a TX like modchip which involves "dangerous" modifications.

I can see why she wouldn't answer them honestly, because it is likely to really kill the hype.

In terms of the switch, I can't see anyone else entering the market with both TX and reswitched claiming that they will have solutions soon. It's more likely that modchip makers will move in after reswitched release their solution, to make it practical.

Outside of the switch the self driving systems would be interesting, but anyone looking to exploit those has a lot more money than switch hackers & other options are available to them. But if they sit back then they'll get the exploit anyway & as we all know it's unpatchable. Fortunately it's not a safety issue as the hardware exploit requires physical access.

 

[ktemkin]

Hi, all-- sorry it's taken me so long to reply to some of this. I'll admit, I've been kind of put off by some of of the hostility in the community here, but I do want to answer questions and share knowledge where I can.

I can definitely respond to some of the things posted here. First, the non-technical:

• Yes, I'm a member of ReSwitched. I joined in mid-January and have wound up in one of the leadership roles, there. I like the team and really value everything they do for the community.
• I can definitely empathize with those frustrated by exclusivity. I really don't like anything that impedes sharing of knowledge, and I value teaching others where I can above pretty much everything else I do. Where I can avoid being secretive, I really try to. There are reasons RS members might not give out all the information they can: the major case is when it hurts our chances of getting access to the inside of future software versions.
• I do try my best to avoid having any ego about this kind of stuff. I'm not sure I always succeed, but I do try. I don't think I tweet about things I've done out of ego or for attention-- it's more that I've done something that I'm happy about and want to share about it. I don't go out of my way to create these kinds of threads; I just talk about things I think are cool on Twitter and sometimes people get overexcited. That's literally my personal twitter; and I haven't intended it to be a communication channel for a "public-facing" person. I just tweet about stuff I like or care about there.
• I don't really like it when hype develops over ambiguous solutions, either. We've announced when we have hacks for various versions 1) because we think they're cool and sometimes like to post things we're happy about to our twitters, and 2) to help people make decisions about which software versions they could feel are guaranteed to get CFW/homebrew. I didn't release the FAQ to build hype, either. I specifically released it to help quell some inaccurate rumors about what we have and to try and help people know that there are alternatives to proprietary modchips, so they can decide how to spend their money.
• I keep seeing the repeated comment that people don't think it'd be dangerous to disclose "just a little more" in a particular area. It's possible I'm being overcautious, but I'm trying to walk a tight line between sharing what I know and revealing information that can point out exactly where to look for the vulnerability. I said I'd try to keep this vulnerability from reaching the public for long enough for vendors to communicate with their downstream customers, and I don't want to betray that promise.
• Part of the reason why "responsible" disclosure of this vulnerability was an easy choice is that NVIDIA has already designed a new revision of the SoC used in the switch (the T214/Mariko); and I have strong technical reason to believe that its bootloader will _not_ vulnerable to Fusée Gelée, and that Nintendo will be releasing a Switch revision based on the new console "soon". Accordingly, I didn't see much advantage in hiding it, and I did see a potential danger in releasing it to the public without disclosing first.
• In response to suggestion that the danger regarding the vulnerability is overstated: people _always_ categorically misestimate the danger associated with these vulnerabilities; and sometimes it's hard to tell in which direction. I can say that the vulnerability affects the Tegra family, and not just the Tegra X1; and I less think this is likely to be used to crash cars than to violate people's privacy-- I don't like the possibility that someone could easily install a tracking rootkit on the affected devices. I honestly don't know if it's likely, but given the previous point I think it'a worth a short delay so I don't have to worry about that. I'm not a super-moral savior or anything; I just don't want to lose sleep wondering if I've hurt anyone.
• The "lower is better" mantra has been a result of us having more options at our disposal in lower firmwares; and not wanting to declare a firmware 'safe' until we know we have a full working exploit chain on that firmware. I haven't participated much in the "stay on 3.0.0" style suggestions, as I honestly believe there are trade-offs to these things, and for a lot of people playing the most recent games is the thing that makes the system worth it. My view is that I want to get you as much information as I can and let you make those decisions-- and I promise you'll have all the information I can give you before too much of the (Northern Hemisphere) summer goes by.
• As an addendum to the point above, if you really want to upgrade, I think that's up to you and sometimes an entirely valid decision. You're not going to lose out on CFW if you have a current-revision Switch; and honestly sometimes it's worth risking some inconveniences to have access to online play and the latest games. I know sometimes people take a really "upgrading is a sin" mentality, but I definitely can see cases where it's entirely valid. I think some of us really just don't want anyone to feel like they've missed out on something due to an upgrade.
• The name "Fusée Gelée" is a reference to the fact that it's a coldboot launcher meant to launch payloads "over the Horizon"-- with Horizon being the name of the Switch's OS. I called it Rocket for a little while, but Rocket was taken by the Rocket Launcher for 3DS; this is the downside of Nintendo keeping the same OS name: the puns get stale. If you'd prefer to call it "coldboothax", you're welcome to it. =P

And the technical:

• No, you're not going to need to disassemble your switch every time you want to boot it. I consider the 'inconvenient' process something I'd be willing to do on the main Switch the spouse and I use for games; and I definitely don't have the patience to take out all those tiny screws every time I want to boot.
• I don't want to comment on tethered-vs-untethered, if just because I don't want to narrow down where the vulnerability could be. It also tends to be the case that every time I ask what exactly people consider a 'tethered' vulnerability, an argument breaks out. I don't care about the hype; feel free assume the worst case for purposes of deciding how excited you'll be. The one exception I'll say to this is that you can consider any solution involving a modchip to be fully standalone.
• The vulnerability is entirely deterministic: there's no "trying repeatedly until it works". The bootrom doesn't have fancy things like ASLR... or like a working MMU.
• The main benefit of being on 4.1.0 is that we have more exploit chains than f-g that work for it. We can simulate a coldboot on up to 4.1 without actually having a coldboot vulnerability; we haven't spent time being able to do that on 5.x yet. I've mentioned that f-g isn't a "holy grail" exploit-- it's not something where you can press one easy button and then have your Switch boot into untrusted code forever-- but that it's still possible that we'll find one that you can accomplish using Pegaswitch on one of the firmwares we still have access to.
• You won't notice a difference between >3.0.0 and latest in terms of convenience at time of release. The exploit that enables us to have that level of access without f-g on those versions is one that SciresM/motezazer/I came up with, and we've agreed to hold off on releasing it yet in the hopes that it gives us more options on the coming hardware revisions.

 

[sarkwalvein]

Welcome @ktemkin

 

[annson24]

• I can definitely empathize with those frustrated by exclusivity. I really don't like anything that impedes sharing of knowledge, and I value teaching others where I can above pretty much everything else I do. Where I can avoid being secretive, I really try to. There are reasons RS members might not give out all the information they can: the major case is when it hurts our chances of getting access to the inside of future software versions.

I really don't understand those people. I mean, they get frustrated if you don't give them something to look forward to. But if you do give them something, nothing will change even though everyone knows it's not ready yet.

Anyway thank you for all your hard work and some of us also do empathize you. On behalf of the others who feel the same way, we're sorry for all the flames your team has been receiving from impatient members.

PS. Good read.

 

[Xandroz]

So From what i understood the exploits in 1.0.0 that were patched wont be releasedso they might help in newer revision
or did i mis read
Welcome to the forum, and thanks for your hard work for the scene @ktemkin

 

[brickmii82]

Hi, all-- sorry it's taken me so long to reply to some of this. I'll admit, I've been kind of put off by some of of the hostility in the community here, but I do want to answer questions and share knowledge where I can.

I can definitely respond to some of the things posted here. First, the non-technical:

• Yes, I'm a member of ReSwitched. I joined in mid-January and have wound up in one of the leadership roles, there. I like the team and really value everything they do for the community.
• I can definitely empathize with those frustrated by exclusivity. I really don't like anything that impedes sharing of knowledge, and I value teaching others where I can above pretty much everything else I do. Where I can avoid being secretive, I really try to. There are reasons RS members might not give out all the information they can: the major case is when it hurts our chances of getting access to the inside of future software versions.
• I do try my best to avoid having any ego about this kind of stuff. I'm not sure I always succeed, but I do try. I don't think I tweet about things I've done out of ego or for attention-- it's more that I've done something that I'm happy about and want to share about it. I don't go out of my way to create these kinds of threads; I just talk about things I think are cool on Twitter and sometimes people get overexcited. That's literally my personal twitter; and I haven't intended it to be a communication channel for a "public-facing" person. I just tweet about stuff I like or care about there.
• I don't really like it when hype develops over ambiguous solutions, either. We've announced when we have hacks for various versions 1) because we think they're cool and sometimes like to post things we're happy about to our twitters, and 2) to help people make decisions about which software versions they could feel are guaranteed to get CFW/homebrew. I didn't release the FAQ to build hype, either. I specifically released it to help quell some inaccurate rumors about what we have and to try and help people know that there are alternatives to proprietary modchips, so they can decide how to spend their money.
• I keep seeing the repeated comment that people don't think it'd be dangerous to disclose "just a little more" in a particular area. It's possible I'm being overcautious, but I'm trying to walk a tight line between sharing what I know and revealing information that can point out exactly where to look for the vulnerability. I said I'd try to keep this vulnerability from reaching the public for long enough for vendors to communicate with their downstream customers, and I don't want to betray that promise.
• Part of the reason why "responsible" disclosure of this vulnerability was an easy choice is that NVIDIA has already designed a new revision of the SoC used in the switch (the T214/Mariko); and I have strong technical reason to believe that its bootloader will _not_ vulnerable to Fusée Gelée, and that Nintendo will be releasing a Switch revision based on the new console "soon". Accordingly, I didn't see much advantage in hiding it, and I did see a potential danger in releasing it to the public without disclosing first.
• In response to suggestion that the danger regarding the vulnerability is overstated: people _always_ categorically misestimate the danger associated with these vulnerabilities; and sometimes it's hard to tell in which direction. I can say that the vulnerability affects the Tegra family, and not just the Tegra X1; and I less think this is likely to be used to crash cars than to violate people's privacy-- I don't like the possibility that someone could easily install a tracking rootkit on the affected devices. I honestly don't know if it's likely, but given the previous point I think it'a worth a short delay so I don't have to worry about that. I'm not a super-moral savior or anything; I just don't want to lose sleep wondering if I've hurt anyone.
• The "lower is better" mantra has been a result of us having more options at our disposal in lower firmwares; and not wanting to declare a firmware 'safe' until we know we have a full working exploit chain on that firmware. I haven't participated much in the "stay on 3.0.0" style suggestions, as I honestly believe there are trade-offs to these things, and for a lot of people playing the most recent games is the thing that makes the system worth it. My view is that I want to get you as much information as I can and let you make those decisions-- and I promise you'll have all the information I can give you before too much of the (Northern Hemisphere) summer goes by.
• As an addendum to the point above, if you really want to upgrade, I think that's up to you and sometimes an entirely valid decision. You're not going to lose out on CFW if you have a current-revision Switch; and honestly sometimes it's worth risking some inconveniences to have access to online play and the latest games. I know sometimes people take a really "upgrading is a sin" mentality, but I definitely can see cases where it's entirely valid. I think some of us really just don't want anyone to feel like they've missed out on something due to an upgrade.
• The name "Fusée Gelée" is a reference to the fact that it's a coldboot launcher meant to run payloads "over the Horizon"-- with Horizon being the name of the Switch's OS. I called it Rocket for a little while, but Rocket was taken by the Rocket Launcher for 3DS; this is the downside of Nintendo keeping the same OS name: the puns get stale. If you'd prefer to call it "coldboothax", you're welcome to it. =P

And the technical:

• No, you're not going to need to disassemble your switch every time you want to boot it. I consider the 'inconvenient' process something I'd be willing to do on the main Switch the spouse and I use for games; and I definitely don't have the patience to take out all those tiny screws every time I want to boot.
• I don't want to comment on tethered-vs-untethered, if just because I don't want to narrow down where the vulnerability could be. It also tends to be the case that every time I ask what exactly people consider a 'tethered' vulnerability, an argument breaks out. I don't care about the hype; feel free assume the worst case for purposes of deciding how excited you'll be. The one exception I'll say to this is that you can consider any solution involving a modchip to be fully standalone.
• The vulnerability is entirely deterministic: there's no "trying repeatedly until it works". The bootrom doesn't have fancy things like ASLR... or like a working MMU.
• The main benefit of being on 4.1.0 is that we have more exploit chains than f-g that work for it. We can simulate a coldboot on up to 4.1 without actually having a coldboot vulnerability; we haven't spent time being able to do that on 5.x yet. I've mentioned that f-g isn't a "holy grail" exploit-- it's not something where you can press one easy button and then have your Switch boot into untrusted code forever-- but that it's still possible that we'll find one that you can accomplish using Pegaswitch on one of the firmwares we still have access to.
• You won't notice a difference between >3.0.0 and latest in terms of convenience at time of release. The exploit that enables us to have that level of access without f-g on those versions is one that SciresM/motezazer/I came up with, and we've agreed to hold off on releasing it yet in the hopes that it gives us more options on the coming hardware revisions.

Appreciate you stopping by. While this community can be quite abrasive, we can be quite loving as well. Many here awe at what you security analysts accomplish in your spare time, and are proud of the entire community when an exploit is accomplished in any capacity.

Like anything though, there’s good and bad. Pros and cons. Ups and downs. But I’d like to think that since you made the effort to keep us updated, you know that already. Thanks for engaging with us, and I hope you’ll stay.

 

[ktemkin]

I really don't understand those people. I mean, they get frustrated if you don't give them something to look forward to. But if you do give them something, nothing will change even though everyone knows it's not ready yet.

I can understand it-- I think the reality is unfortunate. If I were in a lot of people's places, I could see myself wanting to develop cool things for a system-- to contribute to Atmosphère, or to help with getting Linux or Android up and running-- but being frustrated with the "bring your own vulnerability" approach to development. It's definitely something that excludes people who have things to offer, and I don't like it; but it seems like a necessary evil.

I am working to change the 'exclusivity', where I can-- not least by trying to get the public f-g, which I hope will be a powerful development and exploration tool.

So From what i understood the exploits in 1.0.0 that were patched wont be releasedso they might help in newer revision
or did i mis read @ktemkin

No, this isn't what I was suggesting. Jamais Vu, which is SciresM and motezazer's exploit, already has a public writeup; and will be released on SciresM has time to focus on that. Right now he's focusing on getting a cool CFW available for the folks when f-g is released.

 

[brickmii82]

I can understand it-- I think the reality is unfortunate. If I were in a lot of people's places, I could see myself wanting to develop cool things for a system-- to contribute to Atmosphère, or to help with getting Linux or Android up and running-- but being frustrated with the "bring your own vulnerability" approach to development. It's definitely something that excludes people who have things to offer, and I don't like it; but it seems like a necessary evil.

I am working to change the 'exclusivity', where I can-- not least by trying to get the public f-g, which I hope will be a powerful development and exploration tool.



No, this isn't what I was suggesting. Jamais Vu, which is SciresM and motezazer's exploit, already has a public writeup; and will be released on SciresM has time to focus on that. Right now he's focusing on getting a cool CFW available for the folks when f-g is released.

Out of curiousity, what’s the typical time frame for a hardware manufacturer to patch vulnerabilities like this? I’m talking actual factory changes. From discovery to solution. I’m an automotive technician so I’m curious how this compares to recalls and TSB’s, or technical service bulletins, in the auto industry.

 

[gianox]

@ktemkin My car has a tegra 3 cpu with celular access as well as access to all controls. Could you potentially hijack it using this exploit and crash me? I am starting to get worried.

 

[Xandroz]

thanks for the clarification
Will Keep Hanging In There
Me And My Fellow 1.0.0

 

[ktemkin]

Out of curiousity, what’s the typical time frame for a hardware manufacturer to patch vulnerabilities like this? I’m talking actual factory changes. From discovery to solution. I’m an automotive technician so I’m curious how this compares to recalls and TSB’s, or technical service bulletins, in the auto industry.

Well, in this case the vulnerability's not actually patchable, so I have no idea what kind of window would be reasonable for communication and/or part replacement. If it were theoretically patchable, usually a standard disclosure window would be around 90 days.

@ktemkin My car has a tegra 3 cpu with celular access as well as access to all controls. Could you potentially hijack it using this exploit and crash me? I am starting to get worried.

I very strongly doubt that f-g itself would-- especially without a pivot to get you into the CPU via the cellular. I'd be more concerned about other things in their security architecture first.

 

[Absintu]

my thanks to you and all the reswitched team for giving some info out
gonna grab some popcorns, to see the rest of the drama in this thread from now on
also, welcome to temp

 

[subcon959]

I can understand it-- I think the reality is unfortunate. If I were in a lot of people's places, I could see myself wanting to develop cool things for a system-- to contribute to Atmosphère, or to help with getting Linux or Android up and running-- but being frustrated with the "bring your own vulnerability" approach to development. It's definitely something that excludes people who have things to offer, and I don't like it; but it seems like a necessary evil.

I am working to change the 'exclusivity', where I can-- not least by trying to get the public f-g, which I hope will be a powerful development and exploration tool.

I might not agree with some of the disclosure window logic, but I do appreciate your words here. There's nothing worse than feeling excluded from learning (and playing with) cool things.

 

[Lumince]

The main benefit of being on 4.1.0 is that we have more exploit chains than f-g that work for it. We can simulate a coldboot on up to 4.1

Im glad that I stayed on 4.1.0 then. Thanks for the explanations!

 

[TotalInsanity4]

Hi, all-- sorry it's taken me so long to reply to some of this. I'll admit, I've been kind of put off by some of of the hostility in the community here, but I do want to answer questions and share knowledge where I can.

I can definitely respond to some of the things posted here. First, the non-technical:

• Yes, I'm a member of ReSwitched. I joined in mid-January and have wound up in one of the leadership roles, there. I like the team and really value everything they do for the community.
• I can definitely empathize with those frustrated by exclusivity. I really don't like anything that impedes sharing of knowledge, and I value teaching others where I can above pretty much everything else I do. Where I can avoid being secretive, I really try to. There are reasons RS members might not give out all the information they can: the major case is when it hurts our chances of getting access to the inside of future software versions.
• I do try my best to avoid having any ego about this kind of stuff. I'm not sure I always succeed, but I do try. I don't think I tweet about things I've done out of ego or for attention-- it's more that I've done something that I'm happy about and want to share about it. I don't go out of my way to create these kinds of threads; I just talk about things I think are cool on Twitter and sometimes people get overexcited. That's literally my personal twitter; and I haven't intended it to be a communication channel for a "public-facing" person. I just tweet about stuff I like or care about there.
• I don't really like it when hype develops over ambiguous solutions, either. We've announced when we have hacks for various versions 1) because we think they're cool and sometimes like to post things we're happy about to our twitters, and 2) to help people make decisions about which software versions they could feel are guaranteed to get CFW/homebrew. I didn't release the FAQ to build hype, either. I specifically released it to help quell some inaccurate rumors about what we have and to try and help people know that there are alternatives to proprietary modchips, so they can decide how to spend their money.
• I keep seeing the repeated comment that people don't think it'd be dangerous to disclose "just a little more" in a particular area. It's possible I'm being overcautious, but I'm trying to walk a tight line between sharing what I know and revealing information that can point out exactly where to look for the vulnerability. I said I'd try to keep this vulnerability from reaching the public for long enough for vendors to communicate with their downstream customers, and I don't want to betray that promise.
• Part of the reason why "responsible" disclosure of this vulnerability was an easy choice is that NVIDIA has already designed a new revision of the SoC used in the switch (the T214/Mariko); and I have strong technical reason to believe that its bootloader will _not_ vulnerable to Fusée Gelée, and that Nintendo will be releasing a Switch revision based on the new console "soon". Accordingly, I didn't see much advantage in hiding it, and I did see a potential danger in releasing it to the public without disclosing first.
• In response to suggestion that the danger regarding the vulnerability is overstated: people _always_ categorically misestimate the danger associated with these vulnerabilities; and sometimes it's hard to tell in which direction. I can say that the vulnerability affects the Tegra family, and not just the Tegra X1; and I less think this is likely to be used to crash cars than to violate people's privacy-- I don't like the possibility that someone could easily install a tracking rootkit on the affected devices. I honestly don't know if it's likely, but given the previous point I think it'a worth a short delay so I don't have to worry about that. I'm not a super-moral savior or anything; I just don't want to lose sleep wondering if I've hurt anyone.
• The "lower is better" mantra has been a result of us having more options at our disposal in lower firmwares; and not wanting to declare a firmware 'safe' until we know we have a full working exploit chain on that firmware. I haven't participated much in the "stay on 3.0.0" style suggestions, as I honestly believe there are trade-offs to these things, and for a lot of people playing the most recent games is the thing that makes the system worth it. My view is that I want to get you as much information as I can and let you make those decisions-- and I promise you'll have all the information I can give you before too much of the (Northern Hemisphere) summer goes by.
• As an addendum to the point above, if you really want to upgrade, I think that's up to you and sometimes an entirely valid decision. You're not going to lose out on CFW if you have a current-revision Switch; and honestly sometimes it's worth risking some inconveniences to have access to online play and the latest games. I know sometimes people take a really "upgrading is a sin" mentality, but I definitely can see cases where it's entirely valid. I think some of us really just don't want anyone to feel like they've missed out on something due to an upgrade.
• The name "Fusée Gelée" is a reference to the fact that it's a coldboot launcher meant to launch payloads "over the Horizon"-- with Horizon being the name of the Switch's OS. I called it Rocket for a little while, but Rocket was taken by the Rocket Launcher for 3DS; this is the downside of Nintendo keeping the same OS name: the puns get stale. If you'd prefer to call it "coldboothax", you're welcome to it. =P

And the technical:

• No, you're not going to need to disassemble your switch every time you want to boot it. I consider the 'inconvenient' process something I'd be willing to do on the main Switch the spouse and I use for games; and I definitely don't have the patience to take out all those tiny screws every time I want to boot.
• I don't want to comment on tethered-vs-untethered, if just because I don't want to narrow down where the vulnerability could be. It also tends to be the case that every time I ask what exactly people consider a 'tethered' vulnerability, an argument breaks out. I don't care about the hype; feel free assume the worst case for purposes of deciding how excited you'll be. The one exception I'll say to this is that you can consider any solution involving a modchip to be fully standalone.
• The vulnerability is entirely deterministic: there's no "trying repeatedly until it works". The bootrom doesn't have fancy things like ASLR... or like a working MMU.
• The main benefit of being on 4.1.0 is that we have more exploit chains than f-g that work for it. We can simulate a coldboot on up to 4.1 without actually having a coldboot vulnerability; we haven't spent time being able to do that on 5.x yet. I've mentioned that f-g isn't a "holy grail" exploit-- it's not something where you can press one easy button and then have your Switch boot into untrusted code forever-- but that it's still possible that we'll find one that you can accomplish using Pegaswitch on one of the firmwares we still have access to.
• You won't notice a difference between >3.0.0 and latest in terms of convenience at time of release. The exploit that enables us to have that level of access without f-g on those versions is one that SciresM/motezazer/I came up with, and we've agreed to hold off on releasing it yet in the hopes that it gives us more options on the coming hardware revisions.

I wish the 'temp had something more than a "like" button just for this comment. Thank you very much, that cleared up a lot for me and now I know that I'm going to stick around on 4.1 0

 

[Onibi]

Hi, all-- sorry it's taken me so long to reply to some of this. I'll admit, I've been kind of put off by some of of the hostility in the community here, but I do want to answer questions and share knowledge where I can.

Hi and welcome! Not sure which hostility you mean, there has been some different ones going around. Mine personally is less hostility then challenge. If I see a behavior that I can't really explain or agree with I will challenge it and assume negative motives to get a comprehensive response out of people Typically that works quite well. Don't misunderstand my challenge of your motives as hostility towards you personally thou. I wish you nothing but good and absolutely congratulate you to your findings.

I can definitely respond to some of the things posted here. First, the non-technical:

• Yes, I'm a member of ReSwitched. I joined in mid-January and have wound up in one of the leadership roles, there. I like the team and really value everything they do for the community.

• I can definitely empathize with those frustrated by exclusivity. I really don't like anything that impedes sharing of knowledge, and I value teaching others where I can above pretty much everything else I do. Where I can avoid being secretive, I really try to. There are reasons RS members might not give out all the information they can: the major case is when it hurts our chances of getting access to the inside of future software versions.

Hmm. Glad to hear this. However, this does not really explain why neither the Trustzone exploit nor the bootrom bug, or various kernel bugs are public. Literally, we got no public access to the system so far

Is the Trustzone exploit expected to be useful for the hardware revision? Then I would at least understand that ...

• I do try my best to avoid having any ego about this kind of stuff. I'm not sure I always succeed, but I do try. I don't think I tweet about things I've done out of ego or for attention-- it's more that I've done something that I'm happy about and want to share about it. I don't go out of my way to create these kinds of threads; I just talk about things I think are cool on Twitter and sometimes people get overexcited. That's literally my personal twitter; and I haven't intended it to be a communication channel for a "public-facing" person. I just tweet about stuff I like or care about there.

Well, tweeting, that's kinda ego I don't even mind some ego, and I can understand it. It's when it feels like that the "nth release" so far was tweets or not super comprehensive FAQ or less then informative interview that it becomes tiring. I mean it literally is telling others what they can't have, no

• I don't really like it when hype develops over ambiguous solutions, either. We've announced when we have hacks for various versions 1) because we think they're cool and sometimes like to post things we're happy about to our twitters, and 2) to help people make decisions about which software versions they could feel are guaranteed to get CFW/homebrew. I didn't release the FAQ to build hype, either. I specifically released it to help quell some inaccurate rumors about what we have and to try and help people know that there are alternatives to proprietary modchips, so they can decide how to spend their money.

Very ambiguous sometimes ... and not always when needed. The issue is that people who wait would for example like to play, and thus update.

For example: I absolutely get why @SciresM initially advised to stay lower. Because he didn't have the higher FW bugs. I also get why later he said: "Stay low" - IMO he was actually planing to release stuff per firmware once the TZ bug was found. So while he would work on FW 2.0 he could release the exploit for 1.0.

But by now the playfield is different. You guys are going with the bootrom (thanks!). So it would be very helpful to make clear without ambiguity if people have a reason to stay on a lower firmware (for the software exploit). I mean, the bootrom can barely be altered (fuses + micro asm updates) so it's super hard to decipher from the FAQ what 4.1.0 is going to have trouble with. I mean either on 4.1.0 you got the software stack compromised to pull of the same exploit or you don't. If you don't, I would make it clear, if you do and there is an issue, then I don't think that naming the complexity will hurt anybody, no? Why the secrecy there for example? Whos gonna gain from that knowledge? That's likely on the nintendo software stack, no? So it does not help tegra bootrom issue hunters, no?

• I keep seeing the repeated comment that people don't think it'd be dangerous to disclose "just a little more" in a particular area. It's possible I'm being overcautious, but I'm trying to walk a tight line between sharing what I know and revealing information that can point out exactly where to look for the vulnerability. I said I'd try to keep this vulnerability from reaching the public for long enough for vendors to communicate with their downstream customers, and I don't want to betray that promise.

My point on this would be that I actually question if this type of disclosure is not hurting more people then you assume it potentially helps. Right now, I am convinced nvidia is selling affected devices and potentially even still printing them.
The whole thing is based on the assumption that actions are being taken, instead I think they are just going to push the issue to the next layer in a typical security advisory message to their customers. They will have to deal with it, and they likely will do nothing because the issue is not directly impacting. Sure the media center can be hacked, but you need access to it, or software exploit(s). You think they will take this serious enough?

• Part of the reason why "responsible" disclosure of this vulnerability was an easy choice is that NVIDIA has already designed a new revision of the SoC used in the switch (the T214/Mariko); and I have strong technical reason to believe that its bootloader will _not_ vulnerable to Fusée Gelée, and that Nintendo will be releasing a Switch revision based on the new console "soon". Accordingly, I didn't see much advantage in hiding it, and I did see a potential danger in releasing it to the public without disclosing first.

Personally I assumed that Failoverflow used the same bug and tipped them off long ago?

• In response to suggestion that the danger regarding the vulnerability is overstated: people _always_ categorically misestimate the danger associated with these vulnerabilities; and sometimes it's hard to tell in which direction. I can say that the vulnerability affects the Tegra family, and not just the Tegra X1; and I less think this is likely to be used to crash cars than to violate people's privacy-- I don't like the possibility that someone could easily install a tracking rootkit on the affected devices. I honestly don't know if it's likely, but given the previous point I think it'a worth a short delay so I don't have to worry about that. I'm not a super-moral savior or anything; I just don't want to lose sleep wondering if I've hurt anyone.

See above, would really interest me to get a response. I mean specifially the end-user devices will not get a recall or update. If anything, being nice and quite about it is giving nvidia just more time to be layed-back about implementing the change and selling off their stock, no?

• The "lower is better" mantra has been a result of us having more options at our disposal in lower firmwares; and not wanting to declare a firmware 'safe' until we know we have a full working exploit chain on that firmware. I haven't participated much in the "stay on 3.0.0" style suggestions, as I honestly believe there are trade-offs to these things, and for a lot of people playing the most recent games is the thing that makes the system worth it. My view is that I want to get you as much information as I can and let you make those decisions-- and I promise you'll have all the information I can give you before too much of the (Northern Hemisphere) summer goes by.

While I get the point, it's made a bit mute by the fact that you and SciresM claimed the software exploit will work on 4.1.0. See that's the issue. Either it works on 3.0.0+ or it doesn't. If it does, then by now I think it would be helpful to tell people to update to their FW of choice (below XYZ). If it requires running the exploit potentially X times until it works, just say that. If it requires some game, then saying "requires some game for now" that's fine, no?

• As an addendum to the point above, if you really want to upgrade, I think that's up to you and sometimes an entirely valid decision. You're not going to lose out on CFW if you have a current-revision Switch; and honestly sometimes it's worth risking some inconveniences to have access to online play and the latest games. I know sometimes people take a really "upgrading is a sin" mentality, but I definitely can see cases where it's entirely valid. I think some of us really just don't want anyone to feel like they've missed out on something due to an upgrade.

The issue is that "inconveniences" are not measurable by itself. It could be a lot or a little. Anything that would put it on a scale of hardness would help. Is it Sophie's choice or passing on an offer from Microsoft as developer?

What are you missing by updating on the hacking site? I don't understand. Isn't the fuse check the only thing that will keep you from running any software? And if you can run any software, what's the difference? This is an example of a choice of words which make me and others question if we misunderstood something.
Personally, I would get being obsessive compulsive not to burn fuses ... But that's a different deal

• The name "Fusée Gelée" is a reference to the fact that it's a coldboot launcher meant to launch payloads "over the Horizon"-- with Horizon being the name of the Switch's OS. I called it Rocket for a little while, but Rocket was taken by the Rocket Launcher for 3DS; this is the downside of Nintendo keeping the same OS name: the puns get stale. If you'd prefer to call it "coldboothax", you're welcome to it. =P

And the technical:

• No, you're not going to need to disassemble your switch every time you want to boot it. I consider the 'inconvenient' process something I'd be willing to do on the main Switch the spouse and I use for games; and I definitely don't have the patience to take out all those tiny screws every time I want to boot.

Just as a helpfully meant suggestion: Instead of expressing what does not need to be done, it would be helpful to express what needs to be done (to the level of detail you feel comfortable with).

It"s clear that you will only really need to be "modded" (for the hardware route) during flash. So saying that, is helpful as clarification

That also makes clear what the different hardmod options truly are:
- "Hardware assisted" is simply a non permanent hardmod. Correct? You can short something (and that will allow you to reach recovery and flash?)
- You can (of course) also make it permanent (and reach recovery as needed?)

Once that is more clearly separated we know that software up to 4.1.0 means truly just software, thus people can make a choice to update even if they don't want to open their device.

• I don't want to comment on tethered-vs-untethered, if just because I don't want to narrow down where the vulnerability could be. It also tends to be the case that every time I ask what exactly people consider a 'tethered' vulnerability, an argument breaks out. I don't care about the hype; feel free assume the worst case for purposes of deciding how excited you'll be. The one exception I'll say to this is that you can consider any solution involving a modchip to be fully standalone.

I think what people care about is not if the exploit is tethered, but if they will have a persistent coldboot solution. I doubt such a solution would need to be tethered after the initial flash ... Most people, even me, don't care how the initial boot code gets where it is supposed to be going (onto the NAND). Just that it gets there and stays persistently until a reflash is needed.

To say it differently: Can I power on my flashed OFF device in the subway without the need of a laptop?

• The vulnerability is entirely deterministic: there's no "trying repeatedly until it works". The bootrom doesn't have fancy things like ASLR... or like a working MMU.

Expected

• The main benefit of being on 4.1.0 is that we have more exploit chains than f-g that work for it. We can simulate a coldboot on up to 4.1 without actually having a coldboot vulnerability; we haven't spent time being able to do that on 5.x yet. I've mentioned that f-g isn't a "holy grail" exploit-- it's not something where you can press one easy button and then have your Switch boot into untrusted code forever-- but that it's still possible that we'll find one that you can accomplish using Pegaswitch on one of the firmwares we still have access to.

Arrggg? Are you talking about triggering the exploit or about running the resulting bootcode (Package1?) afterwards? Because, really most here do not care too much about the exploits inner workings on triggering something. Don't get me wrong, I certainly would listen for hours on an aesthetic level, and maybe even to learn something, but the majority of your audience want to know their daily interactions.

So not persistent? It will not flash untrusted early bootcode (P1) to the device?

• You won't notice a difference between >3.0.0 and latest in terms of convenience at time of release. The exploit that enables us to have that level of access without f-g on those versions is one that SciresM/motezazer/I came up with, and we've agreed to hold off on releasing it yet in the hopes that it gives us more options on the coming hardware revisions.

This contradicts the FAQ and earlier expressed inconvenience, no? It also implies that F-G is NOT working on 4.1.0 ...?
This is a good example of the curve balls in the FAQ as well. When you read A and then here B you end up not knowing what things meant. I hope by expressing my thoughts above on what I think it means you can correct my errors and in turn we get a cleared up public picture of the SotA

I think it would be super important to more clearly differentiate between software and hardware, exploit execution ("flash" process) and the end result, and overall the use of different names of things which are different. Bootromhax, exploits to get there, etc.

Very kind regards

PS: I still would prefer to see the exploit release asap. Not just for the FW launch. I think you are missing out on developers and community creation if you deliver too much of a product. There are quite a few sub-projects in the FW that could be tackled in a nice open github based community including new people. Esp. on the higher layers.

 

[SH3RLOCK]

@ktemkin, first thank you and @SciresM for being the most communicating team of switch hackers.

So did I understand right, that there won't be a software-only exploit for >3.0.0 (at release of F-G/Atmosphère)? In this case I probably need to buy some hardware (Screwdrivers).
As a software developer I'm also interested in the Homebrew scene, I think I can't start developing before F-G (V4.1)? Or will a userland-only exploit be released before F-G/Summer?

I understand if you don't have the time to answer my questions (or don't want to answer them), just thought I'd try, since I hate random speculation.

 

[Quantumcat]

Just as a helpfully meant suggestion: Instead of expressing what does not need to be done, it would be helpful to express what needs to be done (to the level of detail you feel comfortable with).

This is exactly what I was thinking, but didn't want to get into it anymore. Saying what isn't needed is just talking to hear the sound of one's own voice and not supplying any real information at all.