Hacking Post your ideas regarding how to hack the 3DS, here

[arthurvandijk]

Allright, so we have an encrypted ROM, which consists of: 1. a Header, 2. a Bootloader, 3. the Actual Game. Would it be possible to keep the current Header and bootloader encrypted and in place, while replacing the code segment to which the bootloader points to with some decrypted (or unsigned custom) executable?

Also, I remember those bulky LPT cables, which were connected to large dongles, in which we could slide a GBA-cartridge sized flash cart. Then, we'd use software to flash the NAND of that cart with a single game, which we then could play as if it were a real cartridge. (Fooling even the GC Gameboy Player, and a vareity of GC Games with linking ability, like HM:AWL. I believe The same can be done with 3DS games, as developers use a nintendo branded flashable cartridge to test games on regular 3DS consoles. Of course, a more usable USB connected dongle to Dump Original games and Flash the Flashcart would be nice... Then again, even if this would be pulled off, we'd still not have a way of running unsigned code.

However: There's still a possibility we can do stuff with the downloadable content of the 3DS. For the sake of research, I've been meddling around with some of the GBA titles only obtainable for participants of the "3DS Ambassador Programme". These are my findings: (mind you, I have no way of knowing this for certain, as all files are encrypted, and I have no way to decrypt most of them.)

