mirror of
https://github.com/SabreTools/NDecrypt.git
synced 2026-02-04 05:35:53 +00:00
Decrypting Datel Games n' Music ROMs results in broken ROMs. #17
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @PurpleNekoNova on GitHub (Jul 27, 2024).
Originally assigned to: @mnadareski on GitHub.
Some ROMs from Datel's Games n' Music CD-ROM fail to load on hardware or emulator after being decrypted.
Redump.org entry for the disc of origin:
http://redump.org/disc/116685/
These are Unlicensed Homebrew titles, original state on CD is encrypted and NDecrypt detects them as such. In encrypted format they work as expected, however after decrypting using NDecrypt 2.5, they no longer function.
The titles from the disc that do not function after decryption are:
Carre Rogue
ChainReaction
DiggerDS
Double Skill
DSChess
Invasion
London Underground
Pop the Balls
Solitaire DS
Tales of Dagur
Tic Tac Toe
Zi
If this is outside the scope of the program, I understand. I just felt obligated to report this "issue" at least. Thank you.
@mnadareski commented on GitHub (Apr 1, 2025):
There have been some unrelated changes and cleanups since this was originally opened. In the off chance that any of those helped, do you mind trying again with the latest WIP build?
@PurpleNekoNova commented on GitHub (Apr 1, 2025):
Looks like there's a new issue:
@mnadareski commented on GitHub (Apr 2, 2025):
Interesting notes for future research:
@mnadareski commented on GitHub (Apr 2, 2025):
Relaxing the rigor of the checks ahead of processing helped, but another issue surfaced: The values indicating the "state" of the file are not matching any known values. The fact that they were all being detected as "encrypted" before was a fluke, more than anything.
I have a couple of choices:
@mnadareski commented on GitHub (Apr 2, 2025):
For myself with the possibility of option 2:
@mnadareski commented on GitHub (Apr 2, 2025):
I've relaxed the header requirement for encrypted so that it doesn't block even a force flag to be used. I will leave this open if I decide to look further into these specifically and see if those values are truly encrypted or not.
@mnadareski commented on GitHub (Apr 2, 2025):
These values have been documented in code in a similar manner to empty secure area. All of them will be counted as neither encrypted nor decrypted and won't be processed unless forced. I'm still going to be leaving this open because I still want to find out if they're "encrypted" or not.
@mnadareski commented on GitHub (Apr 2, 2025):
Based on external conversation, there is a summary of additional findings:
The carts in question were distributed as files to be loaded in a Datel flash cart. It is likely that the cart had additional logic that would take care of the inconsistencies seen with the data, including header and secure area values. There is essentially no way to confirm this, though the fact that these do not work in an accurate emulator that is using a user-provided firmware indicates that they were never meant to be played separate from that flash cart.
With all of the above, the changes that have already been done are going to be the full scope of how these are supported. I will not be leaving this open since we basically know that there's no way to know.