Fusée Gelée FAQ by Kate Temkin

subcon959 · Apr 20, 2018

andijames said:
Really? They can be if they're not fixed. They won't be fixed unless they know the vulnerability and patch it.. that's the whole circle! The disclosure period says they will RELEASE the vulnerability after a certain time. That's what they call a disclosure period. Once it's out in the wild I'd they were not patched then all current and future devices would be vulnerable.

You're welcome.

OK, I guess it was you that wasn't following what I was saying.

Everything you just said is bloody obvious and wasn't being argued against by anyone. The point is the PUBLIC disclosure delay doesn't do anything in this case to mitigate the issue. I'm really not sure why you don't get that. Once the initial disclosure to nVidia is made, they can do whatever they want to make sure future hardware doesn't contain the vuln but they CANNOT magically patch the existing userbase. The WHOLE point of the disclosure window is to allow companies time to deploy patches to EXISTING users. Therefore they are given adequate time to maximise distribution of said patch. That doesn't apply here at all. Releasing the vuln to the public on day 1 or day 90 makes NO DIFFERENCE in this case.

ktemkin · Apr 20, 2018

leonmagnus99 said:
oh yhea i have one question only @ktemkin
regarding the upcoming cfw , will a format of (NAND?) storage of the switch be needed?

No; I don't anticipate needing format of the internal NAND.

normal19 said:
If the switch is "completely compromised" and the efuses aren't revelant to cfw does this mean downgrades will be possible?

You can theoretically run lesser firmware using Atmosphère, but I'm not sure why you would. Atmosphère builds in a bypass to the security model, so I'm not sure what you'd gain by 'downgrading'.

saito1234 said:
Or should I search and get a Switch with FW 3.0 to be sure?

I don't think this is necessary-- at least not if you're willing to do the 'trivial hardmod' I've been talking about.

wolf_ said:
Anyone know if the softmods for 4.1 was patched for 5? Since Kate said they wanted to use it to poke around on the new switch it must not have been patched

Our EL3-hacks for 4.1 are composed of an exploit chain-- of which some of the components have been patched, but not all. I happen to think the un-patched pieces are valuable enough to hold on to, so we can hopefully build them into new exploit chains on the T214/Mariko devices.

annson24 said:
So shouldn't they be called softmod and not 'coldboot'?

Exploits like "jamais vu" and "déjà vu" aren't coldboot exploits-- the full chains are technically "warmboot" exploits, which means they do some setup and then e.g. wake the switch from sleep, or re-start the boot chain.

TheCyberQuake said:
Softmod means any mod that is fine purely through software, ie the installation method. Coldboot is a mod that can run on cold boot, ie a type of mod. F-G is coldboot, and can be installed with softmod abs hardmod

A coldboot vulnerability is one that runs from a complete power-off-- a software mod is something that changes the system using only software. A hardware mod modifies the hardware.

guily6669 said:
If on 3.02 I can keep using my tiny tweezers, I will probably keep doing it until TX release a chip or the software solution comes out for my 3.02, but I guess as soon as kate releases the schematics for the chip, everyone will start selling a full chip instead of we having to make it at home.

The hope is that open-source allows anyone to make a batch of modchips if you want to-- but I don't think you'll realistically be in a situation where you spend a long time tweezer-ing some test points.

guily6669 said:
But wont there be a tweezer mode temporary instead of the chip?

Again, the Tweezer aspect is not meant to be literal-- it's a head-nod to Team Twiizers, and intended to convey level of difficulty. There is a simple hardware tweak you can make to get things working.

BL4Z3D247 said:
She stated you'd only have to open the Switch once to do a hardmod, so I take that as either hardmod(tweezer/snip pin or modchip). I could be wrong but it sounded like a blanket statement to me.

Yeah-- I don't anticipate people opening their switches more than {zero times, once} to get things set up.

TotalInsanity4 said:
That's a great question, and one that I doubt she's going to answer until after F-G releases.?

Yeah, this is a question that I unfortunately can't answer without giving out some pretty big hints. The answers will have to wait until after the disclosure window, and the release.

