Hacking Official [Release] CakesFW

[GBHAKC75]

It's also possible they updated in sysnand accidentally, by leaving emunand unchecked. Updating sysnand accidentally would suck, but not as bad as bricking.

I don't see your point. It bricks if updating while FIRM protection patch is disabled. That's why I said it would be great if that was enabled by default...
If FIRM is protected, then A9LH would be still here after the update, so even if that bricks, you could debrick easily. That's the point of enabling FIRM protection by default.

 

[mid-kid]

So, today I just pushed a new nightly. This is the first test build for the new .cake format, which can do much more than the old format could, though most of the features aren't really user-visible.
So, since I know some people are excited about 3ds_injector, I took some time today to expand the new format to be able to have a 3ds_injector.cake: [REDACTED, see below]
It does regionfree and patches the "Ver." string. This is just temporary for people who can't wait for it.

Update: forgot to add NIM patches to allow region free carts: http://chunk.io/f/5224f8c21fb94c3eb348a361305de33f.cake

 

[Gray_Jack]

So, today I just pushed a new nightly. This is the first test build for the new .cake format, which can do much more than the old format could, though most of the features aren't really user-visible.
So, since I know some people are excited about 3ds_injector, I took some time today to expand the new format to be able to have a 3ds_injector.cake: http://chunk.io/f/eb383cddf2aa46c48d3cdde41f13c65f.cake
It does regionfree and patches the "Ver." string. This is just temporary for people who can't wait for it.

What's new in the new .cake format?

 

[mid-kid]

What's new in the new .cake format?

It's a complete makeover. Instead of just FIRM patches, it supports Memory, Userland and Sysmodule patches.
Memory patches are code that is too big to fit in FIRM, and needs some place in memory to stay. They're linked to hooks, which are FIRM patches. I use an ID to match them.
Userland patches speak for themselves, they patch userland applications, but the implementation for them isn't complete yet.
Sysmodule patches (added today due to 3ds_injector being one) are system modules. Just raw NCCHs wrapped in the .cake format. The patcher takes care of finding a location in the FIRM to fit them in, but right now you can only replace existing sysmodules, and the replacement may not be bigger than the original. This is due to me rushing the implementation for me to be able to push the 3ds_injector.cake asap.

The format can combine all four different kinds of patches into a single .cake, as well as combine all the different versions for different firmwares in a single .cake. To support multiple firmware versions, instead of recompiling the patch multiple times for all the firmwares, I have "variables" (strings that are replaced in-binary during patch-time). This way, I only have to change little parts of the patch to support the current firmware instead of replacing it completely (which makes the .cake file smaller).

Also a thing some users will notice: .cakes aren't being filtered, so some cakes will show up on the menu that aren't supported in the current firmware. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/32
If you enable a patch that isn't supported by the current firmware, you try booting, and you go back to the selection menu to disable it, and boot again, you might not be able to boot due to a "partial" patch. You will have to restart your console and attempt patching again. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/31

 

[Gray_Jack]

It's a complete makeover. Instead of just FIRM patches, it supports Memory, Userland and Sysmodule patches.
Memory patches are code that is too big to fit in FIRM, and needs some place in memory to stay. They're linked to hooks, which are FIRM patches. I use an ID to match them.
Userland patches speak for themselves, they patch userland applications, but the implementation for them isn't complete yet.
Sysmodule patches (added today due to 3ds_injector being one) are system modules. Just raw NCCHs wrapped in the .cake format. The patcher takes care of finding a location in the FIRM to fit them in, but right now you can only replace existing sysmodules, and the replacement may not be bigger than the original. This is due to me rushing the implementation for me to be able to push the 3ds_injector.cake asap.

The format can combine all four different kinds of patches into a single .cake, as well as combine all the different versions for different firmwares in a single .cake. To support multiple firmware versions, instead of recompiling the patch multiple times for all the firmwares, I have "variables" (strings that are replaced in-binary during patch-time). This way, I only have to change little parts of the patch to support the current firmware instead of replacing it completely (which makes the .cake file smaller).

Thanks for the explanation! Awesome work btw!!!

