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.

 

[KiiWii]

Thermosphere tweet sounds cool.

 

[Kioku]

Thermosphere tweet sounds cool.

Sounds awesome!

 

[Onibi]

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.

The FAQ is super intentionally vague (for no reason). It really must be clarified what the benefit would be ... if there is a claimed one. Either you get a cold boot or you don't. If you got one, then you have full access. What else could possibly be different? Number of fuses burned? Minor bootrom asm patch? Nothing else, no?

Also it should be more clearly differentiated between hard and soft mod.

 

[NeoSlyde]

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.

In the faq he states that if you want a permanent thing you will need to do a little hardmod

 

[Maximilious]

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...

True, and it could very well be coldboot for 3.0.1+ after running some other stuff on the console first. There's just still some unknowns about it that we have to wait and find out.

The FAQ is super intentionally vague (for no reason). It really must be clarified what the benefit would be ... if there is a claimed one. Either you get a cold boot or you don't. If you got one, then you have full access. What else could possibly be different? Number of fuses burned? Minor bootrom asm patch? Nothing else, no?

It is likely vague due to the nature of the exploit. Given it affects all X1 chips not specific to the switch she must have had to pick her words carefully. We should be very thankful for her blog post being up at all!

 

[Rune]

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 ...

If the software exploit was as effective as you're suggesting, surely Nintendo could then also patch that up via a firmware update. If Nintendo can't fix it, you have to assume hackers dont have any more power than Nintendo do.

 

[NeoSlyde]

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.

 

[Kioku]

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.

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.

I'm assuming this, right? That's just to make the assisted hardmod "permanent". It's a vaque FAQ, with awkwardly placed words.

 

[Onibi]

True, and it could very well be coldboot for 3.0.1+ after running some other stuff on the console first. There's just still some unknowns about it that we have to wait and find out.



It is likely vague due to the nature of the exploit. Given it affects all X1 chips not specific to the switch she must have had to pick her words carefully. We should be very thankful for her blog post being up at all!

That's not true. The differentiation is made on a Nintendo firmware basis. Meaning it is just a Nintendo based difference. This also makes it unlikely that there even is such a difference, considering that the bootrom can barely be affected.

I am telling you, in the end I very much doubt there is an effektive difference regardless of the FW below 5.X. And it should be clearified in the FAQ because it is not helpful to keep people from playing / updating unnecessarily.

 

[leonmagnus99]

so what's going to be the difference with 3.0 and below fws?
are those fws the ones that are going to be easier to install the cfw on and make it a coldboot permanently?

 

[Onibi]

If the software exploit was as effective as you're suggesting, surely Nintendo could then also patch that up via a firmware update. If Nintendo can't fix it, you have to assume hacker dont have any more power than Nintendo do.

Yes they would if they had all the exploits that you need on each FW to do it.

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

I'm assuming this, right? That's just to make the assisted hardmod "permanent". It's a vaque FAQ, with awkwardly placed words.

The "hardware assisted" mod is IMO just a bad way of saying "non permanent hardmod". There is likely no difference between the two other then the fact that the permanent hardmod is ... well ... permanent.

It's likely the same trigger to do a recovery flash.

 

[Rune]

Yes they would if they had all the exploits that you need on each FW to do it.

But then you go back to my first question. If hackers can flash the device to provide us with CFWs and whatever, why can't Nintendo put out a firmware that fixes this issue?
How can we have greater access to the device via software than Nintendo do? I can understand how a hardmod would do it. Maybe the hardmod merely physically alters the device that turns the "read-only" bootrom into one that also grants us access to write also. But from a pure software POV, if we can change the bootrom and exploit the error within it, then surely Nintendo can access this same error and fix it.

 

[BL4Z3D247]

But then you go back to my first question. If hackers can flash the device to provide us with CFWs and whatever, why can't Nintendo put out a firmware that fixes this issue?
How can we have greater access to the device via software than Nintendo do? I can understand how a hardmod would do it. Maybe the hardmod merely physically alters the device that turns the "read-only" bootrom into one that also grants us access to write also. But from a pure software POV, if we can change the bootrom and exploit the error within it, then surely Nintendo can access this same error and fix it.

Because we have the console physically and the only way this can be patched is by applying "ipatches" that can only be done by Nintendo in the factory. There is no software to fix that, the hackers are creating software(or a "package") that will take advantage of the vulnerability in the bootrom and gain control of the full system.

 

[Kioku]

Yes they would if they had all the exploits that you need on each FW to do it.

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



The "hardware assisted" mod is IMO just a bad way of saying "non permanent hardmod". There is likely no difference between the two other then the fact that the permanent hardmod is ... well ... permanent.

It's likely the same trigger to do a recovery flash.

Its a weird way to name it, for sure.

 

[Salazar-DE]

I will stick to the non-coldboot version rather than the hardmod. I like the temporary solution because if i turn off the console it will stay to an original, unmodified state. (FW: 4.1.0)

That's what I'm doing, too, except on firmware 5.1. I like the idea of the CFW going away on a hard reboot so I can easily switch to the legitimate CFW for online play (splatoon 2!). All the benefits of CFW without the drawbacks of possibly being banned.

 

[notimp]

Temkin talked about being exited about a "hardware assisted" mod, which wouldnt necessarily be a modchip, and easy to implement.

A possible interpretation of that also was given in here, talking about, that it could be possible to set the Switch into state that it boots into a "recovery mode" after coldboot, where a triggerable exploit could lay.

Meaning, hardmod or not might not be the difference between "detectable or not". If the switch between firmwares can be done at that stage, it might not be detectable by online checks. If you are running a stock image of a stock firmware.

The argument Temkin made about "being more excited about the hardware assisted version" could be (total hypothetical) read as follows: With a slight hardware modification, we could be able to load different firmwares - while the "normal" Switch firmware could be updated to the most recent version - and would always boot from nand, so Nintendo may not be able to detect a difference.

(If f.e. they cant access logs that show how often "recovery mode" was triggered.)

Also a possible interpretation.

 

[Loke]

Don't get me wrong guys, I think the hacking community is doing an awesome job with the communication towards this community. I really apreciate this FAQ and the way ScireM and the Reswitched team are talking to the community.

I would just like to stress to be careful with factual statements as we still don't know the actual guidelines for the exploit and what is required per firmware. I see people make rather vast statements about this vague FAQ, which can mislead some users.

 

[aos10]

just got back from the hardware store, they did have a set of tools that have 2.0 Y screwdriver, why they didn't tell me?

anyway, just returned the old one and bought the new set, and also got an opening tool (maybe i will need it when i decide to open my PS Vita).

 

[Kioku]

Don't get me wrong guys, I think the hacking community is doing an awesome job with the communication towards this community. I really apreciate this FAQ and the way ScireM and the Reswitched team are talking to the community.

I would just like to stress to be careful with factual statements as we still don't know the actual guidelines for the exploit and what is required per firmware. I see people make rather vast statements about this vague FAQ, which can mislead some users.

The FAQ lays out some useful info. It's vague about the technical details, but the misinformation being spread is from people not thoroughly reading the faq.. Or just not reading it at all. If what I'm gathering is wrong then Kate has a wicked sense of humor.

 

[normal19]

The hardware assit reminds me of putting tweezers to two points on the DS Lite to flash new firmware. Forgot what that was for though lol.