Maximilious said:
Although Kate mentioned it only needs done once, she also mentioned having a hardmod (chip) can add some extra "fun", like possibly switching between NAND options at boot (Android, Horizon/Switch OS, or Ubuntu for example).

The modchip hardmod does add some value over e.g. the 'trivial hardmod', but unfortunately this is one of the things I can't be specific about, yet.

subcon959 said:
Funny isnt it, homebrew devs dont want to give much away cos its "not responsible" and TX dont want to give anything away incase it gets copied. Who are the only ones missing out cos of all this? The actual friggin users.

I mean, it's a fair point that you're not getting the information immediately-- but given the circumstance, I think getting you the information after a delay is the best I can do. As soon as the disclosure deadline passes, I plan on releasing technical documentation and sharing everything I know.

whyyes said:
So is this hardmod something Nintendo can theoretically attack in a future update? Like say, if it can tell you've done this permanent thing to your mainboard refuse to boot or boot games or something?

They won't be able to prevent you from launching Atmosphère-- but hiding the presence of CFW / the hardmod is kind of subtle. Side-channel analysis can almost always detect the presence of modifications; and then it becomes a cat-and-mouse game to try and keep things working. I really hope Nintendo doesn't go the path of trying to detect and block CFW, because it'll be a lot of work for everyone involved.

smf said:
What you need to take on board is that she is discussing multiple ways of doing things. So when she says things like you don't need a mod chip, you don't need to perform the mod every time, you don't need to be on a specific FW then she isn't talking about the same method each time.

This is fair and mostly true-- there are multiple ways of doing things, and the individual statements do sometimes apply to individual methods. I'm more trying to talk about general possibilities and capabilities than to pin down details of individual methods.

smf said:
A lot of her replies contain no context as a way of deliberately making you take what she says out of context.

I'm not trying to mislead anyone-- though in places there isn't much context to 'build in'. Feel free to ask clarifying questions as much as you want, and I'll try to get around to answering them -- even if the answer is "I'm can't answer this yet."

smf said:
So there is a method that requires a mod chip,
there is a method that requires you to perform the mod every time you turn the switch on,
there is a method that requires a specific firmware etc.

There are methods that meet each of the conditions above, yes. There are also other methods, like one that doesn't require you to "hardmod" every time you turn your switch on. Again, I promise I'm not trying to mislead; I just haven't enumerated every possibility.

smf said:
There are pros and cons with each method, you'll only have enough information to make the decision when she decides to be less vague.

Yep, this is true-- I've said this in the FAQ. I intend to give out more information as soon as I can.

smf said:
I don't know if it's possible to create hybrid methods. So use the tweezer mod the first time, install CFW, then you have total control and can do the software mod that makes it work from coldboot. She didn't mention that & her reply to me would have seemed like a good time to bring it up, it might be she hasn't considered it or maybe it's because she is deliberately being vague.

I mean, remember that shorting pins with tweezers was just something I said it was "as difficult as". Yes, theoretically you can hybridize, but as above there are pros and cons to each-- I hope to make sure people understand the actual mechanisms so that people can think of all the methods they want to-- and I'll definitely be open to questions.

smf said:
I'm not entirely sure what context you mean, because she is deliberately avoiding giving any context.

If you use the tweezer method then you do have to open it every time. You don't need to use the tweezer method, you can cut a pin or fit a modchip.

smf said:
Switching from using the tweezer to a softmod is no longer using the tweezer method & that is not something she has directly addressed. This might be because it's not possible, or it might be because she assumes someone who has taken their console apart will take the easy way out and just cut the pin. Rather than using the tweezer mod, booting up CFW and then running a software mod.

As above, you can switch to software hacks after doing the "one time" hardmod-- but the software tricks involved in doing this are kind of ugly.

smf said:
Personally I'm in the group of people who would rather wait for the >3.0.0 exploit to come out, or if they did open the switch then they wouldn't want to risk damaging the switch by cutting the wrong pin but might do the tweezer exploit once.

Fair-- though I think you might want wait for the details before deciding.