Another question, when select the cake that says "Survive reboots when launching some titles" and I try to boot the CFW, always says that the FIRM is not campatible, why? It's a bug cause it's a wip?

 

[yifan_lu]

It's a complete makeover. Instead of just FIRM patches, it supports Memory, Userland and Sysmodule patches.
Memory patches are code that is too big to fit in FIRM, and needs some place in memory to stay. They're linked to hooks, which are FIRM patches. I use an ID to match them.
Userland patches speak for themselves, they patch userland applications, but the implementation for them isn't complete yet.
Sysmodule patches (added today due to 3ds_injector being one) are system modules. Just raw NCCHs wrapped in the .cake format. The patcher takes care of finding a location in the FIRM to fit them in, but right now you can only replace existing sysmodules, and the replacement may not be bigger than the original. This is due to me rushing the implementation for me to be able to push the 3ds_injector.cake asap.

The format can combine all four different kinds of patches into a single .cake, as well as combine all the different versions for different firmwares in a single .cake. To support multiple firmware versions, instead of recompiling the patch multiple times for all the firmwares, I have "variables" (strings that are replaced in-binary during patch-time). This way, I only have to change little parts of the patch to support the current firmware instead of replacing it completely (which makes the .cake file smaller).

Also a thing some users will notice: .cakes aren't being filtered, so some cakes will show up on the menu that aren't supported in the current firmware. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/32
If you enable a patch that isn't supported by the current firmware, you try booting, and you go back to the selection menu to disable it, and boot again, you might not be able to boot due to a "partial" patch. You will have to restart your console and attempt patching again. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/31

Is it possible to have a ".cake" parser in 3ds_injector? Then you can support the userland patches.

 

[mid-kid]

Is it possible to have a ".cake" parser in 3ds_injector? Then you can support the userland patches.

That's what I wanted to do.
Do note, however, that .cake doesn't do any fancy searching for code to replace or the scripting language you wanted, just static offsets.

 

[GBHAKC75]

"Add (untested) emunand patches for 3.x"

