|
| ||
| Views: 1,610,109 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-23-24 09:15 PM |
| Guest: | ||
| 0 users reading Unlaunch.dsi released - DSi bootcode hack | 2 bots |
| Main - Reverse-engineering - Unlaunch.dsi released - DSi bootcode hack | Hide post layouts | New reply |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 12/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Well it appears the source of the FAT corruption issue was found:
https://github.com/Jimmy-Z/twlnf/issues/3 Looks like a heavily modified version of fwtool was the cause. Apparently running a system update can clear up the issue though it may not fix all instances as one user reported it didn't fix his issue. I suppose the best course of action is to not use twlnf.  |
| nocash |
| ||
|
Normal user Level: 20 Posts: 68/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Posted by ApacheThunder Mapping NDS ROMs should be emulated and working since two years ago. On the other hand, writes to SCFG registers are intended to be ignored when SCFG access is disabled, and that is emulated, too. Could that be the problem? I don't in which situation you were to doing the SCFG writes, for example, if you haven't booted through your exploit then SCFG should be usually disabled (unless your cart header properly says not to do so). On other issue is that SCFG_AxROM bits can be changed 0-to-1 only, but not 1-to-0. As far as I know that wasn't known until last week (and isn't yet emulated, so if you were doinf 1-to-0 writes then no$gba would remap the DSi ROMs, which doesn't work on hardware). Well, or if there's something else causing the problem. Do you have more info? Does it go wrong on ARM7 and/or ARM9 side? Did you usethe 80x86-BIOS-clone or the original NDS BIOS ROM images? For that, you need that NDS ROM images, and check the option in "Other" setup page. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 13/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
SCFG_EXT on Arm7 was unlocked when I attempted to switch to NTR mode. Also aware that switching from NTR mode to TWL mode doesn't work on hardware. So I never attempted that. I also never really bothered writing to SCFG_ROM more then once anyways.
I don't recall there being issues doing anything to the arm9 SCFG registers. My only guess is my method of mode change. I've been told that changing SCFG_ROM usually occurs from ITCM/DTCM memory? I use standard code run from normal ram to do it. Seems to work fine on hardware. That's how I do it in NTR Launcher: https://github.com/ApacheThunder/NTR_Launcher/tree/dsi Specifically it happens here: https://github.com/ApacheThunder/NTR_Launcher/blob/dsi/arm7/source/fifocheck.c Works fine on hardware. But not really in No$GBA. I recall NTR Launcher not working in No$GBA due to the issue with SCFG_ROM. I don't remember if it also had issues altering other SCFG ranges in No$GBA. Not sure which bios images I used. I used the bios images from a DSi. As for the NDS ones? Don't recall where I got them. I can provide sha1 hashes of them so you can check which ones you have that match mine: BIOSNDS7.ROM: 24F67BDEA115A2C847C8813A262502EE1607B7DF BIOSNDS9.ROM: BFAAC75F101C135E32E2AAF541DE6B1BE4C8C62D |
| nocash |
| ||
|
Normal user Level: 20 Posts: 69/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
16bit write to the two 8bit SCFG registers? That should probably work on hardware, but I am quite sure that no$gba did ignore it... AND that it did display a warning message about it notyet being emulated (saying "notyet16" or the like).
Executing the SCFG_ROM code in TCM shouldn't be required, you would only need to take care that ARM7 - and especially ARM9 - don't execute code in ROM at that time (ie. no SWI functions, and no IRQs). The SCFG_EXT switch to 4Mbyte Main RAM is usually also done without using TCM, instead, it's just done using code in lower 4MB of Main RAM. The part that I don't understand is that firmware code for ARM7 seems to be still clearing 16MB Main RAM while ARM9 is doing the 4MB switch. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 14/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Interesting thing about the ram change thing. SRLoader/TWLoader uses that to cache rom data without having to do stay in 16MB mode (or 32MB mode on 3DS since TWL_FIRM allows 32mb mode on retail..The only console that allows that on non dev hardware. ) since with NTR mode games you can't use 16/32MB mode without the game not working (normally) and apparently the data doesn't go anywhere when switching back to 4mb. I don't know the details on how it works exactly. But it looks like they do the ram mode switch very quickly as they use it to optimize game load times.
You can see the code for it somewhere in this repo: https://github.com/ahezard/nds-bootstrap (TWLoader is mostly a GUI front end. This is the part that runs in TWL mode and is also used by SRLoader the DSi version of TWLoader) |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 15/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Ok I just noticed that Unlaunch is clearing out the data twlNMenu uses to soft reset into another title. (0x2800000 area of ram isn't normally cleared by stage2 which is where the data is stored to tell Launcher to auto boot something). I don't think Unlaunch should be clearing that out of ram. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 16/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Actually nevermind on that. Seems like Unlaunch doesn't touch ram offset 0x2000300 (would also like to correct the previous post. I said 0x2800000 which was incorrect. That's where HiyaCFW's loader puts the rocketlauncher payload for the retail cart boot method of RocketLauncher. That area of ram isn't cleared by Launcher/stage2 during early boot either but wasn't relevant in this case)
Turns out I forgot one of the things I had do to to get loading stage2 as an SRL using a mostly normal version of nds-bootloader. The issue I ran into early on with that was that the ram address the arm7 and arm9 binaries of stage2 get loaded to the same address. But they are seperated via the odd MBK setup that stage2 uses. The problem came when I tried to use nds-bootloader to load the binaries into ram. nds-bootloader uses only arm7 code (and thus only on the arm7 cpu) to load binaries from an SRL to ram. arm7 would try to load arm9 binary into it's address. But arm7 doesn't have access to the actual location arm9's binary should be at as the virtual address is the same as arm7. As a result it would just overwrite the arm7 binary with the arm9 binary and nothing would get loaded to arm9's location. Arm9 has to load the binary into it's ram address and nds-bootloader wasn't configured to do that. I resolved that issue by adding a bootstub to the arm9 binary that relocates the arm9 binary to the correct location. This occurs after nds-bootloader puts the bins in ram and boots them. I have nds-bootloader put arm9 binary at 0x2000000 instead and the bootstub I added to arm9 does the rest. Since the boostub runs in arm9 space the binary ends up in the right place. But the area of ram used for soft reset uses 0x20000300 and this slipped my mind at the time. So the arm9 binary overwrites this. This wasn't an issue with Unlaunch at all. I corrected this problem by loading stage2's binary to 0x2000800 instead. (I only had to recompile the bootstub to use that as the new entry point for it's code). I can now problerly soft reset into other titles via twlNMenu. Oh and that gives me an idea for Unlaunch. Instead of doing all the work of coding in parsing code for MBK section of SRL extended header and what not. You could simply code in something that checks for if user holds a certain button on bootup. It can then tell Launcher to boot something like hbmenu on bootup. Launcher would do all the work for you. Though you'd have to also install hbmenu to the user's nand so that hbmenu shows up as a bootable title for system menu (or better yet use hbmenu's bootstrap program which would boot a boot.nds off SD). You'd probably have to add more patches to Launcher as our versions of hbmenu only work with HiyaCFW currently. But it's idea for you if you want to avoid having to code in all that extra stuff to load SRL's with the extra MBK info and what not. Just have Launcher do that for you.
Shutterbug2000/Robz8 figured out how the soft reset data in ram works. Here's an example. This goes to 0x2000300: 54 4C 4E 43 01 18 30 50 45 46 4E 48 11 00 03 00 45 4A 4E 48 05 00 03 00 17 00 00 00 00 00 00 00
This is raw hex data. Paste into hex editor to get the intended values. So at 0x6 of the soft reset data region, a basic CRC16 is used. Uses same algo as what is used for the CRC16 section of NTR headers in SRLs. This CRC protects regions 0x8-0x1F. If that CRC isn't valid. Launcher simply ignores it and does a normal boot. If correct, it will look for the title id/type. The full TID for the title to launch seems to start at 0xD with the first part being the platform id. All this is in little endian by the way. Offset 0x15 seems to have another copy of platform id? Then after that there's 0x18 which I think is another copy of application category. In my example above I seemed to have mistakenly set 0x15 to a different value. (probably why I failed to boot it properly. I believe at one point I was testing this to see if I can soft reset into out of region titles. Tried this with Europe version of Launcher on my USA console. Since only header is different, the end result would just be normal boot up of Launcher) Anyways that's the quick run down on what I recall with how the soft reset data at 0x2000300 is supposed to work. Normally only used by twlNMenu, but retail Launcher still looks for this so could be useful. 
|
| nocash |
| ||
|
Normal user Level: 20 Posts: 70/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Offset 0xD and 0x15? In gbatek I have it slightly different: DSi Autostart on Warmboot (20h-byte area) (also requires BPTWL[70h]=01h)
Below area can be used to force Launcher to auto-start a given title (instead of showing the Boot Menu) (the effect is similar to Autostart flag in carthdr[01Fh].Bit2). 2000300h 5 Warmboot ID ("TLNC",00h) 2000305h 1 Warmboot Length of data at 2000308h (01h..18h, for CRC) 2000306h 2 Warmboot CRC16 of data at 2000308h (with initial value FFFFh) 2000308h 8 Warmboot Unknown ;-rarely used 2000310h 8 Warmboot Title ID ;-often used 2000318h 4 Warmboot Flags (bit0, 1-3, 4, 5,6,7) ;-usually 16bit, once 32bit 200031Ch 4 Warmboot Unused Flags: 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 TitleID) (with RSA signed header, or Whitelisted) 02h = Landing ("nand:/tmp/jump.app") (with RSA signed DownloadPlay footer) 03h = DSiware (with TitleID) (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?) I've just removed some of the "notyet" warnings in no$gba that had appeared on I/O with uncommon bit-widths. Uhm, and noticed that I did had that warnings only for READs (so your WRITE to SCFG_ROM was really ignored without warning, sorry). So, now I've also added warning for writes (and in case of SCFG_ROM writes, that will be fully implemented at 8bit/16bit/32bit width in next no$gba update). I've used a tablet to peek at the https-members-only forum, somebody there is just freaking out about a "freshly formatted" SD card not working, sounds like having freshly destroyed the pre-formatted SD-compliant formatting ; ) but if/which non-standard formatting it's now having, there's hardly anything that could be done about it. And offtopic: Somebody seems to have dumped a korean firmware, but can't decrypt it because not knowing that the digits in the CID's "MY" byte are ordered month-year, not year-month : / hope that'll get solved someday (I am still curious if that firmware has some extra/custom korean font file). |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 17/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Oh I didn't know you already had that documented. Yeah I could be wrong on a couple offsets. It has been awhile since I messed with the warm boot title launch data.
Interesting thing on the Korean firmware. I knew Launcher is identical across USA, Europe and Japan (for the versions that aren't exclusive to Japan anyways) aside from header, But I had a feeling Korea (and China if the DSi had a iQue version released there?) would probably be different in more ways. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 71/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Posted by ApacheThunder It's in the hidden in the I2C/BPTWL chapter, but, yes, about of it half of it comes from the PMs that you had sent some months ago (and as far as I remember, you mentioned that it was originally discovered by shutterbug or robz). I am almost ready for a new unlaunch update. I've added a write-protect all files & folders in content folder function. And it seems to be working okay. I haven't tested weird cases like content folder containing thousands of files (it should work though even if it requires crawling multiple directory clusters). For write-protecting folders, I am excluding "." and ".." which aren't supposed to be protected, and, if there are any further sub-folders: I am currently setting the read-only attr for them, too (though, tested under win98: It's possible to set the folders read-only attr via "attrib" command - but win98 nethertheless allows to delete the folder via "rd" command). And, for next no$gba update: I've emulated the write-ability of the MBK1-5 registers in respect to the MBK9 access right settings today. So far the emulation seemed to have worked without that, but now that it's possible to write ARM7 MBK registers on hardware, it's time to have them emulated properly. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 72/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
v0.7 08 May 2018
- write-protects ALL files/folders in launcher content folder (xcept . and ..) - added hotkey: hold button A to skip bootcode.dsi (and force normal launcher) - installer: moved arm7entry from 37f8000h to 2380000h (better for 4swordhax?) - when starting bootcode.dsi: skips GIF display, keeps I2C warmboot flag - added more patches to launcher (rsa) and bootcode (gif instead whitescreen) - rebuilds whole eMMC Info at 2FFD7BCh (in case destroyed by some exploit) - uses faster 4bit sdmmc mode (if detected/supported) - more specific error messages for fat mismatch, bad mbr/vbr, etc - skips DSi DISPSTAT wait when (trying to) run in NDS mode v0.6 24 Apr 2018 - write-protects .tmd file (prevent Data Managment from deleting it) v0.5 23 Apr 2018 - first public release v000 01 Apr 2018 - discovered exploitable .tmd filesize in bootcode disassembly |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 18/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Ok tested it with 4swordshax on hardware. It black screens and doesn't even show any graphics this time. (works fine from Sudokuhax though. No issues installing it).
The only other minor issue I might have spotted thus far is that the screen flashes black during soft-reset . Perhaps due to screen init code in Unlaunch running even for bootcode.dsi payloads? |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 19/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Oh and the screen flashing black doesn't seem to occur on cold boot...And now that I think about it I don't recall if this was part of the normal boot process of the DSi or not? |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 20/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Ok hearing some folks getting softbricks with 1.4.5. The new patches you added must not work with 1.4.5 Launcher. One user can't recover it due to malfunctioning sd card slot. (he says only official software is able to read from it...I'm led to believe it's more of an issue with his SD card though) so one user can't recover it. Me thinks next version needs a Hold B to disable all patches option incase something like this happens again. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 73/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Released v0.8 . and moved the unlaunch thread to to this forum http://forum.gbadev.org/viewtopic.php?t=18147 (4dsdev.org doesn't allow new users to join, so gbadev.org should be more open to comments or bug reports).
|
| nocash |
| ||
|
Normal user Level: 20 Posts: 74/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Back here. I have meanwhile released unlaunch v0.9 as well as no$gba v2.9, for more info see the gbadev thread linked in previous post.
ApacheThunder, SCFG values for stage 2 should be same as in the eMMC Boot Info sector at eMMC offset 200h (if you haven't already have them as so), Unitcode in cartheader should be set to DSi. And load address 2000800h (or do you mean 2000000h with empty secure area?), I think that isn't a valid load address for DSi titles (should be 2004000h or higher), though unlaunch doesn't directly enforce that restriction (aside from "destroying" some data at 2000400h-20006xxh). Loading is done on ARM7 side, with the "ARM7" and "ARM9" MBK settings mapped to ARM7 side during loading as needed - I hope that that's working well, in case of doubt, use no$gba to see if your code gets loaded & mapped to the expected memory areas. What I am working on at the moment is switching the DSi to NDS mode. That is, relocating some data from 2FFFxxxh to 23FFxxxh, switching to 4MB RAM mode, switching to NDS BIOS ROMs, and (that was difficult/unexpected requirement) setting ARM7 POSTFLG register, and switching the TSC chip to NDS touchscreen mode, and initializing some NDS-wifi registers. Doing that stuff, I can boot a copy of DS Download Play from SD card. The thing that isn't working is sound output in NDS mode (neither through speaker nor headphone). I think I have properly setup POWCNT2=01h and PowerMan[0]=0Dh and also tried setting SOUNDBIAS=200h (probably not required to "enable" sound, though it's probably good to init the bias level for "intact" sound anyways). At the moment I could only think of needing to initialized more of the numerous TSC registers - or did I forgot about some other important sound related register? PS. Did anybody contact staplebutter about whether there's some chance for new users to register at 4dsdev? I've tried, but I don't know if got through the gmail spam-shield. If registering at 4dsdev doesn't work out, you could reach me at http://problemkaputt.de/email.htm or via PM in gbadev or nesdev forums. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 21/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
I don't load arm9 to 0x2000000 because the first 0x800 or so region is used for soft reset data. Anytime one wants to tell Launcher to start something on soft reset (normally only twlNMenu does this which is a dev app, but homebrew could use this to auto boot into something on exit) so that's why i did that. seeing that homebrew code was used to load the SRL and not Nintendo's code, the load address I used posed no issue.
Obviously with SRLs installed as apps on System Menu need to be loaded in such a way that the secure area is accounted for even if blank. (TWL_FIRM interestingly is less strict about this. Could load code in secure area just fine on TWL_FIRM, lol ) My DSi isn't available right now. Won't have it back till around July 3rd so I can't do further testing with Unlaunch directly. I do know that I was able to load my stage2 SRL just fine with Unlaunch 0.8. It only stopped working in 0.9. 
I had Ahezard load a revised Stage2 srl with the correct DSi Extended header values. That didn't seem to work either. I will try and play around with this more when July comes around. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 75/77 EXP: 39010 Next: 3429 Since: 10-09-15 Last post: 2100 days ago Last view: 2015 days ago |
Got ROM cartridge booting working. What I've learned is that the "reset" bit in ROMCTRL exists twice: On ARM9 and ARM7.
Normally the bit can be set only once (for releasing reset), without allowing to clear it (until cart power off). However, when booting the cart on ARM7 side, and then switching cart bus to ARM9 via EXMEMCNT, then the "already released" reset can retrigger unexpectedly (unless it was already released on both ARM9 side and ARM7 side (took me quite a whole day or two to figure out what went wrong there)). |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 22/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Ok got my DSi XL back and after testing I can confirm it's not an issue with my header settings most likely as to why my custom Stage2 SRL doesn't work. It hangs on black screens so seems Stage2 never even got far enough to boot Launcher.
I tried booting Launcher as bootcode.dsi with it's private.sav as bootcode.prv and that just white screens. (I can confirm I can boot normal DSiWare directly though. Shantae boots fine and is able to read it's save file) So I'm guessing your wifi init stuff might have borked things with Launcher/Stage2? Could be that or state of emmc controller. I doubt it's the device table stuf you set up. Stage2 wouldn't care and would just replace it with the one it sets up for Launcher. Launcher....probably hangs due to wifi not being in correct state. Device table (if it cares about that either) probably also causes it to hang. Maybe easier to just have a seperate code path for if user attempts to launch Launcher srl as bootcode/boothis.dsi file. Then you could just use a load procedure specific to Launcher's needs. Could then just skip loading custom Stage2. Would simplify things a bit for us. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 23/24 EXP: 6431 Next: 1490 Since: 09-14-16 Last post: 2332 days ago Last view: 2181 days ago |
Ok took another attempt at it. Found out the issue. It looks like Unlaunch 0.9 handles arm9 secure area the same way as official software now.
HiyaCFW's SRL was modified in a similar manner. I added Stage2's MBK values replacing the ones in the extended header then set arm9 back to the standard layout and now HiyaCFW works on Unlaunch 0.9 as well. However because of this we lose the ability to use 0x2000300 region for telling Launcher to auto boot a title. Unlaunch 0.9 doesn't want to load SRLs that have both entry point and load address for arm9 to be the same. Official software of coarse can't be loaded this way, but homebrew like hbmenu and Unlaunch 0.8 could. Maybe you could add a simple check comparing arm9's load address and entry point address in the SRL's header so that if they are the same, use the old method of loading them? This would preserve ability to have Launcher auto boot something. As currently that's impossible with Unlaunch 0.9.
|
| Main - Reverse-engineering - Unlaunch.dsi released - DSi bootcode hack | Hide post layouts | New reply |
|
Page rendered in 0.040 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 103/103, time: 0.007 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |