Hacking Update?

[loler55]

Are you sure? http://switchbrew.org/index.php?title=Fuse_registers
The fuse register also contains bootrom patches and keys. Burnt into hardware after an update.
What if you try to boot an updated emunand with a wrong patch/key ? My guess is -> it won't boot.
Maybe there is a way to get Emunand to work, but it will be years until it's possible.

B9S is not possible, because B9S is not an exploit, it is an oversight from Nintendo in bootrom code and they won't make the same mistake again.



DS flashcarts don't need an entrypoint to work.
Sky3DS does NOT use an entrypoint, because it's a 1:1 clone of a real cart (google shows Cubic Ninja, but this is only needed for homebrew/CFW, not piracy).

• DSi console sends cart initialization sequence
• ARDSi cart determines it’s being ran on a DSi console and starts responding a fixed pattern on every read block request
• Game’s header, ARM9 and ARM7 binary are loaded by the DSi menu and checked for integrity
• Integrity checks pass since all data is 1:1 compared to the original ROM
• Game starts running, starts parsing filename and file allocation tables of filesystem on cartridge
• Game loads overlay 0x01 to 0x020BBF00
• Game does more stuff and eventually branches to code inside loaded overlay @ 0x020BBFE8
• The initial 0xE8 bytes of the datel payload are inifite loop opcodes. The entrypoint is right behind it and payload execution starts.
• Payload sends secret F005000000000000 (Not so secret anymore now, huh?) cart command to put cartridge in secondary mode
• Payload uses normal 0xB7 read commands to read the header, the ARM9 binary and the ARM7 binary.
• Some IPC magic is done to capture execution of the ARM7 cpu
• Finally a softreset SVC/SWI is issued to execute the newly loaded ARM9 code

Actually that's how DSi works. It literally has a giant-ass whitelist of older DS games. The way these carts get around it is to actually wholesale copy a DS game header which doesn't seem exactly legal.

It Smells like this is a Entrypoint..................

 

[Falo]

You know that DS and DSi are different consoles?
A DS flashcart does NOT need an exploit to work.

 

[loler55]

You know that DS and DSi are different consoles?
A DS flashcart does NOT need an exploit to work.

You Know that a flashcart itself a entry Point is?????
Lets Sleep that makes no fun
You are right about sk3ds and ds flashcarts Need no exploit

 

[subcon959]

Even if any of the previous speculation was possible, doing it without a ban seems like a big issue.

 

[loler55]

Even if any of the previous speculation was possible, doing it without a ban seems like a big issue.

Online play its not nessesary for me..
All Good Games like zelda or oddesey yoshi and starfox are Not Really Multiplayer games

 

[subcon959]

Online play its not nessesary for me..
All Good Games like zelda or oddesey yoshi and starfox are Not Really Multiplayer games

That doesn't really matter as I can't imagine any devs would release something that knowingly got people banned.

 

[Lacius]

Are you sure? http://switchbrew.org/index.php?title=Fuse_registers
The fuse register also contains bootrom patches and keys. Burnt into hardware after an update.
What if you try to boot an updated emunand with a wrong patch/key ? My guess is -> it won't boot.
Maybe there is a way to get Emunand to work, but it will be years until it's possible.

B9S is not possible, because B9S is not an exploit, it is an oversight from Nintendo in bootrom code and they won't make the same mistake again.



DS flashcarts don't need an entrypoint to work.
Sky3DS does NOT use an entrypoint, because it's a 1:1 clone of a real cart (google shows Cubic Ninja, but this is only needed for homebrew/CFW, not piracy).

This is all hypothetical, but it might be possible to a.) Prevent fuses from being burnt during the emuNAND-upgrade procedure, since the process would happen while using CFW, and b.) Prevent fuses from being burnt when loading a higher-version emuNAND, since the process would happen while using CFW. If this is possible, the number of fuses burnt can perpetually match the sysNAND version (e.g. three fuses for 3.0.0).

I know B9S is not possible, due to hardware differences, which is why I said a B9S-like exploit could be possible someday. Flaws like these cannot be ruled out.

Edit: With regard to Nintendo "not making that mistake again," that's a laugh. They're not going to make the Switch hack-proof, and B9S, for example, was revealed after the release of the Switch.

 

[Falo]

Yes i agree, it might be possible to prevent efuse burning, but what if you need efuse burning, to get emunand working?
The efuse is not just a value, it contains specific settings, keys and bootrom patches which are burnt into hardware after an update.

I'm not 100% sure, but maybe the nand firmware (and therefore the emunand too), might need an efuse key to successfully decrypt, so not burning a efuse might make an updated emunand un-bootable, because a console-unique key is missing.

B9S has nothing to do with hardware, it's a software bug.
B9S works, because we were able to calculate firm signatures, the bootrom didn't check the full 256 Byte signature.
There is a very good reason why the switch will never have such a bug: Bootrom is patchable via efuse programming.
So even if B9S came out after switch, Nintendo might have patched it already on 2.x.

 

[tech3475]

Yes i agree, it might be possible to prevent efuse burning, but what if you need efuse burning, to get emunand working?
The efuse is not just a value, it contains specific settings, keys and bootrom patches which are burnt into hardware after an update.

I'm not 100% sure, but maybe the nand firmware (and therefore the emunand too), might need an efuse key to successfully decrypt, so not burning a efuse might make an updated emunand un-bootable, because a console-unique key is missing.

B9S has nothing to do with hardware, it's a software bug.
B9S works, because we were able to calculate firm signatures, the bootrom didn't check the full 256 Byte signature.
There is a very good reason why the switch will never have such a bug: Bootrom is patchable via efuse programming.
So even if B9S came out after switch, Nintendo might have patched it already on 2.x.

Aren't the efuses only used as a counter after they leave the factory like with the 360?

If we get to the point that we can have emunand the issue will be patching the expected efuses or mimicking the expected value somehow.

 

[Lacius]

Yes i agree, it might be possible to prevent efuse burning, but what if you need efuse burning, to get emunand working?
The efuse is not just a value, it contains specific settings, keys and bootrom patches which are burnt into hardware after an update.

I'm not 100% sure, but maybe the nand firmware (and therefore the emunand too), might need an efuse key to successfully decrypt, so not burning a efuse might make an updated emunand un-bootable, because a console-unique key is missing.

B9S has nothing to do with hardware, it's a software bug.
B9S works, because we were able to calculate firm signatures, the bootrom didn't check the full 256 Byte signature.
There is a very good reason why the switch will never have such a bug: Bootrom is patchable via efuse programming.
So even if B9S came out after switch, Nintendo might have patched it already on 2.x.

We don't know that an emuNAND setup would be impossible for the reasons you listed.

You misunderstood my point about B9S. It's specific to 3DS hardware, which is why I said something B9S-like might be possible on the Switch. CFW on the Switch could be used to prevent the removal of a B9S-like exploit, like on the 3DS.

There are also other solutions I didn't mention, like using a 3.0.0 frankenfirm emuNAND patched to work with 3.0.1+ games.