Hacking N3DS XL Bricked when updating

[Quantumcat]

This part, we should ask OP or anybody who has bricked, if they feel the same way about it as you do.

As it stands now, nothing can go wrong with menuhax if you have taken precautions to prevent accidental updates. Can't say the same about a9lh but I'm sure it will get safer, with Aurora and other devs looking into it.

In any case, menuhax or a9lh, I think it would be safer running all cias and homebrew, updates and online access to emuNAND.

We have established that things CAN go wrong, and no matter how little that chance is, it compounds because you have to avoid it every time you touch your system.

 

[xtheman]

You know you guy recommend menuhax but tbh just using emunand with a9lh is safer.

 

[satan89]

We have established that things CAN go wrong, and no matter how little that chance is, it compounds because you have to avoid it every time you touch your system.

What specifically are you saying can go wrong everytime a menuhax 3ds is touched? All you have to do is be more aware of updating on the day an update is released. It doesn't happen everyday.
As for regularly running an updated emuNAND via menuhax daily, how exactly does this put the console at any risk?
Even if someone mistakenly boots into sysnand, he has to notice his missing installed games and homebrew, his different theme, his blocked WiFi, and other things that make sysNAND different from emuNAND and he can get back to emuNAND.

 

[naddel81]

EmuNAND uses WiFi info from sysNAND and vice versa. You can't stop sysNAND from downloading updates that way

that is not true. unlinked sysnand has nothing to do with emunands settings at all.

 

[ThisIsDaAccount]

This is for 10.7 downgraded N3DS XL NTSC-U and N3DS LL NTSC-J
1) NO (This is a myth)
2) 6.3.1
3) N3DS XL + LL
4) Luma was on SD Card

This is for 11.0 DSiWarehax downgraded N3DS XL NTSC-U
1) NO
2) 6.6
3) N3DS XL
4) Luma was on SD Card

I don't trust this witch hunt of Luma... Let's help put this myth of bricking while updating caused by Luma + A9LH to rest!

Yeah, I'm not knowledgeable about these things but I doubt Luma is the cause here. I was just wondering if it had happened to anyone that had put it on their CTRNAND, because some of the bricks make it seem like the system is completely unable to detect the payload (which wouldn't happen if it's on the CTRNAND).

 

[Deleted User]

Yeah, I'm not knowledgeable about these things but I doubt Luma is the cause here. I was just wondering if it had happened to anyone that had put it on their CTRNAND, because some of the bricks make it seem like the system is completely unable to detect the payload (which wouldn't happen if it's on the CTRNAND).

There was a post with someone that had the same problem as OP but didn't have the arm9loaderhax.bin in the ctr NAND and he was on a old 3ds,so he didn't get bricked,he just lost a9lh.

 

[Alex658]

Yeah true, but that's not really an argument, we are talking actual human errors causing an update (not a brick technically). What if someone decides to delete your a9lh payload backup on your PC? And your SD card gets formatted or lost? These human errors can happen on a9lh as well. We are not discussing that, I'm talking about bricks that happen when you actually follow a guide, like the otpless a9lh and OPs issue like updating when many others haven't had the same problem happening. I'm not complaining about a9lh, I know it's the better hack, but it looks like of late there are some minor issues affecting a handful of people and till those issues are resolved it's probably best not to advertise it as the safest hax.

Also, what I do is keep a different theme for sysNAND(red) and emuNAND(blue or white) so I can tell the difference. Also you forgot to mention how eShop in emuNAND can update sysNAND for menuhax, yeah it's a problem with that.

If you have CTRNAND cfw with a9lh you're still excerpt from that. You would still have firm protections for firm 0/1. The only thing you need to have is the latest version of a9lh+the payload on CTRNAND root. Now please, don't tell me you or ANYONE else can delete that mistakenly. System formats can't even touch these files (afaik), only FBI/Godmode9/BIG payloads can touch the CTRNAND, and before not even FBI could do it.

With OTPless the problem is the key gets hashed in a very timely race, and it's not an exact science. if the race or your SD fail while moving the keys, the console can't decrypt itself anymore. That's my understanding of it. You're not getting the actual OTP, just using it's hash, and it's a really really REALLY short amount of time to do so.

a9lh is not perfect, nor is any entrypoint. It's just an exploit that can be abused to achieve something. It's the CFW's devs that really do the magic here, they are the ones coding the thing you want to be protected using the elevated permissons your entrypoint gave them.

 

[ZeroX504]

