Hacking [RELEASE] Kecleon Patch for Luma3DS

[Quantumcat]

How come you didn't just make a fork to start with? Then syncing new changes would be easy.

 

[spkuja]

I just wanted to say thank you for this. It's awesome! I have this installed on my tournament 3DS - as I still wanted it hacked in case of the need in the future

 

[laramie]

@sixtails Could you make the new directory at /Nintendo 3DS? or make an option to have a custom directory in the config file?

 

[sixtails]

How come you didn't just make a fork to start with? Then syncing new changes would be easy.

It was always a fork of Luma3DS in my private repo. I just didn't feel like pushing to a public repo out of lazyness, so I distributed it as a diff. It got a little bit bigger, and I got interested in the idea of building an mpeg-1/2 codec for a video player/screen capture, so I thought I might as well setup a public repo.

@sixtails Could you make the new directory at /Nintendo 3DS? or make an option to have a custom directory in the config file?

Yes, I could do either of those (perhaps randomizing part of the path so it blends in) without too much trouble (hope I don't run out of screen real-estate for options though, lol). Out of curiosity, can you tell me why you'd prefer this over saving the config to CTRNAND?

I looked at the filesystem interface more closely, and it's a bit of a mess that I don't think is worth the effort to rewrite. But I am going to try to improve the loading logic so that it loads all files from the SD card first, and when not found, loads them from CTRNAND. I could try to include the path randomization in the next release.

I just wanted to say thank you for this. It's awesome! I have this installed on my tournament 3DS - as I still wanted it hacked in case of the need in the future

Thanks for the support!

 

[laramie]

It was always a fork of Luma3DS in my private repo. I just didn't feel like pushing to a public repo out of lazyness, so I distributed it as a diff. It got a little bit bigger, and I got interested in the idea of building an mpeg-1/2 codec for a video player/screen capture, so I thought I might as well setup a public repo.



Yes, I could do either of those (perhaps randomizing part of the path so it blends in). Out of curiosity, can you tell me why you'd prefer this over saving the config to CTRNAND?

I looked at the filesystem interface more closely, and it's a bit of a mess that I don't think is worth the effort to rewrite. But I am going to try to improve the loading logic so that it loads all files from the SD card first, and when not found, loads them from CTRNAND. I could try to include the path randomization in the next release.

Well, I have luma3ds on my sd card and your patches in my ctrnand. I just want either it all on my sd card (luma folder if I could) or hidden on my sd card so that way it looks normal. And then I could still have a theme

 

[sixtails]

Well, I have luma3ds on my sd card and your patches in my ctrnand. I just want either it all on my sd card (luma folder if I could) or hidden on my sd card so that way it looks normal. And then I could still have a theme

You can have it all on your SD card (put my arm9loaderhax.bin on the root of the SD card, delete arm9loaderhax.bin on CTRNAND). It will use the /luma forlder by default though.

 

[laramie]

You can have it all on your SD card (put my arm9loaderhax.bin on the root of the SD card, delete arm9loaderhax.bin on CTRNAND). It will use the /luma forlder by default though.

True but then the sd wouldn't be "clean" my goals are to obscure the contents of the sdcard in plain sight.

 

[sixtails]

True but then the sd wouldn't be "clean" my goals are to obscure the contents of the sdcard in plain sight.

Hmm... I'm just trying to understand what kind of setup your goal is... so you want to have everything on your SD card, but you want everything hidden? You can't change the path arm9loaderhax.bin unless you modify the A9LH payload (which I'm not going to recommend). Unless you want arm9loaderhax.bin on CTRNAND and have the config/payloads on the SD card disguised in "/Nindento 3DS"?

Can I suggest putting payloads&config in CTRNAND with arm9loaderhax.bin, so that nothings on your SD card but "/Nintendo 3DS", but you'll still have your payloads and config on CTRNAND?

 

[Xiphiidae]

Hmm... I'm just trying to understand what kind of setup your goal is... so you want to have everything on your SD card, but you want everything hidden?

I believe they want a setup that has nothing on the SD, where the CFW will be solely on the CTRNAND and hence their console will appear unhacked, even if the SD is checked.

 

[Quantumcat]

I believe they want a setup that has nothing on the SD, where the CFW will be solely on the CTRNAND and hence their console will appear unhacked, even if the SD is checked.

That should be what Kecleon provides by default. Not sure what their problem is.

 

[Xiphiidae]

That should be what Kecleon provides by default. Not sure what their problem is.

Then they may want to change the location of their arm9haxloader.bin so that they could have it in the Nintendo 3DS folder (or something so that it's 'hidden'), but the only way of doing this would be to have a CFW on CTRNAND that automatically chainloads a payload at a specified location on the SD.

I don't understand why they don't just use Kecleon on CTRNAND.

 

[laramie]

Hmm... I'm just trying to understand what kind of setup your goal is... so you want to have everything on your SD card, but you want everything hidden? You can't change the path arm9loaderhax.bin unless you modify the A9LH payload (which I'm not going to recommend). Unless you want arm9loaderhax.bin on CTRNAND and have the config/payloads on the SD card disguised in "/Nindento 3DS"?

Can I suggest putting payloads&config in CTRNAND with arm9loaderhax.bin, so that nothings on your SD card but "/Nintendo 3DS", but you'll still have your payloads and config on CTRNAND?

If I did that, luma would detect the sd card and not load the a9lh.bin file from the sd card I think. My goal is to have either a clean sd card with the basic theme and then either have my cfw hidden in the nintendo folder or if the sd card is removed, I can still have a hidden cfw that still boots with if need be my payloads (decrypt9)

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

I believe they want a setup that has nothing on the SD, where the CFW will be solely on the CTRNAND and hence their console will appear unhacked, even if the SD is checked.

yeah pretty much, I like this cfw, I just also like the idea of custom paths. (If it's a set path ex: press select on boot), then well it's known by everyone, it's static, whereas if it's dynamic or a custom path, well they can't accuse you of "hacking" it'd be very hard to make this, but maybe in the config file we could set custom paths for the luma folder or other useful things. Making it harder to find.

 

[Quantumcat]

If I did that, luma would detect the sd card and not load the a9lh.bin file from the sd card I think. My goal is to have either a clean sd card with the basic theme and then either have my cfw hidden in the nintendo folder or if the sd card is removed, I can still have a hidden cfw that still boots with if need be my payloads (decrypt9)

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


yeah pretty much, I like this cfw, I just also like the idea of custom paths. (If it's a set path ex: press select on boot), then well it's known by everyone, it's static, whereas if it's dynamic or a custom path, well they can't accuse you of "hacking" it'd be very hard to make this, but maybe in the config file we could set custom paths for the luma folder or other useful things. Making it harder to find.

If you have Kecleon in your CTR-NAND it will be overridden by an arm9loaderhax.bin on your SD card if there is one. You can set a key combination to launch payloads when Kecleon is active so you really don't need Luma as well. Putting Luma's arm9loaderhax.bin on your SD card is only needed if that's a bit faster than putting in the key combination or you forget it. I don't understand what part of this doesn't fit your needs.

 

[Hakujou]

Okay, somethings wrong with my notifications, this didn't show up at all lol.

I am now hosting the entire project on GitHub instead of using diffs. Also note: the 'master' branch is a mirror of Aurura's Luma3DS repository, while the 'kecleon' branch is used for the changes I've made for Kecleon (this is just to make porting changes between the two easier). Don't use the old patch I posted, as that may require manual merging, such as this case.

I have also just ported over the latest Luma3DS commit to Kecleon.

So for building latest Luma3DS-Kecleon that I've tested, something along the lines of:

git clone https://github.com/sixtails/Kecleon.git
cd Kecleon
git submodule update --init --recursive

git checkout kecleon
git pull https://github.com/sixtails/Kecleon.git kecleon
git submodule update --init --recursive
make

If you wanted to apply the differences against the latest Luma3DS (which may require manual merging):

git checkout kecleon
git pull https://github.com/sixtails/Kecleon.git kecleon
git submodule update --init --recursive
git checkout master
git pull https://github.com/AuroraWright/Luma3DS.git master
git submodule update --init --recursive
git checkout kecleon
git merge master
# You may need to do manual merging here.
make

Hey, thanks a lot for that !
I've tried to build your "kecleon" branch in your repo but here's what I get : https://jenkins.hakujou.fr/job/3DS/job/Luma3DS Kecleon/2/console

Any idea to fix that ?

Thanks again.

 

[sixtails]

Hey, thanks a lot for that !
I've tried to build your "kecleon" branch in your repo but here's what I get : https://jenkins.hakujou.fr/job/3DS/job/Luma3DS Kecleon/2/console

Any idea to fix that ?

Thanks again.

I haven't played with Luma's Makefiles much, but here's what I think.

Here's the line that I find concerning (https://jenkins.hakujou.fr/job/3DS/job/Luma3DS Kecleon/2/console):

arm-none-eabi-gcc -Xlinker --defsym="__start__=0x14000000" -specs=3dsx.specs -mcpu=mpcore -mfloat-abi=hard  -o build/Luma3DS.elf build/romfsredir.bin.o build/patcher.o build/loader.o build/fsldr.o build/pxipm.o build/memory.o source/CFWInfo.s build/srvsys.o build/ifile.o build/fsreg.o build/strings.o -L/opt/devkitPro/libctru/lib -lctru

Let's compare it to this build (https://jenkins.hakujou.fr/job/3DS/job/Luma3DS%20Kecleon/2/console):

arm-none-eabi-gcc -Xlinker --defsym="__start__=0x14000000" -specs=3dsx.specs -mcpu=mpcore -mfloat-abi=hard  -o build/injector.elf build/romfsredir.bin.o build/patcher.o build/loader.o build/fsldr.o build/pxipm.o build/memory.o source/CFWInfo.s build/srvsys.o build/ifile.o build/fsreg.o build/strings.o -L/opt/devkitPro/libctru/lib -lctru

Notice in Luma3DS the output is "injector.elf", where as in Kecleon it's "Luma3DS.elf" which is incorrect. I believe this is because the Makefile isn't capsulating path-strings properly, and somewhere along the line it's incorrectly parsing the space and passing something weird. So try giving the project a name (and path) with no whitespace, such as "Luma3DS-Kecleon".

If I did that, luma would detect the sd card and not load the a9lh.bin file from the sd card I think. My goal is to have either a clean sd card with the basic theme and then either have my cfw hidden in the nintendo folder or if the sd card is removed, I can still have a hidden cfw that still boots with if need be my payloads (decrypt9)

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


yeah pretty much, I like this cfw, I just also like the idea of custom paths. (If it's a set path ex: press select on boot), then well it's known by everyone, it's static, whereas if it's dynamic or a custom path, well they can't accuse you of "hacking" it'd be very hard to make this, but maybe in the config file we could set custom paths for the luma folder or other useful things. Making it harder to find.

Sorry, I welcome new idea's and bugs, and would implement them if I see people benifit from it. But I'm having difficulty understanding what this would be good for, and I think we may already have what you're looking for. If not, maybe I could have some information about your situation to best figure out how to address it?

You can have a 100% clean SD card by keeping my arm9loaderhax.bin on your CTRNAND. Then you can delete everything but your "Nintendo 3DS" folder on your SD card, and set the config to save to CTRNAND. This also allows your console to boot without an SD card. This works as long as you have a relatively up to date A9LH payload (ie, used safe9lhinstaller after Oct 17th, 2016).

If you wanted to restore your homebrew stuff later without using an EmuNAND, I suppose you can put GodMode9/Decrypt9/etc in "/rw/luma/payloads" on CTRNAND, and save your secret stash of homebrew stuff somewhere in "/Nintendo 3DS" on your SD card.

Though, you'll also deal with uninstalling/reinstalling CIAs, backing up saves, changing theme, removing stickers, changing suspicious layouts, deleting stuff in the Activity log, moving all folders to stash, etc... which is why EmuNAND/2 SD cards is nicer for people who goto weekly tourny's.

 

[Hakujou]

Nice catch ! Removing the space fixed the error !

 

[laramie]

I haven't played with Luma's Makefiles much, but here's what I think.

Here's the line that I find concerning (https://jenkins.hakujou.fr/job/3DS/job/Luma3DS Kecleon/2/console):

arm-none-eabi-gcc -Xlinker --defsym="__start__=0x14000000" -specs=3dsx.specs -mcpu=mpcore -mfloat-abi=hard  -o build/Luma3DS.elf build/romfsredir.bin.o build/patcher.o build/loader.o build/fsldr.o build/pxipm.o build/memory.o source/CFWInfo.s build/srvsys.o build/ifile.o build/fsreg.o build/strings.o -L/opt/devkitPro/libctru/lib -lctru

Let's compare it to this build (https://jenkins.hakujou.fr/job/3DS/job/Luma3DS%20Kecleon/2/console):

arm-none-eabi-gcc -Xlinker --defsym="__start__=0x14000000" -specs=3dsx.specs -mcpu=mpcore -mfloat-abi=hard  -o build/injector.elf build/romfsredir.bin.o build/patcher.o build/loader.o build/fsldr.o build/pxipm.o build/memory.o source/CFWInfo.s build/srvsys.o build/ifile.o build/fsreg.o build/strings.o -L/opt/devkitPro/libctru/lib -lctru

Notice in Luma3DS the output is "injector.elf", where as in Kecleon it's "Luma3DS.elf" which is incorrect. I believe this is because the Makefile isn't capsulating path-strings properly, and somewhere along the line it's incorrectly parsing the space and passing something weird. So try giving the project a name (and path) with no whitespace, such as "Luma3DS-Kecleon".



Sorry, I welcome new idea's and bugs, and would implement them if I see people benifit from it. But I'm having difficulty understanding what this would be good for, and I think we may already have what you're looking for. If not, maybe I could have some information about your situation to best figure out how to address it?

You can have a 100% clean SD card by keeping my arm9loaderhax.bin on your CTRNAND. Then you can delete everything but your "Nintendo 3DS" folder on your SD card, and set the config to save to CTRNAND. This also allows your console to boot without an SD card. This works as long as you have a relatively up to date A9LH payload (ie, used safe9lhinstaller after Oct 17th, 2016).

If you wanted to restore your homebrew stuff later without using an EmuNAND, I suppose you can put GodMode9/Decrypt9/etc in "/rw/luma/payloads" on CTRNAND, and save your secret stash of homebrew stuff somewhere in "/Nintendo 3DS" on your SD card.

Though, you'll also deal with uninstalling/reinstalling CIAs, backing up saves, changing theme, removing stickers, changing suspicious layouts, deleting stuff in the Activity log, moving all folders to stash, etc... which is why EmuNAND/2 SD cards is nicer for people who goto weekly tourny's.

Oh... I didn't know this was a thing... I'm sorry >.< question then, could I copy things like plugins folder and ntr.bin to ctrnand? I don't want top mess up my ctrnand.... but are those things just put in ro/ ?

 

[sixtails]

Oh... I didn't know this was a thing... I'm sorry >.< question then, could I copy things like plugins folder and ntr.bin to ctrnand? I don't want top mess up my ctrnand.... but are those things just put in ro/ ?

Most homebrew will not work from CTRNAND, including NTR. You could have an SD card for tournaments, and an SD card for everything else though. The "full" setup is to have an emunand as well, which is what the guide gives you in the first post.

 

[laramie]

Most homebrew will not work from CTRNAND, including NTR. You could have an SD card for tournaments, and an SD card for everything else though. The "full" setup is to have an emunand as well, which is what the guide gives you in the first post.

I most likely will do that anyways, or I might edit source code for custom paths with things like ntr boot selector. That's if I could get it to boot from ctrnand...

 

[sixtails]

I most likely will do that anyways, or I might edit source code for custom paths with things like ntr boot selector. That's if I could get it to boot from ctrnand...

When did you install a9lh? If it's too old, then it wont be able to boot from CTRNAND. Other then that, I can't see why boot from NAND doesn't work.