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

Discussion in '3DS - Flashcards & Custom Firmwares' started by martyjake, Jun 8, 2017.

  1. martyjake
    OP

    martyjake Member

    Newcomer
    21
    11
    Jun 16, 2016
    Canada
    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?
     
  2. jupitteer

    jupitteer GBAtemp Lurker

    Member
    669
    435
    Feb 17, 2017
    Antarctica
    Inkopolis
    Ram dumps with a hardmod.
     
  3. Ryccardo

    Ryccardo WiiUaboo

    Member
    2,894
    1,348
    Feb 13, 2015
    Italy
    Imola
    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!
     
  4. Ominous66521

    Ominous66521 GBAtemp Maniac

    Member
    1,046
    233
    Feb 7, 2016
    United States
    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.
     
  5. martyjake
    OP

    martyjake Member

    Newcomer
    21
    11
    Jun 16, 2016
    Canada
    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?
     
  6. Ryccardo

    Ryccardo WiiUaboo

    Member
    2,894
    1,348
    Feb 13, 2015
    Italy
    Imola
    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)