Hacking [QUESTION] SX OS Emunand is safe to prevent recent pokemon/tinfoil/etc bricks?

[comput3rus3r]

When you boot with SX OS Emunand, Sysnand is not touched. So yes, it does protect your Sysnand from being bricked.

can you test it? Don't make assumptions about this.

 

[Raugo]

The best way to know if the emunand protect the console in this case is testing it or asking to the maker of this malware. The "emunand" is only a copy of the actual nand redirected in the user partition but still using the emmc. If the malware overwrite the data using the mounted partition yes, the emunand protect but it if the malware access to the emmc in raw no.

 

[solitaire4eva]

This is a common missunderstanding here. The problem doesn't start when you install the fake game through the nsp. The problem starts when you run it.
Malcious code needs to be executed. This can happen through nsp, xci or a payload. Don't let yourself be fooled by the format it's delivered.

Just look at viruses or malware on a regular pc. Most of the time your problem begins when you open FREE_SONG.mp3.exe. Not when you download it.
The malware would need to be executed through any means on the right level of process elevation, before it can damage your system. The Switch is no different in that regard.

You avoided the problem. Many of the users probably just did a google search for the game, downloaded the first link he/she seen, and installed it. If they would have waited for a legitimate source to get the game from, they wouldn't be having any problems at all.

 

[Localhorst86]

You avoided the problem. Many of the users probably just did a google search for the game, downloaded the first link he/she seen, and installed it. If they would have waited for a legitimate source to get the game from, they wouldn't be having any problems at all.

He was addressing your claim that the attack was inheritent to the Nsp version and that an XCI release would not have caused it. That claim is simply not true. It doesn't matter if the malicious code is disguised in an XCI or A nsp.

So any release that you didn't create yourself (either by dumping your own cart or grabbing your eshop files from your system to create a nsp) can have hidden malware.

 

[takeitfish]

That's bullshit. It's the same system/PRODINFO/... partition. Try to launch the bricker if it's sooo safe.

I think there's a point that people are missing here... yes the data for EmuNAND is stored on the normal partition as a file, BUT - and this is the clincher - when EmuNAND is enabled and you boot from SX-OS doesn't it mount the files in such a way as to use the EmuNAND files instead and mask the original ones? I am only speaking from experience with virtual file systems and assuming that's what they've done - otherwise as suggested it would be kind of pointless.

Just assuming the simple answer here anyway. Isn't EmuNAND in memory to redirect read/writes to the "virtual" NAND instead? Obviously if you booted OFW it wouldn't be the case.

 

[Localhorst86]

I think there's a point that people are missing here... yes the data for EmuNAND is stored on the normal partition as a file, BUT - and this is the clincher - when EmuNAND is enabled and you boot from SX-OS doesn't it mount the files in such a way as to use the EmuNAND files instead and mask the original ones? I am only speaking from experience with virtual file systems and assuming that's what they've done - otherwise as suggested it would be kind of pointless.

Just assuming the simple answer here anyway. Isn't EmuNAND in memory to redirect read/writes to the "virtual" NAND instead? Obviously if you booted OFW it wouldn't be the case.

According to some voices, TXs """"Emunand"""" doesn't mask the entire Nand but only the USER partition. Leaving the target of this attack (the PRODINFO partition) vulnerable.

I can neither confirm nor deny this, just recapping what has been said in this thread.

Gesendet von meinem Mi A1 mit Tapatalk

 

[sj33]

It's pretty clear, Toarn did an excellent job of explaining it.

SX's implementation of EmuNAND only makes a copy of the USER partition. The brickers corrupt PRODINFO which is not stored within the USER partition. Thus, EmuNAND will not protect you from a brick because the corrupted portion is not within the EmuNAND.

There's no room for interpretation there.

 

[Raugo]

It's pretty clear, Toarn did an excellent job of explaining it.

SX's implementation of EmuNAND only makes a copy of the USER partition. The brickers corrupt PRODINFO which is not stored within the USER partition. Thus, EmuNAND will not protect you from a brick because the corrupted portion is not within the EmuNAND.

There's no room for interpretation there.

No, the SX OS "emunand" (is only a dual boot) is really simply but it's better than you say, the first process is defrag the user partition to get joined the amount of space allocated during installation then make files of 4GB until get all this space. Then inject the whole nand in this space but with the user partition reduced to fit in it. When the SX OS boot the "emunand" only need to redirect the offset of the partitions to the "emunand" sector. Theorically all the partitions are redirected, at least al partitions are copied in the user partition.