Homebrew [RELEASE] TWLTool - DSi downgrading, save injection, etc multitool

[nocash123]

Interesting. I didn't knew that there were DSi's with more preinstalled titles (other than Browser and Flipnote), and least that those extra titles were having zeroes in the tik's console ID. Yeah, should be possible to install copies of those titles on other DSi consoles (within same region), I couldn't imagine why one could actually want to install that titles though... unless somebody finds exploits in those titles.

Did you try destroying the RSA signature in some tik file, too? Would be very interesting if the Launcher would still accept it. Just make a backup of your mmc dump before trying to destroy tik's and other things.

 

[I pwned U!]

I couldn't imagine why one could actually want to install that titles though...

The Nintendo DSi Shop will be shutdown, and in less than a month, this will become the only way to install those (or any other) new titles.

Did you try destroying the RSA signature in some tik file, too? Would be very interesting if the Launcher would still accept it. Just make a backup of your mmc dump before trying to destroy tik's and other things.

I did not try this yet, but I will today. I have just changed the signatures of two titles (a preinstalled one and a purchased one) to the following:

13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37 13 37

It is time to encrypt everything and see what happens...

Edit:

I just tried the following command for encrypting tickets, but it just results in the output of a 0 byte file.

twltool syscrypt --consoleid (my console id) --in out.tik --out in.tik

This happens with both original and modified signatures in decrypted tickets. Is there something else that I should add to my command, or is this a bug in TWLTool?

Nevermind, I should have looked back at the documentation first...

printf("syscrypt: crypt system files with ES block crypto (dev.kp, tickets, ...)\n");
printf("  --in [infile]                 Input SRL\n");
printf("  --out [outfile]               Output file (optional)\n");
printf("  --consoleid [file/hex ID]     DSi ConsoleID\n");
printf("  --encrypt                     Encrypt file\n");
printf("  --3ds                         Using 3DS ConsoleID");

Problem solved!

twltool syscrypt --consoleid (my console id) --encrypt --in out.tik --out in.tik

 

[I pwned U!]

I apologize for the bump, but for some reason, everytime I encrypt an unmodified and decrypted ticket, the file looks very different from the original encrypted ticket. Is this supposed to happen? On top of that, the new encrypted ticket looks different each time that I generate it from the decrypted one.

 

[nocash123]

I apologize for the bump, but for some reason, everytime I encrypt an unmodified and decrypted ticket, the file looks very different from the original encrypted ticket. Is this supposed to happen? On top of that, the new encrypted ticket looks different each time that I generate it from the decrypted one.

The "nonce" in the ES Block encryption footer is just random, isn't it? So yes, the whole file can look entirely different after (re-)encryption. If you want to make sure that it's really intact: Try to re-decrypt it.

 

[I pwned U!]

The "nonce" in the ES Block encryption footer is just random, isn't it? So yes, the whole file can look entirely different after (re-)encryption. If you want to make sure that it's really intact: Try to re-decrypt it.

I just did this, and HxD said that the decrypted files are identical! I will resume the "1337 Sig Experiment" later today.

 

[I pwned U!]

Breaking news! ​

Both preinstalled titles (tested with Photo Clock) and purchased titles (tested with Petit Computer) work with the "1337 Sigs!"

My findings:

• Both launched successfully.
• Both ran perfectly after launching.
• Both were able to save correctly after changing some settings.
• Both showed up in Data Management without automatically being deleted afterwards.
• Both could be copied to and from the SD card via Data Management.
• Both could be manually deleted in Data Management.
• Both titles launched and ran perfectly after copying them back to the System Memory from the SD card via Data Management.

Here is what this means (I am updating certain parts of the quote to reflect the discovery):

The bigger question would be if it's It's possible to copy .tik files from one console to another. The shop .tik's do contain a console ID value, and, if that ID is verified by the launcher, then one need to change that ID to match with the target console - doing that would make the RSA signature invalid, but I think that would be that is no problem at all (from what I can see in the launcher code (as of firmware v1.4E), the launcher is checking RSA for .tmd files, but I really can't find any there are no RSA checks for .tik files). I am quite sure that it's It's possible to do that stuff, I've just never tried out of laziness (didn't want to go through the hassle to decrypt/re-encrypt the eMMC dump and .tik's) it has already been tested via breaking .tik signatures, and now it needs to be tested with someone trying out the console ID edit on someone else's .tik to launch and run the person's DSiWare.

If anyone else with a hardmodded US DSi wants to help me out, please PM me with a list of the DSiWare that you have. If you have titles that I do not have, we can test console ID edits on each other's tickets to see if they work on a different DSi!

Unless...

Does anyone know whether or not DSi .app, .tik, and .tmd files for DSiWare are identical to the structures of the 3DS ones for DSiWare? If this is the case, then this will be much easier to test!

 

[Apache Thunder]

