Hacking Discussion Info on SHA-256 hashes on FS patches

[TAOKTC]

Thank you for noticing it! This new release should correct this issue

Perfect ! I just tested it and the missing folders are created with all ips files. Thanks again !

 

[mrdude]

@Dogty

I noticed when you generate patches.ini in the app folder - the resulting ini generates this:

[Loader:4AA57ABADF2922FB]
nosigchk=0:0x5FC6:0x1:01,00

It should generate this:

[Loader:4AA57ABADF2922FB]
.nosigchk=0:0x5FC6:0x1:01,00

Notice the missing period at the start of nosigchk.

 

[ShadowOne333]

@Dogty

I noticed when you generate patches.ini in the app folder - the resulting ini generates this:

[Loader:4AA57ABADF2922FB]
nosigchk=0:0x5FC6:0x1:01,00

It should generate this:

[Loader:4AA57ABADF2922FB]
.nosigchk=0:0x5FC6:0x1:01,00

Notice the missing period at the start of nosigchk.

@impeeza did report that issue with the dot here:

Hello there, I just make some test:

Put again SD:/switch/title.keys and test, the decryption now works fine.

change the installation folder on the card to SD:/switch/sigpatchesgenerator, and all works fine, the Keys.dat file is found without problem.

With no SD:/bootloader/patches.ini file, When run loader or FS a new patches.ini file is generated using only LF end line.

If I put a SD:/bootloader/patches.ini with CR/LF or LF end lines the generated patches.ini have all end lines with the same format.

Now the only problem is what the new patches.ini generated by loader, lacks of the "." on the section ".nosigchk" even if you have or not patches.ini file on SD:/bootloader/

if my old patches.ini do not have sections for the firmware or the loader, they are created, (the loader section without the ".")

View attachment 323528left the correct entry, right the generated one.


@dogty have you do think about enable the touch screen on the interface?

it seems like dogcsty did upload a pack with the fix, but he seems to have deleted it, the next one available after that one is this, possibly already has the dot fix, but I'm not sure

Thank you for noticing it! This new release should correct this issue

 

[dogcsty]

@Dogty

I noticed when you generate patches.ini in the app folder - the resulting ini generates this:

[Loader:4AA57ABADF2922FB]
nosigchk=0:0x5FC6:0x1:01,00

It should generate this:

[Loader:4AA57ABADF2922FB]
.nosigchk=0:0x5FC6:0x1:01,00

Notice the missing period at the start of nosigchk.

I normally corrected this with the latest release

 

[mrdude]

I normally corrected this with the latest release

Where is it uploaded? I downloaded the latest attached file from post #420 about 2 hours ago and it had the error, now the attachment is gone?

 

[mrdude]

Here you go people, ftp stuff added so you can send your atmosphere ips patch files straight to the switch via ftp.

This should only send files with the ips extension that are in the atmosphere folder and file size is limited to 100 bytes per ips file as no ips files are larger than this.

 

[alba93]

Here you go people, ftp stuff added so you can send your atmosphere ips patch files straight to the switch via ftp.

This should only send files with the ips extension that are in the atmosphere folder and file size is limited to 100 bytes per ips file as no ips files are larger than this.

great job

 

[mrdude]

FYI for those that will be using future builds of the sigpatch ips creator I made, here are the modded hactool files if you want to compile hactool yourself. I have added a switch --disableoutput, which will be used in the program to make decompression of files faster. Hactool will still function the same as before but will just have this as an extra option.

Example usage:
hactool -k keys.dat --disableoutput --exefsdir=exefs --romfsdir=. edfc4e338aba2ee7f326e0307deb6a37.nca
hactool -k keys.dat --disableoutput -t pk21 nx/package2 --outdir=.
hactool -k keys.dat --disableoutput -t ini1 INI1.bin --outdir=.
hactool -t kip1 --disableoutput --uncompressed=FS-dec.kip1 FS.kip1

