Hacking I've heard closing a n3DS on 2.1 bricks it... why is this?

[CeeDee]

In the A9LH process, you'd usually need to downgrade to 2.1 to get an OTP, even on n3DS.
But I've seen warnings not to close the n3DS on 2.1, or else it'll brick.

Why is this, technically? Does something break Sleep Mode? Why would this cause a permanent brick, even after rebooting the system?

 

[Cuphat]

I don't think anyone knows the exact answer, but some sleep mode process happens to brick the N3DS. Given that 2.1 is only meant for the original 3DS, and the N3DS didn't exist yet, getting 2.1 to work at all on the N3DS is a feat in itself.

 

[Ryccardo]

I don't think anybody actually tried to figure it out scientifically (by dumping xorpads and nand before and after), but very likely it's caused by the automatic updates - by the time you're supposed to get the nag, the files are already in place and just a commit step is needed, and it is known that you can't run o3ds operating systems since around 7.x on n3ds, but maybe just having the not-so-inactive files is enough to screw it up...

Anyway, it's most likely not the standby, but a side effect (automatic updates)

 

[ih8ih8sn0w]

Like the above people said about it being unknown, but I've heard that it could be caused by an invalid mcu state.

 

[Sketchy1]

Just as the above people stated, its prolly cause the n3ds didn't exist yet, therefore the software believes its running on an o3ds.

Or maybe it could be the fact that it literally has 2 extra processors, and the o3ds software dosent know how to use them when it goes to sleep?

 

[gnmmarechal]

I don't think anybody actually tried to figure it out scientifically (by dumping xorpads and nand before and after), but very likely it's caused by the automatic updates - by the time you're supposed to get the nag, the files are already in place and just a commit step is needed, and it is known that you can't run o3ds operating systems since around 7.x on n3ds, but maybe just having the not-so-inactive files is enough to screw it up...

Anyway, it's most likely not the standby, but a side effect (automatic updates)

Pretty sure it isn't a NAND brick.

 

[Jayro]

You're only in 2.1 for a few seconds, so I really find it to be a non-issue.

 

[Ryccardo]

the o3ds software dosent know how to use them when it goes to sleep?

Just entering standby isn't the problem, you have to leave it there for a while (how much is "a while"? more than 10 seconds, personal experience)

 

[Sketchy1]

Pretty sure it isn't a NAND brick.

+1, if it wasn't, it wouldn't be a problem as you could still boot decrypt/hourglass 9

 

[gnmmarechal]

+1, if it wasn't, it wouldn't be a problem as you could still boot decrypt/hourglass 9

I heard it was similar to the LED bricks (MCU brick, was it?).

 

[Sketchy1]

Just entering standby isn't the problem, you have to leave it there for a while (how much is "a while"? more than 10 seconds, personal experience)

Then perhaps its maybe all the changed hardware. Bigger screen should = display issues right?
Edit:
I know it has nothing to do with it, its asleep Lil. Just spurting random stuff atm

 

[gnmmarechal]

Then perhaps its maybe all the changed hardware. Bigger screen should = display issues right?

It's not because it is "bigger". The o3DS XL has a large display. Also, the New3DS has the same resolution as the old one.

 

[Jayro]

Then perhaps its maybe all the changed hardware. Bigger screen should = display issues right?
Edit:
I know it has nothing to do with it, its asleep Lil. Just spurting random stuff atm

Nah, even the 2DS had a top screen issue of a stretched/glitched image in 2.1

 

[Sketchy1]

It's not because it is "bigger". The o3DS XL has a large display. Also, the New3DS has the same resolution as the old one.

Lml ik, plus display wouldn't matter as it only bricks while asleep lol

 

[gnmmarechal]

Nah, even the 2DS had a top screen issue of a stretched/glitched image in 2.1

That is to be expected, though. That's because of the system not knowing how to deal with the lack of 3D, and doesn't do anything wrong, too.

 

[Sketchy1]

Then let's try and break it down now.
First off, what exactly does a 3ds do when we put it to sleep?
Let's research RN what technical things actually happen

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

That is to be expected, though. That's because of the system not knowing how to deal with the lack of 3D, and doesn't do anything wrong, too.

Plus if I'm not mistaken, downgrading to 2.1 on a 2ds then formatting causes a "brick", as you can't get past setup without putting the 3d slider all the way up. This also applies to any FW below 6.x

 

[gnmmarechal]

Then let's try and break it down now.
First off, what exactly does a 3ds do when we put it to sleep?
Let's research RN what technical things actually happen

https://www.3dbrew.org/wiki/IRU:SetSleepModeActive
https://www.3dbrew.org/wiki/MCUHWC:SetPowerLEDPattern

https://www.3dbrew.org/wiki/MCU_Services

 

[Sketchy1]

Dang, phone battery dying brb, didn't get to read everything in the third link.
From what got to read, perhaps its an MCU error causing the bricks when the system enters sleep?

 

[Cuphat]

+1, if it wasn't, it wouldn't be a problem as you could still boot decrypt/hourglass 9

If you're on a N3DS on 2.1, you don't have A9LH yet and the only way to launch Decrypt9 would be via the browser on 2.1. If you made it to installing A9LH, your next step is to immediately restore your backup.

 

[Hozu]

I read somewhere that someone thinks it may have to do with "invalid" streetpass data. If that's the case, nothing can be done about that because wireless needs to be on to do the exploit for the OTP.