CTR Decryptor fails to decrypt RomFS of most system titles...

[ApacheThunder]

Decryption fails to decrypt RomFS for most system titles I've tried it on. (have yet to find a single one it works on actually) It will decrypt exheader/exefs fine. (in most instances) but RomFS is still encrypted and I had to use a xorpad to decrypt it.

There's also the random block corruption during decryption. (decrypt a large game and use ctrtool -y to check romfs.bin after extraction and you'll see the level checks will fail so data somewhere in the romfs got corrupted) Some times it won't corrupt, but the larger the romfs/partition it's decrypting, the higher chance. I don't know if this impacts the partition decryption stuff when dumping NAND partitions, but it's certainly a problem that plagues CTR Decryptor. Small things like most of the system apps and game patches/dlc may have much lower occurrence, but larger stuff will have a high chance of it.

Also CTR Decryptor didn't decrypt exefs correctly on one system app. I have forgotten which one though. I think it was Home Menu or eShop, but I forget which now. :P

[Syphurith]

Eh even about the xorpads generated for games, i would easily find the necessarity to "Unpack romfs" to make it working. Or else ctrtool could tell me "Romfs size mismatch" or something alike. So there is really such a problem. And, did you face the same result in 2.6 or 2.5.2?

[ApacheThunder]

This has been a issue with CTR Decryptor since it's inception or at the least as long as I can recall. So this was an issue in 2.5+ for sure.

[Syphurith]

Oh.. Thanks. Even i tried dumping decrypted system titles from EmuNAND in 2.5/2.6. properly.

[b1l1s]

This is the offending line : https://github.com/roxas75/rxTools/blob/master/rxtools/source/features/CTRDecryptor.c#L148

The BLOCK_SIZE is currently 8MB, if you have a romfs with the size of say 17MB (8 + 8 + 1), getle32(NCCH.romfssize) * mediaunitsize / BLOCK_SIZE is 2 (floored) instead of 3. So the last 8MB block of a romfs(in my example the 'block' is the last 1MB) never gets decrypted. The current code only works ok if the romfs size is the exact multiple of 8MB.

You should change the loop to something similar to this : https://github.com/roxas75/rxTools/blob/master/rxtools/source/lib/crypto.c#L128

and change the corresponding size parameter to FileRead and FileWrite as well.

Hope this helps.

[dukesrg]

@b1l1s #132 should fix that

[dukesrg]

@ApacheThunder check this one please https://github.com/dukesrg/rxTools/commit/c40815170ceca6ccee92a6a302eab0d2233b4233 if it works with decryption fine now

[ApacheThunder]

Will do. Anything special I need to do with spiderhax or will the current spiderhax html I have work? (I've already transitioned to the new one that doesn't use encryption)

[dukesrg]

Only rxTools.dat moved to /rxTools/system/code.bin, spiderhax works fine just launch with ?rxTools/system/code.bin

[ApacheThunder]

I see. Cool. I just have to adjust the URL and update my MSET installer. :D

[ApacheThunder]

I'll try decrypting Home Menu CXI (as it is one system app I definitely recall it having issues with in the past) and also decrypt a 2GB game and check the resulting romfs.bin. If it works. I'll close this issue once the final pull request is merged. :D

[dukesrg]

Yep. waiting. Even did not make a PR for the last minute fix

[ApacheThunder]

Spiderhax entry worked like a charm. Running decryption now. :D

Noticed this awhile ago, but when it first loads and shows the "loading" text on the bottom screen, the text has a blue background around it but the rest of the screen is black. It looks a bit tacky/unfinished. Hopefully you can just make bottom screen blue at start up or correct the way the text is displayed. ;)

[dukesrg]

It's chaged by @173210 I suppose. I only moved Loading... a bit right to monitor initial boot process. Also no font/notranslation may be displayed at that screen, but now it is not fatal.

[ApacheThunder]

So far good news. Home Menu romfs is decrypted and passed all level checks using ctrtool -y. Still extracting RomFS of my large game so it will be a bit longer before I can tell you the results.

[ApacheThunder]

Ok just finished checking and the romfs.bin decrypted from Pokemon Alpha Sapphire passed all 3 level checks. It appears to be stable now. :D

[dukesrg]

OK, issuing a PR #134

[ApacheThunder]

Final fix was merged to branch. This should no longer be an issue. Closing this for now. :D