Hacking Official [Source Release] ReiNand CFW

[tom2199]

It's now decrypted on the fly.

so it is now using the same firmare.bin as cakes, right? the undecrypted one.

 

[SomeGamer]

so it is now using the same firmare.bin as cakes, right? the undecrypted one.

No, Rei encrypts the bin in his own way.

 

[daxtsu]

btw, why the firmware.bin file changed?

Legal purposes. Rei encrypted it with a key he made up ("memekey") so that it can be redistributed with less issues. I sort of wish it'd just use the one from NUS with the CETK (which would give compatibility with the one Cakes uses) but that'd add some complicated code to a simple code base..

-snip-

-snip-

Don't compile with "gnu tools arm embedded", just use devkitPro/devkitARM.

 

[Aroth]

Legal purposes. Rei encrypted it with a key he made up ("memekey") so that it can be redistributed with less issues. I sort of wish it'd just use the one from NUS with the CETK (which would give compatibility with the one Cakes uses) but that'd add some complicated code to a simple code base..

Honestly it should be easier. To get the file we use, Rei takes the NUS one and decrypts it using the CETK and then encrypts it using his own key. The slot0x11key96 key that cakes uses is autogenerated by the system during firmlaunch from what I understand (to avoid legal issues with hard coding the key).

So whether reinand uses the NUS file and decrypts it using CETK, or uses a personally encrypted one and decrypts it, the file STILL has to be decrypted. Same for whether the cfw uses a hard coded slot0x11key96, pulls it from a bin file or uses code to generate the key. At the end of the day the slot 11 key has to be used, and it seems to me that the code for reading a key from a file and using it would be far simpler than creating the key to use.

 

[Aurora Wright]

The gateway Launcher.dat is heavily encrypted (even multiple encryption layers, if I'm not misremembering stuff) and it's prohibited to be shared here because it contains firmwares inside, though.

 

[daxtsu]

So whether reinand uses the NUS file and decrypts it using CETK, or uses a personally encrypted one and decrypts it, the file STILL has to be decrypted. Same for whether the cfw uses a hard coded slot0x11key96, pulls it from a bin file or uses code to generate the key. At the end of the day the slot 11 key has to be used, and it seems to me that the code for reading a key from a file and using it would be far simpler than creating the key to use.

I know it would still have to be decrypted, but I wasn't really getting at that. By having the user provide the encrypted binary and cetk, it removes the legal burden off Rei completely, rather than risk skirting things with this memekey and the encrypted blob. It's as simple as using a web browser to grab both files off the Nintendo server for the end user.

 

[Aurora Wright]

I know it would still have to be decrypted, but I wasn't really getting at that. By having the user provide the encrypted binary and cetk, it removes the legal burden off Rei completely, rather than risk skirting things with this memekey and the encrypted blob. It's as simple as using a web browser to grab both files off the Nintendo server for the end user.

Here's something though: decrypting NUS files is slow (takes like 5-6s on Cakes) so it would really slow down boot.

 

[daxtsu]

Here's something though: decrypting NUS files is slow (takes like 5-6s on Cakes) so it would really slow down boot.

It could just dump the decrypted file to SD when it's done, and use that on future boots.

 

[Aroth]

I know it would still have to be decrypted, but I wasn't really getting at that. By having the user provide the encrypted binary and cetk, it removes the legal burden off Rei completely, rather than risk skirting things with this memekey and the encrypted blob. It's as simple as using a web browser to grab both files off the Nintendo server for the end user.

Agreed, which is another reason why I personally feel he should handle it that way. The code should be simpler and there is far less legal ramifications towards Rei.

Here's something though: decrypting NUS files is slow (takes like 5-6s on Cakes) so it would really slow down boot.

Could do like rxTools does and do this:

It could just dump the decrypted file to SD when it's done, and use that on future boots.

Though at that point you are looking at something that is more complicated to write code for, I think.

 

[DjoeN]

Hmmz, latest release hangs on ReiNAND bootlogo :/ (First time reinand doesn't boot after updating)
reading the last few posts, it gets a bit confusing, do i still need the firmware.bin in the rei folder?

 

[Rosselman]

Hmmz, latest release hangs on ReiNAND bootlogo :/ (First time reinand doesn't boot after updating)
reading the last few posts, it gets a bit confusing, do i still need the firmware.bin in the rei folder?

Yes, but now it comes in the zip.

 

[daxtsu]

Hmmz, latest release hangs on ReiNAND bootlogo :/ (First time reinand doesn't boot after updating)
reading the last few posts, it gets a bit confusing, do i still need the firmware.bin in the rei folder?

Did you update Reinand.dat too? And yes, you always need the firmware.bin in the rei folder (but this time you need to use the one from Github, and not the dropbox link).

 

[DjoeN]

Found it already, seems i used the old firmware.bin instead of the one included in the zip.
(Comes because i compile myself)

Thanks

 

[Chizko]

work the new firmware.bin on NTR CFW?. Thanks.
EDIT. Work fine on 10.5 emuNAND and NTR CFW 3.3 work. Thanks.

 

[Supster131]

work the new firmware.bin on NTR CFW?. Thanks.

Yes.

 

[daxtsu]

work the new firmware.bin on NTR CFW?. Thanks.

It's the same 10.2 FIRM, just encrypted with a key Rei made up, so yes.

 

[tom2199]

work the new firmware.bin on NTR CFW?. Thanks.

it's an encrypted version of the 10.2 firm if i'm not mistaken, so yes, it would work just like before

 

[Reisyukaku]

I only added my own encryption so i could add firmware to the zip and it'd be:
A. 'legal' to some degree
B. less code then parsing an 'illegal' encrypted file
and
C. prevent all the firmware.bin confusion with people using the wrong ones somehow.
Seems its already still happening though, lol.. i cant win. >.<

 

[Supster131]

I only added my own encryption so i could add firmware to the zip and it'd be:
A. 'legal' to some degree
B. less code then parsing an 'illegal' encrypted file
and
C. prevent all the firmware.bin confusion with people using the wrong ones somehow.
Seems its already still happening though, lol.. i cant win. >.<

Don't hate the game, hate the player (because apparently they're still stupid >.>)

 

[daxtsu]

I only added my own encryption so i could add firmware to the zip and it'd be:
A. 'legal' to some degree
B. less code then parsing an 'illegal' encrypted file
and
C. prevent all the firmware.bin confusion with people using the wrong ones somehow.
Seems its already still happening though, lol.. i cant win. >.<

Probably the only thing you could really do is combine emunand.bin, thread.bin, and reinand.dat into one file, and then the only other things that get used are splash.bin (which is optional anyway) and firmware.bin. Then the only thing that can go wrong is either A) they forgot to put firmware.bin or B) reinand.dat is out of date.

But yeah, you can't possibly cover all user error unless you make it like Gateway's .dat and include the firmware.bin inside it, but then that just brings back the legal issues.