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.

 

[charlieb]

Since we're all playing the "guess game", here's what I think is going to happen. I have a very basic understanding of this stuff so feel free to correct and educate me on this.

Fusee Gelee apparently takes advantage of an error in the read-only bootrom. I imagine the fact that it's "read-only" is the reason why Nintendo can't alter or patch it with a firmware update. That would suggest to me that no hacker could change it either, which then leads me to believe that we probably won't be getting a CFW that simply loads up on boot since the bootrom itself won't change.
What probably needs to happen is we need to use an entry point in the Switch OS that will probably reboot the device and execute the bootrom exploit. OFW versions 1.0 to 3.0 have Pegaswitch so I'd bet they won't need to use a hard mod since they already run homebrew. Those versions will probably get some kind of installer/launcher homebrew that then reboots the device and fires up the CFW. I imagine this is one of the inconveniences they talk about, as it would mean using Pegaswitch everytime you want to run the CFW.
OFW versions higher than 3.0 dont have an public entry point so I'm guessing these are the ones that will require a hardmod. The hardmod will of course require physical work but probably bypasses the process of loading the Switch OS, use Pegaswitch, reboot, and then load up the CFW. This of course is more convenient in the long run but needs a hardmod.
I'd bet the hardmod option is available to everyone regardless of firmware version (including 3.0 and lower), but those higher than 3.0 will have no choice but to use it (unless a new entry point is revealed), where as Pegaswitch users will have a risk free but inconvenient option.

Of course all of that is probably just me talking out of my backside since I don't really have a real understanding of it. But that's my guess on what options we'll have.

I'm hoping 1.0.0 doesn't even need Pegaswitch and there can be installed a news type channel that does it all.

 

[Taffy]

I only have one thing to say.

HELL YEAH!

 

[Onibi]

Since we're all playing the "guess game", here's what I think is going to happen. I have a very basic understanding of this stuff so feel free to correct and educate me on this.

Fusee Gelee apparently takes advantage of an error in the read-only bootrom. I imagine the fact that it's "read-only" is the reason why Nintendo can't alter or patch it with a firmware update. That would suggest to me that no hacker could change it either, which then leads me to believe that we probably won't be getting a CFW that simply loads up on boot since the bootrom itself won't change.
What probably needs to happen is we need to use an entry point in the Switch OS that will probably reboot the device and execute the bootrom exploit. OFW versions 1.0 to 3.0 have Pegaswitch so I'd bet they won't need to use a hard mod since they already run homebrew. Those versions will probably get some kind of installer/launcher homebrew that then reboots the device and fires up the CFW. I imagine this is one of the inconveniences they talk about, as it would mean using Pegaswitch everytime you want to run the CFW.
OFW versions higher than 3.0 dont have an public entry point so I'm guessing these are the ones that will require a hardmod. The hardmod will of course require physical work but probably bypasses the process of loading the Switch OS, use Pegaswitch, reboot, and then load up the CFW. This of course is more convenient in the long run but needs a hardmod.
I'd bet the hardmod option is available to everyone regardless of firmware version (including 3.0 and lower), but those higher than 3.0 will have no choice but to use it (unless a new entry point is revealed), where as Pegaswitch users will have a risk free but inconvenient option.

Of course all of that is probably just me talking out of my backside since I don't really have a real understanding of it. But that's my guess on what options we'll have.

You assume that the SW exploit is not able to flash the device thou. I think that's probably a misconception.

IMO the hardmod will allow you to flash the whole thing via the recovery. Nice and easy.

However, I bet that the software mod will replace the second bootrom stage on your NAND as well, making it likewise a coldboot-able solution.

The only difference is the entry point and thus the ability to do SW on a certain FW (currently all below 5.X), while HW is naturally working for all.

As you described above, the reboot solution: That would have been the way that the Trustzone exploit works.

I remain confident that the SW exploit will install a coldboot solution.

In all honesty thou, that is clearly missing from the FAQ for no good reason ...

 

[NeoSlyde]

...?
You are the troll?
I ask you to provide actual proof for these "factual claims" you make. In fact, most of you guys act like you suddenly have the knowledge, but this FAQ is rather vague.

Another shit in my blocked members list

 

[Kioku]

Another shit in my blocked members list

Why so salty, tho? He's right, the FAQ doesn't explicitly state that a hardmod (of any kind) is required for coldboot. Just that it is an option.