sarkwalvein said:
AFAIK "tweezer", "cut a pin", and perhaps even "modchip" /s are metaphors. Perhaps they even refer to disconnecting a cable, peeing on the console or putting it into the oven... I mean, you're taking it literal while she most of the time said "as easy as", or "something like", and even "just used the word as a homage to team twiizers".

Yep-- this exactly. I'm not trying to say these are things that will happen as much as give an estimate of level-of-difficulty.

Nah3DS said:
Is the hardmod solution permanent?
By permanent I mean, that I won't have to do the hardmod again every time I power-off the console.

Yep-- what I've been calling the "trivial hardmod" is.

TotalInsanity4 said:
By "context" I meant someone in the thread asked if we were going to have to take the back off the Switch every time for the tweezer method, because that would get tedious, and she responded saying that no, the temporary hardmod (which she keeps alluding to being the "tweezer" method) only needs to be done one time to install the exploit

I mean, there are a bunch of methods you can do that leave not traces on the Switch hardware-- including the permanent one. There _do_ exist "one-time" methods that you'd have to repeat every time; I just don't see people actually doing them once they learn the details, as I think there are better solutions.

salamandrusker said:
fuse & gelé is able to load legitimate content from sd instead of cartridge? Homebrew applications directly from sd or usb in the original menu without going through hbl?

Fusée Gelée is just an exploit that lets you launch CFW. You're asking about Atmosphère, our CFW.

Yes, Atmosphère will have a custom loader that should let you load homebrew from an SD card. A goal is to have a nice UI that lets you do this through the main menu.

salamandrusker said:
Will cfw be installed on nand doing an emunand? everything that happens in fuse & gele is invisible to nand real? those answers can be given without compromising the fuse gele information and have not been answered ... why? that is what gives a little distrust.

They haven't been answered here because they're Atmosphère questions, not f-g questions. There's a whole separate thread for Atmosphère Q+A.

In short, though: we'll be using a SD-card based emunand at first. Once we have things stable we'll probably switch to also supporting installation on sysNAND.

crazyxelite said:
Any chance of this coming in June?

June is part of the summer, so it's not ruled out.

Quantumcat said:
Something else I just thought of that points to it following the same path as other things announced ahead of time and being closed development - if it was all ready to go, and they were just waiting for the disclosure period to be over, there would be a definite date, like 1 August or something. A developer gives a vague future release date only when they haven't finished development and they are estimating when it will be done since they just don't know. But here, with it all being finished and delaying on purpose, they should know exactly when they plan to release it. Yet another fishy sign.

Quantumcat said:
Ok. So what date is that? None has been given. She even said the release of FG is not tied to Atmosphere: "my release date for f-g is tied to my disclosure timeline and not in particular to Atmosphère's release." So a project that is supposedly completed still has a vague release date.

I have an exact end-of-disclose-window date in my head-- one I've agreed on with NVIDIA. Given some of the feedback I have gotten, I really don't want to promise an exact date for f-g itself-- that seems like it'd lend itself more to "creating hype" than being useful. Talking about the date seems more to be one of the things that riles people up rather than helps to inform.

Quantumcat said:
She doesn't need to do that on her own - when she opens it to the public (not in a big release way but in a way that interested and informed people can access it), people will help (not to mention there's supposed to be a whole team behind it). And in any case, if it isn't ready for public consumption yet (for documentation reasons or anything else) why pretend that it is being held over just for the disclosure window? Why would the team not do things in the following order: 1. inform nvidia etc, 2. work on everything that needs to be worked on including documenting, then finally 3. announce info and say it is just waiting for the disclosure window to pass (in which they will know the date they are waiting for)?
Either it is being held over for development/documentation or it is being held over for the disclosure window. And I don't think the documentation is going to take so long that she doesn't know if it will be complete in June or in August. In development you can run into horrible problems that you just don't know how to solve and you never anticipated, so taking a month or two longer than expected would be common. But when you're writing, and you know what you're writing about, what unexpected problem can you have? Your notepad application gets a virus? Either it is because development is not finished or she just wants the heaps of extra attention that comes from people continually asking, once June is here, "is it released yet? Is it released yet?" that she can milk until she finally decides to release it late August. If it was just for the disclosure window there could be a date, since it is what the team decides, not something unexpected that they can't anticipate.

