Bug with 3ds decryption routine #20

New Issue

claunia · 2026-01-29T22:29:20Z

claunia commented

2026-01-29 22:29:20 +00:00

Originally created by @Dimensional on GitHub (Mar 30, 2025).

Originally assigned to: @mnadareski on GitHub.

When attempting to decrypt a 3ds/cci file using either v0.3.1 or the rolling release, the decrypted file does not match the hash for no-intro. Additionally, if I take a pre-existing decrypted file who's checksum matches no-intro, it encrypts fine, but decrypting it back produces checksums that are not matching the original, which also causes re-encryption to also produce a different checksum. I have tested with some 3ds files like Xenoblade Chronicles 3D Rev 1 (USA) and Pokemon Omega Ruby Rev 2 (USA).

Not sure if this is a bug in the program or some bug that has to do with the use of .net9, but this doesn't appear to exist at all within v0.2.5.

Originally created by @Dimensional on GitHub (Mar 30, 2025). Originally assigned to: @mnadareski on GitHub. When attempting to decrypt a 3ds/cci file using either v0.3.1 or the rolling release, the decrypted file does not match the hash for no-intro. Additionally, if I take a pre-existing decrypted file who's checksum matches no-intro, it encrypts fine, but decrypting it back produces checksums that are not matching the original, which also causes re-encryption to also produce a different checksum. I have tested with some 3ds files like Xenoblade Chronicles 3D Rev 1 (USA) and Pokemon Omega Ruby Rev 2 (USA). Not sure if this is a bug in the program or some bug that has to do with the use of .net9, but this doesn't appear to exist at all within v0.2.5.

claunia closed this issue

2026-01-29 22:29:20 +00:00

claunia commented

2026-01-29 22:29:20 +00:00

@mnadareski commented on GitHub (Mar 30, 2025):

Able to reproduce locally
Doesn't seem related to BouncyCastle version
Doesn't seem related to keys
Doesn't seem related to IV
Possibly related to specific 9.3 key (unconfirmed)
ExeFS only, not including headers or file table

I'll mark 0.3.1 as unreliable for now as most of the "normal" things that could go wrong aren't.

@mnadareski commented on GitHub (Mar 30, 2025): - Able to reproduce locally - Doesn't seem related to BouncyCastle version - Doesn't seem related to keys - Doesn't seem related to IV - Possibly related to specific 9.3 key (unconfirmed) - ExeFS only, not including headers or file table I'll mark 0.3.1 as unreliable for now as most of the "normal" things that could go wrong aren't.

claunia commented

2026-01-29 22:29:21 +00:00

@mnadareski commented on GitHub (Apr 1, 2025):

Debugging has determined that key, IV, and counter all seem to be initialized identically. Compared to some of the original Python scripts, the read is pulling a different set of data, seemingly? The bytes being read don't match with what is in the file. All of the math that changed to convert the keys and arrays is consistent all the way up to that point. Still investigating.

@mnadareski commented on GitHub (Apr 1, 2025): Debugging has determined that key, IV, and counter all seem to be initialized identically. Compared to some of the original Python scripts, the read is pulling a different set of data, seemingly? The bytes being read don't match with what is in the file. All of the math that changed to convert the keys and arrays is consistent all the way up to that point. Still investigating.

claunia commented

2026-01-29 22:29:21 +00:00

@mnadareski commented on GitHub (Apr 1, 2025):

Issue was that cached values were being used for the ExeFS file table.

@mnadareski commented on GitHub (Apr 1, 2025): Issue was that cached values were being used for the ExeFS file table.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/NDecrypt#20