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

[BastarB]

If you understand kernel programming then you could port the code to newer hardware models, but as it stands, the code is only written for the V1 Pi.

There was an attempt to build code for the arduino at one point, but it was never finished. If you understand arduino programming, then that's another possibility I guess. I personally don't have the time to update the program myself, though I have the skills. If you decide to do it, I'll be happy to help you along when I do have time.

Well, I only know basic python and java programming, so I think Im out of luck. Think I just hit a dead end then, If Im not able to track down a cheap Raspberry Pi I think I'll skip the whole thing. Maybe If I can track down a japanese version of biggest loser, but not sure if the exploit works with that version!?

 

[Gadorach]

Well, I only know basic python and java programming, so I think Im out of luck. Think I just hit a dead end then, If Im not able to track down a cheap Raspberry Pi I think I'll skip the whole thing. Maybe If I can track down a japanese version of biggest loser, but not sure if the exploit works with that version!?

The exploit works, but no one has crafted a save gave for it.

 

[BastarB]

The exploit works, but no one has crafted a save gave for it.

Ok, thanks Gadorach for that info!

Im really new to this! I wonder if its possible to dump a Nand from from one particular Dsi console and then flash it on another Dsi console, or is there any kind of protection on the consoles (encryption, console-id matching etc etc.) preventing this?

 

[nocash123]

The HWINFO_S.dat file http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwaremiscfiles works only with the Port[4004D00h..4004D07h] console id, and that file contains the console region byte... so, sorry, but there's no way that you could install english system menu on a japanese console.

 

[BastarB]

The HWINFO_S.dat file http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwaremiscfiles works only with the Port[4004D00h..4004D07h] console id, and that file contains the console region byte... so, sorry, but there's no way that you could install english system menu on a japanese console.

Ok, but that file is also part of the NAND right, and are you saying then that the HWINFO_S.DAT are different in a Jap console and a U and E console and only works with a specific console id (console id differs by hardware between Jap, usa and Eur consoles?)? And that the file from a E or U console wont work in a japanese console and will result it to not boot at all? What happens if you:

1. decrypt the NANDs of a Jap console and the NAND of a Eur console using TWLTool

2. Copy the HWINFO_S.dat from the Jap NAND over to the Eur NAND

3. Encrypt the Eur (English system menu) NAND with the new Jap HWINFO_S.DAT using TWLTool

4. Flash the encrypted NAND to the Japanese Console

5. Result? Bricked console? Success? Partial success?

6. Other solutions?

 

[Gadorach]

Ok, but that file is also part of the NAND right, and are you saying then that the HWINFO_S.DAT are different in a Jap console and a U and E console and only works with a specific console id (console id differs by hardware between Jap, usa and Eur consoles?)? And that the file from a E or U console wont work in a japanese console and will result it to not boot at all? What happens if you:

1. decrypt the NANDs of a Jap console and the NAND of a Eur console using TWLTool

2. Copy the HWINFO_S.dat from the Jap NAND over to the Eur NAND

3. Encrypt the Eur (English system menu) NAND with the new Jap HWINFO_S.DAT using TWLTool

4. Flash the encrypted NAND to the Japanese Console

5. Result? Bricked console? Success? Partial success?

6. Other solutions?

He's saying that the HWINFO_S.dat file determines your console's region. As that file is signed to your console, and we don't have a hack that runs early enough in the boot chain to disable signature checks, you can't run a HWINFO_s.dat that is not signed to your console. We would need a whole new bootrom hack to do it, it seems. Sorry, I guess region changing is out of the question for now.

 

[BastarB]

He's saying that the HWINFO_S.dat file determines your console's region. As that file is signed to your console, and we don't have a hack that runs early enough in the boot chain to disable signature checks, you can't run a HWINFO_s.dat that is not signed to your console. We would need a whole new bootrom hack to do it, it seems. Sorry, I guess region changing is out of the question for now.

