In order to circumvent it, it would cause high brick chances on all 3ds systems. It is modifying the way FIRMs work. They are asking for another 4.2 AKA the update that bricked Wii's of people that don't know the term "homebrew"
Hacking Luma3DS - Noob-proof 3DS Custom Firmware
- Thread starter Aurora Wright
- Start date
- Views 2,752,601
- Replies 19,840
- Likes 261
- Status
You all are so fast with your responses. Thanks much for the info. Is it still best practice to update from Settings, as opposed to waiting for the popup? ... If this is too, "OMG RTFM" then never mind the question and I'll do more reading. 
What I meant is if Nintendo find a way around the FIRM protection AND is able to "fix" it without bricking the console. Otherwise they won't risk another 4.2
AFAIK, yes.You all are so fast with your responses. Thanks much for the info. Is it still best practice to update from Settings, as opposed to waiting for the popup? ... If this is too, "OMG RTFM" then never mind the question and I'll do more reading.
Last edited by Redferne,
I don't mind. Better to do sys settings updates. And make NAND backups before any update.You all are so fast with your responses. Thanks much for the info. Is it still best practice to update from Settings, as opposed to waiting for the popup? ... If this is too, "OMG RTFM" then never mind the question and I'll do more reading.
That is probably true for A9LH but not for the FIRM protection, remember the same way we find vulnerabilities in their software they might find one in ours (by ours I mean all the talented dev of the scene not me
).That is true. They only have to disable write protection (assuming you can do that in arm11). The rest is beyond me. If I was a little older and studied more about ARM execution, I would be able to give a definitive answer.That is probably true for A9LH but not for the FIRM protection, remember the same way we find vulnerabilities in their software they might find one in ours (by ours I mean all the talented dev of the scene not me
Based on what you're telling me, you left the ".bin" off of the filename. However, you don't need to patch it if you're planning to run Luma as your default A9LH payload. It's already set to look for itself as "arm9loaderhax.bin" after all. The only reason you change it is if you want to move it somewhere else, so you can use another chain loader to launch it. For the sake of keeping this short, let's just say I have a personal preference for BootCTR9, without going into why (they all do a decent job, but, it's the little things). So, I have BootCTR9 as my "arm9loaderhax.bin" file, which then loads Luma as a default from "a9lh/payloads/Luma3DS.bin".
Anyway, now you see how the system responds when the reboot patches aren't working. Though you could tell they were working before because GBA games ran. What you described before reminds me of the time I restored the wrong TWLN backup, but I was able to fix it with a complete SysNAND restore. Since all attempts to restore your TWLN partition have failed, it seems like there must be a block that's gone bad or something. If that is the case, reformatting the system might fix it, but I'm just guessing at this point. I'm no expert on the 3DS file systems. Maybe someone more familiar with these partitions, and the TWL system in particular, can help you, like TuxSH or d0k3. If this was a normal case of TWLN bricking, the attempts to restore the partition should have worked. Maybe one of those guys can come up with a way to build a working TWLN partition from scratch or something.
That would require completely new hardware for them to do. The update from 10.7 to 11 proved that Nintendo can't patch out A9LH and that the protection works.
The only way for them to remove it, is for them to physically go to your house and remove it.
There's also no physical way for them to remove it without bricking your system because of the code used is console specific. Patching that code would require to be overwritten at boot level, which a system update can't do and still not be possible to do without bricking your system.
It sounds like a payload issue. Why not make it easier and download a pre-patched payload from this site?
http://luma3ds.ericchu.net/
Or update using this app?
http://gbatemp.net/threads/release-starupdater-a-luma3ds-updater.427999/
Last edited by The Catboy,
I have a question, purely from a technical point of view, would Luma (or any other CFW for that matter) have the possibility to redirect a file to be read from the SD-card instead of the NAND? I ask because I wondered if it might be possible for future CFWs to load certain custom files like .bcfnt font files from the SD-card. That way we could mod the HomeMenu on the fly without having to flash anything to the NAND. For the record I'm no dev and I know things are always much more complicated than it seems, I'm only asking out of technical-curiosity.
Last edited by SkyDX,
- Joined
- Feb 9, 2009
- Messages
- 939
- Trophies
- 0
- Age
- 33
- Location
- Mom's Basement
- Website
- www.youtube.com
- XP
- 418
- Country
I've done system formats before after installing Luma. In fact, it was one of the first things I tried.
I've tried:
Deleting specific installed titles pertaining do DS mode and running an update.
Restoring TWLN.bin from an earlier SYS_NAND.bin
TinyFormat format
System Menu Format System Memory
Patching the arm9loaderhax.bin
It's fine. I have my new3DS if I wanna play DS games. I have my DSi if I wanna use my Acekard2i. If my Acekard2i ever fails, there's always DesMuMe on my PC. I've done all the things that I can do, followed all the tutorials. I don't see how actually restoring my SYSNAND-Original.bin, then extracting the TWLN.bin then flashing back the my current SYSNAND.bin and injecting the TWLN.bin from the old one will fix anything if I already tried to do so using GodMode9 from a mounted SYSNAND.bin backup file.
As long as there isn't some annoying Anti-Piracy in Pokemon Sun and Moon when they get leaked, I'll be content.
On part 5 of the guide where I restore sysnand from emunand original.bin and after i have done this i get a black screen (n3ds). i can access luma and hg9 though, any help?
In Part 5 Section 6 Part7...I can't boot into the CFW SysNAND..I tried it many times... eventhough I've restored the NAND and begin at start.... Plz help me.....
I had the same problem and used luma 5.2 to set up then updated to 5.5 when removing rednand.
Could someone please help me?
I have a N3DS with A9LH installed and a sysNAND 11.0
For some reason, I started having issues booting into sysnand today, it started hanging at the splash screen two times and other two times after the splash screen, but it was stil booting up.
Now all of the sudden, it has stopped booting at all.
The Luma/A9LH payloads are working just fine, all but Hourglass9 which prompts a Key X, Key Y Not Found and fails to initialize.
I can't recall doing anything that might fuck up booting up to sysnand.
All I did before that was:
I already did the following:
https://github.com/Plailect/Guide/w...n-sysnand-boot-after-installing-arm9loaderhax
At point 4, I press A and the console does turn off, so that means I am not bricked, but what is it then?!
I had the noscreen+screeninit newest A9LH commit (which merges both) working and my system could boot without the SD, but now it doesn't boot, not even without the SD inserted. :/
Please, please help me out! T-T
I have a N3DS with A9LH installed and a sysNAND 11.0
For some reason, I started having issues booting into sysnand today, it started hanging at the splash screen two times and other two times after the splash screen, but it was stil booting up.
Now all of the sudden, it has stopped booting at all.
The Luma/A9LH payloads are working just fine, all but Hourglass9 which prompts a Key X, Key Y Not Found and fails to initialize.
I can't recall doing anything that might fuck up booting up to sysnand.
All I did before that was:
- Updated Decrypt9, Hourglass9 and SafeA9LH .bin files (updated HG9 because I was having the keys not found issue previously too). I also copied both arm9 and arm11 .bin files of SafeA9LH into the root directory.
- Renamed the payloads to boot through the four directional buttons instead of X, Y, Start, etc.
- Dumped FBI 2.3.1 (injected into H&S) and injected the newest FBI 2.3.3 into it.
I already did the following:
https://github.com/Plailect/Guide/w...n-sysnand-boot-after-installing-arm9loaderhax
At point 4, I press A and the console does turn off, so that means I am not bricked, but what is it then?!
I had the noscreen+screeninit newest A9LH commit (which merges both) working and my system could boot without the SD, but now it doesn't boot, not even without the SD inserted. :/
Please, please help me out! T-T
Last edited by ShadowOne333,
Put this on the SD Root and see if the Key X, Key Y problem stills stay there.
https://mega.nz/#!lhMnnDRJ!1ss7wJNU6ep02nCzEBHLytZd6he79UAnvq7G9hzL2uk
Well Hourglass9 is now booting up properly.
However, the main issue still persists, I am unable to enter sysnand. :/
Not even without the SD since I use the merged a9lh.
I already tried that.
It's the first point the Troubleshooting page.
I alreayd went through all points in that page and still nothing. :/
However, apparently the guide says that if at Step 4 the 3DS reboots when I press A, then I'm not bricked, and that's what I get.
- Status
Similar threads
-
- Portal
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
BigOnYa:
Caller -"Everytime I start a Pc game on my S24, playing on a external monitor, someone calls or texts me, n it kicks me out of the game." Customer Support - Click (hangs up)+1 -
-
-
-
-
-
-
@
BigOnYa:
I found it funny cause many many years ago, had a roommate in college that did this same dumbass branding of the school logo, but it didn't look anything like it after it healed. Just looked like a birthmark.
-
-
