Hacking EmuNAND/RedNAND technical implementation

[neobrain]

Hi people,

I've been looking occasionally into public EmuNAND and RedNAND solutions - it does seem like there are quite a few of those available. However, despite the amount of available options, there seems to be quite the lack of technical reference on the actual implementation of EmuNAND and RedNAND - that is, the actual layout of data on the SD card. Maybe I've just missed something even after a while of looking around. Either way, I'm sure there are some knowledgeable people who could clear this up easily, though, hence why I'm creating this thread.

Basically, I'm curious about two things:
- What is the actual layout of EmuNAND images on the SD card? How specifically is the NAND image injected onto the SD card storage? I've heard people talking about hidden FAT partitions and modifying the partition table, but all of this is hard to follow without an understanding of the firmware patches used to load the CFW in the first place.
- What is different about RedNAND images?

For reference, I will keep this thread updated with any information given to me, so that hopefully, people looking for the same information can find it more easily in the future.

Thanks in advance for any suggestions!


EDIT:
Well, nevermind. Normmatt clearred most of it up on IRC (thanks!). Leaving the info out there, though. See the second post in this thread

 

[neobrain]

Current information gathered:

Say, NAND image is N bytes large.

Background and general idea:
- The first 512 bytes on the SD card are the MBR (Master Boot Record), which includes information of all partitions present on the SD card. In particular, it contains information about the offset of each filesystem on the storage device.
- The "actual" SD filesystem can be shrinked and moved to make room for a full NAND image on the storage device.

RedNAND:
- The full NAND image is put onto the SD card at byte offset 512.
- Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
- The RedNAND implementation will offset all reads and writes to the NAND by 512 bytes.

EmuNAND:
- Bytes [512:N-1] of the NAND image are put onto the SD card at byte offset 512.
- Bytes [0;511] of the NAND image are put onto the SD card at byte offset N.
- Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
- The EmuNAND implementation leaves almost all reads/writes unmodified. Accesses to the first 512 bytes need to be redirected, however.

Bonus:
- It's easily possible to hide the NAND image by simply not having any entry for it in the MBR. I'm not quite sure if this serves any actual purpose, though.

I documented all of this on 3dbrew now.

 

[jimmyleen]

Current information gathered:

Say, NAND image is N bytes large.

Background and general idea:
- The first 512 bytes on the SD card are the MBR (Master Boot Record), which includes information of all partitions present on the SD card. In particular, it contains information about the offset of each filesystem on the storage device.
- The "actual" SD filesystem can be shrinked and moved to make room for a full NAND image on the storage device.

RedNAND:
- The full NAND image is put onto the SD card at byte offset 512.
- Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
- The RedNAND implementation will offset all reads and writes to the NAND by 512 bytes.

EmuNAND:
- Bytes [512:N-1] of the NAND image are put onto the SD card at byte offset 512.
- Bytes [0;511] of the NAND image are put onto the SD card at byte offset N.
- Following the NAND image, a standard FAT filesystem containing the "actual" SD data is stored at byte offset N+512.
- The EmuNAND implementation leaves almost all reads/writes unmodified. Accesses to the first 512 bytes need to be redirected, however.

Bonus:
- It's easily possible to hide the NAND image by simply not having any entry for it in the MBR. I'm not quite sure if this serves any actual purpose, though.

I documented all of this on 3dbrew now.

Now all we need is a guide on how to get this up and running on the N3DS.

Edit: I will NOT use my 3ds as a Ginny pig

 

[urherenow]

I still fail to see what makes RedNAND better. What is better about having to shift all reads and writes to emuNAND? What prevents something from messing up the hook, causing a corrupted emuNAND?

 

[DSoryu]

I still fail to see what makes RedNAND better. What is better about having to shift all reads and writes to emuNAND? What prevents something from messing up the hook, causing a corrupted emuNAND?

I guess it benefits on speed, making it as fast as the sysNAND.

I'm using sysnand with A9LH right now and he speed access is quite noticeable compared to emuNAND.

 

[Glix]

I guess it benefits on speed, making it as fast as the sysNAND.

I'm using sysnand with A9LH right now and he speed access is quite noticeable compared to emuNAND.

You are way off the mark. This has nothing to do with making it as fast as sysnand (you can't, latency of sd's cards and the reader/writer slow it down).

Translating into pictures:

Rednand on SD:
[mbr (512b)][SYSNAND converted into sdNAND][FAT user space]

EmuNAND on SD:
[mbr (512b)][512:Sysnand end (don't know why neo states -1 here, why lop it off?)][Sysnand beginning:511][FAT user space]

I presume it's the redirecting and calculating layer that they want to bin in favour for just offsetting every call which would things cheaper in terms of the greater than operations on every call. But in real life, is the Arm really that slow that the user would see the performance gain?

 

[DSoryu]

You are way off the mark. This has nothing to do with making it as fast as sysnand (you can't, latency of sd's cards and the reader/writer slow it down).

Translating into pictures:

Rednand on SD:
[mbr (512b)][SYSNAND converted into sdNAND][FAT user space]

EmuNAND on SD:
[mbr (512b)][512:Sysnand end (don't know why neo states -1 here, why lop it off?)][Sysnand beginning:511][FAT user space]

I presume it's the redirecting and calculating layer that they want to bin in favour for just offsetting every call which would things cheaper in terms of the greater than operations on every call. But in real life, is the Arm really that slow that the user would see the performance gain?

Oh, I see it clearly now, thank you.

 

[nintendowii]

I dont understand the technical details so much. Can anybody explain the pros and cons with easy words? What is the better choice?

 

[jakerman999]

EmuNAND on SD:
[mbr (512b)][512:Sysnand end (don't know why neo states -1 here, why lop it off?)][Sysnand beginning:511][FAT user space]

The -1 isn't lopping off the end of the emunand, N-1 is the end of the emunand. It's a zero indexed system. This means if it were 10 bytes long, the first byte would be 0 and the last byte would be 9.

 

[Glix]

The -1 isn't lopping off the end of the emunand, N-1 is the end of the emunand. It's a zero indexed system. This means if it were 10 bytes long, the first byte would be 0 and the last byte would be 9.

Ah right, thanks, note to self, don't overthink it at 2:43am.

 

[jakerman999]

Ah right, thanks, note to self, don't overthink it at 2:43am.

No worries, I myself am no stranger to the general 3AM grogginess

 

[GerbilSoft]

I dont understand the technical details so much. Can anybody explain the pros and cons with easy words? What is the better choice?

From what I understand, RedNAND is a better choice for N3DSes with the Toshiba 1.8 GB NAND, since the CTRNAND partition is always sized for the 1.2 GB version. In this case, the extra 600 MB can be cut off from the end of the RedNAND without any issues. With GW-style EmuNAND, this isn't possible, since sector 0 is always located at the end of the EmuNAND area, which is determined by checking the SysNAND size.

For other NAND types, it doesn't usually make much of a difference, though you obviously need to use GW EmuNAND if you want to use a Gateway card.