Yes, that was exact what I suspected, my question is if it's possible to have an english system menu using the japanese HWINFO_S.DAT (From the japanese NAND) inside the European NAND running within my japanese console, so that the console still would be of japanese region with the correct HWINFO_S.dat BUT the language would be in english? Maybe that's some signature checks for that also that makes it impossible, I like to speculate thou

EDIT: So in other words, as long as you using the HWINFO_S.DAT thats signed for your console, woulnt you be able to somehow use it alongside an english system menu?

 

[Gadorach]

Yes, that was exact what I suspected, my question is if it's possible to have an english system menu using the japanese HWINFO_S.DAT (From the japanese NAND) inside the European NAND running within my japanese console, so that the console still would be of japanese region with the correct HWINFO_S.dat BUT the language would be in english? Maybe that's some signature checks for that also that makes it impossible, I like to speculate thou

EDIT: So in other words, as long as you using the HWINFO_S.DAT thats signed for your console, woulnt you be able to somehow use it alongside an english system menu?

I suspect that the HWINFO_S.dat will instruct the system to look for a system menu signed to the set region. If it doesn't find one, it likely crashes. Changing the NAND contents probably won't change anything region related.

 

[Deleted member 394844]

3DS Uses a USB reader to extract NAND... Why can't this use it?

 

[Apache Thunder]

The HWINFO_S.dat file http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwaremiscfiles works only with the Port[4004D00h..4004D07h] console id, and that file contains the console region byte... so, sorry, but there's no way that you could install english system menu on a japanese console.

Hmm I'm curious if this is the reason why DSi System menu won't boot on my n3DS. I got DSi System Update to complete a system update. (had to manually move some files it downloaded as it would error out trying to replace things already installed from CTR mode).

It appears the reported version string in DSi System Settings is 1.4.xALL which means maybe retail launcher mistakes my DSi environment as region free/dev. So I guess I'm gonna need files from a dev DSi.... Gonna have a hell of time finding a nand dump from one.

Currently retail launcher (DSi System Menu) white screens and doesn't even write anything to the log. If I change the TID (I do make sure to correct modcrypt doing this) then it sorta boots. ONly it boots to DSi's version of the error has occured screen. It does write to the log that time. Saying Init failed or something. Don't have that on hand unfortunately.

Maybe I just need to have the RSA sigs patched out of the retail launcher SRL because I may have to change the region of the dat file to ALL/dev. How did dev DSi consoles handle region anyway?

 

[nocash123]

The most complex thing in the DSi System Menu (launcher) is the Wifi initialization, it took me months to get the no$gba emulation to pass through that initialization step (without even trying to emulate actual wifi transmissions). On the DSi, the System Menu can upload two different wifi firmware versions (for the two DSi wifi daughterboard revisions). On 3DS you would need to upload a different wifi firmware (for the 3DS wifi daughterboard). I don't know how far it would be possible to get the original DSi System Menu to upload that 3DS wifi firmware which did never exist in real DSi retail units. Oh, and the region, yes, you would somehow need to patch-out the HWINFO_S.dat region check, as far as I know that file doesn't exist at all on 3DS.

 

[Apache Thunder]

Ahh I see, so the wifi init thing would have to be patched out. As for HWINFO_S.dat...Well I have one from a USA region DSi. My n3DS is also USA. Maybe DSi System Settings is only reporting a "ALL" region code due to dev launcher. Then again that means booting retail launcher from dev launcher also means retail launcher might expect a "all" region HWINFO_S.dat then....

 

[nocash123]

HWINFO_S.dat cannot be replaced from different consoles, see gbatek for details. Uhmm, what is dev launcher... did I miss something important? Can it be installed on retail DSi's? And does it have any advantages, like getting rid of the health & safety stuff, or allowing to boot homebrew code more directly/easily?

 

[Apache Thunder]

Dev launcher is a stripped down version of Retail Launcher (and as you expect it does not have the health & safety screen). It lives in the .code section of twlBg which is a CXI that runs on Arm11 during boot of TWL_FIRM. It's section0 of TWL_FIRM's firm section. TWL_FIRM also has it's own version of boot2/bootloader that loads dev launcher into FCRAM from twlBg. The main difference in how it operates from retail DSi, is boot2 on TWL_FIRM does not load launcher from TWLN partition like it would have if it was retail DSi boot2.

