Hacking Official Corbenik - Another CFW for advanced users (with bytecode patches!)

[chaoskagami]

Just to let you know:

With latest build i got a AGB error
When turning AGB patches off in config the system boots fine again.
Then turning AGB patches back on it worked again, no error anymore.

Config file loaded.
FIRM load triggered.
NATIVE_FIRM
  [l_p]
Ver: 00000052, 0
TWL_FIRM
  [l_p]
Ver: 00000016, 0
AGB_FIRM
  [l_p]
Ver: 0000000b, 0
Saving config.
Config file loaded.
Loading firmware...
FIRM load triggered.
NATIVE_FIRM
  [l_p]
Ver: 00000052, 0
TWL_FIRM
  [l_p]
Ver: 00000016, 0
AGB_FIRM
  [l_p]
Ver: 0000000b, 0
Patching firmware...
f flag is not set, halting VM!

What are you using as a firmware file? There's zero way that will ever happen. It's not finding the pattern, which is impossible unless you're using a prepatched AGB firmware. Can you sha1sum your agb file?

EDIT: Actually, why is it loading the firmware twice? That should NEVER happen. Did you hit power off? There's a long standing issue where caches don't get regenerated if you power off after changing settings and not booting.

 

[DjoeN]

What are you using as a firmware file? There's zero way that will ever happen. It's not finding the pattern, which is impossible unless you're using a prepatched AGB firmware. Can you sha1sum your agb file?

EDIT: Actually, why the is it loading the firmware twice? That should NEVER happen.

After i turned all agb patches off and boot without and then reboot in config to turn back on all agb patches it worked.
I wiped the log files to have a clean log now.

Spoiler: boot.log

Config file loaded.
Saving config.
Config file loaded.
Loading firmware...
FIRM load triggered.
NATIVE_FIRM
  [l_p]
Ver: 00000052, 0
TWL_FIRM
  [l_p]
Ver: 00000016, 0
AGB_FIRM
  [l_p]
Ver: 0000000b, 0
Patching firmware...
VM exited without issue
reboot: proc9 mem @ 08028000
            reboot: firmlaunch @ 240da5e8
reboot: fopen @ 08059d25
            reboot: NATF @ 240da714
reboot: TWLF @ 240da718
reboot: AGBF @ 240da71c
reboot: rebc @ 240da700
            emunand: free space @ 2407b1c0
emunand: size is 811344 bytes
emunand: read in emunand code
emunand: found NCSD magic for 0
emunand: layout is gateway
emunand: nand is on sector 0
emunand: head is on sector 1931264
emunand: write @ 240cd730
emunand: read @ 240cd6f0
emunand: patched read/write calls
emunand: SDMMC code @ 080d8a70
emunand: mpu @ 2407c164
emunand: patched MPU settings
            svc: 0x7B (backdoor) missing.
Svc: backdoor is 40 bytes
Svc: Read code to 24062f28
svc: Injected 0x7B.
            module: Grow 2 units
Module: Injecting 610271512
Moule: injected modules.
            Copied FIRM

agb sha1 check

 

[chaoskagami]

After i turned agb off and boot without and then reboot in config to turn on agb it worked
I wiped the log files to have a clean log now.

Config file loaded.
Saving config.
Config file loaded.
Loading firmware...
FIRM load triggered.
NATIVE_FIRM
  [l_p]
Ver: 00000052, 0
TWL_FIRM
  [l_p]
Ver: 00000016, 0
AGB_FIRM
  [l_p]
Ver: 0000000b, 0
Patching firmware...
VM exited without issue
reboot: proc9 mem @ 08028000
            reboot: firmlaunch @ 240da5e8
reboot: fopen @ 08059d25
            reboot: NATF @ 240da714
reboot: TWLF @ 240da718
reboot: AGBF @ 240da71c
reboot: rebc @ 240da700
            emunand: free space @ 2407b1c0
emunand: size is 811344 bytes
emunand: read in emunand code
emunand: found NCSD magic for 0
emunand: layout is gateway
emunand: nand is on sector 0
emunand: head is on sector 1931264
emunand: write @ 240cd730
emunand: read @ 240cd6f0
emunand: patched read/write calls
emunand: SDMMC code @ 080d8a70
emunand: mpu @ 2407c164
emunand: patched MPU settings
            svc: 0x7B (backdoor) missing.
