ROM Hack Question Could the files found in /Nintendo/save/ on the microSD card hold any relevance to Switch hacking?

[Bug_Checker_]

i took a brand new card placed in the switch i opened the 8000000000000124 file and i found : res/drawable-xxxhdpi-v4/zw02.qmg

It appears you have found a pk zip file(starting 0X11B3931 [50 4B 03 04]).
It looks like you need version 1.0 (0x0A) or greater to open the file.
The file zw02.qmg is in res/drawable-xxxhdpi-v4/ .
The file is uncompressed so both file sizes(packed and uncompressed) are 1,286,671 bytes [00 13 A2 0F].
The CRC32 is 9F058259.
The length of the name is 32 bytes (0x20).
The other numbers are time and date.(before the CRC32)

 

[kylemsguy]

That path (res/drawable-xxxhdpi-v4/) looks like a path for an Android resource file, and qmg apparently is a Samsung boot/shutdown image format (https://forum.xda-developers.com/showthread.php?t=2189934). Was this card ever used in an Android phone?

 

[studio1b]

only device the card was used on was a win 7 machine to format it and then stuck it in the switch.

file has to be part of the switch as the header of it is the same as all the switch file headers
: NAX0

 

[jt_1258]

oh boy, time to see what kinda arguing is goin on here

 

[JUSPOZA]

I have no idea if this would help but what about hooking up a sd card/usb sniffing hardware?

 

[Sketchy1]

I have no idea if this would help but what about hooking up a sd card/usb sniffing hardware?

that would tell us nothing more then what it is writing mostly, and at what times because the fact is, the data is still encrypted

but theoretically speaking, it might tell us how it decrypts them when it does it (astronomically slim chance imo though...)

 

[dubbz82]

(astronomically slim chance imo though...)

Gotta remember what company we're dealing with. Nintendo couldn't even manage to implement RSA correctly on a console (the 3ds) after having a previous failure in implementing RSA (the wii). It's worth a stab, imo.

 

[kylemsguy]

So I was discussing this issue with a friend, and he has the theory that the cause of other files appearing in the Nintendo Switch's files could be due to the way it implements functionality similar to Linux's ftruncate. ftruncate is a function that truncates a file to a specified length, and the Nintendo Switch could be using this to extend the length of these files. Now, since FAT32 (not sure about exFAT; perhaps someone try this with an SDXC card that was once in a smartphone?) does not support sparse files, the OS has to pre-allocate the space to the files. Normally, the OS should initialize this new space to NULs (0's), but in the interest of speed, perhaps Nintendo omitted that favour for performance in their implementation of this functionality. From what I've seen here, everyone who's tested has done a quick format, which does not wipe the old files' contents. Because of this, there is a high chance that the previous files' data still remain in this new segment of the file.

TL;DR: this data could be left over from a previous format as a result of an implementation detail, and any foreign, recognizable data is probably a red herring.

 

[DerpyEagle]

So I was discussing this issue with a friend, and he has the theory that the cause of other files appearing in the Nintendo Switch's files could be due to the way it implements functionality similar to Linux's ftruncate. ftruncate is a function that truncates a file to a specified length, and the Nintendo Switch could be using this to extend the length of these files. Now, since FAT32 (not sure about exFAT; perhaps someone try this with an SDXC card that was once in a smartphone?) does not support sparse files, the OS has to pre-allocate the space to the files. Normally, the OS should initialize this new space to NULs (0's), but in the interest of speed, perhaps Nintendo omitted that favour for performance in their implementation of this functionality. From what I've seen here, everyone who's tested has done a quick format, which does not wipe the old files' contents. Because of this, there is a high chance that the previous files' data still remain in this new segment of the file.

TL;DR: this data could be left over from a previous format as a result of an implementation detail, and any foreign, recognizable data is probably a red herring.

Yup, this seems to be the case. I think that your and @Selver 's answers are correct, and I'm just glad that I got my question answered at all. Earlier, when I safe formattted an SD card, there were no out of place strings on it, just encrypted data. It probably just is wonky file allocation.

 

[pietempgba]

very interesting nintendo stuff

 

[GerbilSoft]

So I put a microSD card in my Switch, and checked the file /Nintendo/save/8000000000000000 :

80 KeyX: loaded, verified, set up
9f Finalizing Initialization...
bd Initialization: success!
d7 You selected "SysNAND Restore".
f7 This feature writes to the SysNAND.
11b Data will be overwriten, keep backups!
143 If you wish to proceed, enter:
162 <Left>, <Up>, <Right>, <Up>, <A>
184 (B to return, START to reboot)

Now, I'm pretty sure the Switch doesn't bundle a copy of Decrypt9WIP or Hourglass9. However, the card in question *did* have copies of those before. So it's fairly obvious what's happening: The Switch OS is allocating space on the card, but it isn't zeroing it out. Everything in that file (except maybe the headers?) is leftover content from previously-deleted files.