|
| ||
| Views: 1,610,082 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-23-24 08:15 AM |
| Guest: | ||
| Main - Posts by nocash |
| nocash |
| ||
|
Normal user Level: 20 Posts: 21/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Did anybody already dump the SPI bus FLASH memory on newer DSi consoles (with AR6013G wifi chip), or on 3DS consoles?
The original DSi (with AR6002G wifi chip) used 128Kbyte FLASH chips (ST 45PE10V6, with chip ID 20h,40h,11h). Later DSi's are said to have "less" than 128Kbyte, but as far I know, it isn't yet know how much memory they have, nor which chip ID they have. There are probably also some differences in the header region. The byte at offset 1FDh appears indicate the wifi hardware version: 01h = DWM-W015 with AR6002G (old DSi)
02h = DWM-W024 with AR6013G (newer DSi) unknown = DWM-W028 with AR6014G (3DS) unknown = New3DS And the byte at offset 01Dh seems to indicate the console type: FFh=Nintendo DS
20h=Nintendo DS-lite 57h=Nintendo DSi 43h=iQueDS 63h=iQueDS-lite unknown=3DS unknown=New3DS There might be some further differences to be expected. For example the wifi/channel calibration might consist of dummy values (assuming that newer AR60xx chips are merely emulating the old NDS-style channel selecting, without actually containing a real Mitsumi chip on die). NB. I've also found a copy of the new I2C bus EEPROM calibration data whem dumping the AR6002G chip's RAM, the data is 300h bytes in size (leaving extra 100h bytes unused). Haven't yet figured out the meaning of the calibration values, but it's also containing a copy of the 48bit MAC address; the same value as found in SPI bus FLASH chip). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 22/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Hmmmm, no issues importing JPEGs to 3DS? A while ago, I've read this: http://www.hjort.co/2011/09/transferring-photos-to-nintendo-3ds.html and that sounded as if would be difficult to import images.
Maybe Nintendo dropped that restriction in more recent firmware revisions, as it's been only annoying people and could have been bypassed via the browser trick anyways (?) Or maybe it's been really just a filename issue all the time ;- ) apart from needing to follow the filename notation, the files must be also listed in "pit.bin" on DSi (ie. one could replace existing files with same name, but couldn't add new files with different names). Now I am wondering if the DSi did really ever have had any issues, too... Just tried... Yes, the DSi does refuse even minor modifications of photos taken on DSi. I've used the above sample image from dsibrew (and verified that I can view the original image on my DSi). Then I changed the three date strings from "2009:05:23" to "2009:05:24" in a hex editor, and, after that change, the DSi does just display "?, Cannot display image". My DSi has some portions of the firmware downgraded, but the DSi Camera utility should be from most recent firmware upgrade. EDIT: Since the time/date is also stored in pit.bin, I've restored the original date (caused the file to work on DSi) and then changed "EINH" to "PINH" (caused the "?, Cannot display image" to occur again) |
| nocash |
| ||
|
Normal user Level: 20 Posts: 23/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I've been just wondering why the "4Ds-dev" logo is loading so slowly. There seems to be something wrong with the filesize:
193Kbyte = current "4ds.png" file
Looks as if the 193K file contains plain uncompressed 32bit RGBA pixels, ie. 491*100 pixels * 4 bytes.145Kbyte = same image saved as ".bmp" file via IrfanView at 24bpp 50Kbyte = same image saved as ".bmp" file via IrfanView at 8bpp 38Kbyte = same image saved as ".png" file via IrfanView 18Kbyte = same image saved as ".gif" file via IrfanView |
| nocash |
| ||
|
Normal user Level: 20 Posts: 24/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by Yoshi Okay, so the 3DS appears to store DSi-compatible signatures in the JPEGs. EDIT: Or did you mean that you've tested it... and the test has FAILED? Yes, would be great if you could upload a photo taken on 3DS somewhere, just to see if the signature is really there, and if they have changed the "NintedoDS" string to "Nintendo3DS" or the like. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 25/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I've found the CardIRQ signal; triggered when dragging /IRQ (aka Data1 pin) to LOW. The thing require an ENABLE bit, and a DISABLE bit, and correct settings in PORT_SELECT and CLK_CTL registers - so that explains why nobody has figured out how to receive those /IRQ yet; just trying to enable it by setting or clearing all bits won't work.
Alongsides, I've found four other (rather weird) IRQ sources: 4004836h/4004A36h - SD_CARD_IRQ_STAT (R/ack)
4004838h/4004A38h - SD_CARD_IRQ_DISABLE (R/W) IRQ Flags/Write (0=Acknowledge, 1=No change) IRQ Flags/Read (0=No IRQ, 1=IRQ) IRQ Mask (0=Enable, 1=Disable) (C007h when all IRQs disabled) Bit Stat Mask Function 15 undoc undoc SomeIRQ (triggered SOMETIMES on forced CMDTIMEOUT?) 14 undoc undoc SomeIRQ (triggered near DATAEND?) 13-3 0 0 Always zero 2 undoc undoc SomeIRQ (triggered on forced TXUNDERRUN?) 1 undoc undoc SomeIRQ (triggered about once per datablock?) 0 CINT0 CIMSK0 CardIRQ (triggered by /IRQ aka Data1 pin; for SDIO devices) All stat bits (except bit1) are triggered only if enabled in SD_CARD_IRQ_ENABLE. Bit0 is actually used (for SDIO hardware), the other bits aren't used by existing software (they don't seem to be useful; purpose might be error testing, or forcing commands to abort). 4004834h/4004A34h - SD_CARD_IRQ_ENABLE (R/W) CardIRQ Enable works only when also writing SD_CARD_PORT_SELECT.bit10=0 and only with valid SD_CARD_CLK_CTL setting. 15-10 Always zero 9 Enable setting SD_CARD_IRQ_STAT.bit14 and cause nothing special? (R/W) 8 Enable setting SD_CARD_IRQ_STAT.bit15 and cause CMDTIMEOUT? (R/W) 7-3 Always zero 2 Enable setting SD_CARD_IRQ_STAT.bit2 and cause TXUNDERRUN? (R/W) 1 Always zero 0 Enable setting SD_CARD_IRQ_STAT.bit0 (CardIRQ upon Data1=LOW) (R/W) Bit9 is autocleared at time when bit9 causes setting SD_CARD_IRQ_STAT.bit14. Bit2 is autocleared shortly before bit8 causes CMDTIMEOUT. SD_CARD_IRQ_STAT.bit15 is set only when setting bit8 AND bit2 DURING cmd/xfer. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 26/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Any news? First lots of people posted about JPEGs... and then nobody managed to dump a JPEG from 3DS? Are there tech problems?
I could supply some tutorial on How-to-export-JPGs-on-DSi (if that should be really needed, but don't know if that info would apply on 3DS, too). Does the 3DS support copying .JPGs to SD card at all? Or does it only allow to export .MPO's? For uploading a 3DS .jpg, http://dsibrew.org might be a good place (since the forum doesn't seem to support attachments, and http://3dbrew.org seems to be blocked via some obscure captcha). PS. seeing a .MPO file from 3DS would be also interesting. Are that files compatible with JPG viewers (eg. allowing to see the "left" half as normal 2D image)? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 27/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Thanks for the info on the Brain Age Express Sudoku banner.sav! I was half expecting the file to be 23C0h or 4000h bytes in size (since DSi is often rounding up filesizes to 16K cluster sizes).
I didn't expect the file to contain only 11A0h actually bytes though. The normal 23C0h-byte Icon/Title structure contains an additional non-animated icon, and several title strings, which don't exist in the banner file. The 2 bytes at 0008h contain a CRC, and the other stuff is same as the animation data in normal Icon/Title. With everything puzzled together, my new description for the gbatek doc looks as so: FAT16:\title\000300tt\4ggggggg\data\banner.sav ;if carthdr[1BFh].bit2=1
Some DSi games are having a separate "banner.sav" file stored in the eMMC filesystem, enabled via carthdr[1BFh].bit2 (allowing to indicate the game progress by overriding the default icon). The banner files are 4000h bytes in size, the animation data is same as above, but without title strings and without non-animated icon. 0000h 2 Version (0103h) 0002h 6 Reserved (zero-filled) 0008h 2 CRC16 across entries 0020h..119Fh (with initial value FFFFh) 000Ah 16h Reserved (zero-filled) 0020h 1000h Icon Animation Bitmap 0..7 (200h bytes each) ;\same format as 1020h 100h Icon Animation Palette 0..7 (20h bytes each) ; in Icon/Title 1120h 80h Icon Animation Sequence (16bit tokens) ;/ 11A0h 2E60h Garbage (random values, maybe due to eMMC decryption) The feature is used by some Brain Age Express games (for example, Brain Age Express Sudoku: 'title\00030004\4b4e3945\data\banner.sav'). The feature does probably work only for DSiware titles (unless there are any DSi carts with SD/MMC access enabled; or unless there is a feature for storing similar data in cartridge memory). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 28/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
I have more or less solved that problem. With current exploits, I have no way to verify my conclusions on real hardware - but at least I got it emulated well enough to satisfy the firmware and to get through the firmware boot process.
The main issue is that the "Power State" bits are read/write-able, but, after writing "3", the hardware seems to be automatically changing the written value to "0". 4004010h - DSi9 - SCFG_MC - Memory Card Interface Status (R)
4004010h - DSi7 - SCFG_MC - Memory Card Interface Control (R/W) 0 1st NDS Slot Game Cartridge (0=Inserted, 1=Ejected) (R) 1 1st NDS Slot Unknown/Undocumented (0) 2-3 1st NDS Slot Power State (0=Off, 1=PrepareOn, 2=On, 3=RequestOff) (R/W) 4 2nd NDS Slot Game Cartridge (always 1=Ejected) ;\DSi (R) 5 2nd NDS Slot Unknown/Undocumented (0) ; prototype 6-7 2nd NDS Slot Power State (always 0=Off) ;/relict (R/W) 8-15 Unknown/Undocumented (0) 16-31 ARM7: See Port 4004012h, ARM9: Unspecified (0) NDS-Slot related. Bit3 (and maybe Bit2) are probably R/W on ARM7 side (though the register is disabled on ARM7 side in cooking coach exploit, so R/W isn't possible in practice). Note: Additionally, the NDS slot Reset pin can be toggled (via ROMCTRL.Bit29; that bit is writeable on ARM7 side on DSi; which wasn't supported on NDS). Power state values: 0=Power is off 1=Prepare Power on (shall be MANUALLY changed to state=2) 2=Power is on 3=Request Power off (will be AUTOMATICALLY changed to state=0) power_on: wait until state<>3 ;wait if pwr off busy? exit if state<>0 ;exit if already on? wait 1ms, then set state=1 ;prepare pwr on? or want RESET ? wait 10ms, then set state=2 ;apply pwr on? wait 27ms, then set ROMCTRL=20000000h ;reset cart? or rather RELEASE reset? wait 120ms ;more insane delay? power_off: wait until state<>3 ;wait if pwr off busy? exit if state<>2 ;exit if already off? set state=3 ;request pwr off? wait until state=0 ;wait until pwr off? Power Off is also done automatically by hardware when ejecting the cartridge. Turned out that register is important even for DSiware: With cartridge marked as "Ejected", the firmware can reach the boot menu - but trying to start a DSiware title from within bootmenu doesn't work when the "Power State" bits are handled properly. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 29/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
With the DSi, nintendo invented a whitelist for older NDS cartridges, and, theoretically, they must have added stuff like RSA signatures in newer NDS cartridges...
Did anybody ever see any such cartridges with extra header entries? And did Nintendo even produce NDS games (without DSi features) after releasing the DSi at all? Note: Seeing any extra entries would probably require dumping the whole DSi-style 1000h-byte cart header (older NDS dumping utilities may be unable to do that). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 30/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Just stumbled over some detail: Port 4004800h.bit6=1 causes the SD/MMC controller to send an APP_CMD prefix... but, it doesn't seem to be possible to specify the RCA value for the APP_CMD's parameter field.
That would be no issue for MMC, since ACMD0..63 aren't used for MMC. But for SD cards, the DSi is using ACMD41, ACMD6, ACMD13 (of which, ACMD41 should be sent with RCA=0, the other two should theoretically send the card's RCA value). Does anybody know how that is working? Or does somebody have SD-bus logging hardware to see what is happening on the SD bus? Btw. I don't really understand why SD is using RCA values at all (MMC allows to share the same CMD line for cards with different RCAs, but SD specs suggest that each card must have an own CMD line, so RCA would be rather irrelevant). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 31/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Yes, "Nitro cards" from 2009 or later. I am quite sure that they do exist and that they do have an extended header (else they couldn't be played on DSi or 3DS), but I don't know of anybody having observed (and documented) their header format yet.
If currently available tools aren't allowing to dump the whole 1000h-byte header, then even the incomplete 160h-byte header might contain some interesting stuff: There's probably a flag in there for indicating the presence of the extended header - so one could at least use that flag to detect incompletely dumped ROM-images... assuming that all currently existing ROM-images that have that flag set are incomplete dumps. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 32/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
libnds should contain code for both DS and DSi modes (that code will require "low level" access to SPI bus).
don't know if 3DS comes up with a different mode, just try the DSi code. If it works, then DSi and 3DS are apparently accessing it the same way. calibration data could be read in DS fashion (from wifi flash), but there should be also a 3DS specific config file containing the same calibration values (probably also stored somewhere in RAM). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 33/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Released no$gba v2.8c yesterday: http://problemkaputt.de/gba.htm
The emulator/debugger can now boot the firmware bootcode from scratch, and passes through wifi init, and allows to start games from within bootmenu. The main requirement is having the DSi BIOS ROM images, and a DSi eMMC image. And activating DSi emulation in no$gba setup, and deactivating the Start directly option. Yeah, needing to change that options is a bit uncomfortable, but I guess that there aren't more than a dozen of people having the ROM/eMMC images anyways - I hope those few people will somehow figure out how to get the emulation working (or let me know if not). The built-in help text (and gbatek.htm document) contain loads of new info about the DSi hardware and sd/mmc files. One huge news is documenting the teak instruction set (thanks to normatt for creating a list of all 65536 opcode combinations). The 'small' remaining problem is that the teak memory map (and supposedly existing teak I/O ports) are still unknown. And a very huge news is lots of info about the atheros wifi hardware and wifi firmware... there are lots of new chapters for wifi hardware registers, and lots of more chapters for wifi software protocol... I am hoping that those new chapters are covering almost each and every aspect of the wifi unit - except, one basic detail is still missing: I've no idea how to transfer any data packets. ---- 07 May 2016 - no$gba version 2.8c - webpage: added some dev forum links (http://4dsdev.org and http://gbadev.org) - help: added "us" to known dsi-regions (including its countries and languages) - dsi: re-ordered wram as C-then-B (fixes 3780000h boundary issue on us/sysmenu) - dsi/wifi/help: added specs for WMI commands/events (and for BMI boot-commands) - dsi/sdmmc/help: added sd/mmc state info (specs when/which command can be used) - dsi/softreset: allows rebooting dsi firmware via NUM-* (reinit DSi registers) - dsi: can boot NDS games from within DSi mode (tweaks non4MB via fake_scfg_ext) - dsi: supports NDS-backwards-compatibility-touchscreen mode (for NDS games) - dsi: supports NDS-bios-mapping in DSi mode (for NDS games booted via sysmenu) - dsi: supports firmware-coldboot (when bios_intro enabled with nds_mode=DSi) - dsi: bugfixed jumps in new wram via addr_code_table (fixes many DSi problems) - dsi/help: added DSi Atheros Wifi I2C EEPROM info (access and partial content) - debug/gui: fixed system colors used for cpu-flag checkboxes (swapped red/blue) - dsi/help: added notes on dumping wifi bios, and on dumping dsi keys from 3ds - dsi/help: added flipnote fileformat, added notes on \shared2\0000 file - nds7: emulates disabled bios area being FFh-filled (define_nds7_bios_rom) - aes: forces instant completion on aes-body-len-zero (boot sysflaw via sysmenu) - sdio/wifi: initializes 0500458h to ZERO (indicating not firmware yet uploaded) - dsi/bugfix: moved "sdmmc_try_drain_write_buffer" after status/state handling - dsi: wifi init mimmicked good enough to run bootcode without WLFIRM 2 error - dsi/sdmmc: supports card_irq - dsi/i2c: omits ACK response on non-existing devices (especially A0h/E0h cams) - dsi/misc: omits arm7 warning on 4004001h access, sets DSi flag in cart.chip.id - dsi: emulates SCFG_MC register (else hangs after starting a game in bootmenu) - xtensa: auto-resolves special registers mov opcodes to symbolic sfr_xxx names - dsi/loader: supports loading AR60xxG.rom (for disass at atheros:8E0000h) - dsi/mapping: supports MBK mapping to TEAK memory space (for teak disassembler) - dsi/sdmmc: supports WRITE_MULTIPLE command (requires eMMC image with CID+ID) - dsi: supports 32bit 4004D00h read, and more 16bit/32bit access for other ports - dsi/jpeg/help: added notes on computing jpeg/exif MAC signatures (via AES-CCM) - dsi/sdmmc: emulates fifo16/fifo32, irq-edge-triggering, fixed bits, etc. - dsi/help: added lots of details on sd/mmc/sdio controller's I/O ports - dsi/help: updated dsi exploits chapter (notes on resurrected dsiware hax, etc) - dsi/help: addded teak instruction set specs (encoding, syntax, params) - dsi/help: added atheros/wifi registers specs (for sdio side and xtensa side) - dsi/debug: added teaklite II disassembler (see menubar, window, teak) - dsi/wifi/debug: added xtensa disassembler (see menubar, window, atheros) - dsi/wifi/help: added xtensa/cpu instruction set and xtensa/cpu register map - dsi/sdio: partial sdio/atheros simulation (passing most of "PRE-AUTH" phase) - dsi/help: added sdio specs (cmd52/cmd53 and cccr, fbr, cia areas) - dsi/boot: fixed initialization of emmc-info in main ram - dsi/help: added various details (initial ram, etc.) - nds/debug: optional IPC fifo send/recv logging (in tty debug message window) - dsi/bptwl: supports writing BPTWL registers (except invalid/readonly ones) - debug/tty: displays sd/mmc command names, and resolves sdio func:addr's - debug: accepts mirror of 3800000h at 3FF0000h without warning (common on dsi) - dsi/help: details on tmd, tickets, and big-endian aes-cbc decryption |
| nocash |
| ||
|
Normal user Level: 20 Posts: 34/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by Normmatt Oops, thanks! Fixed it. Posted by Normmatt That message is shown when decrypting something with an AES keys that consists of all zeroes, which normally shouldn't happen - unless the key is "missing" somehow (like due to incomplete BIOS ROM image; there is some info in gbatak about which areas of the DSi BIOS can be dumped: http://problemkaputt.de/gbatek.htm#biosdumping ). And what exactly were you doing? Did you have the "Start cartridge directly" option disabled? If yes, then the boot process should go through these disturbing steps: - blank/white screen - health/safety screen - bootmenu with icons There should be no "aes key zero" message during that steps (nor when clicking an icon). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 35/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Error: 1-2435-8325 is said to be "Invalid signature or partition type in MBR, invalid starting LBA"... ie. some problem decrypting eMMC data. The message is thrown by the code in eMMC bootsector, so it looks as if you DO have an eMMC image, and the bootsector loading step seems to have worked okay.
Do you have the Footer (see "DSi SD/MMC Images" chapter in no$gba) appended to the eMMC image? Most of the eMMC data (except bootsectors) need the console IDs from the footer for decryption. Posted by Normmatt Yes, but the main issue there is that I don't have the external SD card emulated at all yet. Current version supports only the sd/mmc commands for internal eMMC storage. Posted by Normmatt Hmmmm, did you dump the file from real Wifi FLASH chip on real wifi daughterboard? And is it from a DWM-W015 or DWM-W024 board? And is it from a 128Kbyte FLASH chip, or from one of those "smaller" FLASH chips? DWM-W024 would have wifi type "02h" at flash offset 001FDh, causing the DSi to try to load the AR6013G wifi-firmware (problem is there is that I don't have one of those newer wifi boards, and so, can't really emulate that hardware revision). And the "smaller" FLASH chips, I don't have one of those too, and don't even know what size they have. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 36/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by Opposing Force Would depend on how much data you've dumped: The TCM/WRAM areas (from DSi main ram hack), or the TWL area (from 3DS), or (ideally) a combination of that dumps. Here are CRC32's for the separate dump-able areas (you can use the "HxD" hex editor to compute CRC's on selected areas, for example), and the final CRC32's for the 'whole' file (as far as memory is dump-able yet)... Checksums for BiosDSi.rom (20000h bytes)
Offset Size CRC32 00000h 8000h 5434691Dh ;\ 08000h 188h ? ; 08188h 180h E5632151h (not 3ds) ; 08308h 80h 64515306h ; 08388h 3250h ? ; 0B5D8h 20h 85BE2749h ; ARM7 0B5F8h 10h 180DF59Bh (3ds only) ; 0B608h 10h E882B9A9h ; 0B618h 10B8h ? ; 0C6D0h 1048h 3B5CDF06h ; 0D718h 1048h 5AC363F9h (not 3ds) ; 0E860h 18A0h ? ;/ 10000h 8000h 11E7C1EAh ;\ 18000h 7F4h ? ; 187F4h 200h 4405D4BAh ; 189F4h 200h 2A32F2E7h (not 3ds) ; 18BF4h D2Ch ? ; ARM9 19920h 80h 2699A10Fh ; 199A0h 1048h A8F58AE7h ; 1A9E8h 1048h E94759ACh (not 3ds) ; 1BA30h 45D0h ? ;/ ? A0h 180DF59Bh (3ds only) ;-whatever, "Nintendo" string etc. Checksums for the 'whole' 20000h-byte file (with unknown/missing areas zerofilled): 180DF59Bh (tcm/ram dump) (missing 10h bytes) 03A21235h (3ds dump) (missing 180h+200h+1048h+1048h bytes) CDAA8FF6h (combined dump) (missing only the unknown "?" areas) For dumping the complete ROMs (without decapping), one could theoretically install debug exception vectors in RAM, and then reset the DSi, and then do something to provoke a debug exception (like sinking the power supply, or heavily overclocking the CPU for a moment - and then hoping that the CPU will react by throwing an invalid opcode exception). Don't know how difficult it would be to do that - and if it would really succeed. That possibly approach has been mentioned somewhere else, but I guess nobody has ever actually tried doing that yet? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 37/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
About the 3rd question: That stuff seems to be defined in RFC 2313:
A block type BT, a padding string PS, and the data D shall be
As far as I understand, the leading 00h is intended to avoid overflows on large interger maths, the BT block type is always 01h on DSi, the following PS padding consists of FFh's on DSi (as defined for BT=01h), padding does then end with the trailing 00h, then followed by the actual data (usually a 14h-byte SHA1 value on DSi).
formatted into an octet string EB, the encryption block. EB = 00 || BT || PS || 00 || D . The DSi BIOS decrypt function doesn't return the leading 00h, but internally RSA seems to work as if the 00h would be there. So, to make an unencrypted 80h-byte signature, one could just follow that notation (ie. adding a leading 00h to the 7Fh-byte signature). Or am I missing something, and that wouldn't be the optimal format for unencrypted signatures? Plans for next no$gba version are supporting unencrypted signatures in that fashion - so that people could create "authentic" DSi homebrew games or system files that are compatible with the original firmware. One would still need Nintendo's private key to get that files working in real hardware, but in an emulator one could just hook the BIOS RSA functions (ie. detecting if the signature contains the unencrypted "00 || BT || PS || 00" values, and if so, just copy the signature as-is instead of trying to decrypt it). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 38/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
For SD Card emulation, does somebody know a utility for creating empty SD/SDHC Card images (with MBR and FAT)?
A .zip with several empty SD/SDHC Card images (with different sizes) would be nice, too. For testing, I would currently need some small image with 16MB or so. But bigger images with more MB or GB might be also useful at some point. Hmmmm, aside from the raw image, I would also need to have (or create) the ID/capacity info stored in CID, CSD, OCR, SCR registers. Preferably with authentic values that could be also found on real SD/SDHC cards with same capacity. I am afraid that there's no utility (or dataset) for getting that values, or is there something... maybe in another emulator that emulates SD cards? The other option would be dumping the SD card image AND the CID/CSD/etc from real SD cards. I have some 128MB, 1GB, 2GB, 4GB cards around - so I could dump those cards. The advantage would be getting real authentic values. The disadvantages would be not getting clean/empty images (if the original card wasn't empty). And, when releasing no$gba with SD Card support, it would appear quite foolish to prompt users to create the SD card image "by dumping a real SD card". Posted by Normmatt Would be nice, but probably very difficult to find somebody who has the required hardware & software & knowledge on using it - for at least confirming if ROM dumping is possible or not. But yeah, would be great if somebody could check that! |
| nocash |
| ||
|
Normal user Level: 20 Posts: 39/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Posted by gudenau That tools are available for windows? If not: no$gba is a dos/windows utility, so prompting users to install linux for creating no$gba sd-card-images would be a bit weird ;- ) I've meanwhile dumped the MBR, FAT, and CID, CSD, OCR, SCR registers from my 128MB SD card, so I've at least some values to start with - and could probably modify them to simulate other SD card capacities (and hope to get that right). Btw. I've been always wondering if it's possible to use more than one SD card. For MMC cards, multiple cards are handled via the ALL_SEND_CID command (CMD2): Upon that command, the card with the smallest CID number is switched to "ident" state (and any other cards stay in "ready" state until sending futher CMD2's). For SD cards, CMD2 does exist too. But the public SD card specs appear to refuse to mention if it's supporting multiple SD cards in same fashion as for MMC. But just came across this datasheet, http://www.altec-cs.com/downloads/Produkte/Flash_Speicherkarten/SD_Cards_miniSD_microSD/SanDisk_SD_Card_I-G_PM_1.0.pdf - which says "The host repeats the identification process (i.e., the cycles with CMD2 and CMD3 for each card in the system)." It doesn't really say WHAT happens upon CMD2, but it sounds as if CMD2 might be actually working as on MMC. Did anybody ever try such a thing? Would be interesting if it's working technically (although I doubt that the DSi firmware/games support it). I'll need to gather components for making some SD/MMC Y-cable. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 40/77 EXP: 39006 Next: 3433 Since: 10-09-15 Last post: 2099 days ago Last view: 2015 days ago |
Don't know why, too. Or well, I just want to understand the SD/MMC protocol (and to get it documented in gbatek.htm). And the SD specs do contain some sentences that hint on supporting multiple SD cards (with different RCA's), but without explaining how to wire-up and initialize multiple cards - so that's somehow shouting for reverse-engineering.
In practice it would be rather clumsy and useless to attach an Y-cable to the DSi, and one could probably buy a SD card with bigger capacity at the same price as using two smaller cards with Y-cable. |
| Main - Posts by nocash |
|
Page rendered in 0.160 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 96/96, time: 0.010 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
