Homebrew ARM9Loader -- Technical Details and Discussion

[MionissNio]

Actually, you could just not use the OTP data... Change a byte in the secret sector and hope it works, if it doesn't try again and again until you get a jump to the payload (which is more likely than you'd think) once you get the jump to the payload you'd just need a payload to do the unbricking

Raspberry pie hardmod to nand right? And what does OTP stand for?

 

[Columbo2811]

Raspberry pie hardmod to nand right? And what does OTP stand for?

One time pad iirc

 

[MionissNio]

One time pad iirc

Thanks I am willing to break this N3ds for science by Raspberry piei it, if it helps recover 3ds so.

Further info I messed up on 9.5 firmware so I should be good according to what I have read.

 

[RednaxelaNnamtra]

couldn't we theoretically do the brute forcing for the otp hash directly on the 3ds, by simply simulating the encryption and checking the result?

 

[capito27]

couldn't we theoretically do the brute forcing for the otp hash directly on the 3ds, by simply simulating the encryption and checking the result?

if only the hashing algorithm was known....

 

[dark_samus3]

Raspberry pie hardmod to nand right? And what does OTP stand for?

No need for the RasPi just a normal 3DS hardmod with an SD card adapter

 

[MionissNio]

No need for the RasPi just a normal 3DS hardmod with an SD card adapter

Thanks for the info, I shall practise hardmod and hopefully will not return with a fried motherboard soonTM.

 

[ketal]

The screen won't turn on at all, if that's what you're looking for. If you get something to do a firmlaunch or force a shut down, that's usually a good sign.

screeninits are not yet public, don't expect them to magically work without a payload
also, an hardmod is not mandatory. I did it on a o3ds without hardmod just fine. on n3ds, instead, it would be better to have it, since you need to edit the header manually and there's an high chance of messing up

couldn't we theoretically do the brute forcing for the otp hash directly on the 3ds, by simply simulating the encryption and checking the result?

yes, someone did it and it took 4 days. you need external hardware anyway

 

[RednaxelaNnamtra]

if only the hashing algorithm was known....

Do we realy need to know it? We know how the arm9 loader decrypts the secret sector and what its contend is, can't we use arm9 to bruteforce the hash until the secret sector get decrypted properly?

 

[dark_samus3]

Do we realy need to know it? We know how the arm9 loader decrypts the secret sector and what its contend is, can't we use arm9 to bruteforce the hash until the secret sector get decrypted properly?

I mean if you wanna bruteforce 256 bits then go ahead.... you'll be there awhile though

 

[Suiginou]

So, is this the currently accepted and canon O3DS downgrade-to-2.1 procedure?

