Some questions regarding OTP

Discussion in '3DS - Flashcards & Custom Firmwares' started by Sumsquat, Apr 4, 2016.

  1. Sumsquat
    OP

    Sumsquat Advanced Member

    Newcomer
    66
    19
    Jan 15, 2016
    Gambia, The
    As of now, I am using 9.2E with 10.7 rxTools EmuNand(menuhax), and I'm thinking of switching to a9lh.
    I've got some questions.

    1. Do I have to do this whole Rednand thingy,can't I just downgrade my GW-made EmuNand?

    2. According to the 3dbrew-wiki, ARM9Loaderhax also works with the OTP hash, which isn't cleared(last checked on 10.4). So why all the backup-downgrade-reupgrade struggle, if we can just dump that instead?

    I hope, those questions aren't too noobish and were not asked a million times before.
    Greetings!
     
  2. VIERcntHOLZ

    VIERcntHOLZ yep, theres missing an "u".

    Member
    144
    27
    Mar 26, 2016
    Gambia, The
    1. Follow exactly this Guide - Step by Step
    2.
    There is, however, a method to dump the hash of the OTP on version 9.6.0-X. Because Kernel9Loader does not clear the SHA_HASH register after it has been used, dumping the SHA_HASH will give the hash of the OTP which was handed over to Kernel9 from Kernel9Loader. In addition, there is a long standing vulnerability where an MCU reboot caused by the i2c will not clear RAM like it's supposed to.

    This allows for a hardware based attack where arbitrary data is written to nand_sector96+0x10 in a SysNAND backup and flashed to the device. Afterwards we wire the i2c to MCU reboot on our command, write a payload (which will write 0x1000A040 - 0x1000A060 to a file on the SD card) to arm9 memory somewhere, fill all memory with a NOP sled followed by a JMP instruction pointing to the payload. We can then MCU reboot repeatedly (incrementing nand_sector96+0x10 by 1 each time) until the Kernel9Loader jumps to the payload by random chance.

    Because of the complexity and extra hardware involved in the method described above, I have decided to limit the scope of this guide strictly to the software based approach of downgrading to a version below 3.0.0-X. Version 2.1.0-X was selected because it is the only version below 3.0.0-X that contains a fully exploitable browser version (2.0.0-X has a partially exploitable browser, but it won't work for other reasons).

    tl;dr: Too hard, compared to the downgrade process

    Source: Guide from above :D
     
    pscytheology, Minnow and Sumsquat like this.