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

  • Thread starter Thread starter WulfyStylez
  • Start date Start date
  • Views Views 211,471
  • Replies Replies 729
  • Likes Likes 51
The op says the console ID should be obtainable from any DSi export, but there's currently only a way to do it with sudoku and fieldrunners. How can we obtain it using other DSiWare?

I'm asking because, as those who follow the 3DS scene know, it is now possible to inject sudokuhax into any larger dsiware, and I'm assuming the method used should apply here as well.
 
The op says the console ID should be obtainable from any DSi export, but there's currently only a way to do it with sudoku and fieldrunners. How can we obtain it using other DSiWare?

I'm asking because, as those who follow the 3DS scene know, it is now possible to inject sudokuhax into any larger dsiware, and I'm assuming the method used should apply here as well.
you can get it with any exportable dsiware
 
The op says the console ID should be obtainable from any DSi export, but there's currently only a way to do it with sudoku and fieldrunners. How can we obtain it using other DSiWare?

I'm asking because, as those who follow the 3DS scene know, it is now possible to inject sudokuhax into any larger dsiware, and I'm assuming the method used should apply here as well.
did you even read the OP?
 
Just a note to people whom have already managed to run homebrew code on DSi:

I've released a tool for dumping several DSi memory areas & chip IDs here: http://gbatemp.net/threads/dswifi-asm-port-and-bugs-in-dswifi-hll-version.447174/#post-6930129 mostly related to finding (alternate) camera manufacturers & unknown wifi hardware revisions; I am sure that there's a very good chance to find some formerly unknown stuff with that tool.

Would be great if you could run the "dsdump.dsi" tool on your DSi (or 3DS), and the "dsdump.exe" tool (on a Windows PC). It should be hopefully working and easy to use, the most challenging part might be to disable WPA encryption in your wifi access point.
 
  • Like
Reactions: I pwned U!
Just a note to people whom have already managed to run homebrew code on DSi:

I've released a tool for dumping several DSi memory areas & chip IDs here: http://gbatemp.net/threads/dswifi-asm-port-and-bugs-in-dswifi-hll-version.447174/#post-6930129 mostly related to finding (alternate) camera manufacturers & unknown wifi hardware revisions; I am sure that there's a very good chance to find some formerly unknown stuff with that tool.

Would be great if you could run the "dsdump.dsi" tool on your DSi (or 3DS), and the "dsdump.exe" tool (on a Windows PC). It should be hopefully working and easy to use, the most challenging part might be to disable WPA encryption in your wifi access point.
speaking of unknown stuff, my consoleID is odd, it starts with 08a19, which seems to be undocumented (not on gbatek or anywhere I can find) also, we have someone else with a DSi with an odd CID (he used both an external reader as well as a game exploit to extract it from memory) and he's having a hard time decrypting his NAND...

EDIT: that consoleID is verified real too, it decrypts my NAND fine, so I know it's correct

--------------------- MERGED ---------------------------

Yeah, I had read it a long time ago so I just skimmed over it to be honest. Sorry for annoying you!
also, injecting DSiware the way you wanted to test doesn't work. It shows in the menu but errors out when you try to start it, unfortunately
 
Last edited by dark_samus3,
speaking of unknown stuff, my consoleID is odd, it starts with 08a19, which seems to be undocumented (not on gbatek or anywhere I can find) also, we have someone else with a DSi with an odd CID (he used both an external reader as well as a game exploit to extract it from memory) and he's having a hard time decrypting his NAND...

EDIT: that consoleID is verified real too, it decrypts my NAND fine, so I know it's correct

--------------------- MERGED ---------------------------


