Hacking Discussion Info on SHA-256 hashes on FS patches

[crckd]

If you want to know where those hashes came, here is what I've got so far.

1. Download Firmware 11.0.1.zip and extract the contents.

2. 2 ncas will contains "nx" folder (fat32 and exfat). I don't yet know how to identity which specific nca but it's always around 3mb.

Spoiler: Firmware files

12/13/2020 03:43 PM 3,268,608 e399b2e4b955c41a211176371478e728.nca
12/13/2020 03:43 PM 3,286,528 2ce2f151943a80fc719bd4179d7f6270.nca
12/13/2020 03:43 PM 3,327,488 0fd89afc0d0f1ee7021084df503bcc19.nca
12/13/2020 03:43 PM 3,420,160 295926145fbd59982228a9c90f28c064.nca
12/13/2020 03:43 PM 3,430,912 5c24763e70d04b110b25cddb1ad79c4c.nca
12/13/2020 03:43 PM 3,499,520 683e91ab70dd03dc744e8bff803739e8.nca
12/13/2020 03:43 PM 3,665,920 7a9f1fcd81ac310985ba5a3c90516a4b.nca
12/13/2020 03:43 PM 3,775,488 da2887605681bb45a2fbfc24c754368e.nca
12/13/2020 03:43 PM 3,803,136 c38ed0eff5b83338e8f60a37a2047262.nca
12/13/2020 03:43 PM 3,806,208 18e2372b9fb75ed2f5bc44eebf122c02.nca
12/13/2020 03:43 PM 3,853,824 55c413b83f79870e91fa8464b2bcf0e3.nca

3. Extract the contents using hactool to get bct, package1 and package2.

Spoiler: hactool

hactool.exe -t nca --romfsdir=c:\out\2ce2f151943a80fc719bd4179d7f6270 2ce2f151943a80fc719bd4179d7f6270.nca
hactool.exe -t nca --romfsdir=c:\out\0fd89afc0d0f1ee7021084df503bcc19 0fd89afc0d0f1ee7021084df503bcc19.nca

01/24/2021 11:34 AM 10,240 bct
01/24/2021 11:34 AM 193,600 package1
01/24/2021 11:34 AM 2,793,984 package2

4. Extract the contents of package2 to get Kernel1.bin, Decrypted.bin and INI1.bin. In case it fails to extract, compile the latest hactool.

Spoiler: package2

hactool.exe -t pk21 package2 --outdir=.

01/24/2021 11:34 AM 10,240 bct
01/24/2021 11:34 AM 193,600 package1
01/24/2021 11:34 AM 2,793,984 package2
01/24/2021 12:11 PM 2,793,472 Kernel.bin
01/24/2021 12:11 PM 2,793,984 Decrypted.bin
01/24/2021 12:11 PM 2,342,260 INI1.bin

5. Extract the contents of INI1.bin to get FS.kip1

Spoiler: INI1.bin

hactool.exe -t ini1 INI1.bin --outdir=.


01/24/2021 11:34 AM 10,240 bct
01/24/2021 11:34 AM 193,600 package1
01/24/2021 11:34 AM 2,793,984 package2
01/24/2021 12:11 PM 2,793,472 Kernel.bin
01/24/2021 12:11 PM 2,793,984 Decrypted.bin
01/24/2021 12:11 PM 2,342,260 INI1.bin
01/24/2021 12:52 PM 1,312,124 FS.kip1
01/24/2021 12:52 PM 152,840 Loader.kip1
01/24/2021 12:52 PM 308,884 NCM.kip1
01/24/2021 12:52 PM 99,840 ProcessMana.kip1
01/24/2021 12:52 PM 75,112 sm.kip1
01/24/2021 12:52 PM 94,980 spl.kip1

6. SHA-256 of FS.kip1 would be the filename of the FS patch.

Spoiler: SHA-256

