GiantPluto

To remove a submodule you need to:

• Delete the relevant section from the .gitmodules file.
• Stage the .gitmodules changes git add .gitmodules
• Delete the relevant section from .git/config.
• Run git rm --cached path_to_submodule (no trailing slash).
• Run rm -rf .git/modules/path_to_submodule (no trailing slash).
• Commit git commit -m "Removed submodule "
• Delete the now untracked submodule files rm -rf path_to_submodule

GiantPluto

Nintendo Switch RSA-PKCS#1 Public Key Recovery

This is a short writeup of a fun (but ultimately pretty useless) attack I implemented on the Nintendo Switch a few months ago resulting in the recovery of some otherwise unobtainable RSA public keys. Since public keys aren't private keys, this is pretty useless, apart from letting us validate some signatures on PC. Even so, the attack is a pretty cool one, so I thought I'd write it up.

Every Switch gamecart has a unique certificate (called its "CERT"), storing an RSA signature followed by some kind of unknown but unique encrypted data. I was trying to reverse how these certificates work, and the obvious first step was to try to see how they were validated. However, when I tried looking through the FileSystem (FS) module, which should be responsible for validating these certificates, I found no references to the format at all. The "CERT" magic number was nowhere to be seen, and I couldn't find an RSA modulus that validated the signatures I had. This was in

GiantPluto

{
    "version": {
        "format": 1,
        "semantics": 1
    },
    "news_id": 10000,
    "published_at": 0,
    "pickup_limit": 1209600,
    "priority": 50,
    "deletion_priority": 0,

GiantPluto

int cJSON_GetU8(const cJSON *obj, const char *field, u8 *out) {
    const cJSON *config = cJSON_GetObjectItemCaseSensitive(obj, field);
    if (cJSON_IsNumber(config)) {
        *out = (u8)config->valueint;
        return 1;
    } else {
        fprintf(stderr, "Failed to get %s (field not present).\n", field);
        return 0;
    }
}

GiantPluto

#define UNLOADED_FILE   1
#include <idc.idc>

static main(void)
{
  // set 'loading idc file' mode
  set_inf_attr(INF_GENFLAGS, INFFL_LOADIDC|get_inf_attr(INF_GENFLAGS));
  GenInfo();            // various settings
  Segments();           // segmentation
  Enums();              // enumerations

GiantPluto

#define UNLOADED_FILE   1
#include <idc.idc>

static main(void)
{
  // set 'loading idc file' mode
  set_inf_attr(INF_GENFLAGS, INFFL_LOADIDC|get_inf_attr(INF_GENFLAGS));
  GenInfo();            // various settings
  Segments();           // segmentation

GiantPluto

There'll be two stages in the core fusee payload, loading configuration from a shared ini file (https://en.wikipedia.org/wiki/INI_file).

- Stage 1 will be the actual exploit payload, and it will be fairly minimal:
    - It will initialize DRAM, and initialize the display.
    - It will load a filename and address for stage 2, loading stage 2 into DRAM and jumping to it.
    
- Stage 2 will be a "loader" -- it will be responsible for loading everything else into place prior to boot.
    - Stage 2 will be able to load arbitrarily many files to arbitrary load addresses off of the SD card.
        - Stage 2 will get a list of files to load from a "loadlist" key, with loadables delimited by "|" in the value.
        - For each loadable, a _path and _addr key will be used to identify a filename and where to load it to.

GiantPluto

0xbc100: ; save start
mov x19, x0
mov x0, #0xC0000000
adrp x1, #0x15000
ldr x1, [x1, #0x730]
ldr x1, [x1]
add x0, x1, x0
adrp x1, #0x15000
ldr x1, [x1, #0x668]
ldr x1, [x1]

GiantPluto

#include <string.h>
#include <stdio.h>

#include <switch.h>

static Handle g_port;
static uint64_t g_procID;

#define MODULE_HBL 111

GiantPluto

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <stdbool.h>

typedef uint32_t u32;
typedef uint8_t u8;