EDIT: Re-uploaded to skip using prod.keys if it exists in your environmental paths if you use a key file flag.

 

[urherenow]

Here you go people, ftp stuff added so you can send your atmosphere ips patch files straight to the switch via ftp.

This should only send files with the ips extension that are in the atmosphere folder and file size is limited to 100 bytes per ips file as no ips files are larger than this.

Small oopsie in the included keys.dat:

key_area_key_application_0b =
key_area_key_application_0b = <--- instead of 0c

may cause problems if people copy and paste just the value without noticing the wrong/duplicate key name...

 

[mrdude]

Small oopsie in the included keys.dat:

key_area_key_application_0b =
key_area_key_application_0b = <--- instead of 0c

may cause problems if people copy and paste just the value without noticing the wrong/duplicate key name...

Thanks I'l fix and upload.

EDIT: Some small fixes, also implemented the new hactool with the extra flag - so if you don't trust this hactool version that's included, you can compile your own from the files I posted above.

 

[urherenow]

The new upload doesn't contain the keys.dat template at all. Was that intentional? Not that I would want it overwriting my populated one (and perhaps don't need since I have a full file in my profile's .switch folder anyway...)

 

[mrdude]

The new upload doesn't contain the keys.dat template at all. Was that intentional? Not that I would want it overwriting my populated one (and perhaps don't need since I have a full file in my profile's .switch folder anyway...)

It gets generated automatically when no keys.dat exists.

 

[urherenow]

Well, this is embarrassing. I can't get a single thing to work. ES/ES2/FS/NFIM, "unable to find the sdk version.... I can't decrypt the firmware..."

Loader (see attached pics)... and if I uncheck both "auto Clean" boxes, I'm left with the file"dumped_loader" in the directory. Not dec-loader.bin. I even painstakingly let the app generate a new template, and entered the keys into the app 1 by 1, followed by using the "write keys" button, in case something silly like line endings may have messed up the previous keys.dat file. This is with package3 from Atmosphere1.3.2, and the firmware files from 14.1.2.

 

[mrdude]

Well, this is embarrassing. I can't get a single thing to work. ES/ES2/FS/NFIM, "unable to find the sdk version.... I can't decrypt the firmware..."

Loader (see attached pics)... and if I uncheck both "auto Clean" boxes, I'm left with the file"dumped_loader" in the directory. Not dec-loader.bin. I even painstakingly let the app generate a new template, and entered the keys into the app 1 by 1, followed by using the "write keys" button, in case something silly like line endings may have messed up the previous keys.dat file. This is with package3 from Atmosphere1.3.2, and the firmware files from 14.1.2.

It's telling you it can't find the pattern - so the pakage3 file must be corrupt - redownload atmosphere from the github. Also make sure you are using the hactool version posted with the program or it won't work.

 

[urherenow]

It's telling you it can't find the pattern - so the pakage3 file must be corrupt - redownload atmosphere from the github. Also make sure you are using the hactool version posted with the program or it won't work.

nope... it actually couldn't decrypt anything. It **REALLY** did not like the prod.keys file that I had in my profile's .switch folder. You may want to patch that out of hactool completely, so it ONLY looks for and uses keys.dat in ./tools (or you can also use the command line option to specify keys.dat when invoking hactool).

