Homebrew The bootroms

Suiginou

(null)
OP
Member
Joined
Jun 26, 2012
Messages
565
Trophies
0
Location
pc + 8
XP
738
Country
Gambia, The
This is the final frontier of 3DS security: The bootroms. Usually dubbed "bootrom", there are actually two of them: one for the ARM9 ("bootrom9") and one for the ARM11 ("bootrom11").

What we know

The lower 0x8000 bytes of each bootrom is readable and they are 0x10000 bytes each; bootrom9 is at 0xFFFF0000 and bootrom11 is at 0x00000000.

During boot, bit 0 of CFG_SYSPROT9/CFG_SYSPROT11 are set. After that, trying to read the upper 0x8000 bytes (i.e., 0xFFFF8000-0xFFFFFFFF for bootrom9 and 0x00008000-0x0000FFFF for bootrom11) causes the system to hang. It's currently unknown if this causes an exception and the CPU exception vectors infinite loop or this is some other kind of hang.

Unlike the OTP region, the bootrom locks itself. For that reason, there's no silly bypassing the bootrom security by downgrading.

The bootroms do not immediately set up the hardware exception vectors, a few cycles are available until the hardware exception vectors are changed to something the bootrom controls. Loading a payload into the top of FCRAM, rebooting the system via I2C/MCU and then causing a hardware exception would permit code execution before the bootrom locks itself. The timing for that is humanly impossible, however. Reliable and safe means of inducing a hardware exception are currently unknown. Given everything so far, this seems infeasible.

So far, the only hopes of dumping the bootroms seem to lie on a decap and then reading the bootrom off the chip. This requires relatively high amounts of money for equipment, as well as skills with handling the hardware. Since the last fundraiser for this exact purpose has ended in the money being taken and the people involved never having been heard of again, it's doubtful that this will ever happen, either.

What can be done with them

The bootroms hold the missing keys. Given that the AES key scrambler is known, physical 3DSes would no longer be required to do any sort of crypto operation, such as decrypting NCCH containers in the CCI/.3ds -> CIA conversion process or decrypting titlekeys. Decrypt9 would lose its use for any crypto-related operation.

Low-level emulators such as XDS will likely benefit from having the bootroms. Similarly, citra would no longer require a round-trip to decrypt the title to be played.

In the unlikely event that an exploit in one of the bootroms can be identified, the 3DS is fully compromised; a fix would require a new hardware revision.
 

Ricken

Oh Pretty Angel... Did None Teach You?
Member
Joined
Jan 19, 2016
Messages
2,658
Trophies
1
Age
21
Location
Mid-Michigan
XP
2,939
Country
United States
This is the final frontier of 3DS security: The bootroms. Usually dubbed "bootrom", there are actually two of them: one for the ARM9 ("bootrom9") and one for the ARM11 ("bootrom11").

What we know

The lower 0x8000 bytes of each bootrom is readable and they are 0x10000 bytes each; bootrom9 is at 0xFFFF0000 and bootrom11 is at 0x00000000.

During boot, bit 0 of CFG_SYSPROT9/CFG_SYSPROT11 are set. After that, trying to read the upper 0x8000 bytes (i.e., 0xFFFF8000-0xFFFFFFFF for bootrom9 and 0x00008000-0x0000FFFF for bootrom11) causes the system to hang. It's currently unknown if this causes an exception and the CPU exception vectors infinite loop or this is some other kind of hang.

Unlike the OTP region, the bootrom locks itself. For that reason, there's no silly bypassing the bootrom security by downgrading.

The bootroms do not immediately set up the hardware exception vectors, a few cycles are available until the hardware exception vectors are changed to something the bootrom controls. Loading a payload into the top of FCRAM, rebooting the system via I2C/MCU and then causing a hardware exception would permit code execution before the bootrom locks itself. The timing for that is humanly impossible, however. Reliable and safe means of inducing a hardware exception are currently unknown. Given everything so far, this seems infeasible.

So far, the only hopes of dumping the bootroms seem to lie on a decap and then reading the bootrom off the chip. This requires relatively high amounts of money for equipment, as well as skills with handling the hardware. Since the last fundraiser for this exact purpose has ended in the money being taken and the people involved never having been heard of again, it's doubtful that this will ever happen, either.

What can be done with them

The bootroms hold the missing keys. Given that the AES key scrambler is known, physical 3DSes would no longer be required to do any sort of crypto operation, such as decrypting NCCH containers in the CCI/.3ds -> CIA conversion process or decrypting titlekeys. Decrypt9 would lose its use for any crypto-related operation.

Low-level emulators such as XDS will likely benefit from having the bootroms. Similarly, citra would no longer require a round-trip to decrypt the title to be played.

In the unlikely event that an exploit in one of the bootroms can be identified, the 3DS is fully compromised; a fix would require a new hardware revision.
In other words, there can be something faster than A9LH?

Welp, gonna wait for a SafeInsertNameHereIstaller+SafeHardModInstaller (I wish)
 
Last edited by Ricken,

FR0ZN

Well-Known Member
Member
Joined
Nov 2, 2013
Messages
1,362
Trophies
1
Age
37
XP
3,816
Country
United States
This is the final frontier of 3DS security: The bootroms. Usually dubbed "bootrom", there are actually two of them: one for the ARM9 ("bootrom9") and one for the ARM11 ("bootrom11").

The bootroms do not immediately set up the hardware exception vectors, a few cycles are available until the hardware exception vectors are changed to something the bootrom controls. Loading a payload into the top of FCRAM, rebooting the system via I2C/MCU and then causing a hardware exception would permit code execution before the bootrom locks itself. The timing for that is humanly impossible, however. Reliable and safe means of inducing a hardware exception are currently unknown. Given everything so far, this seems infeasible.

What abount underclocking the CPUs ? Thinking about the RGH on 360, the CPU gets underclocked through i2c during boot. Maybe the ARM9/11 can also be locked somewhere in hte kHz area? That would widen the timeframe by alot.
 

FR0ZN

Well-Known Member
Member
Joined
Nov 2, 2013
Messages
1,362
Trophies
1
Age
37
XP
3,816
Country
United States
by looking at the code and mostly of all the risk that is involve.

Pip'

The "risk" is in the nature of the exploit + even if something goes south, it's not a lost device, there is always a way back and since you need a NAND dump in the first place anyway, I don't see a real risk here, only another hurdle in case something funny happens.

And what about the code? Are you talking about the installer ? Because that's not realy part of the hack. It just places crafted files in your NAND which actually trigger the exploit ... and once that is done A9LH is has proven to be the most reliable hack in the 3DS, because it works everytime 100% no matter what, due to its nature.
 

sirocyl

Are we Geniuses or what?
Newcomer
Joined
Apr 30, 2012
Messages
92
Trophies
1
Age
31
XP
324
Country
United States
I have a feeling it would be perfectly feasible to do an attack within the timeframe of SYSPROT9 bit 0x00, but we'd need a good feedback loop.
I propose flashing the MCU firmware, or even completely replacing the chip with a dummy clone, just an I2C bus peripheral that does the bare minimum to initialize the system, and pull the /RESET line on the SoC at the right time.
An RGH-style core slowdown wouldn't work, simply because the SoC doesn't (as far as I know) expose the registers to control CPU clocks with such fine granularity.
As for triggering the exception, three letters: NMI.

(information: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABBGBEC.html it's for a different chip, but the behavior should be the same for the most part.)
 
Last edited by sirocyl,

Suiginou

(null)
OP
Member
Joined
Jun 26, 2012
Messages
565
Trophies
0
Location
pc + 8
XP
738
Country
Gambia, The
I have a feeling it would be perfectly feasible to do an attack within the timeframe of SYSPROT9 bit 0x00, but we'd need a good feedback loop.
I propose flashing the MCU firmware, or even completely replacing the chip with a dummy clone, just an I2C bus peripheral that does the bare minimum to initialize the system, and pull the /RESET line on the SoC at the right time.
An RGH-style core slowdown wouldn't work, simply because the SoC doesn't (as far as I know) expose the registers to control CPU clocks with such fine granularity.
As for triggering the exception, three letters: NMI.

(information: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABBGBEC.html it's for a different chip, but the behavior should be the same for the most part.)
Next up: Finding the reset line. Good luck with that, champ.

The rest sounds somewhat promising. Did you actually try this or?
 
  • Like
Reactions: sirocyl

sirocyl

Are we Geniuses or what?
Newcomer
Joined
Apr 30, 2012
Messages
92
Trophies
1
Age
31
XP
324
Country
United States
Next up: Finding the reset line.
If theory serves right, it runs to the MCU.
Did you actually try this or?
I would love to try it, in the interests of science. I don't want to spill my life's story here, but suffice it to say, I don't have the equipment at the moment. I'm trying to find a job, and it's tough.
There's no well-equipped hackerspaces within 70 miles of here (central Long Island), either.
If anyone's local and willing to lend a hand, I can procure a busted 3DS for relatively cheap.
 

nero99

Well-Known Member
Member
Joined
Sep 18, 2014
Messages
3,135
Trophies
1
Age
31
XP
3,728
Country
United States
by looking at the code and mostly of all the risk that is involve.

Pip'

Have you even tried installing it? I have done to over 100 new 3ds systems the past 3 weeks and nothing has ever gone wrong. No bricking what so ever beside the emunand brick you're supposed to cause with 2.1.
 
  • Like
Reactions: hobbledehoy899

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
  • Sicklyboy @ Sicklyboy:
    maaaaan that's so awesome but I also don't want to fork over a hundo for it
  • Veho @ Veho:
    The fuuuuu---
  • Veho @ Veho:
    I thought it was an actual xBox at that price.
  • Sicklyboy @ Sicklyboy:
    I wanna grab a 360 Slim and a 360 E one of these days. Missed the boat of getting them at their lowest though, once they were discontinued. Could've got them for cheap back when I was a broke 20 something working at Target, but then again, I was a broke 20 something working at Target
  • Veho @ Veho:
    Being broke is no fun.
  • K3Nv2 @ K3Nv2:
    @Sicklyboy, $150 isn't that bad for a jtag slim on ebay
  • Veho @ Veho:
    I only wish it was actually playable.
  • Veho @ Veho:
    There's a guy on the Tube of You that makes playable mechanical arcade games out of Lego. This could work on the same principle.
  • Veho @ Veho:
    Just a couple of guys taking their manatee out for some fresh air, why you have to molest them?
  • Veho @ Veho:
    Stupid Chinese shop switched their shipping company and this one is slooooooow.
  • LeoTCK @ LeoTCK:
    STOP BUYING CHINESE CRAP THEN
  • LeoTCK @ LeoTCK:
    SUPPORT LOCAL PRODUCTS, MAKE REVOLUTION
  • LeoTCK @ LeoTCK:
    THEY KEEP REMOVING LOCAL SHIt AND REPLACING WItH INFERIOR CHINESE CRAP
  • LeoTCK @ LeoTCK:
    THATS WHY MY PARTNER CANT GET A GOOTWEAR HIS SIZE ANYMORE
  • LeoTCK @ LeoTCK:
    HE HAS BIG FOOT AND BIG DUCK
  • LeoTCK @ LeoTCK:
    d*ck i mean*
  • LeoTCK @ LeoTCK:
    lol
  • Veho @ Veho:
    Mkay.
  • Veho @ Veho:
    I just ordered another package from China just to spite you.
  • SylverReZ @ SylverReZ:
    Leo could not withstand communism.
  • SylverReZ @ SylverReZ:
    Its OUR products to begin with lol.
    SylverReZ @ SylverReZ: Its OUR products to begin with lol.