Thanks to CFW on 3DS, you can replace dev launcher/modify it or do other things like install homebrew SRLs direct to home menu that has arm7 scfg unlocked by setting bit31 in 0x1b8 of their DSi extended header. That works because TuxSH/Steveice10 found the RSA sig checks in TWL_FIRM and patched them out in current CFWs like Luma. (TWL_FIRM's arm9 checked the RSA sigs of SRLs and not dev launcher. Dev launcher doesn't seem to care. More on that further below)

Dev Launcher uses dev modcrypt and likely dev sigs as well (though twlBg/boot2 does not sig check it. I guess because the chain of trust has arm9 section of TWL_FIRM verify sig of twlBg, so it doesn't bother also checking dev launcher) The main limitation from trying to replace dev launcher with retail launcher is that TWL_FIRM/twlBg's memory layout in FCRAM only allocates 1MB to it. This is enough room for dev launcher, but retail launcher is quite a bit larger. Retail boot2 might fit though but I have no idea how to deal with the encryption of boot2 and since it's a little larger then what TWL_FIRM has, I can't just insert it into twlBG without breaking some code that occurs after it. TWLTool can decrypt boot2 of TWL_FIRM but does not appear able to rebuild/reencrypt at the moment so I can't even fix boot2 from DSi to work in twlBg in the first place.

Dev launcher will likely not work on a DSi. You may get it to run on a dev DSi, But certainly not on a retail unit due to dev mod crypt.


I have the decrypted SRL if you want to look at it. The interesting thing is, dev launcher does not appear to sign check SRLs that it loads. It's actually arm9 section of TWL_FIRM that does that....If you could ever get it to run on a dev DSi, it would not even bother checking the dev sigs of the installed SRLs. I'm not even sure it will boot on a DSi though. I think with the way things are setup. TWL_FIRM sets up the environment for dev launcher. On a DSi, this was all done by retail launcher for the most part (for things boot2 didn't do first)

So like you mentioned, the wifi init wouldn't even occur on dev launcher because TWL_FIRM/boot2/bootrom of TWL_FIRM would have set that up before hand. I could be wrong though. No telling what TWL_FIRM sets up and what dev launcher does. I always assumed dev launcher was just a stripped down no menu version of retail launcehr that only really just auto boots an SRL. It auto boots a TID passed to it by TWL_FIRM's boot2.

EDIT: Now that I think about it, you might be able to get something that resembles DSi bootrom from TWL_FIRM. It's either stored in TWL_FIRM or accesible during boot. Becaue the 3DS has been throughly hacked to death, you can certainly modify TWL_FIRM to your hearts content to try and keep things unlocked when your SRL fires up. Normmatt tried that not too long ago. Never heard if he was successful though. I think he'd would have had better luck running his dumper as a direct replacement of dev launcher instead of trying to patch things out of dev launcher.

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

Sorry for all the edits. I'm always missing something and have to tack it on or fix typos.

 

[FrozenDragon150]

*attempts to read all the technical stuff*

*brain explodes*

So, uh, what is being done in terms of DSi stuff... Is there enough interest on the console left for hacks?

 

[ThisIsDaAccount]

Will DSiwarehax die out after the DSi shop servers officially close?

 

[Gadorach]

Will DSiwarehax die out after the DSi shop servers officially close?

Currently, Yes.

 

[metroid maniac]

Currently, Yes.

Can you not inject DSiWare and a hacked save with a NAND mod and TWLtool?

 

[Gadorach]

Can you not inject DSiWare and a hacked save with a NAND mod and TWLtool?

You wouldn't have the required license files to run the DSiWare on your system.

 

[metroid maniac]

You wouldn't have the required license files to run the DSiWare on your system.

That would make sense.

But that just makes me wonder why DSi injections work on the 3DS.