1. Make a sysNAND backup with Decrypt9 or Gateway.
2. Install the good ol' 4.x mset pasta in mset.
3. Use Gateway launcher to downgrade to 4.x.
4. Clone sysNAND to a new emuNAND.
5. Use sysUpdater to downgrade to 2.1 on the emuNAND.
6. If the downgrade succeeded, write the emuNAND to sysNAND (after stitching the NCSD header back in). Else, rewrite the emuNAND and retry until you no longer have a partial.
7. Use ARM9 stuff (Cubic Ninja is public, apparently the cakes guys are working on something based on 2.1 spider with no success) to dump the OTP region to SD card.
8. Use ARM9 stuff to restore a sysNAND backup to get back to the original firmware. Alternatively, use ARM9 stuff to implement minipasta on 2.1 and run sysUpdater to get back (which must be recompiled to have matching kernel version stuff, and even then it's dubious whether ctrulib things really will work on 2.1).

Did I miss anything?

if only the hashing algorithm was known....

SHA-256(buf=0x10012000, size=0x90). So if you wanna brute-force 0x90 bytes of stuff to get the right SHA-256 hash, be my guest. (Pro tip: 16 bytes are currently only feasible with quantum computers, 32 bytes is considered quantum-proof right now)

 

[RednaxelaNnamtra]

I mean if you wanna bruteforce 256 bits then go ahead.... you'll be there awhile though

Oh yes, there was something, and the other bruteforcing worked with getting a key that jumps to our code. Was a bad Idea on my site

 

[Vappy]

For anyone who's already got it installed, here's a Very Tiny Payload, essentially just patois' helloARM9 with draw functions taken out. Waits for a button press then powers down. Maybe since it doesn't touch the screen, it'll actually work.

Psi-Hate tested this successfully, which means payloads that don't do anything with the screen should work(?).

 

[Psi-hate]

So, is this the currently accepted and canon O3DS downgrade-to-2.1 procedure?

1. Make a sysNAND backup with Decrypt9 or Gateway.
2. Install the good ol' 4.x mset pasta in mset.
3. Use Gateway launcher to downgrade to 4.x.
4. Clone sysNAND to a new emuNAND.
5. Use sysUpdater to downgrade to 2.1 on the emuNAND.
6. If the downgrade succeeded, write the emuNAND to sysNAND (after stitching the NCSD header back in). Else, rewrite the emuNAND and retry until you no longer have a partial.
7. Use ARM9 stuff (Cubic Ninja is public, apparently the cakes guys are working on something based on 2.1 spider with no success) to dump the OTP region to SD card.
8. Use ARM9 stuff to restore a sysNAND backup to get back to the original firmware. Alternatively, use ARM9 stuff to implement minipasta on 2.1 and run sysUpdater to get back (which must be recompiled to have matching kernel version stuff, and even then it's dubious whether ctrulib things really will work on 2.1).

Did I miss anything?

It's not necessary to use emunand but I suppose it'd work.
Here's how I did it (Without all the messups and complications inbetween)

1: Create Sysnand backup via decrypt9
2: Downgrade via gateway launcher
3: Load up ninjhax1 and run pasta and downgrade to 2.1 via sysupdater
4: Create a blank OTP.bin file and place it in the root of your SD card and run the QR code with the proper code.bin and load.bin
5: Update back to 4.5 via gamecard and then restore nand backup via decrypt9

 

[DigitalJosee]

Have you loaded any homebrew/CFW with this loader?
Or, atm, this's just experimental?

 

[cpasjuste]

It's not necessary to use emunand but I suppose it'd work.
Here's how I did it (Without all the messups and complications inbetween)

1: Create Sysnand backup via decrypt9
2: Downgrade via gateway launcher
3: Load up ninjhax1 and run pasta and downgrade to 2.1 via sysupdater
4: Create a blank OTP.bin file and place it in the root of your SD card and run the QR code with the proper code.bin and load.bin
5: Update back to 4.5 via gamecard and then restore nand backup via decrypt9

I don't know if it can be useful or working but when I looked at arm9loader sources on github I noticed the secondary payload is looking for "NAND.BIN" on SD and if found, write it to NAND.

 

[Psi-hate]

Have you loaded any homebrew/CFW with this loader?
Or, atm, this's just experimental?

We're working on getting payloads to work properly. We have payloads that are comfirmed working but that's about it. We are almost getting screeninit and all that good stuff. Once we have that, we're basically set. I think we can get payloads running as long as they don't touch the screen. @Reisyukaku got Reinand working. I'm about to test it rn.

 

[dark_samus3]

Psi-Hate tested this successfully, which means payloads that don't do anything with the screen should work(?).

Unfortunately it seems that firmlaunching doesn't work we got a ReiNAND payload going, got it booting (as evidenced by it creating a "firmware_patched.bin" file on the SD card, but it wouldn't launch the firm

 

[ketal]

Unfortunately it seems that firmlaunching doesn't work we got a ReiNAND payload going, got it booting (as evidenced by it creating a "firmware_patched.bin" file on the SD card, but it wouldn't launch the firm

to firmlaunch, you have to write A11 kernel @ 0x1FFFFFF8

 

[Ghost]

I shouldn't try this without a hardmod, right?