Hacking hactool release by SciresM

[SirNapkin1334]

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)

 

[TiMeBoMb4u2]

Heh, cartridge dumps do not require any keydata to get into, because they're plaintext. That should always work.

Well... Bubble bursted. =(

 

[AzizR]

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.

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.

 

[Soluble]

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.

 

[_n3o_]

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.

 

[TiMeBoMb4u2]

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.

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.

Also, there are specific requirements for certain decryption methods. The average user may have all the publicly-available requirements, but not know which is required for each type of decryption.

“hactool” is an amazing contribution, and @SciresM deserves every bit of gratitude received. However, until the average user has a use for the decrypted data, “hactool” will only be truly valuable to the devs.

 

[SciresM]

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

 

[TiMeBoMb4u2]

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

If I came across as negative, please accept my apologies, that was not my intention. Since there are only a select number of individuals that can fully take advantage of your tool, I was trying to convey that there are some caveats for the average/uninformed user.

I did read the "Usage" section of the "README", and I saw that the "-i, --info" and "-x, --extract" options were defined as "default action", but the "-t, --intype=type" option did not. In turn, I incorrectly assumed that "hactool" did not have a default input type, it would check the file extension programmatically, and that "-t, --intype=type" was designed to override/force input type designation.

...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:

• "STAGE2 Bootloader Key"
• "XCI Header Key"
• "NCA Header Encryption Key"
• "AES 128 CBC Crypto IV"

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.

Thanks, again, for all your contributions to the scene(s)!

 

[SocraticBliss]

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:

• "STAGE2 Bootloader Key"
• "XCI Header Key"
• "NCA Header Encryption Key"
• "AES 128 CBC Crypto IV"

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.

Thanks, again, for all your contributions to the scene(s)!

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... Like... (This is a dummy master key!!!)

Master_key_00 = ABCDEF123456789A

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.

A list of what keys are needed for what file type would be ideal.

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?

 

[TiMeBoMb4u2]

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...

I like that @SciresM is conversational. I think it provides a nice connection between devs and their users.

...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. The README and KEYS files do provide some good information, but sometimes having examples helps clarify things.
I will say, though, if you have an improper key length, "hactool" will spit an error telling you the length that the key should be! (This was smart!)

...A list of what keys are needed for what file type would be ideal...

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 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?

Agreed. This is basically what I was suggesting in my previous post.
I have this strange feeling that this may not be needed in the near future, though.
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.

 

[SciresM]

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.

 

[SocraticBliss]

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.

I respect you too much to write a simple GUI wrapper

I understand why he uses the names that he uses, it would just be nice to have a better understanding of the types of keys and what they do, I am sure I can probably look into the 3DS filesystem and wiki to get a better general understanding, just was a suggestion for clarity.

 

[PolloDiablo]

Could this tool be used to confirm the firmware requirements for the BigBlueBox rom dumps? (at least the <3.0.0 ones)

 

[AzizR]

Could this tool be used to confirm the firmware requirements for the BigBlueBox rom dumps? (at least the <3.0.0 ones)

you can use this tool for that:
https://gbatemp.net/threads/release-xci-reader.492151/

 

[PolloDiablo]

you can use this tool for that:
https://gbatemp.net/threads/release-xci-reader.492151/

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)

 

[b1313515]

Hello everyone,
Is there any way to convert extracted exeFS to .nso? Thanks in advance.

 

[Mat37]

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 ?

 

[b1313515]

They are already in NSO i think. And what would you use it for ?

To load it on yuzu or RyujiNX emulators.

 

[SirNapkin1334]

To load it on yuzu or RyujiNX emulators.

Yuzu doesn't run retail games!

 

[Mat37]

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 ?