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.

 

[notimp]

The FAQ is completely nondescriptive and even less commital.

("I think most people will be excited about..." "Especially useful for more recent..." "I see no reason to upgrade" "3.0.0 has a great exploit, that allows many things..")

Everyone who is trying to present themselves as the bearer of specifics is oraceling around in non-specifics.

(I for my part tend to go with the obvious reversals of previous statements ("most excited about hardware assisted mod"), because I believe them to be the most noteworthy.)

The only constructive, laid out piece of information in there is, that people shouldn't show "fear of missing out", because every current switch will get some sort of cfw solution in its lifetime.

This was recognized by people by page two of this thread.

Terms like "temporary-hardmods" or concepts like - "i will stay on x.xx so i can play online, and will not need a hardmod, which I will get banned for" are not backed by any available information.

People now arguing over moral superiority over which oracle statements are moral superior to others is "interesting", especially when they participated in posting theories before.

Posting theories is not something that anyone should have to be refrained from because "some people could be mislead".

That would be self censorship. If you are against people trying to make sense of the information released - release more congruent information.

(Especially coming from a scene, that ran with "lower is better" for six months, for no apparent reason. I didn't say anything back then... Not sure it helped.)

 

[normal19]

I thought "lower is better" is just rule of thumb in any scene

 

[subcon959]

I thought "lower is better" is just rule of thumb in any scene

This isn't like any other scene though. It's been like something straight out of a Dan Brown novel.

 

[notimp]

Well, maybe - but if you keep it in contrast with only less than five percent of people in here sticking to 1.0.0 according to every poll in here - and the extreme urge to update to more current firmwares to be able to play "the new Mario" - statements like "i don't see any reason why you would upgrade from a lower firmware" seem somewhat misplaced.

Its not that it wasn't the correct advice at the time, it was, but the notion that there simply would not be any need to update doesn't seem to be shared by the public at large. (Even when they start on a lower firmware, they are heavily nudged to do so):

But let me not fall in the trap of arguing for updating devices you want to have hacked either.

Its more a public information mishap, where even in the face of more detailed information available, the "rule of thumb" was still predominantly shared, because it was easier to understand. If anything, its more that thing I'm speaking against.

Its harder to get "look at the available details" going as a rule of thumb..

 

[smf]

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.

And to get back CFW only takes the simple step of typing the complete works of shakespear correctly in under 24 hours.

I'm joking, the real method will be much harder. Like getting hold of a rare version of a game.

 

[Salazar-DE]

And to get back CFW only takes the simple step of typing the complete works of shakespear correctly in under 24 hours.

I'm joking, the real method will be much harder. Like getting hold of a rare version of a game.

I'm down for the Shakespeare.

That being said Kate did confirm that extra hardware isn't necessary. No games, no second switch, and no chips are necessary for the FG hack. So here's hoping the "inconvenience" is having to plug in the USB C cable to a computer and run a specific program while the Switch is booting.

 

[TheCyberQuake]

And to get back CFW only takes the simple step of typing the complete works of shakespear correctly in under 24 hours.

I'm joking, the real method will be much harder. Like getting hold of a rare version of a game.

That makes me think of the petite computer exploit back on the 3ds.

 

[smf]

That being said Kate did confirm that extra hardware isn't necessary. No games, no second switch, and no chips are necessary for the FG hack. So here's hoping the "inconvenience" is having to plug in the USB C cable to a computer and run a specific program while the Switch is booting.

If it is then her FAQ is utter drivel.

Q: What about suggestions that you only have a "tethered vulnerability" that's inherently weaker than TX's modchip?

Some people keep wanting to suggest that Fusée Gelée is hindered by a reliance on a host PC, or a 'tethered' exploit, and that solutions like TX's are the "true way" to avoid that. The idea that TX is the only one with a "truly portable" solution is really convenient for TX, but that theory's hindered a bit by the minor inconvenience of it not being true.

I think the inconvenience refers to "immediate fun", which is code for not supporting coldboot.

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

Someone was talking about taking the switch over by using a software exploit which sets stuff up in ram and puts the switch to sleep, then when you wake it up it will load cfw. I believe that fusee gelee supports that.....

 

[TheCyberQuake]

If it is then her FAQ is utter drivel.

Q: What about suggestions that you only have a "tethered vulnerability" that's inherently weaker than TX's modchip?

Some people keep wanting to suggest that Fusée Gelée is hindered by a reliance on a host PC, or a 'tethered' exploit, and that solutions like TX's are the "true way" to avoid that. The idea that TX is the only one with a "truly portable" solution is really convenient for TX, but that theory's hindered a bit by the minor inconvenience of it not being true.

I think the inconvenience refers to "immediate fun", which is code for not supporting coldboot.

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

Someone was talking about taking the switch over by using a software exploit which sets stuff up in ram and puts the switch to sleep, then when you wake it up it will load cfw. I believe that fusee gelee supports that.....

Hardmod (or at least one of the variations of hardmod) will very likely offer coldboot to any device no matter the firmware.

 

[Soluble]

Hardmod (or at least one of the variations of hardmod) will very likely offer coldboot to any device no matter the firmware.

I've read on every page at least 1 person saying over 4.1.0 won't get a Coldboot exploit... This exploit IS a Coldboot exploit. That's not speculation... People just can't seem to grasp that.

 

[Onibi]

I've read on every page at least 1 person saying over 4.1.0 won't get a Coldboot exploit... This exploit IS a Coldboot exploit. That's not speculation... People just can't seem to grasp that.

Well, the issue is that it was never quite stated how persistent the software entry is or what it actually is and how it works. It is at least conceivable (though unlikely) that the software mod is not persistent (but some kind of warm reboot deal).

The problem is that the FAQ and the information released are consistently and intentionally vague for no good reason, other then to defeat the purpose of a true FAQ, which is to keep people from asking you over and over. All this does it create more vague hype, which may very likely be the intention. More attention.

 

[Salazar-DE]

Well, the issue is that it was never quite stated how persistent the software entry is or what it actually is and how it works. It is at least conceivable (though unlikely) that the software mod is not persistent (but some kind of warm reboot deal).

The problem is that the FAQ and the information released are consistently and intentionally vague for no good reason, other then to defeat the purpose of a true FAQ, which is to keep people from asking you over and over. All this does it create more vague hype, which may very likely be the intention. More attention.

I'm pretty sure the FAQ is vague because she's trying to appease two audiences. She wants the community to feel like they're being listened to and answered, but she also wants to shed as little information as possible because she gave several companies an "early disclosure" of the bug and doesn't want to leak enough info for someone else to discover it.

 

[Onibi]

I'm pretty sure the FAQ is vague because she's trying to appease two audiences. She wants the community to feel like they're being listened to and answered, but she also wants to shed as little information as possible because she gave several companies an "early disclosure" of the bug and doesn't want to leak enough info for someone else to discover it.

The whole disclosure is another questionable issue that we discussed multiple times now (I think on page 3 or 4 the last time).

However, if you truly think this true, describing how persistent something is, does by no means leak vital information. Most of what people are annoyed by the FAQ is perfectly disclose-able.

Even stating that for example the HW mod will flash via the recovery is not something that nails down the issue to a degree that would be too helpful (and if you can read between the lines with technical knowledge it is somewhat implied).

Really, it may be the intention to not disclose too much, but it is a flawed overly restrictive logic. Then it would be better to say nothing. Same thing with the use of an umbrella term for multiple exploits, not helpful.

 

[Rune]

Well, the issue is that it was never quite stated how persistent the software entry is or what it actually is and how it works. It is at least conceivable (though unlikely) that the software mod is not persistent (but some kind of warm reboot deal).

The problem is that the FAQ and the information released are consistently and intentionally vague for no good reason, other then to defeat the purpose of a true FAQ, which is to keep people from asking you over and over. All this does it create more vague hype, which may very likely be the intention. More attention.

Exactly what I'm thinking. I'll be pleasantly surprised if we get a persistent software exploit without a hardmod, but I'm not getting my hopes up. I have two Switch consoles right now. One on the latest OFW and another on 3.0. So I'm thinking I'll have all options open to me. Having to do a hardmod is not something I'm looking forward to, but have accepted it might be my best solution for the sake of convenience. Using Pegaswitch right now can be such a pain as early homebrew tend to crash the device, forcing a cold boot, and then having to execute the Pegaswitch exploit all over again.

All these claims are thrown around like "its a coldboot exploit", "it's a hard mod", "it's inconvenient", etc, yet we don't know which OFW exploit these claims refer to. I think its pretty much a given that 1.0 users, 3.0, 4.1.0, and 5.0+ are probably all going to have different methods from each other. Which ones require a hardmod? Which ones are going to have the inconvenient methods? No one really knows. We can only speculate, so no one is right or wrong, or should be spreading anything around as fact at this stage.
The FAQ from Kate does state that its a cold boot exploit. But are ALL of them cold boot exploits? Maybe its only persistent from a cold boot when you do a hardmod. Maybe without a hardmod, you have to go through one of these alluded "inconvenient" methods.

 

[Risingdawn]

I'm not sure how a bootrom exploit could be anything but a cold boot solution, seeing as the bootrom is only used...on 'boot'.

 

[Rune]

I'm not sure how a bootrom exploit could be anything but a cold boot solution, seeing as the bootrom is only used...on 'boot'.

That's what I thought, but then asked myself:
1. If its a cold boot exploit, where does the inconvenience come in for people who don't use a hard mod?
2. And besides that, when they say its a cold boot exploit, are they saying its a boot exploit for everyone? Or does that only apply to those on a specific OFW or hard mod users?

 

[Onibi]

That's what I thought, but then asked myself:
1. If its a cold boot exploit, where does the inconvenience come in for people who don't use a hard mod?
2. And besides that, when they say its a cold boot exploit, are they saying its a boot exploit for everyone? Or does that only apply to those on a specific OFW or hard mod users?

To be honest (as previously stated) I think hes right. Bootrom is bootrom. However, with all the weasel wording in the FAQ I get and agree with your issues and thoughts. As I said, I have the same issue with "inconvenience" and treating FW different in the FAQ. IMO it's likely BS because it's expressed badly but ... meh.

IMO the software mod will do (2) below and thus allow recovery flashing. Why this would be "less convenient" on 4.1.0 no idea - should be specified ... Probably just the implementation of the bug for them is harder (who cares?) or maybe you need something specific to pull it off (be on april the 1)

Error Handling and Recovery Mode
Errors may occur during the boot process, such as a missing BCT, BCT hash validation failure, bootloader hash validation failure, etc. In this case, the boot ROM enters recovery mode (RCM).

Other situations may also cause entry into recovery mode:

• A recovery mode strap exists. If this is asserted, recovery mode will be entered unconditionally. This would usually be asserted by the user pressing a button, or some system management controller asserting the strap.
  
  
• If Tegra PMC register scratch0 bit 2 is set at power-up, recovery mode will be entered. This register bit is not cleared when Tegra resets, so any software may set this bit, then reboot, to request recovery mode.

 

[Soluble]

Whether or not it requires a soft or a hard mod, it's still a Coldboot exploit that's unpatchable for all firmwares. I don't mind the speculation of hard or soft mod, just people commenting that it isn't a Coldboot exploit over 3.0. or over 4.1 etc. People take comments as fact. Kate has certainly indicated that to make it permanent on higher firmware the equivalent of ''snipping" may be required. What that looks like we don't know.

 

[Onibi]

Kate has certainly indicated that to make it permanent on higher firmware the equivalent of ''snipping" may be required. What that looks like we don't know.

And exactly that for example makes no sense ...

You could argue that due to KASLR is may be harder to pull of. Or currently not possible. But not stating it exactly as such makes it difficult to accept such a "statement" without considering that something else must be "off". Why would you need to do anything different? The bootrom is the same for all FW. What does "inconvenience and hardware assisted" mean? Either you can do it in software or not. Either you hardware mod or not. If it's permanent for example is secondary (and most would not care to make it permanent if it's avoidable since they will only need to reflash in this manner if something bricks). Just be clear for shits sake.

Simply put, there is so much weasel in the FAQ that stuff is just not clear.

 

[Sephirosu]

I thought "lower is better" is just rule of thumb in any scene

In a way it is thou I'm still waiting for the supposed "2.0 support"... It seems you're either on 1.0 or 3.0 if you want support until cfw with bootrom hack comes out...