Hacking Question I accidentally updated to 5.0 while playing mario

[alepman90]

It could takes time, but from my understanding all the current Switch with this model of Tegra chip are exploitable no update could prevent it until the next Switch’s revision

 

[TheCyberQuake]

It could takes time, but from my understanding all the current Switch with this model of Tegra chip are exploitable no update could prevent it until the next Switch’s revision

With a hardmod its impossible to patch. But the free devs with software exploit have said the exploit is unpatchable, but have yet to comment on the prerequisites of installing that exploit, which may require some form of code execution which is patchable. So its unpatchable with hardmod, but potentially patchable for softmod. Frankly the fact that the devs won't give any info on what kind of privilege escalation or basic code exec, if any, is necessary to access the bootrom exploit installation is a bit worrying, especially when people are now updating expecting to eventually see a software bootrom exploit from any firmware, ie those who are updating to 5.0.0. I would love if there could be some kind of clarification by someone like @SciresM to explain this better.

 

[Kubas_inko]

I have. it bricks.

How does it look like?

 

[Onibi]

https://www.re

ddit.com/r/NintendoSwitch/comments/7m2eca/bricked_during_update/

There are ppl that have already bricked their switches turning them off during an update?

Perhaps I'm wrong I guess.. but afaik, firmware is right on top of hardware.. everything else gets virtual memory and their own virtual address space and can be reinstalled. For me, firmware is "Permanent software programmed into a read-only memory." Exactly how Google defines it. Even wiki has a nice definition too: https://en.wikipedia.org/wiki/Firmware

Seems to be in-lined with what I've learned.. but again, perhaps these definitions have changed. I dunno what they teach in school nowadays..

Hmm, I really don't want to speculate more about what the switch does. But I am not convinced that it uses a low-level approach to update, at all. Maybe at some point I am gonna take a look, or somebody else will. However, it being able to brick does not define how the update is applied, it simply means that Nintendo did not care to make it more safe. (To get back to the original topic, that means I was wrong - if people really bricked during update don't do it However the guy in the link you send seemed to have another update issue prior to shutting down - so maybe that was at fault.)

It's a bit hard to explain why to me the update mechanism is not actually that important: Basically, any update, be it windows or linux, be it bios, be it the switch does touch vital low-level parts at some point that could result in a broken state, if interrupted exactly at that point. However, if care is taken and preferred over simplicity it is always possible to identify and recover such a state automatically. This is the basis of database design (C in ACID) and distributed systems.

To provide an example for a lowlevel FW: If you have 512MB of NAND, and you write a FW of no more then 256MB, you can write them alternating to the upper and lower part of the NAND. That makes it possible to switch the entry-point in an atomic last write.

Towards "Firmware": If you use the textbook (OS) definition here, then the whole argument is out of place either way. Because in that case, the "firmware" part of the switch would only be a small part of the switch update anyway. The update also contains services, the kernel, and various user space programs. Non of them are the textbook definition of the "firmware". For example, the linux kernel has a firmware: https://wiki.ubuntu.com/Kernel/Firmware , yet when you get a router update you call the whole thing "firmware" as well even though it is likely much more then the low level hardware parts.

I would rather think of "Firmware" in the embedded sector as being used for any packed (likely self-contained non-incremental) update and would be reluctant to imply HOW it is applied. The reason why they are typically low level static images is that such a system does not require a complex update mechanism and is as such simpler to maintain in a consistent state. It also makes it trivial to re-flash (if that is allowed by the device).

You can see that there really is little difference between the two in mixed ISO/IMG installation disks (e.g. archlinux). You can treat it as an iso, you can dd it to a USB stick as image. It does not matter because the file is designed to work at both abstractions, low and high. Similarly, a switch update could be directly writable to NAND during hard flash, while during update, it could be unpacked and applied to the existing file system in a more high level process. It is likely not the case that switch updates work in such a dual way, but it could be.

With the kindest of regards

 

[jt_1258]

yes

no, just because there was an update the squashed the bugs we were using to fiddle with the system initially doesn't mean new ones will not be found.

 

[Reploid]

Hey, there is still team executor, that promised any fw and feature proofing.

 

[jt_1258]

Hey, there is still team executor, that promised any fw and feature proofing.

that's somewhat what I'm leaning on myself. I accidentally updated myself too. The a button got stuck down when I was opening bayo and it clicked the update button. Dam thing won't even let you power down the system to cancel an update like the wii did.

 

[punderino]

no, just because there was an update the squashed the bugs we were using to fiddle with the system initially doesn't mean new ones will not be found.

i was obviously joking but whatever. there probably wont be a cfw release for a long time, scires has said hes done working on exploits and is only focusing on developing his cfw for all fw versions up to 4.x. so mostly its a yes youre fucked but only for a year or so