Homebrew ARM9Loader -- Automated Brute-force Using Raspberry PI2?

[Selver]

This is obviously only for N3DS.

This thread is intended to spur discussion about whether it would be both feasible and relatively easy to automate ARM9Loader brute-forcing. I'll update the first post as major updates / answers arrive.

It might not be practical at the moment, given progress made in other areas.

However, future units shipping with 10.5+ might exclude other attack vectors.

 

[Selver]

Would something along these lines work?

Here's a set of presumptions I have... basically what I think I understand:

• I2C can be used to reboot the unit
• GPIO pins can be used to write to the NAND
• Homebrew/payloads can send messages via I2C
• Homebrew/payloads can write memory with hax instructions
• Homebrew/payloads can overwrite exception vectors to point to hax instructions
• Reboot does not clear memory

Would the following be an avenue that an attacker could use to automate / brute force Arm9Loader into branching into their own exception vector?

Spoiler: Initial Setup

1. Hardmod to dump NAND
2. Additional Hardmod to expose I2C externally
3. Create two custom payloads:
   1. "I2C/OTP" payload, which would send a message via I2C, then dump OTP, then send a second message via I2C
   2. "PrepHax" payload, which would send a message via I2C, overwrite the exception vectors to point to I2C/OTP payload, and then send a second message via I2C
4. Setup N3DS to auto-boot the "PrepHax" payload, such as via Theme
5. Have RPI2 setup to write NAND via GPIO
6. Connect the N3DS I2C to RPI2's I2C
7. Connect the N3DS DAT0/CLK/CMD to RPI2's GPIO

Spoiler: High-level logic on RPI2

1. Initialize I2C in multi-master mode, exposing both slave and master
2. Set DAT0/CLK/CMD to not interfere with boot (float?)
3. Reboot via I2C, wait for timeout or an I2C message indicating Hax stage
4. I2C messages:
   • PrepHax started -- set another timeout, things are progressing
   • PrepHax complete -- reboot with sector 150 updated to next test values
   • I2C/OTP started -- set another timeout, things are progressing
   • I2C/OTP complete -- HALT! Potentially usable magic value found!
5. Timeouts (based on last I2C message):
   • PrepHax started -- memory not reliably set, random hax failure? Just reboot via I2C
   • PrepHax complete -- not usable special sector, reboot with sector 150 updated
   • I2C/OTP started -- Log as 'potential' values for sector 150, then reboot with sector 150 updated

If nothing technical prevents this from working, this would seem to reduce
the complexity of the brute-force method.[/SPOILER]

 

[Slashcash]

Would something along these lines work?

Here's a set of presumptions I have... basically what I think I understand:

• I2C can be used to reboot the unit
• GPIO pins can be used to write to the NAND
• Homebrew/payloads can send messages via I2C
• Homebrew/payloads can write memory with hax instructions
• Homebrew/payloads can overwrite exception vectors to point to hax instructions
• Reboot does not clear memory

Would the following be an avenue that an attacker could use to automate / brute force Arm9Loader into branching into their own exception vector?

Spoiler: Initial Setup

1. Hardmod to dump NAND
2. Additional Hardmod to expose I2C externally
3. Create two custom payloads:
   1. "I2C/OTP" payload, which would send a message via I2C, then dump OTP, then send a second message via I2C
   2. "PrepHax" payload, which would send a message via I2C, overwrite the exception vectors to point to I2C/OTP payload, and then send a second message via I2C
4. Setup N3DS to auto-boot the "PrepHax" payload, such as via Theme
5. Have RPI2 setup to write NAND via GPIO
6. Connect the N3DS I2C to RPI2's I2C
7. Connect the N3DS DAT0/CLK/CMD to RPI2's GPIO

[/SPOLIER]

Spoiler: High-level logic on RPI2

