Hacking SX-OS emuNAND is seriously broken.

[Phenj]

Alright, time to make this clear.
First of all, my sysNAND is on 6.2 (online gaming, etc) and i made my emuNAND from a clean 6.2 using the latest SX-OS 2.4 version. Everything worked fine until i restarted my console, like normal, and SX-OS doesn't work anymore with emuNAND, after the Switch logo, a black screen with the error 2002-4373. sysNAND works fine.
I'm using FAT32 and the "Hidden partition on SD" emuNAND type.
The last thing i did was installing a .nsp onto my emuNAND, then i restarted it.

Spoiler: emuNAND

 

[KingMuk]

Seriously? I just dumped my NAND and then made my emuNAND (hidden partition) last night and everything worked out fine and dandy. I'm also on sxos 2.4beta and ofw 6.2.0. Maybe it was the nsp that you installed that fucked something up? Then again idk about that either considering I also installed some nsp's of my own last night when I did all this.

 

[Phenj]

Seriously? I just dumped my NAND and then made my emuNAND (hidden partition) last night and everything worked out fine and dandy. I'm also on sxos 2.4beta and ofw 6.2.0. Maybe it was the nsp that you installed that fucked something up? Then again idk about that either considering I also installed some nsp's of my own last night when I did all this.

I don't know, i just installed the Retroarch .nsp... could you try to "RESTART" your console from your emuNAND? Looks like that's what fucked my emuNAND.

 

[MasterJ360]

I don't know, i just installed the Retroarch .nsp... could you try to "RESTART" your console from your emuNAND? Looks like that's what fucked my emuNAND.

That could be the culprit I've never heard of anyone restarting the console under emunand eh I would believe it would just boot into ofw since you lose cfw upon a boot. Well you can always just
delete the bad emunand and make a new one

 

[KingMuk]

^
Yeah you def did something wrong dude. I'm not sure what because assuming you got the retroarch NSP from the retroarch switch thread then it shouldn't have fucked anything up. As a matter of fact that was one of the nsp's that I installed last night too. Maybe some more knowledgeable folks can help you out more. If no one helps you out here then you should probs try the team xecuter forum in the sxos section.

 

[kamesenin888]

The title should change, I seriously broke sx-os emunand

 

[Phenj]

Uhm... There could be a malicious/broken nsp... I gotta do some bruteforcing with all my nsp files

 

[isoisoiso]

Working as intended
Thanks for the money!

 

[Ransom342]

Black screen after the sx logo usually means corrupt ssd card. I had this happen in the past. backing the data up and reformatting the card fixed it for me.

 

[Deleted User]

Got hidden SD partition emunand, installed RetroArch.nsp, hit power > restart. I tried it, reboots back into emunand and loads fine.

At this point I am also suspecting you got a faulty microSD OP (or a malicious NSP.. but you said you only installed RetroArch NSP?)
If it was a malicious NSP, this emunand just saved you from a brick

 

[Phenj]

Got hidden SD partition emunand, installed RetroArch.nsp, hit power > restart. I tried it, reboots back into emunand and loads fine.

At this point I am also suspecting you got a faulty microSD OP (or a malicious NSP.. but you said you only installed RetroArch NSP?)
If it was a malicious NSP, this emunand just saved you from a brick

Thanks for your testing. I bought my sd from amazon, Samsung redeller... I'll try something else

 

[Phenj]

UPDATE:
Just run H2testw all night long, my SD should be fine:

The media is likely to be defective.
238.4 GByte OK (500108768 sectors)
272 KByte DATA LOST (544 sectors)
Details:272 KByte overwritten (544 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
0 KByte corrupted (0 sectors)
272 KByte aliased memory (544 sectors)
First error at offset: 0x000000123fff0000
Expected: 0x000000123fff0000
Found: 0x000000123fff8000
H2testw version 1.3
Writing speed: 25.8 MByte/s
Reading speed: 26.3 MByte/s
H2testw v1.4

Now i remember that i had installed 3 more .nsp files in the process back then, an Half-Life .nro to .nsp converted file, and a Tinfoil .nsp and a hbl.nsp

 

[Trunkz]

Thats slow speeds for a samsung microsd? Mine hits write speed rates of around 85-90MByte/s..

 

[Phenj]

Thats slow speeds for a samsung microsd? Mine hits write speed rates of around 85-90MByte/s..

I was thinking about that too. How is this possible? It is real 256GB... but the speed should be around 90MB/s, not 25

 

[Phenj]

I might have found the problem, after 2 hours of bruteforcing...
So, none of the installed .nsp files is malicious. But, this is what i did.
I'm using AUTORCM in all this.
0) New fresh emuNAND.
1) Install any NON working .nsp file
2) Run this application and let it crash, for example a non working forwarder.
3) Turned off my console by pressing the power button for like 12 seconds, i put the jig right back in, doesn't work.
4) Had to use Hekate to turn my console off, and then i could use my Xecuter JIG.
5) Bricked emuNAND somehow in the process.

 