Quantumcat said:
My concern is that there's multiple pieces of evidence pointing to this turning out like Hykem. It is better to have healthy scepticism than take everything at face value and ignore anything that doesn't match. As I have said before I'll be very happy if it all turns out to be a coincidence and everything gets released when they say it will. Just reserving my "I told you so" rights by expressing what I have noticed and not keeping it to myself.

Quantumcat said:
No it does not, the disclosure period finishes at some random time in summer. If it is a period of time that has been decided upon by them, they would know a date, not some random time in a three month period. Like are they going to toss a d90 each day of summer to decide if it will be released that day? And Kate already said the release of FG is not at all tied to Atmosphere being completed.

Quantumcat said:
Yeah what salamandrusker said, she has not set a date. That means either she doesn't know it, or she knows it and is hiding it for some reason. She says development of it is finished, therefore it doesn't make sense that she can't know. So, either she is lying that development is finished, or, she is choosing to hide the information for some reason which we can only guess at.

I have good people helping with documentation, and we really should have documentation ready for the disclosure deadline. I've mentioned that the core development is finished, and this is true-- though there are always some niceties that can be added; the core exploit and infrastructure is 100% complete and working. Here's a hash for the code in it's current form that you can use to validate this in retrospect (3633140d9c97930f615a0491200a3c1c683666c0d430c5d4521e49158164f584), and here's a hash of my disclosure deadline (ab5f19f597c97dbb8ffe2267f8c5a3b4968b66a4710bf7128b915f13fba2a0f2, lightly salted).

Is there value in making a date explicit? I've provided a rough timeframe because I wanted people to be able to make decisions regarding firmware upgrades and whether or not to pre-order modchips. Providing a more concrete date than that just seems like it'd build hype around and leading up to that date; it doesn't seem like it'd really provide much value to the community.

I'll admit I'm confused by the repeated negativity. You've mentioned the background with Hykem, and I understand your skepticism and think that's natural and valid-- but this seems to extend beyond skepticism into what seems to me like more general negativity about me and my work. I am trying to respond to and address your points-- but that's difficult to do when I'm not sure where this is coming from.

horokeusama said:
Am I being naive to think they will release it before june?
I'm wishing to watch the World Cup while playing emulators and some backups of games i already have.

You're not going to see a release before June; sorry. I can at least say that the disclosure deadline is after June 1st.

andijames · Apr 20, 2018

subcon959 said:
OK, I guess it was you that wasn't following what I was saying.

Everything you just said is bloody obvious and wasn't being argued against by anyone. The point is the PUBLIC disclosure delay doesn't do anything in this case to mitigate the issue. I'm really not sure why you don't get that. Once the initial disclosure to nVidia is made, they can do whatever they want to make sure future hardware doesn't contain the vuln but they CANNOT magically patch the existing userbase. The WHOLE point of the disclosure window is to allow companies time to deploy patches to EXISTING users. Therefore they are given adequate time to maximise distribution of said patch. That doesn't apply here at all. Releasing the vuln to the public on day 1 or day 90 makes NO DIFFERENCE in this case.

Do you have facts to back up the point this can't be mitigated in other devices? I.e switch v5 needs a hardmod (at this point). Do other devices need this that exist? No one knows. Disclosure gives Nvidia time to notify clients who can mitigate against this if possible before going public.

If you made this a day 0 then what does that exactly achieve?

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

P.s. thanks @ktemkin for the clarification on the above points. You're a goodun as we say

appreciate your help in the scene .

subcon959 · Apr 20, 2018

andijames said:
Do you have facts to back up the point this can't be mitigated in other devices? I.e switch v5 needs a hardmod (at this point). Do other devices need this that exist? No one knows. Disclosure gives Nvidia time to notify clients who can mitigate against this if possible before going public.

