Some eShop CIAs are incorrectly decrypted

[davidmorom]

Hi ihaveamac:

I found a bug on the decryption part of NinFS. Some eShop CIAs that use seed crypto (I think, I'm not 100% sure on this) are not correctly decrypted, and the resulting decrypted.xci is not runnable on Citra/Azahar. The same CIA decrypted on a real 3DS with GodMode9 produces a 100% functional CIA file.

A game that I'm 100% sure is affected by this issue is the EUR version of Alien on the Run, but I know there are more, although I can't remember any others right now.

By comparing the NinFS decrypted files and the GodMode9 decrypted files, I tracked down the problem to the decryption of the .code section of ExeFS. The .code section of NinFS decrypted ExeFS is pure garbage, as if the used key were incorrect.

The worst part is that every tools publicly available to decrypt CIAs produce the same invalid output, maybe they are all based on the same source. Ctrtool.exe, on the other hand, produces a valid ExeFS decrypted file.

[ihaveamac]

Thanks, I will look into it soon.

[ihaveamac]

I've found the root cause. I will push out a fix for pyctr soon. ninfs standalone will need a separate update.

This title uses Original NCCH (keyslot 0x2C), but also uses seed encryption. For things like the ExeFS header, icon, and banner, the original keyslot is used. ExeFS .code and RomFS use the seeded key.

Original NCCH gets overwritten with the unseeded key:
https://github.com/ihaveamac/pyctr/blob/b2b36ae44316ff31302823911c812b5c82eb0e8b/pyctr/type/ncch.py#L337-L338

pyctr normally loads the seeded key into an internal slot (Keyslot.NCCHExtraKey, 0x44). And it gets used correctly for RomFS. But ExeFS kept using the original slot. This was fine when the "extra keyslot" (which may be Original NCCH, 7.0, 9.3, or 9.6) was anything else, but when it's set to Original NCCH, which was overwritten with the unseeded key on purpose, it was decrypting with the wrong key.

ExeFS is decrypted using the extra keyslot:
https://github.com/ihaveamac/pyctr/blob/b2b36ae44316ff31302823911c812b5c82eb0e8b/pyctr/type/ncch.py#L434

The fix here is to make ExeFS also use the internal slot.

diff --git a/pyctr/type/ncch.py b/pyctr/type/ncch.py
index 00c388d..0ab381c 100644
--- a/pyctr/type/ncch.py
+++ b/pyctr/type/ncch.py
@@ -426,7 +426,7 @@ class NCCHReader(TypeReaderCryptoBase):
                 for offset in crypto_changes:
                     self._exefs_crypto_ranges.append((previous_offset, offset, previous_keyslot))
                     previous_offset = offset
-                    previous_keyslot = self.main_keyslot if previous_keyslot is self.extra_keyslot else self.extra_keyslot
+                    previous_keyslot = self.main_keyslot if previous_keyslot is Keyslot.NCCHExtraKey else Keyslot.NCCHExtraKey
 
             # This will set up either the special ExeFS encryption from above, or a straightforward decryption
             # passthrough if not.

[davidmorom]

Nice work! I tested ninfs-2.0 with the new pyctr and it works fine, at least for this game.

I found the source code of the Python based "decrypt.exe" used in "Batch CIA 3DS Decryptor", and thanks to the information you provided, I was able to fix it.

Thank you!

[DocJr90]

@davidmorom

I found what I believe to be a somewhat-related issue in decrypt.exe as well: the tool does not search for the TitleID in a provided seeddb.bin file correctly; rather, it converts a hexadecimal string representation of bytes to a hexadecimal string, again. Thus, the program doesn't correctly locate the TitleID in the seeddb file.

The decrypt.exe is apparently a packed Python program originally written in Python 2.7 or so. I decrypted the .exe with pyinstxtractor-2025.02 and then used pyenv to run uncompyle6 with Python 3.8, made the changes to the decrypt.py source file and also fixed some decompilation errors, and then successfully used decrypt.py to correctly decrypt a file, wherein the script was able to correctly locate the TitleID in the seeddb file.

With all that said, @ihaveamac, would it be appropriate to post the modified decrypt.py source here?