Hacking (Noob question) How was the code for the boot sequence observed before A9LH?

[martyjake]

I'm trying to learn more about hardware hacking and vulnerabilities and I've always wondered, how did people observe the code that the 3DS runs when it boots before they found an exploit?

 

[Deleted member 414991]

Ram dumps with a hardmod.

 

[Ryccardo]

If you mean the bootroms, there's no alternative to dumping them (which was done over a year ago by certain famous people)

If you mean the secret sector (required for decrypting N3DS kernels), the contents were effectively leaked by security deficiencies in, iirc, the kernels themselves

All installable titles are encrypted with keys coming from variable combinations of: the kernel, the bootrom, the OTP, the movable.sed, the nand CID, etc -- but while, without all of those sources, it's impossible to get the actual keys themselves, you can use a hacked console (that can normally decrypt your object of interest, for example you legally bought a digital game with) to decrypt that object without necessarily having direct access to the keys involved (for example, dumping titlekeys)

The above is how pretty much any encryption/decryption had to be done until most people got access to the bootrom = B9S release, since most of the keys come in part from the bootrom

While still comparatively unpopular, it's now possible to do most of those jobs on a PC, at an appropriately increased speed!

 

[Deleted User]

Before a9lh there was menuhax and spider/mset which gave userland access to the kernel with 9.2,which was the golden firmware at the time and let you to boot into the kernel from userland acess before it was patched on newer firmwares after 9.2.Then once we got into downgrading and all with hardmodding,I guess that was when a9lh (access to the arm9 boot rom) was in the works and eventually we found out how to dump the otp which are the keys needed.

 

[martyjake]

If you mean the bootroms, there's no alternative to dumping them (which was done over a year ago by certain famous people)

If you mean the secret sector (required for decrypting N3DS kernels), the contents were effectively leaked by security deficiencies in, iirc, the kernels themselves

All installable titles are encrypted with keys coming from variable combinations of: the kernel, the bootrom, the OTP, the movable.sed, the nand CID, etc -- but while, without all of those sources, it's impossible to get the actual keys themselves, you can use a hacked console (that can normally decrypt your object of interest, for example you legally bought a digital game with) to decrypt that object without necessarily having direct access to the keys involved (for example, dumping titlekeys)

The above is how pretty much any encryption/decryption had to be done until most people got access to the bootrom = B9S release, since most of the keys come in part from the bootrom

While still comparatively unpopular, it's now possible to do most of those jobs on a PC, at an appropriately increased speed!

In order to develop an exploit you need to observe and study the code that is being run, right? Then how this code was able to be decrypted in the first place without a key?

 

[Ryccardo]

In order to develop an exploit you need to observe and study the code that is being run, right?

The usual way to realize an exploit even exists is to blindly feed an application invalid data (hacked saves, too long of a description in the case of the mset exploit, non-level QRs for Cubic Ninja...) and see how it reacts (ignores it, rejects it, crashes and quits, crashes and freezes or does weird stuff) - then you need to figure out if the crash is exploitable (ie if it can be controlled by changing the data you feed it and/or "external" factors)

Then yes, having an accurate emulator with debugger can help, but if you don't have them, you can still try blindly (while maximizing your luck - for example, if you can supply arbitrary data through your hacked save to memory at addresses 500 through 600, and the crash jumps to a random address between 400 and 550, you can have an exploit with 1/3 chance of success if you put your payload after 550, and fill 500-550 with "do nothing, just proceed to next instruction")

(To figure out the above numbers without a debugger, it would be trial and error, yep)