Homebrew The bootroms

[yifan_lu]

I'm going to assume @yifan_lu's method is involving either decapping the chip, or performing the exception-vector timing attack from hardware as outlined earlier in the thread?

From the looks of the insides, it is highly likely that the debugger features are implemented in a FPGA. This gives us two possibilities: 1) it might be possible to reprogram the FPGA to enable JTAG debugging (my theory is that nintendo uses similar hw internally but different FPGA hardware definitions for developers. cuts down costs). 2) since the FPGA is connected directly to the main SoC, it could provide a very convenient way to try to trigger the timing attack without having to create custom hw.

I can't justify spending the money just to test this hypothesis since I could be wrong and brick a dev unit in the process.

 

[sirocyl]

That's what I get for not reading the whole thread. ._.

Either way, that's a very interesting conclusion. The actual 3DS SoC wouldn't happen to have the pins on it to support JTAG in the same way, right? Or, would the consumer-level chip simply have it disconnected from the die?

 

[yifan_lu]

That's what I get for not reading the whole thread. ._.

Either way, that's a very interesting conclusion. The actual 3DS SoC wouldn't happen to have the pins on it to support JTAG in the same way, right? Or, would the consumer-level chip simply have it disconnected from the die?

If nintendo was smart, they would tie off the JTAG pins on retail units. Other manufacturers use efuses for this: that way they can produce a single chip for both testing and consumer (makes sense since you don't want a bug to only be in a consumer unit and not a debug unit). If I were nintendo, I would have a value in the OTP that enables JTAG or not (since that's essentially efuses).

Of course nintendo isn't known for being smart in these things so it wouldn't hurt for someone to check though.

 

[mathieulh]

If nintendo was smart, they would tie off the JTAG pins on retail units. Other manufacturers use efuses for this: that way they can produce a single chip for both testing and consumer (makes sense since you don't want a bug to only be in a consumer unit and not a debug unit). If I were nintendo, I would have a value in the OTP that enables JTAG or not (since that's essentially efuses).

Of course nintendo isn't known for being smart in these things so it wouldn't hurt for someone to check though.

As far as I can tell, a special purpose (write once) register used to disable JTAG is set by boot9 depending on your OTP configuration.

 

[dark_samus3]

in case anyone cares, we did end up identifying the ISA of the MCU, documentation can be found here

We still aren't sure of the exact model, but we can actually disassemble the MCU FW now and get an idea of what they're doing (which is more than can be said from before). There's also a simulator, binutils and gcc for this thing already out in the wild... All this said, it isn't guaranteed that we'll find a way to dump bootrom through this, but it means we have more documentation and options available to us now.

Shoutouts to bilis randomly googling, picking the first result, and it being the exact thing we needed... (we all feel pretty stupid at this point, heh)

 

[Billy Acuña]

in case anyone cares, we did end up identifying the ISA of the MCU, documentation can be found here

We still aren't sure of the exact model, but we can actually disassemble the MCU FW now and get an idea of what they're doing (which is more than can be said from before). There's also a simulator, binutils and gcc for this thing already out in the wild... All this said, it isn't guaranteed that we'll find a way to dump bootrom through this, but it means we have more documentation and options available to us now.

Shoutouts to bilis randomly googling, picking the first result, and it being the exact thing we needed... (we all feel pretty stupid at this point, heh)

Something that was used to be called "bullshit" is coming a reallity.

 

[sirocyl]

As far as I can tell, a special purpose (write once) register used to disable JTAG is set by boot9 depending on your OTP configuration.

What this says to me, is "You can use JTAG to stop boot9 before boot9 disables JTAG."
Which in turn means, "You can use JTAG to stop boot9 before the sysprot write, then tell the CPU to dump the bootrom memory region over JTAG."

I mean, if someone were willing to solder a few tiny wires to a BGA part, we could easily download bootrom over a parallel port on a PC.

 

[mathieulh]

What this says to me, is "You can use JTAG to stop boot9 before boot9 disables JTAG."
Which in turn means, "You can use JTAG to stop boot9 before the sysprot write, then tell the CPU to dump the bootrom memory region over JTAG."

