Recently I was informed that Datel has released a new version of their Action Replay Cheat Cartridge that allows you to cheat in Nintendo DS games on a Nintendo DSi console. Knowing that Nintendo put quite some effort in blocking any third party cartridges from working on the DSi I was curious to figure out how they did it.
Before jumping in this article, I’ll give you a small warning that what is written here might be quite “techy” to some people. I advise reading lots of GBAtek (And maybe a bit of dsibrew) when you get lost. 😉
Research™ has shown that getting a DS cart to boot on a DSi requires quite a bit more effort than it did on a (DS)Lite. Cart timings are very important, you cannot eject the cartridge and insert a new one beyond the DSi menu. But most important of all, the DSi menu does additional integrity checking prior to booting the cartridge.
The integrity checking is there to ensure that the cartridge booted is a genuine licensed game cartridge. There is a ‘white list’ stored on the DSi’s NAND flash which has an entry for every DS game ever released. The entries consist of multiple SHA1 (How these hashes are constructed exactly hasn’t been confirmed) checksums for the cartridge header, ARM9 binary and ARM7 binary.
I hear you thinking “what about newly released DS games? How will they ever boot on a DSi without an update to the whitelist?”. Newer DS games come with a RSA signature in the header that is verified instead of checking against the whitelist, and thus they don’t need to be explicitly white-listed.
So back to the Action Replay DSi cartridge, something that I immediately noticed is that when the cartridge is inserted into a DSi the icon and title of the game “Game & Watch Collection” show up. That’s a little weird.. but when selecting the icon you are thrown into a AR DSi menu.
Let’s take a step back, if all game binaries and headers are checked against a whitelist or need to have a valid RSA signature, then how does this Datel cart manage to boot?
I went to find the source code of my cartridge dumper and dumped the AR DSi cartridge on an old DS-Lite. after checking out the resulting binary I was surprised. No signs of the “Game & Watch Collection” ROM header or icon data, or main data for that matter..
$ hexdump -C ardsi.nds | head -n 2
00000000 4d 45 44 49 41 50 4c 41 59 45 52 20 41 53 4d 41 |MEDIAPLAYER ASMA|
00000010 30 31 00 00 07 00 00 00 00 00 00 00 00 00 00 04 |01..............|
This doesn’t match up with what I saw when the cart was booted on a DSi, huh? Neither would this cartheader qualify as anything whitelisted/valid, so there is no way it could boot on a DSi like this.
During a discussion with neimod he showed me a cartridge access trace (of the cartridge bus) he made of a game cartridge inserted in a DSi. Something noticeable was that a DSi would send the ROM ID cart command right after the reset command, before sending the “get header” command. My dumper software was doing it in a bit different order… (The order an actual (DS)Lite would do it in)
This small difference in order of cart commands allows the AR DSi cartridge to distinguish between a DS(-Lite) and DSi console.
For the sake of clarity:
DS-Lite cart initialization sequence:
CMD 9f00000000000000 # reset
CMD 0000000000000000 # get header
CMD 9000000000000000 # get rom_id
CMD ...
DSi cart init sequence:
CMD 9f00000000000000 # reset
CMD 9000000000000000 # get rom_id
CMD 0000000000000000 # get header
CMD ...
After making this small change to my dumper software, I was indeed getting back something that looked like a Game&Watch collection ROM.
$ hexdump -C ardsi2.nds | head -n 2
00000000 47 41 4d 45 20 57 41 54 43 48 20 43 41 57 54 45 |GAME WATCH CAWTE|
00000010 30 31 00 00 06 00 00 00 00 00 00 00 00 00 00 00 |01..............|
Almost there! .. or so I thought. When I started comparing the original game & watch collection ROM against the result I just dumped, I got nothing but mismatches after the initial 0x8000 bytes (header + secure area).
More and more inspection of the dump and head-to-table banging later I noticed something funny: the data in the dump at 0x8000 (right where the mismatches start) was exactly the data that was supposed to be at 0x10C00, which coincidentally matched up with the exact start offset of the icon/title data. What’s going on? Why does this data show up in the wrong location of the dump?
Then a pattern started to emerge, the right data WAS there, just in the wrong order .. then it hit me. The AR DSI cart was completely ignoring the offset field in the read (0xB7) commands I was sending, and simply advancing a pre-constructed buffer that would exactly match the reply data of the commands a DSi console would normally send. This has the advantage that they only need to require a bare-minimum of data of the original game ROM and don’t need any (complex) logic to fully decode those 0xB7 commands.
With this knowledge in hand I tried reordering the dump in order to get a final ROM image. This proved to be quite tricky since I didn’t know when what was exactly read. I then proceeded to hack up DeSmuMe to log all cart reads and match that against a table of the filesystem to figure out in what order the files we’re read. Even now it was hard to get a good reconstruction of the dump, some files are only read partially, etc.
So I decided to build a list of MD5 hashes for each 0x200 bytes sized block in the original ROM dump and the shuffled AR DSi dump. A couple of minutes later I knew in which order to put what blocks back, and was left over with 3 blocks that didn’t match (0x600 bytes total) with *any* of the blocks in the original ROM.
Due to the preceding read commands I could see where in the dump these 0x600 bytes should go (comparing it against the
cart read access log I made using DesMuMe), and I finally had a final image. Now it was time to figure out how this
thing actually worked it’s magic. The answer was obviously in those 3 changed blocks. 🙂
To give you a quick idea of exactly how much code/data they borrowed from the original ROM: There are 1984 blocks of 0x200 bytes each from the original ROM, of which 1825 blocks are unique. 1825 * 0x200 = ~912Kb of data from the original ROM.
Sure enough the 3 new changed blocks didn’t fall within the area of the ARM9 or ARM7 binary of the game, else it wouldn’t pass the whitelist. I expected it to be a file-based exploit in one of the few files within the nitro filesystem on the cartridge, but all the offsets of those files weren’t in range.
I had a quick look at the 3 new blocks in a hex editor and noticed there was plain ARM opcodes in there, and a big landpad with 0xEAFFFFFE’s in front (label: b label). I started by disassembling this code, not caring HOW it eventually ends up in memory.
The small amount of code does some basic initialisation, then proceeds to send a special cart command that puts the ARDSi cartridge in a different mode. After this three read (0xB7) commands are executed to read and copy out the header, ARM9 binary and ARM7 binary respectively. By this I mean ofcourse the *actual* AR DSi menu header / binaries.
Knowing what their shellcode did was half of the job, now I had to figure out how it ended up executed in memory. Going back to the ROM I realized I didn’t check the *entire* filesystem range for the offset in which the blocks lie. To be more precise, I had only checked within the boundaries of the filesystem entries that have an entry in the File Name Table (FNT).
Nintendo DS ROMs can feature a thing that is known as “filesystem overlays” or “rom overlays”. These overlays are described in separate tables (pointed to by the NDS cartridge header). Overlay tables consist out of entries that look like this:
/* 0x00 */ u32 id;
/* 0x04 */ u32 ram_addr;
/* 0x08 */ u32 ram_size;
/* 0x0C */ u32 bss_size;
/* 0x10 */ u32 sinit_init;
/* 0x14 */ u32 sinit_init_end;
/* 0x18 */ u32 file_id;
/* 0x1C */ u32 unknown;
These overlays are pieces of code that normally aren’t loaded together with the main binary, but rather can be loaded on-demand by the main binary.
The important fields here are: id – a unique identifier (incrementing number) for the current overlay, ram_addr – the address the overlay is copied to in memory when it is loaded, ram_size – the size in RAM reserved for this overlay, file_id – the index of the overlay file in the filesystem table.
Cross checking the filesystem indexes of the overlays against my card access trace from DeSMuME I determined that the 3 changed were infact the first 3 blocks of overlay 0x01.
To not make this article any more lengthy than it already is, here’s what happens:
- DSi console sends cart initialization sequence
- ARDSi cart determines it’s being ran on a DSi console and starts responding a fixed pattern on every read block request
- Game’s header, ARM9 and ARM7 binary are loaded by the DSi menu and checked for integrity
- Integrity checks pass since all data is 1:1 compared to the original ROM
- Game starts running, starts parsing filename and file allocation tables of filesystem on cartridge
- Game loads overlay 0x01 to 0x020BBF00
- Game does more stuff and eventually branches to code inside loaded overlay @ 0x020BBFE8
- The initial 0xE8 bytes of the datel payload are inifite loop opcodes. The entrypoint is right behind it and payload execution starts.
- Payload sends secret F005000000000000 (Not so secret anymore now, huh?) cart command to put cartridge in secondary mode
- Payload uses normal 0xB7 read commands to read the header, the ARM9 binary and the ARM7 binary.
- Some IPC magic is done to capture execution of the ARM7 cpu
- Finally a softreset SVC/SWI is issued to execute the newly loaded ARM9 code
And here I was hoping datel had a clever technique under their belt to leverage code in DS mode on a DSi. But it seems like everyone else (read: Hong Kong pirate cartridge companies), they as well had to resort to ‘borrowing’ bits of a commercial game ROM. The only clever thing here is storing the actual payload inside a ROM overlay that is loaded early in the game. The overlays don’t seem to be checked by the DSi menu during the integrity check, and they don’t have to rely on a buffer overflow or some other tricky attack(s) in order to get their code running.
EDIT: Normmatt just mentioned on IRC that the DSi menu might be in fact checking the ROM overlays. Comparing the SHA sums in the whitelist for a game that has overlays and for a game that doesn’t shows that one of the hashes is empty for a game that has _no_ ROM overlays. This all still makes sense though: the DSi menu initially reads the overlays to check their integrity. But when the game is ran and it loads the overlay(s) on demand different data is returned and the system is fooled into loading the malicious code in memory. A typical case of “read twice, verify once”.
The thing I’m wondering about most is how Datel was planning to get away with this? Someone mentioned the argument of the ROM data being there “just for interoperability” and that would justify it a bit. But in my opinion borrowing roughly a megabyte of original ROM data is a different ballgame than borrowing a couple of (Ok, 48) bytes for the Nintendo logo. I would be interested to hear you guys’ opinions on the ethical aspect of this whole thing.
Oh well, it made for a nice Sunday of reverse engineering anyway. Hopefully you enjoyed the read as much as I did working this out, ciao! ;-]
P.S. Oh, and before I forget here‘s some bonus picture material for you all.
P.P.S If you are interested in the quick dis-assembly I did: click here. Sorry for not having used the correct base-address in that listing, but the code is position independent, you should get the idea. I hope datel doesn’t mind me ‘borrowing’ something from them.
47 responses so far ↓
1 aaron44126 // Feb 1, 2010 at 6:25 am
Correct me if I’m wrong, but wouldn’t it be easy for Nintendo to combat this with a firmware upgrade? Either changing the order of commands in the init sequence to make it look like a regular DS, or adding additional verification. Seems like the ARDSi is already a doomed product…
2 blasty // Feb 1, 2010 at 6:46 am
aaron44126: Yes this is the case, but I think datel accounted for that. There is an USB port on the ARDSi which allows you to connect to some software on the PC. I think they left open the possibility to update the fixed command-reply stream in case nintendo decides to block their cartridge a firmware update.
3 Sektor // Feb 1, 2010 at 6:48 am
I don’t think there’s anything unethical about including the game data. If you can’t find any other way then it’s require, at least they didn’t make the game playable. It would be an extremely impractical way to get a dump of the game.
1KB, 1MB or 1GB, if it’s required to boot your own code then so be it, Nintendo made them do it. Of course the courts could have a very different opinion.
4 BrandonG777 // Feb 1, 2010 at 7:14 am
The smartest dumbass ever. LOL Nice work but even the French court doesn’t agree with you.
5 tech3475 // Feb 1, 2010 at 7:17 am
@Sektor, that argument wont stand up in a court of law (well maybe France if you ahve the right judge).
Is this how modern DSi flash carts work? I wonder because if they dont use this method then why didn’t Datel use it instead of “stealing” Nintendo’s code.
6 blasty // Feb 1, 2010 at 7:29 am
tech3475: Yes this is how all DSi compatible DS-Flashcarts work. Borrowing code/data from original ROMs to bypass integrity checking and get their menu booted. I reversed some of these carts in the past — but I thought the Datel cart would be more interesting to write about since it is supposed to be a somewhat more “legit” and commonly available retail product. If there is any interest in unveiling the secrets of DSi compatible DS flashcarts, let me know .. I’ll see if I can cook up some more stories then. 😉
7 DCX2 // Feb 1, 2010 at 10:37 am
Thanks for the post! I love reading this stuff. MORE! ^_^
8 warll // Feb 1, 2010 at 1:37 pm
Oh boy I would love to read more about DSi flash carts. Blasty I love your articles, I learn something everytime I read one plus they are entertaining.
9 Maat // Feb 1, 2010 at 2:12 pm
I would like to know why Nintendo changed the order of boot? Maybe even they original games can use it to know if it’s a dsi or a ds?
Why instead of using original code why they try using they own code but try making the sha equal to another game…..after all there are a lot of games your sha can be equal. Does anybody mayde the count if it’s possible to break it, because of all sha’s possibilities there are?
Nintendo should send a e-mail thanking for discovering that for them…..
10 karlbowden.myopenid.com/ // Feb 1, 2010 at 3:24 pm
I do much appreciate these articles too. Very interesting to see the lengths some companies (don’t) go to to get around circumvention.
I second Maat’s request to Ninty too.
11 warll // Feb 1, 2010 at 4:27 pm
@Maat: I imagine they changed it so that they could check for a RSA header before testing against the list of known hashes. While as far as I know they could have gone the test then check route they were likely unaware that it would pose a vulnerability.
As to your second point while I have not looked it up I am pretty sure that SHA4 is not vulnerable to hash collision. After all if it was then stealing the code would have been unnecessary, as well Nintedo would be a fool to use a broken hashing algorithm in a new product.
All in all I must say that I am looking forward to a possible run down of flash cart techniques.
“Nintendo should send a e-mail thanking for discovering that for them”
I would expect that Nintedo already knows about this.
12 MatisyahuSerious // Feb 1, 2010 at 5:13 pm
great freaking read, i could eat stuff up like that all day long – but man oh man, aswell and infact aren’t_really_words.
13 Dueler // Feb 1, 2010 at 7:38 pm
I don’t really get how Datel think’s this will pass on retail :\ They have been pushing themselves as a legit company opening the door to media and other optimisations for so long and now they blatantly use G&W code to boot their new product? :\
I seriously am waiting for this lawsuit to come now. And id love to see Datel’s reasoning behind it.
Im just wondering how all their products will come under scrutiny after this, and werent they having issues with microsoft latley over the 3rd party lockout, how will that case look after this is thrown into the light… *that was Datel right?*
14 warll // Feb 1, 2010 at 8:03 pm
The English language would not be the world’s most important one if it wasn’t for our willingness to invent and steal new words when needed.
So remember, every Grammar Nazi is really advocating non-English.
/rant
15 lincruste // Feb 2, 2010 at 3:11 am
No moral issue here. Data must flow.
16 jelbo // Feb 2, 2010 at 3:24 am
Very interesting read, even though I don’t understand the details, but get the overall idea 🙂
offtopic question for bLAStY: What Windows theme is that? I like it very much.
17 blasty // Feb 2, 2010 at 5:05 am
Jelbo: it’s the default ubuntu gnome ‘human’ theme I think. (or the ‘dark’ variant of that or something)
18 Maat // Feb 2, 2010 at 9:56 am
@warll: I didn’t knew sha4 existed, i thought that there are was only sha1 and sha2. Sha3 is being made now with a competition.In the post it says sha1, so it’s broken to hash collissions.
I think they didn’t use this option because it is way more easy to just use the trick posted here….
Maybe while we are writing here, they are trying to break the sha1 so when Nintendo upgrades dsi, they can use a new attack.
19 Sektor // Feb 2, 2010 at 10:45 am
I suppose they could require you to connect an exploitable game to the cart and dump/patch it on powerup or just ship the cart blank and require you to write to it from a PC.
20 Grayda // Feb 2, 2010 at 7:51 pm
I agree with Sektor. A piggyback method could have worked, like the unlicensed games for the NES. But failing that, couldn’t they have said the code was for the sake of “interoperatability”? Much like the breaking of CSS was?
21 umby24 // Feb 2, 2010 at 9:31 pm
Just plain amazing… though i didn’t think that datel would act the same as flash carts…
I know you guys are mostly Nintendo guys when it comes to hacking into stuff like this, but I am curious about another one of Datel’s works, the Action Replay – PSP. I’m interested because they are able to run their action replay software, as if it were signed code, on all PSP systems. (Go, 1000, 2000, 3000) which would mean they either had to pull another trick like this one, or crack SCE’s code for signing applications. Seeing as you guys seem to like reverse engineering, I figured you might be interested. Thanks for the reply, and thanks for this article, quite interesting.
22 Clipper // Feb 2, 2010 at 10:10 pm
That was a really interesting article to read. I can’t say I’m too shocked, given some of Datel’s other recent methods, but it is surprising how blatant it’s getting.
On Nintendo fixing this, couldn’t they just add some randomisation to their startup sequence so that it makes the occasional random and/or duplicated dummy request? That way, even with Datel’s update mechanism, any fixed stream of data would always fail.
23 wiisixtyfour // Feb 2, 2010 at 10:50 pm
@umby24
Apparently PSP Action Replay is installed to the “UPDATE” folder so that probably has something to do with how it runs.
24 Phredreeke // Feb 3, 2010 at 3:50 pm
Grayda: Breaking CSS didn’t use copyrighted data. It was done by reverse engineering a badly done cryptographic scheme (the closest thing I can think to compare it to is the fakesigning bug on the Wii)
25 HyperHacker // Feb 3, 2010 at 6:43 pm
Neat. Curious they hash the binaries and not the cartridge header/filesystem tables; that would have prevented this, wouldn’t it?
On Datel’s side I wonder why they padded with infinite loops instead of NOPs.
I suspect Datel was planning to go for the interoperability defence. Otherwise they’d have included the entire ROM, and honoured the offset field, instead of just replaying a sequence of replies when the commands could change in a future update. This way they have only the bare minimum required to get up and running. Whether that’ll hold up in court (or how that law and DMCA can coexist), I wouldn’t know.
It’s not like Datel doesn’t have a history of releasing products that rely on a security flaw, knowing full well that a firmware update will soon render the product useless. Wii Freeloader, anyone?
26 Grayda // Feb 4, 2010 at 4:27 am
@Phredreeke: It’s true that DeCSS didn’t use copyrighted code. Perhaps I was thinking of use of copyrighted code being an “exception” to the DCMA rule rather than reverse engineering. Thanks for pointing that out. I still do wonder about the “Piggyback” method though..
27 Rafael Vuijk // Feb 4, 2010 at 12:49 pm
Just let the user download the original game onto the card via mini-USB.
Nintendo can’t fix this. Too bad it’s always the companies with money that have the first sales. A lawsuit would be appropriate. I wish they cared more about homebrewers. AR for PSP Go is useless too 🙁
28 reikitsune // Feb 4, 2010 at 10:57 pm
You can use Homebrew with the Action Replay DSi as long as you have a microSD card and the applications on the card. The best part is they work. Team Twiizer, I suggest that this my be like the Twilight Hack for the DSi.
29 Muzer // Feb 5, 2010 at 11:40 am
Nobody gives a **** about DS-mode homebrew – you can do that with flashcarts. What we’re looking for is DSi-mode homebrew (which is already possible, but difficult, with drunkencoders’ exploits)
30 Tweets that mention Lawsuit coming in 3.. 2.. 1.. -- Topsy.com // Feb 5, 2010 at 3:06 pm
[…] This post was mentioned on Twitter by Adrian Burgess and jokergame, Erick Folckemer. Erick Folckemer said: Datel may be suing MS, but hacker claims Nintendo may sue Datel? lol woah. kudos to hackmii: http://tinyurl.com/yajhu4x […]
31 HyperHacker // Feb 5, 2010 at 3:22 pm
The problem with the “upgrade through mini USB” idea is the cartridge probably can’t simply be plugged into a USB cable and upgraded, without it being plugged into a DS with software running to receive the new firmware. That’s difficult if the system won’t boot your cartridge and you don’t have another laying around that will.
They certainly could add circuitry to allow it to be upgraded without a host system, but it doesn’t look like it has that (and knowing Datel, they probably can’t be arsed).
32 hcs // Feb 5, 2010 at 4:34 pm
@HyperHacker:
As I read it they do (or at least may) hash the tables, but the overlay table doesn’t need to be modified: the AR’s code is in the space that the normal overlay would be loaded from (though not the first time when the overlay is hashed), and padded to work nicely in the space where it is loaded into.
33 HenshinMijin // Feb 5, 2010 at 9:40 pm
*In my best movie trailer narrator voice*
In a world, ..where people get paid thousands of dollars to seek out IP theft. One company decides to risk it all! From the producers that brought you Action Replay comes the hit unethical thriller of 2010, ‘Get Sued Or Die Trying’
Rated $$$ – http://www.ripdatel.come onnn
34 RupeeClock // Feb 7, 2010 at 5:24 pm
Well, this is interesting.
It reminds me of the old Galoob Game Genie, which seems to have rom data from the NES Bubble Bobble.
http://www.youtube.com/watch?v=nEDXt8NMq6A
Current Flashcarts trying to run DS mode in the DSi mostly use that Danny Phantom game as the header, which really is shady.
But there’s other weird stuff like being able to use the original AR DS as a PassMe card by holding select whilst booting, I use it often just to boot my Supercard Lite in DS mode.
I bet you guys all already knew that though… 😛
35 SoraHjort // Feb 9, 2010 at 12:57 am
@HyperHacker the ARDSi is setup so that it does not need to be plugged into a DS/DSi for the USB data cable connection to work.
As in you just have to plug the cable itself into the ARDSi cart by itself and it connects to the code manager as is. This makes it so it does not need a powered on DS/DSi system to get code or firmware updates.
36 shuffle2 // Feb 15, 2010 at 6:45 pm
This isn’t really groundbreaking for Datel; They’ve used parts of commercial games in other products as well. I know this is true for the Gamecube AR at least. Seeing as they’re still around I kind of doubt anything will happen.
Also this is tagged with “Wii” :p
37 HyperHacker // Feb 16, 2010 at 11:57 pm
Right on. I haven’t seen one that could do that yet. At least they thought that far ahead.
38 evanextreme // Mar 1, 2010 at 3:15 pm
Hey Blasty, ive been a homebrew user for about a year now, and i have the HB channel, and a DSi action replay.
Recently I discovered the PSP action replay, which actually works by having a program to install it from your pc, and then it functions like a normal PSP app! I was thinking, that if someone could get to the inner workings of what datel does, we could have PSP homebrew without sticking with our current firmware!
do you think team twiizers would be able to find out how it works?
39 fr3sc0 // Mar 16, 2010 at 12:52 pm
Although I don’t really understand everything said I did enjoy this post. Gets me fired up to educate myself more into these things.
*blasty are you by any chance dutch?* Since the pics are hosted at a .nl domain 😉
40 user469 // Mar 20, 2010 at 3:58 pm
@blasty I wonder how iEdge created a legal card with a different help loader that contains no game data when is new . I’m very interested if you can unveil the secrets of DSi compatible DS flashcarts , and also explain why card for the DS are different from card for DSi so they cannot be upgaded and booted in the latest .
41 nitro2k01 // Mar 23, 2010 at 4:52 pm
@evanextreme To the best of my knowledge, the AR for PSP is cryptagraphically signed, which either means Datel has an agreement with Sony or the keys were leaked.
@user469 It seems like iEDGE requires the user to download a ROM image of a game and patch the bootstrap with. They still need a game, but they leave that to the user so that they (iEDGE) don’t have to distribute copyrighted material.
42 ariolander.wordpress.com/ // Mar 25, 2010 at 2:07 am
I wonder how Lexmark International, Inc. v. Static Control Components, Inc.’s supreme court case would apply to this situation?
The United States Court of Appeals for the Sixth Circuit ruled that circumvention of Lexmark’s ink cartridge lock does not violate the Digital Millennium Copyright Act (DMCA).
Lexmark had print toner cartrages that had digital protection chips in them that told them to “expire” even before the ink ran out after, x amount of prints, or x amount of time.
Each cartrage had to go through an encrypted authentication sequence and a checksum matching process.
SCC developed its own computer chip that would duplicate the ‘handshake’ used by the Lexmark chip. SCC’s chip also included a verbatim copy of the loading program, which SCC claimed was necessary to allow the printer to function.
Either way the appelate ruled in favor for SCC saying “‘Lock-out’ codes — codes that must be performed in a certain way in order to bypass a security system — are generally considered functional rather than creative, and thus unprotectable”.
One of the Judges went so far as to say “We should make clear that in the future companies like Lexmark cannot use the DMCA in conjunction with copyright law to create monopolies of manufacturer goods for themselves”
Either way Datel can probably be sued certainly but the legality of such “lockouts” and copying ROMs to bypass security and authentications is still up for debate.
43 user469 // Mar 26, 2010 at 3:01 pm
Can the recent Pwn2Own iPhone exploit used for a DSi ?
The payload used chained return-into-libc (“return oriented programming”) on ARM to execute in spite of code signing. As far as we know, this is the first public demonstration of chainged return-into-libc on thre ARM platform.
44 bushing // Apr 1, 2010 at 9:59 pm
Lexmark vs SCC is an interesting case, and the closest we’ll get to a parallel. I think that if Nintendo sued Datel, it would be an ugly court battle, regardless of the merits. In this case, the almost-a-megabyte-chunk of ROM would be parallel to the 55-byte “Toner Loading Program” in the Lexmark cartridges. Reading the majority opinion, it sounds like they’re saying that the Toner Loading Program should not necessarily be subject to copyright, as it is primarily functional in nature — I don’t think anyone could claim the same about a megabyte of code / data from a video game. There’s a quote on the Wikipedia page for it to the extent that one of the judges said that the same principles should apply, even if the program were more complicated than the TLP — but still, we’re talking several orders of magnitude here, and that statement was more to address the DMCA circumvention claim than the straight-up copyright claim.
I heard the EFF’s Jennifer Granick speak a bit about this recently; she said there generally needs to be a “nexus of infringement” for DMCA cases, which means that some sort of actual IP copyright violation has to be occurring in conjunction with the alleged DMCA violation — meaning, the DMCA should not be used in cases like Lexmark vs. SCC where the real issue is a physical good (like a printer cartridge), as opposed to a movie or computer program. They could still just ignore the DMCA and only try to take on the copyright issue … I don’t know, the whole thing makes my head hurt, and it’s pretty clear that it’s complicated enough that lawyers on both sides would have to put in a lot of time and money to prevail, one way or the other.
45 derfman24 // Apr 7, 2010 at 1:01 pm
My Acekard 2i shows up Danny Phantom Urban Jungle on my DSi, but I eject and insert the cartridge really fast, it will show up with the original Acekard 2i logo.
46 nitro2k01 // Apr 11, 2010 at 5:33 pm
derfman24: But can you boot it when it shows the Acekard logo?
47 macweirdo // May 7, 2010 at 1:39 pm
@nitro2k01: No, the Acekard will just give you an error screen.
You must log in to post a comment.