Hacking Discussion Info on SHA-256 hashes on FS patches

dogcsty · Aug 9, 2022

ZachyCatGames said:
Wrote a rough impl of this b/c I'm bored, it'll dump text, rodata, data, and bss of w/e program you give it the programId for. The dump will be formatted like if you opened w/e program in ida

Thanks that was what I was looking for at the beginning! I am to the point where I've already decompressed every file I needed with the hactool port though but I would have definitely gone with your route if I knew the api to do so. I'll save your code for future use for sure!

mrdude · Aug 10, 2022

FYI, NFIM patches now implemented for testing into the non python pc version of IPS patch maker. I only tested a couple of firmwares to check they were being written. Binary data matches with the patches created with the python scripts so I assume these work fine.

impeeza · Aug 10, 2022

mrdude said:
FYI, NFIM patches now implemented for testing into the non python pc version of IPS patch maker. I only tested a couple of firmwares to check they were being written. Binary data matches with the patches created with the python scripts so I assume these work fine. Anyway for those that want to test I'll attach the new build so you can report any errors/issues that you find.

Well, I took seriously,

Downloaded all version of Atmosphère from GitHub:

0.07.0
0.07.1
0.07.2
0.07.3
0.08.1
0.08.3
0.09.2
0.09.3
0.09.4
0.10.0 prerelease
0.10.1
0.10.2
0.10.3
0.10.4
0.10.5
0.11.0 Prerelease
0.11.1
0.12.0
0.13.0
0.14.0
0.14.1
0.14.2
0.14.3
0.14.4
0.15.0
0.16.0 Prerelease 1
0.16.0 Prerelease 2
0.16.1 Prerelease 1
0.16.2
0.17.0
0.17.1
0.18.0
0.18.1
0.19.0
0.19.1
0.19.2
0.19.3
0.19.4
0.19.5
0.20.0
0.20.1
1.00.0
1.00.0 Prerelease
1.01.0 Prerelease
1.01.1
1.02.0 Prerelease
1.02.1
1.02.2
1.02.3
1.02.4
1.02.5
1.02.6
1.03.0
1.03.1
1.03.2

And from "Darsti" site all firmwares (names from DAT file):