For the GBA "emulated" games (I'll explain later why emulated is encapsulated by quotes), this is the file structure on the SD card after download and playing at least once:

|- 
|- 
|- 
|- 
|- 
|- 
|   |- 00000001.sav
|- 
|- 
|   |- 00000001.cmd
|- 00000000.tmd
|- 00000002.app
|- 00000003.app

My explanation:

00000001.sav: obviously, this would be the Game's saved data. Encrypted, probably unsigned due to checksums or CRC.

00000000.tmd: Seems to be the ticket file, telling the 3DS if this console is eligable to use this title, using the unique console ID. Encrypted and most definitly Signed, as this would be the key point to distribute "3DS-Ware".

00000001.cmd: I suspect this to be a bootloader to tell the 3DS to disable some hardware, go into some hardware assisted virtual mode and presumably sandbox the game and memory used by it. Encrypted, probably signed.

00000002.app: This appears to be the ROM file, but encrypted and probably signed.

00000003.app: Due to the huge file size differences from GBA game to GBA game (from ~1200kB to ~1800kB) I doubt this is an emulator (hence my quotes by emulated above). I have yet to see an encryption algorithm to cause such huge file size differences. I suspect it to be merely a "converted function file", to assist the 3DS hardware to run code native to the GBA. Especially thinking about how Nintendo at this time claims the GBA games probably won't be made publicly available, I suspect them to be game-specific, as in only functions this game needs are in there. This defeats the probability of ROM injection, and would be a Nintendo way to block such attempts.

IMHO, to get somewhere, we first need to crack the ticket file. This would give us insights how to make the 3DS accept custom code. But then again, I could be completely off...

*edited: copy and paste made a number of unnecessary linebreaks

 

[wchill]

Allright, so we have an encrypted ROM, which consists of: 1. a Header, 2. a Bootloader, 3. the Actual Game. Would it be possible to keep the current Header and bootloader encrypted and in place, while replacing the code segment to which the bootloader points to with some decrypted (or unsigned custom) executable?

Also, I remember those bulky LPT cables, which were connected to large dongles, in which we could slide a GBA-cartridge sized flash cart. Then, we'd use software to flash the NAND of that cart with a single game, which we then could play as if it were a real cartridge. (Fooling even the GC Gameboy Player, and a vareity of GC Games with linking ability, like HM:AWL. I believe The same can be done with 3DS games, as developers use a nintendo branded flashable cartridge to test games on regular 3DS consoles. Of course, a more usable USB connected dongle to Dump Original games and Flash the Flashcart would be nice... Then again, even if this would be pulled off, we'd still not have a way of running unsigned code.

However: There's still a possibility we can do stuff with the downloadable content of the 3DS. For the sake of research, I've been meddling around with some of the GBA titles only obtainable for participants of the "3DS Ambassador Programme". These are my findings: (mind you, I have no way of knowing this for certain, as all files are encrypted, and I have no way to decrypt most of them.)

For the GBA "emulated" games (I'll explain later why emulated is encapsulated by quotes), this is the file structure on the SD card after download and playing at least once:

|- 
|- 
|- 
|- 
|- 
|- 
|   |- 00000001.sav
|- 
|- 
|   |- 00000001.cmd
|- 00000000.tmd
|- 00000002.app
|- 00000003.app

My explanation:

00000001.sav: obviously, this would be the Game's saved data. Encrypted, probably unsigned due to checksums or CRC.

00000000.tmd: Seems to be the ticket file, telling the 3DS if this console is eligable to use this title, using the unique console ID. Encrypted and most definitly Signed, as this would be the key point to distribute "3DS-Ware".

00000001.cmd: I suspect this to be a bootloader to tell the 3DS to disable some hardware, go into some hardware assisted virtual mode and presumably sandbox the game and memory used by it. Encrypted, probably signed.

00000002.app: This appears to be the ROM file, but encrypted and probably signed.

00000003.app: Due to the huge file size differences from GBA game to GBA game (from ~1200kB to ~1800kB) I doubt this is an emulator (hence my quotes by emulated above). I have yet to see an encryption algorithm to cause such huge file size differences. I suspect it to be merely a "converted function file", to assist the 3DS hardware to run code native to the GBA. Especially thinking about how Nintendo at this time claims the GBA games probably won't be made publicly available, I suspect them to be game-specific, as in only functions this game needs are in there. This defeats the probability of ROM injection, and would be a Nintendo way to block such attempts.

IMHO, to get somewhere, we first need to crack the ticket file. This would give us insights how to make the 3DS accept custom code. But then again, I could be completely off...

*edited: copy and paste made a number of unnecessary linebreaks

That's not that far off. One of the best posts I've seen in this thread. However, as you say yourself, the signature checks have to be defeated. Tickets are not as important, though of course the 3DS will need one to be authorized to install whatever software that ticket corresponds to. You are correct in thinking that the GBA games are not emulated (why do it when the ARM processor in the 3DS can handle GBA code natively?). Those support libraries you talk about in 00000003.app would probably be for modified timing/graphics/sound routines that would differ from the 3DS and GBA, whereas the DS had an ARM7 processor and GBA-specific hardware that could just kick in when a GBA game was run.

However, because certain 3DS functions are disabled in GBA hypervisor mode (such as the 3D as well as cameras, possibly wireless as well as any other unnecessary functions), injecting code into these will not help us too much. We'd still be missing a lot of things. I'm guessing that the HOME button works by setting a software interrupt when the button is pressed, triggering the appropriate action, which would make sense (DS games run in a hypervisor - HOME pauses the game and launches a menu asking whether to return, 3DS games are paused and suspended when going HOME, trying to go HOME while playing online in MK7 is not allowed - most likely a flag to disable the HOME interrupt). The functions that are disabled would then only be re-enabled when returning HOME, as the code that handles the interrupt would also be handling the hardware and would be running at a lower layer than the game/hypervisor.

(This is speculation, I'll admit, but I think this is pretty accurate)

If you flip the wireless switch on and then off while in a VC/GBA game, does that do anything? Just curious. Too lazy to do it on my own 3DS.

So I totally didn't read up on 3DS security, but what if we have a cart, that takes a retail 3DS card for authentication, then using a timer, routes data from some sort of external memory as the game data? The authentication step is similar to what the original PassMe did.

Isn't this what current DSi carts in DS Mode do? They basically have a retail game in the bootloader that's been modified to jump to the flashcard's menu.
Of course, we can't modify 3DS software or even DSi software to do this yet (damn the lack of keys). The iEvo uses a save game exploit, which is different from how the original PassMes worked. Correct me if I'm wrong, but Martin Korth's successful crack of the encryption on DS games allowed us to modify said games for whatever purpose (leading us to the NoPass, since the DS didn't perform enough checking to make sure that a "game" really was a game instead of relying on just the encryption itself - now we have signature checking and such).

 

[Dionysus]

[media]http://www.youtube.c...feature=related[/media]


.... Real???

Have you guys read the youtube comments? I wonder why so many people commented that it works. I wonder if it could be real. So many people have said that Star Fox and Zelda work. I have been trying to crack the password, because I can't find it on the website they say it is on. I haven't had success with cracking it though. If anyone wants to crack it, you should post what you find.

Can someone confirm this is true or not?

 

[wchill]

[media]http://www.youtube.c...feature=related[/media]


.... Real???

Have you guys read the youtube comments? I wonder why so many people commented that it works. I wonder if it could be real. So many people have said that Star Fox and Zelda work. I have been trying to crack the password, because I can't find it on the website they say it is on. I haven't had success with cracking it though. If anyone wants to crack it, you should post what you find.

Can someone confirm this is true or not?

The fact that the video doesn't show anything other than someone playing a game is suspicious, for one.
Another telltale sign of a fake is that it requires surveys to get the password (claims DMCA, but if so, the video would have been taken down too, no?)
Classic money-making scam.

Additional proof:
I managed to load the site without doing a survey and it just turns out that the site is a blog with an auto-posting script. Evidence enough?

 

[frogboy]

Can someone confirm this is true or not?

It's someone playing SSFIV backwards.

 

[MewtwoEx]

I really think its a scam,especially since most Youtube guys are a bunch of brainless dudes, I just cant see it happening that so many people are making it ¨supposedly¨work, and funny enough n one posts the password, actually I did read some one posting a password but of course it didnt work with the file I downloaded, all those thumbs up must be part of the scheme, when I try going to that page to retrieve the password it forces me to fill up a survey and give me cell number, so yeah I´d call it fake, funny how they wont show how to boot the game either

 

[mysticwaterfall]

Yep, its real. Playing all your games backward is a little bit of a hassle, but I'm starting to get used to it. Even though it makes figuring out the objectives in shadow wars a little tough at times, since all the text is mirrored as well.

 

[Felipe_9595]

[media]http://www.youtube.c...feature=related[/media]


.... Real???

Have you guys read the youtube comments? I wonder why so many people commented that it works. I wonder if it could be real. So many people have said that Star Fox and Zelda work. I have been trying to crack the password, because I can't find it on the website they say it is on. I haven't had success with cracking it though. If anyone wants to crack it, you should post what you find.

Can someone confirm this is true or not?

The fact that the video doesn't show anything other than someone playing a game is suspicious, for one.
Another telltale sign of a fake is that it requires surveys to get the password (claims DMCA, but if so, the video would have been taken down too, no?)
Classic money-making scam.

Additional proof:
I managed to load the site without doing a survey and it just turns out that the site is a blog with an auto-posting script. Evidence enough?

Well, the other day i was searching for Minecraft Xray + Modloader in google and i ended looking at a video of this kind. The download was protected by a password that was stored on a survey site. So i did the survey, i got the password, i tested the mod and it worked, so this might be true.

 

[Kioku]

A quaint little theory? Exploit through saves.. The same way the Twilight Exploit worked. Just a different game. Just my thoughts...

 

[Deleted member 282441]

Save file exploit seems best as of now. On the other hand, maybe a hard mod is a good way. We could solder a chip over the other one... But encryption would make this fail, wouldn't it.

 

[arthurvandijk]

However, because certain 3DS functions are disabled in GBA hypervisor mode (such as the 3D as well as cameras, possibly wireless as well as any other unnecessary functions), injecting code into these will not help us too much. We'd still be missing a lot of things. I'm guessing that the HOME button works by setting a software interrupt when the button is pressed, triggering the appropriate action, which would make sense (DS games run in a hypervisor - HOME pauses the game and launches a menu asking whether to return, 3DS games are paused and suspended when going HOME, trying to go HOME while playing online in MK7 is not allowed - most likely a flag to disable the HOME interrupt). The functions that are disabled would then only be re-enabled when returning HOME, as the code that handles the interrupt would also be handling the hardware and would be running at a lower layer than the game/hypervisor.

(This is speculation, I'll admit, but I think this is pretty accurate)

If you flip the wireless switch on and then off while in a VC/GBA game, does that do anything? Just curious. Too lazy to do it on my own 3DS.

Just tried it this morning, and curiously enough, wireless seems to be operational during GBA Hypervisor. However, I did notice the Wireless LED stop blinking during GBA play, so my guess is that even though the wireless is still operational, it won't do anything, because there is no code or software communicating with it. The switch still turns it off and on though... Too bad we don't have a way of running a ROM with GBA Wireless adapter support to test more.

Also notable: the GBA games DON'T pause (unlike any other software on the 3DS) when the HOME menu is being displayed. Probably to ensure timing is upheld?

Edit:

So I tried something else today, involving swapping files on the SD card. I moved all the contents in my title folder to another folder, effectively making the 3DS unable to load any data. I left just one title in there. When I reinserted the SD and power the 3DS back on, all software I had is still displayed in the system menu, with the normal icon. Selecting any non existing title resulted in not displaying the normal channel info on the top screen. Trying to start a non existing title gives the message "Unable to launch title. Please visit the Nintendo eShop and download it again." (translated from my native tongue: dutch, the actual english message may be different). The title I apparently left on the 3DS was "Metroid Fusion", which has a title ID of 00075700.

My next step in the process, I turned off the 3DS (the system will nag if the SD card is removed when powered on, but not when it's closed and stays closed until the SD card is reinserted), removed the SD card again, and swapped the files in the metroid folder with a similar title. The files I swapped out at first were 00000002.app and 00000003.app, since those actually contain the game. The results were as if the files weren't there, meaning either 00000002.app or 00000003.app (or both) contain a title ID or other signature that must correspond to the ticket file 00000000.tmd.

Curious as I am, I swapped that one out too. Same result: no go. This leads me to think that the name of the folder containing the title has to match the title ID presented by the ticket file. Restoring all files from a backup I made on my PC made all titles operational again.

The icons not disappearing had me interested, so I took another look at the SD card structure. I found this:

|- 
|- 
|- 
|  |- import.db
|  |- title.db
|- 
|  |- 
|	|- 
|	  |- 
|		|- 000000XX
|- 
|-

Deleting the title.db file in the dbs folder, resulted in losing all icons from 3DSWare from my system menu. DSiWare and system icons were still in place (but since those reside in my system memory, that was to be expected).

My conclusions thus far:

• 3DSWare must reside in its OWN titleID folder in the title folder, which must be a match with the actual titleID in the ticket.
• 3DSWare icons (and their locations in the system menu) are stored in the title.db database file.
• It is possible to have a multi-SD Card setup, where every SD Card can contain its own collection of 3DSWare. (Be aware that Streetpass Mii-Park also saves to the SD card when using this)
• When a system icon is moved to a place occupied by a temporarily removed 3DSWare icon, and the DB becomes available again, the system icon takes precedence over the 3DSWare icon, moving the latter to the first available slot from the left in the system menu. Removing the SDCard followed by returning the system icon to its place before, then reinserting the SDCard will result in the 3DSWare icon displaying in its original location, so the location is also stored in the title.db file.
• For 3DSWare to show up in the system menu, a corresponding entry has to exist in the title.db file, which also contains the icon and location for that title. To actually launch the title, a valid ticket file must be present in the 3DSWare's content folder, as well as the .app files that are consistent with the titleID presented by the ticket and folder name. The ticket file probably also contains the 3DS's unique Console ID.

Since both my daughters also have a 3DS, I'll try and see if I can get my software to show up in their menu's, proving (or disproving, for that matter) that the ticket file includes the console ID.

*edited again: corrected some spelling errors

 

[Janthran]

@Arthur: I have a few of thoughts questions about that.
1. Will renaming some folders change anything?
2. Would it be possible to get custom icons by editing title.db?
3. What's import.db?

 

[wchill]

@Arthur: I have a few of thoughts questions about that.
1. Will renaming some folders change anything?
2. Would it be possible to get custom icons by editing title.db?
3. What's import.db?

1. Yes. Don't know how it will affect the 3DS since I'm too lazy to test, but yes it will.
2. Possibly. title.db might be signed/encrypted as well. However, I also just realized that if it isn't, this may be another point of attack (unless N decides to make it signed and encrypted before we can do so).
3. Try deleting import.db or renaming it and see

 

[arthurvandijk]

@Arthur: I have a few of thoughts questions about that.
1. Will renaming some folders change anything?
2. Would it be possible to get custom icons by editing title.db?
3. What's import.db?

@Janthran:
1. renaming folders causes some or all titles to dissapear (changing either "key1", "key2" or "dbs"), or the inability to launch the titles (title, or the titleID folders)
2. It looks like title.db is encrypted, but it seems to be a form of encryption where the encoded data takes up the same space as decoded data, as each entry (as far as I could make out in a HEX editor) has the same size. Every entry however, is filled up with FF bytes when the entry would be too small.
3. the import.db seems to be used in conjuncture with the title.db file. Removing it results in disappearing icons as well. My best guess ATM is that one stores the title, location and some other data, while the other stores the actual icon. Both db files are the exact same size (3.269.632 bytes).

I also discovered that if you have a lot of software downloaded on the 3DS, the capacity of the system menu will expand automatically (effectively giving me twice as much room to locate and store icons).

Edit: I hate to double post

Heh, wchill beat me to the punch there...

... Anyways, continuing on with my experiment:
Using another 3DS' db files and corresponding tickets won't work, even if you have the exact same titles installed (my daughters are participants of the Ambassador Programme too). Probably title.db and/or import.db contain the console ID. Heh, would've been too easy anyway...

Another consideration to be made here might be that every file written to SD (except video's, photo's and such) is signed by a certificate unique to each console. In that case, well, unless we found out a way to make the 3DS sign the files for us, we'd basically be locked out, bent over and screwed. Until we flash the 3DS so that signing isn't an issue anymore that is, but that would kill online activities: Every time the eShop or any other online function is accessed (When in 3DS mode, except the browser), the firmware is checked. I don't know if it's only checking the version number, or also the signature, encryption, etc., but not having the latest firmware results in a message saying you need to update to use that function or title. (Needs more testing, All my systems are at the latest version. eShop and 3DS Transfer utility are confirmed on a brand new "coral pink" 3DS bundled with NintenDogs & Cats)

Anyhoo, someone should try to make something out of those db files...

 

[NeoGohan]

http://www.gonintendo.com/?mode=viewstory&id=168953

nintendo offering an update for a game??
this game had an exploit confirmed

 

[wchill]

htp://www.gonintend...story&id=168953

nintendo offering an update for a game??
this game had an exploit confirmed

Exploits do not apply across different platforms.
3,269,632 bytes seems a little small for the icons. Try removing one app and recheck the size?

 

[arthurvandijk]

3,269,632 bytes seems a little small for the icons. Try removing one app and recheck the size?

Added one app instead, didn't change the size. Someone with a fairly new 3DS (downloaded just 1 or 2 titles) should check, since I noticed the increase in System menu space didn't revert when I removed all of my software.

Also, a PNG icon of a 32x32 size is about 1kB... I've seen no moving icons so far, except for the DSi icons, but let's be safe and say a system menu icon will be about 8kB. In 3MB of space we would be able to store about 350 icons. (probably less, but more that enough). I also suspect that this file will be increased in size by the system menu should the need arise.

 

[wchill]

3,269,632 bytes seems a little small for the icons. Try removing one app and recheck the size?

Added one app instead, didn't change the size. Someone with a fairly new 3DS (downloaded just 1 or 2 titles) should check, since I noticed the increase in System menu space didn't revert when I removed all of my software.

Also, a PNG icon of a 32x32 size is about 1kB... I've seen no moving icons so far, except for the DSi icons, but let's be safe and say a system menu icon will be about 8kB. In 3MB of space we would be able to store about 350 icons. (probably less, but more that enough). I also suspect that this file will be increased in size by the system menu should the need arise.

I should have said the 3D animation for the apps, not the icons. :/
Wonder where those are stored?

 

[Janthran]

3,269,632 bytes seems a little small for the icons. Try removing one app and recheck the size?

Added one app instead, didn't change the size. Someone with a fairly new 3DS (downloaded just 1 or 2 titles) should check, since I noticed the increase in System menu space didn't revert when I removed all of my software.

Also, a PNG icon of a 32x32 size is about 1kB... I've seen no moving icons so far, except for the DSi icons, but let's be safe and say a system menu icon will be about 8kB. In 3MB of space we would be able to store about 350 icons. (probably less, but more that enough). I also suspect that this file will be increased in size by the system menu should the need arise.

I should have said the 3D animation for the apps, not the icons. :/
Wonder where those are stored?

Theoretically, could someone have already found them and replaced the DS card slot icon with one of those?
Some of these supposed 3DS flashcarts might have used them like that.

I don't have an SD slot on my computer, so I can't do any of this stuff.

 

[arthurvandijk]

I should have said the 3D animation for the apps, not the icons. :/
Wonder where those are stored?

@wchill:
I believe those are stored in one of the app files, since removing them will result in displaying the icon, but not the topscreen animation.

Theoretically, could someone have already found them and replaced the DS card slot icon with one of those?
Some of these supposed 3DS flashcarts might have used them like that.

@Janthran:
AFAIK the DS card slot icons are stored in the ROM header and replacing it would corrupt it (I seem to remember some kind of hash checking, but I'm not sure). Any up-to-date DSi or 3DS system would reject a corrupted header (or at least refuse to boot it). That's why the bootloaders of modern DS(i) Flashcards are using legit and unmodified ROM headers. Otherwise the Flashcard release groups would've definitely inserted their own logo/icon in today's flashcards, either to show off or to be identifiable. As I remember, the early AceKards did just that, but they won't run on any up-to-date system.