|
| ||
| Views: 1,610,082 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-23-24 08:06 AM |
| Guest: | ||
| Main - Posts by nocash |
| nocash |
| ||
|
Normal user Level: 20 Posts: 41/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by gudenau Posted by Normmatt Yeah, something like that is planned - sooner or later. At the moment I am focusing on getting the SD card CMD's and ACMD's working (and stick with a SD card image for now). And creating a "virtual" SD card image from a directory: The creation wouldn't be too difficult. Creating a "full" image (with actual data files in it) would be probably quite slow, so I would prefer to create only the FAT+directory (and keep the actual data file at their original locations) (ie. using some list that tells which "cluster" is in which file, and at which file offset). The problems would be handling changes to the files... The first issue would be if the file gets changed on the PC (by some other application). I guess one couldn't do much against that(?) or would it be possible (and desired) to "lock" all files in the directory? Otherwise one could just tell the users not to touch the files during emulation. Or maybe trap timestamp changes and force the emulator to eject-recreate-reinsert the SD card. Any ideas how to handle that? Or info how DeSmuME is doing it? And the other issue would be handling changes by the emulator: Changing/adding/deleting files, and somehow reflecting that changes to the directory when the emulation stops. Or maybe even instantly reflecting it upon any changes to FAT or directory, so a file would get instantly deleted in the directory when the emulated software is deleting it in the SD image. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 42/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Another update, no$gba v2.8d...
This version supports DSi games and system files with unencrypted "rsa" signatures (done by hooking the rsa bios functions). This should be very useful for developing & testing DSi stuff without knowing Nintendo's private key. And, SD Cards are now emulated, too. The no$gba package includes a blank 128MByte SD Card image ready for use (if you want to use it: please unzip the "dsi-sd.zip" file). This should be also very useful for developing and testing anything that accesses the external SD Card slot. http://problemkaputt.de/gba.htm - no$gba homepage http://problemkaputt.de/magicflr.htm - sample for a homebrew DSi cartridge with working/unencrypted signature 26 May 2016 - version 2.8d - dsi/rsa: supports unencrypted "rsa" signatures (via hooked RSA swi functions) - dsi/sdmmc: supports NDMA sdmmc start condition (for SD data32 read/write) - dsi/sdmmc: supports SD card initialization (CMD0,2,3,7,8,9, ACMD6,13,41,42,51) - dsi/sdmmc: created/included empty sd-card-image (file dsi-1.sd, in dsi-sd.zip) - dsi/sdmmc: fixed irq-retriggering (recurse irq_stat on irq_mask changes) - dsi/sdmmc: adjusts insert/eject and write-protect flags depending on dsi-#.sd - dsi/sdmmc: prevents RXRDY in DATA32 mode (@@skip_rxrdy_in_data32_mode) - dsi/help: added notes on EMPTY sd-image (dsi-#.sd) (DSi SD/MMC Images chapter) - dsi/help: added notes unencrypted signatures (see BIOS RSA Functions chapter) - dsi/help: added notes on encrypted twl-*.der files (in "verdata" NARC file) - dsi/help: added CRC32 checksums for currently known/dump-able DSi-BIOS areas - dsi/debug: shows insternal sd/mmc registers in iomap screen (cid,csd,csr,src) - sample: updated magic floor gba/nds version, now with working dsi cart header |
| nocash |
| ||
|
Normal user Level: 20 Posts: 43/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
About the 1st question: Somebody pointed me on this https://github.com/mborisov1/rsa_embedded - it's less than 200 lines of code - and it contains everything needed to decrypt RSA signatures!
That's about a million times simplier than trying to understand polarssl source code, or trying to disassemble the DSi bios functions. I've ported it to ASM, and it's actually working for the DSi signatures. When changing two things: The .h files defines MPI_NUMBER_SIZE=128, counted in 16bit units (ie. 256 bytes), for the DSi that must be changed to half of that size. The source/dest/key values must be little-endian, whilst the DSi does have them stored in big-endian. And the parameters for the "mpi_powm65537" function are then "m=source/dest buffer", and "n=key". |
| nocash |
| ||
|
Normal user Level: 20 Posts: 44/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Found one weird detail: The RSA signatures in the DS Cart Whitelist aren't verified in DSi firmware v1.4E.
Other (older and newer) firmware versions like v1.3U and v1.4.5E are verifying those signatures, but v1.4E doesn't verify them - that firmware version doesn't even include the Whitelist's RSA key. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 45/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
One more DSi mystery getting solved: the 843Kbyte "\sys\TWLFontTable.dat" font file. As one may assume, it does contain fonts, and it's been fairly obvious that it's compressed somehow, but without actually knowing how the compression works - or even where the compression starts.
The answer is surprising simple (and a bit weird): The fonts are compressed backwards; the compression starts at the end, and ends at the start. The exact decompression function can be found in Flipnote (EUR) at address 20BF8E4h (which is mainly doing error checking, and then calling the actual decompression function at 20BF938) (Flipnote does also contain several custom fonts, the TWLFontTable.dat file is used only for Flipnote's "Help" function). The decompression is about same as the BIOS/SWI "LZ77" decompression function, but processed backwards, with some extra footer, using 8bit flags, and 4bit len(+3), and, oddly, 12bit disp(+3) instead of disp(+1). And, it's intended to store the compressed and decompressed data in the same memory block, so that the compressed data will get overwritten during decompression - that would cause problem on worst-case compression ratios (which can require 9 compressed bytes for 8 uncompressed bytes; and which would actually cause problems at the begin if the file; assuming that the bytes in the chunk headers aren't occuring elsewhere in the font data). To avoid still unprossed data getting overwritten in such cases, the first some bytes (usually 15h bytes) are left uncompressed, and the decompession stops when reaching that location. In decompressed form, the font tiles are looking as so: http://problemkaputt.de/dsifontl.png - Large Font, 16x21pix, 2bpp, 7365 characters http://problemkaputt.de/dsifontm.png - Medium Font, 12x16pix, 2bpp, 7365 characters http://problemkaputt.de/dsifonts.png - Small Font, 10x12pix, 2bpp, 7365 characters The three fonts seem contain exactly the same characters (and do differ only by the font size). The font width's are proportional, eg. the 16x21pix font be max 16 pixels wide (plus spacing), but most characters are using than 16 pixels (as defined in the Font Width chunk). From what I can see, the font seems to cover english letters, european letters with accent marks, greek, cyrillic, several symbols & punctuation marks, and... something for some eastern language(s) that I am not really familar with. If I should guess: It's probably japanese. Or, it might be some rather incomplete mixup of japanese, chinese, and/or korean. Anyways, I am still having some questions... 1) Can somebody confirm if it's japanese and/or chinese and/or korean? 2) If it's ONLY japanese: Can anybody check if chinese/korean DSi consoles do have a different file, or extra font files? 3) Can somebody check how many letters are actually legible? The symbols seem to have underwent some ugly resampling process, resulting in rather smeared/dirty character glyphs. The large font might be still 95% legible (?) but the Small font... is anybody able to deciphier more than 10% of those characters? Or well, maybe you can intuitively identify everything if you are familar with the language, even if the letters are only smeared gray rectangles with a few black dots here and there? 4) Does the 3DS have the same font (in the DSi partition)? And do all DSi's have same font version? That is, if it's same as mine, then the RSA signature at the begin of the file should start with 23h,8Bh,F9h,08h,... 5) Is there more info about the Nitro Font format? The stuff that's known to me (see link below) is still a bit incomplete on some chunk header entries. PS. some more info about the overall .dat file format, and about the decompressed Nitro Font format can be found here: http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwarefontfile |
| nocash |
| ||
|
Normal user Level: 20 Posts: 46/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by 54634564 Yes, that should work. The bios might initialize the exception vectors a few cycles after reset (or possibly much later after reset), so there should be at least a short timeframe where one could trigger 'uninitalized' exception vectors. The timing should be rather don't care: It shoud be no big issue if crashes are also triggered before & after that timeframe, ie. like this: - start unstable mode, provoking exceptions - wait a second or so - issue reset - wait a second or so - resume stable operation Same should also work on DSi, the DSi exception vectors are: DSi ARM7 debug vector = 3FFFFDCh (internal ram) DSi ARM9 debug vector = 2FFFD9Ch (external main ram) if neccesary, one could even stretch the timeframe to 'infinite' on ARM9 side (by deactivating the main ram write signal). The main question is How to crash the ARM CPUs? Does anybody have any experiences with that? Crashing ARM CPUs intentionally? Or even unintentionally, eg. by doing some unsuccessful overclocking mods? The debug exceptions are triggered on FIQ, Prefetch Abort, Data Abort, und Undefined instruction. FIQ (fast interrupt) is probably disabled in CPSR so it's probably not usable (even if CPU should have a FIQ input somewhere). Prefetch and Data abort probably won't work either (unless the CPU has external inputs for such aborts somewhere; I haven't spotted any such inputs on DSi, if they are there, then they probably hardwired to VCC/GND underneath of the BGA chip) (don't know if the 3DS CPU has any useful pins for that purpose). So that would leave the Undefined instruction exception... the bootcode is executed in internal ROM, so one obviously can't 'patch' the opcodes, but one could probably cause unstable opcode fetches... my two ideas for doing that would be: - Overclocking the CPU, or, - Lowering the CPU's power supply Any other ideas? Or ideas how to best implement any of those two ideas? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 47/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Thanks for confirming that it's really japanese! Didn't knew that kanji is shared for different languages, I though japanese would be totally different than chinese and korean, and that chinese and japanese would each have more than 6000 symbols, and sum up to more than 12000 for both languages. But with shared symbols... they would sum to something ways less?
I guess nobody has ever dumped the eMMC filesystem from chinese/korean DSi or 3DS yet, or did anybody do so? Aside from the font file, the chinese DS was also known to contain an extra font in Wifi FLASH memory. I am not absolutely sure if or how games were allowed to use that font - if they were allowed to do so, then chinese DSi and 3DS should also include that old DS font somewhere for backwards-compatibilty. And maybe same for korea - but I don't even know when (and if) the DS was ever sold in korea, if yes, if it did contain some similar extra font in Wifi FLASH as in china. Oh, and one note on the character sets supported in the TWLFontTable.dat file. It has been said to support ASCII ;english
but that isn't exactly right. The Char Map chunks are containing only one set of character numbers (though split into separate chunks). The character numbers are probably 16bit Unicode (as indicated by the "Encoding" byte in the Font Info chunk). There isn't anything related to ISO/CP/JIS character numbers in the file. Of course, one could use some external translation table to convert such numbers to unicode.
ISO 8859-1 ;english+european ISO 8859-7 ;english+greek CP 932 ;english+sjis CP 1252 ;english+european CP 1253 ;english+greek JIS X0201 ;english+jis8bit JIS X0208 ;english+jis16bit For the meaning of the various bytes in the chunks, the Glyph chunks is fairly simple: Character Glyph (Tile Bitmaps)
The rotation byte is usually zero (meaning of other rotation values are rather unclear).
00h 4 Chunk ID "PLGC" (Character Glyph) 04h 4 Chunk Size (10h+NumTiles*siz+padding) 08h 1 Tile Width in pixels 09h 1 Tile Height in pixels 0Ah 2 Tile Size in bytes (siz=width*height*bpp+7)/8) 0Ch 1 Underline location 0Dh 1 Max proportional Width including left/right spacing 0Eh 1 Tile Depth (bits per pixel) (usually 1 or 2, sometimes 3) 0Fh 1 Tile Rotation (0=None/normal, other=?) 10h ... Tile Bitmaps ... ... Padding to 4-byte boundary (zerofilled) Byte 0Dh seems to be the "max proportional width" (ie. the biggest value from the Char Width chunk) (not 100% sure, but I've examing about 10 nitrofont files, and it does match that rule with all of those files. Byte 0Ch might be the underline location. But it's hard to tell for sure because the "upper part" of the character is usually always "square", so the byte could be either related to the underline location, or to the bitmap width (unless any games are actually drawing underlined text (?) then one could check if those games use that byte). Character width is also quite simple... Character Width
00h 4 Chunk ID "HDWC" (Character Width) 04h 4 Chunk Size (10h+NumTiles*3+padding) 08h 2 First Tile Number (should be 0000h) 0Ah 2 Last Tile Number (should be NumTiles-1) 0Ch 4 Unknown/unused (zero) 10h+N*3 1 Left Spacing (to be inserted left of character bitmap) 11h+N*3 1 Width of Character Bitmap (excluding left/right spacing) 12h+N*3 1 Total Width of Character (including left/right spacing) ... ... Padding to 4-byte boundary (zerofilled) But the Font Info chunk is pretty unclear: Font Info Chunk
Most of the entries seem to be duplicated stuff that's also found in the Character Glyph chunk (ie. the width/height/underline stuff). Which would be rather useless if it's really like that. And it would be even weirder because there newer 20h-byte chunk version invented more of those useless entries.
00h 4 Chunk ID "FNIF" (Font Info) 04h 4 Chunk Size (1Ch or 20h) 08h 1 Unknown/unused (zero) 09h xxx 1 Height ;or Height+/-1 0Ah xxx 1 Unknown (usually 00h, or sometimes 1Fh) 0Bh 2 Unknown/unused (zero) 0Dh xxx 1 Width ;\or Width+1 0Eh xxx 1 Width_bis (?) ;/ 0Fh 1 Encoding (0/UTF8, 1/UNICODE, 2/SJIS, 3/CP1252) (usually 1) 10h 4 Offset to Character Glyph chunk, plus 8 14h 4 Offset to Character Width chunk, plus 8 18h 4 Offset to first Character Map chunk, plus 8 1Ch (1) Tile Height ;\present only 1Dh xxx (1) Max Width or so +/-? ; when above 1Eh (1) Underline location ; Chunk Size = 20h 1Fh (1) Unknown/unused (zero) ;/(version 0102h) And in case of the "xxx" marked entries, the values aren't even exact dupes (in the files that I've tested, they are sometimes +/-1 bigger or smaller as in the Glyph chunk; there might be some reason for that, or maybe somebody just didn't iniatialize those bytes properly). I haven't checked the open source stuff recently (but used sources like those last year when trying to understand the nitrofont format, and least back then, they couldn't explain all bytes in the Font Info chunk either). Anyways, at the moment, the biggest font mystery would be what's going on in china and korea. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 48/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I've tested crashing the DSi CPUs... with some success on crashing the ARM9... but without actually managing to dump any bootroms yet, and without any success on crashing the ARM7 yet. What I've done so far:
- attached two wires to the oscillator - cut CL1,CL2,CL4 (VDD13,VDD18,VDD33) and bridged them with 220 ohm potentiometers - wired a push-button to mainram /WE and VDD18 - and, of course, hooked to 2FFFD9Ch/3FFFFDCh vectors by software The 220 ohm pots were the smallest ones I had around, 50 ohm or 100 ohm might be a bit more suitable (especially for VDD33). See the Power Managment Device section on the http://problemkaputt.de/twl-core.jpg image for details about the VDDxx lines. For the oscillator I've only tried to attach a 2nd osc (in 16Mz,17MHz,45MHz,100MHz ranges) in parallel with the on-board osc, hoping that it would somehow disturb the clock, but nothing seemed to have happened at all (maybe it'd work better when injecting some amplified clock signal). And, just fiddling with the two wires: Nothing happened when touching only one of the wires, but touching both wires with sweaty fingers made the DSi run a lot slower, and video showed flickering scanlines - but the software just kept running as normal. Lowering VDD12 for a moment does work quite reliable for crashing the ARM9 and trapping the 2FFFD9Ch vector, sometimes it does work out, but I've got it working dozens of times. Displaying LR and CPSR showed these values: LR=FFFF010Ch (retadr to debug handler) and CPSR=600000DBh (cpu in "_und" undefined instruction mode). Lowering VDD18 for a moment just seems to hang the console, the picture on screen freezes, and neither the main program nor the crash handler seem to be executing. Lowering VDD33 didn't got me any useful results either, and worst, the potentiometer prevented the console from booting up (even when setting the pot to "0 ohm" position), the DSi booted only when briding the pot with a screwdriver during power-up (and then worked without the screwdriver; probably the screwdriver was needed only for charging up some huge capacitor). So, the best results have been with VDD12. And to make use of it, one would need to lower VDD12 after Reset (while the bootrom is unlocked), and, best ensuring that the bootcode doesn't overwrite the previously installed 2FFFD9Ch vector (hence the push button on the ram /WE signal). I've got it working this way: - hold down the push button (shortcut /WE to VDD) - tap the power button (to issue a Reset) - release the push button - lower VDD12 for a moment (to jump to 2FFFD9Ch) That procedure doesn't work perfectly reliable, but I got it to execute the 2FFFD9Ch handler a couple of times... However, I haven't yet managed to display any text on the screen (after the Reset, I merely managed to change the backdrop color by writing increasing numbers to the palette at 5000000h, which works fine & produces some sort of snow/stripes on the screen). Maybe text output would work when re-initializing more I/O ports (or if that doesn't work out: Just changing the screen backdrop color should be enough to transfer data to PC serially). But, I didn't manage reading the ARM9 bootrom yet. I've tried reading ROM via a LDR opcodes (and also by calling the FFFF0808h BIOS memory copy function in case the BIOS can be read only by BIOS code; and that FFFF0808h function is specifically used for that purpose)... and programmed the crash handler to do the screen blinking only if [FFFF8000h] is nonzero... and unfortunately that didn't work out yet. Theoretically the ROM should be mapped at FFFF8000h after reset, so maybe it's been just bad luck that I didn't manage to read it, or maybe there's some nasty feature that disables ROM access in certain situations (like when trapping exceptions, or when the bootcode noticed that ram writing didn't work or whatever). Anyways, I am still hoping that there is some chance to get it working... best give it a try yourself, too! |
| nocash |
| ||
|
Normal user Level: 20 Posts: 49/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by StapleButter Yup, that's why I've used the FFFF0808h BIOS memory copy function (it's explicitely intended for copying data from the upper half of ARM9 ROM, so that should work). Posted by Normmatt Blocking only the vector address would require a main ram hack (which, scanlime has given that hack away... to somebody who seems to have disappeared). The keys are written to TCM (not main RAM), so they could be actually written, and yes, good idea, I could check that. But the boot process seems to involve some main ram handshaking, so, with /WE blocked, I would doubt that it could ever reach the end of the bootrom's boot code (in so far I would be more afraid that the boot code might be doing something like "if some error occurs then shutdown withs roms disabled"). But, yeah, I should check the TCM keys to make sure that it didn't just reach the "normal" end of the boot process... which... that could be relatively easily prevented by unplugging the wifi daughterboard). Oh, I've fixed the text output issue (I just have been doing something wrong when trying to map vram via port 4000204h). So now I am no longer "blind" when viewing the test results. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 50/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I've tried reading TCM 1FFC400h, and it's actually containing C3,02,93,DE, ie. the bytes from ROM address FFFF87F4h. So the bootrom did apparently really reach the stage where it did relocated the keys to TCM (and disabled ROM access thereafter).
Tried to unplug the wifi board before reset, to prevent the above stuff, but as by now that gave me only white screens after reset. VDDxx are the official names for the supply lines as shown on PCB text layer, and yes, they have a meaning in volts: 1.2V for VDD12. And yeah, it's not a very difficult hack, the most challeging part is having to reboot the console for each test (and my potentiometer/pushbutton circuit is a totally amateurish approach, maybe it'd be better to control that part by some microprocessor; so one could get the crash timed to occur shortly after reset). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 51/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I've replaced the /WE push-button by switch - so, after having uploaded my crash handler, I can disable ram writes once and forever, that's allowing to crash/reset the console hundreds of times without needing to re-upload the test software. Of course, the program may not use stack & variables in main ram in that case.
For VDD12, the critical boundary is 4.7ohm, which drops the supply to around 0.95V - 1V (varies depending on what the cpu is doing). At the moment I have the VDD12 potentiometer replaced by a voltage divider: 4.7ohm, and a push-button with a 7.3ohm pull-down resistor. That 7.3ohm isn't always working, for example, the bootrom error screen (with the "0000FEFX" error codes) doesn't react at all at 7.3ohms. It does react at 0 ohm pulldown (ie. when dropping VDD12 to 0V), but it looks as if 0 ohm is causing the cpu to do a Reset, instead of doing a crash. I'll have to try other pulldown values between 0 and 7.3 ohm. As by now I've managed only to get crashes after roms got disabled. Or actually, I seem to have gotten some crashes before that point, but they did only show "0000FEFX" error codes, or just blank white screens. The latter effect might be due to some I/O ports not being initialized at that point (so screen output won't work even if the crash was successful), but, I am relocating ROM data to VRAM (done only if ROM is visible, and only if it wasn't already relocated), so the relocated data should show up in later crashes (which have working video output)... But that VRAM relocation didn't work out a single time yet. Maybe VRAM isn't writeable during early boot period, or maybe the DSi just refused to enter my crash handler during early boot. Slowing down the clock might be also useful. For avoiding ROM-disable it shouldn't be required (normally, the DSi should load hundreds of kbytes from eMMC before disabling ROMs, so there should be a fairly huge window for crashes, probably huge enough to trap the crash manually via push-buttons). The ARM7 might have a smaller window because it can overwrite the 3FFFFDCh vector regardless of the main ram /WE signal. So, if somebody finds a way to crash ARM7, then slowdown might become useful. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 52/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Okay, I give up for now. I didn't get ARM7 crashed at all. And only got ARM9 crashed shortly after the ROMs were disabled. Just some final notes...
VDD33 didn't get me anywhere, just lowering it a little causes the power managment device to shut down the power supply (though there should be a way to rewire to board to lower only the CPU supply, still making the power managment device to think that everything is fine). VDD18 seems to have very low power consumption during boot, the boot code is still working when passing it through 220 ohms (whilst in later boot/game stages the console produces some scratch sound and hangs when passing it through maybe 10-50 ohms), maybe values higher than 220 ohm would do something during boot; though getting VDD18 to low may also erase the crash vector in main ram, at least when applying the lower voltage to ALL chips for too much time. I didn't manage to crash the ARM7 directly, however, there's a way to get control of the ARM7 from within the ARM9 crash hander (after boot ROMs are disabled): The ARM7 is executing code in WRAM, and the WRAM control is granted to ARM9 side (via port 4004060h), so the ARM9 can map custom code to the ARM7, it's working more or less stable (and maybe it'd work perfectly stable when finding some opcodes that can be executed in both ARM and THUMB mode). Being able to run code on ARM7 is nice for reinstalling the 3FFFFDCh crash handler (for further attempts to crash ARM7 directly). And, it's allowing to test the behaviour of the normal disabled SCFG registers on ARM7 side, or to access the SD/MMC ports, eg. for installing dsiwarehax (without needing to wire the eMMC chip to a PC card reader; of course one would still need some soldering for the crash, but it be slightly easier than the card reader approach) (I haven't tried if the power managment device survives shortcutting VDD12 to GND, but if it does, then one could theoretically hack the console with a paper clip, without resistors or soldering). And of course, one would still need some exploited DSi cart like biggestloser to install the crash handler (or a NDS cart, when GNDing the upper two main ram address lines for mirroring the 2FFFD9Ch vector to 23FFD9Ch). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 53/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Bit31 should be mainly related to Secure Area (KEY1 commands), but possible that it does also affect the cart header...
For original NDS carts (without DSi features) it doesn't really matter since the NDS header is less than 200h bytes (it should be zeropadded to 1000h bytes, but there's no official code (from Nintendo) for reading that much of header data for NDS carts). What I am doing for reading both NDS and DSi cart headers is always setting ROMCTRL to AC3F1FFFh (=read 1000h bytes at once). From what I remember, that setting was required for some NDS cart headers (eg. for Tony Hawk's Sk8land). And I've also used it for dumping two DSi titles (System Flaw and Cooking Coach, one of them having Bit31 set, the other doesn't). So I guess the 1000h-byte read mode should work for ALL cart headers, no matter if Bit31 is set, and no matter if it's a NDS or DSi title. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 54/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Just some more notes...
I've meanwhile got the ARM9 crashed hundreds of times - but only AFTER the bootrom stage. The reason is probably that Main RAM (=including the Undefined Instruction exception handler) isn't enabled during bootrom stage (it seems that Main RAM gets enabled by setting EXMEMCNT.bit13 at the begin of the 2nd boot stage). One thing that might work is getting an unstable ARM9 opcode to jump to a "wrong" memory address (for example, ITCM and New WRAM are known to be enabled at some point during bootrom stage, and VRAM might be also enabled; at least when displaying HEX error codes upon boot errors). That approach would probably require to reboot the console hundreds or millions of times, until eventually getting it to do what it should do (and making sure that the auto-crash-reboot procedure stops at that point). And ARM7... it seems to be possible crash ARM7 by holding the supply voltage low for some LONG time (about a second or so). But I've never managed to get that effect to occur during bootrom stage... For doing so, one might need to start lowering the supply voltage a while before rebooting, but even then: no luck so far. It's also possible that the power consumption drops during bootrom phase (so one might need some heavier pulldown to get the supply voltage lowered in that boot stage). Ah, and some notes from derrek (who dumped the 3DS bootroms using some similar approach): * Desoldering the CPU's capacitors might help (that is: those very tiny (almost invisible small) capacitors "under" the CPU / on the PCB's "back" side). * Spraying all kinds of RAMs with jump opcodes might help (rather than relying only on the exception vectors). * And using some FPGA to control the glitches & stuff might also help. Of those, I didn't try the capactitor desoldering. In later tests I have sprayed most of the RAMs (with ARM+THUMB code), and used a PC parallel port (and some transistors) to control the reset signal & supply voltage (not as accurate as an FPGA timing wise, but maybe timing isn't too critical when just intending to crash the CPU via unstable/random conditions; ie. one could only guess when ITCM and New WRAM are getting enabled anyways). Ah, and I've used the RTC signals for transferring data to PC, that's been working fine (but to be actually useful, one would need to manage to crash the ARM7 during bootrom stage). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 55/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Time to uninstall your wanna-be virus scanners: http://problemkaputt.de/gba.htm ; )
Major news is heavily extended documentation - including for some first specs on the TeakLiteII processor. The built-in assembler does now support both Xtensa (Wifi) and Teak (DSP) assembler source code, so it's now actually possible to run hardware tests on that processors (not that I would expect anybody to do such things, so just forget about it). Other weird stuff includes the DSi memory dumper - most recent version is released here: http://gbatemp.net/threads/dswifi-asm-port-and-bugs-in-dswifi-hll-version.447174/#post-7009852 - to my knowledge, that's the first tool ever that could dump the DSi/3DS camera device ID's, the newer Wifi-ROMs and such stuff (again, just forget about it, the program must be in run in DSi mode, and there are currently only 2-3 people who could do such things). Anyways, the good news is that there are now wide parts of the DSi hardware documented, and that we could theoretically start to reverse-englneer the remaining unknown details at some day in future. 11 Feb 2017 - version 2.8e
- gba/bugfix: forces WAITCNT.15=readonly (for DKong:KingOfSwing, thanks endrift) - dsi/teak/a22i: added TeakLite II assembler (supports most TL+TL2 opcodes) - dsi/teak/help: specs for teak cpu flags (which opcodes affect which flags) - dsi/teak/help: specs for memory mapped I/O ports on teak/dsp side - dsi/teak/help: specs for teak CPU registers, details for operand encoding - dsi/teak/help: specs for teak st0-2,icr plus undoc stt0-2,mod0-3 - dsi/emmc: detects/supports debug-version eMMC images (tweaks port 4004024h) - dsi/help: cleaned up some RSA descriptions, notes on debug-version RSA keys - dsi/help: first attempts on describing SCFG_xxx registers for ARM7 side - nds/wifi/help: added details on ds-download-play's openpgp-rsa-sha1 signature - dsi/boot: mimmicked support for booting with AR6013 (when WifiFlash[1FDh]=2) - dsi/dsdump: released dumping tool for dsi memory areas and chip IDs - nds/wifi: released dswifi ASM port (and bugfixes for original dswifi-library) - dsi/wifi/a22i: added assembler support for atheros/xtensa instruction set - dsi/wifi/disass: fixed bugs for ANY/ALL/4/8 and EXTUI-based SHR pseudo-opcode - bugfix: handles 16bit (not 32bit) return value of GetKeyState/GetAsyncKeyState - nds/wifi/help: added note on W_IF acknowledging for counter half-overflows - dsi/tmd/help: added age ratings and public/private .sav entries in .tmd specs - dsi/devicelist/help: added DSi SD/MMC Device List chapter (for carthdr[1D4h]) - dsi/startdirect: initializes device list, aes keys, etc. (still imperfect) - fontfile/help: more info on dsi font file (compression, nitrofont, characters) - lz/help: added pseudo code for lzss, lz11, and lzrev decompression - bootinfo/help: SHA1 WifiFlash[00h..27h] and eMMCBootInfo[00h..FFh,180h..1FFh] - whitelist/help: info on RSA-SHA1's, SHA1-HMAC's and missing RSA check in v1.4E - flipnote/help: info on various flipnote files, rsa, md5, xor-encryption - rsa/help: added info on rsa basics, rsa pseudo code, rsa big-endian format - rsa/help: added note on SWI 23h using OpenPGP Message Format (RFC 4880) - rsa/bios: 80x86 dsi bios clone supports RSA bios functions (SWI 20h..23h) - nds/bugfix: disables dsi I/O ports in DS mode (avoids misdetecting DS as DSi) PS. "we" is the hacking community, but I don't know where it is. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 56/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I think that I've solved the Wifi SPI FLASH myth. Either that, or I am making a fool of myself.
Newer DSi's and 3DS's are having a smaller SPI FLASH chip on the wifi board. From what I got told, the chip capacity is exactly the amount of writeable memory needed for storing settings & calibration data. If that's true then Nintendo has somehow manufactured a custom FLASH chip with NDS-compatible 24bit address bus and 3.75Kbyte capacity for cost-down reasons. Might be so. But the theory always smelled like bad research to me. One known thing is that the newer SPI FLASH chips have different package & pinout than older chips. Now I've recently discovered that the new pinout does match-up with W25D40 chips, and that those 25xxx chips are using different SPI write commands (and do also require additional erase commands, which wasn't needed on the 45xxx chips used in NDS and early DSi's). So the new theory is: Nobody has ever successfully written any data to the new FLASH chips, hence making it impossible to know whether the chip capacity is 3.75Kbytes, or if it's 128Kbytes, or even 512Kbytes, or the like. To prove that I am wrong isn't possible. The problem is that even old NDS titles from 2005 appear to be made forwards compatible with 25xxx FLASH chips (though maybe very early titles from 2004 aren't, which would make them unable to store Wifi access point settings on consoles with 25xxx FLASH chips). The only other option would be examining the actual hardware, ie. to try to write to the FLASH memory, or to read its chip ID. But I suspect that the DSi and 3DS homebrew scenes aren't yet remotely able to accomplish such things. Or well - you can prove that I am wrong on that part : ) |
| nocash |
| ||
|
Normal user Level: 20 Posts: 57/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Guess I made a fool of myself : )
DSi launcher 1.4E does support 25xxx chips on ARM7 side: 0376D0A0 EA00000C b 376D0D8h ;@@spi_flash_func_00h_write_enable
But, ARM9 side seems to use only a few of those functions:0376D0A4 EA00000D b 376D0E0h ;@@spi_flash_func_01h_write_disable 0376D0A8 EA00000E b 376D0E8h ;@@spi_flash_func_02h_get_status 0376D0AC EA000010 b 376D0F4h ;@@spi_flash_func_03h_read_data 0376D0B0 EA00001F b 376D134h ;@@spi_flash_func_04h_fast_read_data 0376D0B4 EA00002E b 376D174h ;@@spi_flash_func_05h_write_45xxx_cmd_0Ah 0376D0B8 EA00003F b 376D1BCh ;@@spi_flash_func_06h_write_25xxx_cmd_02h 0376D0BC EA000050 b 376D204h ;@@spi_flash_func_07h_erase_100h 0376D0C0 EA00005D b 376D23Ch ;@@spi_flash_func_08h_erase_10000h 0376D0C4 EA00006A b 376D274h ;@@spi_flash_func_09h_enter_deep_power_down 0376D0C8 EA00006B b 376D27Ch ;@@spi_flash_func_0Ah_release_deep_power_down 0376D0CC EA00006C b 376D284h ;@@spi_flash_func_0Bh_erase_whole_chip 0376D0D0 EA000078 b 376D2B8h ;@@spi_flash_func_0Ch_get_jedec_chip_id 0376D0D4 EA00007A b 376D2C4h ;@@spi_flash_func_0Dh ... padding? 026C27D6 4905 ldr r1,=3002000h ;IPC for "@@spi_flash_func_00h_write_enable"
So the 25xxx code seems to be just garbage where they've linked in some library containing several unused functions.
026C27F2 4905 ldr r1,=3002100h ;IPC for "@@spi_flash_func_01h_write_disable" 026C2810 4913 ldr r1,=2002200h ;IPC for @@spi_flash_func_02h_get_status 026C2876 4923 ldr r1,=2002300h ;IPC for "@@spi_flash_func_03h_read_data" 026C291A 491D ldr r1,=2002500h ;IPC for "@@spi_flash_func_05h_write_45xxx_cmd_0Ah" 026C2996 4905 ldr r1,=3002D00h ;IPC for "@@spi_flash_func_0Dh ... padding?" Going by the photos on http://dsibrew.org/wiki/WiFi_Module the flash chip is marked "5A32", if there's any meaning behind it then the "5" might translate to 25xxx, 45xxx, or 95xxx flash/eeprom families. And the "32" might refer to 32Kbits (=4Kbytes) or 32Mbits (=4Mbytes). The latter one would be nice - but it's quite unlikely that they've used a chip with that capacity. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 58/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Version v0.6: added write-protect flag to the .tmd file (avoiding Data Managment to delete it). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 60/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 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: ;/ |
| Main - Posts by nocash |
|
Page rendered in 0.103 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 96/96, time: 0.006 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
