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.Ahh last i checked the ticket.db is always 37 MB...
i could be wrong though...
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.Ahh last i checked the ticket.db is always 37 MB...
i could be wrong though...
I'd rather dump the whole thing intact to be on the safe side, pretty sure people have had issues with his ticket dumper/injector (might have been fixed, don't know).
Okay, I took a look, and I think the problem lies in these lines:
The FileOpen() function (at least the one used in Decrypt9) can only access the SD card. That's somehow hard coded in there. There are also limitations on which "Archives" (as Nintendo calls it) we have access to, and I'm unsure if Brahma gives us the access to undecrypted TWL. If we were able to decrypt it, though, that would be a whole different story.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.
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.
Alright, big update here! First, look at the thread title: It's changed to reflect the shift in focus for this project.
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.
It should. If it doesn't work I already got some ideas how to fix.woh, nice.
but the laucher can be used on n3DS MSET 9.0 ?
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.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.
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?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.
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.the launcher is not working for me.
And why the ticket dumped is in .bin and not .db ?
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?
New launcher.dat attached. This should work and it will also be part of the next release. Could you tell me if this works for you?the launcher is not working for me.
Dammit... I guess you'll have to resort to Ninjhax then. I think the launcher.dat may only work on O3DS. Thanks for testing!always crash and back to home menu
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.
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!
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!
That looks good! I think without the 'Toolkit' it is better. Or you should design the 'toolkit' writing differently.@d0k3 (or anyone looking)...Toolkit or no toolkit...that is the question.