Toggle sidebar

Homebrew The bootroms

  • Thread starter Thread starter Suiginou
  • Start date Start date
  • Views Views 52,338
  • Replies Replies 307
  • Likes Likes 39
8BitWonder said:
Out of curiosity, would finding a vulnerability in either bootroms allow lead to a method to grab the OTP on any firmware? Or would we still need 2.1 for that no matter what?
Click to expand...
I believe (correct me if I am wrong) that you can indeed dump OTP if bootrom is exploited...

but why would you install A9LH if a bootrom exploit is found?
 
Ev1l0rd said:
So um... this is just a question out of curiosity, but anyways:

What could we achieve that hasn't been done yet? Aside from decrypting straight from PC, which is useful for convenience, is there anything else we could do?
Click to expand...
From the OP:
Suiginou said:
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.
Click to expand...
 
  • Like
Reactions: Pandaxclone2 and astronautlevel
This is kind of a strange question, but has anyone run the incomplete bootrom through a disassembler? I ask this only because arm9 bootrom bytes 0xffff5d30-0xffff8000 are all zero - at least on my console - and that seems kind of odd to me.

EDIT: Okay, quick use of objdump tells me that the readable region is probably code, and it reads data from the high region. I'm doubtful that the 0x0 nop sled is ever intended to be hit; the bootrom is probably locked by then, so it nop sleds into an invalid read by design if something goes horribly wrong, I think. We have access to the code of the bootrom, but not the data (which is where the keys are, obviously.)
 
Last edited by chaoskagami,
chaoskagami said:
This is kind of a strange question, but has anyone run the incomplete bootrom through a disassembler? I ask this only because arm9 bootrom bytes 0xffff5d30-0xffff8000 are all zero - at least on my console - and that seems kind of odd to me.

EDIT: Okay, quick use of objdump tells me that the readable region is probably code, and it reads data from the high region. I'm doubtful that the 0x0 nop sled is ever intended to be hit; the bootrom is probably locked by then, so it nop sleds into an invalid read by design if something goes horribly wrong, I think. We have access to the code of the bootrom, but not the data (which is where the keys are, obviously.)
Click to expand...
The zeros are the copy protection if I am correct.
 
dankzegriefer said:
The zeros are the copy protection if I am correct.
Click to expand...

I'm pretty sure the idea of copy protection at a random unaligned offset is absurd, considering nintendo didn't plan far enough to stop arm9loaderhax. That would mean that 'locking' the bootloader encompasses more than just disabling access to 0xffff8000, and that this absurd 'read as 0' is part of the chip. I don't know of any arm9 variants that have this as a 'feature'. If they really wanted to disable access like that, why not the whole 0xffff bytes?

As far as I'm concerned, it's a nop sled, which is commonly used when you need to pad code sections. Just `andeq r0, r0, r0` to a read fault at 0xffff8000.

The disassembly is certainly interesting, though. It gives an incomplete idea of how boot goes. It's annoying to read since it's intermixed thumb and normal code, and I'm pretty sure there was a C complier involved (or a very drunk nintendo employee, one of the two)
 
Last edited by chaoskagami,
Reality check: there's not going to be a bootrom exploit for one reason: even if the astronomical odds of a vulnerability are satisfied, how are we going to write to that bootrom to set up said exploit?
 
Swiftloke said:
Reality check: there's not going to be a bootrom exploit for one reason: even if the astronomical odds of a vulnerability are satisfied, how are we going to write to that bootrom to set up said exploit?
Click to expand...
Doesn't necessarily need to write to bootrom. It wouldn't be an EXPLOIT if it cannot be exploited. It would merely be a vulnerability.
 
  • Like
Reactions: Harvest God, Wolfvak and astronautlevel
People keep talking about hype for 'bootromhax'. Not happening is what I'm saying. Thread put on watch list, I really want to see where this goes.
 
chaoskagami said:
I'm pretty sure the idea of copy protection at a random unaligned offset is absurd, considering nintendo didn't plan far enough to stop arm9loaderhax. That would mean that 'locking' the bootloader encompasses more than just disabling access to 0xffff8000, and that this absurd 'read as 0' is part of the chip. I don't know of any arm9 variants that have this as a 'feature'. If they really wanted to disable access like that, why not the whole 0xffff bytes?

As far as I'm concerned, it's a nop sled, which is commonly used when you need to pad code sections. Just `andeq r0, r0, r0` to a read fault at 0xffff8000.
Click to expand...
Notice that the area read as non zero is exactly the same size as the area read as zeros.... that region is what's locked, when the register to protect it is set it completely disconnects that area of the mask rom on the CPU die from, well the rest of the CPU... clearing the register has no effect, it doesn't actually get written after it's been written the first time, it's a write once register... also, that area of RAM you're reading from is simply the area where the mask rom is mapped to in memory, so they aren't disabling access to RAM, they're disabling access to the mask rom, which in turn makes that area read out to zero
 
  • Like
Reactions: astronautlevel
dark_samus3 said:
Notice that the area read as non zero is exactly the same size as the area read as zeros.... that region is what's locked, when the register to protect it is set it completely disconnects that area of the mask rom on the CPU die from, well the rest of the CPU... clearing the register has no effect, it doesn't actually get written after it's been written the first time, it's a write once register...
Click to expand...

I'm not confused about the write once bit, nor the fact that bootrom is a memory-mapped device. I do know how to read, and I've worked with arm boards before for fun. I'm pretty clear on how that works.

dark_samus3 said:
also, that area of RAM you're reading from is simply the area where the mask rom is mapped to in memory, so they aren't disabling access to RAM, they're disabling access to the mask rom, which in turn makes that area read out to zero
Click to expand...

To be clear; the readable amount of data is not an equal 0x4000/0x4000 split what can be read. 0x5d30 bytes can be read before being all zero, which is not really page-aligned. I just find it weird; I'm not suggesting 'magical boothax nao'. In fact, it's probably just downright worthless information.

I'm just curious why nobody has done an incomplete bootrom dump and posted it.
 
Last edited by chaoskagami,
chaoskagami said:
I'm not confused about the write once bit, nor the fact that bootrom is a memory-mapped device. I do know how to read, and I've worked with arm boards before for fun. I'm pretty clear on how that works.



To be clear; the readable amount of data is not an equal 0x4000/0x4000 split what can be read. 0x5d30 bytes can be read before being all zero, which is not really page-aligned. I just find it weird; I'm not suggesting 'magical boothax nao'. In fact, it's probably just downright worthless information.

I'm just curious why nobody has done an incomplete bootrom dump and posted it.
Click to expand...
They have before, iirc, and reverse engineered it... how do you think we know some of what the bootrom does?

also, that other stuff was for others as well as you (since I didn't know how much you knew)
 
Last edited by dark_samus3,
  • Like
Reactions: chaoskagami and astronautlevel

Site & Scene News

Go to forum More news

Popular threads in this forum

Why did the price of 3ds shoot up ?

Hacking Homebrew Project  BlazerTube - a YouTube 3DS revival using the REAL app!

[WIP] SMW 3DS Port - Early Playable Demo by ZalgonEn

Problems getting Homebrew to appear outside of the Homebrew Launcher (homebrew won't appear on the HOME menu)

Homebrew app Emulator  [Release] 3DS-CLI - Run a real RISC-V Linux environment on the Nintendo 3DS

Website for finding alternative games for 3DS

Homebrew  [Progress update] LCE Minecraft 3ds

Gaming  any good rpgs on 3ds?