|
| ||
| Views: 1,610,082 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-23-24 08:26 AM |
| Guest: | ||
| Main - Posts by nocash |
| nocash |
| ||
|
Normal user Level: 20 Posts: 61/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 62/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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 |
| nocash |
| ||
|
Normal user Level: 20 Posts: 63/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 64/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 65/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 66/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 67/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 68/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by ApacheThunder Mapping NDS ROMs should be emulated and working since two years ago. On the other hand, writes to SCFG registers are intended to be ignored when SCFG access is disabled, and that is emulated, too. Could that be the problem? I don't in which situation you were to doing the SCFG writes, for example, if you haven't booted through your exploit then SCFG should be usually disabled (unless your cart header properly says not to do so). On other issue is that SCFG_AxROM bits can be changed 0-to-1 only, but not 1-to-0. As far as I know that wasn't known until last week (and isn't yet emulated, so if you were doinf 1-to-0 writes then no$gba would remap the DSi ROMs, which doesn't work on hardware). Well, or if there's something else causing the problem. Do you have more info? Does it go wrong on ARM7 and/or ARM9 side? Did you usethe 80x86-BIOS-clone or the original NDS BIOS ROM images? For that, you need that NDS ROM images, and check the option in "Other" setup page. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 69/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
16bit write to the two 8bit SCFG registers? That should probably work on hardware, but I am quite sure that no$gba did ignore it... AND that it did display a warning message about it notyet being emulated (saying "notyet16" or the like).
Executing the SCFG_ROM code in TCM shouldn't be required, you would only need to take care that ARM7 - and especially ARM9 - don't execute code in ROM at that time (ie. no SWI functions, and no IRQs). The SCFG_EXT switch to 4Mbyte Main RAM is usually also done without using TCM, instead, it's just done using code in lower 4MB of Main RAM. The part that I don't understand is that firmware code for ARM7 seems to be still clearing 16MB Main RAM while ARM9 is doing the 4MB switch. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 70/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Offset 0xD and 0x15? In gbatek I have it slightly different: DSi Autostart on Warmboot (20h-byte area) (also requires BPTWL[70h]=01h)
Below area can be used to force Launcher to auto-start a given title (instead of showing the Boot Menu) (the effect is similar to Autostart flag in carthdr[01Fh].Bit2). 2000300h 5 Warmboot ID ("TLNC",00h) 2000305h 1 Warmboot Length of data at 2000308h (01h..18h, for CRC) 2000306h 2 Warmboot CRC16 of data at 2000308h (with initial value FFFFh) 2000308h 8 Warmboot Unknown ;-rarely used 2000310h 8 Warmboot Title ID ;-often used 2000318h 4 Warmboot Flags (bit0, 1-3, 4, 5,6,7) ;-usually 16bit, once 32bit 200031Ch 4 Warmboot Unused Flags: 0 IsValid (somehow enables/disables HealthSafety when TitleID is wrong?) 1-3 Boottype (01h=Cartridge, 02h=Landing, 03h=DSiware) (see below) 4 Unknown 5 Unknown 6 LoadCompl (causes some error when set) (loading completed flag?) 7 Unknown 8-15 Unused 16-31 Unused (usually not accessed at all, with normal 16bit reads) Boottypes (in Flags.bit1-3): 01h = Cartridge (with TitleID) (with RSA signed header, or Whitelisted) 02h = Landing ("nand:/tmp/jump.app") (with RSA signed DownloadPlay footer) 03h = DSiware (with TitleID) (with RSA signed header) TitleID.LSW should match DSi cart header (or be reverse of NDS gamecode?) TitleID.MSW should match DSi cart header (or be zero for NDS titles?) I've just removed some of the "notyet" warnings in no$gba that had appeared on I/O with uncommon bit-widths. Uhm, and noticed that I did had that warnings only for READs (so your WRITE to SCFG_ROM was really ignored without warning, sorry). So, now I've also added warning for writes (and in case of SCFG_ROM writes, that will be fully implemented at 8bit/16bit/32bit width in next no$gba update). I've used a tablet to peek at the https-members-only forum, somebody there is just freaking out about a "freshly formatted" SD card not working, sounds like having freshly destroyed the pre-formatted SD-compliant formatting ; ) but if/which non-standard formatting it's now having, there's hardly anything that could be done about it. And offtopic: Somebody seems to have dumped a korean firmware, but can't decrypt it because not knowing that the digits in the CID's "MY" byte are ordered month-year, not year-month : / hope that'll get solved someday (I am still curious if that firmware has some extra/custom korean font file). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 71/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by ApacheThunder It's in the hidden in the I2C/BPTWL chapter, but, yes, about of it half of it comes from the PMs that you had sent some months ago (and as far as I remember, you mentioned that it was originally discovered by shutterbug or robz). I am almost ready for a new unlaunch update. I've added a write-protect all files & folders in content folder function. And it seems to be working okay. I haven't tested weird cases like content folder containing thousands of files (it should work though even if it requires crawling multiple directory clusters). For write-protecting folders, I am excluding "." and ".." which aren't supposed to be protected, and, if there are any further sub-folders: I am currently setting the read-only attr for them, too (though, tested under win98: It's possible to set the folders read-only attr via "attrib" command - but win98 nethertheless allows to delete the folder via "rd" command). And, for next no$gba update: I've emulated the write-ability of the MBK1-5 registers in respect to the MBK9 access right settings today. So far the emulation seemed to have worked without that, but now that it's possible to write ARM7 MBK registers on hardware, it's time to have them emulated properly. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 72/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
v0.7 08 May 2018
- write-protects ALL files/folders in launcher content folder (xcept . and ..) - added hotkey: hold button A to skip bootcode.dsi (and force normal launcher) - installer: moved arm7entry from 37f8000h to 2380000h (better for 4swordhax?) - when starting bootcode.dsi: skips GIF display, keeps I2C warmboot flag - added more patches to launcher (rsa) and bootcode (gif instead whitescreen) - rebuilds whole eMMC Info at 2FFD7BCh (in case destroyed by some exploit) - uses faster 4bit sdmmc mode (if detected/supported) - more specific error messages for fat mismatch, bad mbr/vbr, etc - skips DSi DISPSTAT wait when (trying to) run in NDS mode v0.6 24 Apr 2018 - write-protects .tmd file (prevent Data Managment from deleting it) v0.5 23 Apr 2018 - first public release v000 01 Apr 2018 - discovered exploitable .tmd filesize in bootcode disassembly |
| nocash |
| ||
|
Normal user Level: 20 Posts: 73/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Released v0.8 . and moved the unlaunch thread to to this forum http://forum.gbadev.org/viewtopic.php?t=18147 (4dsdev.org doesn't allow new users to join, so gbadev.org should be more open to comments or bug reports).
|
| nocash |
| ||
|
Normal user Level: 20 Posts: 74/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Back here. I have meanwhile released unlaunch v0.9 as well as no$gba v2.9, for more info see the gbadev thread linked in previous post.
ApacheThunder, SCFG values for stage 2 should be same as in the eMMC Boot Info sector at eMMC offset 200h (if you haven't already have them as so), Unitcode in cartheader should be set to DSi. And load address 2000800h (or do you mean 2000000h with empty secure area?), I think that isn't a valid load address for DSi titles (should be 2004000h or higher), though unlaunch doesn't directly enforce that restriction (aside from "destroying" some data at 2000400h-20006xxh). Loading is done on ARM7 side, with the "ARM7" and "ARM9" MBK settings mapped to ARM7 side during loading as needed - I hope that that's working well, in case of doubt, use no$gba to see if your code gets loaded & mapped to the expected memory areas. What I am working on at the moment is switching the DSi to NDS mode. That is, relocating some data from 2FFFxxxh to 23FFxxxh, switching to 4MB RAM mode, switching to NDS BIOS ROMs, and (that was difficult/unexpected requirement) setting ARM7 POSTFLG register, and switching the TSC chip to NDS touchscreen mode, and initializing some NDS-wifi registers. Doing that stuff, I can boot a copy of DS Download Play from SD card. The thing that isn't working is sound output in NDS mode (neither through speaker nor headphone). I think I have properly setup POWCNT2=01h and PowerMan[0]=0Dh and also tried setting SOUNDBIAS=200h (probably not required to "enable" sound, though it's probably good to init the bias level for "intact" sound anyways). At the moment I could only think of needing to initialized more of the numerous TSC registers - or did I forgot about some other important sound related register? PS. Did anybody contact staplebutter about whether there's some chance for new users to register at 4dsdev? I've tried, but I don't know if got through the gmail spam-shield. If registering at 4dsdev doesn't work out, you could reach me at http://problemkaputt.de/email.htm or via PM in gbadev or nesdev forums. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 75/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Got ROM cartridge booting working. What I've learned is that the "reset" bit in ROMCTRL exists twice: On ARM9 and ARM7.
Normally the bit can be set only once (for releasing reset), without allowing to clear it (until cart power off). However, when booting the cart on ARM7 side, and then switching cart bus to ARM9 via EXMEMCNT, then the "already released" reset can retrigger unexpectedly (unless it was already released on both ARM9 side and ARM7 side (took me quite a whole day or two to figure out what went wrong there)). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 76/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Released unlaunch v1.0, and, moved to yet another forum:
http://forums.nesdev.com/viewtopic.php?f=23&t=17581 (see there for details). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 77/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I have started looking into 3DS hardware specs last week, at the moment I am still learning about what is already known and I am still trying to figure out how to write & execute a program that displays "hello" on the 3DS screen... and if I get that working then I could start doing actual rev-engineering about bits and registers, and perhaps contribute some still unknown details.
I don't know if anybody is still reading 4dsdev - and it doesn't seem to be possible to create new accounts here anymore - so I am posting more questions & findings on nesdev: http://forums.nesdev.com/viewtopic.php?f=23&t=18490 It would be really nice if somebody could help me on getting started, and answer some basic questions here and there! And maybe also some more specific expert questions like "what the heck is a CGC?" (in such cases, I would be glad even if somebody could just confirm that it's still unknown what "CGC" means). |
| Main - Posts by nocash |
|
Page rendered in 0.043 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 90/90, time: 0.005 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |