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.
User avatar
Apache Thunder
Posts: 24
Joined: Tue Jul 24, 2018 6:28 pm

Re: DSi unlaunch (bootcode exploit)

Post by Apache Thunder »

Unlaunch stores it' settings in the Launcher TMD that it's code also resides in. This file is on NAND so issues with SD card/missing SD card won't impact it's ability to store settings.
lorecast162
Posts: 1
Joined: Wed Jul 03, 2019 11:15 am

Re: DSi unlaunch (bootcode exploit)

Post by lorecast162 »

Hi, I was pointed to this thread from RocketRobz on github.
On my DSi XL with Unlaunch 1.9 I have two games that when launched via TWLMenu++ just go to a white screen and then freeze.
These games are Zenonia and Petit Computer.
I just tried downgrading to 1.8 and Zenonia works now. Petit Computer still freezes. These issues appeared after I upgraded from Unlaunch 1.2 to 1.9 after not using my DSi for a while.
Launching from the DSi's stock launcher presents no issues at all.
Trash_Bandatcoot
Posts: 7
Joined: Fri May 03, 2019 2:38 am

Re: DSi unlaunch (bootcode exploit)

Post by Trash_Bandatcoot »

A Chinese NAND has been found and does not work at the moment with Unlaunch.
Dunno if Korean NANDs work with v1.9 yet, I haven't tested it, but I have a Korean NAND somewhere.

For those wondering, this is v1.4C_dev (dev and retail have such little changes that it works nontheless). Let me know if anyone needs the NAND to add iQue compatibility in a later update.
Attachments
v1.4c.png
v1.4c.png (33.29 KiB) Viewed 24378 times
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Released unlaunch v2.0 - http://problemkaputt.de/unlaunch.htm

v2.0 27 Aug 2019
- extra ipc sync before arm9 vram remapping (avoid memory pit arm7 vram crash)
- cosmetic: Wifi-LED kept switched OFF during/after wifi-firmware init
- bugfixes: initializes dsi_flag AFTER vramcnt, and fixed options glitch
- removed warning on unknown chinese region (no longer unknown)
- wifiboot: faster reconnect on warmboot, rtc set, icon/title
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

I haven't yet tested if it's now working with Memory Pit exploit. Could somebody check that?

The thing that didn't work was that Memory Pit did still execute ARM7 code in VRAM while already having started the ARM9 unlaunch entrypoint, and crashed when unlaunch started to remap & initialize VRAM. Normally that shouldn't happen with NDS/DSi bootloaders. The official bootloader works as so:
- Do the overall booting and set IPC Sync to nonzero values.
- Relocate and execute final 200h-byte bootstubs at 23FEE00h (ARM9) and 380F600h (ARM7).
- Wait until both CPUs set IPC Sync to zero, and, immediately thereafter, jump to the entrypoints

EDIT: Uhm, looks as if I got that wrong, and memory pit wasn't executing anything in VRAM, or at not least not at time when starting the unlaunch entrypoint(s).
Last edited by nocash on Tue Aug 27, 2019 12:52 pm, edited 1 time in total.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
User avatar
Apache Thunder
Posts: 24
Joined: Tue Jul 24, 2018 6:28 pm

Re: DSi unlaunch (bootcode exploit)

Post by Apache Thunder »

Tested it by booting directly from Memory Pit. Stops on Green Screen so never boots it. Not using the initial release build made by Shutterbug though. I'm using the version compatible with 1.4's Camera app. So at least on that version anyways it doesn't work. I've been able to run it from hbmenu that was booted from Memory Pit though. Memory Pit's loader needs some fine tuning. I recall having to use an older build of hbmenu to get Memory Pit to work. At least the unofficial one for 1.4. Don't know if this was an issue for the one Shutterbug made. You could probably just roll your own Memory Pit payload. Probably a better idea instead of trying to deal with what ever flavor of Memory Pit the end user might have.

Oh one bug but not a big deal. Unlaunch won't boot from hbmenu if I don't have Unlaunch.dsi (renamed to NDS file for hbmenu though) at SD card root. I tried to launch it from a sub directory and it hung on white top screen black bottom screen.