Svc: backdoor is 40 bytes
Svc: Read code to 24062f28
svc: Injected 0x7B.
            module: Grow 2 units
Module: Injecting 610271512
Moule: injected modules.
            Copied FIRM

It was either that you didn't invalidate the cache properly or lost a sector on your SD card. I have no clue. Unless you can find a way to reproduce this reliably, I'm afraid I have no clue. Nothing has changed in the VM.

Also: DO NOT WIPE THE LOGS. I mean, I'm not attempting to grill here, but this is pretty important.

I need the full log whenever debugging issues, not just the 'relevant portion.' That's a very slippery slope to users giving me just the last line (which happens all the time on linux forums and is useless to me.)

I can sift through them myself and decide what is relevant, please don't do so for me.

 

[DjoeN]

It was either that you didn't invalidate the cache properly or lost a sector on your SD card. I have no clue. Unless you can find a way to reproduce this reliably, I'm afraid I have no clue. Nothing has changed in the VM.

Also: DO NOT WIPE THE LOGS. I mean, I'm not attempting to grill here, but this is pretty important.

I need the full log whenever debugging issues, not just the 'relevant portion.' That's a very slippery slope to users giving me just the last line (which happens all the time on linux forums and is useless to me.)

I can sift through them myself and decide what is relevant, please don't do so for me.

Sorry :/
I'll keep that in mind and will never wipe any log again

 

[chaoskagami]

Sorry :/
I'll keep that in mind and will never wipe any log again

It's alright. I just wanted to let you know (since you seem pretty reasonable, heh. )

I'm taking a sleep for the day. Fixing in morning.

 

[chaoskagami]

As far as I can tell, 0975fb7e fixed uncart. As a bonus, I merged master into my fork (which just has a slightly less eye-murdery UI.)

I think it's getting to be about time for another release here.

 

[Kirtai]

As a bonus, I merged master into my fork (which just has a slightly less eye-murdery UI.)

I have to wonder what inspired the red on white uncart ui. Was the author watching slasher flicks while coding?

 

[chaoskagami]

I have to wonder what inspired the red on white uncart ui. Was the author watching slasher flicks while coding?

