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

[Billy Acuña]

Or maybe... emunand running on the SDcard! And probably having unlimited space!

Unlikely to have emunand on DSi for a long time, don't put your hopes and wait for the @ahezard's amazing nds-bootstrap and forget emunand.

 

[Flashed]

Or maybe... emunand running on the SDcard! And probably having unlimited space!

I think things like that will never exist.

 

[Ryccardo]

Or maybe... emunand running on the SDcard! And probably having unlimited space!

Won't happen for the exact same reason emunand doesn't work in GBA/DS/DSi mode on 3DS - the DSi has no real background operating system, so it's up to each title using nand to be patched for accessing the SD instead (maybe without encryption or even larger partitions, eh?)

 

[I pwned U!]

What would be nice (and probably much more doable) is a DSiHax payload that just reloads the launcher with signature and region-free patches. (This is beyond my skill level, but I hope that it is possible and someone can pull it off.)

 

[Billy Acuña]

What would be nice (and probably much more doable) is a DSiHax payload that just reloads the launcher with signature and region-free patches. (This is beyond my skill level, but I hope that it is possible and someone can pull it off.)

Does actually need the DSi sign parches?
From what I saw is that you don't even need legit tickets to have content, afaik your method uses fake tickets

 

[Billy Acuña]

Btw would be nice if we port the TWLoader to the DSi, a good thing is that we have a completly working and open sourced DSi4DS, just need some rework and we have TWLoader completly ported to the DSi [emoji14]

Enviado desde mi SM-J111M mediante Tapatalk

 

[metroid maniac]

Won't happen for the exact same reason emunand doesn't work in GBA/DS/DSi mode on 3DS - the DSi has no real background operating system, so it's up to each title using nand to be patched for accessing the SD instead (maybe without encryption or even larger partitions, eh?)

That's not entirely true.
If DSiWare works anything like retail DS games do, then ARM7 binaries are all extremely similar between games. In that case, writing a single patch or a small number of similar patches could implement something like emuNAND across all DSiWare titles.

Of course, that's not really going to happen, because the DSi hacking community lacks dedicated talent.

 

[Flashed]

That's not entirely true.
If DSiWare works anything like retail DS games do, then ARM7 binaries are all extremely similar between games. In that case, writing a single patch or a small number of similar patches could implement something like emuNAND across all DSiWare titles.

Of course, that's not really going to happen, because the DSi hacking community lacks dedicated talent.

That's it. We have no devs so we are very limited

Things that would be interesting are mentioned ones: region free

 

[I pwned U!]

Does actually need the DSi sign patches?
From what I saw is that you don't even need legit tickets to have content, afaik your method uses fake tickets

My current method only works for installing properly signed titles that were available on the DSi Shop with properly signed DSi-formatted TMDs. The following items would be made possible with signature patches:

• running eShop exclusive DSiWare titles, such as Nintendo Fan Network
• loading DSiWare ROM hacks
• running retail builds of SDK apps
• installing and running homebrew apps that show up on the launcher

 

[Flashed]

My current method only works for installing properly signed titles that were available on the DSi Shop with properly signed DSi-formatted TMDs. The following items would be made possible with signature patches:

• running eShop exclusive DSiWare titles, such as Nintendo Fan Network
• loading DSiWare ROM hacks
• running retail builds of SDK apps
• installing and running homebrew apps that show up on the launcher

Top thing would be an entry point so hardmod wouldn't be necessary

 

[Billy Acuña]

Top thing would be an entry point so hardmod wouldn't be necessary

I think we first need a "CFW" thing to debug stuff and find a primary entrypoint on the last FW. You know, if we don't have any entrypoint on lastest FW is because the lack of tools and in consecuence lack of devs/hackers.

 

[Flame]

i have all the exploitable games, BUT would i be able to downgrade to lower firmware and inject a hax and then upgrade again now that the eshop closed for DSi?

before i didnt have the time but soon i should so is it possible?

 

[I pwned U!]

i have all the exploitable games, BUT would i be able to downgrade to lower firmware and inject a hax and then upgrade again now that the eshop closed for DSi?

There is no need to downgrade your firmware. After hardmodding, just copy the save payloads to the appropriate directory in your decrypted NAND backup. The only downgrading that I recommend is replacing your existing copy of Sudoku with the exploitable one, and downgrading the whitelist to enable more flashcards

 

[Apache Thunder]

Just thought I'd put this out there:



Nintendo forgot to implement RSA checking of the DS Cart White list SRL on DSi with firmware 1.4 (this is the only fw version affected). So you can add new entries to it to unblock flashcarts. This has long been documented by gbatek but seems to have gone unnoticed until now.

