https://www.3dbrew.org/w/api.php?action=feedcontributions&user=CHR15x94&feedformat=atom3dbrew - User contributions [en]2024-03-29T12:17:21ZUser contributionsMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=User:CHR15x94&diff=3933User:CHR15x942012-08-29T20:41:59Z<p>CHR15x94: </p>
<hr />
<div>Hey there. I'm CHR15x94. You probably haven't heard of me, and that's because I haven't really made or done anything useful to contribute to the hacking/homebrew community before. The only semi interesting thing I've made is a half-ass GameBoy (monochrome) emulator, which can be found on EmuTalk (build's old though). I'll create and edit pages here on 3DBrew when I can.<br />
<br />
==Contact Info==<br />
Feel free to contact me through one of the following services/websites.<br />
<br />
[http://www.youtube.com/user/CHR15x94 YouTube]<br />
[http://www.emutalk.net/members/70586-CHR15x94 EmuTalk.net]<br />
<br />
I'm registered on other sites as well, but these are the ones I am most frequently on.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=File_talk:Exefs_dec_Xcution.png&diff=2384File talk:Exefs dec Xcution.png2012-02-23T20:26:59Z<p>CHR15x94: </p>
<hr />
<div>How did you get decrypted content? The 3DS keys haven't been dumped yet, and the encryption layer is atleast as complex as the DSi's. Or is that some kind of debug CXI that was encrypted with a simpler, insecure key? --[[User:Luigi2us|Luigi2us]] 18:59, 23 February 2012 (CET)<br />
:hehe, Xcution has the SDK... btw is it legal to share the key?--[[User:Lazymarek9614|Lazymarek9614]] 19:15, 23 February 2012 (CET)<br />
::Sharing keys is a legal gray area if I'm not mistaken (this would probably be more on the illegal side though). But this is most likely a debug app, so it wouldn't be encrypted with the retail key, so no poking around retail code yet. At least that's how I understand it. Pretty neat though! :) --[[User:CHR15x94|CHR15x94]] 21:26, 23 February 2012 (CET)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Games&diff=2347Games2012-02-14T23:17:23Z<p>CHR15x94: Added Mario Kart 7, and did some reorginzation and other changes.</p>
<hr />
<div>This page lists off many 3DS games and info about them, as well info about the product code and serial format. If the list is missing a game, and you have info about it, feel free to add it to the list.<br />
<br />
Some of these games also have a savegame dumped, which can be downloaded under the Savegame column of the table. Info about the savegames' filesystem can be found on the [[Savegames]] page.<br />
<br />
== Game list ==<br />
Note the [DEMO] in the title name denotes that the game is a demo. Also, when adding games, please keep them in alphabetical order, keeping demos at the start of the list.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! width="35%" | Title<br />
! width="12%" | Serial*<br />
! width="12% | Product Code<br />
! width="5%" | EUR<br />
! width="5%" | USA<br />
! width="5%" | JPN<br />
! width="5%" | ROM Size<br />
! width="5%" | FLASH Size<br />
! width="5%" | FLASH ID<br />
! width="5%" | FLASH Chip #<br />
! width="6%" | Savegame<br />
|-<br />
| [DEMO] Mario Kart 7 (E3)<br />
| ?<br />
| CTR-P-AMKU<br />
| No<br />
| No<br />
| No<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| [DEMO] Nintendogs+Cats (Kiosk)<br />
| LNZ-CTR-ADAP<br />
| CTR-P-ADAP<br />
| Yes<br />
| ?<br />
| ?<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| [DEMO] Super Mario 3D Land<br />
| LNZ-CTR-AREP<br />
| ?<br />
| Yes<br />
| No<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| [DEMO] Super Mario 3D Land (E3)<br />
| ?<br />
| CTR-P-CTAP<br />
| No<br />
| No<br />
| No<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| [DEMO] The Legend of Zelda: Ocarina of Time 3D<br />
| LNZ-CTR-AQEP<br />
| ?<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| Asphalt 3D<br />
| LNA-CTR-ASFE<br />
| CTR-P-ASFE<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| Cubic Ninja<br />
| LNA-CTR-AQNE<br />
| CTR-P-AQNE<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| Dead or Alive - Dimensions<br />
| LNA-CTR-ADDP<br />
| CTR-P-ADDP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Lego Star Wars III: The Clone Wars<br />
| LNA-CTR-ALGP<br />
| CTR-P-ALGP<br />
| Yes<br />
| Yes<br />
| No<br />
| 4GBit<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Mario Kart 7<br />
| LNA-CTR-AMKE<br />
| CTR-P-AMKE<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| Nintendogs+Cats: French Bulldog & New Friends<br />
| LNA-CTR-ADBP<br />
| CTR-P-ADBP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 512kByte<br />
| 0xC22213<br />
| 25L4001<br />
| ?<br />
|-<br />
| One Piece: Unlimited Cruise SP<br />
| LNA-CTR-ALFJ<br />
| CTR-P-ALFJ<br />
| No<br />
| No<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Pilotwings Resort<br />
| LNA-CTR-AWAP<br />
| CTR-P-AWAP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Puzzle Bobble Universe<br />
| LNA-CTR-ABBP<br />
| CTR-P-ABBP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| [[Raving Rabbids: Travel in Time 3D]]<br />
| LNA-CTR-ARBJ<br />
| CTR-P-ARBJ<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| [http://dl.dropbox.com/u/7830918/3DS%20Upload/decrypted.bin de]/[http://dl.dropbox.com/u/7830918/3DS%20Upload/encrypted.bin en]<br />
|-<br />
| Ridge Racer 3D<br />
| LNA-CTR-ARRP<br />
| CTR-P-ARRP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 8GBit<br />
| 512kByte<br />
| 0xC22213<br />
| 25L4001<br />
| ?<br />
|-<br />
| Samurai Warriors - Chronicles<br />
| LNA-CTR-A66P<br />
| CTR-P-A66P<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 512kByte<br />
| 0xC22213<br />
| 25L4001<br />
| ?<br />
|-<br />
| Splinter Cell 3D<br />
| LNA-CTR-ASCP<br />
| CTR-P-ASCP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 16Gbit<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Steel Diver<br />
| LNA-CTR-ASDP<br />
| CTR-P-ASDP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 512kByte<br />
| 0xC22213<br />
| 25L4001<br />
| [http://dl.dropbox.com/u/32759832/3DS_saves/Steel_Diver/decrypted.sav de]/[http://dl.dropbox.com/u/32759832/3DS_saves/Steel_Diver/encrypted.sav en]<br />
|-<br />
| Super Mario 3D Land<br />
| LNA-CTR-AREP<br />
| CTR-P-AREP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Super Monkey Ball 3D NTSC<br />
| LNA-CTR-ASME<br />
| CTR-P-ASME<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 2GBit<br />
| 128kByte<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| Super Monkey Ball 3D PAL<br />
| LNA-CTR-ASMP<br />
| CTR-P-ASMP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 2GBit<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| Super Street Fighter IV - 3D Edition<br />
| LNA-CTR-ASSP<br />
| CTR-P-ASSP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
| [[The Legend of Zelda: Ocarina of Time 3D]]<br />
| LNA-CTR-AQEP<br />
| CTR-P-AQEP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| ?<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| [http://dl.dropbox.com/u/32759832/3DS_saves/Zelda_OoT/decrypted.sav de]/[http://dl.dropbox.com/u/32759832/3DS_saves/Zelda_OoT/encrypted.sav en]<br />
|-<br />
| The Sims 3<br />
| LNA-CTR-AS3P<br />
| CTR-P-AS3P<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 4GBit<br />
| 512kByte<br />
| 0xC22213<br />
| 25L4001<br />
| ?<br />
|-<br />
| Tom Clancy's Ghost Recon: Shadow Wars<br />
| LNA-CTR-AGRP<br />
| CTR-P-ARGP<br />
| Yes<br />
| Yes<br />
| Yes<br />
| 2GBit<br />
| 128kByte<br />
| 0xC22211<br />
| 25L1001<br />
| ?<br />
|-<br />
|}<br />
<br />
Elisherer's Savefile collection: [http://sherer.co.il/saves http://sherer.co.il/saves]<br />
== Serial structure ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]<br />
<br />
Product: Length=2, LN - Product type (Cartridges are LN, Game boxes are TS, Instruction manuals are MA, leaflets are FA, Quick-Start guides are MK)<br />
<br />
Retail/Demo: Length=1, [A/Z] - Retail / Demo<br />
<br />
CTR - 3DS' Codename Rumored to be Horizon<br />
<br />
Type: Length=1, [A/C/H/J/S] - Retail / C is part of the default Serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is eShop Title / S is 3D Classics eShop title.<br />
<br />
Identifier: Length=2, Game's name (made from letters and digits)<br />
<br />
Region: Length=1, [E/P/J] - English (US) / Pal (Europe/Australia) / Japanese (Japan)<br />
<br />
<br />
The longer version of the serial number adds a geographical region (usually because of extra languages)<br />
<br />
Those are 3 letters codes at the end of the serial (can be found mostly on demos).<br />
<br />
i.e. The code of the Canadian version of Mario Kart 7 is CAN [http://imageshack.us/photo/my-images/687/ctrcan.jpg/]<br />
<br />
== Product Code ==<br />
<br />
This is similar to the serial structure, but this is how the 3DS internally identifies 3DS Applications. And follows this structure:<br />
<br />
CTR-[P/N]-[Type][Identifier][Region]<br />
<br />
* P/N - P Generally used for games (note: for detail and dev games this is the same) / N Generally used for built in applications like [[Mii Maker]]<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
<br />
So for example a Japanese copy of Ridge Racer 3D would have a Product Code of "CTR-P-ARRJ" and a Serial of "LNA-CTR-ARRJ"<br />
<br />
The Product Code "CTR-P-CTAP" is the default Product Code for developers.<br />
<br />
You can check the product code at the end of the 'Health & Safety' section of the 'Manual' of your appliction in the Home menu.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:CIA&diff=2217Talk:CIA2012-02-02T22:41:38Z<p>CHR15x94: The link to the CIA example is broken.</p>
<hr />
<div>Good work Lazymarek9614, Now 3dsexplorer on the svn is 0.73 (you can download it from the beta link) supports cia. --[[User:Elisherer|Elisherer]] 21:34, 10 November 2011 (CET)<br />
:@Elisherer where is that beta link?--[[User:3dsguy|3dsguy]] 02:39, 11 November 2011 (CET)<br />
::[[3DSExplorer]], bottom of the bage. --[[User:Elisherer|Elisherer]] 08:09, 11 November 2011 (CET)<br />
<br />
"Each section is cleartext for dev CIAs, for retail CIAs the APP data is encrypted."<br />
: Dev/Production CIA use the same specification. So I'm not sure what you mean by this. <br />
: The "ctrtool" on the CXI page already parses the CIA format, why re-invent the wheel?<br />
"CIA files can be created with the Nintendo 3DS SDK and installed on the 3DS test units by the Dev Menu."<br />
: Please keep the focus on documentation of the spec., we don't want to explain things from the perspective of SDK users- but for someone that knows (potentially) nothing about the 3DS. The SDK does not tell the whole story of most file formats, and most people don't need to know what the SDK can do for them but what they can do without the SDK. - [[User:Jl12|Jl12]]<br />
::: "Dev/Production CIA use the same specification. So I'm not sure what you mean by this. " I originally worded it that way on the page because both CIAs [[User:3dsguy|3dsguy]] uploaded had cleartext APP data, thus I wasn't sure if CTR-SDK had an option for encrypting the dev CIAs. I don't get why [[User:Elisherer|Elisherer]] re-implements about everything ctrtool already does either... --[[User:Yellows8|Yellows8]] 05:26, 12 November 2011 (CET)<br />
::: - Depending on which one it was, the link that was removed initially was a old presentation from e3. It's just out dated enough that the cia format probably hadn't been finalized. Anything before firmwares 0.10.0 - 0.11.0 neither use LZ compression nor encrypt (!) but - except the use of keys, the SDK now produces .cia with close to retail specs. [[User:Jl12|Jl12]]<br />
::::If you like working with the windows command line be my guest. I got more progress looking at the files with 3dsexplorer... (And i'm not re-inventing 3dsexplorer didn't support cia so I added it, I will continue fixing the structure to be as accurate it can be) --[[User:Elisherer|Elisherer]] 09:48, 12 November 2011 (CET)<br />
::::: - I was thinking more the wiki and the "documentation" of the structures then 3dsexplorer tool. (I thought this was based on binaries, though) [[User:Jl12|Jl12]]<br />
:::::I personaly like a command line tool more, but it's really annoying to have for each format another tool. Shall I create a new page for the certs and tickets?--[[User:Lazymarek9614|Lazymarek9614]] 15:06, 13 November 2011 (CET)<br />
::::::The format of the certs/tickets seem to be the same as before,(besides the new signature types already described on the TMD page) not really necessary to create pages for those.(Any info on what cert is used to sign what should be on a /sys/cert.sys page or so later IMO) [[User:Elisherer|Elisherer]], you're re-inventing the wheel aka re-implementing CXI/CIA code which ctrtool had for months, which is a waste of time IMO. --[[User:Yellows8|Yellows8]] 19:24, 13 November 2011 (CET)<br />
:::::::[[User:Yellows8|Yellows8]], I didn't write any new code for the CXI/CCI/TMD/CIA opening, I just copied it from the ctrtool (as I mentioned when I just written the app). The rest (which is the SAVE flash) became the prime goal of the app and with it I discovered a lot of new information. I try implementing most of the file structures we know so it would be more accessible to everyone (Hoping it would help solving more mysteries). I know that now it's not clear why 3dsexplorer opens these sort of files but with time more information will come and it will grow to extract more important information. I hope you understand. --[[User:Elisherer|Elisherer]] 20:27, 13 November 2011 (CET)<br />
::::::Sorry guys, this discussion doesn't really has anything to do with the CIA format. Please choose another page for this or stop it now. @ [[User:Yellows8|Yellows8]]: I think it's not important to create a new page for it too, only some links to the TMD format and wiibrew wiki are necessary.--[[User:Lazymarek9614|Lazymarek9614]] 20:44, 13 November 2011 (CET)<br />
:::::::Other than that TMD code, that CXI/CIA code looks nothing like the ctrtool code to me - but whatever. --[[User:Yellows8|Yellows8]] 22:07, 13 November 2011 (CET)<br />
<br />
: Maybe you guys would like a forum... it would be less clumsy or interefering to the wiki then plastering talk page with comments. Not to mention we could use pictures and attach files directly. I don't mind setting up something like that if it's actually going to be used. [[User:Jl12|Jl12]]<br />
::I think a forum is not a bad idea, but I also don't mind using the Talk page on the wiki aslong as it is relevant. Maybe [[User:Mha|Mha]] can take a look into setting up a forum on the 3dbrew host? --[[User:Neimod|Neimod]] 21:51, 18 November 2011 (CET)<br />
* http://n-dev.net <br />
[[User:Jl12|Jl12]]<br />
: I prefer having a forum running on the 3dbrew host and managed by the 3dbrew administrators. The forum link above is fine for now as a temporary measure. --[[User:Neimod|Neimod]] 04:48, 20 November 2011 (CET)<br />
<br />
Is there any reason it has to be on the 3dbrew host? If it's an issue of forum management I can just move your account(s) to the administrator group. Nobody's forced to use it, of course. [[User:Jl12|Jl12]]<br />
<br />
I agree with Neimod.--Matyapiro31 11:56, 20 November 2011 (CET)<br />
<br />
<br />
The link to [[User:Jl12|Jl12]]'s CIA example is broken (probably since the FBI took down MegaUpload). Could someone re-upload it somewhere else? Thanks! [[User:CHR15x94|CHR15x94]] 23:41, 2 February 2012 (CET)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Friend_code&diff=2110Friend code2011-12-31T22:16:45Z<p>CHR15x94: Typo</p>
<hr />
<div>This is a list of friend codes of different users.<br />
<br />
Remember to [http://3dbrew.org/w/index.php?title=Friend_code&action=watch watch this article] if you wish to get notified when someone modifies the list.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! width="32%" | User<br />
! width="20%" | Friend code<br />
! width="8%" |Region<br />
! width="30%" |Comment here<br />
! |Mii image<br />
|-<br />
| Matyapiro31<br />
| <nowiki>3351-4131-7014</nowiki><br />
| Japan<br />
| Let's hack 3DS! I changed my code.Add again, please.<br />
| [[File:HNI 0019.JPG|120px]]<br />
|-<br />
| Crediar<br />
| 2535-3625-3742<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| Kazuma<br />
| 2277-6646-9164<br />
| Europe<br />
| None<br />
|<br />
|-<br />
| SaltyPancakes<br />
| 0044-2836-4738<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| Inspectah<br />
| 3909-7495-9525<br />
| Europe<br />
| None<br />
|<br />
|-<br />
| XanLoves<br />
| 3995-6523-2805<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| muhkuh2005<br />
| 2449-4689-9707<br />
| Europe<br />
| Germanfag<br />
|<br />
|-<br />
| RHOPKINS13<br />
| 4854-6450-1577<br />
| USA<br />
| None<br />
| [[File:RHOPKINS13_Mii.JPG]]<br />
|-<br />
| fishuyo<br />
| 2535-3630-0678<br />
| USA<br />
| None<br />
|<br />
|-<br />
| marcosxd<br />
| 0216-0901-5448<br />
| Mexico<br />
| Crediar add me please, I already added you :)<br />
|<br />
|-<br />
| Mafril<br />
| 5112-3460-1421<br />
| USA<br />
| None<br />
| [[File:Mafril_Mii.JPG]]<br />
|-<br />
|Epicdude<br />
|0130-1922-3022<br />
|USA<br />
|<br />
|-<br />
|David<br />
|3553-9962-0973<br />
|USA<br />
|Add me<br />
|<br />
|-<br />
| Muzer<br />
| 3136-6762-5385<br />
| Europe<br />
| I have added everyone on this list who has a valid friend code (David and marcosxd don't) - so please add me if you get the chance.<br />
| [[File:Muzer_Mii.jpg|120px]]<br />
|-<br />
| Rikku2000<br />
| <nowiki>1461-6425-0347</nowiki><br />
| Germany<br />
| None<br />
|<br />
|-<br />
|Elisherer<br />
|0001-3489-0550<br />
|USA<br />
|None<br />
|[[File:Elisherer_Mii.JPG|120px]]<br />
|-<br />
|Liam87<br />
|2664-2361-9358<br />
|England<br />
|Add me please, i have added everyone on here, thank you<br />
|<br />
|-<br />
|Luishane<br />
|1289-8459-2533<br />
|Venezuela<br />
|Add me...thanks<br />
|<br />
|-<br />
|Immortal_no1<br />
|0516-7257-0011<br />
|UK<br />
|Add me and PM me on gbatemp.net with yours or e-mail me on "immortal_no1@hotmail.com"<br />
|<br />
|-<br />
|CrimsonΣ (CrimsonSigma)<br />
|5284-1673-1864<br />
|Brazil<br />
|Add me<br />
|<br />
|-<br />
|E-Chan<br />
|2062-9187-2394<br />
|Spain<br />
|Add me please~! Im up for online gaming of any sorts and discussing the scene!<br />
|<br />
|-<br />
|Lazymarek9614<br />
|1590-4676-4678<br />
|Europe<br />
|Online gaming SSF IV 3D, I try to add everyone here!<br />
|<br />
|-<br />
<br />
|FireFly<br />
|4554-0352-3499<br />
|Europe<br />
|<br />
|-<br />
<br />
|Hikari06<br />
|5241-1966-6545<br />
|Europe<br />
| I added everyone, please add me :) <br />
|[[File:HIKARI06MII.jpg|120px]]<br />
<br />
|-<br />
|CVosler<br />
|4554-0499-6731<br />
|USA<br />
| I added everyone. You can also email me your code after you add me "cvosler@hotmail.com"<br />
|[[File:Chip.JPG|120px]]<br />
<br />
|-<br />
|[[User:CHR15x94|CHR15x94]]<br />
|0688-5814-3517<br />
|Canada (USA)<br />
| Feel free to add me. I'll add anyone. If you need to contact me, message me on 3DBrew, or through one of my contacts on my 3DBrew profile.<br />
|[[File:CHR15x94_-_Mii.JPG|120px]]</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Friend_code&diff=2106Friend code2011-12-31T02:13:41Z<p>CHR15x94: Finally got a 3DS, added my Friend Code. Feel free to add me! :D</p>
<hr />
<div>This is a list of friend codes of different users.<br />
<br />
Remember to [http://3dbrew.org/w/index.php?title=Friend_code&action=watch watch this article] if you wish to get notified when someone modifies the list.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! width="32%" | User<br />
! width="20%" | Friend code<br />
! width="8%" |Region<br />
! width="30%" |Comment here<br />
! |Mii image<br />
|-<br />
| Matyapiro31<br />
| <nowiki>3351-4131-7014</nowiki><br />
| Japan<br />
| Let's hack 3DS! I changed my code.Add again, please.<br />
| [[File:HNI 0019.JPG|120px]]<br />
|-<br />
| Crediar<br />
| 2535-3625-3742<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| Kazuma<br />
| 2277-6646-9164<br />
| Europe<br />
| None<br />
|<br />
|-<br />
| SaltyPancakes<br />
| 0044-2836-4738<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| Inspectah<br />
| 3909-7495-9525<br />
| Europe<br />
| None<br />
|<br />
|-<br />
| XanLoves<br />
| 3995-6523-2805<br />
| Europe<br />
| None<br />
| <br />
|-<br />
| muhkuh2005<br />
| 2449-4689-9707<br />
| Europe<br />
| Germanfag<br />
|<br />
|-<br />
| RHOPKINS13<br />
| 4854-6450-1577<br />
| USA<br />
| None<br />
| [[File:RHOPKINS13_Mii.JPG]]<br />
|-<br />
| fishuyo<br />
| 2535-3630-0678<br />
| USA<br />
| None<br />
|<br />
|-<br />
| marcosxd<br />
| 0216-0901-5448<br />
| Mexico<br />
| Crediar add me please, I already added you :)<br />
|<br />
|-<br />
| Mafril<br />
| 5112-3460-1421<br />
| USA<br />
| None<br />
| [[File:Mafril_Mii.JPG]]<br />
|-<br />
|Epicdude<br />
|0130-1922-3022<br />
|USA<br />
|<br />
|-<br />
|David<br />
|3553-9962-0973<br />
|USA<br />
|Add me<br />
|<br />
|-<br />
| Muzer<br />
| 3136-6762-5385<br />
| Europe<br />
| I have added everyone on this list who has a valid friend code (David and marcosxd don't) - so please add me if you get the chance.<br />
| [[File:Muzer_Mii.jpg|120px]]<br />
|-<br />
| Rikku2000<br />
| <nowiki>1461-6425-0347</nowiki><br />
| Germany<br />
| None<br />
|<br />
|-<br />
|Elisherer<br />
|0001-3489-0550<br />
|USA<br />
|None<br />
|[[File:Elisherer_Mii.JPG|120px]]<br />
|-<br />
|Liam87<br />
|2664-2361-9358<br />
|England<br />
|Add me please, i have added everyone on here, thank you<br />
|<br />
|-<br />
|Luishane<br />
|1289-8459-2533<br />
|Venezuela<br />
|Add me...thanks<br />
|<br />
|-<br />
|Immortal_no1<br />
|0516-7257-0011<br />
|UK<br />
|Add me and PM me on gbatemp.net with yours or e-mail me on "immortal_no1@hotmail.com"<br />
|<br />
|-<br />
|CrimsonΣ (CrimsonSigma)<br />
|5284-1673-1864<br />
|Brazil<br />
|Add me<br />
|<br />
|-<br />
|E-Chan<br />
|2062-9187-2394<br />
|Spain<br />
|Add me please~! Im up for online gaming of any sorts and discussing the scene!<br />
|<br />
|-<br />
|Lazymarek9614<br />
|1590-4676-4678<br />
|Europe<br />
|Online gaming SSF IV 3D, I try to add everyone here!<br />
|<br />
|-<br />
<br />
|FireFly<br />
|4554-0352-3499<br />
|Europe<br />
|<br />
|-<br />
<br />
|Hikari06<br />
|5241-1966-6545<br />
|Europe<br />
| I added everyone, please add me :) <br />
|[[File:HIKARI06MII.jpg|120px]]<br />
<br />
|-<br />
|CVosler<br />
|4554-0499-6731<br />
|USA<br />
| I added everyone. You can also email me your code after you add me "cvosler@hotmail.com"<br />
|[[File:Chip.JPG|120px]]<br />
<br />
|-<br />
|[[User:CHR15x94|CHR15x94]]<br />
|0688-5814-3517<br />
|Canada (USA)<br />
| Feel free to add me. I'll add anyone. If you need to contact me, you can contact me on 3DBrew, or through one of my contacts on the my 3DBrew profile.<br />
|[[File:CHR15x94_-_Mii.JPG|120px]]</div>CHR15x94https://www.3dbrew.org/w/index.php?title=User:CHR15x94&diff=2105User:CHR15x942011-12-31T02:13:35Z<p>CHR15x94: Added my contact info</p>
<hr />
<div>Hey there. I'm CHR15x94. You probably haven't heard of me, and that's because I haven't really made or done anything useful to contribute to the hacking/homebrew community before. The only semi interesting thing I've made is a half-ass GameBoy (monochrome) emulator, which can be found on EmuTalk (build's old though). I'll create and edit pages here on 3DBrew when I can.<br />
<br />
==Contact Info==<br />
Feel free to contact me through one of the following services/websites.<br />
<br />
[http://www.youtube.com/user/CHR15x94 YouTube]<br />
[http://steamcommunity.com/profiles/76561198015628900 Steam]<br />
[http://www.emutalk.net/members/70586-CHR15x94 EmuTalk.net]<br />
[mailto:chrisad@eastlink.ca Email]<br />
<br />
I'm registered on other sites as well, but these are the ones I am most frequently on.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=File:CHR15x94_-_Mii.JPG&diff=2104File:CHR15x94 - Mii.JPG2011-12-31T02:05:27Z<p>CHR15x94: My (CHR15x94's) Mii profile image.</p>
<hr />
<div>My (CHR15x94's) Mii profile image.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Hardware&diff=2011Hardware2011-12-23T21:30:01Z<p>CHR15x94: Added SoC section. Mainly just a small summary about the CPU.</p>
<hr />
<div>{{stub}}<br />
<br />
This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.<br />
<br />
<br />
== Specifications ==<br />
<br />
{| class="wikitable"<br />
! Type !! Name !! Datasheet !! Source<br />
|-<br />
| SoC || Nintendo 1048 0H (Custom): CPU, GPU, VRAM & DSP all on one chip. || N/A || N/A<br />
|-<br />
| Processor Core || ARM11 MPCore 2x 268MHz & 2x VFP Co-Processor || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html] || [11] <br />
|-<br />
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz || N/A || [11] <br />
|-<br />
| DSP || 134Mhz. 24ch 32728Hz sampling rates. || N/A || [11]<br />
|-<br />
| VRAM || 6 MB within SoC. Independent of system memory (FCRAM). || N/A || [11]<br />
|-<br />
| FCRAM || 2x64MB Fujitsu MB82M8080-07L ||[http://crediar.no-ip.com/sg_/download.php?id=d67d1c][http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e511463.pdf][http://edevice.fujitsu.com/jp/datasheet/j-ds/j511463.pdf]|| [5]<br />
|-<br />
| Storage || Toshiba THGBM2G3P1FBAI8 1GB NAND Flash || N/A || N/A<br />
|-<br />
| Power Management || Texas Instruments PAIC3010B 0AA37DW || N/A || FCC filing<br />
|-<br />
| Gyroscope || Invensense ITG-3270 MEMS Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf] || N/A<br />
|-<br />
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || [http://dl.dropbox.com/u/20520664/references/CD00213470.pdf] || N/A<br />
|-<br />
| Wifi || 802.11b/g Atheros AR6014 || [http://www.db.pokestation.net/3DS/Wi-Fi%20module%20pinouts.pdf] || N/A<br />
|-<br />
| Infrared IC || NXP infrared IC, "S750 0803 TSD031C" || N/A || [10]<br />
|-<br />
| Auxiliary Microcontroller || UC CTR, custom Nintendo microcontroller || N/A || N/A<br />
|}<br />
<br />
* [11] Official Documentation<br />
<br />
* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):<br />
<br />
* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).<br />
<br />
* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].<br />
<br />
== FCRAM ==<br />
<br />
There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.<br />
<br />
The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.<br />
<br />
<br />
== SoC ==<br />
<br />
The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.<br />
<br />
According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.<br />
<br />
<br />
== Images ==<br />
<br />
=== Front ===<br />
<br />
[[Image:CTR_Front.jpg|600px]]<br />
<br />
[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]<br />
<br />
=== Back ===<br />
<br />
[[Image:CTR_Back.jpg]]<br />
<br />
[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]<br />
<br />
=== NAND pinout ===<br />
[[Image:CTR_NAND_pinout.png]]<br />
<br />
NAND dumping has been successful, but the image is encrypted.<br />
<br />
=== WiFi dongle pinout ===<br />
[[Image:CTR_WiFiDongle_pinout.png|600px]]<br />
<br />
SDIO interface is colored red: <br />
* CLK<br />
* CMD<br />
* D0, D1, D2, D3<br />
<br />
This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.<br />
<br />
The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.<br />
<br />
I2C eeprom is colored blue:<br />
* SCL<br />
* SDA<br />
<br />
SPI Flash is colored purple:<br />
* CLK<br />
* CS#<br />
* SI<br />
* SO<br />
* WP#<br />
* NC<br />
<br />
=== Auxiliary Microntroller ===<br />
[[Image:CTR_UC.png|600px]]<br />
<br />
Monitors HOME button, WiFi switch, 3D slider, volume control slider.<br />
Controls LEDs, various power supplies.<br />
<br />
Devices attached to I2C bus:<br />
* UC (master?)<br />
* Accelerometer (slave address 0x18)<br />
* SoC (master? slave?)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Hardware&diff=2010Hardware2011-12-23T20:52:29Z<p>CHR15x94: Some cleanup.</p>
<hr />
<div>{{stub}}<br />
<br />
This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are proprietary and are expanded upon here or in other pages.<br />
<br />
== Specifications ==<br />
<br />
{| class="wikitable"<br />
! Type !! Name !! Datasheet !! Source<br />
|-<br />
| SoC || Nintendo 1048 0H (Custom): CPU, GPU, VRAM & DSP all on one chip. || N/A || N/A<br />
|-<br />
| Processor Core || ARM11 MPCore 2x 268MHz & 2x VFP Co-Processor || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html] || [11] <br />
|-<br />
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz || N/A || [11] <br />
|-<br />
| DSP || 134Mhz. 24ch 32728Hz sampling rates. || N/A || [11]<br />
|-<br />
| VRAM || 6 MB within SoC. Independent of system memory (FCRAM). || N/A || [11]<br />
|-<br />
| FCRAM || 2x64MB Fujitsu MB82M8080-07L ||[http://crediar.no-ip.com/sg_/download.php?id=d67d1c][http://edevice.fujitsu.com/fj/DATASHEET/e-ds/e511463.pdf][http://edevice.fujitsu.com/jp/datasheet/j-ds/j511463.pdf]|| [5]<br />
|-<br />
| Storage || Toshiba THGBM2G3P1FBAI8 1GB NAND Flash || N/A || N/A<br />
|-<br />
| Power Management || Texas Instruments PAIC3010B 0AA37DW || N/A || FCC filing<br />
|-<br />
| Gyroscope || Invensense ITG-3270 MEMS Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf] || N/A<br />
|-<br />
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || [http://dl.dropbox.com/u/20520664/references/CD00213470.pdf] || N/A<br />
|-<br />
| Wifi || 802.11b/g Atheros AR6014 || [http://www.db.pokestation.net/3DS/Wi-Fi%20module%20pinouts.pdf] || N/A<br />
|-<br />
| Infrared IC || NXP infrared IC, "S750 0803 TSD031C" || N/A || [10]<br />
|-<br />
| Auxiliary Microcontroller || UC CTR, custom Nintendo microcontroller || N/A || N/A<br />
|}<br />
<br />
* [11] Official Documentation<br />
<br />
* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):<br />
<br />
* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).<br />
<br />
* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].<br />
<br />
== FCRAM ==<br />
<br />
There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.<br />
<br />
The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM*) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.<br />
<br />
== Images ==<br />
<br />
=== Front ===<br />
<br />
[[Image:CTR_Front.jpg|600px]]<br />
<br />
[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]<br />
<br />
=== Back ===<br />
<br />
[[Image:CTR_Back.jpg]]<br />
<br />
[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]<br />
<br />
=== NAND pinout ===<br />
[[Image:CTR_NAND_pinout.png]]<br />
<br />
NAND dumping has been successful, but the image is encrypted.<br />
<br />
=== WiFi dongle pinout ===<br />
[[Image:CTR_WiFiDongle_pinout.png|600px]]<br />
<br />
SDIO interface is colored red: <br />
* CLK<br />
* CMD<br />
* D0, D1, D2, D3<br />
<br />
This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.<br />
<br />
The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.<br />
<br />
I2C eeprom is colored blue:<br />
* SCL<br />
* SDA<br />
<br />
SPI Flash is colored purple:<br />
* CLK<br />
* CS#<br />
* SI<br />
* SO<br />
* WP#<br />
* NC<br />
<br />
=== Auxiliary Microntroller ===<br />
[[Image:CTR_UC.png|600px]]<br />
<br />
Monitors HOME button, WiFi switch, 3D slider, volume control slider.<br />
Controls LEDs, various power supplies.<br />
<br />
Devices attached to I2C bus:<br />
* UC (master?)<br />
* Accelerometer (slave address 0x18)<br />
* SoC (master? slave?)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=17893DS System Flaws2011-12-13T00:11:37Z<p>CHR15x94: Removed some stuff. Added 'Current efforts' section with a link to the amazing RAM dumping setup neimod has been working on for a while. Breathtaking work, neimod!</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.<br />
<br />
==List of 3DS exploits==<br />
There are currently no known 3DS-mode exploits.<br />
<br />
==Current efforts==<br />
There are people working on finding exploits and documenting the 3DS. Here's a list of some current efforts being made to make homebrew on the 3DS possible:<br />
<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's desoldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. Recent photos show that the setup is working quite well, with the 3DS successfully booting up. Pictures of neimod's work can be found on [http://www.flickr.com/photos/neimod/ his Flickr stream].<br />
<br />
==Tips and info==<br />
Information on the 3DS's internals is scarce. There is little information on programming the 3DS available, other than basic information found by taking the 3DS apart, leaks and reverse engineering.<br />
<br />
What this means is if any exploits are found, it would be very difficult to do anything useful with them. Work is currently being done to find out how the 3DS ticks and to aid in finding exploits. See the [[#Current efforts | current efforts]] section of this page for examples and more information.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:News&diff=1319Talk:News2011-09-23T19:24:15Z<p>CHR15x94: News feed split (homebrew/software releases and major releases, vs one for both). Yay or nay?</p>
<hr />
<div>Is the defective by designs campaign really relevant to 3dbrew? Should it really be on the news page? --[[User:Matthew|Matthew]] 06:27, 13 May 2011 (CEST)<br />
<br />
I believe so. Homebrew appears to be a primary target of the Nintendo 3DS EULA and any bricking efforts Nintendo may implement.--[[User:Winmaster|Winmaster]] 17:29, 13 May 2011 (CEST)<br />
<br />
<br />
<br />
It shouldn't be there. This wiki is for cataloging up to date knowledge about the 3ds hardware/software and any development efforts. It is not a bulletin board or a place to solicitate anything - even if its related to the 3DS platform.<br />
<br />
It's also myth and wrong/misinformation. Another reason we shouldn't be hosting or "spreading" it.<br />
<br />
The only argument I've read about that was referencing a statement in the user manual that says something about "interruption of service". There's a service associated with the 3ds. How do you think you get your updates and notifications. Apparently someone believed it meant they're going to "brick" your 3ds. Don't believe everything you come across plz. Do your own homework and check for it up yourself.<br />
<br />
Don't spread misinformation if you don't know either.<br />
<br />
I feel sorry for the one getting those paper bricks ( if the page isn't shut down first ) because he's not responsible for some kid misreading their user manual elsewhere in the world or the lame trends they started, instead of asking somebody else that would have known better. Someone studying law maybe. Not like gbatemp/wiki I guess. >_><br />
<br />
[[User:Jl12|Jl12]] 20:39, 14 May 2011 (CEST)<br />
<br />
What about crown3ds? Is it a fake?--[[User:Lazymarek9614|Lazymarek9614]] 19:30, 16 September 2011 (CEST)<br />
<br />
Why would it be a fake? Crown3DS's website is 50% finished. Fake flashcards never let you know when their website will be completed. --[[User:Kiddyshaq34|Kiddyshaq34]] 19:36, 16 September 2011 (BST)<br />
<br />
For me the video on their page seems to be a fake. It looks like starting a normal SplinterCell3D with its extern hardware (just put the chips on another board). Maybe it's a fake,<br />
but I'm not sure.--[[User:Lazymarek9614|Lazymarek9614]] 20:52, 16 September 2011 (CEST)<br />
<br />
It look's pretty fake. And like [[User:Lazymarek9614|Lazymarek9614]] said, they probably just have the ROM chip from the Splinter Cell cartridge stuck on another board. Also it's directly promoting piracy, so it doesn't belong here. --[[User:CHR15x94|CHR15x94]] 21:26, 16 September 2011 (CEST)<br />
<br />
Why? huf :( --[[User:Jocopoco|Jocopoco]] 15:28, 17 September 2011 (CEST)<br />
:Wow.. If you wouldn't edit this post 3 times too, it might have been overlooked.. --[[User:Elisherer|Elisherer]] 16:22, 17 September 2011 (CEST)<br />
::Yeah, exactly this happens now...--[[User:Lazymarek9614|Lazymarek9614]] 17:53, 17 September 2011 (CEST)<br />
<br />
@[[User:Elisherer|Elisherer]]:<br />
"Move the last entry to the news archive. There should be no more than 4 entrees in the list." <br />
Please don't spam the news like that! Please only move 1 version (latest) of your tool to the news and only change the version number, don't add it again!<br />
Thanks.--[[User:Lazymarek9614|Lazymarek9614]] 14:48, 23 September 2011 (CEST)<br />
:I thought that what I was doing for the last 2 updates... :) . I could delete the 0.3 line if you like and restore the last archived one... --[[User:Elisherer|Elisherer]] 14:59, 23 September 2011 (CEST)<br />
<br />
Just a thought, but would anyone prefer if the news feed were split into two categories, like major news and homebrew/software releases as it is on WiiBrew.org? I know it's not a huge deal now that homebrew isn't currently possible and there are relatively few software releases, but once it is, big news like system updates would be quickly overrun by homebrew releases and what not. I personally would. Thoughts? --[[User:CHR15x94|CHR15x94]] 21:24, 23 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Savegames&diff=1296Savegames2011-09-19T00:44:55Z<p>CHR15x94: </p>
<hr />
<div>This page describes the format, de/encryption, etc. of savegames found in 3DS game cartridges/gamecards. You can find savegames from various 3DS games on the [[Games]] page.<br />
<br />
<br />
=== Encryption ===<br />
<br />
On the 3DS savegames are stored much like on the DS, that is on a FLASH chip in the gamecart. On the DS these savegames were stored in plain-text but on the 3DS a layer of encryption was added. This is highly likely a streamcipher, as the contents of several savegames exhibit the odd behavior that xor-ing certain parts of the savegame together will result in the plain-text appearing.<br />
<br />
The reason this works is because the stream cipher used has a period of 512 bytes. That is to say, it will repeat the same keystream after 512 bytes. The way you encrypt with a stream cipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plain-text (in our case, zeros) you are basically giving away your valuable keystream.<br />
<br />
So how do you use this to decrypt a savegame on a 3DS? First off, you chunk up the savegame into 512 byte chunks. Then, you bin these chunks by their contents, discarding any that contain only FF. Now look for the most common chunk. This is your keystream. Now XOR the keystream with your original savegame and you should have a fully decrypted savegame. XOR with the keystream again to produce an encrypted savegame.<br />
<br />
=== Wear leveling ===<br />
<br />
The 3DS employs a wear leveling scheme on the savegame FLASH chips. This is done through the usage of blockmaps and a journal. The blockmap is located at offset 0 of the flash chip, and is immediately followed by the journal. The initial state is dictated by the blockmap, and the journal is then applied to that.<br />
<br />
First, there are 8 bytes whose purposes are currently unknown. Then comes the actual blockmap.<br />
The blockmap structure is simple:<br />
<pre><br />
struct header_entry {<br />
uint8_t phys_sec; // when bit7 is set, block has checksums, otherwise checksums are all zero<br />
uint8_t alloc_cnt;<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
</pre><br />
<br />
There's one entry per sector, counting from physical sector 1 (sector 0 contains the blockmap/journal).<br />
<br />
The 2 bytes that follow the blockmap are the CRC16 (with starting value 0xFFFF (like modbus)) of the first 8 bytes and the blockmap.<br />
<br />
Then comes the journal.<br />
The journal structure is as follows:<br />
<pre><br />
struct sector_entry {<br />
uint8_t virt_sec; // Mapped to sector<br />
uint8_t prev_virt_sec; // Physical sector previously mapped to<br />
uint8_t phys_sec; // Mapped from sector<br />
uint8_t prev_phys_sec; // Virtual sector previously mapped to<br />
uint8_t phys_realloc_cnt; // Amount of times physical sector has been remapped<br />
uint8_t virt_realloc_cnt; // Amount of times virtual sector has been remapped<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
<br />
struct long_sector_entry{<br />
struct sector_entry sector;<br />
struct sector_entry dupe;<br />
uint32_t magic;<br />
}__attribute__((__packed__));<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
The checksums in the blockmap/journal entries work as follows:<br />
* each byte is the checksum of an encrypted 0x200 bytes large block<br />
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFF) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum<br />
<br />
=== Partitions ===<br />
<br />
There can be multiple partitions on the chip. For some games one is a backup partition, some other games seem to use only one partition, yet other games actually use multiple partitions. Partitions are defined at the start of the de-wearleveled blob. At offset 0x200 into the image, the DIFI blobs start. These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. In order to find the partitions, you will need the uint32_t at 0x9C into the DIFI block, and the uint32_t at 0xA4. The uint32_t at 0x9C describes the length of the hash table at the start of the partition, the uint32_t at 0xA4 is the length of the filesystem. Partitions are catted together, so the end of one partition is the beginning of the next.<br />
<br />
The first partition starts at 0x2000. The hashtable at the start of the partitions describe each in-use block in the partition with a SHA256 of the 0x1000 sized block.<br />
<br />
* The exact location of the partition can vary in each save/game.<br />
* The first two hashes don't seem to be associated with any 0x1000 block.<br />
* (edit) The last 0x20 bytes of the hash table, doesn't appear to change along with the rest of the data and repeats at the end of all other hash-tables, even when the hashes/data are different. (edit) The last 0x20 bytes of the hash table is NULL data, it is because the Hash table is only 0x1E0 in size and the XOR hash is 0x200 in size, so the 0x20 bytes you see at the end is actually 0x20 bytes of (FF) xor'd with the last 0x20 bytes of the key. Thus the data recurs. --[[User:Immortal|Immortal]] 09:14, 19 August 2011 (GMT)<br />
<br />
The hash in the DISA blob hashes 300 bytes of the first DIFI blob.<br />
<br />
* If the uint32 before the hash in the DISA is 0x01, the first DIFI blob is hashed, if it's 0x00 the second DIFI is hashed. The offsets and size for each DIFI can be found beneath the DISA tag (10h, 20h and 18h, 30h relative to the DISA location). <br />
<br />
The last 4 bytes in each DIFI blob are garbage; they appear as FF FF FF FF in an encrypted savegame.<br />
<br />
=== Filesystem ===<br />
<br />
Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live. The header can be found by searching for the string "SAVE" (minus quotation marks) in the savefile. The address where the 'S' is located is the base address for the SAVE header/filesystem.<br />
<br />
The most important information in the savefile is the FST or filesystem table. You can find the FST by first finding the file base offset which is the offset to which all the entries in the FST are relative. The file base offset is a uint16_t at 0x58 from the filesystem start. The FST offset is a uint32_t at 0x6C and is in blocks (which are 0x200 bytes large).<br />
<br />
For example, the Legend of Zelda: Ocarina of Time 3D SAVE header looks like this:<br />
<br />
<pre><br />
00001FF0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ<br />
00002000: 53415645 00000400 20000000 00000000 SAVE.... ....... //Start of SAVE header<br />
00002010: 68000000 00000000 00020000 00000000 h...............<br />
00002020: 00000000 00020000 88000000 00000000 ........ˆ.......<br />
00002030: 03000000 00020000 94000000 00000000 ........”.......<br />
00002040: 09000000 00020000 B8000000 00000000 ........¸.......<br />
00002050: 66000000 00020000 00040000 00000000 f............... //File base offset - 0x0400 (little endian byte ordering)<br />
00002060: 66000000 00020000 00000000 01000000 f............... //FST offset - 0x00000001 (little endian byte ordering) * 0x200<br />
00002070: 00000000 00020000 01000000 01000000 ................<br />
00002080: 08000000 00020000 01000000 00000000 ................<br />
...<br />
</pre><br />
<br />
Once you've found the FST, parsing it is fairly straightforward.<br />
<br />
<pre><br />
struct fs_entry {<br />
u32 node_cnt;<br />
u8 filename[0x10];<br />
u32 index;<br />
u32 unk1; // magic?<br />
u32 block_offset;<br />
u32 file_size;<br />
u32 unk2;<br />
u32 unk3; // flags and/or date?<br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
The first entry is the root directory, easily identifiable by the node_cnt being larger than 1. The node_cnt includes the root directory itself, so there are node_cnt - 1 files in the root directory. The entries that follow after the root directory are the actual files. Reading them out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.<br />
<br />
Here's a follow-up example from the Legend of Zelda: Ocarina of Time 3D:<br />
<pre><br />
//FST entry = SAVE base + File base + (FST offset * 0x200) + (FST entry # * 0x30)<br />
//0x2600 = 0x2000 + 0x400 + (0x1 * 0x200) + (0x0 * 0x30)<br />
<br />
00002600: 03000000 09000000 00000000 00000000 ................<br />
00002610: 00000000 00000000 00000000 00000000 ................<br />
00002620: 00000000 00000000 00000000 00000000 ................<br />
00002630: 01000000 73797374 656D2E64 61740000 ....system.dat..<br />
00002640: 00000000 00000000 D57B1100 02000000 ........Õ{......<br />
00002650: 22000000 00000000 E8121500 00000000 ".......è.......<br />
00002660: 01000000 73617665 30302E62 696E0000 ....save00.bin..<br />
00002670: 00000000 01000000 69921100 03000000 ........i’......<br />
00002680: DC140000 00000000 04000000 00000000 Ü...............<br />
</pre><br />
<br />
=== Initialization ===<br />
<br />
When a save EEPROM contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user. <br />
<br />
<br />
<br />
[[セーブデータ|Japanese]]</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Savegames&diff=1295Savegames2011-09-19T00:16:44Z<p>CHR15x94: Some confusion on IRC about the savefile filesystem. This should make it a bit clearer. Better explaination, new example and new replacement example.</p>
<hr />
<div>This page describes the format, de/encryption, etc. of savegames found in 3DS game cartridges/gamecards. You can find savegames from various 3DS games on the [[Games]] page.<br />
<br />
<br />
=== Encryption ===<br />
<br />
On the 3DS savegames are stored much like on the DS, that is on a FLASH chip in the gamecart. On the DS these savegames were stored in plain-text but on the 3DS a layer of encryption was added. This is highly likely a streamcipher, as the contents of several savegames exhibit the odd behavior that xor-ing certain parts of the savegame together will result in the plain-text appearing.<br />
<br />
The reason this works is because the stream cipher used has a period of 512 bytes. That is to say, it will repeat the same keystream after 512 bytes. The way you encrypt with a stream cipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plain-text (in our case, zeros) you are basically giving away your valuable keystream.<br />
<br />
So how do you use this to decrypt a savegame on a 3DS? First off, you chunk up the savegame into 512 byte chunks. Then, you bin these chunks by their contents, discarding any that contain only FF. Now look for the most common chunk. This is your keystream. Now XOR the keystream with your original savegame and you should have a fully decrypted savegame. XOR with the keystream again to produce an encrypted savegame.<br />
<br />
=== Wear leveling ===<br />
<br />
The 3DS employs a wear leveling scheme on the savegame FLASH chips. This is done through the usage of blockmaps and a journal. The blockmap is located at offset 0 of the flash chip, and is immediately followed by the journal. The initial state is dictated by the blockmap, and the journal is then applied to that.<br />
<br />
First, there are 8 bytes whose purposes are currently unknown. Then comes the actual blockmap.<br />
The blockmap structure is simple:<br />
<pre><br />
struct header_entry {<br />
uint8_t phys_sec; // when bit7 is set, block has checksums, otherwise checksums are all zero<br />
uint8_t alloc_cnt;<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
</pre><br />
<br />
There's one entry per sector, counting from physical sector 1 (sector 0 contains the blockmap/journal).<br />
<br />
The 2 bytes that follow the blockmap are the CRC16 (with starting value 0xFFFF (like modbus)) of the first 8 bytes and the blockmap.<br />
<br />
Then comes the journal.<br />
The journal structure is as follows:<br />
<pre><br />
struct sector_entry {<br />
uint8_t virt_sec; // Mapped to sector<br />
uint8_t prev_virt_sec; // Physical sector previously mapped to<br />
uint8_t phys_sec; // Mapped from sector<br />
uint8_t prev_phys_sec; // Virtual sector previously mapped to<br />
uint8_t phys_realloc_cnt; // Amount of times physical sector has been remapped<br />
uint8_t virt_realloc_cnt; // Amount of times virtual sector has been remapped<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
<br />
struct long_sector_entry{<br />
struct sector_entry sector;<br />
struct sector_entry dupe;<br />
uint32_t magic;<br />
}__attribute__((__packed__));<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
The checksums in the blockmap/journal entries work as follows:<br />
* each byte is the checksum of an encrypted 0x200 bytes large block<br />
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFF) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum<br />
<br />
=== Partitions ===<br />
<br />
There can be multiple partitions on the chip. For some games one is a backup partition, some other games seem to use only one partition, yet other games actually use multiple partitions. Partitions are defined at the start of the de-wearleveled blob. At offset 0x200 into the image, the DIFI blobs start. These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. In order to find the partitions, you will need the uint32_t at 0x9C into the DIFI block, and the uint32_t at 0xA4. The uint32_t at 0x9C describes the length of the hash table at the start of the partition, the uint32_t at 0xA4 is the length of the filesystem. Partitions are catted together, so the end of one partition is the beginning of the next.<br />
<br />
The first partition starts at 0x2000. The hashtable at the start of the partitions describe each in-use block in the partition with a SHA256 of the 0x1000 sized block.<br />
<br />
* The exact location of the partition can vary in each save/game.<br />
* The first two hashes don't seem to be associated with any 0x1000 block.<br />
* (edit) The last 0x20 bytes of the hash table, doesn't appear to change along with the rest of the data and repeats at the end of all other hash-tables, even when the hashes/data are different. (edit) The last 0x20 bytes of the hash table is NULL data, it is because the Hash table is only 0x1E0 in size and the XOR hash is 0x200 in size, so the 0x20 bytes you see at the end is actually 0x20 bytes of (FF) xor'd with the last 0x20 bytes of the key. Thus the data recurs. --[[User:Immortal|Immortal]] 09:14, 19 August 2011 (GMT)<br />
<br />
The hash in the DISA blob hashes 300 bytes of the first DIFI blob.<br />
<br />
* If the uint32 before the hash in the DISA is 0x01, the first DIFI blob is hashed, if it's 0x00 the second DIFI is hashed. The offsets and size for each DIFI can be found beneath the DISA tag (10h, 20h and 18h, 30h relative to the DISA location). <br />
<br />
The last 4 bytes in each DIFI blob are garbage; they appear as FF FF FF FF in an encrypted savegame.<br />
<br />
=== Filesystem ===<br />
<br />
Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live. The header can be found by searching for the string "SAVE" (minus quotation marks) in the savefile. The address where the 'S' is located is the base address for the SAVE header/filesystem.<br />
<br />
The most important information in the savefile is the FST or filesystem table. You can find the FST by first finding the file base offset which is the offset to which all the entries in the FST are relative. The file base offset is a uint16_t at 0x58 from the filesystem start. The FST offset is a uint32_t at 0x6C and is in blocks (which are 0x200 bytes large).<br />
<br />
For example, the Legend of Zelda: Ocarina of Time 3D SAVE header looks like this:<br />
<br />
<pre><br />
00001FF0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ<br />
00002000: 53415645 00000400 20000000 00000000 SAVE.... ....... //Start of SAVE header<br />
00002010: 68000000 00000000 00020000 00000000 h...............<br />
00002020: 00000000 00020000 88000000 00000000 ........ˆ.......<br />
00002030: 03000000 00020000 94000000 00000000 ........”.......<br />
00002040: 09000000 00020000 B8000000 00000000 ........¸.......<br />
00002050: 66000000 00020000 00040000 00000000 f............... //File base offset - 0x0400 (little endian byte ordering)<br />
00002060: 66000000 00020000 00000000 01000000 f............... //FST offset - 0x00000001 (little endian byte ordering) * 0x200<br />
00002070: 00000000 00020000 01000000 01000000 ................<br />
00002080: 08000000 00020000 01000000 00000000 ................<br />
...<br />
</pre><br />
<br />
Once you've found the FST, parsing it is fairly straightforward.<br />
<br />
<pre><br />
struct fs_entry {<br />
u32 node_cnt;<br />
u8 filename[0x10];<br />
u32 index;<br />
u32 unk1; // magic?<br />
u32 block_offset;<br />
u32 file_size;<br />
u32 unk2;<br />
u32 unk3; // flags and/or date?<br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
The first entry is the root directory, easily identifiable by the node_cnt being larger than 1. The node_cnt includes the root directory itself, so there are node_cnt - 1 files in the root directory. The entries that follow after the root directory are the actual files. Reading them out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.<br />
<br />
Here's a follow-up example from the Legend of Zelda: Ocarina of Time 3D:<br />
<pre><br />
00002600: 03000000 09000000 00000000 00000000 ................ //FST entry = SAVE base + File base + (FST offset * 0x200)<br />
00002610: 00000000 00000000 00000000 00000000 ................ //0x2600 = 0x2000 + 0x400 + (0x1 * 0x200)<br />
00002620: 00000000 00000000 00000000 00000000 ................<br />
00002630: 01000000 73797374 656D2E64 61740000 ....system.dat..<br />
00002640: 00000000 00000000 D57B1100 02000000 ........Õ{......<br />
00002650: 22000000 00000000 E8121500 00000000 ".......è.......<br />
00002660: 01000000 73617665 30302E62 696E0000 ....save00.bin..<br />
00002670: 00000000 01000000 69921100 03000000 ........i’......<br />
00002680: DC140000 00000000 04000000 00000000 Ü...............<br />
</pre><br />
<br />
=== Initialization ===<br />
<br />
When a save EEPROM contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user. <br />
<br />
<br />
<br />
[[セーブデータ|Japanese]]</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:CXI&diff=1281Talk:CXI2011-09-16T20:52:33Z<p>CHR15x94: </p>
<hr />
<div>How 3DS system judge encryption type? --[[User_talk:Matyapiro|Matyapiro]]<br />
: Sorry the question is not understood. What do you mean? --[[User:Neimod|Neimod]]<br />
<br />
:: I think that he means "How does the 3DS decide what encryption method must be used" --[[User:Quincy|Quincy]] 23:47, 29 May 2011 (CEST)<br />
<br />
::: That question does not make sense. There are no decisions. It is always AES CTR. --[[User:Neimod|Neimod]]<br />
<br />
Sorry,how does the 3DS decide what key to use for encryption?<br />
--[[User_talk:Matyapiro|Matyapiro]]<br />
: If you figure that out, let us know, thanks. --[[User:Neimod|Neimod]] 02:45, 1 June 2011 (CEST)<br />
There's a common key used to generate output at compile time, when the cci/ctx files are made. Why do you say 128 bit AES CTR though? --[[User:Jl12|Jl12]]<br />
: Because 128-bit AES CTR is used to encrypt those formats. --[[User:Neimod|Neimod]] 15:40, 18 June 2011 (CEST)<br />
<br />
I know *something* is used to encrypt but do we know it is 128 bit AES CTR? --[[User:Jl12|Jl12]]<br />
<br />
Frankly I don't think it was AES. I think it's using RSA for encryption. Besides it already used it once for the 2048-bit signature as you said. Wouldn't it make way more sense to also use it for the encryption scheme. --[[User:Jl12|Jl12]]<br />
: Lol. --[[User:Neimod|Neimod]] 16:06, 20 June 2011 (CEST)<br />
What's funny? So I guess it's just based purely on speculation? You should say so. That way nobody believes something that isn't right. --[[User:Jl12|Jl12]] 22:28, 20 June 2011 (CEST)<br />
: RSA is only used for the signature. After that a symmetric block cipher called AES is used in CTR mode. --[[User:Neimod|Neimod]] 23:32, 20 June 2011 (CEST)<br />
<br />
<br />
How did you get this data? Did you find some way to dump 3DS cartridges? --[[User:Popoffka|Popoffka]] 09:15, 1 June 2011 (CEST)<br />
:Yes, someone found a way to dump the data on 3DS cards. Unfortunately the method cannot be disclosed, and at this point dumping is not really useful since most of the information is encrypted. --[[User:Neimod|Neimod]] 10:03, 1 June 2011 (CEST)<br />
<br />
Do you have any method to run a Dump? and did you find the key for the ctrtool? --[[User:Stevechou|Stevechou]]<br />
:Nope on both questions. --[[User:Neimod|Neimod]] 17:33, 25 June 2011 (CEST)<br />
<br />
There's code in ctrtool that takes the AES counter value from some partition ID and type. I can't help but wonder, how do you know that the counter value is generated this way? And if we know that, isn't it a start to finding out the key? --[[User:Luigi2us|Luigi2us]] 20:17, 25 June 2011 (CEST)<br />
:Sorry this information cannot be disclosed. --[[User:Neimod|Neimod]] 05:17, 27 June 2011 (CEST)<br />
<br />
Anyway, can you read the encrypt datas?<br />
<br />
<br />
Hi! Do we already know where the offset of the ARM11 code is?<br />
And that I got correctly, that the hole 3DS ROM encrypted by AES?<br />
--[[User:Lazymarek9614|Lazymarek9614]] 21:10, 1 August 2011 (CEST)<br />
:Yes, see ctrtool for more exact details. --[[User:Neimod|Neimod]] 17:44, 6 September 2011 (CEST)<br />
<br />
::I mean the offset of the ARM11 code not the exefs. Exefs contains not only the code, right?<br />
::Would CXI be the homebrew application file format, what do you think? If so, then I think we can modify it a bit for homebrew,<br />
::because some parts doesn't make sense.--[[User:Lazymarek9614|Lazymarek9614]] 19:18, 6 September 2011 (CEST) <br />
:::The ExeFS contains only the ARM11 code and the banner. To know the offset of the ARM11 code you would need to scan the ExeFS for the file ".code". <br />
:::As for the homebrew file format, I think it's a little too early for that. Whatever happens, happens. --[[User:Neimod|Neimod]] 23:12, 6 September 2011 (CEST)<br />
::::Thanks, but please can you give me the parameters for your tool to decrypt the ExeFS and save it? The usage for that is a bit ununderstandable.--[[User:Lazymarek9614|Lazymarek9614]] 20:01, 7 September 2011 (CEST)<br />
:::::One of the parameters to use this tool is the master decryption key, which is currently not known. So at this point, nobody can use this tool to decrypt the ExeFS. --[[User:Neimod|Neimod]] 03:12, 8 September 2011 (CEST)<br />
::::::This master decryption key, is it used for every game? For the 3ds homebrew format I will create a tool which includes a 3d model, an icon and the machine code in the file. However, before we should think about the structure for it. I know that's a bit early, but later (when we can run homebrew) we will be glad if we have it.--[[User:Lazymarek9614|Lazymarek9614]] 20:14, 9 September 2011 (CEST)<br />
:::::::We can also use the elf Format for homebrew--[[User:ichfly|ichfly]]<br />
::::::::Yes, but it has not a banner.--[[User:Lazymarek9614|Lazymarek9614]] 16:54, 10 September 2011 (CEST)<br />
:::::::::Shall I create a new talk about the homebrew format? We should discuss and plan it a bit.--[[User:Lazymarek9614|Lazymarek9614]] 11:08, 11 September 2011 (CEST)<br />
::::::::::Yes, you shall.. --[[User:Elisherer|Elisherer]] 11:55, 11 September 2011 (CEST)<br />
<br />
Hi Neimod, love your work! my question is: The extended header suppose to start right after the NCCH header so why there is twice the space? (extended header size is usually 1024 and plain region offset is usually 5*512 = 2560 -> 2048 after the end of the ncch) thanks. --[[User:Elisherer|Elisherer]] 11:46, 6 September 2011 (CEST)<br />
:I'm not sure I understand you. The extended header does come right exactly after the NCCH header. The only place where this does not hold is the NCCH header at offset 0x1000, but this one header should be ignored because this space does not exist on a real card. I suspect this is the plaintext header from command 0x82 that was injected into the ROM in post-processing by the dumpergroup. --[[User:Neimod|Neimod]] 17:40, 6 September 2011 (CEST)<br />
::Thanks for the answer, what I meant is that there is a block (of 2048 bytes) between the ncch header and the plain region. this is where the extended header should be, and it supposed to be 1024 bytes. So my question was what are the extra 1024 bytes for (they are not zeros...) --[[User:Elisherer|Elisherer]] 19:07, 6 September 2011 (CEST)<br />
:::Ah that, I'm not sure what that 0x400-byte region is. --[[User:Neimod|Neimod]] 23:12, 6 September 2011 (CEST)<br />
::::So... how did you get that "Example dependency list from the extended header" obviously it's encrypted...? --[[User:Elisherer|Elisherer]] 13:22, 7 September 2011 (CEST)<br />
:::::That was added by [[User:Jl12|Jl12]], maybe he can answer this for you. --[[User:Neimod|Neimod]] 03:12, 8 September 2011 (CEST)<br />
<br />
I have a simple question why Neimod are thinking the code is compressed? I think LZSS is not good for binary images.<br />
:Because they just are. --[[User:Neimod|Neimod]] 17:40, 6 September 2011 (CEST)<br />
:Game editors want to fit their game in the smallest ROM chip size possible, to reduce manufacturing costs. Also, encrypting blocks of zeros/FF is bad practices, compression avoids it. --[[User:Luigi2us|Luigi2us]] 18:17, 6 September 2011 (CEST)<br />
<br />
I've found something in my Chronicles Samurai Warriors savegame:<br />
18 A1 72 6F 6D 3A 2F 53 00 6F 75 6E 64 2F 73 74 .¡rom:/S.ound/st<br />
72 00 65 61 6D 2F 53 54 52 4D 00 5F 53 59 53 5F MES.SAGE_GOO.D.b<br />
63 73 74 6D F9 D7 9A 2F 95 90 8D 0A 93 00 03 B0 cstmùך/•...“..°<br />
Looks like a path in the ROM filesystem in a LZ77 compression. Maybe it can help to find the master decryption key (if we would have<br />
a dumped Samurai Warriors).--[[User:Lazymarek9614|Lazymarek9614]] 21:12, 16 September 2011 (CEST)<br />
<br />
:I'm by no means an expert on de/encryption, signing code and what not, but the master decryption key is probably stored in internal RAM/ROM (in other words, inside the CPU die), that way it can't be sniffed or easily obtained. I doubt Nintendo would store a key as important as that in external RAM/ROM/SRAM, or in a some form of a filesystem. If they did, their programmers are dumber than Sony's. But again, system security is not the sort of thing I am good at, so take this with a grain of salt. --[[User:CHR15x94|CHR15x94]] 21:35, 16 September 2011 (CEST)<br />
<br />
The key is stored in every 3DS and it's always the same key...! I wonder that no one sniffed the 3DS' RAM yet. This should be done now!<br />
Has anyone experience in RAM sniffing?--[[User:Lazymarek9614|Lazymarek9614]] 22:01, 16 September 2011 (CEST)<br />
<br />
:Someone will eventually. It's not an easy thing to do, and FPGAs (the device you'd use to access RAM) are quite expensive ($500 - $700+USD for a decent one). People did it with the DSi, I'm sure it won't be _too_ long for the 3DS. Might find [http://hackmii.com/2009/09/dsi-ram-hax/ this] interesting as well. --[[User:CHR15x94|CHR15x94]] 22:55, 16 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:CXI&diff=1279Talk:CXI2011-09-16T19:32:34Z<p>CHR15x94: </p>
<hr />
<div>How 3DS system judge encryption type? --[[User_talk:Matyapiro|Matyapiro]]<br />
: Sorry the question is not understood. What do you mean? --[[User:Neimod|Neimod]]<br />
<br />
:: I think that he means "How does the 3DS decide what encryption method must be used" --[[User:Quincy|Quincy]] 23:47, 29 May 2011 (CEST)<br />
<br />
::: That question does not make sense. There are no decisions. It is always AES CTR. --[[User:Neimod|Neimod]]<br />
<br />
Sorry,how does the 3DS decide what key to use for encryption?<br />
--[[User_talk:Matyapiro|Matyapiro]]<br />
: If you figure that out, let us know, thanks. --[[User:Neimod|Neimod]] 02:45, 1 June 2011 (CEST)<br />
There's a common key used to generate output at compile time, when the cci/ctx files are made. Why do you say 128 bit AES CTR though? --[[User:Jl12|Jl12]]<br />
: Because 128-bit AES CTR is used to encrypt those formats. --[[User:Neimod|Neimod]] 15:40, 18 June 2011 (CEST)<br />
<br />
I know *something* is used to encrypt but do we know it is 128 bit AES CTR? --[[User:Jl12|Jl12]]<br />
<br />
Frankly I don't think it was AES. I think it's using RSA for encryption. Besides it already used it once for the 2048-bit signature as you said. Wouldn't it make way more sense to also use it for the encryption scheme. --[[User:Jl12|Jl12]]<br />
: Lol. --[[User:Neimod|Neimod]] 16:06, 20 June 2011 (CEST)<br />
What's funny? So I guess it's just based purely on speculation? You should say so. That way nobody believes something that isn't right. --[[User:Jl12|Jl12]] 22:28, 20 June 2011 (CEST)<br />
: RSA is only used for the signature. After that a symmetric block cipher called AES is used in CTR mode. --[[User:Neimod|Neimod]] 23:32, 20 June 2011 (CEST)<br />
<br />
<br />
How did you get this data? Did you find some way to dump 3DS cartridges? --[[User:Popoffka|Popoffka]] 09:15, 1 June 2011 (CEST)<br />
:Yes, someone found a way to dump the data on 3DS cards. Unfortunately the method cannot be disclosed, and at this point dumping is not really useful since most of the information is encrypted. --[[User:Neimod|Neimod]] 10:03, 1 June 2011 (CEST)<br />
<br />
Do you have any method to run a Dump? and did you find the key for the ctrtool? --[[User:Stevechou|Stevechou]]<br />
:Nope on both questions. --[[User:Neimod|Neimod]] 17:33, 25 June 2011 (CEST)<br />
<br />
There's code in ctrtool that takes the AES counter value from some partition ID and type. I can't help but wonder, how do you know that the counter value is generated this way? And if we know that, isn't it a start to finding out the key? --[[User:Luigi2us|Luigi2us]] 20:17, 25 June 2011 (CEST)<br />
:Sorry this information cannot be disclosed. --[[User:Neimod|Neimod]] 05:17, 27 June 2011 (CEST)<br />
<br />
Anyway, can you read the encrypt datas?<br />
<br />
<br />
Hi! Do we already know where the offset of the ARM11 code is?<br />
And that I got correctly, that the hole 3DS ROM encrypted by AES?<br />
--[[User:Lazymarek9614|Lazymarek9614]] 21:10, 1 August 2011 (CEST)<br />
:Yes, see ctrtool for more exact details. --[[User:Neimod|Neimod]] 17:44, 6 September 2011 (CEST)<br />
<br />
::I mean the offset of the ARM11 code not the exefs. Exefs contains not only the code, right?<br />
::Would CXI be the homebrew application file format, what do you think? If so, then I think we can modify it a bit for homebrew,<br />
::because some parts doesn't make sense.--[[User:Lazymarek9614|Lazymarek9614]] 19:18, 6 September 2011 (CEST) <br />
:::The ExeFS contains only the ARM11 code and the banner. To know the offset of the ARM11 code you would need to scan the ExeFS for the file ".code". <br />
:::As for the homebrew file format, I think it's a little too early for that. Whatever happens, happens. --[[User:Neimod|Neimod]] 23:12, 6 September 2011 (CEST)<br />
::::Thanks, but please can you give me the parameters for your tool to decrypt the ExeFS and save it? The usage for that is a bit ununderstandable.--[[User:Lazymarek9614|Lazymarek9614]] 20:01, 7 September 2011 (CEST)<br />
:::::One of the parameters to use this tool is the master decryption key, which is currently not known. So at this point, nobody can use this tool to decrypt the ExeFS. --[[User:Neimod|Neimod]] 03:12, 8 September 2011 (CEST)<br />
::::::This master decryption key, is it used for every game? For the 3ds homebrew format I will create a tool which includes a 3d model, an icon and the machine code in the file. However, before we should think about the structure for it. I know that's a bit early, but later (when we can run homebrew) we will be glad if we have it.--[[User:Lazymarek9614|Lazymarek9614]] 20:14, 9 September 2011 (CEST)<br />
:::::::We can also use the elf Format for homebrew--[[User:ichfly|ichfly]]<br />
::::::::Yes, but it has not a banner.--[[User:Lazymarek9614|Lazymarek9614]] 16:54, 10 September 2011 (CEST)<br />
:::::::::Shall I create a new talk about the homebrew format? We should discuss and plan it a bit.--[[User:Lazymarek9614|Lazymarek9614]] 11:08, 11 September 2011 (CEST)<br />
::::::::::Yes, you shall.. --[[User:Elisherer|Elisherer]] 11:55, 11 September 2011 (CEST)<br />
<br />
Hi Neimod, love your work! my question is: The extended header suppose to start right after the NCCH header so why there is twice the space? (extended header size is usually 1024 and plain region offset is usually 5*512 = 2560 -> 2048 after the end of the ncch) thanks. --[[User:Elisherer|Elisherer]] 11:46, 6 September 2011 (CEST)<br />
:I'm not sure I understand you. The extended header does come right exactly after the NCCH header. The only place where this does not hold is the NCCH header at offset 0x1000, but this one header should be ignored because this space does not exist on a real card. I suspect this is the plaintext header from command 0x82 that was injected into the ROM in post-processing by the dumpergroup. --[[User:Neimod|Neimod]] 17:40, 6 September 2011 (CEST)<br />
::Thanks for the answer, what I meant is that there is a block (of 2048 bytes) between the ncch header and the plain region. this is where the extended header should be, and it supposed to be 1024 bytes. So my question was what are the extra 1024 bytes for (they are not zeros...) --[[User:Elisherer|Elisherer]] 19:07, 6 September 2011 (CEST)<br />
:::Ah that, I'm not sure what that 0x400-byte region is. --[[User:Neimod|Neimod]] 23:12, 6 September 2011 (CEST)<br />
::::So... how did you get that "Example dependency list from the extended header" obviously it's encrypted...? --[[User:Elisherer|Elisherer]] 13:22, 7 September 2011 (CEST)<br />
:::::That was added by [[User:Jl12|Jl12]], maybe he can answer this for you. --[[User:Neimod|Neimod]] 03:12, 8 September 2011 (CEST)<br />
<br />
I have a simple question why Neimod are thinking the code is compressed? I think LZSS is not good for binary images.<br />
:Because they just are. --[[User:Neimod|Neimod]] 17:40, 6 September 2011 (CEST)<br />
:Game editors want to fit their game in the smallest ROM chip size possible, to reduce manufacturing costs. Also, encrypting blocks of zeros/FF is bad practices, compression avoids it. --[[User:Luigi2us|Luigi2us]] 18:17, 6 September 2011 (CEST)<br />
<br />
I've found something in my Chronicles Samurai Warriors savegame:<br />
18 A1 72 6F 6D 3A 2F 53 00 6F 75 6E 64 2F 73 74 .¡rom:/S.ound/st<br />
72 00 65 61 6D 2F 53 54 52 4D 00 5F 53 59 53 5F MES.SAGE_GOO.D.b<br />
63 73 74 6D F9 D7 9A 2F 95 90 8D 0A 93 00 03 B0 cstmùך/•...“..°<br />
Looks like a path in the ROM filesystem in a LZ77 compression. Maybe it can help to find the master decryption key (if we would have<br />
a dumped Samurai Warriors).--[[User:Lazymarek9614|Lazymarek9614]] 21:12, 16 September 2011 (CEST)<br />
<br />
:I'm by no means an expert on de/encryption, signing code and what not, but the master decryption key is probably stored in internal RAM/ROM (in other words, inside the CPU die), that way it can't be sniffed or easily obtained. I doubt Nintendo would store a key as important as that in external RAM/ROM/SRAM, or in a some form of a filesystem. If they did, their programmers are dumber than Sony's. But again, system security is not the sort of thing I am good at, so take this with a grain of salt. --[[User:CHR15x94|CHR15x94]] 21:35, 16 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:News&diff=1278Talk:News2011-09-16T19:23:08Z<p>CHR15x94: </p>
<hr />
<div>Is the defective by designs campaign really relevant to 3dbrew? Should it really be on the news page? --[[User:Matthew|Matthew]] 06:27, 13 May 2011 (CEST)<br />
<br />
I believe so. Homebrew appears to be a primary target of the Nintendo 3DS EULA and any bricking efforts Nintendo may implement.--[[User:Winmaster|Winmaster]] 17:29, 13 May 2011 (CEST)<br />
<br />
<br />
<br />
It shouldn't be there. This wiki is for cataloging up to date knowledge about the 3ds hardware/software and any development efforts. It is not a bulletin board or a place to solicitate anything - even if its related to the 3DS platform.<br />
<br />
It's also myth and wrong/misinformation. Another reason we shouldn't be hosting or "spreading" it.<br />
<br />
The only argument I've read about that was referencing a statement in the user manual that says something about "interruption of service". There's a service associated with the 3ds. How do you think you get your updates and notifications. Apparently someone believed it meant they're going to "brick" your 3ds. Don't believe everything you come across plz. Do your own homework and check for it up yourself.<br />
<br />
Don't spread misinformation if you don't know either.<br />
<br />
I feel sorry for the one getting those paper bricks ( if the page isn't shut down first ) because he's not responsible for some kid misreading their user manual elsewhere in the world or the lame trends they started, instead of asking somebody else that would have known better. Someone studying law maybe. Not like gbatemp/wiki I guess. >_><br />
<br />
[[User:Jl12|Jl12]] 20:39, 14 May 2011 (CEST)<br />
<br />
What about crown3ds? Is it a fake?--[[User:Lazymarek9614|Lazymarek9614]] 19:30, 16 September 2011 (CEST)<br />
<br />
Why would it be a fake? Crown3DS's website is 50% finished. Fake flashcards never let you know when their website will be completed. --[[User:Kiddyshaq34|Kiddyshaq34]] 19:36, 16 September 2011 (BST)<br />
<br />
For me the video on their page seems to be a fake. It looks like starting a normal SplinterCell3D with its extern hardware (just put the chips on another board). Maybe it's a fake,<br />
but I'm not sure.--[[User:Lazymarek9614|Lazymarek9614]] 20:52, 16 September 2011 (CEST)<br />
<br />
It look's pretty fake. And like [[User:Lazymarek9614|Lazymarek9614]] said, they probably just have the ROM chip from the Splinter Cell cartridge stuck on another board. Also it's directly promoting piracy, so it doesn't belong here. --[[User:CHR15x94|CHR15x94]] 21:26, 16 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Main_Page/Navigation&diff=1266Main Page/Navigation2011-09-15T19:15:08Z<p>CHR15x94: </p>
<hr />
<div>{{Main page box|Navigation|Main Page/Navigation}}<br />
<div style="margin: -.3em -1em -1em -1em;"><br />
{| width="100%" bgcolor="#fff" border="0" cellpadding="2px" cellspacing="2px" style="margin:auto;"<br />
|- align="center" bgcolor="#e7eef6"<br />
! width="33%" | '''General'''<br />
! width="34%" | '''3DS hardware'''<br />
! width="33%" | '''3DS software'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[3DS exploits]]<br />
*[[Glossary]]<br />
*[[FAQ]]<br />
*[[Friend code]]<br />
*[[Games]]<br />
|<br />
*[[Hardware]]<br />
*[[Gamecards]]<br />
|<br />
*[[Nintendo Software]]<br />
*[[CXI|CXI Format]]<br />
*[[File Formats]]<br />
*[[Title list]]<br />
*[[Title metadata]]<br />
*[[SD Filesystem]]<br />
*[[Flash Filesystem]]<br />
*[[Bootloader]]<br />
*[[Savegames]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Main_Page/Navigation&diff=1250Main Page/Navigation2011-09-14T20:45:01Z<p>CHR15x94: Added list of system updates</p>
<hr />
<div>{{Main page box|Navigation|Main Page/Navigation}}<br />
<div style="margin: -.3em -1em -1em -1em;"><br />
{| width="100%" bgcolor="#fff" border="0" cellpadding="2px" cellspacing="2px" style="margin:auto;"<br />
|- align="center" bgcolor="#e7eef6"<br />
! width="33%" | '''General'''<br />
! width="34%" | '''3DS hardware'''<br />
! width="33%" | '''3DS software'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[3DS exploits]]<br />
*[[Glossary]]<br />
*[[FAQ]]<br />
*[[Friend code]]<br />
*[[Games]]<br />
|<br />
*[[Hardware]]<br />
*[[Gamecards]]<br />
| <br />
*[[Nintendo Software]]<br />
*[[List_of_system_updates|List of system updates]]<br />
*[[CXI|CXI Format]]<br />
*[[File Formats]]<br />
*[[Title list]]<br />
*[[Title metadata]]<br />
*[[SD Filesystem]]<br />
*[[Flash Filesystem]]<br />
*[[Bootloader]]<br />
*[[Savegames]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=12453DS System Flaws2011-09-13T19:56:20Z<p>CHR15x94: scanlime's not bushing's RAM dumping setup.</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.<br />
<br />
==List of 3DS Exploits==<br />
There are currently no known 3DS-mode exploits.<br />
<br />
==Tips and info==<br />
Information on the 3DS's internals is scarce, notably the following:<br />
<br />
Flash encryption type/key(s)<br />
Gamecard encryption key(s)<br />
Memory mappings<br />
Pica200 GPU registers and general programming info (commands, setup, etc.)<br />
Many other things<br />
<br />
What this means is if any exploits are found, it would be very difficult to do anything useful with them. <br />
<br />
There are similarities between the 3DS and it's predecessors that could be used to communicate with an outside device (PC, microcontroller, etc.), one of them being the WiFi chip, which is very similar between the 3DS and DSi. Theoretically, if you could launch some code on the 3DS via an exploit, you could initialize the WiFi chip in the 3DS, connect to an access point, then connect to some network connected device, and send and receive data from the 3DS to the network connected device. This would allow you to do memory dumps over WiFi, upload code to the 3DS, etc.<br />
<br />
Another method would be to dump the contents of the 3DS's RAM through a hardware modification. This can be done by soldering connections to the 3DS's RAM and connecting it to an FPGA or similar device. The 3DS would then be powered on and it would modify and use RAM as it normally would, and then the hacker can disengage the 3DS from it's RAM (through a switch, etc.) or access the RAM through the FPGA while the 3DS is still using it. A good example of this type of modification is scanlime's work with the DSi ([http://hackmii.com/2009/09/dsi-ram-hax/ link]).</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:Hardware&diff=1238Talk:Hardware2011-09-13T19:09:17Z<p>CHR15x94: </p>
<hr />
<div>If the CPU is ARM does it have JTAG or SWD test access points.<br />
<br />
We need a datasheet about the ARM11!<br />
<br />
I thought the ARM11 has a JTAG support?<br />
How can we dump the NAND, through its pinout yes, but how can we do it exactly? I would like to do some tests on it to see how it works.--[[User:Lazymarek9614|Lazymarek9614]] 23:36, 10 September 2011 (CEST)<br />
:The ARM11 IP (intellectual property) has JTAG support, however this port can probably be permanently disabled internally. So there is no way of knowing if this port even still works or exists in the first place.<br />
:For dumping NAND, you need to hook up the NAND pins to an FPGA or microcontroller. Then you need to follow the eMMC hardware protocol to read out the data in the various sectors. --[[User:Neimod|Neimod]] 07:06, 11 September 2011 (CEST)<br />
<br />
Are there any photos of the back of the 3DS's PCB? Anything available in a higher resolution (front or back)? Closeups of the SoC and surrounding components (front and back)? Any help greatly appreciated, thanks! --[[User:CHR15x94|CHR15x94]] 00:35, 13 September 2011 (CEST)<br />
:You could ask the [http://www.youtube.com/watch?v=OFoZGt8tCNw&feature=related Doctor] --[[User:Elisherer|Elisherer]] 19:16, 13 September 2011 (CEST)<br />
::Hop... found [http://tvgzone.com/viewthread.php?tid=6136&highlight=3ds some]. Maybe we should add them to our page? --[[User:Elisherer|Elisherer]] 19:23, 13 September 2011 (CEST)<br />
:::That's [http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/2 from] [http://guide-images.ifixit.net/igi/IkjXAUHUgmdZch6A.large iFixit], which is already linked to on the page. --[[User:Yellows8|Yellows8]] 20:50, 13 September 2011 (CEST)<br />
::::Crap, I always manage to miss things like that... >_< Anyway, thanks Elisherer and Yellows8. --[[User:CHR15x94|CHR15x94]] 21:11, 13 September 2011 (CEST)<br />
<br />
Yes, please add them or replace the existing ones if nesessary.--[[User:Lazymarek9614|Lazymarek9614]]</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:Hardware&diff=1227Talk:Hardware2011-09-12T22:32:52Z<p>CHR15x94: Looking for pictures of the back of the PCB, closeups of SoC and surrounding components, higher res photos.</p>
<hr />
<div>If the CPU is ARM does it have JTAG or SWD test access points.<br />
<br />
We need a datasheet about the ARM11!<br />
<br />
I thought the ARM11 has a JTAG support?<br />
How can we dump the NAND, through its pinout yes, but how can we do it exactly? I would like to do some tests on it to see how it works.--[[User:Lazymarek9614|Lazymarek9614]] 23:36, 10 September 2011 (CEST)<br />
:The ARM11 IP (intellectual property) has JTAG support, however this port can probably be permanently disabled internally. So there is no way of knowing if this port even still works or exists in the first place.<br />
:For dumping NAND, you need to hook up the NAND pins to an FPGA or microcontroller. Then you need to follow the eMMC hardware protocol to read out the data in the various sectors. --[[User:Neimod|Neimod]] 07:06, 11 September 2011 (CEST)<br />
<br />
Are there any photos of the back of the 3DS's PCB? Anything available in a higher resolution (front or back)? Closeups of the SoC and surrounding components (front and back)? Any help greatly appreciated, thanks! --[[User:CHR15x94|CHR15x94]] 00:35, 13 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3dbrew:Copyrights&diff=12253dbrew:Copyrights2011-09-12T21:39:18Z<p>CHR15x94: Typo</p>
<hr />
<div>3DBrew.org is a website devoted to hacking and documenting Nintendo's 3DS portable video game console. Information found on this website is found through legal reverse engineering (both in the hardware and software sense) and publicly available information.<br />
<br />
This website can be edited by anyone who registers an account on this website. Because of this, this website cannot be held responsible for information submitted by users, as it is impossible to fully monitor information that is submitted to this website. If information is found to infringe copyright, or IP (Intellectual Property) laws, etc., it must be removed and reported to a site administrator immediately.<br />
<br />
==NDAs (Non-Disclosure Agreements)==<br />
NDAs (Non-Disclosure Agreements) are legal agreements issued to companies and individuals who request information from another company(s) or individual(s). These agreements state what information you can and cannot disclose to people who are and aren't under the same NDA, in exchange for you being given such private information. Disclosing any of this information on this website, other websites, to other people(s) or another company(s) is a violation of the agreement and therefore illegal.<br />
<br />
For this reason, information you have obtained via an NDA, and/or from someone(s) or a company(s) who have signed an NDA, etc., cannot be disclosed on this website. Please refrain from doing so. Any information found to have been from a source where the supplier has signed an NDA, or has been indirectly obtained from someone(s) or some company(s) who have signed an NDA, will be removed.<br />
<br />
==Notice==<br />
Information on this website should not infringe on the copyrights of any company(s) or person(s), including, but not limited to Nintendo Co., Ltd., Digital Media Professionals (DMP) Inc., any of their affiliated companies or persons, etc. Any information found to infringe any copyrights, intellectual property(s) (IP), NDAs (non-disclosure agreements), etc., must be removed and reported to a site administrator immediately.<br />
<br />
<br />
Nintendo 3DS is a registered trademark of Nintendo Co., Ltd. All related text, logos, graphics, etc., copyright Nintendo Co., Ltd. 2010 - 2011.<br />
<br />
PICA is a registered trademark of Digital Media Professionals (DMP) Inc. All related text, logos, graphics, etc., copyright Digital Media Professionals (DMP) Inc. 2006 - 2011 (?).</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3dbrew:Copyrights&diff=12243dbrew:Copyrights2011-09-12T21:33:13Z<p>CHR15x94: Created page. Don't post information, links, etc., that infringe copyright/IP, or that was obtained under an NDA. I am not a lawyer so this should be reviewed, preferably by a site admin and/or lawyer</p>
<hr />
<div>3DBrew.org is a website devoted to hacking and documenting Nintendo's 3DS portable video game console. Information found on this website is found through legal reverse engineering (both in the hardware and software sense) and publicly available information.<br />
<br />
This website can be edited by anyone who registers an account on this website. Because of this, this website cannot be held responsible for information submitted by users, as it is impossible to fully monitor information that is submitted to this website. If information is found to infringe copyright, or IP (Intellectual Property) laws, etc., it must be removed and reported to a site administrator immediately.<br />
<br />
==NDAs (Non-Disclosure Agreements)==<br />
NDAs (Non-Disclosure Agreements) are legal agreements issued to companies and individuals who request information from another company(s) or individual(s). These agreements state what information you can and cannot disclose to people who are and aren't under the same NDA, in exchange for you being given such private information. Disclosing any of this information on this website, other websites, to other people(s) or another company(s) is a violation of the agreement and therefore illegal.<br />
<br />
For this reason, information you have obtained via an NDA, and/or from someone(s) or a company(s) who have signed an NDA, etc., cannot be disclosed on this website. Please refrain from doing so. Any information found to have been from a source where the supplier has signed an NDA, or has been indirectly obtained from someone(s) or some company(s) who have signed an NDA, will be removed.<br />
<br />
==Notice==<br />
Information on this website should not infringe on the copyrights of any company(s) or person(s), including, but not limited to Nintendo Co., Ltd., Digital Media Professionals (DMP) Inc., any of their affiliated companies or persons, etc. Any information found to infringe any copyrights, intellectual property(s) (IP), NDAs (non-disclosure agreements), etc., must be removed and reported to a site administrator immediately.<br />
<br />
<br />
Nintendo 3DS is a registered trademark of Nintendo Co., Ltd. All related text, logos, graphics, etc., copyright Nintendo Co., Ltd. 2010 - 2011.<br />
<br />
PICA is a registered trademark of Digital Media Professionals (DMP) Inc. All related text, logos, graphics, etc., copyright Digital Media Professionals (DMP) Inc. copyright 2006 - 2011 (?).</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=12233DS System Flaws2011-09-12T20:40:46Z<p>CHR15x94: Added a bit more to tips and info section. (RAM hacks/RAM IO through hardware modification) Link to bushing's RAM hacking work on the DSi.</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.<br />
<br />
==List of 3DS Exploits==<br />
There are currently no known 3DS-mode exploits.<br />
<br />
==Tips and info==<br />
Information on the 3DS's internals is scarce, notably the following:<br />
<br />
Flash encryption type/key(s)<br />
Gamecard encryption key(s)<br />
Memory mappings<br />
Pica200 GPU registers and general programming info (commands, setup, etc.)<br />
Many other things<br />
<br />
What this means is if any exploits are found, it would be very difficult to do anything useful with them. <br />
<br />
There are similarities between the 3DS and it's predecessors that could be used to communicate with an outside device (PC, microcontroller, etc.), one of them being the WiFi chip, which is very similar between the 3DS and DSi. Theoretically, if you could launch some code on the 3DS via an exploit, you could initialize the WiFi chip in the 3DS, connect to an access point, then connect to some network connected device, and send and receive data from the 3DS to the network connected device. This would allow you to do memory dumps over WiFi, upload code to the 3DS, etc.<br />
<br />
Another method would be to dump the contents of the 3DS's RAM through a hardware modification. This can be done by soldering connections to the 3DS's RAM and connecting it to an FPGA or similar device. The 3DS would then be powered on and it would modify and use RAM as it normally would, and then the hacker can disengage the 3DS from it's RAM (through a switch, etc.) or access the RAM through the FPGA while the 3DS is still using it. A good example of this type of modification is [[user:bushing|bushing's]] work with the DSi ([http://hackmii.com/2009/09/dsi-ram-hax/ link]).</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:Homebrew_Format&diff=1208Talk:Homebrew Format2011-09-12T01:15:03Z<p>CHR15x94: Small mistake</p>
<hr />
<div>It might be a bit early, but I think we can plan the homebrew format for the 3DS now.<br />
<br />
Here we can discuss and plan the format (e.g:) <br />
*file extension (.3ds?)<br />
*structure of the format<br />
:*header, banner (icon, 3d model, description...)<br />
:*header and executable areas<br />
...and so on.<br />
<br />
I think we should make it similar to the CXI format, that flashcards can run both: commercial and homebrew files.--[[User:Lazymarek9614|Lazymarek9614]] 16:17, 11 September 2011 (CEST)<br />
<br />
According to the decisions here I create a tool to create homebrew (3dstool?).--[[User:Lazymarek9614|Lazymarek9614]] 17:13, 11 September 2011 (CEST)<br />
:Do you have any experience in making such files and tool? --[[User:Elisherer|Elisherer]] 19:02, 11 September 2011 (CEST)<br />
<br />
::Well, I know about the elf, afx, bmp, 3ds, obj, nds format. I also have read the sources of tools like ndstool (used for creating nds files).<br />
<br />
::Let's discuss the format!--[[User:Lazymarek9614|Lazymarek9614]] 19:33, 11 September 2011 (CEST)<br />
:::Ok, i just wanted to know if it's somebody who knows what he talks about, You could never know... I was wondering, because I watch this wiki a lot maybe we wanna make this discussion on another forum like gbatemp so it won't notify us for every post. Because these wiki pages weren't made for big discussions, just on stuff that we aren't sure about... --[[User:Elisherer|Elisherer]] 20:04, 11 September 2011 (CEST)<br />
<br />
:::Wouldn't we just use CXI or CCI? I don't see why we'd need to make a new format. Any flash carts made for the 3DS would boot files in the CXI or CCI format, since that's the format commercial ROM images use, and the primary goal of flash carts is to boot commercial pirated content (unfortunately). CXI is also the 3DS's native format, and has space reserved for code, the banner, etc. Not trying to be rude, but I don't think we need to make a new format for 3DS homebrew, or really discuss it for that matter. And we're spamming the crap out of the changelog, so... --[[User:CHR15x94|CHR15x94]] 21:00, 11 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=12073DS System Flaws2011-09-12T01:10:20Z<p>CHR15x94: Added tips and info section. If you feeling this isn't wiki material, or is wrong, remove it and/or put it in the 3DS exploits:talk page</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.<br />
<br />
==List of 3DS Exploits==<br />
There are currently no known 3DS-mode exploits.<br />
<br />
==Tips and info==<br />
Information on the 3DS's internals is scarce, notably the following:<br />
<br />
Flash encryption type/key(s)<br />
Gamecard encryption key(s)<br />
Memory mappings<br />
Pica200 GPU registers and general programming info (commands, setup, etc.)<br />
Many other things<br />
<br />
What this means is if any exploits are found, it would be very difficult to do anything useful with them. <br />
<br />
There are similarities between the 3DS and it's predecessors that could be used to communicate with an outside device (PC, microcontroller, etc.), one of them being the WiFi chip, which is very similar between the 3DS and DSi. Theoretically, if you could launch some code on the 3DS via an exploit, you could initialize the WiFi chip in the 3DS, connect to an access point, then connect to some network connected device, and send and receive data from the 3DS to the network connected device. This would allow you to do memory dumps over WiFi, upload code to the 3DS, etc.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Talk:Homebrew_Format&diff=1206Talk:Homebrew Format2011-09-11T19:02:09Z<p>CHR15x94: </p>
<hr />
<div>It might be a bit early, but I think we can plan the homebrew format for the 3DS now.<br />
<br />
Here we can discuss and plan the format (e.g:) <br />
*file extension (.3ds?)<br />
*structure of the format<br />
:*header, banner (icon, 3d model, description...)<br />
:*header and executable areas<br />
...and so on.<br />
<br />
I think we should make it similar to the CXI format, that flashcards can run both: commercial and homebrew files.--[[User:Lazymarek9614|Lazymarek9614]] 16:17, 11 September 2011 (CEST)<br />
<br />
According to the decisions here I create a tool to create homebrew (3dstool?).--[[User:Lazymarek9614|Lazymarek9614]] 17:13, 11 September 2011 (CEST)<br />
:Do you have any experience in making such files and tool? --[[User:Elisherer|Elisherer]] 19:02, 11 September 2011 (CEST)<br />
<br />
::Well, I know about the elf, afx, bmp, 3ds, obj, nds format. I also have read the sources of tools like ndstool (used for creating nds files).<br />
<br />
::Let's discuss the format!--[[User:Lazymarek9614|Lazymarek9614]] 19:33, 11 September 2011 (CEST)<br />
:::Ok, i just wanted to know if it's somebody who knows what he talks about, You could never know... I was wondering, because I watch this wiki a lot maybe we wanna make this discussion on another forum like gbatemp so it won't notify us for every post. Because these wiki pages weren't made for big discussions, just on stuff that we aren't sure about... --[[User:Elisherer|Elisherer]] 20:04, 11 September 2011 (CEST)<br />
<br />
:::Wouldn't we just use CXI? I don't see why we'd need to make a new format. Any flash carts made for the 3DS would boot files in the CXI format, since that's the format commercial ROM images use, and the primary goal of flash carts is to boot commercial pirated content (unfortunately). CXI is also the 3DS's native format, and has space reserved for code, the banner, etc. Not trying to be rude, but I don't think we need to make a new format for 3DS homebrew, or really discuss it for that matter. And we're spamming the crap out of the changelog, so... --[[User:CHR15x94|CHR15x94]] 21:00, 11 September 2011 (CEST)</div>CHR15x94https://www.3dbrew.org/w/index.php?title=Flash_Filesystem&diff=626Flash Filesystem2011-06-01T23:48:27Z<p>CHR15x94: Created page. Flash is encrypted, no filesystem info, blah. Is there any info on encryption type, etc.?</p>
<hr />
<div>The format of the Nintendo 3DS's flash filesystem is currently undocumented. Reading of flash is possible (through pinouts on the motherboard) and has been successfully performed, but the data is encrypted and can't be understood without first decrypting it.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=User:CHR15x94&diff=587User:CHR15x942011-05-26T20:46:35Z<p>CHR15x94: Typo</p>
<hr />
<div>Hey there. I'm CHR15x94. You probably haven't heard of me, and that's because I haven't really made or done anything useful to contribute to the hacking/homebrew community before. The only semi interesting thing I've made is a half-ass GameBoy (monochrome) emulator, which can be found on EmuTalk (build's old though). I'll create and edit pages here on 3DBrew when I can.<br />
<br />
Some sites you may have seen me on: <br /><br />
- ''EmuTalk'' - Made a couple posts in the Programming section. Posted a GameBoy emulator I did (about a year old, build is old, contains bugs, most of which I fixed a few days after release) <br /><br />
- ''YouTube'' - Posted a couple useless videos <br /><br />
- ''XboxHacker'' - Signed up to view a few threads. Was thinking of doing something 360 related, but found the 360 rather dull <br /><br />
- Probably others - I have a crappy memory :P <br /><br />
<br />
I don't currently have a 3DS, but plan on getting one later on this year. Will certainly do some homebrew dev if I can, maybe some other things. Anything I do will probably be emulation related.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=User:CHR15x94&diff=586User:CHR15x942011-05-26T20:45:42Z<p>CHR15x94: Created my page.</p>
<hr />
<div>Hey there. I'm CHR15x94. You probably haven't heard of me, and that's because I haven't really made or done anything useful to contribute to the hacking/homebrew community before. The only semi interesting thing I've made is a half-ass GameBoy (monochrome) emulator, which can be found on EmuTalk (build's old though). I'll create and edit pages here on 3DBrew when I can.<br />
<br />
Some sites you may have seen me on: <br /><br />
- ''EmuTalk'' - Made a couple posts in the Programming section. Posted a GameBoy emulator I did (about a year old, build is old, contains bugs, most of which I fixed a few days after release) <br /><br />
- ''YouTube'' - Posted a couple useless videos <br /><br />
- ''XboxHacker'' - Signed up to view a few threads. Was thinking of doing a something 360 related, but found the 360 rather dull <br /><br />
- Probably others - I have a crappy memory :P <br /><br />
<br />
I don't currently have a 3DS, but plan on getting one later on this year. Will certainly do some homebrew dev if I can, maybe some other things. Anything I do will probably be emulation related.</div>CHR15x94https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=5853DS System Flaws2011-05-26T19:12:23Z<p>CHR15x94: Blank pages are gross. Basic summary of what exploits are in relation to the 3DS. Placeholder list of exploits.</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.<br />
<br />
==List of 3DS Exploits==<br />
There are currently no known 3DS-mode exploits.</div>CHR15x94