C:\out\2ce2f151943a80fc719bd4179d7f6270\nx>"c:\Program Files\7-Zip\7z.exe" h -scrcsha256 FS.kip1
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
E399156E844EB0AA3CC5152979961C879F5E90696C1224A1BBE0FF1BCDBFD7DC 1312124 FS.kip1
---------------------------------------------------------------- ------------- ------------
E399156E844EB0AA3CC5152979961C879F5E90696C1224A1BBE0FF1BCDBFD7DC 1312124

C:\out\0fd89afc0d0f1ee7021084df503bcc19\nx>"c:\Program Files\7-Zip\7z.exe" h -scrcsha256 FS.kip1
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
0BA15BB304B505633B6DA6B2C6E991B6A06EBAFB3378DF02BF6B494075976F06 1350048 FS.kip1
---------------------------------------------------------------- ------------- ------------
0BA15BB304B505633B6DA6B2C6E991B6A06EBAFB3378DF02BF6B494075976F06 1350048

7. Decompress FS.kip1

Spoiler: kip1decomp

kip1decomp d FS.kip1 FS.decomp.kip1

8. Open FS.decomp.kip1 using a hex editor. The offset on 11.0.1 is 0E3014 and replacing 4 bytes with 1F2003D5 which is NOP on ARM64 arch.


Hope someone can make a script to find the sha256 of fs.kip1 and the offset to automate FS patching.

 

[mrdude]

Great post, I've been pulling my hair out (luckily we a re locked down as I now have lots of it), trying to find how these hashes are generated. I spent hours extracting stuff etc. I searched the net for clues and posted on here, but to no avail, Now I at least know It can help me immensely on my next quest which will be to see if this can be automated with a script.

Thanks.

 

[LyuboA]

what about es patches

 

[mrdude]

Hi I followed your guide, what I did notice is that the offset in IDA is different from the offset in HXD, this is what the offset is for the patch in ida:

Does that byte pattern look like what you (OP) are patching?

 

[crckd]

Hi,
I haven't verify/confirm the bytes before patch is applied.
I was planning to do one of following to verify :
a. compare FS.decomp.kip1from different firmware version
b. dump or browse the memory region on a running Switch with and without the fs patch and compare.
c. check the vcdiff files used on ChoiDujour

 

[mrdude]

Hi,
I haven't verify/confirm the bytes before patch is applied.
I was planning to do one of following to verify :
a. compare FS.decomp.kip1from different firmware version
b. dump or browse the memory region on a running Switch with and without the fs patch and compare.
c. check the vcdiff files used on ChoiDujour

My mistake - offset in IDA is correct, I was using a Switch64.dll to load the decompressed kip into ida, however in IDA 7.5 the python loaders weren't working - that's why I used the dll file, I switched back to IDA 7.2 and used the python loader - nxo64.py and the offsets now work properly.

The picture I posed above shows where the firmware is patched - and the offset is shown properly in ida (green square)

 

[mrdude]

@crckd.

Now that I've had a look at the different firmwares - I can say that it will be indeed possible to automate this :-).

As you can see from the picture - the bytes after where we patch is the same for most newer firmware, this makes it easy to find. A small batch file can be written to do the part of dumping the firmware and extracting. Then we can mod the python files I made for autoips to get the sha256 values, search for the hex and write the ips patch - just need to search for the stuff in the pink boxes (from 1E) and subtract the 5 bytes from the address that it finds - then write the patch to that address.

 

[ShadowOne333]

@crckd.

Now that I've had a look at the different firmwares - I can say that it will be indeed possible to automate this :-).

As you can see from the picture - the bytes after where we patch as the same for most newer firmware, this makes it easy to find. A small batch file can be written to do the part of dumping the firmware and extracting. Then we can mod the python files I made for autoips to get the sha256 values, search for the hex and write the ips patch - just need to search for the stuff in the pink boxes and subtract the 4 bytes from the address that it finds.

Oh boy!
Finally, making ES/FS patches is no longer an obscure thing to do! Thanks @crckd!
Will be looking forward to what you can do to automate the process.
I will also create a Linux bash script, like with the Loader script, so users have more options

 

