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.
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.
