Take a look at the readme in the new D9 release (released today). Download as always here.
What you want to do is dump all tickets from the clean one and check (by the naming scheme) for console ids.
What you want to do is dump all tickets from the clean one and check (by the naming scheme) for console ids.
Either I'm too dense to understand, or we have our wires crossed lol.
I think what you are talking about is the procedure of getting the unique tickets from one 3ds to work on the other. That's not what I'm talking about here.
I'll try to explain this with 2 pictures:
See, assume the first picture is a clean .db (it's not.. just an assumption) .. see the highlighted title? This one was preinstalled on the 3ds, and has a unique consoleID.
So I'm saying if I dump this ticket, (again assuming this was clean) and injected it in the other 3ds that obviously have different consoleID, The console ID from the first ticket will transfer to the second 3ds?
And if yes, what happens if I download new stuff from eshop on my second 3ds after the injection? Will I now have a .db with a mixture of both console IDs?
On a semi-unrelated note, is there any harm for me to display my console ID like that? I'll remove the post if I shouldn't be doing so..
Yup, that's what I meant. Check if there is actually stuff with console ids other than zero in there. What is this tool, btw?Either I'm too dense to understand, or we have our wires crossed lol.
I think what you are talking about is the procedure of getting the unique tickets from one 3ds to work on the other. That's not what I'm talking about here.
I'll try to explain this with 2 pictures:
See, assume the first picture is a clean .db (it's not.. just an assumption) .. see the highlighted title? This one was preinstalled on the 3ds, and has a unique consoleID.
So I'm saying if I dump this ticket, (again assuming this was clean) and injected it in the other 3ds that obviously have different consoleID, The console ID from the first ticket will transfer to the second 3ds?
And if yes, what happens if I download new stuff from eshop on my second 3ds after the injection? Will I now have a .db with a mixture of both console IDs?
On a semi-unrelated note, is there any harm for me to display my console ID like that? I'll remove the post if I shouldn't be doing so..
So, the problem in your "clean" db is you have at least one ticket with a console id unequal zero. I guess if you use FBI to install the same ticket (from the other console) , the old one would get replaced. Needs experimentation.
Other than that, yup, you can have a mixture of console ids in your ticket.db.
I believe that is CDN-FX.
https://gbatemp.net/threads/release-cdn-fx-the-ultimate-eshop-content-downloader.414004/
Yeah ok, that was the problem I'm facing. A clean ticket from a new console is bound to have at least 1 non-zeroed ticket .. dumping that and injecting it in another console for usage will ultimately lead to a mixture of tickets, which defeats the purpose of a "clean" ticket I suppose.. It would be great if there is a way to edit or "clean" out the .db opposed to these workarounds.. But like I said, not sure how technically possible that is
As for installing the same ticket from the other console would show them twice in the .db, once with the unique consoleID, and the other as a zeroed out ConsoleID (as that's the only way a CIA would install) .. Here is a picture to show what I mean:
As for the tool, like @Xenosaiga said, this is CDN-FX (formerly known as GroovyCIA) by @Ptrk25 .. It's a great GUI for FunkyCIA (literally ported from FunkyCIA) with some additions to it. Biggest addition is that it supports reading the title names from an XML.. A new version of it is being worked on but it's already the best tool I've personally seen in it's department
Alright, that is somewhat bad... I wonder, can't a ticket.db be found that doesn't have any console unique stuff? Also... Do you know what titles have that non zero console id? Clean removal of tickets is not possible afaik. Also, keep in mind that the ticket.db has two partitions, with only one active at a time (for hotswapping I assume).Yeah ok, that was the problem I'm facing. A clean ticket from a new console is bound to have at least 1 non-zeroed ticket .. dumping that and injecting it in another console for usage will ultimately lead to a mixture of tickets, which defeats the purpose of a "clean" ticket I suppose.. It would be great if there is a way to edit or "clean" out the .db opposed to these workarounds.. But like I said, not sure how technically possible that is
As for installing the same ticket from the other console would show them twice in the .db, once with the unique consoleID, and the other as a zeroed out ConsoleID (as that's the only way a CIA would install) .. Here is a picture to show what I mean:
As for the tool, like @Xenosaiga said, this is CDN-FX (formerly known as GroovyCIA) by @Ptrk25 .. It's a great GUI for FunkyCIA (literally ported from FunkyCIA) with some additions to it. Biggest addition is that it supports reading the title names from an XML.. A new version of it is being worked on but it's already the best tool I've personally seen in it's department
I assume it's possible some 3ds versions out there won't have any preloaded stuff, and therefore would only have system titles on the ticket, which is universal. Universal titles, similar to "legit titles" are zeroed titles by default, which is why they can be installed on any 3ds without any side effects such as it getting removed when visiting eshop.
But even if systems with zeroed tickets do exist, if simply dumping and injecting on another console would have any undesired side-effect, I wouldn't know.. Just because we can see the console ID on the ticket might not be necessarily be the only place where it has console specific ID or something.. I don't know I'm spitballing here.
If you do have an interest in looking into making something for this. I would talk to @Steveice10 .. He seems to have the most knowledge/experience with playing with the .db file .. Presumably When you delete a title and A ticket from FBI, it marks that title on the db for deletion for whenever you download something new for eshop. This was never confirmed though, some people say yes, and some people say no. I can't seem to get a straight answer. In any case, talking to him would be the place where I would start
except that @Steveice10 uses AM services ARM11
https://www.3dbrew.org/wiki/Application_Manager_Services
https://www.3dbrew.org/wiki/Application_Manager_Services
hi @d0k3,
Sorry for my noob question but why Decrypt9WIP can make a full(1888MB Toshiba) and a min size(1240MB Samsung) backup and Hourglass9 makes automatically a min size backup without letting you choose first?Is the min size better?
also what is the difference of a full size vs a min size backup?
I was using my N3DSXL(Luma, a9lh) and the NAND backups match Plailect's guide
answer this post when you have free time
Thanks!
Sorry for my noob question but why Decrypt9WIP can make a full(1888MB Toshiba) and a min size(1240MB Samsung) backup and Hourglass9 makes automatically a min size backup without letting you choose first?Is the min size better?
also what is the difference of a full size vs a min size backup?
I was using my N3DSXL(Luma, a9lh) and the NAND backups match Plailect's guide
answer this post when you have free time
Thanks!
normal size nand dumps just have extra padding. min size dumps work fine and are faster to dump, while still being valid.
Exactly - we can't do what SteveIce10 does, because we have no access to AM services. Also, those .db files have not been fully figured out yet (thus we can't do any edits). It is highly unlikely the console ID is anywhere else inside the ticket.db but in the tickets themselves (why should it?). You can try to find out, though. Find a clean ticket.db first, then try to find the console ID via a hex editor.
Yup, good answer. There really is no good reason for a standard user to have a full sized NAND backup. Everything you need is there, in the min size one.
You wouldn't say?
This was clear from the start, we were wondering if the console id is stored outside of the tickets themselves.
How can I update to a new Decrypt9 version, if I normally use the payload?
Do I only have to replace the payloads/x_Decrypt9.bin by the new one? Or is there anything else that I have to replace?
Thanks for your help.
Do I only have to replace the payloads/x_Decrypt9.bin by the new one? Or is there anything else that I have to replace?
Thanks for your help.
Nope. That's pretty much it. Download. Place Decrypt9.bin in the payload folder. Delete the old payload. Rename the new Decrypt9.bin to the old payloads name which using what you provided would be X_Decrypt9.bin
Last edited by Xenosaiga,
Hello. Maybe someone here can help me. I recently switched from rxtools to arm9loaderhax+luma. And I noticed that all of my gba game saves are gone. I made a thread about it here.
https://gbatemp.net/threads/i-just-...d-that-all-my-gba-save-files-are-gone.442513/
I tried using decrypt 9. I restored my old sysnand, dumped the gbavc save, restored my new sysnand, injected the gbavc save. But the saved still weren't there. Not sure what to do now.
https://gbatemp.net/threads/i-just-...d-that-all-my-gba-save-files-are-gone.442513/
I tried using decrypt 9. I restored my old sysnand, dumped the gbavc save, restored my new sysnand, injected the gbavc save. But the saved still weren't there. Not sure what to do now.
Can you run this with a Sysnand 4.5 on an Old Gateway 3DS without arm9loader installed if you use the browser hack? I am currently trying to backup my Emunand. I have 4.5 U sysnand on and Old 3DS.
Last edited by TheMasterFOu,
Similar threads
(
