... and it's very likely that this will still be implemented
.An update:
I discussed with Archshift, and I think we will now find a solution to work together on the code instead of letting the projects drift apart. This way, future developers will better profit from my changes plus those changes will be accessible to more people. Also, there will always be a fork with the Brahma Loader for us Ninjhax users available, and the Brahma Loader can be compiled and used on it's own as well. I will keep you updated about my progress, of course.
@Shadowtrance:
I'd definitely want to have you on board for this, and Archshifts Decrypt9 also badly needs some work on the aesthetics. Your design looks pretty fine to me, so maybe, you could look to make it work with my recent changes and then sent him a pull request? You should wait for a a few days, though, as a lot of stuff is subject to change now and I still need to send the pull requests myself. Keep in mind that I'm currently pondering the possibility to use the lower screen for output (the upper screen can contain a progress indicator then).
Also, on another note, did you test my recent changes?
--------------------- MERGED ---------------------------
... and, @everyone:
My next goal is to implement the "Dump Tickets" and "Decrypt Titlekeys" functionality. "Decrypt Titlekeys" will pull the titlekeys directly from NAND instead of using an extra file as Decrypt9 does now. However, I need your help for this as I don't exactly understand what these two do and what these are good for. In other words - if I don't understand them, I can't test them, and if I can't test them I can't properly implement them.
So, could anyone explain to me, as exactly as possible, what these two do, what additional tools you use to make them useful and what their use is?
Yeah I'm testing the latest source of ctrxtools now.
Why does the top screen appear as though the 3D is turned on or something? It looks strange.
And Dump Tickets - basically what the name implies, it dumps the ticket.db from the nand which can be used with FunkyCIA to download things that you've previously downloaded, isn't on eshop anymore etc and build cia's from them.
Decrypt Titlekeys is similar to the above, but is used with dump_ticket_keys.py (which dumps the encrypted titlekeys from your ticket.db) to give you encTitlekeys.bin which is then used with this option (Decrypt Titlekeys) which gives you the decrypted titlekeys, decTitlekeys.bin which can then be used with print_ticket_keys.py and cdn_download.py.
That's the best way i can explain those 2 really.
Edit: ok that's weird, just started it again after rebooting and screen is normal this time...
I haven't changed anything related to 3D... I just hope that's not a Brahma problem again.Yeah I'm testing the latest source of ctrxtools now.
Why does the top screen appear as though the 3D is turned on or something? It looks strange.
And Dump Tickets - basically what the name implies, it dumps the ticket.db from the nand which can be used with FunkyCIA to download things that you've previously downloaded, isn't on eshop anymore etc and build cia's from them.
Decrypt Titlekeys is similar to the above, but is used with dump_ticket_keys.py (which dumps the encrypted titlekeys from your ticket.db) to give you encTitlekeys.bin which is then used with this option (Decrypt Titlekeys) which gives you the decrypted titlekeys, decTitlekeys.bin which can then be used with print_ticket_keys.py and cdn_download.py.
That's the best way i can explain those 2 really.
Edit: ok that's weird, just started it again after rebooting and screen is normal this time...
Your explanation, what you just wrote, that almost sounds like decrypt Titlekeys is redundant, because dump Tickets does it all in one. Of course one might still have a encTitleKey.bin floating around and may want to process this.
Yeah not sure what it was, it was odd though, I've loaded it a few times since and it hasn't done it so who knows what it was.
decrypt titlekeys can still be useful even if possibly made redundant by other tools. Still handy to have imo.
decrypt titlekeys can still be useful even if possibly made redundant by other tools. Still handy to have imo.
Did anyone verify the ctrnand.bin dump from the new NAND partitions dump feature? For example by extracting the ticket.db and using that? I mounted the image in ofsmount and checked some files via a hex editor. Everything looks good, but there are two things that seem strange...
- FIRM0 and FIRM1 (the other 2 bin files) are not completely identical, and I thought they should be.
- I checked the mounted ctrnand.bin via Windows chkdsk and it found one small (32kB) lost file. If anything went wrong with my decryption, that should be a lot more, but still strange.
I get the same as well, firm0 and firm1 aren't identical (not sure if they're meant to be or not to be honest).
ctrnand fat16 partition is 172 KB smaller compared to the fat16 partition extracted from a full nand dump with 3DSFAT16Tool, not sure if it matters as the ctrnand partition appears fine otherwise, the one extracted from a full dump has the extra 172 KB at the start (before "CTR" appears).
I also dumped the TWL partitions (twln and twlp) but both appear encrypted still (kinda expected that), so i guess that's something else to look at, decrypting those/ generate xorpads for them etc. And xorpads for other partitions just for the hell of it. haha
Last edited by Shadowtrance,
Thanks for testing!
I already have an idea where these 172kB went. The ctrnand partition has a slightly different offset for N3DS and FAT16Tool uses one offset for both, N3DS and O3DS. I still need to check, though.
For the TWL partitions, did you also use the correct AES keyslot 0x3? I don't think they're decryptable yet, though. Roxas75 also has the partition in between in his list, the agbsave.
Yeah i set the keyslot correctly for the TWL partitions.
And yeah that makes sense about the ctrnand, either way it appears fine as it is now.
And yeah that makes sense about the ctrnand, either way it appears fine as it is now.
Okay, we'll see about the TWL partitions.
I already have a better explanation for the additional 176kB. 3DSFAT16Tool uses the begin of the partition (which is, in fact, unneeded data), while my algorithm uses the actual begin of the file system.
I already have a better explanation for the additional 176kB. 3DSFAT16Tool uses the begin of the partition (which is, in fact, unneeded data), while my algorithm uses the actual begin of the file system.
Ah yep that makes sense.
Working as intended then.
edit: one thing that would be cool to add is the dsi injection/dumping part of this... https://dl.dropbox.com/s/22onijp0cqjc7s9/DSiWare_Injector.zip?dl=0 https://gbatemp.net/threads/tutorial-installing-sudokuhax-on-3ds.388621/ although I've tried and can't get it to work for some reason.
Working as intended then.
edit: one thing that would be cool to add is the dsi injection/dumping part of this... https://dl.dropbox.com/s/22onijp0cqjc7s9/DSiWare_Injector.zip?dl=0 https://gbatemp.net/threads/tutorial-installing-sudokuhax-on-3ds.388621/ although I've tried and can't get it to work for some reason.
one thing that would be cool to add is the dsi injection/dumping part of this... https://dl.dropbox.com/s/22onijp0cqjc7s9/DSiWare_Injector.zip?dl=0 https://gbatemp.net/threads/tutorial-installing-sudokuhax-on-3ds.388621/ although I've tried and can't get it to work for some reason.
I'll see what I can do! rxTools features first, then either cart dumping (we need to see if Archshift wants that in there) or DSI dumping / injection. I won't enable writing to SYSNAND, though, too dangerous (I could not even test this without risking my 3DS).
@everyone:
Things have changed. I am now participating in official Decrypt9 development, and therefore I renamed my fork back to "Decrypt9". It was initially "CTRXtools", because I wanted to do some kind of a Decrypt9 / rxTools hybrid. I also updated the first post, it now includes a link to my recent source code and binaries for you to test. Just be careful and take your precautions, this is still bleeding edge. If you encounter some bugs, just write here in thread.
Yeah but that's where i come in. I CAN test dangerous stuff seeing as i have 3 3ds's (1 old xl, 2 small n3ds) all with nand mods (well 2 i test stuff on and my main n3ds), so i can recover if something did happen to go horribly wrong lol
Just had a look at getting it working again, still no go. Not sure what I'm missing but I'm missing something.
Yeah but that's where i come in. I CAN test dangerous stuff seeing as i have 3 3ds's (1 old xl, 2 small n3ds) all with nand mods (well 2 i test stuff on and my main n3ds), so i can recover if something did happen to go horribly wrong lol
Just had a look at getting it working again, still no go. Not sure what I'm missing but I'm missing something.
It is more difficult for me if I can't test it myself, but I assume once I get the reading right, I could code something for you.
Yeah good point, but at least you know there is someone who can test possibly dangerous stuff if need be.
I'll PM you the code i have for it atm, totally missing something I'm sure of it...
I'll PM you the code i have for it atm, totally missing something I'm sure of it...
Okay, I took a look, and I think the problem lies in these lines:Yeah good point, but at least you know there is someone who can test possibly dangerous stuff if need be.
I'll PM you the code i have for it atm, totally missing something I'm sure of it...
Code:
FileOpen("twln:/title/00030004/4b513956/data/public.sav");I will have to take a closer look later.
Yeah i figured i was missing something (or multiple things), i was testing it on the spider(browser) version, same result on brahma as well so i dunno.
The original one is launched from MSET, don't know if that makes any difference at all or not. I'm guess just a code issue though.
The original one is launched from MSET, don't know if that makes any difference at all or not. I'm guess just a code issue though.
The first issue is that FileOpen() doesn't give us access beyond accessing the SD card (no access to TWL, CTRNAND or others), permissions come afterwards. There is something you could try, but no guarantees:
http://4dsdev.org/thread.php?id=40
(the first post by profi200 on there)
I still think that dumping and decrypting would be the better option.
... and a new release. Ticket dumper included. See first post.
By the way, what is a reasonable size for the ticket.db? Roxas75 says 832kB, but that seems to be an odd number. If anyone tests, let me know how it works for you.
By the way, what is a reasonable size for the ticket.db? Roxas75 says 832kB, but that seems to be an odd number. If anyone tests, let me know how it works for you.
Similar threads
