DSi unlaunch (bootcode exploit)

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

ChampionLeake wrote:Hello, I just recently updated to Unlaunch 1.5 for hiyaCFW (on a native 1.4U console) and I only came upon 1 problem. SysNAND's touch functionality works on the system menu but once I use emuNAND(hiyaCFW), touch functionality stops working on the system menu.
Good that you found that bug so quickly, thanks! I've uploaded v1.5 just a few hours ago (and didn't even announce it anywhere yet). Ah, yes, I'm gettiing the same problem when booting DSi System Flaw cartridge. Hmmmm, the problem is related to these new/additional TSC writes:

Code: Select all

switch to TSC bank 00h
TSC[0:25h]=00h  ;DAC Flag Register (00h) (R)
TSC[0:26h]=00h  ;DAC Flag Register (00h) (R)
TSC[0:27h]=00h  ;Overflow Flags (00h) (R)
TSC[0:36h]=03h  ;SDIN (IN Pin) Control (02h or 03h)
TSC[0:75h]=2Ch  ;VOL/MICDET-Pin Gain (xxh) (R)
switch to TSC bank 01h
TSC[1:20h]=D4h  ;..already? Class-D Speaker Amplifier
TSC[1:2Ah]=14h  ;..already? SPL Driver (Left Speaker)
TSC[1:2Bh]=14h  ;..already? SPL Driver (Right Speaker)
TSC[1:32h]=61h  ;Input CM Settings
switch to TSC bank 03h
TSC[3:02h]=98h  ;SAR ADC Control 1 (00h)
TSC[3:03h]=87h  ;SAR ADC Control 2 (00h)
TSC[3:04h]=22h  ;Precharge and Sense (00h)
TSC[3:05h]=04h  ;Panel Voltage Stabilization (00h)
TSC[3:0Eh]=ADh  ;Reserved / Undocumented (read by DSi for Pen Down Test) (0Fh)
TSC[3:0Fh]=A0h  ;Scan Mode Timer (40h)
TSC[3:10h]=88h  ;Scan Mode Timer Clock (81h)
switch to TSC bank 00h (as default state)
That new writes were supposed to have the TSC registers in exact same state as how the launcher is initializing them, or at least in the state how launcher ends up when being emulated in no$gba, which apparently isn't working perfectly correct on that stuff.
Okay, I've uploaded another update, unlaunch v1.6, that's having those TSC writes removed again. Half of them were nonsense anyways as they were writing to read-only bits; and at least one of the write-able bits must have caused the problem.

The reason for having that stuff (and half a dozen other changes) in v1.5 was trying to get DSi Sound working, the changes didn't really help on that issue, but I had hoped that they would improve some details in other situations, without screwing up things.

DSi Sound itself didn't work because that specific title is actually requiring Main RAM to be zerofilled. So I am now doing that zerofilling for best compatibility, although it's slowing down the boot process and not needed for most other titles. The good thing is that I found out that zerofilling can be made a bit faster when using the new NDMA fill-mode:

Code: Select all

 ;benchmarks for filling 0ff8000h bytes (15.9MB) Main RAM with all program code residing in VRAM
 ;263ms via NDMA3 on ARM7 when SRC=FILLWORD in NDMA.FILLDATA  ;<-- best
 ;265ms via NDMA3 on ARM9 when SRC=FILLWORD in NDMA.FILLDATA
 ;344ms via STMIA in VRAM code on ARM7 by software zerofill
 ;369ms via STMIA in VRAM code on ARM9 by software zerofill (with parts of main ram having write-cache)
 ;393ms via NDMA3 on ARM7 when SRC=FILLWORD in ARM7.WRAM
 ;393ms via DMA3 on ARM7 by hardware zerofill
 ;393ms via DMA3 on ARM9 by hardware zerofill
Last month my best result was about 400ms, which is now down to 263ms for DSi titles (and 66ms for NDS titles with only 4MB memory used). And, to speed up homebrew booting, I've added an 16byte ID string in the cart header that allows to disable the zerofilling for faster booting:

Code: Select all

  carthdr[0B0h]="DoNotZeroFillMem"
Well, customizing the carthdr isn't optimal, but that was the best solution I could think of. Now that I've that feature... I will probably change it to also affect ITCM/WRAM zerofilling in future - that is, destroying that memory (including the BIOS AES keys) if the ID string isn't present. If your bootcode.dsi file does require those AES keys: Best add the above ID string right now to avoid future issues.
edo9300 wrote:Updated to 1.5, and finally it no longer freezes
I've no idea what has fixed that issue, but if it's working stable now then it's just fine. Oh, I just noticed that I've disabled a few more changes (apart from the TSC writes) in v1.6. So maybe I've thrown you back to freezing state with that newly removed changes. Please let me know if v1.6 is still working for you. If it isn't then that does at least help to track down what was causing the problem : )

