-k or --keyset does not prevent /.switch/prod.keys from loading

[urherenow]

I'm pretty sure the intent is to look for prod.keys or dev.keys in %home%/.switch if you DON'T specify with -k or --keyset. I was having a hard time with a certain project that only wants certain keys, the author does specify the file, but the prod.keys in my profile's .switch folder was messing up the process.

[SciresM]

Not sure I understand. Where is the bug?

per main.c, the key file passed with -k is used whenever it exists. https://github.com/SciresM/hactool/blob/master/main.c#L449

local testing does prefer the file passed with -k when present to the one in prod.keys...can you clarify what the unexpected behavior is?

utils.c isn't responsible for -k key file selection...

[SciresM]

Yeah, I can't reproduce at all. When I test, you can see that the stuff in ~/.switch/prod.keys gets overridden when I use -k:

I will close this issue in 24 hours without clarification.

[urherenow]

utils.c 262-279. It doesn't check for the flag. Pardon me if the check is somewhere else, but see thread https://gbatemp.net/threads/info-on-sha-256-hashes-on-fs-patches.581550/post-9918507

the file is specified and present, and in the specified place and in the expected format, with ONLY the correct (expected) keys. I know there is a bug in the program I'm dealing with (it's an executable made from python scripts) since extra/unneeded keys should not halt the process, but with my prod.keys FULLY populated via Lockpick_RCM, and in the %HOME/.switch folder, this program does not work. If I rename to _prod.keys, it works perfectly, so I know the key file is both specified and correct (and in the correct location). Hactool is therefore loading prod.keys at some point, when it shouldn't.

[SciresM]

The check is in main.c as mentioned/linked. The code in utils.c is not responsible for this check, the code in utils.c is supposed to find the most appropriate default-file-not-using-the-k-command-line-option.

hactool should attempt to open the file in ~/.switch unconditionally, so that it can warn if it's not present -- issuing a warning when the file doesn't exist is intended.

But seriously, I can't reproduce -- see my screenshot. The code that does the selection in main.c prefers the passed keyfile.

Closing this, try to link to the actual problematic code in main.c if you think this is real.

[urherenow]

Using the command you used, without specifying any file/command after -t, I get warnings of unmatched keys, that are NOT in keys.dat. They are in /.switch/prod.keys. I'd post a screenshot, but I'd have to quickly make a bunch of nonsense keys for obvious reasons...

[SciresM]

Make nonsense keys.

[SciresM]

And, ideally, make a single nonsense key.

What platform are you on? Because you can see that it's behaving correctly on windows, using my build.

You can also see the code in main.c always prefers the file passed via -k.

[urherenow]

OR just block out the pic... these are not in keys.dat.

The author of the tool, actually removed the above mentioned lines and compiled a modded hactool for me, so my issue is solved personally. I thought I was doing my duty to report it.

[SciresM]

your command line is invalid. You need to pass -t keygen, passing "-t" with nothing else will be using "-k" as the type value, and attempting to parse "keys.dat" as main input.

Also, >sigpatch, piracy is not supported.

[SciresM]

(the command line in your screenshot does not have a -k argument, it has a -t argument of -k, and a main-file argument of keys.dat)

[urherenow]

using -t keygen, it says Error: Rights ID 01007EF00011F0010000000000000000 already has a corresponding titlekey!

Anyway, with prod.keys renamed, it works as expected. The author built me a hactool real quick (thus me using _hactool just now) that removed those lines from utils.c, and that version works without renaming prod.keys. I'll end the convo here.

[SciresM]

Sounds like you have title keys in your prod.keys (incorrect) and in title.keys, which is indeed an error condition. I'll lock this now.