DSi Tmd files are somewhat similar to 3DS. But smaller. I think 3DS added some extra data I don't really understand fully how the tmd files work, so I can't tell you exactly is different besides how they look in a hex editor. They are signed I believe so you may not be able to edit them.. 3DS does not use tik files at all anymore. The .app files are not the same. The .app files on 3DS are CXI containers which operate differently then the files on DSi. DSi .app files are basically just SRLs. Almost identical to DS rom files but with extra stuff in the header and DSi extended binaries.

NTR/TWL mode on 3DS uses the same files as a DSi. Except a few files are not present like tik files and the SRL for "launcher" (DSi System Menu) is stored in arm11 section of TWL_FIRM. It's also a stripped down launcher with no menu of sorts.

The .app files in TWL partition on 3DS are the same as the ones on DSi. However I believe the TMD files are using the new format CTR titles use. Tik files are not present at all on TWL partition. The tickets were moved to a database type file on CTR_NAND along with tickets for CTR titles. The tickets are checked CTR side before legacy mode boots. In fact most of the security related stuff is checked while still in CTR mode. There's minimal checking TWL_FIRM it self does besides the RSA sigs in the SRLs and flashcart related checks it may do if starting a slot-1 card.

 

[metroid maniac]

The .app files are not the same. The .app files on 3DS are CXI containers which operate differently then the files on DSi. DSi .app files are basically just SRLs.

...

The .app files in TWL partition on 3DS are the same as the ones on DSi.

Are you comparing CTR content on the 3DS and TWL content on the DSi on the first line? I'm a little confused.

 

[Apache Thunder]

Are you comparing CTR content on the 3DS and TWL content on the DSi on the first line? I'm a little confused.

I was responding to this:

Does anyone know whether or not DSi .app, .tik, and .tmd files for DSiWare are identical to the structures of the 3DS ones for DSiWare? If this is the case, then this will be much easier to test!

I didn't see the part about DSiWare. Most of my statement is still true however. TMD files aren't the same as they use the upgraded format CTR titles also use and tik files don't exist anymore. The .app files for DSiWare are the same for both consoles however and I also mentioned that in my original reply.

The TMD files are signed so I don't think you'd be able to strip out the extra data to make them conform to what the DSi expects. You'll have to use TMD files generated by a DSi/DSi eShop server.

As for the tickets, they aren't in individual files anymore and are found in the same location as CTR tickets. You'll basically have to forge the entire ticket to make it work on a DSi which I don't know if you can do or not. But if DSi's launcher doesn't check the RSA sig on launch of a title, then I guess you could just make your own ticket entirely and use that. It'd just have to have the correct console id and encryption.. You'd really only need a valid TMD file then.

Though isn't title key stored in the tik file? You'd have to forge that too. Not sure if they handle title keys the same way on DSi or not. I don't think you can just make a fake title key either. Has to be a valid one from an existing console. Though I think title key would work for any DSi console as long as the rest of the tik is valid supposedly. Also pretty sure you need a proper title key to get it from DSi eShop since like with 3DS eShop, DSi files have an additional layer of encryption that requires the title key to decrypt.

 

[ahezard]

I have performed some trials with no$gba (sadly I do not have a real dsi only an nand dump given by a friend) and I got some success : I was able to inject the sudoku app (v0) into this nand even if this app was not present initially. I got the decrypted .app from DSiWare_usa_sudokuhax_injection kit found on the internet. I created the .tik using an existing one decrypting it and just updating the title id. I got the .tmd file using nusdownloader (it is not encrypted). It is running in no$gba even if I use the "insist on rsa" option in dsi rsa signature so it should works on a real hardmodded dsi right?

 

[Apache Thunder]

TMD isn't encrypted on NUS? Someone should start downloading them all then....

 

[ahezard]

TMD isn't encrypted on NUS? Someone should start downloading them all then....

Very good idea, this will be the hardest part to found soon since the .app can be taken from a 3ds and the .tik can be faked. Can someone confirm that this method to add a dsiware works on a real hardmodded dsi?

 

[metroid maniac]

TMD isn't encrypted on NUS? Someone should start downloading them all then....

Can you download the TMD knowing purely the Title ID, or some other easily accessible identifier?
If this CDN is going down then we better pull everything we can ASAP.

 

[ahezard]

Can you download the TMD knowing purely the Title ID, or some other easily accessible identifier?
If this CDN is going down then we better pull everything we can ASAP.

You only need the title id, optionally the version. The title id can even be guessed from the 3ds one you just have to replace the first 5 digits (example from sudoku on 3ds : 000480044b344445 => 000300044b344445 on dsi)

 

[bobrocks95]

This seems like a fun weekend project. I'll be reading through the rest of the thread, but would it be possible to modify the region of DSiWare games, or would I need to use my US DSi for US rips (I have a JPN DSi XL)?