Oh and I noticed you were doing some 3DS dev work? You finally have a 3DS? That's cool. Hopefully Unlaunch will have some kind of functionality on 3DS eventually. 3DS like the DSi has a 40 title limit for DSiWare and being able to boot them from SD would be beneficial for 3DS users so even if it won't boot DSi System Menu on 3DS. 3DS also has smaller TWLN partition then DSi NAND so you can't fit as much DSiWare on a 3DS as a DSi either.

It would still be useful for launching carts and DSiWare from SD. That widescreen patch thing they got going on is neat to. I'd like to see them getting that working on DSiWare at some point. Maybe you can help them with that once you get something running on 3DS. :D
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

nocash wrote:I haven't yet tested if it's now working with Memory Pit exploit. Could somebody check that?

The thing that didn't work was that Memory Pit did still execute ARM7 code in VRAM while already having started the ARM9 unlaunch entrypoint, and crashed when unlaunch started to remap & initialize VRAM. Normally that shouldn't happen with NDS/DSi bootloaders. The official bootloader works as so:
- Do the overall booting and set IPC Sync to nonzero values.
- Relocate and execute final 200h-byte bootstubs at 23FEE00h (ARM9) and 380F600h (ARM7).
- Wait until both CPUs set IPC Sync to zero, and, immediately thereafter, jump to the entrypoints
Nice, I'll test asap. There's still no hope for those with the messed up fat tables? You could make a separate tool (or integrate it in unlaunch) that copies the 1st fast table to the address of the 2nd, as that's the wrong one when using twlnf
DaPorkchop_
Posts: 1
Joined: Tue Aug 27, 2019 8:17 am

Re: DSi unlaunch (bootcode exploit)

Post by DaPorkchop_ »

Having an issue with wifiboot since upgrading Unlaunch to v2.0. A very simple homebrew thing I was working on yesterday (which simply shows some text on the screen) suddenly is unable to start any more, resulting in a plain white screen as soon as the ROM transfer completes. It was working perfectly fine yesterday when I was using v1.9, and has only started occurring since v2.0. I haven't made any changes to the code or re-compiled it or anything between testing it yesterday evening and writing this post, the only thing that's changed is Unlaunch.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Apache Thunder wrote:Tested it by booting directly from Memory Pit. Stops on Green Screen so never boots it.
I should have tested that myself before releasing the update, and my theory about the vram code problem seems to have been nonsense anyways. Okay, I gave it another look, this time looking at the I/O map windows in no$gba. Memory pit is starting unlaunch with some unusual settings:

Code: Select all

 arm9 starts with code cache and data cache enabled
 arm7 starts with CPSR irq/fiq enabled
 arm7 has value 0004000C in IPC send fifo (this causes green screen crash)
 arm7 has sound capture 0 and 1 enabled/busy (this causes below no$gba issues)
 unlaunch in no$gba runs super slow even with arm7/halt
 unlaunch in no$gba completely hangs in 80x86 emulated ARM7 SWI wait_by_loop