[mrdude]

Oh boy!
Finally, making ES/FS patches is no longer an obscure thing to do! Thanks @crckd!
Will be looking forward to what you can do to automate the process.
I will also create a Linux bash script, like with the Loader script, so users have more options

You need keys file to do it - that was missing from the first post - Example:

(cd to folder that contains hactool + keys.dat)
cd "C:\Users\MrDude\Desktop\xxx"

(create a dumped folder in the directory you just cd'd to)
mkdir dumped

(extract firmware files around 3 megabytes and put in firmware folder - (dump them first))
for %f in (firmware/*.*) do hactool.exe -k keys.dat -t nca --romfsdir=dumped/ firmware/%f

(Find our files we need: nx folder)
dir *package2*.* /s

(create a folder called dumps)
mkdir dumps

(dump extact package2 files to the dumps folder).
hactool.exe -k keys.dat -t pk21 dumped/nx/package2 --outdir=dumps/

(make a folder called files to dump ini1 into)
mkdir files

(extract INI1.bin)
hactool.exe -k keys.dat -t ini1 dumps/INI1.bin --outdir=files/

(In files directory FS.kip1 - use sha256 of this compressed file for name of patch)

(Decompress FS.kip1)
kip1decomp.exe d files/FS.kip1 FS.decomp.kip1

Now open FS.decomp.kip1 in hxd hex editor and search for the hex shown in the pink box (from 1E), look in blue box where to put the patch address for the ips file.


(For a batch file - replace % with %%)

 

[DarkMatterCore]

Identifying which NCAs are the correct ones is a trivial operation. The output from:

hactool -t nca --disablekeywarns --header=hdr.bin [nca_file]

Should yield a 0xC00 byte-long decrypted NCA header, saved to "hdr.bin". The byte at 0x205 will always match 0x04 (Data NCA), and the little-endian unsigned 64 bit integer at 0x210 will always match either 0x0100000000000819 (BootImagePackage, FAT32-only firmware) or 0x010000000000081B (BootImagePackageExFat, firmware with exFAT support).

Alternatively, you can also get these in extracted form straight from a Switch using one of the proof-of-concept builds from nxdumptool-rewrite - this is still not ready for a release yet, but for this particular task it works wonders. That way, you won't need to wait until a full firmware dump is released online, nor will you need to identify the correct NCAs using a scripted loop.

 

[crckd]

Great! thanks for all inputs!
a quick cpp code to get the offset

#include <stdio.h>
#include <iostream>

using namespace std;

typedef unsigned char BYTE;

long getFileSize(FILE *file)
{
    long lCurPos, lEndPos;
    lCurPos = ftell(file);
    fseek(file, 0, 2);
    lEndPos = ftell(file);
    fseek(file, lCurPos, 0);
    return lEndPos;
}

int main(int argc, char *argv[])
{
        if (argc != 2)
    {
        cout << "usage : " << argv[0] << " filename" << endl;
    }
    else
    {
    BYTE *fileBuf;
    FILE *file = fopen( argv[1], "rb");
        if (file == 0 )
        {
            cout << "Could not open specified file" << endl;
        }
        else
        {
            long fileSize = getFileSize(file);
            fileBuf = new BYTE[fileSize];
            fread(fileBuf, fileSize, 1, file);

            for (int i = 0; i < fileSize - 1; i++){           

                if (fileBuf[i] == 0xFE && fileBuf[i+1] == 0x97 && fileBuf[i+7] == 0x1E && fileBuf[i+8] == 0x42 && fileBuf[i+9] == 0xB9 && fileBuf[i+10] == 0x1F && fileBuf[i+11] == 0xC1 && fileBuf[i+12] == 0x42 && fileBuf[i+13] == 0x71){
                    printf("Here   : %02X\n", i+2);
                    
                }
            }
            delete[]fileBuf;
            fclose(file);                       
        }
    }
    return 0;
}

 

[mrdude]

Here's that c++ code compiled:

usage: fsOffset FS.decomp.kip1

 

[ShadowOne333]

Here's that c++ code compiled:

usage: fsOffset FS.decomp.kip1

Bundling the code alongside a quick ReadMe for setup could be good too.
I believe I can compile the C code on Linux and create a 32bit binary for it, so anyone can use it on any machine.
I'll give it a try.

 

[mrdude]

Identifying which NCAs are the correct ones is a trivial operation. The output from:

hactool -t nca --disablekeywarns --header=hdr.bin [nca_file]

Should yield a 0xC00 byte-long decrypted NCA header, saved to "hdr.bin". The byte at 0x205 will always match 0x04 (Data NCA), and the little-endian unsigned 64 bit integer at 0x210 will always match either 0x0100000000000819 (BootImagePackage, FAT32-only firmware) or 0x010000000000081B (BootImagePackageExFat, firmware with exFAT support).

Alternatively, you can also get these in extracted form straight from a Switch using one of the proof-of-concept builds from nxdumptool-rewrite - this is still not ready for a release yet, but for this particular task it works wonders. That way, you won't need to wait until a full firmware dump is released online, nor will you need to identify the correct NCAs using a scripted loop.

On windows that byte pattern is different at offset:210, due the endianess being different from linux it will look like this:

1B 08 00 00 00 00 00 01
and

19 08 00 00 00 00 00 01

Still, thanks for the info. Although it takes longer to do that way than just dumping the files near 3 meg in size.

For those that want to do that way - this command works will from command prompt in windows: Dump to folder called headers

for %f in (firmware/*.*) do hactool -k keys.dat -t nca --disablekeywarns --header=headers/%f firmware/%f

 

[DarkMatterCore]

On windows that byte pattern is different at offset:210, due the endianess being different from linux it will look like this:

1B 08 00 00 00 00 00 01
and

19 08 00 00 00 00 00 01

Still, thanks for the info. Although it takes longer to do that way than just dumping the files near 3 meg in size.

For those that want to do that way - this command works will from command prompt in windows: Dump to folder called headers

for %f in (firmware/*.*) do hactool -k keys.dat -t nca --disablekeywarns --header=headers/%f firmware/%f

That's because I didn't provide byte patterns, but unsigned 64-bit integer values. It's not gonna look any different under other OS - the data is stored using little-endian byte order because that's what the Switch uses.

 

[mrdude]

Done, that's me done the script now......

Use your own keys.dat file....put in the folder as shown in the picture.

Make a firmware folder and put your firmare files in it.

Click on run.bat and wait a few minutes until the ips is created, don't worry as the batch file will clean everything up for you.

You will need to edit run.bat to point to where you have python installed. You will need the bitstring module installed and python3.

Enjoy and mod to how you want :-)

 

[LyuboA]

Done, that's me done the script now......

Use your own keys.dat file....put in the folder as shown in the picture.

Make a firmware folder and put your firmare files in it.

Click on run.bat and wait a few minutes until the ips is created, don't worry as the batch file will clean everything up for you.

You will need to edit run.bat to point to where you have python installed. You will need the bitstring module installed and python3.

Enjoy and mod to how you want :-)

amazing thanks man
can the same be done for the es patches

 

[mrdude]

amazing thanks man
can the same be done for the es patches

I haven't looked at es patches, and I don't have the time too just now. I suppose it depends how many things are patched and if the byte patterns are similar between versions. If they are, it should just be a case of modding the scripts a little bit. Maybe you can look into it and let us know. Do you even need ES patches, what are they for?

 

[LyuboA]

I haven't looked at es patches, and I don't have the time too just now. I suppose it depends how many things are patched and if the byte patterns are similar between versions. If they are, it should just be a case of modding the scripts a little bit. Maybe you can look into it and let us know. Do you even need ES patches, what are they for?

well i`m not that good to do that but as far as i know es patches are for new firmware patching exefs_patches/es_patches
or we dont need these anymore ??

 

[crckd]

Great! You can include it on your AutoIPS thread to be more visible to others. I'll be looking on ES patches also