The boot rom patches have to be burned at the factory so that's the only way to mitigate. Downstream vendors have no way to correct this so existing customers are looking at having to fork out for new hardware (if they care about the vuln in the first place).

normal19 · Apr 20, 2018

ktemkin said:
You can theoretically run lesser firmware using Atmosphère, but I'm not sure why you would. Atmosphère builds in a bypass to the security model, so I'm not sure what you'd gain by 'downgrading'.

I figured that since 1.0.0 is the most valuable firmware for exploits then it would be good to have in sysnand if we can get it back, but if you say there's no point in having it once the exploit is in then fine

andijames · Apr 20, 2018

subcon959 said:
The boot rom patches have to be burned at the factory so that's the only way to mitigate. Downstream vendors have no way to correct this so existing customers are looking at having to fork out for new hardware (if they care about the vuln in the first place).

That was the point. They can mitigate against the exploit if possible for current devices but the window gives them time for this. If you day zeroed this like you say then this would cause panic and no time to even try to mitigate. Why would you do this? You just regurgitated half of my fact. Back to yours. What benefit would a day zero on this bring? Given no one has a CFW imple implementation yet and the irresponsibility toward current devices?

Quantumcat · Apr 21, 2018

andijames said:
They can mitigate against the exploit if possible for current devices

They can't.

TheCyberQuake · Apr 21, 2018

Quantumcat said:
They can't.

But it gives them time to potentially work with downstream clients, specifically ones where things like private confidential data would be at risk, to potentially get hardware replaced. They won't do a recall for the normal consumers, but in the end this doesn't affect them all too much, it's more about the businesses that can potentially be completely screwed over by an exploit. On top of that it would allow them to mitigate any software-based attacks on the bootrom for those downstream clients making it at least much more difficult for a remote bootrom exploit.

andijames · Apr 21, 2018

Quantumcat said:
They can't.

They can. Search. I know it's an unknown skill round here but a ROM can be flashed when it's a ROM exploit.

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

If you're talking about other devices they can mitigate. Nintendo have. Now you need HW access which is much more unlikely for a car for example.

andijames · Apr 21, 2018

No whining? Wow. Someone must have used Google for once.

Look please let them be and let's have a little patience instead of bitching like teenagers

Quantumcat · Apr 21, 2018

andijames said:
They can. Search. I know it's an unknown skill round here but a ROM can be flashed when it's a ROM exploit.

Did you even read the FAQ? You missed this part:

The relevant vulnerability is the result of a 'coding mistake' in the read-only bootrom found in most Tegra devices. This bootrom can have minor patches made to it in the factory ('ipatches'), but cannot be patched once a device has left the factory

I guess reading is a bit of an unknown skill around here.

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

TheCyberQuake said:
But it gives them time to potentially work with downstream clients, specifically ones where things like private confidential data would be at risk, to potentially get hardware replaced. They won't do a recall for the normal consumers, but in the end this doesn't affect them all too much, it's more about the businesses that can potentially be completely screwed over by an exploit. On top of that it would allow them to mitigate any software-based attacks on the bootrom for those downstream clients making it at least much more difficult for a remote bootrom exploit.

Yeah I understand that, the user I quoted is under the impression existing devices can be fixed to no longer have the vulnerability. Replacing critical ones is a good idea. I haven't heard any news saying they're doing that, but at least they have the opportunity to.

guily6669 · Apr 21, 2018

Nice, thank you Kate Temkin.

@ktemkin could you also clarify if there's any hardware risk using the "trivial hard mode" of shorting 2 points on the board. I mean, if done right is there any chance it can damage any component\chip from the Switch hardware?

Adrian137 · Apr 21, 2018

If we are required to open the switch for the hardmod, do we need philips screw driver as well?

annson24 · Apr 21, 2018

Adrian137 said:
If we are required to open the switch for the hardmod, do we need philips screw driver as well?

yes.

wicksand420 · Apr 21, 2018

guily6669 said:
Nice, thank you Kate Temkin.