The first two are not so good, but don't seem to cause problems in this case. The non-empty IPC fifo appears to be the cause of the problem; I can get unlaunch booted from memory pit when clearing the IPC fifo (done shortly after the initial IPC sync, so I hope that it won't break other bootloaders).
And the sound capture: It's done with sound capture frequency set to zero, and with sound unit disabled. I am not sure what happens on real hardware in that situation? The sound unit disable might act as master disable, so the capture hopefully won't overwrite main ram. And the frequency setting and emulation slowdown... no$gba is currently excpecting one whole capture block to complete within 0 clock cycles (whatever real hardware is doing, that current emulation is obviously wrong).
Apache Thunder wrote:Oh one bug but not a big deal. Unlaunch won't boot from hbmenu if I don't have Unlaunch.dsi (renamed to NDS file for hbmenu though) at SD card root. I tried to launch it from a sub directory and it hung on white top screen black bottom screen.
I've no idea what happens there, unlaunch doesn't know & doesn't care which folder it is booted from (or if it's booted from wifi or other sources).
Apache Thunder wrote:Oh and I noticed you were doing some 3DS dev work? You finally have a 3DS?
Yes/no, I still need a 3DS console, or a New3DS XL mainboard with intact top-screen connector. At the moment, I can use only the bottom screen... which is good enough for displaying test results, except that the viewing angle isn't so good for reading the test results : /
edo9300 wrote:There's still no hope for those with the messed up fat tables? You could make a separate tool (or integrate it in unlaunch) that copies the 1st fast table to the address of the 2nd, as that's the wrong one when using twlnf
Is that verified with tools like scandisk? Ie. running scandisk leaves the 1st fat unchanged and updates only the 2nd fat? Or, manually copying 1st fat to 2nd fat does fully repair all errors, so that scandisk will then treat the mmc image as fully intact?
Just overwriting one fat by another is very easy... but I am not so sure if that is a good solution, in worst case it might overwrite the good fat by the wrong fat, or overwrite a fully intact fat by garbage in case of fat-type misdetection. In so far, it might be safer to repair the problem with dedicated tools like scandisk; and as a side-effect, that does force people to make a mmc backup.
But yeah, with some bug testing and error checking it should no problem to repair fats directly on the dsi. I am not so motivated to do that stuff because my fat isn't corrupted, and I have a working backup anyways : )
DaPorkchop_ wrote:Having an issue with wifiboot since upgrading Unlaunch to v2.0. A very simple homebrew thing I was working on yesterday (which simply shows some text on the screen) suddenly is unable to start any more, resulting in a plain white screen as soon as the ROM transfer completes.
Thanks for the feedback! I really didn't knew that anybody had ever used wifiboot. As a quick workaround, so that you can keep working: you could install unlaunch v1.9. Or if you want to investigate what went wrong in which wifiboot version, you could try loading the last some wifiboot versions from SD card, the last three versions are online at
http://problemkaputt.de/wifibo25.zip - this should be (almost) same as in unlaunch v1.9
http://problemkaputt.de/wifibo26.zip - this was released between unlaunch v1.9 and v2.0
http://problemkaputt.de/wifibo27.zip - same as in unlaunch v2.0
The major changes in that versions are added 3DS support (and some support for real time clock and icon/title), theoretically that changes shouldn't affect nds/dsi functionality... unless the problem is related to timings or unitializied memory.
What transfer tool are you using - the no$gba/utility function or devkitpro/dslink tool?
Can you upload the non-working nds file somewhere?
Oh, and are you using Open/WEP/WPA/WPA2?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
RyanTheInkling
Posts: 1
Joined: Thu Oct 31, 2019 5:00 pm

Re: DSi unlaunch (bootcode exploit)

Post by RyanTheInkling »

When I launch the DSi Camera, it gives me a message saying The System Memory has been damaged. What is causing this error?
Robz8
Posts: 13
Joined: Sun Aug 05, 2018 12:52 pm

devkitPro/dkArm/libnds homebrew wifiBoot issue

Post by Robz8 »

Gericom has tried booting some homebrew made with devkitPro/dkArm/libnds in wifiBoot, and they don't seem to boot.
Any chance of looking into this issue?

Also, some DSiWare such as Petit Computer, don't seem to boot in Unlaunch either.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Which homebrews are that? And are the binaries available for download somewhere?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
lotrosh
Posts: 2
Joined: Tue Mar 10, 2020 8:35 am

Re: DSi unlaunch (bootcode exploit)

Post by lotrosh »

Hello!My friend got a 1.4U_Dev nand. But unlaunch installer can not works fine on it. How to send the nand dump to you? BTW append unlaunch to the end of launcher's tmd file works fine.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Don't know if I need a nand dump for that.
Manually appending unlaunch to the tmd does work, on the same 1.4U_Dev nand, right?
So it's only the automatic install function not working - is there an error message, or does it hang before/after displaying any text at all?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
lotrosh
Posts: 2
Joined: Tue Mar 10, 2020 8:35 am

Re: DSi unlaunch (bootcode exploit)

Post by lotrosh »

nocash wrote: Tue Mar 10, 2020 10:47 am Don't know if I need a nand dump for that.
Manually appending unlaunch to the tmd does work, on the same 1.4U_Dev nand, right?
So it's only the automatic install function not working - is there an error message, or does it hang before/after displaying any text at all?
It is said that boot unlaunch installer via hbmenu with memory pit will show 'Unknown bootcode version' message after enter 'Install now'.
But loaded unlaunch installer as a cart with no$gba, it works all fine. idk if it is a memory pit issue.
21.png
20.png
Post Reply