Alright, and here are the URLs and release notes for the updates...
http://problemkaputt.de/unlaunch.htm - unlaunch
http://problemkaputt.de/gba.htm - no$gba
http://problemkaputt.de/wifiboot.zip - wifiboot

Code: Select all

v1.6 30 Sep 2018
 - re-fixed dsi touchscreen input

v1.5 30 Sep 2018
 - co-releases: no$gba v2.9b and wifiboot v2.3
 - zerofill main ram support added (needed for a few titles like DSi Sound)
 - zerofill done via fast NDMA-fill (16MbyteDSiMode=263ms, 4MbyteNdsMode=66ms)
 - zerofill skipped if carthdr[0B0h]="DoNotZeroFillMem" (fastboot for homebrew)
 - memory moved exploit entry code to gap between 37F0E3Ch and 37F22C8h
 - memory shares cluster_buf as rom_cart_xxx buffers (for sd/mmc vs rom carts)
 - moved wifi firmware load prior to cartload (so wifi can trash main ram)
 - added warnings on unsupported cluster sizes (too small or too large)
 - allows FFFFh as 'valid' camera id (for consoles with broken camera/cables)
 - speedup: uses DMA for modcrypt (some dsiwares have HUGE modcrypt regions)
 - added warning on unknown chinese firmware & unknown old firmwares from 2008
 - added uninstall function (dealloc clusters, change filesize, unprotect)
 - added warning about uninstall function (prompt X+Y buttons to confirm)
 - initializes microphone MIC_CNT, teak DSP_xxx, stop/clear NDMA before title
 - vram_code (moved unlaunch to vram; faster & leaves main ram to loaded title)
 - gif: much faster gif decoder (r0-r12 instead ram, faster code table)
 - gif: simplified gif decoder (no interlace, without wrap at image width)
 - gif: special edition themed on broken arrow cold war nuclear accidents
 - added support for modcrypt with more than FFFFh blocks (eg. dsi sound)

Code: Select all

30 Sep 2018 - version 2.9b
- web: created no$project patreon page, https://www.patreon.com/martin_korth
- dsi/emu: allows 8bit vram writes on dsi (if enabled in SCFG_EXT9.bit13)
- dsi/help: added note on dsi debug blowfish key used when SCFG_OP nonzero
- carthdr/help: added carthdr[0B0h] "DoNotZeroFillMem"=unlaunch fastboot ID
- dma/help: added note on dma-fill via 40000Exh being slower than stmia/ndma
- dsi/help: added note on broken cameras being more common than unknown cameras
- dsi/tsc/iomap: shows tsc page 0,1,3 registers (page 3 is hidden in aes tab)
- dsi/tsc/emu: basic emulation for reading/writing tsc page 0,1,3 registers
- dsi/startdirect: initializes GPIO registers (sound,powerbutt,wifimode)
- a22i: throws error message on forward references within .pack blocks
- nds/cart: supports flashcarts with arm9 code below offset 4000h (ievolution)
- nds/bugfix: resurrected BG0CNT/BG1CNT.bit13 (unlike GBA) (thanks chocoreep)
- dsi/help: info about ST NAND02G AH0LZC5 emmc chips (thanks barawer+trade girl)
- dsi/emmc: emulates different eMMC CSD's (matched to four known eMMC CID's)

Code: Select all

wifiboot v2.3 - 30 Sep 2018
 - added carthdr[B0h]="DoNotZeroFillMem" for unlaunch/fastboot without zerofill
 - forces disabled cache to be MADE EMPTY before starting loaded title
 - zerofills vram/oam/palette before starting other titles (takes about 6ms)
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

PS. Now that I've ended up releasing two unlaunch updates on the same day... I could as well threw in a third update:

Code: Select all

v1.7 30 Sep 2018
 - re-enabled some other tweaks (except the one causing touchscreen problems)
 - webpage: added notes on the new background GIFs
Please let me know if you find something working in v1.6, but not working in v1.7 (or vice-versa).

The faulty TSC init is removed in both versions. v1.6 did also remove some more new features. And v1.7 does have that new features (hopefully properly initializing RCNT, AES_CNT, CAM_MCNT, SCFG_CLK9, SNDEXCNT, and default P15,0,C1,C0,0 setting for DSi).
Kodtiz3D
Posts: 2
Joined: Sun Sep 30, 2018 8:52 pm

