|
| ||
| Views: 1,393,970 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 04-19-24 11:03 PM |
| Guest: | ||
| Main - Posts by ApacheThunder |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 1/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 days ago |
That's interesting. If you manage something out of that I may actually get a DSi at some point. As for what ahezard said, yeah a lot of low level stuff we can now do on 3DS courtasy of modified TWL_FIRM environment. You simply enable bit31 of 0x1b8 in the DSi Extended header of a custom homebrew SRL to keep scfg unlocked for arm7 in DSi mode.
So these are the things we've managed to do with that: https://github.com/ApacheThunder/NTR_Launcher https://github.com/ahezard/nds-hb-menu https://github.com/ahezard/NitroHax Of coarse things will be different on DSi. Would be fun to see how these projects behave on a DSi. Sounds like you are working on trying to run code on a DSi before it's had a chance to launch boot2/Retail Launcher? I can imagine you'd run into problems. I tried a similar thing replacing dev launcher in TWL_FIRM with hbmenu and get a GURU exception. (so it sorta booted but crashed) Somethings are definitely not setup right. Maybe your work here may allow custom dev launcher for TWL_FIRM too by coincedence. Been trying to get retail launcher running on 3DS. Almost there. Got valid tickets and system apps installed to TWLN and DSi System Settings can finish a system update sequence now. But Retail Launcher hangs on white screen if I attempt to boot it. (it seems to fail very early on as it doesn't even get a chance to write to the log file on TWLN) It probably won't boot unless it somehow boots inplace of dev launcher and to do that I'd have to either replace dev launcher with it (which is impossible because there's not enough ram reserved for it in FCRAM to jam retail launcher there in it's current configuration without a major rewrite of low level stuff in TWL_FIRM) or run some kind of custom loader in place of Dev launcher to boot it from SD/NAND. Maybe replacing boot2/bootloader with DSi one would be the more feasible route. But now I'm dragging this off topic with things I may never get to finishing. 
Maybe you can try and make something that runs in dev launcher place and use it on DSi for what you ar doing here. I'm thinking the environment is similar enough at this early bootstage of TWL_FIRM that what you do there can be used on DSi pre launcher environment. But what you are doing seems to occur even before boot2 starts because it looks like your trying to get at the bootroms.... |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 2/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 3/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 4/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 5/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 7/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 9/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 10/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 11/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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.  |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 12/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 13/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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 |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 14/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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.
|
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 17/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 18/24 EXP: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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: 6192 Next: 1729 Since: 09-14-16 Last post: 2114 days ago Last view: 1964 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. |
| Main - Posts by ApacheThunder |
|
Page rendered in 0.061 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 99/99, 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. |