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.
wzhy90
Posts: 3
Joined: Sun Sep 02, 2018 6:44 am

Re: DSi unlaunch (bootcode exploit)

Post by wzhy90 »

nocash wrote: 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.
yep, I have the bootthis.pub file. and the game works fine while I install to hiyaCFW as a title dsiware. so I don't think it's a chines firmware issue
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

unlaunch v1.8 released

After spending some weeks on NES stuff last month, I had fresh energy for working on unlaunch.dsi. First step was improving the filesystem (with automatically parsed "device:\path\name" strings), and opened doors to adding a filemenu and many more features.

For the filemenu, I was sceptical if it could work fast enough when crawling the whole directory tree. My first attempt took about one second, but then I figured that I could abort directory reading on the first unused entry (as opposed to used or deleted entries), and that made things about 32x faster (ie. one 200h-byte sector vs one 4000h-byte cluster), and the filemenu is now showing up almost instantly (unless you have thousands of files on SD card, of course).

Next version(s) are planned to support lowercase letters & maybe french accent marks and such, reading & displaying icon/title, and some option to change the sort order of the files in the filemenu. But I think the current version does already look quite neat, and includes several details like scrolling & keyrepeat, automatically sensing ROM and SD card eject/insert, different colors for files in different locations.

After adding the filemenu I had originally planned to switch back to loading bootcode.dsi by default... but then nobody would even see the nice new features - so I changed my mind last minute and kept the filemenu as default boot action - but threw in an options screen where one can configure the boot defaults, including redefining hotkeys A,B,X,Y. The filename "bootcode.dsi" is still used (as default for button Y), but one could change that and select any other filename without needing anything called "bootcode.dsi" anymore. Another final addition is including a copy of "wifiboot.nds" as overlay, so one could now do wifi uploads without having the file on the SD card, or even without any SD card inserted.

With the new features, unlaunch can do pretty much everything that the official launcher can do (except gimmicks like making photos & displaying time/date), and you could theoretically completely delete the official launcher .app file. I guess that's now making unlaunch the "First homebrew DSi firmware" ever : )

http://problemkaputt.de/unlaunch.htm

Code: Select all

unlaunch v1.8 06 Nov 2018
 - filesys: decodes lfn's, ascii-case-insensitive, with alternate short names
 - filesys: parses path+file strings (eg. sdmc:\dir\subdir\file.ext)
 - filesys: skips mount_drive when already having the same device mounted
 - directory crawler: scans all folders on eMMC and SD/MMC (xcept DCIM etc)
 - directory crawler: creates filelist with all .app/.nds/.dsi files
 - directory crawler: adds entries for internal functions cart:, wifi:, sett:
 - crawler: doesn't treat volume labels as files (even if named .app/nds/dsi)
 - quick crawl: aborts folder reading on 1st UNUSED entry (instead cluster end)
 - quick crawl: does NOT load carthdr (instead, done on the fly in filemenu)
 - quick crawl: skip data,0003000f,import,progress,shared12,sys,ticket,tmp,dcim
 - filemenu: displays all titles from crawler and allows to select/start them
 - filemenu: displays carthdr title (instead nintendo's 000000vv.app filenames)
 - filemenu: supports scrolling and keyrepeat, loads carthdr's during scrolling
 - filemenu: ROM cart eject/insert: auto-updates ROM cart title on the fly
 - filemenu: SD/MMC card eject/insert: auto-recreates the whole filelist
 - filemenu: displays full filename and pub/prv sizes on lower screen
 - filemenu: different colors for card:+wifi:+sett: vs nand: vs sdmc: files
 - filemenu: hinge close: auto-power-off
 - device list: adjusts savedata names either data\public.sav or filename.pub
 - device list: adjusts savedata names either data\private.sav or filename.prv
 - autoload: allows retails titles to start titles via 2000300h (via title id)
 - autoload: allows frontends to start titles via 2000800h (via path\filename)
 - creates title list at 2FFD800h (needed for enter_settings & reboot_title)
 - options: allows to configure default boot action and hotkeys A,B,X,Y
 - options: shows abbreviated name for each hotkey, and full name for current
 - hotkeys not treated as menu-input in filemenu/options (when still held down)
 - hotkeys checked early (and multiple times ORed up during boot)
 - removed skip wifi-init hotkey (button Y has now other/custum use)
 - redirect to "load error" handler when trying to start empty rom/sdmmc slot
 - early backdrop init (before decompression) (black, or color from 2000800h)
 - patches tmd-size-selfcheck in launcher v1.4.2E (if size=bad, force default)
 - patches launcher.carthdr[1B4h].bit3 (needed if loading launcher from sd/mmc)
 - patches for launcher applied as usually; when selecting launcher in filemenu
 - loads verdata tmd (2FFD7B0h region/filename needed for SysSettings and Shop)
 - moved ARM9 "gif_table" to what is "cluster_buf" on ARM7 side
 - bugfixed hex32bit_r0_to_string_r1_upcase (was badly bugged on digit 9)
 - wifiboot: now included as overlay in unlaunch (allows wifi without SD card)
 - added NO ONE IS ILLEGAL tagging, and removed the nuke-crash-bombing pictures
 - resumed old GIFs, or actually it's only one of them, for memory reasons
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

PS. titles
The filemenu does show the ASCII titles from carthdr (because the official numeric filenames like 00000001.app aren't of too much use). One funny finding was that most homebrew titles having the field set to "HOMEBREW" or to contain some obscure opcode (that comes out as ".<garbage>". That's making it a bit difficult to select homebrew titles ; )
I'll change that in next update, either by using the name from icon/title structure (if it does exist), or otherwise use the filename (for homebrew files, but of course for the official 000000nn.app files). Until then... maybe some devrs will be motivated to use more meaningful titles in the carthdr.

PPS. filenames
There are two naming schemes for files (and savedata filenames). The offical scheme is using weired numeric folder+filenames, and uses separate "content" and "data" folders - that's used on eMMC (and I think hiyacfw is using that naming scheme on SD card, too).
The alternate naming scheme is using more meaningful filenames, like "My Game (EUR+AUS).dsi" combined with "My Game (EUR+AUS).pub" and/or ".prv" in the same folder - I would recommend using that for SD card.
Unlaunch is automatically storing the "device:\path\filename.ext" strings in the Device List, with the names converted to short name 8.3 format (with that short names one can have 3-5 directories nested without exceeding the device list's 64 byte limit) (NB the .pub/.prv files are auto-created yet, so you must provide them yourself).

Code: Select all

public & private savedata
If the file is in a folder named "CONTENT", then savedata is stored in a
separata "DATA" folder (this is as how Nintendo is doing it officially):
  "nand:/../CONTENT/title.tmd"
  "nand:/../CONTENT/00000002.app"
  "nand:/../DATA/public.sav"
  "nand:/../DATA/private.sav"
If the file is anywhere else (not in a CONTENT folder), then savedata should be
stored in the same folder & same name, with extension changed to .pub or .prv
(this homebrew convention allows to use more descriptive non-numeric filenames,
and doesn't require "title.tmd"):
  "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).dsi"
  "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).pub"
  "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).prv"
As seen above, names can exceed the 8.3 character shortfilename limit (and can
use 16bit unicode), however, using such long filenames can quickly exceed the
64 character limit of the DSi's Device List (or it's 8bit character space), as
a workaround, unlaunch is converting the above names to 8.3 character format
before storing them in the Device List:
  "sdmc:/../MYFOLD~1/FLIPN~12.DSI"
  "sdmc:/../MYFOLD~1/FLIPN~10.PUB"
  "sdmc:/../MYFOLD~1/FLIPNO~2.PRV"
With those short 8-character folder names, one can have up to five folders
nested (or only three folders with extension alike "MYFOLD~1.EXT", or more than
five folders if folder/filename are shorter than 8 characters).
As shown in the above examples, the longname ("Filpnote Studio (EUR.AUS)") is
same for all three files, but the ~NN suffix may vary for shortnames.
PPPS. autoload
The new unlaunch version supports the offical autoload by titleid (via 2000300h), and a new alternate autoload method by path\filename (via 2000800h).
Alongsides I've figured out a few more details on the structures at 2000000h and 2000300h, and noticed that retails refuse to autoload anything when not having the title list at 2FFD800h. Which, I knew that it did exist, but didn't have much of a clue what it was good for. So, now I know it: It's mostly for autoload (or for accessing pub/prv savedata from other titles), and the title list content varies depending on the started title (it's only containing titles from the SAME maker, plus some system titles like System Settings which are permitted to be autoloaded by to ALL makers).

Code: Select all

DSi Autoload on Warmboot
------------------------

Overview
Launcher (and unlaunch) can be commanded to autoload a different title.
  2000000h  Autoload Parameters for newly loaded title  ;<-- optional extra
  2000300h  Autoload via numeric Title ID               ;<-- official method
  2000800h  Autoload via string "device:\path\filename" ;<-- alternate method
  2FFD800h  Title List (jump-able titles for use at 2000300h)
  BPTWL[70h].bit0  Warmboot flag                        ;<-- required flag
  BPTWL[11h].bit0  Trigger reset                        ;<-- trigger reset
Moreover, autoload can occur on warmboot & coldboot: Launcher autoloads any ROM
cartridge with carthdr[01Fh].Bit2. Unlaunch defaults to autoload any file named
"sdmc:\bootcode.dsi".

Examples
DSi Browser settings screen allows to autoload System Settings (via 2000300h),
and automatically enter the Internet options page (via 2000000h).
Nintendo Zone, if started with Wireless Communications disabled, allows to
reboot itself (via specifying it's own Title ID in 2000300h).
Homebrew frontends for unlaunch could start themselves (via bootcode.dsi) and
then command unlaunch to load another title (via 2000800h or 2000300h).

2000000h - Optional Auto-load parameters (passed on to new title)
  2000000h 8    AutoParam Old Title ID (former title)    ;carthdr[230h]
  2000008h 1    AutoParam Unknown/Unused
  2000009h 1    AutoParam Flags (03h=Stuff is used?)
  200000Ah 2    AutoParam Old Maker code                 ;carthdr[010h]
  200000Ch 2    AutoParam Unknown (02ECh) ;\counter/length/indices/whatever?
  200000Eh 2    AutoParam Unknown (0000h) ;/
  2000010h 2    AutoParam CRC16 on [000h..2FFh], initial=FFFFh, [010h]=0000h
  2000012h 2    AutoParam Unknown/Unused (000Fh = want Internet Settings?)
  2000014h 2ECh AutoParam Unknown... some buffer... string maybe?
Above is the overall skeleton as intended by Nintendo, the purpose/format of
the 2ECh bytes is unknown (there seems to be some relation to entries [0Ch] and
[0Eh], but theoretically, each title could use that bytes as pleased).

2000300h - Nintendo Auto-load feature (via numeric Title ID)
  2000300h 4    AutoLoad ID ("TLNC")
  2000304h 1    AutoLoad Unknown/unused (usually 01h)
  2000305h 1    AutoLoad Length of data at 2000308h (01h..18h,for CRC,18h=norm)
  2000306h 2    AutoLoad CRC16 of data at 2000308h (with initial value FFFFh)
  2000308h 8    AutoLoad Old Title ID (former title) (can be 0=anonymous)
  2000310h 8    AutoLoad New Title ID (new title to be started,0=none/launcher)
  2000318h 4    AutoLoad Flags (bit0, 1-3, 4, 5,6,7) ;usually 16bit, once 32bit
  200031Ch 4    AutoLoad Unused (but part of checksummed area when CRC len=18h)
  2000320h E0h  AutoLoad Unused (but zerofilled upon erasing autoload area)
Flags (usually 13h or 17h):
  0     IsValid (somehow enables/disables HealthSafety when TitleID is wrong?)
  1-3   Boottype (01h=Cartridge, 02h=Landing, 03h=DSiware) (see below)
  4     Unknown
  5     Unknown
  6     LoadCompl (causes some error when set) (loading completed flag?)
  7     Unknown
  8-15  Unused
  16-31 Unused (usually not accessed at all, with normal 16bit reads)
Boottypes (in Flags.bit1-3):
  01h = Cartridge (with NewTitleID)    (with RSA signed header, or Whitelisted)
  02h = Landing ("nand:/tmp/jump.app") (with RSA signed DownloadPlay footer)
  03h = DSiware (with NewTitleID)      (with RSA signed header)
TitleID.LSW should match DSi cart header (or be reverse of NDS gamecode?)
TitleID.MSW should match DSi cart header (or be zero for NDS titles?)
Note: Many titles do create the above structure even when not requesting to
boot a new file: with NewTitleID=0=none & flags=13h=cartridge (in that case
flags should be ignored, and NewTitleID=0=none has priority).

2000800h - Unlaunch Auto-load feature (via "device:/Path/Filename.ext")
  2000800h 12   Unlaunch Auto-load ID ("AutoLoadInfo")
  200080Ch 2    Unlaunch Length for CRC16 (fixed, must be 3F0h)
  200080Eh 2    Unlaunch CRC16 (across 2000810h..2000BFFh, initial value FFFFh)
  2000810h 4    Unlaunch Flags
  2000814h 2    Unlaunch Upper screen BG color (0..7FFFh)
  2000816h 2    Unlaunch Lower screen BG color (0..7FFFh)
  2000818h 20h  Unlaunch Reserved (zero)
  2000838h 208h Unlaunch Device:/Path/Filename.ext (16bit Unicode,end by 0000h)
  2000A40h 1C0h Unlaunch Reserved (zero)
Unlaunch Flags (usually 01h):
  0    Load the title at 2000838h
  1    Use colors 2000814h (use if loaded title is KNOWN to use such colors)
  2-31 Reserved (zero)
The name can use slashes or backslashes for folders, and it can use both long
or short filenames (LFN or 8.3). The total length should not exceed 260
characters including EOL (alike windows MAX_PATH, although WinNT seems to allow
up to 32K characters, which isn't supported here).
  "nand:/path/name.ext",0000h   File on 1st partition of internal eMMC
  "sdmc:/path/name.ext",0000h   File on 1st partition of external SD/MMC
  "cart:",0000h      ROM cartridge (in NDS cartridge slot)
  "menu:",0000h      Force starting unlaunch filemenu (instead bootcode.dsi)
  "sett:",0000h      Force starting unlaunch options
  "wifi:",0000h      Force starting unlaunch wifiboot overlay
Case-sensitivity: device, path and file can use upper/lower case A-Z (not
case-sensititive), however currently any other letters are case-sensitive (eg.
umlaut's or accented letters) (that is, they must be uppercase for short names,
or have matching case for long names).
For black colors, you should also disable backlights before issuing reset (else
screen will flash white for a short moment during initial forced blank; before
unlaunch gets started).

2FFD800h - Title List
Before autoloading a title, one should make sure that the title is actually
installed (and which region code it is having, ie. one should use wildcards
that ignore the lower 8bit of the Title ID when searching the title).
The offical way is to look up the Title List in RAM, this is faster than
manually crawling the directory tree. However, there are some restrictions: The
Title List contains only titles from the same Maker (as the currently loaded
title), plus some special "jumpable" system titles.
  2FFD800h 1     Titles: Number of titles in below lists (max 76h)
  2FFD801h 0Fh   Titles: Zerofilled
  2FFD810h 10h   Titles: Pub Flags (1bit each) ;same maker plus public.sav
  2FFD820h 10h   Titles: Prv Flags (1bit each) ;same maker plus private.sav
  2FFD830h 10h   Titles: Jmp Flags (1bit each) ;jumpable or current-title
  2FFD840h 10h   Titles: Mkr Flags (1bit each) ;same maker
  2FFD850h 3B0h  Titles: Title IDs (8 bytes each)
Related carthdr entries are:
  [010h].bit0-15  Maker (must match current title for Mkr Flags).
  [01Dh].bir0     Jump (must be set for Jmp Flags)
  [230h].bit0-63  Title ID (must be nonzero for being listed)
  [238h].bit0-31  Public.sav size (must be nonzero for Pub Flags)
  [23Ch].bit0-31  Private.sav size (must be nonzero for Prv Flags)
The list can contain the hidden Nintendo Zone utility, and DSi ROM cartridges
(both provided that Maker does match up with current title).
The jumpable titles with [01Dh].bit0 that are always in the list are:
  00030015484E42xxh  ;System Settings
  00030005484E4441h  ;DS Download Play
  00030005484E4541h  ;Pictochat
  00030004484E47xxh  ;Nintendo DSi Browser (if installed)
The list does NOT contain the Launcher itself, nor files from System Data
folder (WifiFirmware, Whitelist, VersionData), nor NDS ROM cartridges, nor
anything where Jmp+Mkr flags would be both zero.
If started via 2000300h, then the New Title (from 2000310h) does also receive
the the Old Title ID (from 2000308h) with Jmp flag being set; ie. permitting to
return to the Old Title (to know which title was the old title, one should
probably look at 2000000h, or at 2000308h if that's still intact in memory?).
Also, the Jmp flag is always set for the current title; ie. permitting the
title to reboot itself.
Last edited by nocash on Tue Nov 06, 2018 2:13 pm, edited 2 times in total.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

nocash wrote:unlaunch v1.8 released

After spending some weeks on NES stuff last month, I had fresh energy for working on unlaunch.dsi. First step was improving the filesystem (with automatically parsed "device:\path\name" strings), and opened doors to adding a filemenu and many more features.

For the filemenu, I was sceptical if it could work fast enough when crawling the whole directory tree. My first attempt took about one second, but then I figured that I could abort directory reading on the first unused entry (as opposed to used or deleted entries), and that made things about 32x faster (ie. one 200h-byte sector vs one 4000h-byte cluster), and the filemenu is now showing up almost instantly (unless you have thousands of files on SD card, of course).

Next version(s) are planned to support lowercase letters & maybe french accent marks and such, reading & displaying icon/title, and some option to change the sort order of the files in the filemenu. But I think the current version does already look quite neat, and includes several details like scrolling & keyrepeat, automatically sensing ROM and SD card eject/insert, different colors for files in different locations.

After adding the filemenu I had originally planned to switch back to loading bootcode.dsi by default... but then nobody would even see the nice new features - so I changed my mind last minute and kept the filemenu as default boot action - but threw in an options screen where one can configure the boot defaults, including redefining hotkeys A,B,X,Y. The filename "bootcode.dsi" is still used (as default for button Y), but one could change that and select any other filename without needing anything called "bootcode.dsi" anymore. Another final addition is including a copy of "wifiboot.nds" as overlay, so one could now do wifi uploads without having the file on the SD card, or even without any SD card inserted.

With the new features, unlaunch can do pretty much everything that the official launcher can do (except gimmicks like making photos & displaying time/date), and you could theoretically completely delete the official launcher .app file. I guess that's now making unlaunch the "First homebrew DSi firmware" ever : )

http://problemkaputt.de/unlaunch.htm

Code: Select all

unlaunch v1.8 06 Nov 2018
 - filesys: decodes lfn's, ascii-case-insensitive, with alternate short names
 - filesys: parses path+file strings (eg. sdmc:\dir\subdir\file.ext)
 - filesys: skips mount_drive when already having the same device mounted
 - directory crawler: scans all folders on eMMC and SD/MMC (xcept DCIM etc)
 - directory crawler: creates filelist with all .app/.nds/.dsi files
 - directory crawler: adds entries for internal functions cart:, wifi:, sett:
 - crawler: doesn't treat volume labels as files (even if named .app/nds/dsi)
 - quick crawl: aborts folder reading on 1st UNUSED entry (instead cluster end)
 - quick crawl: does NOT load carthdr (instead, done on the fly in filemenu)
 - quick crawl: skip data,0003000f,import,progress,shared12,sys,ticket,tmp,dcim
 - filemenu: displays all titles from crawler and allows to select/start them
 - filemenu: displays carthdr title (instead nintendo's 000000vv.app filenames)
 - filemenu: supports scrolling and keyrepeat, loads carthdr's during scrolling
 - filemenu: ROM cart eject/insert: auto-updates ROM cart title on the fly
 - filemenu: SD/MMC card eject/insert: auto-recreates the whole filelist
 - filemenu: displays full filename and pub/prv sizes on lower screen
 - filemenu: different colors for card:+wifi:+sett: vs nand: vs sdmc: files
 - filemenu: hinge close: auto-power-off
 - device list: adjusts savedata names either data\public.sav or filename.pub
 - device list: adjusts savedata names either data\private.sav or filename.prv
 - autoload: allows retails titles to start titles via 2000300h (via title id)
 - autoload: allows frontends to start titles via 2000800h (via path\filename)
 - creates title list at 2FFD800h (needed for enter_settings & reboot_title)
 - options: allows to configure default boot action and hotkeys A,B,X,Y
 - options: shows abbreviated name for each hotkey, and full name for current
 - hotkeys not treated as menu-input in filemenu/options (when still held down)
 - hotkeys checked early (and multiple times ORed up during boot)
 - removed skip wifi-init hotkey (button Y has now other/custum use)
 - redirect to "load error" handler when trying to start empty rom/sdmmc slot
 - early backdrop init (before decompression) (black, or color from 2000800h)
 - patches tmd-size-selfcheck in launcher v1.4.2E (if size=bad, force default)
 - patches launcher.carthdr[1B4h].bit3 (needed if loading launcher from sd/mmc)
 - patches for launcher applied as usually; when selecting launcher in filemenu
 - loads verdata tmd (2FFD7B0h region/filename needed for SysSettings and Shop)
 - moved ARM9 "gif_table" to what is "cluster_buf" on ARM7 side
 - bugfixed hex32bit_r0_to_string_r1_upcase (was badly bugged on digit 9)
 - wifiboot: now included as overlay in unlaunch (allows wifi without SD card)
 - added NO ONE IS ILLEGAL tagging, and removed the nuke-crash-bombing pictures
 - resumed old GIFs, or actually it's only one of them, for memory reasons
Tested this new version, and i have to say it's pretty good, as for software issues, there seems to be no problems, as unlaunch works correctly at every boot, on the other side there is an issue that didn't happen before, if you launch the default launcher and you press teh power button once launched, it freezes (this seems to happen even with other apps launched from the launcher), the weird thing is that this thing before happened when launching hiya, but now instead on hiya this no longer happens, while it happen with the stock launcher. Other stuff regards the file browser, the first thing i noticed, and that annoyed me was that the right pad and the b button are threated as the a button, i'm not sure if this is a bug or you intended it in that way, but it gives you some troubles when scrolling, for example when keeping a direction pressed your finger slips and press the right button, the ap is immediately launched. Another thing is that when you launch something, you're not sure if it's been launched or maybe the app crashed, as it just remains in the same screen until the app has finished loading, maybe adding a "loading" text could make you understand what's happening (idk if that could also be integrated with a loading bar). It would also be nice to have hotkeys on the shoulder buttons too, from my experience i know there are people who like to have tons of hotkeys to launch their stuff imediately (i'm not one of them). Last little thing, you should update your how it works "page" in the app, as it still says it automatically boots bootcode.dsi
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

Quick update, i tested the sd swapping, it detected the sd being removed, but then whenever i put it back it has undefined behaviour: sometimes it shows a new entry with garbage data "];x;", with this info "pub size: 8016, prv size 4341004a, and as path "SDMC:/00000000.APP" (post edit, i tried running that and it refreshed the list corectly), it also shown another wrong entry once, that time with the name of my the last app in the "default" list, so in that case "UGOMEMO-V2" and with path still "SDMC:/00000000.APP", otherwise most of the time it just freezes. Obviously i don't have any file named 00000000.APP in my sd. Another thing but this is just a minor graphical thing, i made some custom dsiwares for my sdnand, and those files in their header have a pub and prv size of 0, but actually it's shown as ffffffff.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

This thing isn't completely related to unlaunch but it still concerns that, since nw wifiboot is like "prepacked" i decided to try it, and i coulnd't notice that it managed to connect to my wifi network even if that is wpa2 encrypted, but i couldn't use dslink to upload stuff to it, so was it really connected to my network or it was like a false positive of it trying to connect?
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

edo9300 wrote:Tested this new version, and i have to say it's pretty good
Glad that you say that - looks as if I didn't screw up something that caused all DSi's in your neighbourhood to get bricked. Or are there any angry kids gathering up at your front door?

Power button in Launcher: I've used that many times, and it doesn't freeze here. Which launcher version did you use? I've v1.4E installed, and also tested loading v1.4.2E from SD card, both working okay with power button.
Compared to unlaunch v1.7, the launcher is now started directly (without bootstage 2), and it's cart header is flagged to force enabling SD carts, and - after pressing power button in launcher - unlaunch will handle any incoming autoload info at 2000300h. Maybe the freezing is related to that changes.

Control Buttons: How on earth did you manage to hit DPAD-Right - and Button B - during scrolling? Only good that you didn't also hit the Start button in that process ; )
Yeah, the buttons were intended as so. You could use either A or B. And I am also often using DPAD-Right & Left as "Enter" and "Exit" (in that manner, I should have also implemented DPAD-Left for leaving the options screen).
Anyways, for future versions: Button B (plus Up/Down) is planned to drag files (for changing their sort order). And, I was considering using Left/Right as Page Up/Down.

Title loading progress bar: Yes, I was thinking about that, too. And/or showing the separate loading stages (ARM9, ARM7, ARM9i, ARM7i), and eventually "Done loading, starting title now" at the end. Though the latter should vanish almost immediately after displaying it because unlaunch is clearing VRAM before starting the title.
Are there cases where loading takes more than max 1-5 seconds (or freezes completely), while you keep seeing the unlaunch screen? That would mean that something gets wrong in unlaunch itself, before even starting the loaded title.

How it works: Yup, I should update that concerning bootcode.dsi and hotkeys (and the unlaunch.htm webpage, too).

SD card eject/insert: Works fine for me (using an old 128MB SD Card). Sounds as if other cards might need some power up delay after inserting them, Or retrying reading several times until they do response with valid data. Currently the only "delay" is the eMMC being re-read before reading the newly inserted SD card.
Surprising that it goes so far to read garbage filenames from the directories. Theoretically it should complain about errors during card initialization, or at least complain about bad MBR/VBR sectors before trying to read directory sectors. Maybe I should review my error handling... hmmm... or maybe there's some switch bounce effect: It might have had actually read the MBR/VBR successfully, and then lost contact for a moment.

Pub/prv savedata size shown as FFFFFFFFh instead of 0: Okay, that's only cosmetic for now. But it might become pricy if I add a function for auto-creating files of that size - then the two 4GB files would instantly exceed the free memory space on 8GB cards.
Are you sure that carthdr[238h] and carthdr[23Ch] are really zero? The unitcode in carthdr[012h] is set to DSi, too? If not, then the DSi's extra entries should become zerofilled, either way, the FFFFFFFFh shouldn't happen.
Do you know what cluster size you have on the SD card? I am currently loading the carthdr by reading "the first 400h bytes of the first cluster". So that would go wrong badly if the card uses clusters smaller than 400h bytes. I don't know if any cards are formatted like that, common cluster size seems to be around 4000h bytes.

Wifiboot: That's working only with open networks or WEP encryption. WPA2 won't work. Or it might go half way through the connection steps, picking up the router's SSID name and MAC address and channel number - and then hang without going through DHCP and receiving IP addresses.
Does wifiboot display SSID and Channel for your WPA2 network? If yes, I should do something to prevent that, ie. if you have two networks, one WEP, and one WPA2, then wifiboot shouldn't hang upon trying to use the WPA2 one.
Adding WPA2 support for the DSi's new wifi hardware would be another huge project. I had hoped that somebody would log the traffic on the SDIO bus using some dedicated logging hardware - but I guess that won't happen anytime soon, maybe because off-the-shelf SD/SDIO logging hardware seems to cost around $2000. My new plan would be patching the DSi Browser, so that it'll log all SDIO commands & replies by software.

Many thanks for the feedback!
User avatar
Apache Thunder
Posts: 24
Joined: Tue Jul 24, 2018 6:28 pm

Re: DSi unlaunch (bootcode exploit)

Post by Apache Thunder »

It appears loading Launcher from SD (as DSiWare I guess) still doesn't work even though the change log seems to suggest you made a patch case for loading Launcher off SD?

Also I would like to test how far this gets on a 3DS, but I think the wifi error screen is still getting in the way. Unlike on DSi, TWL_FIRM on 3DS will have stuff already inited and so you could skip a lot of things.

Unlaunch could still be useful on 3DS. TWLN partition on 3DS is smaller then DSi so not as much DSiWare can be installed to nand (and while possible to resize it, it's not easy for users to do without bricking things as this requires editing the NCSD header of the nand). Plus the 39 or so title limit for DSiWare exists on 3DS too. Currently I use DSi's Stage2 packed to a SRL installed to TWLN and booted by TWL_FIRM to test Unlaunch. I simply replicate the exploit on my SD card since this version of Stage2 I've modified to redirect all reads to SD. (this is another thing you'd have to do to get Launcher to boot off SD correctly but you already know this I believe)

An interesting note about 3DS and DSi's Stage2. Stage2 wants to load the "A" region of Launcher (or the dev version I can't recall at the moment) as it doesn't want to load Launcher from any other location. Not even sure I can provide matching DSi firmware for that region. Probably why I can't DSi System Menu to boot up on 3DS. The closest I got was getting an old pre 0.9 version of Unlaunch to "attempt" booting the "A" version of Launcher by replicating the exploit chain (without the malformed TMD, it gives me a stage2 error screen. Haven't figured out why).

Stage2 should be resetting things back to what a DSi has on bootup so the only reason Launcher is failing is a self check it's own TID compared to the region it's detecting for the console or checks on certain files on SD/NAND. (redirected Launcher's reads to SD to make things easier). At least I was able to get around Stage2 not wanting to boot Launcher by having Unlaunch do it instead. Just can't do that anymore with newer builds of Unlaunch due to wifi error screen.

I provided all the missing files from a DSi on my 3DS to ensure it wasn't working for that reason. But Launcher just white screens. Though there's no real reason to bother doing this if Unlaunch could be made to work on 3DS anyways now that you have a file browser and stuff. I was messing around trying this because I was bored. :P

I did manage to get DSi System Settings to complete a system update, but Launcher still doesn't boot. :P

A whole separate build of Unlaunch is probably needed if you want to expand to 3DS TWL_FIRM support. The exploit related code wouldn't be needed. You can just install Unlaunch as DSiWare on 3DS with all the header settings you want as if the DSi was already hacked. (since 3DS has flows in CTR side that allow booting unsigned things and this carries over to TWL_FIRM too as a result)

You are limited by how the hardware is inited on bootup though in that TWL_FIRM will always have things inited a certain way based on the header settings you used in the theoretical Unlaunch SRL you would build for this.

Although you can always just re-init the hardware to get around this if you need to. Aside from that, 3DS in TWL legacy mode is pretty much the same as DSi minus certain things like files DSi Shop would need and things like tickets not being stored on TWLN partition. (3DS has them stored in CTR partition and are not accessible by DSiWare, but this only matters for things like DSi System Settings and Launcher which will probably never boot correctly on a 3DS anyways. Well DSi System Settings will work, but it's not really recommended to use that on a 3DS anyways)

Not sure you own a 3DS though so I guess it's understandable you can't add support for that console unless you get enough donations to afford one.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

I suspected that wpa2 support was too good to be true... :cry: anyways, on that app I get all(?) the info from the router, bssid, apmac and ssid. Also other than that it shows the channel too. Then it successfully runs "dhcp discover" and then it shows connection failed after about 3 screens of "dhcp next", and in the meantime I can see that the device is connected through my router's settings page.
Reading Apache's post instead, I can confirm that the unlatched launcher booted fine from my SD card, while hiya's patched one didn't. I'm on 1.4.5
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Power button in Launcher: Just noticed that I had Launcher v1.4.5E installed on the console (not v1.4E). Also just tried loading Launcher v1.4.5E from external SD card. But it doesn't freeze for me when pressing power button.
- Does the freeze happen with & without SD card inserted? And with & without ROM cart inserted?
- Does the freeze happen in no$gba, too? It doesn't emulate power-button, but clicking "return to DSi menu" might act similar.
- Did you configure unlaunch options to use, say, Browser as default for "No Button" and as "Load Error" handler - and then uninstall the Browser? I guess that could semi-brick the console (but should still boot with Button A+B backdoor).

Pub/prv savedata size shown as FFFFFFFFh instead of 0: I just figured out that I was zerofilling the extended DSi header area only for ROM carts, not for DSiware files - which is half correct (because DS Download Play does have/require a Title ID at [230h]) - and half incorrect (because NDS don't have Device Lists at all, and thus should treat [238h,23Ch] as zero).
If your DSiware file did have [012h].bit1=0=NDS and [238h..23Fh]=FFh-filled, then, I think that I've solved the problem now.

Patched Launcher: That might conflict with my own patches (which are applied if Title ID matches launcher, with region byte ignored). Or, vice-versa, if you are using a different Title ID, then my own patches would be missing.
The .app filename passed to Device List contains the filename with device "sdmc:" when loading it from SD card (unlike your trick with using "nand:" and tweaking it to get redirect to SD card.
Aside from that incoming .app filename being on sdmc, I am not using any further patches, ie. the private.sav file and stuff in sys folder are loaded from eMMC (unless your patches are changing that).
For using .app on sdmc:, I had to patch carthdr[1B4h] in launcher. There might be problems if you were loading US launcher from sdmc: while having EU files on nand:.

3DS: I have a japanese New 3DS, but I've no idea how to run code on it. Japanese gui is nasty, I can't make sense of the 3DS guide webpage, for actual 3DS titles I didn't even figure out what fileformat they are using or if it's documented anywhere, and the console is booting up so slow that it's unpleasant to use. I never got familar with 3DS.
Having an european 3DS might help getting started.
Or some way to run DSi code on 3DS, something simple, via flipnote or so, without needing going through 3DS guide.
And seeing the 3DS bootroms would be valueable for examining the console from scratch-up, as far as I know they can be dumped - but one could dump them only when already knowing how to run code on 3DS - which I am miles away from.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Apropos things I never could make sense of:

DLDI

As far as I understand that's some sort of driver for using different flashcarts with homebrew NDS titles, and it's extremely popular in most of the homebrew scene, and there's no technical documentation about how it's working. There's some open source code available, including a "template" for the driver structure, but it's all very abstract, not really providing info on which bytes are to be stored at which address for which purpose. Or does anybody know how to make sense of it?

For DSi (and unlaunch), it might be useful to supply a DLDI driver that allows old NDS homebrews to read from the DSi's SD/MMC slot instead from flashcart. Is there already such a DLDI driver?
The two possible problems would be: A few titles might want to access both flashcart (via DLDI) and SD/MMC slot (via 40048xxh), and might get confused if DLDI redirects to 40048xxh, too. And, NDS can access flashcarts via both ARM9 or ARM7, whilst DSi can access SD/MMC via ARM7 only (or would need a way to forward data from ARM7 to ARM9).

EDIT: Made a separate thread for DLDI stuff - viewtopic.php?f=23&t=18009
Last edited by nocash on Wed Nov 07, 2018 3:31 pm, edited 1 time in total.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by tepples »

Does "Writing a DLDI Driver" at Chishm's page answer any of your questions?
User avatar
Apache Thunder
Posts: 24
Joined: Tue Jul 24, 2018 6:28 pm

Re: DSi unlaunch (bootcode exploit)

Post by Apache Thunder »

Well as for what changes I've made to Launcher I'm trying to use on SD. I modified the "default" device list table Launcher uses. Found at offset 0x191304 on 1.4E (should be the same for the big 3 regions. Only different with dev versions and perhaps more exotic versions like China/Korea).

This was to ensure that Launcher loads top screen photo from photo partition which I was able to redirect to a photo.img file stored on SD. This seemed to avoid any possible corruption issues/mix ups when switching back and forth from SD Launcher and Launcher on nand. This method also ensured that Flipnote/other DSiWare that reads stuff from photo partition also operated correctly. Tested this mostly with DSi Camera App too. Though I think HiyaCFW is using a different method of redirectiong photo. I think they are redirecting it to a folder on SD. As for other patches, the only other patches I've got on Launcher are mostly the same patches Unlaunch does too like skipping DS Cart White list checks, RSA patches, etc. I seem to recall testing this prepatched version of Launcher on NAND in No$GBA. (the version that redirects to SD) and that did work. Unlaunch boots it correctly and I can have Unlaunch CFW on SD instead of NAND.

Should work on hardware too due to how the Stage2 exploit you are using works. But I never bothered to test that as I wanted my version of Launcher to have working boot splash/menu music.

This was when replacing Launcher on NAND, not using your DSiWare booting functions.

What I am currently trying to do is using your DSiWare booting stuff to launch Launcher instead. (trying to use Launcher as bootcode.dsi for example. This is where I'm having problems getting Launcher to work.)

Anyways this also makes it so any app Launcher boots is booted off SD (and as a result it looks for tmd and app files from SD instead of nand). ALL content Launcher would normally read off nand is read off SD with how I'm starting it with modified Stage2 and the modified device table stored in Launcher. That includes things like wifi settings and the like too!

Of coarse your new Unlaunch versions sorta does this already when you launch DSiWare via button combination or via the new file browser you added.

You already redirect DSiWare to read off SD when using the file browser (or the old button combos from older versions).

What I did was to make sure official Launcher did the same. So when I try to launch this version of Launcher with Unlaunch directly it doesn't work for some reason because I assumed you were doing the same to Launcher too. I did try a vanilla unmodified copy of Launcher as well and that didn't work. At least in previous versions of Unlaunch. Have not had a chance to test that part yet. I could change the TID so Unlaunch treats it like a normal DSiWare app, but I'm pretty sure I can't do that. Launcher has some things it does based on it's own TID that fail. I recall changing TID on Launcher while testing things and it would just error out if I did that.

If your intent to allow booting different versions of Launcher off SD but have it still read nand....that could be dangerous. If the user accidentally gives it the wrong region of Launcher or a version of launcher that decides to remove files from nand that it didn't like this could brick Launcher on nand. Though as I recall that you did make sure that that one particular version of Launcher that would check it's own TMD file wouldn't do that, so I don't see consoles getting full bricked from Launcher version/region mixups. The worst that can happen with my SD redirected Launcher is it deleting things off SD or corrupting something on SD. As far as I can tell Launcher is not able to touch nand anymore with the changes I've made so it should be completely safe.

It's basically like "emunand" on 3DS. CFW on 3DS has emunand patches that redirects all nand read/writes to a hidden section on SD card. Though unlike 3DS, on DSi I'm able to avoid using hidden partitions and the like. It's almost like Nintendo planned to support installing DSiWare to SD at some point but changed their minds.... :P

Anyways the new file browser and options menu is a good addition. I hope you also add ability to toggle which patches to use on Launcher at some point to. I'd like the DSi Boot splash/menu music to be one patch that could be configured to be on or off. With your preference to being off by default. Just give us the option of choosing that.

I'm hoping you get Launcher SD redirection working to a degree you deem satisfactory enough to be a feature in Unlaunch. I have been doing it the way I mentioned above for awhile now and well as others via HiyaCFW and have not really seen any file system related corruption or problems crop up. So having an option for Unlaunch could launch firmware from SD instead of nand would be nice. It allows installing DSiWare or other changes without having to mess with nand and having to deal with the nand crypto.

It also greatly simplifies testing homebrew that I want to install to System Menu. I haven't had to do anything with NAND other then upgrade Unlaunch in quite some time and I'm happy with that. :D

Would be cool to see Unlaunch get support for this too.

As for 3DS support. Yeah a Japanese 3DS would be hard to work with. Unfortunate you don't have a more suitable one you can use. Currently the best way to hack a 3DS is to use a flashcart like Acekard 2i to exploit a bootrom flaw to install custom FIRM partitions and the like and then install a CFW like Luma. You'd have to also get a "CIA" installer homebrew so you can install CIA's of stuff like DSiWare.

Yeah the 3DS stuff is complicated compared to the DSi stuff you are familiar with. You could perhaps see if someone could donate an already hacked console to you. Then you'd only have to learn how to make CIAs out of your Unlaunch SRL and then you can test things there.
mrkrabs
Posts: 2
Joined: Fri Aug 24, 2018 1:20 pm

Re: DSi unlaunch (bootcode exploit)

Post by mrkrabs »

Unlaunch 1.8 seems to be very stable and a huge upgrade! However, if you have a .NDS file that does not have any title information, it will display as a "fuzzy" square. When you are selecting a hotkey, you are able to choose "options" from the list of choices. Not sure if that was supposed to be there, but I just thought that you would want to know. :D Also, is it possible if you can implement a feature that will load custom images for the background? If so that would be amazing. Is it also possible if you are able to use the Dpad-left and right? They could be used to run more programs, but if you have something else planned for them, that would be fine.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Thanks. Yes, some workaround for homebrew title strings is planned.
Allowing to use Options as hotkey... allows you to have a hotkey for changing other hotkeys.
Or, in future versions it might get changed to bring up more extended options, similar to System Settings.
Post Reply