Re: DSi unlaunch (bootcode exploit)

Post by Kodtiz3D »

I had the initial pubic version of unlaunch installed by twlnf because of the mismatch in FAT copies error and previous fixes were not doable for me at the time, then twlnf installed 0.6, bricked it and haven't fully hardmodded my DSi yet so I am using NO$GBA in it's place to test this.
I try using the install/uninstall feature of 1.7 and I get an unknown emmc CID/CSD error.
In text it is:

Code: Select all

BD XX XX XX XX 32 57 37
31 36 35 4D 00 01 15 00
40 40 96 E9 7F DB F6 DF
01 59 0F 2A 01 26 90 00
80 80 FF 80 00 04 00 00
00 00 00 00 00 00 00 00
00 09 00 00 00 01 D0 40
00 00 01 00
I also attached a screencap of the installer if needed.
Keep doing what you're doing, wish I could donate by patreon or something but I can't at the moment.
Attachments
unknown emmc.PNG
gabo12
Posts: 3
Joined: Sat Aug 18, 2018 7:47 am

Re: DSi unlaunch (bootcode exploit)

Post by gabo12 »

updated from 1.4 to 1.7 (haven't tried 1.5 or 1.6), now it never freezes anymore! thanks so much for your hard work!
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Kodtiz3D wrote:I am using NO$GBA in it's place to test this. I try using the install/uninstall feature of 1.7 and I get an unknown emmc CID/CSD error.
Looks like a bug in no$gba, or, wait, are you using an old no$gba version? The latest version is no$gba v2.9b (released just yesterday, alongsides with the unlaunch updates).
The screenshot shows your CID in first 16 bytes (that's the CID that you have in your console, and that you've also stored in the eMMC image in the "no$gba footer"), and the CSD is shown in next 16 bytes (40 40 96 ..), and unlaunch is complaining because the values don't match up with each other (the CID is for an "Newer Samsung" chip, but the CSD is that used in "Older Samsung" chips).
That problem will occur in older no$gba versions, but no$gba v2.9b should compare your CID against all known CIDs (for OldSamsung, NewSamsung, OldST, and NewST chips), and then automatically use the correct/matching CSD for your CID (at least that was supposed to happen, maybe I got something wrong there).
Kodtiz3D wrote:Keep doing what you're doing, wish I could donate by patreon or something but I can't at the moment.
Thanks, don't worry if you can't donate! Yesterday, nine people have joined the patreon, that's been a really nice surprise and makes my financial situation a good bit less hopeless - thanks everybody!
gabo12 wrote:updated from 1.4 to 1.7 (haven't tried 1.5 or 1.6), now it never freezes anymore! thanks so much for your hard work!
Good to know. If v1.7 does keep working for edo9300, too, then the freezes are hopefully gone now.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

nocash wrote: Good to know. If v1.7 does keep working for edo9300, too, then the freezes are hopefully gone now.
Tested and have no issues on both 1.6 and 1.7, :)
bybb
Posts: 1
Joined: Mon Oct 01, 2018 12:50 pm

Re: DSi unlaunch (bootcode exploit)

Post by bybb »

Hi nocash, I have a bit of a problem.
I'm on unlaunch 0.6 (installed via twlnf) and have mismatched FAT copies meaning the unlaunch installer doesn't work.
I'm fairly certain that unlaunch 0.6 is one of the versions that bricks due to non-read-only tmd and SRL, this is made worse by the fact I didn't use the official installer, but a twlnf script that manually copied a modified tmd to the NAND.
Is there anything I can do to either safely update unlaunch, or fix my mismatched FAT copies error?
Thanks!
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Unlaunch v0.6 could brick the launcher, but loading bootcode.dsi should still work, so it's only semi-bricked and could be still repaired without hardmod (but better avoid that as it would still some extra work).
No, stop! If you've installed it via twlnf then I've no idea if twlnf had write-protected the .tmd and/or .app files, if it didn't then it could give you a full-brick.

For repairing FAT copies: I would dump + decrypt + mount the eMMC, and then run scandisk on it. Then unmount, re-encrypt, and write it back to the console. That's much the same as downgrading via TWLtool, except that you are running scandisk instead of downgrading.

I don't know if scandisk is capable of fixing the problem (ie. if it's using the correct FAT, or if it's using the bad FAT copy, and it might create dozens of (possibly useless) FILEnnnn.CHK files), so better keep a backup before passing your eMMC image through scandisk.
Instead of scandisk, you could also load the decrypted image into a hex editor, and manually copy the 1st FAT to 2nd FAT (1st FAT should be at offset 0010F000h, the FAT size is 6800h bytes, followed by 2nd FAT at offset 00115800h with same size), that should work too, as long as you don't screw it up.
After re-encrypting the repaired image: Best test it in no$gba and check if it can boot into launcher, and start DSiware titles from there.
Before writing the image to the console: Some people have that, but some people say that current tools for doing that aren't perfectly reliable (if it goes wrong then you need a hardmod).
edo9300 wrote:Tested and have no issues on both 1.6 and 1.7, :)
Fine. Thanks for testing!
wzhy90
Posts: 3
Joined: Sun Sep 02, 2018 6:44 am

Re: DSi unlaunch (bootcode exploit)

Post by wzhy90 »

I have try a big dsiware on unlaunch 1.7 but still has no sound. it's nintendogs dsiware from china iQue which file is 39MB. I rename it to bootthis.dsi and press X when poweron. but it's still no sound.
Robz8
Posts: 13
Joined: Sun Aug 05, 2018 12:52 pm

Re: DSi unlaunch (bootcode exploit)

Post by Robz8 »

Hello!
I have a feature request.

How about having Unlaunch doing something, depending on a flag set in RAM?
For example, if the word "THIS" is written to 0x02000330 by an app (ex. TWiLight Menu++), and then reboots the console, Unlaunch will boot "bootthis.dsi" without the need to hold X.
Would make transitioning into DSiWare in .nds format from TWiLight Menu++ (aka DSiMenu++) much better.
How it works right now, is after the user launches the DSiWare (by renaming to "sd:/bootthis.dsi"), TWiLight Menu++ will tell the user to hold X to boot the DSiWare, and as a result, the console reboots, and into the DSiWare, by X being held.

Also, someone else requested to have Unlaunch start the console NAND by a set flag.
For that, I think having "SKIP" written to 0x02000330, will skip booting any "boot????.dsi" file(s).

Also, would it be possible to have Unlaunch start with white screens, instead of black screens?
Kodtiz3D
Posts: 2
Joined: Sun Sep 30, 2018 8:52 pm

Re: DSi unlaunch (bootcode exploit)

Post by Kodtiz3D »

Someone from the support Discord server used the uninstaller from the 1.7 installer, and it worked just fine for them. They had a regular sized DSi from launch, I might be able to ask them for more technical info about their DSi if needed.
User avatar
Apache Thunder
Posts: 24
Joined: Tue Jul 24, 2018 6:28 pm

Re: DSi unlaunch (bootcode exploit)

Post by Apache Thunder »

Finally got around to testing 1.7. Seems to work fine for me. Cart loader still doesn't boot my DS-Xtreme. Had to sell my iEvo, so no longer have that to test so not sure on that one. (my guess is probably still no since you'd need to have the cart in hand to test it. Likely a hardware issue with how the cart responds to commands). Also still can't launch Launcher as bootcode.dsi (even tested it by holding Y to disable Wifi init to let Launcher do this instead, which it seems to get far enough to do that, but still hangs on white screen).

Only reason I can see it still not working is perhaps the different location Launcher expects nand info to be in ram? Would be nice to be able to load Launcher from SD without having to hack together a pre-patched Stage2 built into an SRL. :P
cosarara
Posts: 1
Joined: Fri Oct 26, 2018 12:16 pm

Re: DSi unlaunch (bootcode exploit)

Post by cosarara »

Hello there,
I installed unlaunch 1.7 using flipnote, following the guide on https://dsi.cfw.guide/installing-unlaunch and a 4GB SD card. This is an European DSi XL.
With unlaunch installed I can't get to the system menu ("an error has occurred" screen) - it doesn't matter if I hold A or not, or if the SD card is in the DSi or not.
I've tested in no$gba using my nand backup that the same thing happens - the nand backup works, and when I install unlaunch I stop being able to use the system menu. If I set up a bootcode.dsi with the unlaunch installer, I can uninstall it, and then it goes back to normal.
On no$gba I've also tried to use 0.8 and 1.4, with the same results.
The system is on version 1.4.2E.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