Spoiler

Q: Will a hardmod be required to use Fusée Gelée?

I do have a "hardmod"-assisted variant, where the hardmod is approximately equivalent to shorting a couple of pins with tweezers. No soldering or dangerousness required, and there's a very minor thing you can do (think the equivalent of snipping a pin) to make the assistance permanent.

There's also a neat twist on things that allows you to do the above with no permanent modifications to your Switch.

There's a "variant" but nothing explicitly stating a hardmod is required. Not quite yet. The FAQ is pretty vague for what it is.

Spoiler

Q: So, is there a variant that you can apply without disassembling the device? Or a hardmod-less variant?

The answer to both questions is "yes"; though I'm not going to be more specific until after the disclosure window ends.

I will say that pure-software implementations of Fusée Gelée exist, but they're some of the ones I'm least excited about, especially on higher firmwares.

There's also this that contradicts your statements.

 

[bytar]

i see conflicting talkings about it but can anyone who understand the faq well tell me what is the benefit of being on 4.1.0?

 

[thekarter104]

Why so salty, tho? He's right, the FAQ doesn't explicitly state that a hardmod (of any kind) is required for coldboot. Just that it is an option.

It also made me confusing at first if we really need a screwdriver, but I'm glad that's for those who want hardmod.

 

[Kioku]

It also made me confusing at first if we really need a screwdriver, but I'm glad that's for those who want hardmod.

I've edited my post with some points from the FAQ that seem to point out that a hardmod is NOT required.

--------------------- MERGED ---------------------------

i see conflicting talkings about it but can anyone who understand the faq well tell me what is the benefit of being on 4.1.0?

Apparently there's a slight "inconvenience" of going above 4.1... Actually 4.1 was considered the last "safe" homebrew capable firmware until a release for F-G was announced. So, we'll see.

 

[Maximilious]

...
Don’t feed this troll please

I'm going to need some proof too. The post reads as if coldboot is availalbe to firmware 3.0.0 and lower, while 3.0.1+ will require hardmod (for coldboot only). 3DS doesn't require hardmod for coldboot, so not all HW requires a hardmod for it to be accomplished.

 

[Kioku]

I'm going to need some proof too. The post reads as if coldboot is availalbe to firmware 3.0.0 and lower, while 3.0.1+ will require hardmod (for coldboot only). 3DS doesn't require hardmod for coldboot, so not all HW requires a hardmod for it to be accomplished.

Nothing points to any firmware REQUIRING a hardmod for the coldboot.

 

[bytar]

I've edited my post with some points from the FAQ that seem to point out that a hardmod is NOT required.

--------------------- MERGED ---------------------------



Apparently there's a slight "inconvenience" of going above 4.1... Actually 4.1 was considered the last "safe" homebrew capable firmware until a release for F-G was announced. So, we'll see.

as far as i know the inconvenience thing came from sciresm. kate didn't mention about it, did she?

 

[Quantumcat]

i see conflicting talkings about it but can anyone who understand the faq well tell me what is the benefit of being on 4.1.0?

We don't know, only that it will be "more convenient" than 5.x, whatever that means.

 

[Taffy]

Frozen Rocket

 

[Quantumcat]

as far as i know the inconvenience thing came from sciresm. kate didn't mention about it, did she?

Kate said it:

Q: Do the different versions of Fusée Gelée provide different final feature-sets? That is, are there limitations on the capabilities granted when using software versions or on systems with higher firmware versions?

The versions differ mostly in the amount of work required to reach a state where you're running CFW ("they vary in how convenient they are"). Once CFW is booted, there won't be a difference in the final experience or what you can do from that CFW.

 

[Kioku]

Scratch that. Quantum got it.

 

[Maximilious]

Nothing points to any firmware REQUIRING a hardmod for the coldboot.

The reason I think coldboot is below 3.0.1 is due to these comments below from the article:

Q: I'm currently on a firmware between 3.0.1 and 4.0.0. Should I find a way to upgrade to 4.1.0?

I don't see any particular technical reason to upgrade your unit to 4.1.0 specifically. These versions are mostly equivalent from my perspective, and SciresM, Motezazer, and I have collaborated on ***non-coldboot hacks*** that still give us full system access on versions up to 4.1.0.

Q: Is it reasonable to upgrade from <console version here> to the latest?