EDIT: lol nevermind I popped open my DSi and there's no way I've got the SMD soldering skills to get the data line, unless someone's offering install services . Still an interesting question about region modding I guess?

 

[redunka]

Well, it is possible to change region of a SRL (DSiWare rom file), but would DSi launch it?
Region flags are stored in extended header, which is protected by RSA signature.
TWL_FIRM on 3DS (without sig checks patched) doesn't boot DSiWare apps with broken sig, that's for sure.
Has anyone tried to break SRL header's signature and see if it still works on real hardware (DSi)?
If DSi allows fake tickets, there can be more fails (but it probably does check SRL's though).

I'd really like to know if there is, or will ever be a way to launch DSiWare titles with invalid signature on a real DSi.
Not only because of region free, but also because I have a couple of DSiWare romhacks (one is unfinished for now).
Yeah, I can test and use them on CFW'd 3DS, but it'd be really nice to be able to run them on original DSi too (even though I don't have one).

On an unrelated note: does 3DS check TMD's for DSiWare titles at all?
If it does, why can't it compare .app's size and hash with the ones from TMD?
That would prevent us from replacing SRL from legit title with another one, wouldn't it?
And even if we would replace TMD, it could still check if title ID from TMD matches the one from ticket.
Since TMD's are signed, we wouldn't be able to change title ID, thus losing an ability to launch "wrong" titles.
Don't get me wrong, it's not that I really want Nintendo to fix this, just pure curiosity.
Also, excuse me if this whole post is a complete nonsence.

 

[ahezard]

Well, it is possible to change region of a SRL (DSiWare rom file), but would DSi launch it?
Region flags are stored in extended header, which is protected by RSA signature.
TWL_FIRM on 3DS (without sig checks patched) doesn't boot DSiWare apps with broken sig, that's for sure.
Has anyone tried to break SRL header's signature and see if it still works on real hardware (DSi)?
If DSi allows fake tickets, there can be more fails (but it probably does check SRL's though).

I'd really like to know if there is, or will ever be a way to launch DSiWare titles with invalid signature on a real DSi.
Not only because of region free, but also because I have a couple of DSiWare romhacks (one is unfinished for now).
Yeah, I can test and use them on CFW'd 3DS, but it'd be really nice to be able to run them on original DSi too (even though I don't have one).

On an unrelated note: does 3DS check TMD's for DSiWare titles at all?
If it does, why can't it compare .app's size and hash with the ones from TMD?
That would prevent us from replacing SRL from legit title with another one, wouldn't it?
And even if we would replace TMD, it could still check if title ID from TMD matches the one from ticket.
Since TMD's are signed, we wouldn't be able to change title ID, thus losing an ability to launch "wrong" titles.
Don't get me wrong, it's not that I really want Nintendo to fix this, just pure curiosity.
Also, excuse me if this whole post is a complete nonsence.

You may be right. I just realized that I am running the v0 sudoku .app with the v257 .tmd and it runs anyway. There is a check about the title id between .tmd and .app and the .app have to be modcrypted but the size & sha signature in the tmd file are not checked respectively to the .app

 

[Valery0p]

Two little questions next to all this enthusiasm:
1- Can We extract the ticket of a title copy on sdcard? Because SLR extractor needs it to dercypt the app...right?
2-Anyone else here have a copy of sudoku EUR ticket? (even v256...) Is going to be a meme...


Anyway, welcome back @ahezard

 

[ahezard]

Two little questions next to all this enthusiasm:
1- Can We extract the ticket of a title copy on sdcard? Because SLR extractor needs it to dercypt the app...right?
2-Anyone else here have a copy of sudoku EUR ticket? (even v256...) Is going to be a meme...


Anyway, welcome back @ahezard

1- I do not think so, you need hardmod or an existing dsiware entrypoint to do that (but I do not recommend to play with your nand if you do not have hardmod)
2- you do no need the ticket (it can be faked) you only need the tmd which is easy to get using nusdownloader v1.9 (title id of sudoku eur last version 000300044b344456)

 

[redunka]

You may be right. I just realized that I am running the v0 sudoku .app with the v257 .tmd and it runs anyway. There is a check about the title id between .tmd and .app and the .app have to be modcrypted but the size & sha signature in the tmd file are not checked respectively to the .app

Hmm, I wonder if Nintendo's just being lazy (or stupid, or both), or they actually can't implement size & sha checks for some reason?
I mean, the fact that we can just replace one .app with another and it'd still run, as long as the ticket for original title is legit, that's old news.
But why haven't Nintendo ever tried to do something about it, especially when it became clear that SRL's aren't checked during system transfer either?
They did try to prevent dsiwarehax downgrading, but only by refusing to perform systransfer when there's no other purchases for account but certain dsiware titles.
What's the point of having metadata files then, if not for validating content?