|
| ||
| Views: 1,611,767 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 12-03-24 05:01 PM |
| Guest: | ||
| 0 users reading Unlaunch.dsi released - DSi bootcode hack | 1 bot |
| Main - Reverse-engineering - Unlaunch.dsi released - DSi bootcode hack | Hide post layouts | New reply |
| nocash |
| ||
|
Normal user Level: 20 Posts: 58/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Just released unlaunch.dsi - the first ever (released) bootcode exploit for DSi. It's gaining control of the CPUs before even starting the launcher.
Installation should work on all retail DSi consoles, regardless of region or firmware version. The are two installation methods... Via DSiware exploits: Start "unlaunch.dsi" and click "Install Now". Via Hardmod: Append "unlaunch.dsi" at the end of the file "title.tmd" in folder ""title\00030017\484E41xx\content" (the "xx" varies per region). Once when installed, it will start "bootcode.dsi" from SD card almost immediately after power-up (eg. that could be renamed dslink.nds file for wifi-uploading code from PC to DSi). Or, if "bootcode.dsi" doesn't exist then it will resume booting the normal firmware (with some patches for skipping healthsafety and unlocking homebrew code). unlaunch.dsi can be downloaded on the no$gba webpage: http://problemkaputt.de/gba.htm Warning: It's still in beta testing stage, it's tested and working on my own console, and theoretically it should work everywhere, but there might some unexpected issues... Testing on real hardware For now, try this only if you have backup of your DSi's eMMC storage including Console ID and CID, and have a hardmod installed (or are ready to install one case installation goes wrong). Testing firmware/region variants The actual exploit is in bootstage 2 (which same on all retail DSi models). However, the part that resumes to bootstage 3 (launcher) requires region/version specific patches. This is currently done by searching for code patterns and modifying them accordingly, but it might fail if some firmwares contain slightly code snippets. When failing to apply some patches, unlaunch will pause booting until pressing a button (and show flickering colors on the upper screen to indicate that something went wrong). Currently tested is firmware v1.4E. If you have another older/newer firmware, or different region: Please let me know if it's working with your firmware. Testing can be done in no$gba, store a copy of your eMMC image (with correct filename and "footer") in no$gba folder, run "unlaunch.dsi" in no$gba and click "Install Now", then go to no$gba emulation setup, set "Reset/Startup Entrypoint" to "GBA/NDS BIOS" and reboot. It should then show the unlaunch boot screen for a short moment, and then boot straight to the launcher (without needing to push a button and without healthsafety). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 59/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Version v0.6: added write-protect flag to the .tmd file (avoiding Data Managment to delete it). |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 2/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Nice work. The installer has some issues mounting FAT/EMMC init with some boot up environments. (doesn't work from 4swordshax or ugopwn for example but runs fine with sudokuhax/other games that use generictwlpayload) but seems mostly safe from the reports I've seen.
Launcher needs write protect flag too but I've already notified you about this on a different forum.  |
| nocash |
| ||
|
Normal user Level: 20 Posts: 60/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've released an updated version of wifiboot (a dslink clone) on the no$gba webpage. This version is capable of doing wifi uploads on consoles with DWM-W024 wifi daughterboards. I've recently got on of those boards myself, and took maybe 2-3 hours to get it working. Errrm. Now I am really puzzled what the rest of the DSi scene was doing in the past 5 years for not getting it working.
However, there's one small problem when using wifiboot combined with unlaunch: The DWM-W024 boards seem to work only if the wifi firmware was installed (which is done by the launcher). Currently the only workaround is to eject SD card and boot launcher once, then insert SD card, and reboot as often as you want via power button tapping. In future, the wifi firmware could be installed automatically (not yet decided where: either within unlaunch.dsi or within bootcode.dsi). I've some experiences with emulating the installation in no$gba, so I could probably implement the counterpart as well, doing the actual installation on real hardware. bootcode.dsi - there seems to be some confusion what the file is supposed for. At the moment it can be used in similar fashion as boot.nds with other exploits. The huge difference is that will be started almost instantly - with most of the hardware still being uninitialized. In long term, bootcode.dsi would be required to implement the same initializations as launcher. Of course that's something that nobody has ever done yet, and I couldn't say if takes weeks or months to create a firmware that's reproducing the whole functionality of the original launcher. SD Card redirect - ApacheThunder: You already have a boot.nds file that can do that, don't you? Theoretically, you would only need to rename that file to bootcode.dsi, and then you have what you want. Or are there any problems? Personally, I am glad if I can run wifiboot after power-up, and I am happy if I won't have to use the official firmware any further (no matter if it's loaded from eMMC or from SD card). But yeah, one specific case that the SD card redirect might be good for is messing with the firmware, eg. for trying different firmware versions, or different firmware regions/languages. Concerning corrupting SD cards: As far as I remember you are redirecting both physical devices ("nand:" and "sdmc:") to SD card, and as I mentioned last year, that looks like a perfect way for data loss to me. If it's really a problem depends on how nintendo is doing the sector caching, and on which software layer it's being done. I don't think that anybody has reverse engineered that yet. Maybe your trick is causing nintendo's software to use only one cache for both "nand" and "sdmc". Or maybe it isn't, then you have a neat timebomb - it might work well for years, but could screw up as soon as some unlucky person ends up writing two files on different devices that share entries in the same (but double-cached) FAT sector. Open source. I haven't decided if unlaunch will be open source. At the moment I am rather scared about people complaining about it not being open source. Unless I am mistaken, that people seem to have never released or programmed software themselves, neither as open nor closed source. I've frequently experimented with some open source releases in past some years (for some smaller 1-3 month ASM projects with only 1000-15000 lines), and my overall expirience is that there's usually a big silence with nobody remotely using or understanding or improving the code. In case of unlaunch, I don't know if the source code would help on fixing bugs. Bug reports (from different people) are a bit unprecise so far without mentioning if the tests were done on hardware or in no$gba (and in latter case: if the program can be seen to hang on some specific address). For problems on hardware: It would be interesting if the same problem occurs also with the exact same eMMC image in no$gba. If it's a hardware specific problem: Is it bound to certain chipsets (eg. different eMMC chips)? Issues "mounting FAT/EMMC init"? What is that? There are status messages saying "Mounting eMMC drive" and "Loading FAT" do you mean that the program hangs after one of those messages? Or that it randomly hangs here or there once or when? Hanging while "Loading FAT" would theoretically mean that the FAT copies don't match up with each other. Best would be to decrypt & scandisk the eMMC image to check if that's actually the cause of the problem. "doesn't work from 4swordshax or ugopwn for example". I don't have those exploits, maybe that exploits are just missing some fundamental basic initialization steps? My own init code is probably not perfect, too. But as far as I can see it's good enough to work with the official launcher (in no$gba at least). Anyways, I could try to add some workarounds for that exploits - if somebody could point me on what gets wrong and how to fix it would be appreciated! Otherwise, somebody mentioned that one could use the exploits to start "hbmenu" and then start unlaunch from there. "Launcher needs write protect flag too". Works without that for me. And if it's deleting the launcher .app file - well, then, there you have the "SD card only" booting feature that you were asking for ; ) But yes, I can write-protect the file, and I would rather want to maintain ability to boot the console without needing a SD card. The reason why some consoles seem to need the write flag on both files might be that the programs are deleting the files in the same order as how they are stored in the directory (and abort upon first protected file). The third deleted file would be private.sav in the data folder. Are there cases where that file gets deleted, too, leaving only the .tmd file intact? And if yes, does the missing .sav file cause problems, or does the firmware automatically recreate that file when needed? PS. The code for making dswifi DWM-W024 compatible (to be done at begin of ARM7 Wifi Init function) (basically set 4004C04h.bit8, and, nintendo is also issuing the delay when having changed the bit from 0 to 1): ldr r1,=4004c04h ;\
ldrh r0,[r1] ; tst r0,0100h ; unlock NDS-WIFI for DWM-024 boards, 4/2018 bne @@is_dsi_and_already_set ; however, orr r0,0100h ; one MUST run LAUNCHER once (for wifi firmware init) strh r0,[r1] ; and then, ldrh r0,[r1] ; issue WARMBOOT via power-button tapping tst r0,0100h ; beq @@is_nds_and_cannot_set ; ldr r0,=0A410h ;42000 decimal ; swi 03h shl 16 ;waitbyloop ; @@is_nds_and_cannot_set: ; @@is_dsi_and_already_set: ;/ |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 3/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
The FAT mount issues I think are coming from certain SD card configurations. I myself have a 2GB SD card formatted as FAT16 with default cluster size I believe. Haven't had issues with the installer if I used sudokuhax. It did hang for some people when booting it from a DSiWare exploit that used minitwlpayload (4swordshax and ugopwn). I don't know the full details on that. I think it either hung on FAT for them or didn't boot properly at all. Oh and all the issues people reported involved hardware. Not in No$GBA.
The SD redirect thing is part of HiyaCFW...which relies on prepatched stage2 binaries packed into a SRL and Launcher prepatched and installed to SD. The full working setup for it is not pubically available though due to relying on copywrited binaries from Nintendo. (HiyaCFW is just a modified build of hbmenu with no GUI that loads a prepatched stage2 binary packed into a SRL) I had someone with a hard mod test modifying the Launcher on NAND to have just my SD redirect patch and it gets along fine with your Unlaunch boot process. The corruption issue I believe I solved. I tested this with DS Photo app and Data Management to test circumstances with how apps on SD would differ with what's present on NAND. Never saw an issue with it. My method of redirecting photo partition to photo.img seems stable as well and did not see issue with that. Flipnote and Photo App get along with that just fine. As for open sourcing it. I suppose it's fine for it to stay closed source. But I would hope you would give us more control over certain aspects of it. Like adding a menu/settings configuration system for enabling/disabling certain patches and whether or not the program displays anything on boot. (a clean boot into Launcher with no graphics shown before hand would be nice to have for those who like the DSi Bootsplash being disabled). Or if you want to avoid adding too much code to the program, you can provide alternate builds of it with certain patches left out or added in. Also while having the SRL for Unlaunch be both the installer and the payload for the TMD file is convenient, it may be one source of the issue for some people being unable to get it to work properly with some game exploits. Separating them may help in resolving this issue. But since I don't know how this is organized in the code I can't say if this would help at all. For example, I prefer not to disable the DSi Bootsplash and certainly don't like that this disabled the music in Launcher. (I have issue with the unlocked SCFG in NTR mode patch. Is that still a thing in 0.6?) In anycase having some of the patches optional or having alternate builds of your installer that has different patches would be nice to have. I did notice I was unable to enable the Bootsplash. How are you disabling the DSi Bootsplash? By setting the warmboot flag? that seems to occur even when a bootcode.dsi file is used. Perhaps move that to only occur when it goes to launch system menu? It's important that you write protect the Launcher SRL. Data Management, DSi Shop, and 3DS transfer tool will delete the SRL if it sees the malformed TMD. I've had one user confirm that this occurs and that write protecting the Launcher SRL resolves this. It's not as big of a problem as the TMD getting removed was. The exploit still works even after Launcher gets deleted because Stage2 loads TMD first so exploit occurs before it can check for Launcher's existance and validity. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 61/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
The installer isn't accessing the SD/SDHC card at all. It's reading/writing eMMC only. Hmmm, or maybe left-over from previous SDHC access could somehow screw up my eMMC access? Shouldn't happen, but if the same console/exploit is working only with certain SD/SDHC cards with ...? Then I might need to check my code.
And once when installed, it's loading from SD card upon power-up. I am currently using SD/FAT16 for testing (2GB or less). Theoretically, SDHC/FAT32 (4GB and up) is also implemented, too. Don't know if it's actually working, or if anybody has already tested that yet? Posted by ApacheThunder Might be so, but I am only half convinced. It isn't easy to test that stuff, problems might occur only if two writes occur to same FAT sector shortly after each other. Even if you are manually editing the FAT to provoke that situation, then you would still need to be sure that the timing issue is taking place, too. Some cosmetic fixes are planned, maybe also with some options as needed: I'll probably remove the bootscreen when loading bootcode.dsi (as it's flickering up only for a short moment anyways). On the hand, without SD card: showing the bootscreen with unlaunch version number during loading isn't that bad practice, I would rather try to tweak it being displayed a bit longer (instead of the blank white loading screen), I could maybe add an option to disable the .gif's. For disabling patches - especially those with compatibility issues: Did you check if there are actually any such problems with unlaunch... with which titles? Classic NDS titles should never touch the DSi registers at 4004xxxh, so not sure how the ports could cause problems, they are initialized for NDS mode as usually, but just without completely locking them from further access. Using bootcode.dsi as installer and payload shouldn't have any negative effects... except maybe filesize alignment. At the moment the .tmd size is 14000h bytes, which isn't really needed to be so, and which, in turn, makes the .dsi file not being a multiple of 200h-bytes. On the other hand, is there a requirement for 200h-byte size alignment? |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 4/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Well I think the same controller controls SD and NAND so if there's an issue with it being in a bad state, the installer may have issue accessing NAND? I recall I did have to init SDMCC controller a second time in HiyaCFW's bootloader just before launching arm7/arm9 binaries. Could be a matter of needing to ensure AES Engine and mmc controller are in a usable state in every boot circumstance.
As for the unlocked SCFG in NTR mode patch. As I recall that one causes some retail games to not boot correctly and will produce issues with older DS homebrew that will misdetect it as TWL mode and attempt to use TWL specific things. As for the retail games...it's been a few years now and I forget which games would have an issue with this. We saw this problem crop up when we initially modified TWL_FIRM's dev Launcher to not lock SCFG when going to NTR mode. But this was quite some time ago. Is there a specific reason you added this patch? I suppose debugging state of hardware while in NTR mode would be useful, but end users would have trouble using it. Besides hbmenu as bootcode.dsi or if hbmenu is installed to as DSiWare to system menu would provide easy access to features that require full access. I'll try and find out what games were impacted by unlocked NTR mode. I think if it only impacted games on flashcarts (caused AP measures to be triggered) then that's really not something you have to worry about fixing as long as this doesn't also impact official game carts. I'll try and find someone with a game that would be impacted this and also has a retail copy of it. The corruption issue with SD redirect patch would be extremely rare and would not impact NAND in any way since it is able to prevent DSiWare and Launcher from ever touching NAND at all. The only apps I know of that can interact with SD and NAND at the same time in quick succession is Flipnote Studio, DSi Camera App, and Data Management (and maybe DSi Browser? But I don't think that does anything with SD). I've tried copying/reading/deleting apps in Data Management between SD and redirected NAND and seen no corruption appear. Also Launcher I don't think ever does anything to SD. Launcher requires that top screen photos be on photo partition. It sorta is on SD now if you redirect Photo partition to SD. But it has it's own entry in the device table so I don't think reads/writes to photo partition on SD could cause issues with Launcher when Launcher goes to read something from NAND. The only time Launcher may write to nand is to delete invalid TMD/APP files and for storing certain settings like icon order, etc. I believe the benefits of SD redirection here outweigh the risks. It makes dealing with installing things to the redirected NAND files much easier and one never has to try messing with NAND again. A bricked console is a much bigger problem then a corrupted SD card. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 62/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Correction to my previous post: Just learned that Dave's original dslink version did have the same 4004C04h patch for DWM-W024 boards since last september. Sorry about having claimed that no one else got it working in past some years!!!
https://github.com/devkitPro/dswifi/commit/2afb800ed0faa99bb938ab7798bc0823915cea90 |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 5/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Getting reports that the RSA patches aren't fully working. Custom TMDs don't seem to work? I have not attempted this myself as I have not installed anything custom to NAND (aside from my RocketLauncher white list file which is pretty useless now with Unlaunch installed).
How many of the patches did you implement? As I recall there was RSA patches but also patches for SHA-1 stuff that you had found for 1.4 Launcher (which HiyaCFW currently uses and we have had no issues with them) SRLs that booted fine with HiyaCFW do not boot with Unlaunch. Although I've been advising people not to install custom SRLs to NAND. This is why I think SD redirect patch needs to be a thing. I keep telling people not to mess with NAND...but it seems folks are gonna do that regardless... |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 6/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Ok I tested a copy of NTR Launcher on NAND but it will not launch. (show error has occured screen) This despite providing a valid ticket and TMD. Does your RSA patch only work on the SRL?
Anyways there's not enough patches to allow homebrew to launch from System Menu. The patches you provided for HiyaCFW allow homebrew SRLs to work even without tickets for them being present. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 63/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
The SDMMC init is done pretty much from scratch up, I hope that it shouldn't get affected by previous accesses to SD or SDHC cards.
Oh, but my code still relies on the CID value in mainram at 2FFD7BCh for eMMC encryption. Can somebody run 4swordhax in no$gba and check if it keeps the CID intact at 2FFD7BCh? Reason for keeping SCFG_EXT.bit31 in NDS mode? Well, I've just done it because it was possible - and it might serve as an extra backdoor to run DSi tools (booted from NDS flashcarts). But yeah, there are probably no currently existing programs that would take use of that feature. Instead, many programs with DSi support could get confused about that new configuration. If it's causing problems then I could remove it (unless somebody reports problems loading bootcode.dsi). But before removing it: Would be nice if somebody could confirm that it's really causing problems. I am ONLY keeping the SCGF_EXT.bit31 flags set, everything else is set to NDS mode as usually (not sure if you were doing it the same way, too?). No, I haven't implemented all patches at the moment, but I can add the others, too. With the automatic patch-search functions it's a bit more difficult to implement than with hardcoded addresses for 1.4E firmware. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 7/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
So far the issues I ran into with the unlocked NTR mode are flashcart related. Cyclo DS iEvolution does not operate correctly if the cart is booted in NTR mode with your unlocked NTR mode patch. But as for the games with triggered AP functions I'm still waiting to hear back on that.
The NAND CID thing could be the issue. Old version of sudokuhax removes that from ram and I'm pretty sure hbmenu's clear ram functions remove it too. So it has to be used directly as boot.nds. Minitwlpayload uses hbmenu's nds-bootloader which I do believe has a clear ram function. That may be causing the problem. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 8/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
StuckPixel has said you can get the CID as part of the init process for EMMC. Have you not tried this? Relying on a keyblob in ram that may not be there is probably not a good idea.
You should already have code to obtain NAND CID from the init process. I just tested ugopwn and 4swordshax in No$GBA. Your installer works there. Odd that it doesn't on hardware. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 64/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Yes, I know that I can read the CID from hardware, I was just mentioning that my decryption code was instead using the CID value from main ram.
Sudokuhax v1.0 doesn't erase the CID, you probably mean the last two works of key3.y being erased. Anyways, if ugopwn/4swordhax are working with unlauch.dsi renamed to boot.nds in no$gba... then ugopwn/4swordhax apparently aren't erasing the CID either. So the problem must be somewhere else. I am rewriting most of my eMMC init code, maybe that'll help. Or maybe it requires to reset AES hardware somehow, or whatever. I got another bug report about unlaunch hanging after displaying "Loading FAT" (more specifically, ARM7 hanging in the FAT copy compare loop; after having stumbled over mismatching entries). That happens before unlaunch is writing any data, so the FAT was apparently already corrupted before starting unlaunch. What's the best way to repair FATs? I guess there's no scandisk-like tool for DSi? Or actually, the DSi firmware seems to contain that functionality - but I've no idea if or when it's actually executing that functions. My other ideas would be restoring a (hopefully more intact) eMMC backup. Or better: dumping+decrypting the eMMC and then running it through scandisk on PC - that should also show the filename(s) belonging to the corrupted FAT entry(s)... that would be interesting for getting an idea which file writes had caused the issue. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 9/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
I noticed while working with HiyaCFW code that the DSi Bootsplash will not run unless we force the value for normal boot in i2c. Is your Unlaunch payload setting the i2c stuff for disabling bootsplash even for bootcode.dsi payloads? I suggest moving this to the step of your boot process where it goes to start Launcher.
The issue is right now to get around this we have to force the DSi Bootsplash to run to undo your i2c write. So users would have to sit through the DSi Bootsplash even for real soft resets. We only want bootsplash to run on cold boot for users who decide to enable it in the settings for HiyaCFW. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 65/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Yeah, I can change it to leave the I2C warmboot flag as in case when starting bootcode.dsi. Actually makes sense if you want to add a "Important information about your brainwashed mind - touch the touchscreen to confirm that you are brainwashed" message, mimmicking the original bootscreen.
Got another bug report from somebody using a .mmc file without footer in no$gba. The footer with CID and Console ID is important for encrypting/decrypting the .mmc file. I'll add a warning message for missing footers in next no$gba version. And just in case: The DSi BIOS ROM images with AES and RSA keys are also important. More on that can be found in the first chapter of the no$gba help function. So, two issues are solved: Corrupted FAT and Missing Footer (neither one being a bug in unlaunch). So far the only real issue seems to be needing to write protect ALL files in content folder. Or did anybody encounter other problems that are definetely unrelated to Footer and FAT corruption...? I am unsure if that might apply to 4swordhax/ugopwn. From what I gathered, it works on no$gba (=no footer issue), but I can't remember if anybody had mentioned where it would hang... during "Loading FAT" or elsewhere? |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 10/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Well I did encounter an issue where Unlaunch hung trying to mount emmc when I booted it hbemnu that was installed to System Menu via HiyaCFW (was trying to use it to update to 0.6 from 0.5). Probably something funky with EMMC state with hbmenu booted this way, but other apps that use SD didn't have issues booted from this version of hbmenu. Just your Unlaunch installer.
Also I just now tested Unlaunch with ugopwn on hardware....Works fine there. So that was just the fat issue some folks had which isn't a bug in Unlaunch then and an issue with NAND format. I don't run into the fat mount hang so I guess my NAND is fine. I also tested Unlaunch installer on 4swordshax. It does hang there. Does not even show the menu options. Shows the top text showing what version it is with the graphics and such. But it never does anything after that. So there is an issue with it on 4swordshax. But it's not as big a problem since ugopwn is what most folks will probably use and if they don't have the fat issue, then the installer should run fine for them. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 66/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Sounds as if 4swordhax + unlaunch hangs on ARM7 side (the menu is drawn by ARM7, the other text and gif's by ARM9). The ARM7 code is currently loaded to 37F8000h, maybe 4swordhax doesn't have any WRAM mapped to that address (?) though then, I wouldn't know how it could have worked with 4swordhax in no$gba. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 11/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
Yeah that might explain it. Maybe different wram mappings or something. Could be different settings in SCFG registers to. Maybe something No$GBA isn't emulating accurately. I do recall it doesn't emulate the mode switch code for NTR Launcher properly. The SCFG state change occurs as intended on hardware, but in NO$GBA the change in SCFG_ROM never occurs.
Also, seems like they decided to release HiyaCFW. In regards to that, I was able to boot the prepatched stage2 SRL I made for HiyaCFW directly with Unlaunch. So that means that MBK registers and crypto keys in ram are still configured for that. That's interesting. I don't even have to use the HiyaCFW loader to boot stage2 (it's really just a modified version of hbmenu with GUI stripped out and altered to load bootloader.nds instead of boot.nds from SD) How are you launching Launcher when a bootcode.dsi file is not present? Do you just hook back into stage2 already in ram or do you roll your own code to load Launcher? Can stage2 still be booted via a bootcode.dsi or do you clear stage2 out of ram when going to load a bootcode.dsi file? Seeing how Unlaunch can load a prepatched Stage2 packed into an SRL just fine. I wonder if you could just implement the ini file configuration system HIyaCFW (or something similar to it) used so that you can allow users to control what patches are enabled at boot and whether to show the Unlaunch boot graphics on startup/reboot. That way we wouldn't need to use a launcher for HiyaCFW at all and the SD redirect patch you don't have to worry about since end users could just provide that on their own with a patched stage2 as their bootcode.dsi file and for those who decide to just roll with Unlaunch'es patches, they can control what patches to enable and whether or not the Unlaunch boot graphics show up during boot.  |
| nocash |
| ||
|
Normal user Level: 20 Posts: 67/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Yes, in unlaunch I am just using the stage2 bootcode that is still in wram for loading launcher. It's working fine, without even needing to restore any initial variables. The only thing that required rollback was copying the eMMC Info area back from main ram to wram, and then jumping to stage2 entrypoints.
But from within bootcode.dsi: Don't trust on stage2 being still present there. Currently it's probably still there - but I should change that in future and do proper zero-filling for unused memory. Except, I would rather not erase the rsa/aes/blowfish keys from memory (as it's now easily possible to dump that snippets of bios rom data from there). There should be a flag in cart header for requesting to keep that keys intact - so I could just adopt that behaviour. The MBK registers are currently unchanged - but in future they should be initialized from cart header, too. Prepatched stage2? That sounds a bit lame and dubious - you could as well reload stage2 from eMMC and then patch it. You need one extra patch though: ARM9:37B9C78h = ARM.mov r2,208h To force tmd filesize 208h (to avoid to retrigger unlaunch). |
| Main - Reverse-engineering - Unlaunch.dsi released - DSi bootcode hack | Hide post layouts | New reply |
|
Page rendered in 0.086 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 103/103, time: 0.014 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |