I was gonna ask if they were plaintext. Thanks for answering my question! (Even though you didn't know I was about to ask it)Heh, cartridge dumps do not require any keydata to get into, because they're plaintext. That should always work.
I was gonna ask if they were plaintext. Thanks for answering my question! (Even though you didn't know I was about to ask it)Heh, cartridge dumps do not require any keydata to get into, because they're plaintext. That should always work.
Well... Bubble bursted. =(Heh, cartridge dumps do not require any keydata to get into, because they're plaintext. That should always work.
External keys can be provided by the -k/--keyset argument to the a keyset filename. Keyset files are text files containing one key per line, in the form "key_name = HEXADECIMALKEY". Case shouldn't matter, nor should whitespace.
In addition, if -k/--keyset is not set, hactool will check for the presence of a keyset file in $HOME/.switch/prod.keys (or $HOME/.switch/dev.keys if -d/--dev is set). If present, this file will automatically be loaded.
What are you trying to do that requires a guide? Tell the community what you're trying to achieve and someone will most likely assist.you just quoted SciresM's github page, i already read that ... the question is what does all mean?
can someone please make a noob friendly guide for the tool.
you just quoted SciresM's github page, i already read that ... the question is what does all mean?
can someone please make a noob friendly guide for the tool.
What are you trying to do that requires a guide? Tell the community what you're trying to achieve and someone will most likely assist.
i'have just quoted him because everything is clear and there is nothing more to say.
if you can't understand what it mean .. so this tool is useless for you.
Here are some of my observations, after tinkering around with “hactool”... Although it has a lot of options and is quite detailed, some things are just not obvious to the uninformed user.
For instance, unless I overlooked something, the documentation doesn’t mention that the default input filetype is NCA. If you would like to handle a different type, you must define it with the “-t INPUTTYPE” syntax.
I was taking advantage of prior knowledge -- ctrtool also worked this way.
Also, those reading the USAGE will notice " -t, --intype=type Specify input file type [nca, xci, pfs0, romfs, hfs0, npdm, pk11, pk21, ini1, kip1]", heh.
I agree it's not obvious to the uninformed user...but then the uninformed user won't be using command line tools, just running commands others have given them
...Secondly, unless you’re a developer, or familiar with some of the terms that @SciresM uses in the documentation, it will be very confusing to an average user—primarily because some very important terms of this tool have been called other things, by other parties...
The "terms" I was referring to are what the general public have been calling them, but may not necessarily be the same name that developers use. An example of this is when TX posted the "key to decrypt STAGE2 of the bootloader", the public started calling it the "STAGE2 Bootloader Key".
A few other examples that may/will be questioned, due to publicly generalized terms:
Although some of these have already been discussed, in other mediums, as alternate names, like "Package1 Key" and "Header IV", I'm assuming you will get endless questions regarding definition of terms.
- "STAGE2 Bootloader Key"
- "XCI Header Key"
- "NCA Header Encryption Key"
- "AES 128 CBC Crypto IV"
Thanks, again, for all your contributions to the scene(s)!
I like that @SciresM is conversational. I think it provides a nice connection between devs and their users.Agreed, I talked about this shortly with SciresM in Discord yesterday, it would be nice if the Keys.md had dummy examples at the very least...
Agreed. The README and KEYS files do provide some good information, but sometimes having examples helps clarify things....That way we have a better understanding of how to format each key, also how many HEX characters are required for each key without needing to put in something and have it spit out an error...
Agreed. I cannot recall at the moment, but there was a post or page somewhere explaining exactly which keys were required for certain file decryption....A list of what keys are needed for what file type would be ideal...
Agreed. This is basically what I was suggesting in my previous post....A theosarus for the key names would be hugely beneficial, so we know which keys match with the names in the keys.md file. Maybe have it as a wiki page?
I speculate that a GUI for this tool has already, or has nearly, been written. If so, the field label will most-likely be the common names we've seen.
One hasn't, hopefully -- and I really ask that if someone is going to write a GUI that they use my names.
Or, if they don't, that they please use "Package1 key" as the name for the key to decrypt Package1, and not "Stage 2 bootloader key" -- that key decrypts all of Package1, and not just NX_Bootloader.bin...
Anyway, I agree I should probably specify what keys are required to decrypt what types of files.
Could this tool be used to confirm the firmware requirements for the BigBlueBox rom dumps? (at least the <3.0.0 ones)
Nah... that tool doesn't actually reads the rom, only gets the crc32 of the file and does a lookup on nswdb.com (the daabase I'm trying to reconfirm, because it has wrong information)you can use this tool for that:
https://gbatemp.net/threads/release-xci-reader.492151/
They are already in NSO i think. And what would you use it for ?Hello everyone,
Is there any way to convert extracted exeFS to .nso? Thanks in advance.
They are already in NSO i think. And what would you use it for ?
Yuzu doesn't run retail games!To load it on yuzu or RyujiNX emulators.
SirNapkin1334 is right, plus where do you want to store the RomFS to be detected when loading the files ?To load it on yuzu or RyujiNX emulators.