Perfect ! I just tested it and the missing folders are created with all ips files. Thanks again !
Hacking Discussion Info on SHA-256 hashes on FS patches
- Thread starter crckd
- Start date
- Views 205,520
- Replies 526
- Likes 17
@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 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:
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
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?
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.
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.
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.
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.
Last edited by 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.
Last edited by 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.
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.
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.
Attachments
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).
Last edited by 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:
Code:
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).
No worries, if you want to compile yourself just change the part of the code in utils.c to this:
Code:
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.
Last edited by mrdude,
Similar threads
-
- Article
