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

  • Thread starter Thread starter chaoskagami
  • Start date Start date
  • Views Views 287,525
  • Replies Replies 2,153
  • Likes Likes 60
Great CFW. @chaoskagami thank you for all your hard work and tireless effort to add features and fix the issues that pop up. I have no idea what you have in store for this project going forward, I just wanted to say it is rock solid and pretty perfect from my standpoint. Alot of users on here are enjoying and interested in your ideas for it's future.
 
Great CFW. @chaoskagami thank you for all your hard work and tireless effort to add features and fix the issues that pop up. I have no idea what you have in store for this project going forward, I just wanted to say it is rock solid and pretty perfect from my standpoint. Alot of users on here are enjoying and interested in your ideas for it's future.

It was pretty buggy back 0.0.1, but due to the people crashing it in so many ways, most of that has been cleaned up. :)

I'm incapable of breaking the current git state, so I'll make a few more cleanup-ish commits and then release today.
 
NTR doesn't work :(

NTR won't work much longer anyways. It'll probably break on 11.1 due to reliance on old native FIRM. I can't support using NTR in combination with this. You're on your own if you do so regardless.

Anyways, 0.0.10 up. Changelog:

Changelog:

* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience.

Joking aside, here's the real changelog:

* Menu code has been unified. Notably, your cursor will keep its' position when you go in and out of a submenu. Some of the layout of menus has also been generally improved.

* Contributed patch directory added. Anyone who has anything cool they want to share - submit a PR! These are bundled with official releases in the `/corbenik/contrib` directory. Currently, the one patch here is `mysterymachine.vco` which allows using SALT's servers like their official HANS-based code patcher. (Thanks, @Wolfvak!)

* Rate limit keypresses to a human amount. That said, how people were hitting this IDK since I don't actually process the key until it is lifted.

* text/ro/data loading/saving are now separate. This is for a very good reason - combined codebins don't give information about segment size to fix up the current exheader without having an exheader (which with size changes in segments, we need to do)

* Fixed a crash caused by enabling Loader and EmuNAND at the same time.

* Fix a crash caused by enabling step through. That said, this is a temporary fix and only prevents hitting the real bug.
 
NTR won't work much longer anyways. It'll probably break on 11.1 due to reliance on old native FIRM. I can't support using NTR in combination with this. You're on your own if you do so regardless.

Anyways, 0.0.10 up. Changelog:
ok, thanks for your answer ;)

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

It works with 10.2 FIRM, as always.
how to install it in corbenick ?
 
ok, thanks for your answer ;)

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


how to install it in corbenick ?

You just use 10.2 instead of the suggested 11 on README. I can't link it, it's against the rules. You can find it on that iso site, or on Plailect's guide when it still had Cakes.
 
  • Like
Reactions: chronoss
Just one small suggestion. "Saving config." could have some other wording. Like "Config saved" or just something that confirms it's actually saved. :)
 
@chaoskagami You've made a typo
C:
if (channel == TOP_SCREEN)
color = &color_top;
else if (channel == TOP_SCREEN)
color = &color_bottom;

Oh my god. You're right.

Ignore the build guys, I found the bug. I'm fixing it now.
 
NTR won't work much longer anyways. It'll probably break on 11.1 due to reliance on old native FIRM. I can't support using NTR in combination with this. You're on your own if you do so regardless.

Anyways, 0.0.10 up. Changelog:
Nice.
Small feature request, and one that may help with patch making: RAM dumping. Maybe an opcode
Code:
dump YYYY ZZZZ
which dumps to SD Z bytes with offset Y from the current location.

I'd understand perfectly if it were too hard to implement currently (you know, with changes and stuff) but it may help in the future.
 
Last edited by Wolfvak,
Nice.
Small feature request, and one that may help with patch making: RAM dumping. Maybe an opcode
Code:
dump YYYY ZZZZ
, which dumps to SD Z bytes with offset Y from the current location.

I'd understand perfectly if it were too hard to implement currently (you know, with changes and stuff) but it may help in the future.

If we're talking dumping ram while the program is running - no. Once the program is loaded, loader gets out of the way and has no control over it anymore, aside from terminating it and querying its' status. It could be possible to add this as a custom commandbuf call (maybe) but that sure isn't supported by ctrulib, and you would need something NOT an application to call it, like an applet. This comes down to needing resident code that isn't loader somewhere (and I haven't bothered to check whether loader can spawn threads.) The obvious way is to implement an ARM9 thread like Reisyukaku used to do in ReiNAND.

However, if we're talking dumping bits of data just for debug purposes, that I can do. I've been planning to add a scratch register at some point, as well.
 
Last edited by chaoskagami,
If we're talking dumping ram while the program is running - no. Once the program is loaded, loader gets out of the way and has no control over it anymore, aside from terminating it and querying its' status. It could be possible to add this as a custom commandbuf call (maybe) but that sure isn't supported by ctrulib, and you would need something NOT an application to call it, like an applet. This comes down to needing resident code that isn't loader somewhere (and I haven't bothered to check whether loader can spawn threads.) The obvious way is to implement an ARM9 thread like Reisyukaku used to do in ReiNAND.

However, if we're talking dumping bits of data just for debug purposes, that I can do. I've been planning to add a scratch register at some point, as well.
Nope, I meant while the bytecode is being executed. Having one instruction that dumps pre-patch (set) and post-patch would be useful, for example, just to check if they were applied correctly
 
Nope, I meant while the bytecode is being executed. Having one instruction that dumps pre-patch (set) and post-patch would be useful, for example, just to check if they were applied correctly

I can do that, yeah. How would you prefer filenames?

(As an aside - there's also the abort[cond] series of instructions now, so I really don't expect correct application to be an issue.)
 
Last edited by chaoskagami,
Sequentially ("/corbenik/dump/000.bin", "001.bin", "002.bin", etc, perhaps?). The only other way I can think of is using the RNG to set some sort of file name, and it'd be fun, sure... but nah :P

I'll see what I can do. I'll put that under 'developer options' and make it a NOP with the option off, since it has no real effect on the VM's actual execution (e.g. no way to feed that data back in.)

Oh, by the way - loader is now larger than Nintendo's by two units. So we're getting a bit weighty here (not that I care)
 
Last edited by chaoskagami,

Site & Scene News

Popular threads in this forum