Firmware 01.0.0 (NintendoSDK Firmware for NX 1.0.0-15) (0.0.0.0450) (Cartridge).zip
Firmware 01.0.0 (NintendoSDK Firmware for NX 1.0.0-15) (0.0.0.0450).zip
Firmware 01.0.0-89d9b_r49916 (NintendoSDK Firmware for NX 1.0.0-7) (0.0.0.0330) (Pre-Release).zip
Firmware 02.0.0 (NintendoSDK Firmware for NX 2.0.0-15) (0.0.1.0260).zip
Firmware 02.1.0 (NintendoSDK Firmware for NX 2.1.0-0) (0.0.2.0090).zip
Firmware 02.2.0 (NintendoSDK Firmware for NX 2.2.0-1) (0.0.3.0020).zip
Firmware 02.3.0 (NintendoSDK Firmware for NX 2.3.0-0) (0.0.4.0020).zip
Firmware 03.0.0 (NintendoSDK Firmware for NX 3.0.0-10.0) (3.0.0.0410).zip
Firmware 03.0.1 (NintendoSDK Firmware for NX 3.0.1-0.0) (3.0.1.0050).zip
Firmware 03.0.2 (NintendoSDK Firmware for NX 3.0.2-0.0) (3.0.2.0020).zip
Firmware 04.0.0 (NintendoSDK Firmware for NX 4.0.0-4.0) (4.0.0.0200).zip
Firmware 04.0.1 (NintendoSDK Firmware for NX 4.0.1-0.0) (4.0.1.0010).zip
Firmware 04.1.0 (NintendoSDK Firmware for NX 4.1.0-0.0) (4.1.0.0050).zip
Firmware 05.0.0 (NintendoSDK Firmware for NX 5.0.0-3.0) (5.0.0.0430).zip
Firmware 05.0.1 (NintendoSDK Firmware for NX 5.0.1-0.0) (5.0.1.0030).zip
Firmware 05.0.2 (NintendoSDK Firmware for NX 5.0.2-0.0) (5.0.2.0040).zip
Firmware 05.1.0 (NintendoSDK Firmware for NX 5.1.0-3.0) (5.1.0.0080).zip
Firmware 06.0.0 (NintendoSDK Firmware for NX 6.0.0-4.0) (6.0.0.0310) (Pre-Release).zip
Firmware 06.0.0 (NintendoSDK Firmware for NX 6.0.0-5.0) (6.0.0.0360).zip
Firmware 06.0.1 (NintendoSDK Firmware for NX 6.0.1-1.0) (6.0.1.0010).zip
Firmware 06.1.0 (NintendoSDK Firmware for NX 6.1.0-4.0) (6.1.0.0090).zip
Firmware 06.2.0 (NintendoSDK Firmware for NX 6.2.0-1.0) (6.2.0.0040).zip
Firmware 07.0.0 (NintendoSDK Firmware for NX 7.0.0-5.0) (7.0.0.0200).zip
Firmware 07.0.1 (NintendoSDK Firmware for NX 7.0.1-1.0) (7.0.1.0030).zip
Firmware 08.0.0 (NintendoSDK Firmware for NX 8.0.0-4.99) (8.0.0.0530).zip
Firmware 08.0.1 (NintendoSDK Firmware for NX 8.0.1-1.0) (8.0.1.0080).zip
Firmware 08.1.0 (NintendoSDK Firmware for NX 8.1.0-1.0) (8.1.0.0120).zip
Firmware 08.1.1 (NintendoSDK Firmware for NX 8.1.1-100.0) (8.1.1.0030).zip
Firmware 09.0.0 (NintendoSDK Firmware for NX 9.0.0-4.0) (9.0.0.0440).zip
Firmware 09.0.1 (NintendoSDK Firmware for NX 9.0.1-1.0) (9.0.1.0100).zip
Firmware 09.1.0 (NintendoSDK Firmware for NX 9.1.0-1.0) (9.1.0.0240).zip
Firmware 09.2.0 (NintendoSDK Firmware for NX 9.2.0-1.0) (9.2.0.0020).zip
Firmware 10.0.0 (NintendoSDK Firmware for NX 10.0.0-6.0) (10.0.0.0360).zip
Firmware 10.0.1 (NintendoSDK Firmware for NX 10.0.1-1.0) (10.0.1.0020).zip
Firmware 10.0.2 (NintendoSDK Firmware for NX 10.0.2-1.0) (10.0.2.0040).zip
Firmware 10.0.3 (NintendoSDK Firmware for NX 10.0.3-1.0) (10.0.3.0020).zip
Firmware 10.0.4 (NintendoSDK Firmware for NX 10.0.3-1.0) (10.0.4.0020).zip
Firmware 10.1.0 (NintendoSDK Firmware for NX 10.1.0-1.0) (10.1.0.0120).zip
Firmware 10.2.0 (NintendoSDK Firmware for NX 10.2.0-1.0) (10.2.0.0060).zip
Firmware 11.0.0 (NintendoSDK Firmware for NX 11.0.0-5.0) (11.0.0.0440).zip
Firmware 11.0.1 (NintendoSDK Firmware for NX 11.0.1-1.0) (11.0.1.0020).zip
Firmware 11.0.1 (NintendoSDK Firmware for NX 11.0.1-1.0) (11.0.1.1000).zip
Firmware 12.0.0 (NintendoSDK Firmware for NX 12.0.0-4.0) (12.0.0.2520).zip
Firmware 12.0.1 (NintendoSDK Firmware for NX 12.0.1-1.0) (12.0.1.0040).zip
Firmware 12.0.2 (NintendoSDK Firmware for NX 12.0.2-1.0) (12.0.2.0020).zip
Firmware 12.0.3 (NintendoSDK Firmware for NX 12.0.3-1.0) (12.0.3.0020).zip
Firmware 12.1.0 (NintendoSDK Firmware for NX 12.1.0-1.0) (12.1.0.0120).zip
Firmware 13.0.0 (NintendoSDK Firmware for NX 13.0.0-4.0) (13.0.0.0220).zip
Firmware 13.1.0 (NintendoSDK Firmware for NX 13.1.0-1.2) (13.1.0.0160).zip
Firmware 13.2.0 (NintendoSDK Firmware for NX 13.2.0-1.0) (13.2.0.0020).zip
Firmware 13.2.1 (NintendoSDK Firmware for NX 13.2.1-1.0) (13.2.1.0080).zip
Firmware 14.0.0 (NintendoSDK Firmware for NX 14.0.0-4.0) (14.0.0.1240).zip
Firmware 14.1.0 (NintendoSDK Firmware for NX 14.1.0-1.0) (14.1.0.0020).zip
Firmware 14.1.1 (NintendoSDK Firmware for NX 14.1.1-1.0) (14.1.1.0020).zip
Firmware 14.1.2 (NintendoSDK Firmware for NX 14.1.2-1.0) (14.1.2.0060).zip
Firmware 14.1.2 (NintendoSDK Firmware for NX 14.1.2-1.0) (14.1.2.5060).zip