I am working on making my filesystem functions a bit more flexible. The old functions did manually load folder-by-folder, that worked okay for loading a few relevant files, but it wasn't suitable for loading other files at random locations. Anyways, my new code can now decipher strings like "device:/directory/subdirectory/filename.ext" and then load the specified folders & file. And it's now supporting long filenames (and also keeps supporting short names alternately).
Robz8 wrote:How about having Unlaunch doing something, depending on a flag set in RAM?
For example, if the word "THIS" is written to 0x02000330 by an app (ex. TWiLight Menu++), and then reboots the console, Unlaunch will boot "bootthis.dsi" without the need to hold X.
Yes, sorts of. Or a bit more flexible: Storing an ID and CRC and the full filename "sdmc:/bootthis.dsi" (or any other "device:/path/name" you might want to use.
I was planning to store that at 2000300h..20003FFh (alternately to the similar "load-this-title-id" stuff stored there by nintendo). Hmmm, but FAT32 allows up about 260 16bit characters (=520 bytes), that are too many bytes to be stored at 2000300h.
Guess I'll store it at 2000800h..2000BFFh, that area should be free for such purposes, and that 1024 byte area would be more than enough for long(est) filenames plus some ID+CRC values.
Robz8 wrote:Also, someone else requested to have Unlaunch start the console NAND by a set flag. For that, I think having "SKIP" written to 0x02000330, will skip booting any "boot????.dsi" file(s).
Yes, I could probably add that, too. For loading Launcher. And maybe also for loading system settings? Or if the above works, then you could do it manually (though that would require knowing region and version of the launcher/settings files).
Robz8 wrote:Also, would it be possible to have Unlaunch start with white screens, instead of black screens?
Yes, optionally. I prefer black because wifiboot has black background, but I could store some "favorite bg color" option somewhere in future versions.

Apropos, 2000300h allows to load a specific title-id, right?
There's also something similar at 2000000h (see "BIOS RAM Usage" chapter in gbatek). I am not what that is used for (or if it's used - some titles seem to be testing the title-id in that bytes, but - as far as I can see - without actually doing anything even if the title-id is there). Maybe 2000000h can contain some sort of command line parameters, to be used by the title loaded via 2000300h?

If that's so, then we could maybe adopt that in homebrew, too. Or else store command line parameters elsewhere, like at 2000C00h, or the way how dslink is doing it. Or not at all. In most cases I don't see too much need for command line parameters. Maybe except for browsers or so, where it might be nice to tell the browser to load a specific webpage.
cosarara wrote:I installed unlaunch 1.7 using flipnote...With unlaunch installed I can't get to the system menu ("an error has occurred" screen)... I can uninstall it, and then it goes back to normal... On no$gba I've also tried to use 0.8 and 1.4, with the same results.... The system is on version 1.4.2E.
Hmmmm, never heard of that issue before. Maybe firmware 1.4.2E is doing some extra error checks not present in 1.4E and 1.4.5E.
wzhy90 wrote:I have try a big dsiware on unlaunch 1.7 but still has no sound. it's nintendogs dsiware from china iQue which file is 39MB. I rename it to bootthis.dsi and press X when poweron. but it's still no sound.
Might require the bootthis.pub file, too? Or it might require the chinese font file, or chinese language enabled - and somehow refuse to do sound output otherwise? Do you have the chinese firmware, too? As far as I know nobody in dsi-scene has ever seen that firmware.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

v1.4.2E should be the "00000004.app" file as found on nintendo's servers. Loading that file into no$gba (via no$gba filemenu, ie. as if it were a ROM-image) does somewhat work (although normally that's working only for real ROM-images, not for DSiware files).

Anyways, it's working okay if unlaunch isn't installed, but throws the error message if unlaunch is installed. Looking closer, the reason is that this launcher version is intentionally or accidentally checking the filesize for it's own tmd file (whilst other older/newer launcher versions are checking the tmd sizes for most or all other tmd files, but not for their own tmd file).
I'll replace the "if size=bad then error" check by "if size=bad then size=208h" so it'll see the default size instead of the size of the patched tmd file. That patch should be compatible with 1.4E, too. And I hope that it won't disturb any other versions.

Btw. did anybody ever dump the earlier firmware versions, and knows if they did even exist? Wikipedia claims that v1.0J didn't exist, and dsibrew says that v1.1J didn't exist, but suggests that there was a pre-installed version older than v1.0J. The available info is quite a mess, and probably inaccurate.

Oh, and unrelated: The v1.4.2E launcher does have the whitelist RSA key in it! So maybe the people claiming that the RSA key was missing ONLY in v1.4 haven't been that wrong at all, except maybe it's missing in v1.4.1, too. The other version do probably have it (unless nintendo was repeatedly adding/removing it).
Post Reply