This is always a question that depends on what matters to you. In general, I'd say a there are a few heuristics that help to make the decision:

• I'd never upgrade a 1.0.0 console-- these are a rare firmware version with software that's filled with delightful issues. If you have one and want a latest-firmware version now, I'd suggest selling it and buying a new console-- currently, this appears to be profitable.
• Versions below 3.0.1 but above 1.0.0 still have some pretty neat value to them-- ***they have a very powerful vulnerability that allows access to most of the system***. However, it's up to you if you want to hold on to these versions. I'd suggest it, but it's entirely possible that it is worth more to you be able to e.g. use your switch online right now than it is to have the possibility of using those software exploits in the future.
• Versions between 3.0.1 and 4.1.0 still have vulnerabilities that we've proven to work, but they ***don't give you the immediate fun that switches in the previous two categories do***. There's still a case for holding onto these until all details regarding Fusée Gelée are released, so you can understand what the advantages and disadvantages are of Fusée Gelée before upgrading.

 

[Kioku]

The reason I think coldboot is below 3.0.1 is due to these comments below from the article:
Q: I'm currently on a firmware between 3.0.1 and 4.0.0. Should I find a way to upgrade to 4.1.0?

I don't see any particular technical reason to upgrade your unit to 4.1.0 specifically. These versions are mostly equivalent from my perspective, and SciresM, Motezazer, and I have collaborated on ***non-coldboot hacks*** that still give us full system access on versions up to 4.1.0.

Q: Is it reasonable to upgrade from <console version here> to the latest?

This is always a question that depends on what matters to you. In general, I'd say a there are a few heuristics that help to make the decision:

• I'd never upgrade a 1.0.0 console-- these are a rare firmware version with software that's filled with delightful issues. If you have one and want a latest-firmware version now, I'd suggest selling it and buying a new console-- currently, this appears to be profitable.
• Versions below 3.0.1 but above 1.0.0 still have some pretty neat value to them-- ***they have a very powerful vulnerability that allows access to most of the system***. However, it's up to you if you want to hold on to these versions. I'd suggest it, but it's entirely possible that it is worth more to you be able to e.g. use your switch online right now than it is to have the possibility of using those software exploits in the future.
• Versions between 3.0.1 and 4.1.0 still have vulnerabilities that we've proven to work, but they ***don't give you the immediate fun that switches in the previous two categories do***. There's still a case for holding onto these until all details regarding Fusée Gelée are released, so you can understand what the advantages and disadvantages are of Fusée Gelée before upgrading.

FG is a coldboot exploit that will work on any firmware on current hardware revisions. Unless I've got some wires crossed and misunderstood somewhere? AFAIK, from Kate's FAQ and various quotes from SciresM? Coldboot is possible on any current (and future) firmware that isn't on the new SOC (?).

 

[Maximilious]

FG is a coldboot exploit that will work on any firmware

coldboot via softmod (3.0.0 and lower) or via hardmod (3.0.1+). She even states non-coldboot CFW for 3.0.1 in the snip I just posted. This is just my assumption, it's still too early for us to know since she can't publicly come out and give us a direct answer.

 

[Kioku]

coldboot via softmod (3.0.0 and lower) or via hardmod (3.0.1+). She even states non-coldboot CFW for 3.0.1 in the snip I just posted. This is just my assumption, it's still too early for us to know since she can't publicly come out and give us a direct answer.

You're right, she mentioned "non-coldboot".. Nothing pointed to any FW above 3.x not having a coldboot exploit. I'm also reading that going above 4.x will provide a "barrier" for installation. There's obviously different methods to acquire a coldboot, but this thread is about F-G which is (and I quote) a "coldboot "hack" software launcher for the Nintendo Switch". The big unknown currently is what being on a higher firmware means for the software installation. A hardmod is obvious, but she does mention a "pure software" implementation of FG...

 

[BL4Z3D247]

I've edited my post with some points from the FAQ that seem to point out that a hardmod is NOT required.

--------------------- MERGED ---------------------------



Apparently there's a slight "inconvenience" of going above 4.1... Actually 4.1 was considered the last "safe" homebrew capable firmware until a release for F-G was announced. So, we'll see.

I'll just drop this here to support this theory...

Worth mentioning that this is a genuine software bug-- no modifications to the Switch itself, despite the absent back cover. ^-^

https://mobile.twitter.com/ktemkin/status/964780944094736384