Hacking Official [Source Release] ReiNand CFW

[Supster131]

include the firmware.bin inside it, but then that just brings back the legal issues.

But can't Rei keep the encryption currently used right now? So it can be "legal to some degree"?

 

[nic0lette]

Hey rei, mind sending me a pm or sharing where in the code should be modified in order to display Rei on the top screen in order to distinguish cfw and reinand? O:

As far as I can tell, the code to do so is here:

void patches(void){

//Change version string for(int i = 0; i < 0x600000; i+=4){
if(strcomp((void*)0x27B00000 - i, (void*)L"Ver.", 4)){

if(strcomp((void*)0x27B00000 - i + 0x28, (void*)"T_ver_00", 4))

strcopy((void*)0x27B00000 - i, (void*)L"\uE024Rei", 4);​

}​

}​

}

(I had to reformat it a bit to be easier to read here)

 

[daxtsu]

As far as I can tell, the code to do so is here:

void patches(void){

//Change version string for(int i = 0; i < 0x600000; i+=4){
if(strcomp((void*)0x27B00000 - i, (void*)L"Ver.", 4)){

if(strcomp((void*)0x27B00000 - i + 0x28, (void*)"T_ver_00", 4))

strcopy((void*)0x27B00000 - i, (void*)L"\uE024Rei", 4);​

}​

}​

}

(I had to reformat it a bit to be easier to read here)

You can also use code tags ( [code ] [ /code] without spaces) to show code; it does give an ugly horizontal bar though, at times.

void patches(void){
    //Change version string
    for(int i = 0; i < 0x600000; i+=4){
        if(strcomp((void*)0x27B00000  - i, (void*)L"Ver.", 4)){
            if(strcomp((void*)0x27B00000  - i + 0x28, (void*)"T_ver_00", 4)) strcopy((void*)0x27B00000 - i, (void*)L"\uE024Rei", 4);
        }
    }
}

 

[nic0lette]

But can't Rei keep the encryption currently used right now? So it can be "legal to some degree"?

The thing I'm curious about (and hoping someone can answer) is that "firmware.bin" is just a copy of NATIVE_FIRM, correct? But NATIVE_FIRM is both in memory AND in emuNAND. Why can't we just grab the file from there?

(My guess for why we can't just grab it from emuNAND is that it's encrypted and the key for it is thrown away after boot so we can't reuse it? And the reason we can't use the one in RAM is that we messed it up to get into homebrew?)

 

[daxtsu]

The thing I'm curious about (and hoping someone can answer) is that "firmware.bin" is just a copy of NATIVE_FIRM, correct? But NATIVE_FIRM is both in memory AND in emuNAND. Why can't we just grab the file from there?

(My guess for why we can't just grab it from emuNAND is that it's encrypted and the key for it is thrown away after boot so we can't reuse it? And the reason we can't use the one in RAM is that we messed it up to get into homebrew?)

This is mostly a series of guesses on my part, but I'll break it down:

The thing I'm curious about (and hoping someone can answer) is that "firmware.bin" is just a copy of NATIVE_FIRM, correct?

This is correct (no guess here).

But NATIVE_FIRM is both in memory AND in emuNAND. Why can't we just grab the file from there?

I would guess that we don't use the one from emuNAND for either A) compatibility reasons (can't guarantee a future NATIVE_FIRM will always work, even with the new smart patching; if Nintendo ends up coming out with a new OS that connects the 3DS to the NX for example, we're probably SOL for a while, until it's reverse-engineered) or B) encryption/decryption issues (wouldn't we need the console's unique key to decrypt that part of emuNAND?)

And the reason we can't use the one in RAM is that we messed it up to get into homebrew?

When you just use MenuHax, the NATIVE_FIRM would still be fine and intact, but when you use CakeHax/Brahma/etc., which is what we use to launch CFW, you're doing a hostile takeover of the ARM9 CPU, so whatever Nintendo code was there will be trashed or removed. Even if you could still use the current NATIVE_FIRM, that wouldn't necessarily be desirable, since the 4.x-9.2 kernel is pretty old, and newer games are needing newer ones. I would take a guess that there would also be race conditions or stability issues with trying to redirect already running code to read from SD instead of NAND. It's probably much, much safer to load a new kernel into memory, patch it to read from SD from the get-go and then just reboot into it.

 

[tom2199]

I think the discussion about the new firmware.bin file overshadowed the problem with nds-flashcards in reinand 3.2. others are experiencing the same problem as well. @Reisyukaku can you please look into this? great work btw

 

[RednaxelaNnamtra]

The thing I'm curious about (and hoping someone can answer) is that "firmware.bin" is just a copy of NATIVE_FIRM, correct? But NATIVE_FIRM is both in memory AND in emuNAND. Why can't we just grab the file from there?

With the new smart patching it could maybe be possible(haven't checked how smart it is), but we would have to check somehow which encryption key we need to use, the first one, the 9.5 one or the 9.6+ one. so we would need to encrypt at least a port of the firmware to check if the result is properly decrypted. The other way would be to save a part of the firm(like a signature) ans check it, but this way we would need to do this for every firm version.

 

[Stack3r]

So my reinand works but the splash screen doesnt show up sometimes, is there a way to fix this so it will show up everytime?

 

[Supster131]

So my reinand works but the splash screen doesnt show up sometimes, is there a way to fix this so it will show up everytime?

Yeah, happens to me sometimes. I just assume it doesn't appear because it's booting too fast to even have time for the splash screen to appear. (That may just be a placebo effect though...)

 

[RednaxelaNnamtra]

Yeah, happens to me sometimes. I just assume it doesn't appear because it's booting too fast to even have time for the splash screen to appear. (That may just be a placebo effect though...)

I think this happens, when the screen initialisation doesn't work as expected, and is happening before the reinand payload(inside of brahma/CakeBrah).

 

[nic0lette]

Just want to poke a bit, so I can see where my misunderstandings come from =)

