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

  • Thread starter Thread starter chaoskagami
  • Start date Start date
  • Views Views 284,025
  • Replies Replies 2,153
  • Likes Likes 60
You don't have to use NTR to use the remove the outline or the mystery machine patch, so both work on O3DS and N3DS
NTR wasn't used to remove the outline, it was used to take the screenshot. I guess I didn't really clear that up in my post
 
So all the patches work, ect ect. Nothing broken. What I was more interested in was the "Remove Outline" in Pokemon S/M. So of course I had to setup NTR to take some screenshots and to properly show it working. Which was nice because I ran into the same battle both before and after the patch was applied

I also tested the patch on an old3DS to see if it would actually work. Which I am pleased to say, it does indeed work on an old3DS as well. So reboot patches and the remove outline patch do not conflict with each other and will work on an old3DS.

These tests we preformed on an actual physical copy of the game and both systems are running the latest OFW.
Here's the screenshots from my new3DS

Thank @Gray_Jack and @Kitlith for porting the S&M stuff (god, we need a better abbreviation for Sun/Moon.) That was 100% them.

Also, reboot and individual loader patches literally can't conflict. They're not the same thing at all. If an application patch failed, you'd be stuck at the 3DS logo. And if reboot and loader conflicted...the OS would never boot.
 
Thank @Gray_Jack and @Kitlith for porting the S&M stuff (god, we need a better abbreviation for Sun/Moon.) That was 100% them.

Also, reboot and individual loader patches literally can't conflict. They're not the same thing at all. If an application patch failed, you'd be stuck at the 3DS logo. And if reboot and loader conflicted...the OS would never boot.
Then I would like to properly thank those two! Because it's an interesting feature.
And I kind of figured they wouldn't conflict with each other, but I like to test everything. I was more worried that it won't work on the old3DS.
 
Can someone give me the latest commit compiled?
I still cannot get rid of the segmentation fault error T-T

This is going to sound borderline nonsense, but I got makerom segv'ing after rebuilding devkitpro on a fresh gentoo install. After stepping through the crash, it seemed libyaml was doing something fucky with libc. Unbundling and compiling against my system libyaml fixed it.

Code:
--- a/makerom/Makefile
+++ b/makerom/Makefile
@@ -1,5 +1,5 @@
# Sources
-SRC_DIR = . polarssl libyaml
+SRC_DIR = . polarssl
OBJS = $(foreach dir,$(SRC_DIR),$(subst .c,.o,$(wildcard $(dir)/*.c)))
# Compiler Settings
@@ -18,7 +18,7 @@ else
  else
  # Linux
  CFLAGS += -Wno-unused-but-set-variable
-  LIBS +=
+  LIBS += -lyaml
  endif
endif
--- a/makerom/yaml_parser.h
+++ b/makerom/yaml_parser.h
@@ -1,6 +1,6 @@
#pragma once
-#include "libyaml/yaml.h"
+#include "yaml.h"
typedef enum
{

EDIT: gbatemp kinda wrecked the patch formatting, but it's not that hard to manually edit the files.
 
Last edited by chaoskagami,
This is going to sound borderline nonsense, but I got makerom segv'ing after rebuilding devkitpro on a fresh gentoo install. After stepping through the crash, it seemed libyaml was doing something fucky with libc. Unbundling and compiling against my system libyaml fixed it.

Code:
--- a/makerom/Makefile
+++ b/makerom/Makefile
@@ -1,5 +1,5 @@
# Sources
-SRC_DIR = . polarssl libyaml
+SRC_DIR = . polarssl
OBJS = $(foreach dir,$(SRC_DIR),$(subst .c,.o,$(wildcard $(dir)/*.c)))
# Compiler Settings
@@ -18,7 +18,7 @@ else
  else
  # Linux
  CFLAGS += -Wno-unused-but-set-variable
-  LIBS +=
+  LIBS += -lyaml
  endif
endif
--- a/makerom/yaml_parser.h
+++ b/makerom/yaml_parser.h
@@ -1,6 +1,6 @@
#pragma once
-#include "libyaml/yaml.h"
+#include "yaml.h"
typedef enum
{

EDIT: gbatemp kinda wrecked the patch formatting, but it's not that hard to manually edit the files.

IT WORKS!!!!!
THANKS SO MUCH!!!
I would never think that the problem was the makerom
 
IT WORKS!!!!!
THANKS SO MUCH!!!
I would never think that the problem was the makerom

Y'know, it surprised me too.

Maybe I should file a bug report...
 
You could have Travis build every commit from upstream and upload nightlies as releases on this repo.

You know the reason why I didn't do that? Security. That requires Travis to have commit access, and that requires either A) a github account with push access or B) my github account. In the case of "my github account' I would have to issue a SSH key for Travis, and be prepared for it to be compromised since it would need the private key (which is a big no-no.)

It was the wrong way to do it. Completely.

@chaoskagami
Would be possible to make the chainloader load elf files using libctr9? It's not a request, it's just a curiosity question

Possible? Yeah.

There's a number of things I have to fix before I can update the libctr9 submodule and even start on that, though. There's been a number of API breaks, not to mention the rather nice console subsystem that does most of what draw.c does in a far cleaner manner (but not all of it, sadly.) This is going to be a *really* gradual process.
 
Possible? Yeah.

There's a number of things I have to fix before I can update the libctr9 submodule and even start on that, though. There's been a number of API breaks, not to mention the rather nice console subsystem that does most of what draw.c does in a far cleaner manner (but not all of it, sadly.) This is going to be a *really* gradual process.

Thanks for the info, it's really good to know that. I hope one day it became a feature, not that it will change too much for the end user, but I think elf loading is better than binaries loading (I may be wrong on that).
 
  • Like
Reactions: chaoskagami
Thanks for the info, it's really good to know that. I hope one day it became a feature, not that it will change too much for the end user, but I think elf loading is better than binaries loading (I may be wrong on that).

No, you're not wrong. ELF is a defined standard, and it's been frustrating all along for me to see the 3DS community use hackish file formats like 3dsx and raw binaries. Every other scene uses ELF files. Hell, Linux uses ELF files. It's a well defined and flexible format.
 
I have a Jenkins setup if anyone is interrested, but to be honest, I never configured a 3DS project in it. Any guidelines regarding it ?
It would build at least Corbenik and Luma every time a commit is pushed.
 
Jenkins is up and running, Corbenik is now automatically built.
Just need to purchase an additional domain and setup a server for file delivery (as I don't want to expose Jenkins to everyone because of the users) and it'll be up for everyone.
 
  • Like
Reactions: gnmmarechal

Site & Scene News

Popular threads in this forum