Note that the white list is separated into 3 parts with the third section acting more as a blacklist on game codes that are spoofed by some flashcarts. You can easily unblock those carts (there's really only 4 game codes here in the 1.4 version of the white list file though) blocked this way by simply setting the number of titles field in the header to 0 for that section and removing all the entries. The hash type used is SHA1-HMAC and the HMAC keys can be found in Launcher. Gbatek pretty much tells you where to find them. In most cases for the first section you only need to hash the header (0x160h in size) + arm9 (with secure area encrypted) + arm7 binaries as a single file. Then for section two (this section uses a separate HMAC key FYI) The icon/banner is hashed.

Refer to this on the full file spec of the cart white list SRL:

http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwarenintendodscartwhitelistfile

Anyways I show my code breaker working on my recently acquired DSi. Probably the first time that cart has ever worked on it. It has a custom game code too by the way so I was able to white list it without killing an existing game code.

Remember this only applies to v1.4 fw so you will have to dg your DSi to that version to do this. (though you may get away with only downgrading launcher and DSi System Settings)

 

[Shicky256]

Remember this only applies to v1.4 fw so you will have to dg your DSi to that version to do this. (though you may get away with only downgrading launcher and DSi System Settings)

Couple questions:
1. What version of System Menu on NUS Downloader is the version from 1.4?
2. On early firmware versions (1.3 and below) the Acekard 2i was able to use a custom title instead of mimicking a licensed DS title (I'm pretty sure the title ID was ACEK). Because I don't see that title ID in the "blacklist" portion of the SRL, was the black list a new thing in 1.4? If so, is it possible to downgrade to a DSi version that doesn't have the whitelist? I'm already on launcher v512, which according to NUS Downloader is the first US version, and it doesn't work there.
Also, just making sure, is v256 the correct version of the white list SRL to be editing?

 

[Apache Thunder]

v256 is the oldest available and I think newer versions really just updated the blacklist section though I haven't actually checked what the differences are.

1.3 Launcher isn't available on NUS anymore. I believe the oldest one you can download is the 1.4 one. (for USA region anyways. Did not check the others)

The DS Cart Whitelist existed in 1.3 so curious as to how the Acekard got away with using a custom icon there. Note that the third section used for verifying specific regions on a cart which was used to blacklist spoofed game roms wasn't a thing in 1.3. So yeah that didn't start till 1.4.

I don't think it would be safe to downgrade to 1.3. I think bootloader might have seen in update in 1.4. Not sure. Bootloader is a early stage boot manager that is responsible for booting Launcher. It's sorta like the FIRM partitions on a 3DS. It's what bootrom loads at early boot and it's from here that Launcher actually starts up from. So pretty much similar to the 3DS's NATIVE_FIRM partition in that regard. (and yes it's RSA signed too, so you can't modify it)

There's a partition on NAND dedicated to it. It hadn't seen any changes since 1.4 that much I do know. But not sure about early firmwares. So maybe run that nand image through No$GBA first before you try and use it on hardware. (unless you have a nand mod of coarse)

 

[Shicky256]

So maybe run that nand image through No$GBA first before you try and use it on hardware. (unless you have a nand mod of coarse)

How'd you manage to get No$GBA working? The help file mentions having to create a custom header for your NAND image but it says there's an "invalid index" or something (it's been a while, forget the actual error) when I try to go to the section that mentions the header format.

 

[Apache Thunder]

You have to make a special "footer" for your NAND. So it's not really a header (as those usually go to the top of the file while a footer goes to the end).

Here's an example image showing what it looks like:

It's added to the end of hte file and is about 0x40 in length. The first number is the NAND CID (the long string). Then the CPU ID. BUT the CPU ID must be in little endian, so the hex pairs are in reverse to what you normally use when using TWLTool. These are console unique. (the bumbers shown in the image are fake. Replace them with the real numbers you got from your console)

Also make sure you have these files present in your No$GBA folder:

bios7i.bin
bios9i.bin
BIOSDSI7.ROM
BIOSDSI9.ROM
BIOSNDS7.ROM
BIOSNDS9.ROM


Once you have the emulator configured to start from GBA BIOS instead of cartridge it will boot the DSi System Menu. (you still have to give it a rom to use however. Just note that most homebrew won't launch from system menu this way, so use start from cartridge option when not using DSi System menu)

 

[Razor83]

@Apache Thunder
I was looking at the launcher and whitelist versions on DSibrew:-
http://dsibrew.org/wiki/Title_list#System
http://dsibrew.org/wiki/System_Menu
and the few available DSi update reports from here:-
https://yls8.mtheall.com/ninupdates/titlelist.php?sys=twl
and as far as I can tell the whitelist was only introduced with system update 1.4?
I made this chart which I think is correct:-

If the above is correct couldn't we downgrade to launcher v512 to avoid the whitelist entirely? Or perhaps there was a v0 of the whitelist that didnt block flashcarts, and came with 1.2 and 1.3 systems so was never available on the update servers?

Also, is there any way we could extract launcher v256 (and whitelist v0 if it exists) from the NAND dump of a launch model DSi thats has never been updated?

 

[Apache Thunder]

Your chart seems a bit off. I have 1.4 FW and I checked v512 Launcher downloaded from NUS. It is identical to the one I already have. So v512 is the 1.4 version of Launcher. If I could get my hands on a 1.3 version of Launcher I could test to see how it behaves. I was not aware 1.3 did not have a white list implemented?

Maybe yoru chart is for the JPN/Europe version of Launcher. But USA consoles had 1.4 use v512 Launcher.