Hacking EmuNAND/RedNAND technical implementation

neobrain

-
OP
Member
Joined
Apr 25, 2014
Messages
306
Trophies
0
XP
730
Country
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
 
Last edited by neobrain,

neobrain

-
OP
Member
Joined
Apr 25, 2014
Messages
306
Trophies
0
XP
730
Country
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.
 
Last edited by neobrain,

jimmyleen

Well-Known Member
Member
Joined
Feb 28, 2016
Messages
1,171
Trophies
0
XP
704
Country
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

Well-Known Member
Member
Joined
Mar 8, 2009
Messages
4,702
Trophies
2
Age
48
Location
Japan
XP
3,571
Country
United States
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?
 
  • Like
Reactions: fr3quency

DSoryu

GBA/NDS Maniac
Member
Joined
May 5, 2010
Messages
2,346
Trophies
2
Location
In my house
XP
4,693
Country
Mexico
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

Well-Known Member
Member
Joined
Jan 11, 2016
Messages
102
Trophies
0
XP
166
Country
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?
 
  • Like
Reactions: FenrirWolf

DSoryu

GBA/NDS Maniac
Member
Joined
May 5, 2010
Messages
2,346
Trophies
2
Location
In my house
XP
4,693
Country
Mexico
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

Well-Known Member
Member
Joined
Feb 28, 2011
Messages
166
Trophies
1
XP
1,200
Country
Germany
I dont understand the technical details so much. Can anybody explain the pros and cons with easy words? What is the better choice?
 

jakerman999

Well-Known Member
Newcomer
Joined
May 15, 2013
Messages
52
Trophies
0
Age
31
XP
338
Country
Canada
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.
 
  • Like
Reactions: Glix

Glix

Well-Known Member
Member
Joined
Jan 11, 2016
Messages
102
Trophies
0
XP
166
Country
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. :P
 

GerbilSoft

Well-Known Member
Member
Joined
Mar 8, 2012
Messages
2,395
Trophies
2
Age
34
XP
4,249
Country
United States
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.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    K3Nv2 @ K3Nv2: Sorry for accidentally bending over