Hacking Luma3DS - Noob-proof 3DS Custom Firmware
- Thread starter Aurora Wright
- Start date
- Views 2,747,994
- Replies 19,840
- Likes 261
- Status
Indeed, you're better off disabling it if you don't have EmuNAND. Because it allows you to use firmware.bin without any drawbacks. Luma will boot SysNAND with 10.4 NATIVE_FIRM by default, and 10.2 (or 9.6 on O3DS) when you hold R (for running NTR). So, you can have both if you don't need a 9.2 EmuNAND for GW (if you do, you'll need to turn it back on to boot it with 9.0). It's hard to nail down what this actually does with a short description. It's already been renamed once.
I see, that explains alot
just builded Luma3DS with latest libctru and indeed the same errors,
anyway i'll place my previous libctru back for the time being
I know that feeling, same here, updating is better then gaming
Latest libctru can build both luma3ds and fbi just fine now. Try it
Hello, I've just successfully hacked my Japanese o3DS with a9lh, but I'm currently having problems with my Friend List and Notifications.
Every time I exit either of them it just freezes on the HOME Menu splash screen. Is there some way to fix this?
Every time I exit either of them it just freezes on the HOME Menu splash screen. Is there some way to fix this?
- Joined
- Oct 21, 2005
- Messages
- 5,489
- Trophies
- 0
- Age
- 54
- Location
- Somewhere in this potatoland!
- Website
- djoen.dommel.be
- XP
- 2,857
- Country
Thanks! Saw itLatest libctru can build both luma3ds and fbi just fine now. Try it
, Aurora fixed libctru in her build One more question... I setup the payloads, and I am using Uncart. What good are .3ds files unless you have a multicart like gateway or sky3ds? is there a way to load them without a cart?
Thanks. Was hoping I missed something in my search. Thought maybe someone came up with a direct loader.
Hi guys, working on the A9LH guide here (https://github.com/Plailect/Guide/wiki/Part-3-(RedNAND)) and stuck on the last parts of step three. I'm booting into my Luma3DS RedNAND and trying to update, but it throws an error and restarts without updating. Do I need to have an updated RedNAND to proceed? Thanks!
Not sure if this was intended behavior but after both splash screens show up, the bottom one gets turned off and the upper remains (albeit with scanlines) until home menu boots. I'm using the no-screen init version of A9LH. Aurora's if I'm not mistaken.
- Joined
- Jun 12, 2012
- Messages
- 509
- Trophies
- 1
- Location
- HELL
- Website
- tiduscrying.wordpress.com
- XP
- 2,491
- Country
I'm experiencing the same behavior using the latest commit as well. The screen turns off fine after exiting the config menu, however the splash screen seems to be doing some weird stuff. Like above, it will show both top and bottom splash screens, turn off the screen, then bring back the top screen with some visual glitches until the system fully boots.Not sure if this was intended behavior but after both splash screens show up, the bottom one gets turned off and the upper remains (albeit with scanlines) until home menu boots. I'm using the no-screen init version of A9LH. Aurora's if I'm not mistaken.
You need 9.x native firm. So in other words, boot from an EmuNAND (or SysNAND) with 9.2 or lower.
OK, @Aurora Wright, I have found the real problem. And guess what? It actually has nothing to do with either corrupted or patched TWL_FIRM at all. In fact, patched TWL_FIRM actually seems to work alright, believe it or not.
For one thing, 5.4 apparently only looks at the first .tmd file it finds. In the case of one 3DS, the 00000016.app was present (most up to date version), and it was not corrupt. The problem was that 0000000F.APP was there also. So there were two .tmd files. The problem was that 00000000.TMD referenced the old app, and 00000002.tmd referenced the new one. ReiNAND was having no problems finding the right one, nor was Luma 5.2. Or at least, if they were running the old one, it worked. Luma 5.4 could not find it. So I deleted the old .app and .tmd files using Godmode9, and, problem solved. Just to prove that it wasn't even looking for the right .tmd file, I renamed the 00000002.tmd file to 00000000.tmd. DSiWare still worked just fine in Luma 5.4 after doing that, even though it shouldn't, because the firmware shouldn't be able to find the file now. It correctly broke it in ReiNAND. Which leads me to believe it was using the updated version. Both worked when I renamed it back to 00000002.tmd. So, apparently Luma 5.4 doesn't check the actual installation, it just uses the first .tmd file it finds.
Now, apparently on the other one, the online update failed to install 00000016.app at all, and it was still running 0000000f.app. That, or maybe I actually did reinstall the older version on that one (I definitely didn't on the first one I mentioned, it must have stayed from before the A9LH install, so the "keep A9LH" NAND restore option must have left it). Regardless, the only patched TWL_FIRM I have is the latest version. Surprisingly, "Four Swords" actually runs just fine with that installed. I just installed it for easy extraction via Godmode9, so I could use it in fc/b comparisons to prove my TWL_FIRM had not been patched. I wasn't really expecting it to work with you saying it wouldn't, but it does (though I switched it back to the original just in case there were long-term side effects). Anyway, the 0000000f.app file is definitely not patched. Just an older version. An older version that apparently nothing else has trouble supporting. Now, I know Cakes uses it's own external copy, but ReiNAND 4.0 and Luma 5.2 do not. Neither of them had a problem with it being an older version of TWL_NAND.
So, apparently there is still a TWL problem. It just has fewer symptoms. Well, at least now I know that it had nothing to do with patching or corruption, and that it is not going to be a recurring issue where the compatibility keeps breaking or anything.
My apologies if I sound overly critical. And I hate to be the bearer of bad news. I am merely trying to help the best CFW stay that way. I always recommend Luma3DS over all the rest.
Not yet they haven't. However, Simple CIA Converter is relatively easy. Just put the ROMs in the "roms" folder, run the app, click the button to create the ncchinfo.bin file, save it in the same folder as the app, copy it to your "Decrypt9" folder on SD. Boot Decrypt9, Xorpad Generator Options, NCCH Padgen. When it's done simply turn the 3DS off with L+Start, eject the SD card, copy the .xorpad files in the "Decrypt9" folder to Simple CIA Converter's "xorpads" folder, and click the button to generate the CIAs. Should be done in a few minutes unless you're doing 100 games at a time or something.
If you use a "firmware.bin" file, Make sure "SysNAND is updated" is turned off. Otherwise it will boot SysNAND with 10.2 on an N3DS or 9.6 on an O3DS. It should not hang if it's booting with the 9.0 NATIVE_FIRM. If that's already unchecked, not sure what else to say. It works on my 9.2 EmuNAND in A9LH. Actually, I have BootCTR load it directly through Menuhax, or I use the Gateway CIA. I modified regular BootCTR to use boot_confg2.ini so I can have both (it's easy with a hex editor, the file name is in plain text). Haven't tried to launch it from HBL in a long time. So, maybe try one of those.
For one thing, 5.4 apparently only looks at the first .tmd file it finds. In the case of one 3DS, the 00000016.app was present (most up to date version), and it was not corrupt. The problem was that 0000000F.APP was there also. So there were two .tmd files. The problem was that 00000000.TMD referenced the old app, and 00000002.tmd referenced the new one. ReiNAND was having no problems finding the right one, nor was Luma 5.2. Or at least, if they were running the old one, it worked. Luma 5.4 could not find it. So I deleted the old .app and .tmd files using Godmode9, and, problem solved. Just to prove that it wasn't even looking for the right .tmd file, I renamed the 00000002.tmd file to 00000000.tmd. DSiWare still worked just fine in Luma 5.4 after doing that, even though it shouldn't, because the firmware shouldn't be able to find the file now. It correctly broke it in ReiNAND. Which leads me to believe it was using the updated version. Both worked when I renamed it back to 00000002.tmd. So, apparently Luma 5.4 doesn't check the actual installation, it just uses the first .tmd file it finds.
Now, apparently on the other one, the online update failed to install 00000016.app at all, and it was still running 0000000f.app. That, or maybe I actually did reinstall the older version on that one (I definitely didn't on the first one I mentioned, it must have stayed from before the A9LH install, so the "keep A9LH" NAND restore option must have left it). Regardless, the only patched TWL_FIRM I have is the latest version. Surprisingly, "Four Swords" actually runs just fine with that installed. I just installed it for easy extraction via Godmode9, so I could use it in fc/b comparisons to prove my TWL_FIRM had not been patched. I wasn't really expecting it to work with you saying it wouldn't, but it does (though I switched it back to the original just in case there were long-term side effects). Anyway, the 0000000f.app file is definitely not patched. Just an older version. An older version that apparently nothing else has trouble supporting. Now, I know Cakes uses it's own external copy, but ReiNAND 4.0 and Luma 5.2 do not. Neither of them had a problem with it being an older version of TWL_NAND.
So, apparently there is still a TWL problem. It just has fewer symptoms. Well, at least now I know that it had nothing to do with patching or corruption, and that it is not going to be a recurring issue where the compatibility keeps breaking or anything.
My apologies if I sound overly critical. And I hate to be the bearer of bad news. I am merely trying to help the best CFW stay that way. I always recommend Luma3DS over all the rest.
Not yet they haven't. However, Simple CIA Converter is relatively easy. Just put the ROMs in the "roms" folder, run the app, click the button to create the ncchinfo.bin file, save it in the same folder as the app, copy it to your "Decrypt9" folder on SD. Boot Decrypt9, Xorpad Generator Options, NCCH Padgen. When it's done simply turn the 3DS off with L+Start, eject the SD card, copy the .xorpad files in the "Decrypt9" folder to Simple CIA Converter's "xorpads" folder, and click the button to generate the CIAs. Should be done in a few minutes unless you're doing 100 games at a time or something.
If you use a "firmware.bin" file, Make sure "SysNAND is updated" is turned off. Otherwise it will boot SysNAND with 10.2 on an N3DS or 9.6 on an O3DS. It should not hang if it's booting with the 9.0 NATIVE_FIRM. If that's already unchecked, not sure what else to say. It works on my 9.2 EmuNAND in A9LH. Actually, I have BootCTR load it directly through Menuhax, or I use the Gateway CIA. I modified regular BootCTR to use boot_confg2.ini so I can have both (it's easy with a hex editor, the file name is in plain text). Haven't tried to launch it from HBL in a long time. So, maybe try one of those.
Last edited by Kazuma77,
Don't except "commitlies" to be stable ... especially when Aurora can't test her changes right now (and I still haven't switched to a non-screen-init al9h).
Actually, testing is appreciated.
Last edited by TuxSH,
Turn auto-obtain DNS on in Internet Connections? If you've DNS blocked System Updates, they're going to fail. May sound obvious, but I forgot I did that before. Or you might need to set the correct time and date if you changed it in order to avoid the browser block while downgrading.
Eh... I've linked you to the Gateway troubleshooting for a reason XD
What you described is Gateway which messed up your CTRNAND, and it can be fixed by reinstalling the TWL/AGB/NATIVE FIRM cias (the same version as the latest one) which wipes their folder and recreates it (because FBI first deletes the title and then reinstalls).
And you're mistaken about it using the first, it uses the oldest of the .apps, because the NANDs which have a partial downloaded update (in the background) have two .apps/tmds too, but that's intended behavior, not Gateway crap. So I prefer the (seemingly more common too) intended behavior to fixing Gateway's mess.
Ah, but it wasn't Gateway. It was D9 that kept the old files. Anyone restoring EmuNAND over their SysNAND during the A9LH install process is probably going to run into this, actually. Also, that it lacks compatibility with older versions of TWL_FIRM is an even bigger problem if you ask me. Nothing GW-involved about that. Every other CFW supports 0000000f.app. This does not anymore. You might want to fix that.
Last edited by Kazuma77,
It was a Gateway downgrade. D9 has nothing to do with what you said.
"Also, that it lacks compatibility with older versions of TWL_FIRM is an even bigger problem if you ask me": the older version of TWL_FIRM was in 6.0.0 (from 6.2.0 we have the current version). So yeah, pointless to support it (Luma doesn't even support FIRMs before 7.0.0).
"Every other CFW supports 0000000f.app": other CFWs don't use CTRNAND, you need to provide the firmware bins
- Status
Similar threads
-
- Portal
