Homebrew [Request] CTRAging (3ds debug app) research.

  • Thread starter Thread starter PabloMK7
  • Start date Start date
  • Views Views 119,213
  • Replies Replies 562
  • Likes Likes 22
Had to compile with for 64-bit since it was erroring with 32bit MinGW.
Thanks for this! You forgot to build it with the dll files, but I will upload fffuck with the three dll files here.
Hopefully this tool can make things easier.
 

Attachments

Last edited by Thunder Hawk,
  • Like
Reactions: Ryccardo
I have browsed several of my consoles's ticket.db.
Only the consoles, having / used to have / System Transferred from a console used to have pre-installed titles, have the 000400000F980000 title.
So I think 000400000F980000 is a Nintendo factory title installer for non-dev consoles.
 
Last edited by MelonGx,
Looks like my console doesn't have it (unsurprisingly, I've had it for 2 years now :P) I might be able to get my hands on the consoles of some friends to find it. I know one with a rarely-used 2DS, and one with a old O3DS, but it was rarely updated or had titles installed to it. I'll see if I can find anything from them.
 
Looks like my console doesn't have it (unsurprisingly, I've had it for 2 years now :P) I might be able to get my hands on the consoles of some friends to find it. I know one with a rarely-used 2DS, and one with a old O3DS, but it was rarely updated or had titles installed to it. I'll see if I can find anything from them.
Good luck!
 
I have an idea. What about we collect all the bad dumps of this and compare them? Maybe we can "make" a good dump of this when we have enough bad dumps?
 
I have an idea. What about we collect all the bad dumps of this and compare them? Maybe we can "make" a good dump of this when we have enough bad dumps?
As @Normmatt can confirm, the bad O3DS CTRAging ExeFS dumps are all bad in the same location. Some just have slightly more corruption than others. Well, either that or for some reason parts of the ExeFS are stored elsewhere on the NAND (with a separate FAT entry that gets wiped later on), but they're obviously pretty much impossible to find.
 
Looks like my console doesn't have it (unsurprisingly, I've had it for 2 years now :P) I might be able to get my hands on the consoles of some friends to find it. I know one with a rarely-used 2DS, and one with a old O3DS, but it was rarely updated or had titles installed to it. I'll see if I can find anything from them.
Welp, looks like the rarely-updated 3ds was accidentially updated to 10.6. Gonna have to get my hands on some other consoles :(
 
I have an idea. What about we collect all the bad dumps of this and compare them? Maybe we can "make" a good dump of this when we have enough bad dumps?
As I said, I have an O3DS copy of ctraging with matching ExeFS hash, however, the keyY is missing, so we can't decrypt it :unsure:
 
Last edited by PabloMK7,
  • Like
Reactions: Seriel
As I said, I have an O3DS copy of ctraging with matching ExeFS hash, however, the keyX is missing, so we can't decrypt it :unsure:
If the ExeFS hashes match according to ctrtool, then you've already decrypted it. All hashes in an NCCH refer to the plaintext, not the ciphertext.
Also, what ctrtool calls "ExeFS Hash" is just the hash of the superblock. This matching does not mean jack shit; individual subsections can still be corrupted. Report back when the hash of the ExeFS:/.code matches.

Lastly, the keyX can't be missing. Either you have a CTRAging from a retail console and then you can use Decrypt9 as usual to decrypt it, or you have a CTRAging from a dev console and then you can use whatever people use on dev consoles to decrypt it.
If you're saying the keyY, taken from the signature, is corrupted, then congratulations, you have contributed absolutely nothing with your post because you stated that issue in the OP already. Besides, brute forcing 128 bits is still computationally infeasible.
 
Last edited by Suiginou,
  • Like
Reactions: piratesephiroth
If the ExeFS hashes match according to ctrtool, then you've already decrypted it. All hashes in an NCCH refer to the plaintext, not the ciphertext.
Also, what ctrtool calls "ExeFS Hash" is just the hash of the superblock. This matching does not mean jack shit; individual subsections can still be corrupted. Report back when the hash of the ExeFS:/.code matches.

Lastly, the keyX can't be missing. Either you have a CTRAging from a retail console and then you can use Decrypt9 as usual to decrypt it, or you have a CTRAging from a dev console and then you can use whatever people use on dev consoles to decrypt it.
If you're saying the keyY, taken from the signature, is corrupted, then congratulations, you have contributed absolutely nothing with your post because you stated that in the OP and brute forcing 128 bits is still computationally infeasible.
I used HxD to check the hash, and I posted that to reply @Thunder Hawk 's post :/
 
If the ExeFS hashes match according to ctrtool, then you've already decrypted it. All hashes in an NCCH refer to the plaintext, not the ciphertext.
Also, what ctrtool calls "ExeFS Hash" is just the hash of the superblock. This matching does not mean jack shit; individual subsections can still be corrupted. Report back when the hash of the ExeFS:/.code matches.

Lastly, the keyX can't be missing. Either you have a CTRAging from a retail console and then you can use Decrypt9 as usual to decrypt it, or you have a CTRAging from a dev console and then you can use whatever people use on dev consoles to decrypt it.
If you're saying the keyY, taken from the signature, is corrupted, then congratulations, you have contributed absolutely nothing with your post because you stated that issue in the OP already. Besides, brute forcing 128 bits is still computationally infeasible.
Do you need to make an effort to come off as an arrogant, elitist asshole? Or does it just come naturally at this stage?
 

Site & Scene News

Popular threads in this forum