Homebrew ARM9Loader -- Technical Details and Discussion

[subcon959]

Am I the only one that's reluctant to ditch emuNAND? I don't know why it just makes more sense to me to stick with it instead of messing about on sysNAND.

 

[daxtsu]

Am I the only one that's reluctant to ditch emuNAND? I don't know why it just makes more sense to me to stick with it instead of messing about on sysNAND.

I don't blame you. There's no compelling reason to do so yet. Even if emuNAND doesn't end up getting hooks for D9/E9, we can still just reboot into a boot manager and pick them once we have backlights and such.

 

[Urbanshadow]

the title is NATIVE_FIRM... and since the titles check the NATIVE_FIRM version and refuse to boot in certain conditions we can't run 2.1 NATIVE_FIRM with the newer titles

Pfft. Oh. I have a question. If somehow a9lh aureinand supported 2.1 emunand with the 2.X firm, given it boots right away, will the otp be unprotected even it theres a superior version sysnand?
(I know its useless because you would need the otp to grab the otp, but it's nice to know there's a way to re-obtain it easily)

EDIT: What am I saying. It's the otp locked when a9lh arrives?

 

[dark_samus3]

Pfft. Oh. I have a question. If somehow a9lh aureinand supported 2.1 emunand with the 2.X firm, given it boots right away, will the otp be unprotected even it theres a superior version sysnand?
(I know its useless because you would need the otp to grab the otp, but it's nice to know there's a way to re-obtain it easily)

Nope, since once the bit to protect the OTP is set it can't be unset without a full power off and the bit is set very early in FIRM boot on console power on

 

[daxtsu]

Nope, since once the bit to protect the OTP is set it can't be unset without a full power off and the bit is set very early in FIRM boot on console power on

It still gets locked even with A9LH present? That's interesting, I thought it decrypted the FIRM to garbage and then ran our code, which would come before loading another FIRM (which then locks it)?

 

[Tjessx]

Am I the only one that's reluctant to ditch emuNAND? I don't know why it just makes more sense to me to stick with it instead of messing about on sysNAND.

I'm waiting for graphical applications to work in arm9.
Then i will ditch emunand swell.
From that moment we could easily create an unblock application, or a more user friendly boot loader that can boot into something like (forgot the name, Nand format + copy application)

 

[FenrirWolf]

I don't blame you. There's no compelling reason to do so yet. Even if emuNAND doesn't end up getting hooks for D9/E9, we can still just reboot into a boot manager and pick them once we have backlights and such.

Yeah I don't see the point in rushing away from emunand yet either. A9LH in its current state lets you boot your emunand so quickly and reliably that you hardly even notice the difference, and there's no chance of something unforeseen in a future update throwing something out of whack that can't be easily repaired by an emunand restore.

I don't see myself switching to sysnand-only until there's a Decrypt9 BootMii Edition that you can always run no matter how badly you pulverize your nand just like with the Wii.

 

[DjoeN]

At this point I feel like downgrading to get the OTP might even be safer than downgrading from an unhacked console to 9.2 in the first place. In the case of the OTP downgrade you perform most of the dangerous steps in an emunand environment and so everything really should be in order by the time you flash anything to your sysnand.

The most dangerous part where it can go wrong on N3DS Only: fixing your bricked emunand 2.1 and write it to sysnand.
If for some reason the bricked emunand wasn't fixed or gor corrupted during the fix, your N3DS(XL) gets bricked (i know, my N3DS XL got bricked this way :/ )

 

[Urbanshadow]

It still gets locked even with A9LH present? That's interesting, I thought it decrypted the FIRM to garbage and then ran our code, which would come before loading another FIRM (which then locks it)?

Well, as I understand it, it's a gamble. What are the chances of crypto garbage to set the otp lock bit before the payload jump?

 

[dark_samus3]

It still gets locked even with A9LH present? That's interesting, I thought it decrypted the FIRM to garbage and then ran our code, which would come before loading another FIRM (which then locks it)?

arm9loader locks it as soon as it reads the OTP (which is before it decrypts the bad key we implanted in the 0x96 sector)

 

[daxtsu]

arm9loader locks it as soon as it reads the OTP (which is before it decrypts the bad key we implanted in the 0x96 sector)

Thanks for clarifying.

 

[FenrirWolf]

The most dangerous part where it can go wrong on N3DS Only: fixing your bricked emunand 2.1 and write it to sysnand.
If for some reason the bricked emunand wasn't fixed or gor corrupted during the fix, your N3DS(XL) gets bricked (i know, my N3DS XL got bricked this way :/ )

Yeah, that part is definitely risky, but it's at least risky in a much more deterministic sense than having memchunkhax2 randomly decide to abort in the middle of a downgrade. Assuming everything is done right by the user and that the programs themselves are written and configured right and running in the right environment, then ideally they would work 100% of the time. Sorry to hear that something went wrong in the chain of events for you though x_x

 

[Urbanshadow]

arm9loader locks it as soon as it reads the OTP (which is before it decrypts the bad key we implanted in the 0x96 sector)

What would happen if left unlocked?

 

[dark_samus3]

What would happen if left unlocked?

We'd read the OTP out and wouldn't have to downgrade

 

[Kayak]

We could dump it at higher firms but as it isnt we need 2.1

 

[subcon959]

I'm waiting for graphical applications to work in arm9.
Then i will ditch emunand swell.
From that moment we could easily create an unblock application, or a more user friendly boot loader that can boot into something like (forgot the name, Nand format + copy application)

Yeah, I get that being able to run D9 that early on will provide the ability to restore a working NAND backup if someone messes up sysNAND. I guess I just don't feel totally safe yet. It's not like the PSP where there was the Pandora battery, we can still get perma-bricked if enough shit went wrong. Always having my 9.2 sysNAND kinda gives me that protected feeling.

 

[dark_samus3]

Yeah, I get that being able to run D9 that early on will provide the ability to restore a working NAND backup if someone messes up sysNAND. I guess I just don't feel totally safe yet. It's not like the PSP where there was the Pandora battery, we can still get perma-bricked if enough shit went wrong. Always having my 9.2 sysNAND kinda gives me that protected feeling.

This is why I hardmod all of my consoles as soon as possible and before doing any risky stuff with them...

 

[subcon959]

This is why I hardmod all of my consoles as soon as possible and before doing any risky stuff with them...

I guess I should do that too as it seems to be the only way to get that cosy safe feeling I'm looking for.

 

[dark_samus3]

I guess I should do that too as it seems to be the only way to get that cosy safe feeling I'm looking for.

if you're doing a model other than the non XL o3ds the soldering is super easy and it's only 4 wires... if you have a bit more skill o3ds non XL is pretty easy too

 

[subcon959]

if you're doing a model other than the non XL o3ds the soldering is super easy and it's only 4 wires... if you have a bit more skill o3ds non XL is pretty easy too

It would probably be my O3DSXL and N3DSXL.. I'm not too bothered about the 2 O3DS non-XLs.