I would LOVE this. ^^
- Vastly improve the SD decryptor feature - the way this works now, you have to copy the files to decrypt to a certain folder, and also keep the correct folder strcuture. This is a feat not even easily accomplished with CTRXplorer. The way it should work is, let the user select what to decrypt, then copy that automagically to the work folder and decrypt it from there. Same for the SD xorpad generator.
Maybe supplementing the dsibrew doc with http://www.3dbrew.org/wiki/DSiWare_Exports will help some.
- Add a NDS .tad decryptor feature (or NDS SD decryptor) (unsure) - as requested by @zoogie . Problem here is: the DSiBrew article doesn't provide enough information to actually decrypt it, and I don't have data to test on (the test data must be tested on the same 3DS they cam from). If at least test data was available, decryption could be tested with a handful of different configurations until the correct one is found (unsure if that is doable, too).
Well, that should already be handled by the Decrypt9 SD decryptor. It should be the same as for the other SD stuff, and also, only the first layer of encryption. This (the assumed second layer of encryption) is where it gets difficult: http://dsibrew.org/wiki/TadMaybe supplementing the dsibrew doc with http://www.3dbrew.org/wiki/DSiWare_Exports will help some.
"each section is encrypted with AES-CBC" -hopefully that's enough, lol.
You should only need the movable sed for the initial decryption, then hopefully dsi_srl_extractor could do the rest.
I can help you test. Just PM me as always.
I believe 3ds games use a different crypto type (and different keyslots) and, according to 3dbrew, the dsiware is decrypted by section rather than the length of the file.Well, that should already be handled by the Decrypt9 SD decryptor. It should be the same as for the other SD stuff, and also, only the first layer of encryption. This (the assumed second layer of encryption) is where it gets difficult: http://dsibrew.org/wiki/Tad
Or maybe I just get that wrong... What do you get if you use the SD decryptor to handle the Nintendo DSiWare folder? Even after the initial decryption, some of it is still encrypted, correct?
Okay, after reading up on this.... the normal SD data (that should include extdata, titles, etc...) is encrypted with AES-CTR, while the DSiWare data is encrypted using AES_CBC. AES_CBC is already implemented in Decrypt9 (it is also used for CIA encryption), so no problem. Maybe we also have to set the IV (initialization vector) anew for each section (not 100% sure). Not a problem either. Now, the remaining problem is... What keyslot to use? It is absolutely impossible to try each and every combination, and as it is now I have to assume it is the same as for the remainder SD data (0x34).I believe 3ds games use a different crypto type (and different keyslots) and, according to 3dbrew, the dsiware is decrypted by section rather than the length of the file.
What I'm talking about here is just the initial per-console encryption layer.

That did the trick! And yes the screenshot function is handy indeed.Already fixed that, take a look at my Github. By the way, the screenshot feature proves useful again!![]()

Don't see why it wouldn't work to be honest.@d0k3 Just a question about the .nds MSET installer, can we use it in Old3DS and a original 4.5 (not downgraded) for decrypt a SDK9 game instead using this very old launcher?:
http://image.noelshack.com/fichiers/2015/20/1431433915-launcher.jpg
Don't see why it wouldn't work to be honest.

Decrypt9WIP.bin is for running it from Brahma (or a bootmanger i guess) by itself.Just for be sure :3
For what purpose are used the Decrypt9WIP.bin and Decrypt9WIP.dat?
For the ROP, do we need to have just your launcher.dat and the .nds, right?


What's the URL for use the .dat with spider?
The URL used by gateway, or a custom?
The width is 8 pixels, and the height should be the same.That did the trick! And yes the screenshot function is handy indeed.
Any idea how many pixels one letter is in the DrawStringF ? Just trying something with those man menu strings (sd space, game/work dirs etc)...
The CIA deep decryptor already does that. If you meant the full conversion process (encrypted) 3DS -> (cryptofixed) CIA, that's not possible, at least not as good as Riku's tool does it, so there's not really a reason to add it in. If you meant GW compatibility, there is also a special option for that in there, and if you need it for .3DS GW compatibility, you need to decrypt, then reencrypt the .3DS file.Only need cryptofix funtion and then it will be perfect XD

Good to know.The width is 8 pixels, and the height should be the same.
Good to know.
I think positioning looks ok... (top screen strings)
![]()

Maybe in the next few days depending on how much i mess around/get distracted by other stuff. hahalooks really nice! How long do you think until the new release is ready?
I liked the blue you proposed, I think it was in that thread... I'll also teach you how to get a similar word effect to the D9 banner with ImageMagick if you like (its pretty simple)Maybe in the next few days depending on how much i mess around/get distracted by other stuff. haha
Still got the UI version of EmuNAND9 to do too (because i want to and d0k3 said i probably would haha)... some ppl don't seem to like the purple of D9 for it though.
Throw ideas at me people!!!!!

Yeah the blue one looks ok, the pin striping is too dark though and looks terrible with text over it imo so that'll need to be changed.I liked the blue you proposed, I think it was in that thread...
Yeah sure, sounds good.I'll also teach you how to get a similar word effect to the D9 banner with ImageMagick if you like (its pretty simple)