@ktemkin could you also clarify if there's any hardware risk using the "trivial hard mode" of shorting 2 points on the board. I mean, if done right is there any chance it can damage any component\chip from the Switch hardware?

I don't think she said you will actually have to short 2 pins, that just a example, but if it is indeed what has to be done, then shorting the wrong pins would possibly result in breaking your switch

andijames · Apr 21, 2018

Quantumcat said:
Did you even read the FAQ? You missed this part:

I guess reading is a bit of an unknown skill around here.

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

Yeah I understand that, the user I quoted is under the impression existing devices can be fixed to no longer have the vulnerability. Replacing critical ones is a good idea. I haven't heard any news saying they're doing that, but at least they have the opportunity to.

Thanks for quoting that. The first line is what I was getting at. It's a result of a coding mistake. Yes machines in the wild cannot be patched at ROM level but factory ones can. The ones in the wild can be MITIGATED against as you still need an exploit to get to the bootrom one.

Quantumcat · Apr 21, 2018

andijames said:
Thanks for quoting that. The first line is what I was getting at. It's a result of a coding mistake. Yes machines in the wild cannot be patched at ROM level but factory ones can. The ones in the wild can be MITIGATED against as you still need an exploit to get to the bootrom one.

You originally said that current devices can be fixed:

andijames said:
They can mitigate against the exploit if possible for current devices

I don't know what you mean by "MITIGATED against" because ones in the wild cannot be fixed once they have left the factory i.e. been shipped to a retailer and sold to consumers. No software patch is going to fix this, since it can be installed by hardware. The coding mistake is in the bootrom which is what cannot be changed after it leaves the factory.

andijames · Apr 21, 2018

Quantumcat said:
You originally said that current devices can be fixed:

I don't know what you mean by "MITIGATED against" because ones in the wild cannot be fixed once they have left the factory i.e. been shipped to a retailer and sold to consumers. No software patch is going to fix this, since it can be installed by hardware. The coding mistake is in the bootrom which is what cannot be changed after it leaves the factory.

Where did I say current devices can be fixed?

Yes you're right once devices are in the wild the ROM cannot be flashed / fixed by virtue of it being ROM. Mitigation is essentially like what Nintendo have been doing with KSLR and closing off other vulnerabilities that open the door to the bootrom exploit (you need exploits to actually get to the bootrom one right?) That's what other manufacturers can do for the devices currently out there. Harden against actually getting at the non fixable exploit

Quantumcat · Apr 21, 2018

andijames said:
Where did I say current devices can be fixed?

Here:

andijames said:
They can mitigate against the exploit if possible for current devices

andijames said:
you need exploits to actually get to the bootrom one right?

Can be installed with hardmod - stuff happens before the console boots up, so no patch to the OS is going to affect whether we can install it*

*I would say I am 95% sure, as long as there haven't been any real lies in the information we have been given - until it's released and we actually get to install it ourselves we can't know for certain

andijames · Apr 21, 2018

Quantumcat said:
Here:

Can be installed with hardmod - stuff happens before the console boots up, so no patch to the OS is going to affect whether we can install it*

*I would say I am 95% sure, as long as there haven't been any real lies in the information we have been given - until it's released and we actually get to install it ourselves we can't know for certain

Mitigate and fix are two different things. I explained that in my previous post so no need to go over old ground.

Hardmod can circumvent it by the sounds of it yes possibly but that's for the switch. How easy and realistic is that for other tegra bearing devices we simply do not know. For a car that might not be an issue as you can't GET to it unlike a switch.

The whole point of this conversation was about the disclosure window and why it's important. This is why. So other customers can decide how to handle it and actually investigate to see if it's a viable threat or issue to them.

@!#?@!

Member

Well-Known Member

@!#?@!

Well-Known Member

Well-Known Member

Dead and alive

Certified Geek

Well-Known Member

Well-Known Member

Dead and alive

GbaTemp is my Drug

Active Member

The Patient One

Well-Known Member

Well-Known Member

Dead and alive

Well-Known Member

Dead and alive

Well-Known Member

Similar threads

Popular threads in this forum