1. Initialize I2C in multi-master mode, exposing both slave and master
2. Set DAT0/CLK/CMD to not interfere with boot (float?)
3. Reboot via I2C, wait for timeout or an I2C message indicating Hax stage
4. I2C messages:
   • PrepHax started -- set another timeout, things are progressing
   • PrepHax complete -- reboot with sector 150 updated to next test values
   • I2C/OTP started -- set another timeout, things are progressing
   • I2C/OTP complete -- HALT! Potentially usable magic value found!
5. Timeouts (based on last I2C message):
   • PrepHax started -- memory not reliably set, random hax failure? Just reboot via I2C
   • PrepHax complete -- not usable special sector, reboot with sector 150 updated
   • I2C/OTP started -- Log as 'potential' values for sector 150, then reboot with sector 150 updated

If nothing technical prevents this from working, this would seem to reduce
the complexity of the brute-force method.

From a theoretical point of view i don't see anything preventing this. Am i not considering something vital? This seems a really fun task if i wasn't stuck with an o3ds i would try to pursue this way myself

 

[DigitalJosee]

Why this doesn't work with the o3DS?

 

[Selver]

Why this doesn't work with the o3DS?

I'm not 100% sure it couldn't work this with an O3DS, once that O3DS was already fully rooted. But, there are other options once rooted.

Rather, can this be generalized in a way to break new N3DS shipping with 10.5+ firmware? Thus, the curiosity:

• How feasible to automate this process?
• How long would it have to run to find a usable result? (does it match the theory?)

Spoiler: Smaller parts that may be needed

• RPI2 I2C library to...
  • library to listen to and log all I2C traffic (for Reverse Engineering)
  • library to setup I2C multimaster mode at unused address, such as ID 0x3A (0x74>>1)
• homebrew that, in incremental development steps:
  • sends I2C messages to ID 0x3A
  • writes payload
  • writes all accessible memory with NOP / BRANCH sleds (pointing to payload)
  • if possible (??? is A9 Kernel needed ???), overwrite exception vectors to point to payload
• Experiment and document, at least one configured state for GPIO pins connected to DAT0/CLK/CMD, such that:
  • the 3DS operates the eMMC device normally (all three pins floating?)
  • the 3DS boot results in bluescreen (DAT0 forced high/low, others floating?)
• RPI2 GPIO based library to send basic eMMC commands (
  • Datasheet for Samsung MC12H064NBCA-2SA00
  • Datasheet for Samsung KLM4G1YEMD-B031
  • Datasheet for Toshiba THGBM5G6A2JBAIR

The question is how low the bar actually is, not including initial development time. Can this be done with only RPI2, without additional electronic circuitry (voltage converters, resistors, capacitors, transistors, etc.)?

For more thoughts on how long to find a usable result, see the ARM9Loader -- Technical Details and Discussion thread, specifically the section titled ARM9Loader v2 (2/3).

 

[Joom]

Wait, rebooting doesn't flush RAM? That seems like an incredibly dangerous flaw on Nintendo's part.

 

[Selver]

Wait, rebooting doesn't flush RAM? That seems like an incredibly dangerous flaw on Nintendo's part.

Correct. See 3dBrew.org for details.

 

[Selver]

From a theoretical point of view i don't see anything preventing this. Am i not considering something vital? This seems a really fun task if i wasn't stuck with an o3ds i would try to pursue this way myself

Most eMMC devices also support SPI mode, if the RPI2 isn't easily able to control the device using CMD/CLK/DAT0.

Question: Has anyone discovered which test points correspond to the I2C bus on the various 3DS models (2DS, O3DS, O3DS XL, N3DS, N3DS XL)?

 

[Syphurith]

Most eMMC devices also support SPI mode, if the RPI2 isn't easily able to control the device using CMD/CLK/DAT0.
Question: Has anyone discovered which test points correspond to the I2C bus on the various 3DS models (2DS, O3DS, O3DS XL, N3DS, N3DS XL)?

Thanks for your effort. However Hardware related stuffs are merely put on 3dbrew. But yes you can still search for "Pinout" there.