Yup, but Roxas says after 832kB nothing useful is found anymore. I guess you'd have to try if the dumped ticket.bin works as intented.
The problem is, to find out the correct size of the ticket.db I'd have to have a proper FAT image reader, which I don't have. I guess I'll leave it that way until someone complains.
Last edited by d0k3,
I dug a little deeper in the TWL injector source code, and that does in fact use a whole different set of file system (FS.s) functions. A whole lot more complicated than what we use in Decrypt9 and, for me, almost impossible to adapt for use in Brahma / Ninjhax.
I'll try an explanation...
The way data is accessed on the 3DS is via 'archives' (that's what Nintendo calls it). There are a whole lot of archives, for a complete(?) list take a look here. Via the file system functions in decrypt9 we have access only to the SDMC and directly to the NAND memory (both with write access). While direct access to the NAND sounds good on paper, that actually means what we read from there is encrypted. If the file system functions gave us access (f.e.) to the NAND TWL FS archive, what we would read from there would actually be unencrypted, and if we would be crazy enough to write there, it would get properly encrypted in the process (ie. then being usable by the 3DS). That's how it is done in the DSI injector.
What we do now in Decrypt9 is different. We read directly from the NAND and do the decryption (and encryption, if we intend to write) on our own (vs letting the 3DS handle it if we used the process described above). For some reason, the decryption routines in Decrypt9 cannot handle the TWL partitions yet (it works with FIRM0, FIRM1 and CTRNAND, though).
Now, the best solution - in my opinion - would be to figure out what's keeping our decryption / encryption routines from properly handling the TWL. There is another option, using profi200's file system routines (which can handle archives): https://github.com/profi200/sysUpdater/blob/master/include/fs.h
These are well written, but still a whole lot more complicated to use than what we got in Decrypt9. Also, there is no guarantee if it works, cause access to specific archives depends on internal permissions being set correctly.
Ah ok, thought there was some funky stuff going on with the old source with its asm FS stuff (totally over my head). I did get it to load on brahma, but it doesn't DO anything except make the bottom screen all messed up and a blank top screen. haha
Was worth a try i guess...
Hopefully way to decrypt ALL the partitions becomes reality at some point.
Alright, big update here! First, look at the thread title: It's changed to reflect the shift in focus for this project.
We also have new features:
@Shadowtrance
I have an idea what's stopping us from decrypting the TWL partitions. It's just an elaborated guess so far, but I think these need a different start-CTR. The CTR, if you haven't digged that far yet, is one of the parameters involved in the AES decryption, and it is calculated from start-CTR and offset. The start-CTR for the CTRNAND (and FIRM0 / FIRM1) partition is hidden in memory (this is already found) and the start-CTR for TWL should be as well (no idea yet).
Second point: If you want to try some dangerous stuff, I can enable NAND restore and NAND partition injection for you. These are almost sure-brickers, but no problem with a hard mod. Maybe you've got some ideas what to do with this.
We also have new features:
- Launcher.dat version now available
- Fixed the ticket.bin dumper (testing with FunkyCIA, I noticed some tickets were missing before)
- A new feature to decrypt titlekeys from NAND (no 'encTitleKeys.bin' needed)
- A new feature to dump titles from NAND
@Shadowtrance
I have an idea what's stopping us from decrypting the TWL partitions. It's just an elaborated guess so far, but I think these need a different start-CTR. The CTR, if you haven't digged that far yet, is one of the parameters involved in the AES decryption, and it is calculated from start-CTR and offset. The start-CTR for the CTRNAND (and FIRM0 / FIRM1) partition is hidden in memory (this is already found) and the start-CTR for TWL should be as well (no idea yet).
Second point: If you want to try some dangerous stuff, I can enable NAND restore and NAND partition injection for you. These are almost sure-brickers, but no problem with a hard mod. Maybe you've got some ideas what to do with this.
Last edited by d0k3,
Yeah I've been watching your updates.
As for the TWL thing, you could be right with your guess. I haven't really dug around 3dbrew much for info about it really, might be something there though.
As for the dangerous stuff, i can test it out if you want. Maybe keep it out of the repo until it has been thoroughly tested though so people who do happen to update from source don't go possibly bricking their systems... just a thought.
As for me, I've been slowly messing with getting a proper menu working (bottom screen, similar to how pasta cfw does it) and still have text output on top screen when doing xorpads etc. Still a bit to do yet though.
I don't have an idea on how to use that dangerous stuff for anything legitimate yet, but I'm pretty sure something will come up later. If you have an idea, just let me know.
That sounds good! Actually I've been thinking about doing a bare bones menu system myself, cause the old menu gets more and more cluttered. You've got nothing on Github yet, though, correct?
Also, I noticed you have an own rxTools branch now. Are you trying to get that working on N3DS or did you just add the Brahma loader?
--------------------- MERGED ---------------------------
Okay, I'll fix the launcher tomorrow. The dumped file is actually not the same as the ticket.db. It contains only the useful stuff, therefore it also is a lot smaller (~2MB vs ~35mb). If you try it in FunkyCIA, you will see that it finds the exact same numbers of tickets in your ticket.bin as it would have found in your ticket.db.
Nand restore could be handy for people who upgrade/downgrade reasonably often, instead of using the gateway launcher (or hard mod when it isn't needed).
Nothing on github yet, still just working on it locally a bit at a time when i can.
rxTools has been there since he first put it on github.
just been updating it as he does. Haven't done anything to it.
Dammit... I guess you'll have to resort to Ninjhax then. I think the launcher.dat may only work on O3DS. Thanks for testing!
@Shadowtrance:
The last commit in my bootstrap branch contains something dangerous, but it is disabled (meaning: without a change in the source code, you won't have it). I guess you know what to do
.I also coded a very simple menu system. It is nothing much, but the structs and the general menu system may provide a base for something better (unless you're already beyound the point of having use for a base). I think I should also add short feature descriptions to the menu structs, dunno yet. Also, note that Decrypt9 now uses a work directory "/Decrypt9" instead of the root directory. It is better that way (the system titles dumper dumps > 100 titles), but I don't know if it will stay. It would break some tutorials and would lead to noob questions.
Last edited by d0k3,
Dammit... I guess you'll have to resort to Ninjhax then. I think the launcher.dat may only work on O3DS. Thanks for testing!
@Shadowtrance:
The last commit in my bootstrap branch contains something dangerous, but it is disabled (meaning: without a change in the source code, you won't have it). I guess you know what to do
I also coded a very simple menu system. It is nothing much, but the structs and the general menu system may provide a base for something better (unless you're already beyound the point of having use for a base). I think I should also add short feature descriptions to the menu structs, dunno yet. Also, note that Decrypt9 now uses a work directory "/Decrypt9" instead of the root directory. It is better that way (the system titles dumper dumps > 100 titles), but I don't know if it will stay. It would break some tutorials and would lead to noob questions.
Yeah I just noticed the latest commits.
DANGER ZONE! The work dir is a good idea, got enough crap on the root of my sd card as it is haha
As for the menu, mine is probably beyond needing it as a base but i still got a lot to do/clean up etc and still graphics to do/finish first. It's a different approach though.
I started a fresh branch for it based on your bootstrap branch, I'll just manually add any changes you make to yours there.
I'll probably do some more on it later today/tonight, but for now i have to finish an assignment due tomorrow...
EDIT: @d0k3 we have a small (but possibly annoying) problem... i triggered the ncchinfo.bin error (deliberately) when testing stuff and it's too long for one line it seems and cuts off the edge of the top screen (sort of wraps around to the other side of the same line on top screen too) onto the bottom screen.
It's not isolated to your source because i checked and it does it with mine too (bootstrap-mod). Kinda weird.
Probably get graphics done over the weekend.
Pics in spoiler...
Last edited by Shadowtrance,
Nice!
As for that problem: I think that is because the memory regions for one of the lower screen framebuffers is right next to the memory region of one of the upper screen framebuffers. I guess I will just add string length checking to Debug and fix that errormessage in the NCCH Padgen function. Expect a fix soon and thanks for testing!
As for that problem: I think that is because the memory regions for one of the lower screen framebuffers is right next to the memory region of one of the upper screen framebuffers. I guess I will just add string length checking to Debug and fix that errormessage in the NCCH Padgen function. Expect a fix soon and thanks for testing!
- Joined
- Feb 9, 2015
- Messages
- 321
- Trophies
- 0
- Age
- 31
- Location
- The state with lots of wives
- XP
- 428
- Country
I was getting the same error on my N3DS. Just went back to the older version for now. I'm excited with the new features!
I triggered the "error" intentionally to test stuff out (messing with new GUI ideas on my end), unless you mean the issue with it going off screen/on to the bottom screen, then that shouldn't happen i guess. haha
Edit: (double posts are bad).
@d0k3 (or anyone looking)...Toolkit or no toolkit...that is the question. (top screen image btw)
Last edited by Shadowtrance,
That looks good! I think without the 'Toolkit' it is better. Or you should design the 'toolkit' writing differently.
Similar threads