1) Did you brick? No
2) What version of Luma were you on? Not sure, updated luma today and didn't see what version I had before...I think I had a version from Thanksgiving if that helps.
2) What type of 3ds do you have? N3DS XL
4) What version of luma (if any) is on your CTRNAND? Luma was on SD Card

I have another N3DS XL and O3DS XL that need to be updated, I will post tomorrow to let you guys know how the update goes.

 

[Xiphiidae]

For everyone who updated:

1) Did you brick?
2) What version of Luma were you on?
2) What type of 3ds do you have?
4) What version of luma (if any) is on your CTRNAND?

1) No.
2) 6.3.1
3) O3DSXL
4) N/A

 

[ZeroX504]

1) Did you brick? No
2) What version of Luma were you on? 6.6
2) What type of 3ds do you have? 2 N3DS XL and 2 O3DS XL
4) What version of luma (if any) is on your CTRNAND? Luma was on SD Card

So far no issues noticed on 4 3DS that I updated so far, 2 O3DS XL and 2 N3DS XL. I performed the DSI Downgrade with one of the N3DS XL.

 

[AniTracks]

So basically I'm screwed without a hardmod?

Seems to be the case IMO. Man, I feel sorry for you :\

 

[linuxares]

Seems to be the case IMO. Man, I feel sorry for you :\

Not 100% true. I seen all suggestions except changing out the arm9loadhax.bin to a totally different one. I hope OP comes back and see this, if for example safea9hlinstaller managed to boot. He can just rename decrypt9.bin to arm9loaderhax.bin and restore his firmware.

 

[Quantumcat]

he has to notice his missing installed games and homebrew,

Did you not see where I explained that there are several things you can do in Settings that will reboot you, and you never see your home menu? Not to mention you may accidentally click OK one day on the update nag (even if it's an 0.00001% chance, it still exists) or a friend or relative might pick up your console without permission one day and update it.

that is not true. unlinked sysnand has nothing to do with emunands settings at all.

You haven't been around here long, have you?
https://gbatemp.net/threads/does-sysnand-share-wifi-settings-with-an-unlinked-emunand.387775/
https://gbatemp.net/threads/unlinked-nands-sysnand-wifi-appeared-on-emunand.382768/
https://gbatemp.net/threads/unlinking-sysnand-emunand-questions.380891/

 

[AniTracks]

Not 100% true. I seen all suggestions except changing out the arm9loadhax.bin to a totally different one. I hope OP comes back and see this, if for example safea9hlinstaller managed to boot. He can just rename decrypt9.bin to arm9loaderhax.bin and restore his firmware.

Ah I see. He'll likely see it anyways. I wouldn't ignore anything in a situation like his.

 

[satan89]

Did you not see where I explained that there are several things you can do in Settings that will reboot you, and you never see your home menu?

You can either update in settings where you can check emu/Ver, or in home menu where you should be able to tell the difference. I am not aware of any other state where you may update accidentally (except eshop)

Not to mention you may accidentally click OK one day on the update nag

There is no update nag if you block off the sysNAND WiFi settings, and keep emuNAND updated.

or a friend or relative might pick up your console without permission one day and update it.

Isn't it just as likely they could manually uninstall a9lh and update sysNAND? I don't know if its possible as I haven't used a9lh yet.

Anyways, with otpless being discontinued by the guide (for the moment at least) it would seem that the only bricks that can happen at a9lh install are by user error only, which makes the guide very safe again. I still think the wisest choice would be a9lh + emuNAND over menuhax + emuNAND. I feel keeping sysNAND as untouched as possible would be safest.

 

[damex]

i have no idea why people are getting such desperate bricks.
i could only recall freezes on homebrew loading (before a9lh. menuhax and others).

i have two n3dsxl ntsc-u. red and black. had more of them but sold.
red belong to girlfriend now and have had otp-less a9lh installed (downgrade to 9.2.0 and two resets/formats through settings). it is using last firmware (ota update) and fresh a9lh/cfw/etc related software installed. everything directly from github.
black have a9lh installed from the time when it just appear. i recently updated it bringing to fresh a9lh/cfw/etc and installed luma to ctrnand. same as red. it was ota updated every single time since then.

important parts:
a9lh - always last update from github.
luma - always last update from github.
nintendo firmware - always last ota update.

before i have had three more consoles with a9lh installed (got rid of them). no problems at'all.
maybe it is the problem with user? maybe people doing something wrong with their systems?

 

[Hyoretsu]

I'm in no way affected by any threats of this kind if I'm using EmuNAND with a9lh+Luma, right?