I have no clue, but it makes my eyes bleed (no offense intended, it's a good tool.)

I would PR my fork (the pretty UI is in the fancy branch - white on black and a progress bar) but I don't know if it's up to quality standards. Plus, maybe they LIKE the text color. I dunno.

 

[Kirtai]

I have no clue, but it makes my eyes bleed (no offense intended, it's a good tool.)

It's great, I've used it to dump all my carts and they all match the no-into dat files.
The UI feels to me like a quick and dirty one that was intended to be fixed later that no one got around to.

The only thing I really want added besides a better UI is DS cartridge dumping.

 

[DjoeN]

Gonna switch another O3DSXL system to corbenik as daily CFW this evening!

- I really love the way it uses patches and users can submit there own patches (mysterymachin as example)
- It now has the much needed chainloading!
- BootNTR works great on it!
- Choice of patches you want to use/not use (yes i have 1 system i don't use for virtual console games/dsi, so no need for AGB/TWL patches)
- etc...

Thumbs up @chaoskagami

Yes, somebody should redo the uncart, more like @d0k3 style
+ NDS(i) support
+ Reboot option
+ Shutdown option
+ Etc...

(but this belongs in another thread anyway )

 

[chaoskagami]

Gonna switch another O3DSXL system to corbenik as daily CFW this evening!

- I really love the way it uses patches and users can submit there own patches (mysterymachin as example)
- It now has the much needed chainloading!
- BootNTR works great on it!
- Choice of patches you want to use/not use (yes i have 1 system i don't use for virtual console games/dsi, so no need for AGB/TWL patches)
- etc...

Thumbs up @chaoskagami

Yes, somebody should redo the uncart, more like @d0k3 style
- NDS support
- Reboot option
- Shutdown option
- Etc...

(but this belongs in another thread anyway )

There's preliminary support for NDS/TWL dumping in one of the forks, but it isn't fully working due to missing security keys, bus protocol and a lot of DS documentation having disappeared over the years, in case you're curious. Technically, uncart has always had support for detecting NTR carts - it just lacks the proper work to dump them.

But yeah, OT.

 

[d0k3]

Gonna switch another O3DSXL system to corbenik as daily CFW this evening!

- I really love the way it uses patches and users can submit there own patches (mysterymachin as example)
- It now has the much needed chainloading!
- BootNTR works great on it!
- Choice of patches you want to use/not use (yes i have 1 system i don't use for virtual console games/dsi, so no need for AGB/TWL patches)
- etc...

Thumbs up @chaoskagami

Yes, somebody should redo the uncart, more like @d0k3 style
+ NDS(i) support
+ Reboot option
+ Shutdown option
+ Etc...

(but this belongs in another thread anyway )

There is a cart dumper in D9 now (just compile from latest commit). It also has a decryptor, and I'm working on getting on the fly decryption working. NDS(i) support is still out of reach, though. But, OT, ikr.

 

[chaoskagami]

There is a cart dumper in D9 now (just compile from latest commit). It also has a decryptor, and I'm working on getting on the fly decryption working. NDS(i) support is still out of reach, though. But, OT, ikr.

Seriously? Neat. But yeah, we're all getting a bit OT here (including me.)

EDIT: Welp, guess I found my new rom dumper. Not using uncart anymore. Nice job as usual. ;P

 

[DjoeN]

Seriously? Neat. But yeah, we're all getting a bit OT here (including me.)

EDIT: Welp, guess I found my new rom dumper. Not using uncart anymore. Nice job as usual. ;P

Yeps, same here, i'm dumping a game right now! Love the full/slim options and dump&decrypt
Bye, Bye ugly uncart

Anyway now back on topic
A question i have in mind since contrib mysterypatcher was introduced and working well.
In theory it should be possible to have user submitted game patches instead of system patches?
Boot into config, enable gamepatch and boot into homemenu and play that game with the patches on?

I'm not asking for it, just something i wanted to ask if possible in theory

 

[chaoskagami]

Yeps, same here, i'm dumping a game right now! Love the full/slim options and dump&decrypt
Bye, Bye ugly uncart

Anyway now back on topic
A question i have in mind since contrib mysterypatcher was introduced and working well.
In theory it ishould be possible to have user submitted game patches instead of system patches?
Boot into config, enable gamepatch and boot into homemenu and play that game with the patches on?

I'm not asking for it, just something i wanted to ask if possible in theory

All patches are applied the same way - they go in the patch folder. There's no logical distinction between the two - which is why I see no need to separate them. Being part of contrib just means that I'll fix it if needed come an incompatible update, and that the patch must be open source.

As long as the patch isn't intended for a sysmodule or the firmware, there's no reason the cache can't be regenerated by an application on the HOME menu and changed on the fly. Not yet implemented, obviously.

But if you're curious, you can (and probably should) use subfolders in the patch folder and chain folder for organization purposes. It goes down the entire tree. There's nothing preventing putting user patches in `/corbenik/patch/user/<whatever>`.

 

[Svaethier]

Is it possible for someone to make a path changer like Luma has for this so I can boot this with shadowNAND?

 

[chaoskagami]

Is it possible for someone to make a path changer like Luna has for this so I can boot this with shadowNAND?

The only reason Luma needs a path changer is because the reboot patch reexecutes the arm9loaderhax.bin.

We don't need that here. As long as you keep the /corbenik folder as /corbenik, it doesn't matter where you put the payload. It should already work as-is.

 

[Svaethier]

The only reason Luma needs a path changer is because the reboot patch reexecutes the arm9loaderhax.bin.

We don't need that here. As long as you keep the /corbenik folder as /corbenik, it doesn't matter where you put the payload. It should already work as-is.

Ah, @Shadowhand said for shadownand to boot a cfw besides saltFW you need a pathchanger for it to work :/

 

[chaoskagami]

Ah, @Shadowhand said for shadownand to boot a cfw besides saltFW you need a pathchanger for it to work :/

This is incorrect for CakesFW as well as Corbenik. Neither need a path changer. All you need to do is to rename the arm9loaderhax.bin.

EDIT: Also, looking through the thread he only said that the path changer was needed for Luma.

 

[Shadowhand]

This is incorrect for CakesFW as well as Corbenik. Neither need a path changer. All you need to do is to rename the arm9loaderhax.bin.

EDIT: Also, looking through the thread he only said that the path changer was needed for Luma.

That is correct. Luma expects you to have arm9loaderhax.bin at the root of your SD for reboot patches to work. SaltFW expects either arm9loaderhax.bin, or /homebrew/boot.bin, or /homebrew/SaltFW.bin, therefore working out of the box with ShadowNAND. I have not used any other CFWs, so refer to their guides for reboot patches.