Homebrew The bootroms

  • Thread starter Thread starter Suiginou
  • Start date Start date
  • Views Views 52,363
  • Replies Replies 307
  • Likes Likes 39
Dude. If anyone "dumps the bootrom" they'd share it immediately. There's no reason not to. Nintendo can't patch it.
Their political stance on contributing to piracy? Not sure about yifanlu, but most named hackers in this scene won't share anything unless they can implement their own method of security.
 
Just thinking out loud here:

We know from A9LH that FIRM consists of a ARM9 Loader and the encrypted ARM9 binary.
But is the ARM9 Loader also encrypted? If it is, do we have access to this key so we can change it just like Key #2?

If so, maybe we can apply the same technique for ARM9 Loader this time ? So a payload runs instead of ARM9 Loader?
 
Dude. If anyone "dumps the bootrom" they'd share it immediately. There's no reason not to. Nintendo can't patch it.
you don't know how some devs think...!
not all are about sharing, whatever their reason may be.


oops, this guy was already quoted twice about this lol, anyway, yeah not everyone has the same mindset as yourself!
 
Last edited by cearp,
  • Like
Reactions: WeedZ
Dude. If anyone "dumps the bootrom" they'd share it immediately. There's no reason not to. Nintendo can't patch it.
As much as I wish that would be the case it isn't, bootrom has actually already been confirmed to be dumped yet people don't share it...

--------------------- MERGED ---------------------------

Just thinking out loud here:

We know from A9LH that FIRM consists of a ARM9 Loader and the encrypted ARM9 binary.
But is the ARM9 Loader also encrypted? If it is, do we have access to this key so we can change it just like Key #2?

If so, maybe we can apply the same technique for ARM9 Loader this time ? So a payload runs instead of ARM9 Loader?
Bootrum locks itself before the arm9loader runs.
 
Bootrum locks itself before the arm9loader runs.

Are you sure it's not the next component in the bootchain? How did Nintendo set the CFG_SYSPROT9 for OTP after the 2.1.0 update? They can't update the bootrom.
But let's say what you say is true ... on N3DS ARM9 Loader (which my theory exploits here) is the one which sets the locking register according to this?:

https://www.3dbrew.org/wiki/CONFIG_Registers#CFG_SYSPROT9

Says: On New 3DS, the above is instead done by the Kernel9 loader.
 
Are you sure it's not the next component in the bootchain? How did Nintendo set the CFG_SYSPROT9 for OTP after the 2.1.0 update? They can't update the bootrom.
But let's say what you say is true ... on N3DS ARM9 Loader (which my theory exploits here) is the one which sets the locking register according to this?:

https://www.3dbrew.org/wiki/CONFIG_Registers#CFG_SYSPROT9

Says: On New 3DS, the above is instead done by the Kernel9 loader.
That's about the OTP region, not bit0 for the bootrom.

I know how to get it, I just don't have the funds to do so. Especially since I don't care that much about getting the bootrom. But if I do stumble upon it of course I'll share; otherwise I won't even mention it.
Maybe someone else has the funds. Might be worth just posting the theory on your blog?
 
Are you sure it's not the next component in the bootchain? How did Nintendo set the CFG_SYSPROT9 for OTP after the 2.1.0 update? They can't update the bootrom.
But let's say what you say is true ... on N3DS ARM9 Loader (which my theory exploits here) is the one which sets the locking register according to this?:

https://www.3dbrew.org/wiki/CONFIG_Registers#CFG_SYSPROT9

Says: On New 3DS, the above is instead done by the Kernel9 loader.
Well, let's get the full context for your quote
On Old 3DS, NATIVE_FIRM reads CFG_SYSPROT9 to know whether it has previously initialized the TWL console-unique keys using the OTP data. After setting the TWL console-unique keys, NATIVE_FIRM sets CFG_SYSPROT9 bit 1 to disable the OTP area. In subsequent FIRM launches prior to the next reset, NATIVE_FIRM will see that the OTP area is disabled, and skip this step.

On New 3DS, the above is instead done by the Kernel9 loader.

What the kernel9 loader does is lock CFG_SYSPROT9 bit 1, which disables OTP - this is why downgrading to 2.1 allows us to get OTP as it's the FIRM, not the bootrom, that locks the OTP registers.
 
I know how to get it, I just don't have the funds to do so. Especially since I don't care that much about getting the bootrom. But if I do stumble upon it of course I'll share; otherwise I won't even mention it.
funds? how much would it cost to get the hardware or whatever to do it? (assuming someone has not much hardware for this stuff)
(not interested in setting up a fundraiser haha, just curious!) :)
 
funds? how much would it cost to get the hardware or whatever to do it? (assuming someone has not much hardware for this stuff)
(not interested in setting up a fundraiser haha, just curious!) :)
I asked the person who said that he was selling them for a cost estimate on the CTR-DEBUGGER unit, but he hasn't responded yet. I can imagine it would be at least somewhat expensive, however.
 
  • Like
Reactions: cearp
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?
 
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?
The FPGA is just an Altria Cyclone. The SDK references JTAG although the PARTNER Debugger does not use it. The existence of the files and symbols means that perhaps we can reconfigure the FPGA to enable JTAG access. With JTAG you can freeze the unit on boot and dump the boot rom.
 

Site & Scene News

Popular threads in this forum