also, injecting DSiware the way you wanted to test doesn't work. It shows in the menu but errors out when you try to start it, unfortunately
Ah, that's a dissapointment. I wonder why it works on a 3ds and not here. Maybe it's just a difference in how the twl_firm handles things? (Wouldn't really know, noob)

Edit: Misspelled a word.
 
Last edited by ThisIsDaAccount,
speaking of unknown stuff, my consoleID is odd, it starts with 08a19, which seems to be undocumented (not on gbatek or anywhere I can find) also, we have someone else with a DSi with an odd CID (he used both an external reader as well as a game exploit to extract it from memory) and he's having a hard time decrypting his NAND...
Thanks for the info! So the Port 4004D00h Console ID values would be:
Code:
  08A20nnnnnnnn1nnh  for DSi
  08A19???????????h  for some other DSi
  08201nnnnnnnn1nnh  for DSi XL
  ????????????????h  for 3DS
Do you have some more info on the other digits after 08A19? Or could PM them? Mostly I'd wonder if they are all BCD (0..9) and if it's having the fixed "1" in bit 8-11 like the others. Oh, and is it from DSi or DSi XL or something else? I don't know if there's any relation between ID value and console model.

For the CIDs, WulfyStylez mentioned KLM5617EFW-B301 quite a while ago. Just added it to gbatek, so there are now three known CIDs:
Code:
  MY ss ss ss ss 03 4D 30 30 46 50 41 00 00 15 00  ;DSi CID KMAPF0000M-S998
  MY ss ss ss ss 32 57 37 31 36 35 4D 00 01 15 00  ;DSi CID KLM5617EFW-B301
  MY ss ss ss ss 03 47 31 30 43 4D 4D 00 01 11 00  ;3DS CID
Does that updated list cover the odd CID? Different CIDs should (EDIT: "should NOT") cause problems when decrypting the memory (unless one would read the value backwards, or omit the ending 00-byte, or the like).
 
Last edited by nocash123,
  • Like
Reactions: I pwned U!
Thanks for the info! So the Port 4004D00h Console ID values would be:
Code:
  08A20nnnnnnnn1nnh  for DSi
  08A19???????????h  for some other DSi
  08201nnnnnnnn1nnh  for DSi XL
  ????????????????h  for 3DS
Do you have some more info on the other digits after 08A19? Or could PM them? Mostly I'd wonder if they are all BCD (0..9) and if it's having the fixed "1" in bit 8-11 like the others. Oh, and is it from DSi or DSi XL or something else? I don't know if there's any relation between ID value and console model.

For the CIDs, WulfyStylez mentioned KLM5617EFW-B301 quite a while ago. Just added it to gbatek, so there are now three known CIDs:
Code:
  MY ss ss ss ss 03 4D 30 30 46 50 41 00 00 15 00  ;DSi CID KMAPF0000M-S998
  MY ss ss ss ss 32 57 37 31 36 35 4D 00 01 15 00  ;DSi CID KLM5617EFW-B301
  MY ss ss ss ss 03 47 31 30 43 4D 4D 00 01 11 00  ;3DS CID
Does that updated list cover the odd CID? Different CIDs should cause problems when decrypting the memory (unless one would read the value backwards, or omit the ending 00-byte, or the like).
well, the guy with odd CID does report his matching the one added to the list. That console also has a consoleID of 08202nnnnnnnn1nnh and is from a DSi XL, so there's another to add to the list. The 08A19 consoleID does seem to follow the 08A19nnnnnnnn1nnh structure, and is from a normal DSi, bought near the end of the DSi lifecycle. If you want/need, I can send both consoleIDs in a PM.
 
Last edited by dark_samus3,
Is there any way I can extract the NAND without any soldering (such as dumping to SD card through DSi Homebrew)? I'd gladly appreciate it if I could be able to dump my DSi Nand, so I can do some research on it.

I'm completely unexperienced at soldering, so if this is the only way, then I can't do it (unless I want to accidentally break my DSi through attempting to solder).
 
Is there any way I can extract the NAND without any soldering (such as dumping to SD card through DSi Homebrew)? I'd gladly appreciate it if I could be able to dump my DSi Nand, so I can do some research on it.

I'm completely unexperienced at soldering, so if this is the only way, then I can't do it (unless I want to accidentally break my DSi through attempting to solder).
Need a primary dsiware exploit. Not easy finding those at all.
 
Kind of a stupid question, but now that the dsiwarehax exploits are open source, couldn't you just comment out whatever lines disable NAND read/write and recompile to get NAND access? Kind of a moot point now that DgTool's out but whatever
 
@OctopusRift @Gadorach

Just a super stupid post on my side here... but wouldn't something like soundhax for the 3ds also work on the dsi?
I can't imagine that on the much older system the same flaw / exploit / entrypoint is absent, but available on the newer one...

Only 0.000001 cent from my side here, knowing nothing to specific of the dsi but... its just that prior this xmas, soundhax was not available but now is.
Maybe it can be ported to the dsi and would allow us for hacking and nand dumping... without extensive hardware solutions.
http://nintendo.wikia.com/wiki/Nintendo_DSi_Sound
Dsi Sound supports m4a... I guess the file extension does not matter but the code inside does.

Just a thought here.
 
@OctopusRift @Gadorach

Just a super stupid post on my side here... but wouldn't something like soundhax for the 3ds also work on the dsi?
I can't imagine that on the much older system the same flaw / exploit / entrypoint is absent, but available on the newer one...

Only 0.000001 cent from my side here, knowing nothing to specific of the dsi but... its just that prior this xmas, soundhax was not available but now is.
Maybe it can be ported to the dsi and would allow us for hacking and nand dumping... without extensive hardware solutions.
http://nintendo.wikia.com/wiki/Nintendo_DSi_Sound
Dsi Sound supports m4a... I guess the file extension does not matter but the code inside does.

Just a thought here.
Only thing is, it needs to be in .mp4 format, .m4a format is not supported. And yes, I'm sure soundhax can be ported over. We have to try. If anyone is good at programming, please port it over.
 
Only thing is, it needs to be in .mp4 format, .m4a format is not supported. And yes, I'm sure soundhax can be ported over. We have to try. If anyone is good at programming, please port it over.
m4a is just a container, and it is supported. The actual format behind the audio is AAC. m4a/mp4 can both contain AAC, or something else, so it doesn't matter the extension as much as it matters the audio type. It could be possible that there is a vulnerability in sound, but it isn't the same as the one on 3ds if it's there
 
@OctopusRift @Gadorach

Just a super stupid post on my side here... but wouldn't something like soundhax for the 3ds also work on the dsi?
I can't imagine that on the much older system the same flaw / exploit / entrypoint is absent, but available on the newer one...

Only 0.000001 cent from my side here, knowing nothing to specific of the dsi but... its just that prior this xmas, soundhax was not available but now is.
Maybe it can be ported to the dsi and would allow us for hacking and nand dumping... without extensive hardware solutions.
http://nintendo.wikia.com/wiki/Nintendo_DSi_Sound
Dsi Sound supports m4a... I guess the file extension does not matter but the code inside does.

Just a thought here.
That's not stupid at all. And I'd be more than willing to put hours into it once I'm off of school for a bit.

Never occurred to me honestly. :)
 
Is it possible to use the tickets from a decrypted NAND with NUS Downloader to download and decrypt titles from NUS? Or does NUS Downloader have no support for that?
 

Site & Scene News

Popular threads in this forum