I would guess that we don't use the one from emuNAND for either A) compatibility reasons (can't guarantee a future NATIVE_FIRM will always work, even with the new smart patching; if Nintendo ends up coming out with a new OS that connects the 3DS to the NX for example, we're probably SOL for a while, until it's reverse-engineered) or B) encryption/decryption issues (wouldn't we need the console's unique key to decrypt that part of emuNAND?)

Hm. I was just looking at ReiNAND and it looks like loadFirm (firm.c) undoes Reisyukaku's encryption and then passes the pointer to the code off to arm9loader (crypto.c) so it seems as though it can get access to the key that's used?

What you said also brings up an interesting question. What if 10.6 is released and it's not easily patched for some reason or another. Could one still update emuNAND and have it load and boot Nintendo firmware properly (ie: just like it had been sysNAND but from the SDcard?)

When you just use MenuHax, the NATIVE_FIRM would still be fine and intact, but when you use CakeHax/Brahma/etc., which is what we use to launch CFW, you're doing a hostile takeover of the ARM9 CPU, so whatever Nintendo code was there will be trashed or removed. Even if you could still use the current NATIVE_FIRM, that wouldn't necessarily be desirable, since the 4.x-9.2 kernel is pretty old, and newer games are needing newer ones. I would take a guess that there would also be race conditions or stability issues with trying to redirect already running code to read from SD instead of NAND. It's probably much, much safer to load a new kernel into memory, patch it to read from SD from the get-go and then just reboot into it.

Using the 9.2 NATIVE_FIRM would probably be a bad idea, you're right. ^^ I wasn't even thinking about that.

I wonder if it would make much difference with the timing though. Like, the code isn't running until we jump to it. In ReiNAND that happens in launchFirm (firm.c) which happens way way after firmware.bin is loaded. (The sequence in main (main.c) is: mount the SD card, load/show the splash screen, load firmware.bin, load emunand, apply firmware patches, and then starting)

Actually... since it's already loading firmware.bin from the SD card the only difference would be that it have to read it from the "invisible" partition, which might be interesting to get going?

But yeah, I feel as though I'm missing something... Well, I *know* I am! I'm unsure when the "emuNAND" on the SD card is actually loaded in relation to all of this happening =/

 

[daxtsu]

But yeah, I feel as though I'm missing something... Well, I *know* I am! I'm unsure when the "emuNAND" on the SD card is actually loaded in relation to all of this happening =/

I believe the CFW boot process goes like this currently:

Power button -> BootROM executes -> sysNAND Firm0 is loaded (NATIVE_FIRM basically) -> various system modules are loaded -> Home Menu -> MenuHax kicks in, crashing the home menu -> <whatever you use to boot ReiNAND> -> ARM11 gets exploited -> reinand.dat (or whatever cfw.dat) is loaded -> ARM9 takeover -> Reboot into emuNAND

Someone can fill in the gaps that I got wrong or missed, though.

 

[nic0lette]

With the new smart patching it could maybe be possible(haven't checked how smart it is), but we would have to check somehow which encryption key we need to use, the first one, the 9.5 one or the 9.6+ one. so we would need to encrypt at least a port of the firmware to check if the result is properly decrypted. The other way would be to save a part of the firm(like a signature) ans check it, but this way we would need to do this for every firm version.

I'm not sure what you mean "check ... which encryption key we need to use"? How would the 3DS natively do that, or is it because CFW wants to support multiple versions whereas the 3DS only needs to support the one its currently on?

 

[RednaxelaNnamtra]

I'm not sure what you mean "check ... which encryption key we need to use"? How would the 3DS natively do that, or is it because CFW wants to support multiple versions whereas the 3DS only needs to support the one its currently on?

Yes, the n3DS is simply launches the arm9loader. The arm9laoder knows which key it would need to use, because its inside of the code, while a cfw implements its own arm9loader to encrypt the firm and apply the patches.

 

[Stack3r]

Updated to 3.2 and now my dstwo doesnt work

 

[daxtsu]

..That's interesting, my Gateway Blue card also doesn't work on 3.2 (by doesn't work, I mean it just boots to a black screen), despite having just had it work with 3.2b last night. And no, I haven't upgraded or downgraded any whitelists/TWL_FIRMs since then, or changed anything on the NANDs themselves.

 

[Stack3r]

..That's interesting, my Gateway Blue card also doesn't work on 3.2 (by doesn't work, I mean it just boots to a black screen), despite having just had it work with 3.2b last night. And no, I haven't upgraded or downgraded any whitelists/TWL_FIRMs since then, or changed anything on the NANDs themselves.

Same here

 

[fate6]

GBA boots to black screen as well.

Edit: Oh and as others have said DS is broken, Using R4i SDHC 3DS RTS On my end.

 

[daxtsu]

Retail DS carts also do not boot. I'll see if I can figure out which of the two new commits broke it.

Edit: It was something in the smart patching. https://github.com/Reisyukaku/ReiNand/commit/e789d6091180d7d7ba56f3cea02b09d19b28074b Unsure what. Guess i could mess around with it a bit to see.

 

[Pacman`]

Stop complaining about your damn DS and GBA shiat.
Wanna use it, do it from sysnand.
Besides, booting DS from sysnand doesn't unstick the mset exploit and when you leave the game you can use DS right away (on emunand, leaving a DS game boots you back to sysnand).
Think about it