I have it sorted now on my end (got the patches, even though I had them anyway... I'm just fooling around for now).

 

[mrdude]

nope... it actually couldn't decrypt anything. It **REALLY** did not like the prod.keys file that I had in my profile's .switch folder. You may want to patch that out of hactool completely, so it ONLY looks for and uses keys.dat in ./tools (or you can also use the command line option to specify keys.dat when invoking hactool).

I have it sorted now on my end (got the patches, even though I had them anyway... I'm just fooling around for now).

The code already has the key flag set when it tries to decrypt, I've no idea why hactool tried to use your prod.keys file as it shouldn't.

It's probably this code in utils.c that's causing the issue:

FILE *open_key_file(const char *prefix) {
    filepath_t keypath;
    filepath_init(&keypath);
    /* Use $HOME/.switch/prod.keys if it exists */
    char *home = getenv("HOME");
    if (home == NULL)
        home = getenv("USERPROFILE");
    if (home != NULL) {
        filepath_set(&keypath, home);
        filepath_append(&keypath, ".switch");
        filepath_append(&keypath, "%s.keys", prefix);
    }

I can remove that or comment it out.

 

[urherenow]

The code already has the key flag set when it tries to decrypt, I've no idea why hactool tried to use your prod.keys file as it shouldn't.

It's probably this code in utils.c that's causing the issue:

FILE *open_key_file(const char *prefix) {
    filepath_t keypath;
    filepath_init(&keypath);
    /* Use $HOME/.switch/prod.keys if it exists */
    char *home = getenv("HOME");
    if (home == NULL)
        home = getenv("USERPROFILE");
    if (home != NULL) {
        filepath_set(&keypath, home);
        filepath_append(&keypath, ".switch");
        filepath_append(&keypath, "%s.keys", prefix);
    }

I can remove that or comment it out.

you're quicker than me... I was just about to post that. Don't know the last time I've used mingw either, because I usually build in a ubuntu vm. Pretty sure last time I even used it was to make a PC executable of the SM64 RE...

it is a bug, though, because the intent should be not to look for it, if you specify the -k flag (I think).

 

[mrdude]

you're quicker than me... I was just about to post that. Don't know the last time I've used mingw either, because I usually build in a ubuntu vm. Pretty sure last time I even used it was to make a PC executable of the SM64 RE...

it is a bug, though, because the intent should be not to look for it, if you specify the -k flag (I think).

Here you go, replace this modded version with the one you had, that should ignore the prod.keys file if it exists in your home directory.

 

[urherenow]

Here you go, replace this modded version with the one you had, that should ignore the prod.keys file if it exists in your home directory.

Perfect! Works like a champ. Thanks a bunch!

 

[mrdude]

Perfect! Works like a champ. Thanks a bunch!

No worries, if you want to compile yourself just change the part of the code in utils.c to this:

FILE *open_key_file(const char *prefix) {
    filepath_t keypath;
    filepath_init(&keypath);
    char *home = getenv("HOME");
    
    if (keypath.os_path != "" || NULL) {
        /* Use $HOME/.switch/prod.keys if it exists and key flag is not set*/
      if (home == NULL)
          home = getenv("USERPROFILE");
      if (home != NULL) {
          filepath_set(&keypath, home);
          filepath_append(&keypath, ".switch");
          filepath_append(&keypath, "%s.keys", prefix);
      }
    }
    

    /* Load external keys, if relevant. */
    FILE *keyfile = NULL;
    if (keypath.valid == VALIDITY_VALID) {
        keyfile = os_fopen(keypath.os_path, OS_MODE_READ);
    }
    
    if (keypath.os_path != "" || NULL) {

      /* If $HOME/.switch/prod.keys don't exist, try using $XDG_CONFIG_HOME */
      if (keyfile == NULL) {
          char *xdgconfig = getenv("XDG_CONFIG_HOME");
          if (xdgconfig != NULL)
              filepath_set(&keypath, xdgconfig);
          else if (home != NULL) {
              filepath_set(&keypath, home);
              filepath_append(&keypath, ".config");
          }
          /* Keypath contains xdg config. Add switch/%s.keys */
          filepath_append(&keypath, "switch");
          filepath_append(&keypath, "%s.keys", prefix);
      }
      
    }

    if (keyfile == NULL && keypath.valid == VALIDITY_VALID) {
        keyfile = os_fopen(keypath.os_path, OS_MODE_READ);
    }

    return keyfile;
}

If should skip using prod.keys if a path has been set in the key flag. Hactool mods updated in the attachment a few post up to implement this change.