Homebrew Is it possible to recover from a bricked 2ds after installing arm9loaderhax?

[MadMageKefka]

.... did you even read my post? If NATIVE_FIRM is bricked, recovery mode doesn't work, since the system calls NATIVE_FIRM first.

A9LH doesn't even touch recovery mode.... it touches the firm....

That makes no sense.... an update will update the NATIVE_FIRM like you said, but the ENTIRE POINT of recovery mode is to fix a failed update. If failing to update breaks recovery mode..... that would be just plain stupid.

 

[Genitez]

Isn't aeskeydb.bin meant to be at the root of the card instead of /luma/payloads/ ?

tried changing position to that,nothing changes.

 

[gnmmarechal]

That makes no sense.... an update will update the NATIVE_FIRM like you said, but the ENTIRE POINT of recovery mode is to fix a failed update. If failing to update breaks recovery mode..... that would be just plain stupid.

it's what happens. Which is why downgrading has a risk of hardbricking as well, if the downgrade fails while it is flashing the new NATIVE_FIRM, you won't be able to boot recovery. Recovery NEEDS a working NATIVE_FIRM to even boot.

 

[MadMageKefka]

it's what happens. Which is why downgrading has a risk of hardbricking as well, if the downgrade fails while it is flashing the new NATIVE_FIRM, you won't be able to boot recovery. Recovery NEEDS a working NATIVE_FIRM to even boot.

https://www.3dbrew.org/wiki/FIRM#SAFE_MODE_FIRM

Doesn't safe mode use SAFE_MODE_FIRM?

 

[gnmmarechal]

https://www.3dbrew.org/wiki/FIRM#SAFE_MODE_FIRM

Doesn't safe mode use SAFE_MODE_FIRM?

No idea, but the system doesn't boot at all without NATIVE_FIRM working. That much I can assure you. is SAFE_MODE_FIRM called by NATIVE_FIRM?

 

[MadMageKefka]

No idea, but the system doesn't boot at all without NATIVE_FIRM working. That much I can assure you. is SAFE_MODE_FIRM called by NATIVE_FIRM?

I'm no dev, I don't fully understand the inner workings of the 3DS. I thought recovery mode and its FIRM were kept separate as a failsafe, but after reading your posts I looked into it some and I am seeing a couple reports of downgrading breaking recovery mode, like you said. I am curious as to what exactly is going on with recovery mode and downgrading now because this seems like an insanely obvious design flaw.... either way this topic is derailing a bit. If you find out more about how recovery mode works though, please do send me a message, I'm legit curious now.

@Genitez I'm sorry, but you will have to send it back to Nintendo and have them fix / replace it for you for a fee. Just tell them you closed the lid or shut off the power during an update on accident, and now it won't boot.

 

[gnmmarechal]

I'm no dev, I don't fully understand the inner workings of the 3DS. I thought recovery mode and its FIRM were kept separate as a failsafe, but after reading your posts I looked into it some and I am seeing a couple reports of downgrading breaking recovery mode, like you said. I am curious as to what exactly is going on with recovery mode and downgrading now because this seems like an insanely obvious design flaw.... either way this topic is derailing a bit. If you find out more about how recovery mode works though, please do send me a message, I'm legit curious now.

@Genitez I'm sorry, but you will have to send it back to Nintendo and have them fix / replace it for you for a fee. Just tell them you closed the lid or shut off the power during an update on accident, and now it won't boot.

yep, it's a stupid decision imo. Anyway, @Genitez , you'll need to do that, tell them the system didn't boot after an update.

 

