There is no working o3ds dump as far as I know.I have an O3DS that was only once updated using a cartridge, never used again. Should I go for the trouble of searching for it or we already have an working dump?
There is no working o3ds dump as far as I know.I have an O3DS that was only once updated using a cartridge, never used again. Should I go for the trouble of searching for it or we already have an working dump?
Could someone compile this for Windows? Getting build errors.Relevant to this thread
http://pastebin.com/NZpxC7qU
Oh c'mon, stop being lazy and setup a Linux VM.Could someone compile this for Windows? Getting build errors.
I would rather not do that just for one thing. Maybe you should compile and upload it since you consider it so easy to do.Oh c'mon, stop being lazy and setup a Linux VM.
Had to compile with for 64-bit since it was erroring with 32bit MinGW.Could someone compile this for Windows? Getting build errors.
Thanks for this! You forgot to build it with the dll files, but I will upload fffuck with the three dll files here.Had to compile with for 64-bit since it was erroring with 32bit MinGW.
Good luck!Looks like my console doesn't have it (unsurprisingly, I've had it for 2 years now ) 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.
This is really cool! I'll be getting a 3ds soon and will definitely try this out!Good luck!
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.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?
Welp, looks like the rarely-updated 3ds was accidentially updated to 10.6. Gonna have to get my hands on some other consolesLooks like my console doesn't have it (unsurprisingly, I've had it for 2 years now ) 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.
As I said, I have an O3DS copy of ctraging with matching ExeFS hash, however, the keyY is missing, so we can't decrypt itI 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?
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.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
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 in the OP and 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?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.
It comes naturally, thanks for asking.Do you need to make an effort to come off as an arrogant, elitist asshole? Or does it just come naturally at this stage?