But can't Rei keep the encryption currently used right now? So it can be "legal to some degree"?
- Thread starter Reisyukaku
- Start date
- Views 869,901
- Replies 6,480
- Likes 115
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, (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.
Code:
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);
}
}
}
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:
This is correct (no guess here).
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?)
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.
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
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.
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).
Just want to poke a bit, so I can see where my misunderstandings come from =)
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?)
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 =/
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?)
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 =/
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.
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.
..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.
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.
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.
Last edited by daxtsu,
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
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
Similar threads
-
- Portal
-
- Article