Then I did generate all files for Atmosphère, ES and NFIM files using the latest Python scripts and the latest Windows Program.

The Phyton scripts for Atmosphère versions between 0.07.0 and 0.10.3 give the error:

Loader not found in C:\AutoIPS\ATM0103\fusee-secondary.bin - exiting script!

For version 0.10.4 & 0.10.5 the error is:

Can't find the byte pattern, unable to create the ips file :-([/INDENT][/INDENT][/INDENT]
[INDENT][INDENT][INDENT]Check GBATemp for an update

The Windows Program for Atmosphère versions between 0.07.0 and 0.08.3 give the error:

"Error is: Not Enough data"

The Windows Program generate the patches for Atmosphère versions between 0.09.2 and 1.03.2 without error

The patches for Atmosphère 0.11.0, 0.11.1 and 0.12.0 are different between Python Scripts and Windows program

The files for atmosphère 0.13.0 and newer are the same between Python Scripts and Windows Program.

The Next image is a file comparison between the files generated for ES using Python Scripts alt (right) and Windows Program (left):

For firmware version between 02.0.0 and 04.1.0 the Phyton Scripts give the eror: "Hex match not found" but generate the IPS file

-Edit- on the image above the patches for firmware 14.x.x are shown as different but I did a mistake and generate these using ES-Alt.py file instead of: ES-Alt-AutoIPS.py when corrected, the files generated by the windows program and ES-Alt-AutoIPS.py script are the same, sorry.

The next image is a file comparison between the files generated for NIFM patches using Python Scripts (right) and Windows Program (left):

Note:
For firmware version 05.1.0 and lower the Phyton Scripts give the eror: "Hex match not found" but generate the IPS file

mrdude · Aug 10, 2022

@impeeza

The reason for those errors on older firmwares and Atmosphere is just because the code changed a lot between versions and the hex patterns to check are changed and not found in older versions. In the python scripts the loader patch is looking for the byte pattern for loader but then the case changed to Loader which failed because hex L and hex l are different, so I fixed that on the new program. I didn't bother checking patterns in old firmware or Atmosphere when you get past firmware version 7 because nobody uses that nowadays.
The reason there's a discrepancy between old patches and new patches is because the patches changed in older versions to newer versions and as patches already exist for these old versions I didn't think it worthwhile to make scripts to generate old pacthes for something nobody uses anymore as it would be a waste of time considering those that use old outof date firmware probably already have the patches for it anyway.

However the fact that patches are being generated when bytes patterns are not found needs looked at, so I will fix that - thanks for reporting.

As for NFIM, I checked verion 9.10 firmware in python and windows and can see the difference here:
Firmware 9.1.0
Probable patch offset location: 0x0000E2C0

50 41 54 43 48 E2 C0 00 08 E0 03 1F AA C0 03 5F D6 45 4F 46 - windows
50 41 54 43 48 00 E2 C0 00 08 E0 03 1F AA C0 03 5F D6 45 4F 46 - python

