#169355 - scanlime - Mon Jul 06, 2009 7:23 am
So, I've had the DSi for little more than a week, and already I can't resist opening it up in an attempt to help the cause of DSi homebrew. I'm new to the DSi homebrew community, so I'm not entirely sure what the state of the art is.. but as far as I can tell, very little of the differences between DS and DSi hardware are documented, and nobody has publicly posted information about dumping the ROM from a DSi.
So I thought I'd make an attempt to dump the NAND flash. As far as I can tell, it's the only nonvolatile memory on the board. Besides all of the downloaded DSiware and saved games/settings, it must also have the firmware and the DSi menu. It might also be what the DSi boots from- though it's also possible there's a mask ROM in the CPU that bootstraps from the NAND flash. If we're really unlucky, the CPU or the boot ROM may decrypt code from the NAND before running it. But, whether we're lucky or not, it still seems useful to have a dump of the NAND flash.
As mentioned on http://www.dsibrew.org/wiki/Hardware, the NAND flash is a Samsung KMAPF0000M-S998. This is Samsung's "moviNAND" series, a mobile NAND flash chip which combines an MMC controller in the same package:
http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_MoviNAND.html
There's also a part number decoder on Samsung's site. The part is 256 MByte (2Gbits * 1), 3.3v, and otherwise seems pretty unremarkable. The package is FBGA, and it appears to follow the JEDEC standard eMMC pinout. See the eMMC spec:
http://www.jedec.org/download/search/JESD84-C43.pdf
Anyway, the DSi mainboard is just covered in tasty testpoints with nice hacker-friendly labels. It seems reasonable to speculate that the NAND flash is hooked up to the system's SPI bus, especially given that there are SPI test points directly under the NAND flash chip.
So, I (carefully) disassembled my DSi, and tried to see if I could get any info from these test points. The first problem I ran into is that the DSi's mainboard doesn't want to do much unless all of its peripheral boards are attached, and you can't mechanically plug them in while retaining any access to the test points. As soon as you unplug the camera or either LCD, the DSi will hang during boot. You can't turn the DSi on if the power board is unplugged, and it won't run off of AC power if the battery is missing.
I managed to run the board stand-alone by hooking the battery test points (BT+, BT-) up to a benchtop power supply at 3.6V, and momentarily shorting the "PWSW" testpoint to ground. The DSi will hang during boot, and the only way you can even tell it's on is with a current meter.. but nevertheless I figured it should be possible to observe it bootstrapping off of the NAND flash.
I scoped out the SPI bus, and it appeared to be transmitting a single byte in an infinite loop. Ok, so I figured it was initializing some hardware and stuck in an infinite retry loop. I figured I should still see some different packets right after poweron, if it is indeed bootstrapping over SPI- but no luck. The very first byte is the same as every other.
To get some more evidence, I wired up an external connector that would provide access to the SPI bus while the DSi is fully assembled. I reassembled it, verified that it worked, then looked at the SPI bus activity with an oscilloscope while doing different things. There is good news and bad news:
The good news: The DSi cameras appear to be controlled over SPI. I haven't confirmed yet, but there is an additional chipselect line that was not present on the DS's SPI bus, and I see bursts of SPI traffic when initializing or switching cameras.
The bad news: The camera data isn't going over SPI. This is unfortunate- if the cameras were purely an SPI device, we could use them pretty easily in DS compatibility mode. I'm sure this was done for performance reasons. The DSi's SPI bus still runs at only 4MHz.
More bad news: Unlike the DS, it appears that the DSi doesn't keep its firmware on the system's SPI bus. In times when I would have expected NAND reads/writes (boot, loading and saving images in the gallery) there was little or no SPI activity. This makes sense, unfortunately. 4MHz is also a bit slow for their NAND flash, and they probably also want to make it impossible for DS-mode software to read or write NAND.
I took some pictures of the test setup:
http://www.flickr.com/photos/micahdowty/tags/dsi20090705/
I'd still like to do a proper SPI trace and see what's different between the DS and DSi, and especially take a closer look at the traffic that I think is camera-related. But it also seems that this won't help us get any closer to a firmware dump.
I think the next step might be to desolder the NAND flash and build either a passive sniffer or a standalone reader. Since it's electrically compatible with MMC, it might even be possible to solder the NAND flash onto an SD/MMC card reader, and solder an SD/MMC socket onto the DSi. Has anyone tried this yet?
It seems like a pretty invasive operation.. and FBGA doesn't seem like a lot of fun.. but if it works (and especially if the NAND isn't encrypted) it could be big step toward reverse engineering the DSi-specific hardware.
If nobody else has tried it yet, I might try and work up the courage to do this to my new DSi :)
#169366 - scanlime - Mon Jul 06, 2009 4:39 pm
After posting this, I realized: If all of the signals for the NAND flash are buried, how do they program the NAND flash at the factory?
I can think of a few possible answers:- The NAND flash is not factory programmed at all. Instead, there is a mask ROM elsewhere (like in the CPU package) which contains the initial firmware image. This seems unlikely, since it would be very expensive for Nintendo to start shipping a newer default firmware image.
- There is a bootloader contained in a mask ROM in the CPU, and they factory program the NAND via some other port. This seems a bit roundabout, but it's concievable that Nintendo did this just to make it more difficult to access the NAND flash. It could also be that they're using the flash in parallel (MMC, not SPI) mode, and they wanted a way to program it using fewer pins.
- There are test points for the NAND flash, I just need to look closer :)
It would be really cool if someone had X-ray photos of the DSi mainboard...
#169367 - Mighty Max - Mon Jul 06, 2009 4:53 pm
I think you have the wrong impression.
I personally don't own a DSi, but i would just start by reading out the flash with the functions we have already for it. (On the arm7, SPI device 1 when in DS mode) Hey, the "old" games need to access it the same way .... (i.e. when reading out the wifi ini sequence)
_________________
GBAMP Multiboot
#169368 - wintermute - Mon Jul 06, 2009 5:04 pm
That's already been done, the flash read in DS mode is empty barring the user & wfc data.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#169369 - Mighty Max - Mon Jul 06, 2009 5:06 pm
ok
_________________
GBAMP Multiboot
#169402 - ritz - Wed Jul 08, 2009 3:04 pm
I've always found this stuff very interesting and wish I had the skills to explore hardware like this. Time just never allowed for it in earlier years, so I just look over the shoulders of others now :)
Thanks scanlime and keep up the cool work!
#169403 - scanlime - Wed Jul 08, 2009 5:11 pm
Thanks for all the replies.
Sounds like nobody has a NAND flash dump of the DSi yet. I'm going to practice BGA rework a bit first, but then I think I'll try desoldering the flash chip and wiring it up to an SD/MMC card reader.
I'll let you know how it goes...
--Micah
#169474 - MechaBouncer - Tue Jul 14, 2009 9:05 pm
Before you get too deep into it, it looks like Team Twiizers have found a way to exploit the system in DSi mode and been able to dump the RAM over SPI. It may be a save-game exploit. In any case, you might want to confer with them before desoldering chips from the system board. Here's the link to the news article:
http://hackmii.com/2009/07/dsi-mode-homebrew-anyone/
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#169504 - scanlime - Sun Jul 19, 2009 12:34 am
| MechaBouncer wrote: |
Before you get too deep into it, it looks like Team Twiizers have found a way to exploit the system in DSi mode and been able to dump the RAM over SPI. It may be a save-game exploit. In any case, you might want to confer with them before desoldering chips from the system board. Here's the link to the news article:
http://hackmii.com/2009/07/dsi-mode-homebrew-anyone/ |
Thanks for the link! This is pretty cool, and definitely a step forward. But I'm still really interested in learning more about the DSi's boot process. A dump of the NAND flash would be useful, but I'm actually even more interested in getting a trace of the reads made from the NAND flash during boot.
Anyway.. I was busy with Real Life for the last few weeks, but I finally had time to revisit the DSi today :)
I managed to desolder the NAND flash, and get some PCB scans with the flash removed. It turns out that all of the interesting signals are in fact available on nearby components or vias. Here's a false-color image showing the top and bottom PCB layers near the flash chip:
http://www.flickr.com/photos/micahdowty/3732858713/in/set-72157621023570420/
The four signals along the top are data bits (this is eMMC, and the DSi is using it in 4-bit mode). The clock is available via a test point on the back (SD11_CLK), and CMD is available from a resistor nearby.
So, as fun as it was to get the flash off, I figured I'd put it back on and build a passive sniffer that can log all of the traffic between the DSi's CPU and the flash. It was a pretty nerve-wracking process, but I did manage to get the flash back on without frying it =D
I did find out what the DSi does when you try to boot it without the flash chip installed:
http://www.flickr.com/photos/micahdowty/3732858859/in/set-72157621023570420/
This would seem to confirm that there's a real boot ROM in the same package as the CPU, and they aren't just reading the SPI flash in hardware. (A hardware bootloader wouldn't be smart enough to display an error message like that.) Presumably this bootloader is also what they would use at the factory to program the NAND flash.
I also measured the clock frequency at SD11_CLK while the DSi is running. In very early boot, it runs at only 250 kHz.. but most of the time, it's running at a much more sensible 16.7 MHz.
Next step: Use an FPGA to build a protocol sniffer. I'd like to stream all of the reads/writes back to my PC over USB 2.0. This would be enough data to reconstruct the portions of the NAND flash that are actually being read during boot, and it would let us know what order the firmware is read in.
For future reference, it should also be possible to electrically separate the flash memory and the CPU without desoldering, just by cutting a few traces. Once we know more about the format of the NAND flash, it could be interesting to try installing alternate firmware by attaching an MMC card socket.
Cheers,
--Micah
#169506 - scanlime - Sun Jul 19, 2009 9:59 am
This is really really rough still, but I think I have the first dump of the DSi's NAND flash reads during boot.
The MMC commands aren't decoded much yet. The "tb=1 CMD18" lines indicate that a multi-block read is starting. "arg" is the address, in bytes. So you can see that the first thing the ROM does is to load the second 512-byte block out of flash. That block is some kind of header, hopefully with some useful addresses/flags in it. The second half of that block is a bit uglier, but still looks somewhat structured. Maybe it's thumb code? I haven't tried disassembling any of this yet.
After that first block read, there is a much longer read starting at byte 0x26E00. This is probably the actual firmware image, and it looks to be compressed and/or encrypted.
Note that this log shows each block as 0x208 bytes long. Ignore those last 8 bytes, they're just the MMC protocol's CRC.
I'm just including a snippet below. I need to clean this up a lot more before posting the full log. (The biggest problem is that my hardware buffer keeps filling up, so there are some missing pieces later on ;)
| Code: |
[CMD] tb=1 CMD0 arg= 0 crc=4a end=1
[CMD] tb=1 CMD55 arg= 0 crc=32 end=1
[CMD] tb=1 CMD1 arg= 100000 crc=21 end=1
[CMD] tb=0 CMD63 arg= ff8080 crc=7f end=1
[CMD] tb=1 CMD1 arg= 100000 crc=21 end=1
[CMD] tb=0 CMD63 arg=80ff8080 crc=7f end=1
[CMD] tb=1 CMD2 arg= 100000 crc=7b end=1
[CMD] tb=0 CMD63 arg=15000041 crc=28 end=0
[CMD] tb=1 CMD6 arg=30304d03 crc=4f end=0
[CMD] tb=0 CMD10 arg=a5593cfd crc=7f end=1
[CMD] tb=1 CMD3 arg= 10000 crc=3f end=1
[CMD] tb=0 CMD3 arg= 500 crc=7d end=1
[CMD] tb=1 CMD9 arg= 10000 crc=78 end=1
[CMD] tb=0 CMD63 arg=9026012a crc=07 end=1
[CMD] tb=1 CMD25 arg= 1dff6db crc=3f end=1
[CMD] tb=1 CMD12 arg=b202056f crc=7f end=1
[CMD] tb=1 CMD7 arg= 10000 crc=6e end=1
[CMD] tb=0 CMD7 arg= 700 crc=3a end=1
[CMD] tb=1 CMD16 arg= 200 crc=0a end=1
[CMD] tb=0 CMD16 arg= 900 crc=05 end=1
[CMD] tb=1 CMD6 arg= 3b70100 crc=16 end=1
[CMD] tb=0 CMD6 arg= 900 crc=6e end=1
[CMD] tb=1 CMD18 arg= 200 crc=66 end=1
[CMD] tb=0 CMD18 arg= 900 crc=69 end=1
[CMD] tb=1 CMD12 arg= 200 crc=26 end=1
[DAT] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 020: 00 80 00 01 06 40 20 00 08 07 b0 30 06 60 20 00 : .....@ ....0.` .
[DAT] 030: 06 e0 20 08 87 50 20 00 08 07 b0 30 07 60 20 00 : .. ..P ....0.` .
[DAT] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cb : ................
[DAT] 100: 3f fe ce 58 df 06 1d a0 7e f9 72 b5 21 e8 96 b2 : ?..X....~.r.!...
[DAT] 110: f5 c1 77 99 c8 f0 09 e4 f9 f3 0a 78 0b 0b b9 40 : ..w........x...@
[DAT] 120: db 06 56 45 55 88 d0 a1 07 d0 f4 6c c0 0e 5f 1a : ..VEU......l.._.
[DAT] 130: 7a 14 f9 9c 50 e2 89 e7 25 8f 49 05 04 e8 44 89 : z...P...%.I...D.
[DAT] 140: aa 45 79 65 cf df 80 d8 be 42 73 ee a8 1b 81 94 : .Eye.....Bs.....
[DAT] 150: ab f2 28 af b9 5f 3c 51 13 b9 74 2e 40 a0 c5 6d : ..(.._<Q..t.@..m
[DAT] 160: 39 a8 aa 23 c6 16 6e d8 5d c7 59 cc f8 62 39 f5 : 9..#..n.].Y..b9.
[DAT] 170: 93 f2 b5 ef aa 17 02 c1 63 37 a3 e3 03 50 d9 08 : ........c7...P..
[DAT] 180: 08 48 88 c8 18 58 98 d9 19 59 99 c8 18 58 98 d9 : .H...X...Y...X..
[DAT] 190: 19 59 99 dc 03 70 00 80 03 0c 00 70 03 00 00 00 : .Y...p.....p....
[DAT] 1a0: 03 00 00 00 03 04 00 0b 83 7f 80 70 00 00 0f f0 : ...........p....
[DAT] 1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
[DAT] 1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b : ................
[DAT] 200: 3c 5a f2 99 06 36 42 8f : <Z...6B.
[CMD] tb=0 CMD12 arg= b00 crc=3f end=1
[CMD] tb=1 CMD18 arg= 26e00 crc=53 end=1
[CMD] tb=0 CMD18 arg= 900 crc=69 end=1
[DAT] 000: 99 f2 62 e1 c4 6f 23 3d fa 57 ab fe 58 49 31 ed : ..b..o#=.W..XI1.
[DAT] 010: 72 25 6c 30 f4 a1 15 fc d8 c3 59 52 e8 06 69 2a : r%l0......YR..i*
[DAT] 020: 7a 05 27 b5 47 b8 9c eb d4 ca 11 d3 64 e4 1b df : z.'.G.......d...
[DAT] 030: a8 8b 15 e9 88 f0 ac 96 7f 51 5a 48 71 7a c6 27 : .........QZHqz.'
[DAT] 040: ed 61 bd cf d3 66 1a 06 89 d5 b8 bf 34 8d 01 65 : .a...f......4..e
[DAT] 050: 2a 58 37 35 de 36 1c 50 4c 8b 56 5a 2f a9 1a bd : *X75.6.PL.VZ/...
[DAT] 060: 6a 4d 40 f2 09 8c 12 9d 0e cd 12 8d dc e8 4f 32 : jM@...........O2
[DAT] 070: 9e 61 1c a1 46 de 4a f8 66 f8 3b 6e 92 77 9e 52 : .a..F.J.f.;n.w.R
[DAT] 080: 61 be 46 b5 f4 7e c5 57 50 04 78 75 58 c2 0e ce : a.F..~.WP.xuX...
[DAT] 090: 22 74 79 2c aa ba 28 d4 19 47 3a 43 7c 46 23 14 : "ty,..(..G:C|F#.
[DAT] 0a0: 71 5a f5 bc f0 9e ec ef 00 53 e4 a6 76 ec 89 6a : qZ.......S..v..j
[DAT] 0b0: a8 b6 8c 59 94 4c c4 da 49 2a 86 9b 09 8e 3f 07 : ...Y.L..I*....?.
[DAT] 0c0: 3f 6e fb 3a ae 73 b4 3f 0a f7 ee a3 f7 a0 82 9e : ?n.:.s.?........
[DAT] 0d0: 3d 21 aa f1 c1 3f 0a d2 8a eb 30 95 c1 11 ab c9 : =!...?....0.....
[DAT] 0e0: d3 8d c2 e8 0b 69 77 17 1d ae 98 88 86 0c f6 78 : .....iw........x
[DAT] 0f0: 71 32 dc 58 8c e5 b1 25 e6 28 7a 63 bb 95 f1 2d : q2.X...%.(zc...-
[DAT] 100: 4d 9a 8c 40 e1 38 88 08 1d fe bb 99 87 e7 b2 9c : M..@.8..........
[DAT] 110: 57 7c ab bd 88 06 fd ff 32 59 ae 9b de 1d f2 b7 : W|......2Y......
[DAT] 120: 93 d0 25 b3 10 6c 2d 82 17 18 0f 77 2a 1c 81 fe : ..%..l-....w*...
[DAT] 130: 18 de ca b2 f7 ad 75 df 8c 00 f4 5e b3 b4 c2 e4 : ......u....^....
[DAT] 140: 62 72 3d 82 c8 eb cb b8 82 fe 4b 42 05 4c f2 4a : br=.......KB.L.J
[DAT] 150: 26 e9 5a fe 75 8c 79 57 26 0d 49 01 08 8c d5 8b : &.Z.u.yW&.I.....
[DAT] 160: 49 ec 73 81 ba 6c 84 28 94 85 c5 d1 bb 0e 2d 70 : I.s..l.(......-p
[DAT] 170: 10 86 da ca 0a 95 18 51 19 1e 0a 68 b3 04 89 22 : .......Q...h..."
[DAT] 180: 98 4c 0c 87 c9 78 b8 10 23 25 7d ec b7 a5 26 4a : .L...x..#%}...&J
[DAT] 190: 5c e2 3d 94 7f 58 c5 f2 b2 06 cf 1a ec da ee 35 : \.=..X.........5
[DAT] 1a0: cf 8a 2a 39 ed 88 d4 f8 ec cf 43 5a d9 98 6d 66 : ..*9......CZ..mf
[DAT] 1b0: 7d 6a c8 24 e8 7d 9d 67 d9 5f 23 f9 bd 72 4e 56 : }j.$.}.g._#..rNV
[DAT] 1c0: 59 f4 fd 51 01 c3 77 4f 66 32 e6 51 5a 9d 14 e5 : Y..Q..wOf2.QZ...
[DAT] 1d0: 77 75 7f 4c 99 30 dc 3b 1b 12 34 8b 0c d6 a8 26 : wu.L.0.;..4....&
[DAT] 1e0: de 49 72 ea cc 7a 9a 4c 2a 12 37 a0 26 17 18 38 : .Ir..z.L*.7.&..8
[DAT] 1f0: 78 88 74 b1 21 d4 57 07 89 2a fb 71 80 63 5a 2b : x.t.!.W..*.q.cZ+
[DAT] 200: 1c b3 8d e9 b0 89 69 af : ......i.
[DAT] 000: 49 2e b8 db b0 6a 8b 02 80 1d 3b 63 c8 b7 de c2 : I....j....;c....
[DAT] 010: 63 c1 69 f9 94 12 fc 6c 95 77 34 fd 09 d9 29 11 : c.i....l.w4...).
[DAT] 020: 9f 17 4f a6 fc 3e 80 8a 5f b4 ef 07 45 07 a9 e3 : ..O..>.._...E...
[DAT] 030: 50 eb 71 4b bd 81 8d db 11 0c 89 04 19 de 83 ec : P.qK............
[DAT] 040: f8 6b 10 dd 55 4a cd cc a7 5d 93 12 6a 7c d9 9f : .k..UJ...]..j|..
[DAT] 050: 8b 71 ec 28 a4 1a 15 ad 24 8e 3c 07 02 4f d7 a0 : .q.(....$.<..O..
[DAT] 060: c6 22 5b 57 8d df 69 2b b3 66 a7 fa d1 a9 7e 5d : ."[W..i+.f....~]
[DAT] 070: c2 2a f8 40 d7 66 dc 73 f5 0d b1 df c7 a7 ea 8a : .*.@.f.s........
[DAT] 080: 41 93 10 9f 9e 71 18 34 ad bb 53 47 ce 09 b2 f4 : A....q.4..SG....
[DAT] 090: d1 33 d3 49 f1 7e c4 b6 64 86 c5 90 f5 ae e6 66 : .3.I.~..d......f
[DAT] 0a0: 91 f9 34 26 de e8 5c 2a 49 dd ab 4c 00 7e 45 d8 : ..4&..\*I..L.~E.
[DAT] 0b0: 46 f2 17 db 1d 80 8d 57 08 88 14 34 43 dc bf 02 : F......W...4C...
[DAT] 0c0: 3f 0d e2 58 b6 12 a9 6f ea 9e a8 6c ab b4 9b 83 : ?..X...o...l....
[DAT] 0d0: 96 f8 02 68 88 e1 9e 5e 37 7f 4e 61 1f 46 db 93 : ...h...^7.Na.F..
[DAT] 0e0: c5 e3 f0 76 73 a6 49 4a 6b 35 62 6f d7 08 2b ef : ...vs.IJk5bo..+.
[DAT] 0f0: 4f 5b 3b b4 e7 55 b8 fd a1 53 74 ac a9 79 65 ae : O[;..U...St..ye.
[DAT] 100: 45 89 65 fc a9 51 dc 74 01 91 94 3f fa c5 76 61 : E.e..Q.t...?..va
[DAT] 110: c1 20 56 7e 6e 03 76 f6 09 99 88 d4 73 f6 c1 45 : . V~n.v.....s..E
[DAT] 120: bc 74 b3 c0 d1 5a fd ca 36 8f 18 d3 b2 37 15 bc : .t...Z..6....7..
[DAT] 130: 0c f4 22 17 58 3f 31 87 38 40 39 b6 c0 8c 92 7c : ..".X?1.8@9....|
[DAT] 140: bb 28 66 75 76 37 5e 8f 56 bc c3 28 cd ce 68 6e : .(fuv7^.V..(..hn
[DAT] 150: 52 03 24 18 01 ee d1 65 40 87 45 bd 7f 3b 7b 6a : R.$....e@.E..;{j
[DAT] 160: 12 3c b7 17 dd 66 54 2e 95 93 64 1c a2 65 9f 83 : .<...fT...d..e..
[DAT] 170: c4 cc c6 c7 c7 c8 55 2b 40 3c 7b ac e7 b1 f1 44 : ......U+@<{....D
[DAT] 180: 0d 4c 4e 4f ff 06 c0 8d 9d c1 fc 78 01 18 12 06 : .LNO.......x....
[DAT] 190: 19 01 84 4f dc a4 a4 fe cf 3a 2a 03 b9 af b8 dd : ...O.....:*.....
[DAT] 1a0: f6 a0 a0 52 af 3c e8 10 df 41 89 82 80 ba c7 e3 : ...R.<...A......
[DAT] 1b0: 35 f7 35 a2 c0 3e a1 a5 44 90 38 ce 84 ce ac 0c : 5.5..>..D.8.....
[DAT] 1c0: 08 e9 63 f6 2e 18 4a 8a 18 4c 1b 2d 38 4b 44 b1 : ..c...J..L.-8KD.
[DAT] 1d0: 38 cd dd ee e9 75 3f e8 98 10 8c d1 5f dc 86 e4 : 8....u?....._...
[DAT] 1e0: 27 0f 8e dd 8d a8 d4 83 ce 49 ff a7 3c 6b 4f 78 : '........I..<kOx
[DAT] 1f0: 28 7a c7 4f 47 8f bd 48 c0 e2 60 53 86 51 37 14 : (z.OG..H..`S.Q7.
[DAT] 200: 41 17 15 98 9d 85 b6 0f : A.......
|
#169507 - scanlime - Sun Jul 19, 2009 6:10 pm
My lame FPGA setup was dropping bits, so the addresses above are correct but the data dump isn't quite right. I tried hooking up an old USB SD/MMC card reader in parallel with my FPGA, and I got a nicer-looking dump:
| Code: |
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000220 00 08 00 00 10 64 02 00 00 80 7b 03 00 66 02 00 |.....d....{..f..|
00000230 00 6e 02 00 88 75 02 00 00 80 7b 03 00 76 02 00 |.n...u....{..v..|
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c |................|
00000300 b3 ff ec e5 8d f0 61 da 07 ef 97 2b 52 1e 89 6b |......a....+R..k|
00000310 2f 5c 17 79 9c 8f 00 9e 4f 9f 30 a7 80 b0 bb 94 |/\.y....O.0.....|
00000320 0d b0 65 64 55 58 8d 0a 10 7d 0f 46 cc 00 e5 f1 |..edUX...}.F....|
00000330 a7 a1 4f 99 c5 0e 28 9e 72 58 f4 90 50 4e 84 48 |..O...(.rX..PN.H|
00000340 9a a4 57 96 5c fd f8 0d 8b e4 27 3e ea 81 b8 19 |..W.\.....'>....|
00000350 4a bf 22 8a fb 95 f3 c5 11 3b 97 42 e4 0a 0c 56 |J."......;.B...V|
00000360 d3 9a 8a a2 3c 61 66 ed 85 dc 75 9c cf 86 23 9f |....<af...u...#.|
00000370 59 3f 2b 5e fa a1 70 2c 16 33 7a 3e 30 35 0d 90 |Y?+^..p,.3z>05..|
00000380 80 84 88 8c 81 85 89 8d 91 95 99 9c 81 85 89 8d |................|
00000390 91 95 99 9d c0 37 00 08 00 30 c0 07 00 30 00 00 |.....7...0...0..|
000003a0 00 30 00 00 00 30 40 00 b8 37 f8 07 00 00 00 ff |.0...0@..7......|
000003b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
|
The values at 0x220 are definitely offsets to other areas on the card. The firmware image that the bootloader starts reading immediately after this block is at 0x26e00, and you can see that address appear at 0x230.
As for how the rest of the card is encoded.. your guess is as good as mine ;)
#169508 - Mighty Max - Sun Jul 19, 2009 7:48 pm
I don't think it will be something too complicated.
Have you tried to run the methods the gba/nds bios implements too, like LZ77, simple Huffman over the data? To see if you can identify some ARM or Thumb instructions that make sense?
_________________
GBAMP Multiboot
#169525 - MechaBouncer - Mon Jul 20, 2009 4:51 pm
Awesome! Are you going to post what you find up on dsibrew.org as well? It would be awesome if you and Team Twiizers were able to work together and share what you all know about the innards of the DSi. This makes me even more hopeful of a DSi Homebrew Channel.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#169530 - Da-Bomb1 - Tue Jul 21, 2009 4:47 am
Wow, good job so far. Have you tried contacting Twiizers to see what they say about this?
#169552 - wintermute - Wed Jul 22, 2009 8:29 pm
| Mighty Max wrote: |
| I don't think it will be something too complicated. |
Why not? It would be completely crazy to go to the trouble of encrypting the NAND and then making it easy to break.
See the encryption used on the Wii for instance.
As for Twiizers, still not entirely sure how Blasty exploiting the games becomes them being the be all & end all of homebrew hacking. I have my own exploits for both games too & work is in progress to get libnds code running.
http://www.youtube.com/watch?v=gXwvTqkIAiY
Ignore the comments about photoshopping, it's just a couple of the regulars from #dsdev on irc.blitzed.org messing around.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#169553 - Mighty Max - Wed Jul 22, 2009 8:52 pm
| wintermute wrote: |
| Mighty Max wrote: | | I don't think it will be something too complicated. |
Why not? It would be completely crazy to go to the trouble of encrypting the NAND and then making it easy to break. |
Because i don't think the purpose of it is to encrypt it, but to safe space.
I think so, because it would be half-hearted to leave things like data indizes unencrypted and to have it guarding a system that does not allow native execution of encrypted code to protect it beeing simply read from injected parts.
Not to mention that the simple things are easier to check first ;-)
_________________
GBAMP Multiboot
#169554 - MechaBouncer - Wed Jul 22, 2009 9:44 pm
| wintermute wrote: |
As for Twiizers, still not entirely sure how Blasty exploiting the games becomes them being the be all & end all of homebrew hacking. I have my own exploits for both games too & work is in progress to get libnds code running.
http://www.youtube.com/watch?v=gXwvTqkIAiY
Ignore the comments about photoshopping, it's just a couple of the regulars from #dsdev on irc.blitzed.org messing around. |
Sorry, I didn't see that before hand. The topic at hackmii.com was fresh in my mind since I follow it and the news was posted a few days earlier. Team Twiizers mentioned they were able to dump the RAM and scanlime was trying to dump the NAND, so I thought there might be something that both sides could learn from each other. He had also mentioned dsibrew.org for the hardware write up they had, so I also thought it would be a good place to add his findings to for all to benefit.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#169562 - ritz - Thu Jul 23, 2009 2:36 pm
| wintermute wrote: |
| work is in progress to get libnds code running |
Go wintermute! I need more CPU to do silhouette shadows ;)
#169757 - dovoto - Sun Aug 02, 2009 5:18 am
scanline,
Now that we have some code up and running on the dsi has anything you have discovered pointed to how we might access NAND from dsi code?
_________________
www.drunkencoders.com
#169799 - wintermute - Tue Aug 04, 2009 11:23 am
We don't need access to NAND. In fact it would probably be much better for the reputation of homebrew if NAND access and the decryption mechanism for DSiWare were to remain exclusive to Nintendo. There are other means to make homebrew access reasonably convenient without resorting to methods which ultimately will help piracy more than it helps homebrew.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#169805 - hacker013 - Tue Aug 04, 2009 1:20 pm
So, no homebrew channel (no nand acces = no homebrew channel) :( ?
_________________
Website / Blog
Let the nds be with you.
#169814 - wintermute - Tue Aug 04, 2009 8:51 pm
| hacker013 wrote: |
| So, no homebrew channel (no nand acces = no homebrew channel) :( ? |
Nobody said that.
Given that Nintendo have blocked the DSi flashcarts with their first firmware update it's likely they'll be doing as much as they can to prevent unauthorised software being installed on the NAND. I already have code running via both of the Ubisoft hybrid games, from there we hope to have a bootstrap from the internal SD.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#169819 - spinal_cord - Wed Aug 05, 2009 6:44 am
So we will require one of these games to run homebrew, using a save exploit without installing anything? seems like quite a tedious way to run code :(
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#169823 - hacker013 - Wed Aug 05, 2009 9:59 am
I think this will be like homebrew running on the wii. It just need some time to get easy ways of running homebrew ^^ It is a pity that I don't have a DSi otherwise I would help you guys :)
_________________
Website / Blog
Let the nds be with you.
#169835 - wintermute - Thu Aug 06, 2009 12:07 am
| spinal_cord wrote: |
| So we will require one of these games to run homebrew, using a save exploit without installing anything? seems like quite a tedious way to run code :( |
Not really sure why you think that. Once we bootstrap to a menu there's no need to reboot the DSi - we can install a soft reset handler which just reloads the menu from SD rather than going back to the DSi menu.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#169841 - scanlime - Thu Aug 06, 2009 9:11 pm
Reading the NAND flash was a fun exercise, but I was doing it mostly on the (slim) chance that part of the bootloader was unencrypted. At this point, I agree with WinterMute- I don't think the homebrew scene has anything to gain from accessing the NAND flash, and it would certainly muddy the waters legally if we ended up basing our homebrew on some exploit that could also be used to pirate DSIware games.
@MechaBouncer: I can dump the RAM too now ;)
Lately I've been working on a different reverse engineering strategy. I have a save game exploit for Cooking Coach which bootstraps some C code (using a limited subset of libnds) onto the ARM9, running out of unused system RAM. That C code can dump/load memory, poke at registers, and install hooks in the Cooking Coach code. When it returns, the game resumes executing nearly where it left off.
I plan to use this as a debugging and reverse engineering tool, to help understand more about how Cooking Coach is using the DSi's hardware. This probably means understanding how it communicates with the ARM7, so we can either take control of the ARM7 as well or at least talk to it using the same protocol that the game uses.
I've been running my exploit off of a homebrew SPI EEPROM emulator that I finished earlier this week. It has 1MB of SRAM that's accessible simultaneously by the DS and a PC. It emulates normal save game memory out of the first 64KB, and the rest is accessible using custom SPI commands. So I can use it to very quickly load the exploit itself, plus it serves as extra memory for the C-language code that gets injected, plus it can be used as a communication buffer to send debug info back to the PC. This could probably even be used to inject a GDB stub into the game.
Here's a photo of my current setup:
http://www.flickr.com/photos/micahdowty/3794878172/sizes/l/in/set-72157621023570420/
#169842 - GugloPWN - Thu Aug 06, 2009 9:35 pm
It seems like every new piece of software released for the DSi specifically has been used to run homebrew so far. Sheesh!
#169850 - M!kk@ - Fri Aug 07, 2009 9:43 am
you have hardware to run any code in DSi-Mode on the DSi.
Why you don't build the first DSi-flashcard? that would be very nice :)
#169851 - sonny_jim - Fri Aug 07, 2009 12:54 pm
| Quote: |
Why you don't build the first DSi-flashcard? that would be very nice :)
|
This is a very murky territory.
_________________
| Quote: |
Would that be the internet driver for the program?
|
#169854 - M!kk@ - Fri Aug 07, 2009 3:49 pm
| sonny_jim wrote: |
| This is a very murky territory. |
why? this would be a way of running homebrew (and games) or is that wrong?
#169855 - sonny_jim - Fri Aug 07, 2009 4:05 pm
It's the 'and games' part that people want to stay 6 million miles away from. Any information that is posted here (or anywhere else) about the DSi is going to be used by pirates for their own monetary gain, and the authors know this.
_________________
| Quote: |
Would that be the internet driver for the program?
|
#169856 - M!kk@ - Fri Aug 07, 2009 4:38 pm
that doesn't matter because it's legal to release flashcards - the owner have to decide if he uses it illegaly or not.
and the way the people on this site are currently on is to develop a mod-firmware - that would be 100% illegal because you have to break the protection
#169858 - DiscoStew - Fri Aug 07, 2009 4:54 pm
| M!kk@ wrote: |
that doesn't matter because it's legal to release flashcards - the owner have to decide if he uses it illegaly or not.
and the way the people on this site are currently on is to develop a mod-firmware - that would be 100% illegal because you have to break the protection |
The fact that the owner even has the choice of using a flashcard illegally is enough for Nintendo to block it with a simple firmware update.
_________________
DS - It's all about DiscoStew
#169860 - M!kk@ - Fri Aug 07, 2009 5:10 pm
the guys who want to use a modified DSi should not update their ds until its "cracked", but i that what i wanted to say was that the possibility of a flashcard is already there.
i would prefer a soft-mod because its free :P
#169862 - scanlime - Fri Aug 07, 2009 5:58 pm
| M!kk@ wrote: |
| sonny_jim wrote: | | This is a very murky territory. |
why? this would be a way of running homebrew (and games) or is that wrong? |
As far as I know, there isn't a way to make a legal DSi flash card. The game's headers are signed- so unless you can somehow find Nintendo's private keys, the flash card would have to bootstrap itself using a commercial game.
At this point it definitely seems like a save game hack plus an SD card bootloader is the best goal for launching homebrew on the DSi. With the Cooking Coach hack, the exploit can take control immediately after the Ubisoft splash screen. Installation would just involve running some DS-mode program that can overwrite the save file on your Cooking Coach cartridge. Now you've transformed this high-quality game into a homebrew bootloader. No need to break any of the system's encryption.
There are still a few big hurdles to get over before this is really useful:- Most of the interesting hardware appears to be on the ARM7 (Camera, SD card, maybe DSP..)
- The save game exploits only run code on the ARM9. Another step is necessary to take control of the ARM7. (This is what I'm working on now.)
- Either we'd need to reverse engineer the SD card control registers and access them from the ARM7, or figure out how to access them from the ARM9 via Nintendo's default ARM7 firmware.
#169863 - M!kk@ - Fri Aug 07, 2009 6:38 pm
if you would have access, you could dump the firmware and overwrite it with a custom-firmware which is able to launch homebrew, right?
#169864 - GugloPWN - Fri Aug 07, 2009 7:09 pm
I think people want to avoid rewriting the firmware in case nintendo decides to make drastic changes themselves. Also because of the brick risk.
#169866 - M!kk@ - Fri Aug 07, 2009 8:45 pm
for me a firmware replacement would be the first choise because so the functions are integratet in the main software of the dsi otherwise you would have to go in another menu(see NDS)
and look at the Wii. firmware replacement is ther the most poplular method. und meanwhile it's secure. :)
#169867 - MechaBouncer - Fri Aug 07, 2009 9:01 pm
And what happens when new DSi-only games require a certain firmware like they do with some Wii games? I suppose it's still a bit off, but is certainly possible. Although no NAND access is disappointing because I was hoping for a dedicated Homebrew Channel like the one for the Wii. That way we wouldn't have to have a card of any sort in the DS slot (or just have a different game in there). Ah well. A hacked save game couldn't be any worse than using a flashcart like we do now. Although it makes me wonder if Nintendo might find a way to patch against this as well like they did with the Twilight Hack on the Wii. Hopefully it'll be harder for them to do so.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#169869 - vuurrobin - Fri Aug 07, 2009 11:19 pm
for the people that are interested, GEMISIS used wintermutes hack to run its own code on the dsi, and he made the first dsi only homebrew game.
http://www.youtube.com/watch?v=HCq7CUVfWAA
#169872 - dantheman - Sat Aug 08, 2009 5:51 am
Simplistic game, but a game nonetheless. Progress!
#169873 - M!kk@ - Sat Aug 08, 2009 9:10 am
all the time we are taslking about games and flashcards based on the savgame-bug, but what's up with accessing the ARM9 to develop besser methods of "homebrewing" the DSi?
Will there be a way?
#169875 - hacker013 - Sat Aug 08, 2009 11:56 am
Maybe there is the posibility that we could patch the DSi through this game that it redirects the dsi when it boots to a menu on the mircro-sd slot when we press a key combination and so easy boot firmware without modifying the original firmware or is that imposible ?
_________________
Website / Blog
Let the nds be with you.
#169879 - M!kk@ - Sat Aug 08, 2009 1:13 pm
patching the original firmware would be easier if the connection between the update server and the DSi wouldn't using SSL :)
I thought about let the internet connection going over a proxy server on a pc and redirect the connection to another SSL-Server. If the DSi would accept non-nintendo ssl-certificates we could make a connecten between the dsi and a "hacked update server" so we could give the DSi an fake update without special hardware.
The thing were i stopped was the ssl-server: i am not able to program something like this. Could anyone make and try?
#169882 - yellowstar - Sat Aug 08, 2009 4:45 pm
#169891 - zigg - Mon Aug 10, 2009 6:24 pm
Apologies if anyone has said anything to this effect, but is it at all reasonable to expect existing builds to run under this boot process at some point in the future?
Or will they have to be updated and/or rebuilt under the new libnds(i)?
#169998 - ritz - Fri Aug 21, 2009 3:40 am
That new free DSiWare game/app FlipNote writes and *reads* from the SD card (and sys memory). It spits out about a half a dozen different file formats including animated and regular gifs. The app also utilizes the camera and microphone.
Seems like a good little free program to find holes in (need firmware 1.4 though, I believe, for the DSiShop to get it). Would be nicer than having to use a commercial cart for an exploit and uploading sav files and whatnot.
Also, what about fiddling with the formatting of an SD card in general. Like the disk geometry table stuff or the FAT filesystem structure? On boot up, the DSi would read and puke on init'ing the SD port? Or some app trying to read the SD port/card? The loader that would start from this would know the weird SD structure and init a different partition or something.
I really don't know anything about either of these things, but I thought I'd post my babble anyway.
Brain fart at its finest!
#170008 - Sektor - Fri Aug 21, 2009 1:45 pm
#170014 - SteveH - Fri Aug 21, 2009 6:39 pm
You forgot one Sektor:
http://dsibrew.org/wiki/Flipnote_Files/PPM
Looking at the way the sound is stored at the moment, but so far all we can do is read these files, it's another to write them.
#170033 - zigg - Mon Aug 24, 2009 3:14 pm
I think I'd rather have a hard game bootstrap.
There's very little Nintendo can do to shut that down. Flipnote in particular is a good target for an update because it depends on an online service, etc?changing the service to require the new version, for example.
There actually has been one feature update of Flipnote already in Japan, and I understand they're going to phase out online support for the original version.
#170034 - SteveH - Mon Aug 24, 2009 3:52 pm
That feature update in Japan was to bring it upto date with the US / EU versions. Just read the information on the Iwata Asks section of the Nintendo portal data 12 August about the new features in the next version, which includes dual layers and the onion skin feature.
#170035 - zigg - Mon Aug 24, 2009 4:08 pm
| SteveH wrote: |
| That feature update in Japan was to bring it upto date with the US / EU versions. Just read the information on the Iwata Asks section of the Nintendo portal data 12 August about the new features in the next version, which includes dual layers and the onion skin feature. |
Sure, but nothing's precluding them from coming out with Flipnote 3 (and they might!), using continued access to Hatena as a carrot to update... basicallly, taking away a feature from people who would need to continue using an old version.
Whereas if you have a game card, there's no possibility of such an update. All they could do is scan for "bad" saves... and there's a limit to how much of that can be done.
#170040 - SteveH - Mon Aug 24, 2009 6:42 pm
Slight problem with the game exploit tho - you need a copy of the game, a slot 2 device and a flashed DSL to set it up...
#170044 - zigg - Mon Aug 24, 2009 7:11 pm
| SteveH wrote: |
| Slight problem with the game exploit tho - you need a copy of the game, a slot 2 device and a flashed DSL to set it up... |
savsender or my own in-progress TFTP server will remove the slot-2 requirement, running entirely off one of the rather ubiquitous slot-1 cards. You do still need an original DS or Lite (apparently the appropriate functions don't work on an Acekard? really need to get around to verifying that someday), though they don't need to be FlashMe'd.
Of course, both routes are still advantageous to pursue. Never can have too many tools in one's arsenal.
#170055 - ritz - Tue Aug 25, 2009 1:53 am
If someone finds an appropriate exploit in Flipnote, than simply copy the game to SD card and save the bin file. No need to worry about accidently updating it, just revert to the archived homebrew-enabler version.
But it would be silly to discount any option at all. A comm cart exploit would be very welcome.
#170116 - spinal_cord - Mon Aug 31, 2009 8:04 pm
Has there been any more progress on this? Are you (DSi hackers in general) any closer to a homebrew channel/bootmii type function?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#170139 - scanlime - Wed Sep 02, 2009 9:50 am
Rest assured, I'm still working on the DSi :)
Most of the discussion has moved to IRC lately. The best ways to follow what I'm personally working on are to watch the dsibrew wiki and my Flickr set.
#170228 - MechaBouncer - Wed Sep 09, 2009 8:42 pm
Or HackMii because they mentioned your work a couple days ago:
http://hackmii.com/2009/09/dsi-ram-hax/
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#171581 - spinal_cord - Mon Nov 30, 2009 6:55 pm
I apologise for resurrecting the thread, but has there been any breakthroughs at all? IS the DSi likely to remain unhackable?
Will we be forever forced to run DS-only homebrew on our DSi's using even less legal solutions than before?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#171583 - scanlime - Tue Dec 01, 2009 5:59 am
Personally I've been busy with Real Life (tm) for the last couple months. But the Team Twiizers folks are working on it. If you want to follow what I'm doing personally, I have a blog (http://micah.navi.cx) and any real progress is likely to be announced on Hackmi (http://hackmii.com) first.
#174116 - t377y000 - Wed May 19, 2010 5:08 am
hi i was wondering if using the DSi exclusive games systems flaw or foto showdown can be used for a DSi exploit or someway to make DSi homebrew? they both use the camera & are real DSi games that don't work on the DS or DSL. maby make a save exploit for them?
Last edited by t377y000 on Wed Aug 20, 2014 8:07 am; edited 1 time in total
#174128 - SteveH - Wed May 19, 2010 1:27 pm
| t377y000 wrote: |
| hi i was wondering if useing the DSi exclusive games systems flaw or foto showdown can be used for a DSi exploit or someway to mak eDSio homebrew? they both use the camera & are real DSi games that dont work on the DS or DSL. maby make a save exploit for them? |
Slight problem with that, you need a fair bit of space to do anything useful, and most of the current DS/DSi games have limited save space (<1k). I've seen some proof of concept code to run software from the SD card, but IIRC it's still a while before it will be released due to the complexities of getting the exploit working consistantly on all DSi's.
Using the DSi only games is going to be problematic as well since you can not access the save game area of those games without taking them out of the DS card slot, if you can't access them from a normal DS / DSl then you are going to face a huge problem trying to get the save game exploit onto the card in the first place.
#175239 - yellowstar - Sat Oct 09, 2010 7:53 pm
Anyone have some dsiware which has ascii-only(no Unicode/Japanese support) string input? DSiware sd .bin exports savedata can be extracted+decrypted and modified+encrypted.
#175747 - yellowstar - Thu Jan 27, 2011 8:33 pm
#176220 - yellowstar - Fri May 20, 2011 5:23 am
#176739 - guestsarewelcome - Tue Sep 27, 2011 7:57 pm
Sorry for resurrecting an old thread.
Couldn't you install a DSi-mode Homebrew by using the same method as HyperGTS? (Which would mean making a DNS Server on computer, change DNS on DSi to the computer's DNS server, access DSi Shop, get HomeBrew Channel!)
Would this be feasible?
Also, would it be possible to have this as a channel -- no bootstrapping required? That way you would have no chance of bricking the device (as far as I can tell), as well as being able to delete it at any time, without having to format the device.
_________________
This is a guest account.
Please respect the rules.
UserNM: guestsarewelcome
PsWd: loginnow