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 »

clonardo wrote:
nocash wrote:Whew, I actually got a $5 patron : )
2 now....
Just wanted to tell you i love your work, i've been following you since NO$GMB, i used it on a 386 SX 33 Mhz with a Hercules graphics card (damn, how old i am).
Be well bro. And THANKS.
Thank you, too!

And also thanks to the third person having joined the https://www.patreon.com/martin_korth page!
Racso55 wrote:Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?
That's intended for identifying the unknown cameras, I think it's somewhat important (if nintendo has ever manufactured any consoles with those cameras).
But as it looks now, it appears to be more common to find people with broken camera(s). That's good to know, too. So best advice to game developers would be to "keep your games playable despite of broken cameras - that seems to be more important than supporting unknown cameras".
In unlaunch, I can change it to show the warning only on unknown ID values (but ignore missing ID's with value FFFF/FF). Btw. how are you destroying the camera/connectors?
highmans wrote:With regards to the R4i Gold 3DS -- I could send you mind to test, but I'd prefer to have it back if possible... Is there any information I could dump from the cart and provide you or does it require specialized hardware/software?
I guess it's hardware related... if I could get and keep one of those carts would be best... especially if I happen to need to do more tests with it in future.
mrkrabs wrote:Hey, I would just like to ask if you could add a hotkey to boot a file called, let's say bootme.dsi I know that there is already one for bootthis.dsi but Robz8 DSiMenu++ uses that to boot DSiWare, meaning you can't use it for anything else unless you stop using DSiMenu++ or start using .launargv files.
Maybe yes, though the hotkeys are already quite a mess, but I can probably remove some of them in future.
Sion.zaphod wrote:Also a wired issue when running DSiware using dsimenu++ Warioware Touch and Jeckyl and Hyde have no sound yet if I use the argv method to run them they work absolutely fine. All the House MD games hang with black screen and bgm in endless loop. Again these games work fine with the argv method. I presume this is an issue with Unlaunch as unlaunch is trying to run those ROMs renamed to runthis.dsi by holding X button while console reboots.
I don't really understand the sentence. I didn't make dsimenu++, and I don't have those games, and I don't know anything about an argv method, or about runthis.dsi.

I've just tried loading the launcher directly from eMMC (just like loading bootcode.dsi from SD card). It seems to be working without problems... aside from loading the file it seems to require (parts of) the device list: The ".app" name seems to be needed. And all other device list entries seem to be generated by the launcher itself.
Not sure why it can't load the launcher from SD card... the main issue seems to be "sdmc" not being included in the device list... maybe that could be fixed by adjusting the launcher's cart header (if the launcher is using it's own header to determine whether it wants to create the "sdmc" device or not).
Racso55
Posts: 2
Joined: Wed Aug 15, 2018 12:52 pm

Re: DSi unlaunch (bootcode exploit)

Post by Racso55 »

nocash wrote:
Racso55 wrote:Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?
That's intended for identifying the unknown cameras, I think it's somewhat important (if nintendo has ever manufactured any consoles with those cameras).
But as it looks now, it appears to be more common to find people with broken camera(s). That's good to know, too. So best advice to game developers would be to "keep your games playable despite of broken cameras - that seems to be more important than supporting unknown cameras".
In unlaunch, I can change it to show the warning only on unknown ID values (but ignore missing ID's with value FFFF/FF). Btw. how are you destroying the camera/connectors?
In my case it was because the insurance was toasted of the old, others that I have known was due to lack of technician and as they do not give importance they leave it this way, thanks for answering! I'll be waiting for the update
Sion.zaphod
Posts: 2
Joined: Sat Aug 25, 2018 11:01 am

Re: DSi unlaunch (bootcode exploit)

Post by Sion.zaphod »

Since my sentence was grammatically incorrect I revised it in the original post
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

Okay, now I understand what you mean. Yes, agreed, that really seems to be an issue in unlaunch.
I guess you made sure providing bootthis.pub and/or bootthis.prv as needed. Some other things that might relate to sound issues...

What value do you have in cart header [1BFh]? The touchscreen/sound controller mode in bit0 could affect sound. And the banner.sav flag in bit2 might cause weird effects if the banner.sav file doesn't exist (and I've no idea which device:/path it would use for the banner.sav file; especially in combination with the device list being redirected to sdmc:/bootthis.xxx).

If you feel like debugging your sd and mmc images in no$gba:
A look at the "Sound7" page in I/O map window would help (to see if there are any voices sent to the sound channels, if so, then inaudible sound might be caused by something muting audio amplifier or master volume).
Or if no$gba is bugging about writes to the DSP registers at 40043xxh, then the game might use the Teak DSP for sound output (the launcher is doing some minimal initialization for that; maybe I should do that, too).
Last edited by nocash on Sun Aug 26, 2018 5:18 pm, edited 1 time in total.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

edo9300 wrote:Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
Sounds similar to what gabo12 had said (there working twice in 10 tries). Do you know if you needed to have button Y pressed to get it working at least once?
Would be interesting to see what chipset you have on the mainboards/wifiboards. Especially if it turns out that you are both having the same/uncommon chips.

---

About Teak DSP: I've tried booting DSi Sound for testing if there are DSP issues... and it does have at lease some issues...

First of, it hangs with blackscreen (still in unlaunch, before even starting the DSi Sound binary). The reason is that one of the modcrypt areas is extremly huge. It's exceeding the hardware's 16bit AES block counter, so one must split it into smaller blocks before decryption (and increase the IV manually alongsides).

And after fixing that, it now hangs in white screen (ie. the binary is started, but hangs before displaying anything else than white). Trying to init the DSP clock/reset/control registers doesn't seem to help. One uncommon thing is that DSi Sound (and Flipnote) are using the shared2\0000 file, but I don't think that that is causing the problem.

Running Unlaunch with DSi Sound in no$gba works better (apart from expected issues about the DSP not being emulated). So well, that'll be a bit difficult to find what goes wrong on hardware and why it isn't going wrong in no$gba... I guess it's some hardware issue, maybe DSP related, or maybe something else.

Are there other DSi(ware) games known to use Teak DSP, and do they work with unlaunch? The only two other titles known to me are Cooking Coach and Nintendo Zone... which well, I guess could test them myself with some effort (uninstalling the cooking exploit, or trying to start the (normally hidden) Nintendo Zone tool manually).
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

nocash wrote:
edo9300 wrote:Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
Sounds similar to what gabo12 had said (there working twice in 10 tries). Do you know if you needed to have button Y pressed to get it working at least once?
Would be interesting to see what chipset you have on the mainboards/wifiboards. Especially if it turns out that you are both having the same/uncommon chips.
I tried without Y pressed but no luck, while it booted once with it pressed. Attached there are the pics of the wifi board and the nand chip
Attachments
Senza titolo-1.jpg
IMG_20180828_215043.jpg
wzhy90
Posts: 3
Joined: Sun Sep 02, 2018 6:44 am

Re: DSi unlaunch (bootcode exploit)

Post by wzhy90 »

I meet a new weird bug. my friend has newly install unlaunch.
after he install 1.4, he cant boot into sysnand via press A with power on
but it can boot while press A + UP :shock:
satelman
Posts: 2
Joined: Sun Sep 23, 2018 9:18 am

Re: DSi unlaunch (bootcode exploit)

Post by satelman »

Hi, @nocash,

I'm not sure if anybody has reported this problem yet: I've been using unlaunch + HiyaFCW on both a DSi and a DSi XL console for some time now. Recently, I created a downgraded NAND for each console with fwTool v1.6.1 --I wanted them to be on system 1.4E-- and then restored these new NANDs (they work fine if restored through fwTool v1.6.1).

From then on, I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing. When I reboot the consoles, the usual system is loaded. I cannot launch anything through bootcode.dsi, since this file is completely ignored (?). So, I can't install HiyaCFW or DsiMenu++ anymore. Why is this so strange behaviour happening? Maybe the .tmd in the NAND can't be modified anymore? Is it right-protected? But that should not matter if you want to update unlaunch, right? And why does unlauch (apparently) installs fine, but then the console acts as if unlaunch was NOT present?? The key combinations at boot time do nothing either.

UPDATE: I think unlaunch is not actually installed. I dumped the NAND after 'installing' unlaunch, and the launcher .tmd file is still 520 bytes, so it has not been modified at all!

UPDATE 2: Now I know what is the issue about not being able to install unlauch normally. If you downgrade a nand copy (for instance, from 1.4.5E to 1.4E), something happens to the launcher title that makes it impossible to install unlaunch through its installer (it seems to install, but it actually doesn't). What happens to the downgraded launcher title??

Any suggestions about how to make unlaunch work as it should again?

I'm out of ideas right now and a bit desperate because I can't figure out what is going on.

Thank you in advance for your help.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

satelman wrote:I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing.
Reminds me about this: https://gbatemp.net/threads/my-nintendo ... -8.516016/
That ended up with the person saying to know what was wrong, whatever that was (myself, I've no idea what was wrong).

Oh, and you've posted this here https://gbatemp.net/threads/unlaunch-ds ... st-8298477 saying "not changed at all in the 484e4150 (EUR) folder, but a new folder, 484E4145 (US), was created with the unlaunch .tmd file instead!" and this "Hi, @ThisIsDaAccount, I have found a bug related to European DSi consoles and the tempNand unlaunch installer."

That sounds as if you've used an unofficial installer made by ThisIsDaAccount? The official installer would be "unlaunch.dsi" itself (you might need to rename it to "boot.nds" when starting it via common exploits).

My own installer doesn't contain any functions for creating new directories, so no idea where the 484E4145 (US) folder came from. And, my installer is using "\sys\HWINFO_S.dat" to determine the folder name for your region (from the "PANH" string in that file, with "P" being europe). My understanding is that the original firmware/bootcode is doing it the same way, so my installer should use the correct folder for your region.

Downgrading from 1.4.5E to 1.4E should be no problem (I've done that myself, for using sudokuhax). I can't imagine a situation where unlaunch installer can't find the correct .tmd file whilst the console's bootcode can still find it & boot up successfully. More likely, you could end up in a situation where both can't find the .tmd file (=console is bricked because you got something wrong when downgrading).
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 »

if Europe is "HNAP" then America must be "HNAE".

Code: Select all

$ python3
>>> b"HNAE".hex()
'484e4145'
satelman
Posts: 2
Joined: Sun Sep 23, 2018 9:18 am

Re: DSi unlaunch (bootcode exploit)

Post by satelman »

nocash wrote:
satelman wrote:I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing.
Reminds me about this: https://gbatemp.net/threads/my-nintendo ... -8.516016/
That ended up with the person saying to know what was wrong, whatever that was (myself, I've no idea what was wrong).

Oh, and you've posted this here https://gbatemp.net/threads/unlaunch-ds ... st-8298477 saying "not changed at all in the 484e4150 (EUR) folder, but a new folder, 484E4145 (US), was created with the unlaunch .tmd file instead!" and this "Hi, @ThisIsDaAccount, I have found a bug related to European DSi consoles and the tempNand unlaunch installer."

That sounds as if you've used an unofficial installer made by ThisIsDaAccount? The official installer would be "unlaunch.dsi" itself (you might need to rename it to "boot.nds" when starting it via common exploits).

My own installer doesn't contain any functions for creating new directories, so no idea where the 484E4145 (US) folder came from. And, my installer is using "\sys\HWINFO_S.dat" to determine the folder name for your region (from the "PANH" string in that file, with "P" being europe). My understanding is that the original firmware/bootcode is doing it the same way, so my installer should use the correct folder for your region.

Downgrading from 1.4.5E to 1.4E should be no problem (I've done that myself, for using sudokuhax). I can't imagine a situation where unlaunch installer can't find the correct .tmd file whilst the console's bootcode can still find it & boot up successfully. More likely, you could end up in a situation where both can't find the .tmd file (=console is bricked because you got something wrong when downgrading).
I posted in several places and tried different approaches because I was a bit desperate with my situation: I downgraded my DSi from 1.4.5 to 1.4 and created this downgraded nand copy ONLY AFTER installing unlaunch --when I should have created a clean nand before doing anything else, my mistake. The resulting downgraded nand worked fine, had no unlaunch installed, but strangely enough, whenever I tried to install unlaunch again, the installer said that everything went OK, but all I got was the original DSi home menu without the exploit. And I couldn't understand why unlaunch refused to properly install.

My intention was to have a 'clean' downgraded 1.4 nand without unlaunch but with the possibilty of installing it again in the future if I wanted to. After some more testing and different working nands (previously tested in NO$GBA), I found a 'strange' solution: if I set the original .app and .tmd files in the nand launcher directory as read-only, then this resulting nand allows you to install unlaunch as usual again! Why is this happening? What does protecting the original files against writing do to make this possible? I thought that the unlaunch-modified .tmd had to be write-protected in order to work properly, but... the original files?? Can you explain this?

Apart from that, I also tried another different approach, and I injected the unlaunch.dsi installer directly into a nand copy through the latest tempNand tool, but this is a different story altogether, and the new issue I found in this case is related to the way tempNand works, not to your installer (also, I tried this after writing my first post to you). Basically, the author of tempNand added this unlaunch feature to his tool having US consoles in mind only, and so tempNand puts the unlaunch-modified .tmd into the wrong place when creating a European nand (it uses the US ...45 folder, instead of the ...50 European folder). I wanted him to know, so that he may check this behaviour and fix it in a future update of tempNand in case he wants to include support for other regions.

As you can see, there are two different issues here, one related to your installer on the one hand, and another related to ThisIsDaAccount's installer on the other hand.

So, to sum up, do you have any ideas why setting a downgraded nand .app and .tmd files in the 00030017\484e4150\content folder as read-only allows installing unlaunch, but leaving them without the read-only attribute does not? This still puzzles me.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: DSi unlaunch (bootcode exploit)

Post by nocash »

satelman wrote:So, to sum up, do you have any ideas why setting a downgraded nand .app and .tmd files in the 00030017\484e4150\content folder as read-only allows installing unlaunch, but leaving them without the read-only attribute does not? This still puzzles me.
No good ideas... but some random bad ideas...

Are you doing something totally unexpected, like installing unlaunch, and then running your emmc image through a batch file that overwrites the modified .tmd file by the downgraded 1.4E files? Or have some special bootcode.dsi file on your SD card that is intentionally overwriting the .tmd file?

The read-only attribute should have no effect on the unlaunch installer, unless the tool that you are using to change the attribute is also manipulating further bytes in the directory; one idea would be that it might delete the old directory entry and create a new entry - in a different directory sector or even a different cluster (if that should happen then it should still work, but it isn't really tested as most DSi directories are smaller than 200h bytes, and thus occupy only a single sector).

When using the "Install Now" function unlaunch.dsi, you should see about 10 messages with green font showing the installation progress, and then an orange message saying "Installation complete" - are you seeing that?
If yes, eject your SD card, and then power off/on. You should then see the unlaunch boot screen, followed by the launcher system menu screen.

PS. Are you doing the installation on real hardware, or in no$gba?
ChampionLeake
Posts: 1
Joined: Sun Sep 30, 2018 10:04 am

Re: DSi unlaunch (bootcode exploit)

Post by ChampionLeake »

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. Other applications seems to fine, but it's only just the SDNAND that's having problems with the touch functionality.
edo9300
Posts: 33
Joined: Wed Jul 25, 2018 6:34 am

Re: DSi unlaunch (bootcode exploit)

Post by edo9300 »

Updated to 1.5, and finally it no longer freezes :D ! As for the touch issue some people are having, o me the touch didn't work only once. I also tried the card boot, and i can confirm now games with wifi support boots, except for my copy Pokemon White, that remains stuck on a black screen (worth noting this a TWL card, and all teh other i have are NTR).
Post Reply