I mean, if someone were willing to solder a few tiny wires to a BGA part, we could easily download bootrom over a parallel port on a PC.

It's not that easy, timing is too short to make it doable, in short they weren't that stupid.

Envoyé de mon SM-G935F en utilisant Tapatalk

 

[PabloMK7]

So if timing is that short, what about making a loop that increments the number of ms each time so we get the timing with brute force?

 

[Xenon Hacks]

So if timing is that short, what about making a loop that increments the number of ms each time so we get the timing with brute force?

That should be doable now just active monitor it till it clicks into place and adjust as needed.

 

[astronautlevel]

So if timing is that short, what about making a loop that increments the number of ms each time so we get the timing with brute force?

If it was milliseconds this would be easy mode.

 

[Xenon Hacks]

If it was milliseconds this would be easy mode.

Is the actual timing known but not feasible to get?

 

[sirocyl]

Is the actual timing known but not feasible to get?

Something like that. We need to stop the ARM9 CPU within 2-300 instructions, which is somewhere in the ballpark of 6-1200 clocks at 134MHz.
(Going by the average ARM9 cycles-per-instruction count.)

A back-of-the-napkin calculation says that, optimistically, we have almost 9 microseconds, or 9000 nanoseconds to work in.

Pessimistically? We only have 45 nanoseconds to work in.
Good luck finding something that quick to respond over JTAG.

But, if we can tie into the /RESET line, then we could use a clock drift strategy to eventually hit that sweet spot after a few million tries.

 

[Xenon Hacks]

Something like that. We need to stop the ARM9 CPU within 2-300 instructions, which is somewhere in the ballpark of 6-1200 clocks at 134MHz.
(Going by the average ARM9 cycles-per-instruction count.)

A back-of-the-napkin calculation says that, optimistically, we have almost 9 microseconds, or 9000 nanoseconds to work in.

Pessimistically? We only have 45 nanoseconds to work in.
Good luck finding something that quick to respond over JTAG.

But, if we can tie into the /RESET line, then we could use a clock drift strategy to eventually hit that sweet spot after a few million tries.

is there something you can do to force this window to widen kinda of like loading a bunch of crap 0's to cause "lag"?

 

[mathieulh]

If it was milliseconds this would be easy mode.

You mean longer it takes for the whole boot9 code to run? Be realistic, think nanoseconds.

Envoyé de mon SM-G935F en utilisant Tapatalk

 

[astronautlevel]

You mean longer it takes for the whole boot9 code to run? Be realistic, think nanoseconds.

Envoyé de mon SM-G935F en utilisant Tapatalk

The person who I was replying to said "making a loop that increments the number of ms (milliseconds)," trust me, I know the time frame is much shorter than that

 

[chaoskagami]

is there something you can do to force this window to widen kinda of like loading a bunch of crap 0's to cause "lag"?

No. Not without tying to specific (and currently unidentified) pins that are potentially so small you can't solder. "Loading a bunch of crap 0's" is not only software, but we *physically* don't have execution so early (that's the entire point.) Even if software could stall (it can't) we don't have the ability to do so.

Please read the end of @sirocyl's post carefully.

 

[Poryhack]

Can the bootrom of a dev unit be dumped over JTAG as @yifan_lu theorized? Would doing so be helpful? I've seen speculation that the bootrom could be the same between dev and retail.

 

[Aletron9000]

Can the bootrom of a dev unit be dumped over JTAG as @yifan_lu theorized? Would doing so be helpful? I've seen speculation that the bootrom could be the same between dev and retail.

The dev bootrom (as i have heard) can be used to decrypt dev roms and then we can use a retail 3ds to reencrypt it to a retail rom.

 

[Poryhack]

The dev bootrom (as i have heard) can be used to decrypt dev roms and then we can use a retail 3ds to reencrypt it to a retail rom.

That should already be quite doable without any bootroms. Hell the "bigbluemenu" that everyone was using for so long is nothing but a dev "rom" with a banner and (maybe) encryption/signing swap.