[Zan']

if i remember correctly i powered off by pressing down the power button WHEN the installation was complete and it was rebooting,because i knew if it rebooted it was pointless and it was just black screen as normal.. i don't think it was the reason

with the sd folder i messed a little,changing various arm9loader and payloads,but i always putted the originals back after the test with different arm9loader.bin


for answering you questions,loading arm9loaderhax did had like 2 or 3 freeze during installation on the webpage of the 2ds,then i retried another time and it worked fine,then i shut down manually as i said. i'm 99% that it was complete and it was rebooting itself.

i certanly used the 2.0 installer

i already tried to delete the config from the luma folder before,as i readed in another thread (For information,ths 2ds now can't even do the up+L+R+a trick to recover,just a black screen without even the light coming in life,and of course the blue light led of power)

tried the decrypt9 trick you mentioned,but nada.still black screen. (do i have to put in the name of the "x_D9.bin" the .bin part or just x_D9? i already tied both and nothing)

while i was searching for some answers i seen someone having this "rei" folder that i didn'thad,and i created it manually copying the files the others had in there... so that rei is not a correct installation but a copy of what seemed to be missing

for the luma installation and other files,as i remember, i never downloadedsome latest release,as the were literally from a bunch of days ago,and i wanted the latest files before those super recent ones,because the guide is some months old and i wanted the exact same files to be sure it would run all as expected.



the screen of my sd card https://postimg.org/image/6wj59xhsh/

In that case you most likely bricked your FIRM by using mismatching versions.
A9LHInstaller would say it was successful, since it did exactly what it should, but due to providing incompatible files you would end up writing the wrong things to the wrong sectors, which would end up messing up your FIRM and therefore get stuck on boot.

Also before anyone says you can brick following the guide. This is entirely user error and if he would actually have followed the guide and used the files provided he wouldn't have had this problem.
The Guide is updated nearly every day and if important things happen that would cause users to brick, it is adapted in no time.

You may have a chance sending it in, just telling them you wanted to update and it shutdown mid update. Because this is a very unlikely brick, which can occur in the updating process.
And I highly doubt they'd go through the NAND to check the exact cause of this to "proof you wrong". They'll probably just reflash it.

 

[Xenon Hacks]

Seriously just return it to gamestop you people are over thinking things the person working at the counter gives two shits about what happened to it.

 

[ChaosRipple]

I understand that, and I do have auto menuhax + Luma3DS set up. I like it alot, and correct me if I'm wrong, but isn't emuNAND just as safe from Nintendo as A9LH is? I know A9LH has more advantages over emuNAND, but in terms of being protected from the updates Nintendo sends isn't it about the same?

A9LH and Emunand cannot be compared like that. A9LH is just a way of getting Arm9 code execution during boot and Emunand is a redirection of read/writes to the SD card instead of the nand. A9LH boots either into your Sysnand or your Emunand with the CFW of your choice. As most people do prefer booting into Sysnand with A9LH, I still prefer to boot into Emunand with A9LH.

Oh wow, I didn't hear of that. I'll have to google it now, lol. But that's exactly what I mean. With a 9.2 sysNAND they could in theory mess with your system, whereas with updated sysNAND mode on a9lh, it would be both impossible, and even if they did you could simply restore a previous NAND backup and promptly give Nintendo the finger.

I don't think that's how it works. I'm 99% certain that CFW Sysnand is just as safe as Emunand and vice versa. Emunand protects the entire portion of the nand whereas CFW Sysnand only protects the A9LH portion. Therefore, in theory, if Nintendo could somehow access your Sysnand when you're using Emunand, then Nintendo should also be able to somehow access your A9LH stages in the nand when you're using CFW Sysnand.

 

[gnmmarechal]

A9LH and Emunand cannot be compared like that. A9LH is just a way of getting Arm9 code execution during boot and Emunand is a redirection of read/writes to the SD card instead of the nand. A9LH boots either into your Sysnand or your Emunand with the CFW of your choice. As most people do prefer booting into Sysnand with A9LH, I still prefer to boot into Emunand with A9LH.



I don't think that's how it works. I'm 99% certain that CFW Sysnand is just as safe as Emunand and vice versa. Emunand protects the entire portion of the nand whereas CFW Sysnand only protects the A9LH portion. Therefore, in theory, if Nintendo could somehow access your Sysnand when you're using Emunand, then Nintendo should also be able to somehow access your A9LH stages in the nand when you're using CFW Sysnand.

why would you use EmuNAND if you have A9LH? FIRM is write-protected by A9LH during boot afaik, they can't change it with an update afaik.

 

[ChaosRipple]

why would you use EmuNAND if you have A9LH? FIRM is write-protected by A9LH during boot afaik, they can't change it with an update afaik.

Call it OCD or something, it irks me to feel like my Sysnand is partially 9.2 and partially fully updated. And Nintendo probably can't fix the read/write redirection/protection. We have full Arm9 access and will have a way around whatever they attempt do to patch it out, especially with A9LH since it's super early within the boot.

 

[gnmmarechal]

Call it OCD or something, it irks me to feel like my Sysnand is partially 9.2 and partially fully updated. And Nintendo probably can't fix the read/write redirection/protection. We have full Arm9 access and will have a way around whatever they attempt do to patch it out, especially with A9LH since it's super early within the boot.

lel, all right.

 

[Deleted User]

Hey, I hope I'm not too late to reply to this thread. You said you were using the non-screeninit version? Personally, I actually had problems with that (exactly like you said, black screen when powering on), So I used the SafeArm9installer v2 to install the screeninit version and everything worked fine. I hope this helps you and that I replied in time!

 

[N7Kopper]

It's kinda obvious... There's no way to brick your recovery mode without attempting to mod the system. The whole point of recovery mode is to be a failsafe. But so long as you're paying for the repair, I doubt they will care.

Electrical damage could do that. Even if SAFE_MODE_FIRM didn't need NATIVE_FIRM to boot, one poorly-done charger port fix from the big N could fry your NAND chip, or at least corrupt it.
yes I am talking from personal experience why do you ask?
at least they fixed it free-of-charge that time, still lost some really sentimental pictures and my streetpass mii plaza progress
and my friend list

 

[MadMageKefka]

Electrical damage could do that. Even if SAFE_MODE_FIRM didn't need NATIVE_FIRM to boot, one poorly-done charger port fix from the big N could fry your NAND chip, or at least corrupt it.
yes I am talking from personal experience why do you ask?
at least they fixed it free-of-charge that time, still lost some really sentimental pictures and my streetpass mii plaza progress
and my friend list

Electrical damage causing problems is kinda obvious..... That's a very rare case scenario though. You're not wrong... I'm just saying you take the same risk with literally any electrical device.