Wow, sounds good. So you plan to bring old firmwares to EmuNAND ? Can't wait to see some 2.1 firmware here
That would allow N3DS users to test their patched 2.1 NANDs before flashing them to sysNAND (even if it's pretty safe now with OTPHelper).

 

[mid-kid]

"Add (untested) emunand patches for 3.x"

Wow, sounds good. So you plan to bring old firmwares to EmuNAND ? Can't wait to see some 2.1 firmware here
That would allow N3DS users to test their patched 2.1 NANDs before flashing them to sysNAND (even if it's pretty safe now with OTPHelper).

This patch was added by @Normmatt (I forgot to credit him in the commit), and I haven't bothered adding the firm signature for 3.x nor test it yet (I just needed to commit the file to merge the wip branch). No, I don't plan on doing that, though I know some other people have efforts going for doing just that. Please note that nintendo rewrote the FIRM between 2.x and 3.x, so porting patches to 2.x is hard.

--------------------- MERGED ---------------------------

Thanks for the explanation! Awesome work btw!!!

Another question, when select the cake that says "Survive reboots when launching some titles" and I try to boot the CFW, always says that the FIRM is not campatible, why? It's a bug cause it's a wip?

I added that info later, in an edit:

Also a thing some users will notice: .cakes aren't being filtered, so some cakes will show up on the menu that aren't supported in the current firmware. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/32
If you enable a patch that isn't supported by the current firmware, you try booting, and you go back to the selection menu to disable it, and boot again, you might not be able to boot due to a "partial" patch. You will have to restart your console and attempt patching again. See this issue: https://github.com/mid-kid/CakesForeveryWan/issues/31

 

[Krude]

Would the new format make it possible to also patch SAFE_MODE firm with the a9lh firm protection? AuReiNand currently just flat out blocks safe mode to prevent bricks via a safe mode update, but that's not a very good solution. It would be better to just adapt the firm protection patches to the safe mode firm and leave the user to access it.

 

[mid-kid]

Would the new format make it possible to also patch SAFE_MODE firm with the a9lh firm protection? AuReiNand currently just flat out blocks safe mode to prevent bricks via a safe mode update, but that's not a very good solution. It would be better to just adapt the firm protection patches to the safe mode firm and leave the user to access it.

I'm sure it can be done, but right now I have no idea how, nor interest in doing it. I won't block access to SAFE_MODE, though.

 

[GBHAKC75]

This patch was added by @Normmatt (I forgot to credit him in the commit), and I haven't bothered adding the firm signature for 3.x nor test it yet (I just needed to commit the file to merge the wip branch). No, I don't plan on doing that, though I know some other people have efforts going for doing just that. Please note that nintendo rewrote the FIRM between 2.x and 3.x, so porting patches to 2.x is hard.

Okay, thanks for the explanation ! Just one last little question : does 3.x firmwares needs to be "unbricked" on N3DS ? I was wondering because I would like to try to install a 3.x firmware, just for testing purposes.

I'm sure it can be done, but right now I have no idea how, nor interest in doing it. I won't block access to SAFE_MODE, though.

May I ask why ? Safe Mode is dangerous with A9LH...

 

[DjoeN]

@mid-kid
Do we have to add something to build the newest version ourself? cause i get an error while trying to build:

make[1]: Leaving directory `/d/CFWCN3DS/CakesForeveryWan/CakeHax'
dd if=build/main.bin of=out/Cakes.dat bs=512 seek=144
85+1 records in
85+1 records out
43568 bytes (44 kB) copied, 0.02 seconds, 2.2 MB/s
bake out/cakes/patches/emunand.cake
ARMIPS Assembler v0.8.0 (Jan 25 2016 00:21:31) by Kingcom
Done.
/bin/sh: line 2: python3: command not found
make: *** [out/cakes/patches/emunand.cake] Error 127

 

[mid-kid]

@mid-kid
Do we have to add something to build the newest version ourself? cause i get an error while trying to build:

make[1]: Leaving directory `/d/CFWCN3DS/CakesForeveryWan/CakeHax'
dd if=build/main.bin of=out/Cakes.dat bs=512 seek=144
85+1 records in
85+1 records out
43568 bytes (44 kB) copied, 0.02 seconds, 2.2 MB/s
bake out/cakes/patches/emunand.cake
ARMIPS Assembler v0.8.0 (Jan 25 2016 00:21:31) by Kingcom
Done.
/bin/sh: line 2: python3: command not found
make: *** [out/cakes/patches/emunand.cake] Error 127

You require python version 3 with pyyaml to build cakes.

 

[DjoeN]

Ok, time to setup python 3 on another computer i suppose

 

[mid-kid]

Okay, thanks for the explanation ! Just one last little question : does 3.x firmwares needs to be "unbricked" on N3DS ? I was wondering because I would like to try to install a 3.x firmware, just for testing purposes.

Probably, I don't have an n3ds so I haven't done any messing with that.
Just note that as I haven't added the 3.x firm signature yet, Cakes will tell you the firmware is unsupported.

May I ask why ? Safe Mode is dangerous with A9LH...

Because I... I don't have a reason not to, I just don't think it's necessary. I'd rather look for a way to patch SAFE_MODE_FIRM.

 

[GBHAKC75]

Probably, I don't have an n3ds so I haven't done any messing with that.
Just note that as I haven't added the 3.x firm signature yet, Cakes will tell you the firmware is unsupported.



Because I... I don't have a reason not to, I just don't think it's necessary. I'd rather look for a way to patch SAFE_MODE_FIRM.

I see, thanks !

Oh, so we could update using Safe Mode ? That's actually a great idea, didn't thinked about it !

 

[Madridi]

You require python version 3 with pyyaml to build cakes.

So we can no longer use Python 2.7?

If yes, I suppose python 2.7 & 3 can't be on the same PC can it..

 

[DjoeN]

Yes it can, but it's not that evident (python 3 has a build in selector or something like that
read more here:
http://stackoverflow.com/questions/341184/can-i-install-python-3-x-and-2-x-on-the-same-computer

 

[mid-kid]

So we can no longer use Python 2.7?

If yes, I suppose python 2.7 & 3 can't be on the same PC can it..

Unless someone wants to make the script work on both py2 and py3, no. But you can have both on the same machine.