[The Real Jdbye]

UPDATE:
Just run H2testw all night long, my SD should be fine:

The media is likely to be defective.
238.4 GByte OK (500108768 sectors)
272 KByte DATA LOST (544 sectors)
Details:272 KByte overwritten (544 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
0 KByte corrupted (0 sectors)
272 KByte aliased memory (544 sectors)
First error at offset: 0x000000123fff0000
Expected: 0x000000123fff0000
Found: 0x000000123fff8000
H2testw version 1.3
Writing speed: 25.8 MByte/s
Reading speed: 26.3 MByte/s
H2testw v1.4

Now i remember that i had installed 3 more .nsp files in the process back then, an Half-Life .nro to .nsp converted file, and a Tinfoil .nsp and a hbl.nsp

Those are very odd results. Overwritten bytes are typical of a fake card, which this is obviously not, but it shouldn't be overwriting data like that.
The emuNAND should be at the beginning of the card, so it wouldn't be affected by the overwritten data, but the nsp might have been corrupted in just the right way to brick your emuNAND (unlikely, but possible)
Not sure what to make of that. You can't really format the card to avoid that section either, because it's in the middle, right around the 74GB mark, so you'd have to have two partitions avoiding that part, but the Switch probably doesn't support multiple partitions on SD cards. Even Windows doesn't support it.

I was thinking about that too. How is this possible? It is real 256GB... but the speed should be around 90MB/s, not 25

Could just be your reader, is it USB 2.0 or USB 3.0? USB 2.0 can't achieve full speed with that card, but in addition to that, older readers tend to be slower because they were made in a time before faster cards were common and are using cheap parts that just aren't capable of faster speeds. A USB 3.0 one has to be newer, so it's more likely to be fast.

Thats slow speeds for a samsung microsd? Mine hits write speed rates of around 85-90MByte/s..

Sure you're not thinking of read speed? Write speed is usually lower than read speed.

 

[Phenj]

Those are very odd results. Overwritten bytes are typical of a fake card, which this is obviously not, but it shouldn't be overwriting data like that.
The emuNAND should be at the beginning of the card, so it wouldn't be affected by the overwritten data, but the nsp might have been corrupted in just the right way to brick your emuNAND (unlikely, but possible)
Not sure what to make of that. You can't really format the card to avoid that section either, because it's in the middle, right around the 74GB mark, so you'd have to have two partitions avoiding that part, but the Switch probably doesn't support multiple partitions on SD cards. Even Windows doesn't support it.

Could just be your reader, is it USB 2.0 or USB 3.0? USB 2.0 can't achieve full speed with that card, but in addition to that, older readers tend to be slower because they were made in a time before faster cards were common and are using cheap parts that just aren't capable of faster speeds. A USB 3.0 one has to be newer, so it's more likely to be fast.

Sure you're not thinking of read speed? Write speed is usually lower than read speed.

Was thinking about that, it is probably the reader, really cheap.
What's the thing around the 74GB mark? I'm really confused at this point

 

[The Real Jdbye]

Was thinking about that, it is probably the reader, really cheap.
What's the thing around the 74GB mark? I'm really confused at this point

The part with the overwritten data.

 

[Phenj]

The part with the overwritten data.

Yeah but why is that happening, why exactly at the 74GB mark... Never seen that before

 

[The Real Jdbye]

Yeah but why is that happening, why exactly at the 74GB mark... Never seen that before

I have no idea. Manufacturing defect maybe?