It seems I forgot to put a leading zero in the windows program when the patch is written, so I'll need to check that patch creation routine to see what I missed. I'll check patches from ITJ to see what version is correct.

I've attached a new file with NFIM hopefully fixed, I tested various FW from 7.0.0 upwards and this version seems to fix the issues, also I did the same changes to the ES patch creation routine and put in an error check so that if the patch offset wasn't found it shouldn't generate a patch.

EDIT: Reuploaded - forgot to include Loader checks + modded loader patch writing routine.

mrdude · Aug 10, 2022

@impeeza

Post above reuploaded as I fixed some issues, changed the Loader search routine (it's a little slower), and added some sounds to let you know if the patch was successful or failed. Loader patches will only be generated from Atmosphere 0.8.5 and above and there was a big code change since that point and old patches are arleady available, so no need to make new ones for those as they are obsolete now anyway.

ShadowOne333 · Aug 10, 2022

mrdude said:
@impeeza

Post above reuploaded as I fixed some issues, changed the Loader search routine (it's a little slower), and added some sounds to let you know if the patch was successful or failed. Loader patches will only be generated from Atmosphere 0.8.5 and above and there was a big code change since that point and old patches are arleady available, so no need to make new ones for those as they are obsolete now anyway.

I think there was an issue with the uploading of the file, as the previous post doesn't show any downloads available anymore.

mrdude · Aug 10, 2022

ShadowOne333 said:
I think there was an issue with the uploading of the file, as the previous post doesn't show any downloads available anymore.

Sorry about that, I uploaded the wrong file - I'll reupload in a bit.

Edit: This should be the proper version. If there's no more bugs I'll start on fs stuff.

deejay87 · Aug 10, 2022

mrdude said:
Sorry about that, I uploaded the wrong file - I'll reupload in a bit.

Edit: This should be the proper version. If there's no more bugs I'll start on fs stuff.

Hi, i have test and have the box msg error "main_dec not found" (ES firmware 14.1.2)

mrdude · Aug 10, 2022

deejay87 said:
Hi, i have test and have the box msg error "main_dec not found" (ES firmware 14.1.2)

Can you tell me the button combo of what you did to bring up that - it's probably a variable name I used when changing the loader routine and it's affected the es stuff.

I re-uploaded the file and it says, 0 views so you must have the old one I uploaded accidentaly.

deejay87 · Aug 10, 2022

mrdude said:
Can you tell me the button combo of what you did to bring up that - it's probably a variable name I used when changing the loader routine and it's affected the es stuff.

Or do you have the correct keys installed ? - that shouldn't matter as I put an error check in for that.
key_area_key_application_0d = xx
package2_key_0d = xx

I've tried about every button combo and I can't get that error to come up.

Oups right, my fault , i use the wrong keys
It work

impeeza · Aug 11, 2022

mrdude said:
Sorry about that, I uploaded the wrong file - I'll reupload in a bit.

Edit: This should be the proper version. If there's no more bugs I'll start on fs stuff.

Excellent, comparing the patches Generated between the Old Python Scripts and the newest Windows program:

Old Scripts cannot generate Patches for Atmosphère <= 0.10.5 so no comparison there

The patches for Atmosphère 0.11.0-Prerelease, 0.11.1 & 0.12.0 still are different between Python and Windows App generated.

The low speed is almost not noticeable, and the ding at end is a very nice tweak

Now all the patches for Atmosphère >= 0.13.0 are the same :hrth:

For the ES patches the only different are:
02.0.0, 02.1.0, 02.2.0, 02.3.0, 03.0.0, 03.0.1, 03.0.2, 04.0.0, 04.0.1, 04.1.0, but they are very old firmwares, I think I am the only one with a SYSNAND still on 04.1.0

For the NFIM patches the patches for Firmware > 05.1.0 are exactly the same between the ones generated with the Python Scripts and the Windows Application. :bow:

We owe you a lot of beer :grog:

mrdude · Aug 11, 2022

impeeza said:
Excellent, comparing the patches Generated between the Old Python Scripts and the newest Windows program:

Old Scripts cannot generate Patches for Atmosphère <= 0.10.5 so no comparison there

The patches for Atmosphère 0.11.0-Prerelease, 0.11.1 & 0.12.0 still are different between Python and Windows App generated.

The low speed is almost not noticeable, and the ding at end is a very nice tweak

Now all the patches for Atmosphère >= 0.13.0 are the same

For the ES patches the only different are:
02.0.0, 02.1.0, 02.2.0, 02.3.0, 03.0.0, 03.0.1, 03.0.2, 04.0.0, 04.0.1, 04.1.0, but they are very old firmwares, I think I am the only one with a SYSNAND still on 04.1.0

For the NFIM patches the patches for Firmware > 05.1.0 are exactly the same between the ones generated with the Python Scripts and the Windows Application.

We owe you a lot of beer

Yes, old Atmosphere and firmware below 7.0 are not supported and probably won't be - I should add an sdk check to quit if sdk under 7.x is detected. I can add a web link to old patches or create a database with all the old patches in it. This program is really for newer patches and upcoming releases. Thanks for testing and bug finding - just now I am more concerned about finding bugs in the code that's been written, so you should only test with newer firmware above 7.x

Atmosphère 0.11.0-Prerelease, 0.11.1 & 0.12.0 with python scripts are different because the python scripts are wrong and look for Loader rather than loader - there is a difference in case, so the pc app is probaly correct, but I'll need to decompile with ida to check, when I get some time.

mrdude · Aug 11, 2022

FYI FS for those following the PC app I am currently making, I have now implemented FS patching. This is a little slow for now due to the extraction process with hactool - it's doing this for fat and exfat files at the same time.... (so limit your keys to what are in the keys template or it will take longer).

I should probably put the hactool stuff on a new thread/process to make it faster, but for now I am only concerned about the patch creation - not the time it takes.

Anyway, for those that want to test - here you go. If you find bugs (apart from above time issues) let me know.

impeeza · Aug 11, 2022

mrdude said:
FYI FS for those following the PC app I am currently making, I have now implemented FS patching. This is a little slow for now due to the extraction process with hactool - it's doing this for fat and exfat files at the same time.... (so limit your keys to what are in the keys template or it will take longer).

I should probably put the hactool stuff on a new thread/process to make it faster, but for now I am only concerned about the patch creation - not the time it takes.

Anyway, for those that want to test - here you go. If you find bugs (apart from above time issues) let me know.

Will test this night

deejay87 · Aug 11, 2022

mrdude said:
FYI FS for those following the PC app I am currently making, I have now implemented FS patching. This is a little slow for now due to the extraction process with hactool - it's doing this for fat and exfat files at the same time.... (so limit your keys to what are in the keys template or it will take longer).

I should probably put the hactool stuff on a new thread/process to make it faster, but for now I am only concerned about the patch creation - not the time it takes.

Anyway, for those that want to test - here you go. If you find bugs (apart from above time issues) let me know.

perfect on 14.1.2

mrdude · Aug 11, 2022

deejay87 said:
perfect on 14.1.2

Thanks, also I found why hactool was taking a while to extract the files, It's because it generates an output during extraction. However if you do the same thing for extraction with a batch file and run it with no output like this:

run.bat >nul

Output gets suppressed and extraction is far faster, in python code you can run a subprocess and put this at the end "stdout=subprocess.DEVNULL" - that's why the python scripts are faster for now.
In c# you can do something like this.

Code:

Process nca = new Process();
nca.StartInfo.FileName = "tools//hactool.exe";
nca.StartInfo.Arguments = " -t nca --keyset=tools//keys.dat --section0dir=Temp//ExFat " + '"' + NCA_dir + EXFAT + '"';
nca.StartInfo.UseShellExecute = false;
nca.StartInfo.RedirectStandardOutput = false;
nca.StartInfo.CreateNoWindow = true;
nca.Start();
nca.WaitForExit();
nca.Close();

Does anyone know how to change that to stop hactool running in the background without output? This will make extraction far quciker. I know I can generate a batch and run that, but I don't want to do it like that.

This works from cmd line:

Code:

hactool -t nca --keyset=keys.dat --section0dir=Temp/Fat 8d9c654ef632ffdb8928a789c8d41556.nca >NUL

In c# this doesn't work...????

Code:

nca.StartInfo.Arguments = " -t nca --keyset=tools//keys.dat --section0dir=Temp//ExFat " + '"' + NCA_dir + EXFAT + '"' + " >NUL";

No idea why the above doesn't work - as I'm not used to c# yet, Does anyone know how to do that?

impeeza · Aug 11, 2022

mrdude said:
Thanks, also I found why hactool was taking a while to extract the files, It's because it generates an output during extraction. However if you do the same thing for extraction with a batch file and run it with no output like this:

run.bat >nul

Output gets suppressed and extraction is far faster, in python code you can run a subprocess and put this at the end "stdout=subprocess.DEVNULL" - that's why the python scripts are faster for now.
In c# you can do something like this.

Code:

Process nca = new Process(); nca.StartInfo.FileName = "tools//hactool.exe"; nca.StartInfo.Arguments = " -t nca --keyset=tools//keys.dat --section0dir=Temp//ExFat " + '"' + NCA_dir + EXFAT + '"'; nca.StartInfo.UseShellExecute = false; nca.StartInfo.RedirectStandardOutput = false; nca.StartInfo.CreateNoWindow = true; nca.Start(); nca.WaitForExit(); nca.Close();

Does anyone know how to change that to stop hactool running in the background without output? This will make extraction far quciker. I know I can generate a batch and run that, but I don't want to do it like that.

This works from cmd line:

Code:

hactool -t nca --keyset=keys.dat --section0dir=Temp/Fat 8d9c654ef632ffdb8928a789c8d41556.nca >NUL

In c# this doesn't work...????

Code:

nca.StartInfo.Arguments = " -t nca --keyset=tools//keys.dat --section0dir=Temp//ExFat " + '"' + NCA_dir + EXFAT + '"' + " >NUL";

No idea why the above doesn't work - as I'm not used to c# yet, Does anyone know how to do that?

great work, sadly my C# knowledge is near 0, on VBS when you crate a proccess is a parameter to redirect output to null, but on C I don't know.

mrdude · Aug 11, 2022

impeeza said:
great work, sadly my C# knowledge is near 0, on VBS when you crate a proccess is a parameter to redirect output to null, but on C I don't know.

I don't want any output as I explained, this is what slows hactool down, I know how to redirect it as I explained just not how to stop it from doing it in the background. I can make the app much faster by creating a batch on the fly and then executing that and then deleting it - but there must be an easier way than that.

StringIsNullOrEmpty · Aug 11, 2022

I'm not sure but I think it doesn't work because the redirection is handled by the shell and since you specify UseShellExecute = false there's nothing to parse the command. I would try setting it to true, or enabling redirect output and put a do-nothing lambda function as the callback.

mrdude · Aug 12, 2022

StringIsNullOrEmpty said:
I'm not sure but I think it doesn't work because the redirection is handled by the shell and since you specify UseShellExecute = false there's nothing to parse the command. I would try setting it to true, or enabling redirect output and put a do-nothing lambda function as the callback.

I ended up writing a new routine instead that creates a temp batch file and executes that instead, it's far faster now for FS patch generation. Also I added some more error checks and disabled the relevant buttons when patches are being created. Here's the new improved version.

Hopefully this should be better for now - hope you enjoy as I am away for the weekend.

I'll put the code on github this week so some of you c# guru's can make it better as my coding is not the best to be honest.

Hacking Discussion Info on SHA-256 hashes on FS patches

Well-Known Member

Developer

¡Kabito!

Developer

Developer

QVID PRO QVO

Developer

Well-Known Member

Developer

Well-Known Member

¡Kabito!

Developer

Developer

¡Kabito!

Well-Known Member

Developer

¡Kabito!

Developer

Well-Known Member

Developer

Similar threads

Popular threads in this forum