Homebrew Neimod is making progress!

[Quincy]

This is very interesting. It is kind of a nerd read tho, but still read it up.

Overview
A CXI file contains the 'application' program code, which runs on a single ARM11 core. It can communicate through SVC calls with the other ARM11 core running the 'system' program code. For reasons of clarity, the ARM11 cores will sometimes be called the 'appcore' and 'syscore' respectively.
The CXI file format contains application ARM11 code, the menu icon, the menu 3D model, and an embedded read-only (ROM) filesystem for external filestorage. In fact, the application ARM11 code, menu icon, and menu 3D model are embedded into its own filesystem too, called the ExeFS.
More specifically, the CXI file format is structured in the following order:
first an NCCH header,
followed by an extended header,
followed by a plain binary region,
followed by an embedded executable filesystem (ExeFS),
and finally followed by a read-only filesystem (RomFS).
The extended header contains additional information regarding access control. The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.
The extended header, the ExeFS and the RomFS are encrypted using AES CTR.

NCCH Header

OFFSETÂÂÂÂ SIZEÂÂÂÂ DESCRIPTION
0x000ÂÂÂÂ 0x100ÂÂÂÂ RSA-2048 signature of the NCCH header, using SHA-256.
0x100ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Magic ID, always 'NCCH'
0x104ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Content size, in media units (1 media unit = 0x200 bytes)
0x108ÂÂÂÂ 8ÂÂÂÂÂÂÂÂÂÂÂÂ Partition ID
0x110ÂÂÂÂ 2ÂÂÂÂÂÂÂÂÂÂÂÂ Maker code
0x112ÂÂÂÂ 2ÂÂÂÂÂÂÂÂÂÂÂÂ Version
0x114ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x118ÂÂÂÂ 8ÂÂÂÂÂÂÂÂÂÂÂÂ Program ID
0x120ÂÂÂÂ 1ÂÂÂÂÂÂÂÂÂÂÂÂ Temp flag
0x121ÂÂÂÂ 0x2FÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x150ÂÂÂÂ 0x10ÂÂÂÂ Product code
0x160ÂÂÂÂ 0x20ÂÂÂÂ Extended header hash
0x180ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Extended header size
0x184ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x188ÂÂÂÂ 8ÂÂÂÂÂÂÂÂÂÂÂÂ Flags
0x190ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Plain region offset, in media units
0x194ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Plain region size, in media units
0x198ÂÂÂÂ 8ÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x1A0ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ ExeFS offset, in media units
0x1A4ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ ExeFS size, in media units
0x1A8ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ ExeFS hash region size, in media units
0x1ACÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x1B0ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ RomFS offset, in media units
0x1B4ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ RomFS size, in media units
0x1B8ÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ RomFS hash region size, in media units
0x1BCÂÂÂÂ 4ÂÂÂÂÂÂÂÂÂÂÂÂ Reserved
0x1C0ÂÂÂÂ 0x20ÂÂÂÂ ExeFS superblock hash
0x1E0ÂÂÂÂ 0x20ÂÂÂÂ RomFS superblock hash

NCCH header example for Lego Starwars III

Signature:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ720FF8F83F2A1E998322A026D1434165
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂED19642ABC1CB2722135AA202BEAD60A
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ80BCD21C768C597B8268FEF2C64EA710
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ4C9BA5E12CFFBD1D0C619F4EF7B42CA7
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂDD8482CB4EB26720AD66CDA57ABCBCFB
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂD63268A6E2896A59B3B744E39E45B88A
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂABB4C0980ACC6210818DCE6DAC838A10
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ95D0F66B352474D4B3DA4B333F49912D
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ29AF7EA58BC8C890B18C70B7D540A9FB
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂEBE24A5312055617D3353B28C3EB1D17
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ61021BEFF6AD22C384835B40BD44DFAD
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ981F6350F9458B17BCB5F768C92ABC93
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ2BCE9888855A8998F4CDE40C9543514A
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂC57B84EB75A680E7C742632614620D1D
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂA253284DF3DC01091EB3800C36FD62EE
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂBA15340F1FD498FAB67C0302E9CDA397
Magic:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂNCCH
Content size:ÂÂÂÂÂÂÂÂÂÂ 0x1cfef400
Partition id:ÂÂÂÂÂÂÂÂÂÂ 0004000000038c00
Maker code:ÂÂÂÂÂÂÂÂÂÂÂÂ 3436 ("46")
Version:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ0002
Program id:ÂÂÂÂÂÂÂÂÂÂÂÂ 0004000000038c00
Temp flag:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ00
Product code:ÂÂÂÂÂÂÂÂÂÂ CTR-P-ALGP
Extended header hash:ÂÂ 0C27E3C1DE7B2AE2D3114F32A4EEBF46
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ9AFD0CF352C11D4984C2A9F1D2144C63
Extended header size:ÂÂ 00000400
Flags:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ0000030100000000
Plain region offset:ÂÂÂÂ0x00004a00
Plain region size:ÂÂÂÂÂÂ0x00000200
ExeFS offset:ÂÂÂÂÂÂÂÂÂÂ 0x00004c00
ExeFS size:ÂÂÂÂÂÂÂÂÂÂÂÂ 0x00143800
ExeFS hash region size: 0x00000200
RomFS offset:ÂÂÂÂÂÂÂÂÂÂ 0x00148400
RomFS size:ÂÂÂÂÂÂÂÂÂÂÂÂ 0x1ceab000
RomFS hash region size: 0x00000200
ExeFS Superblock Hash:ÂÂ130C042615F647C4C63225EA9E67F8A2
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ7B15246B88FBC7A927257B84977B787B
RomFS Superblock Hash:ÂÂA65BEE1060BB6A6821BBCEC600035B7E
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ64FB6EACA7F0960CFB1F5A37087728F7
Note: Offsets and sizes in media units have been converted to byte sizes.

Plain region example for Lego Starwars III

0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54ÂÂ[SDK+NINTENDO:CTÂÂÂÂ[SDK+NINTENDO:CTR_SDK-0_14_23_200_none]
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30ÂÂR_SDK-0_14_23_20
0004a20: 30 5f 6e 6f 6e 65 5d 00 5b 53 44 4b 2b 4e 49 4eÂÂ0_none].[SDK+NINÂÂÂÂ[SDK+NINTENDO:Firmware-02_27]
0004a30: 54 45 4e 44 4f 3a 46 69 72 6d 77 61 72 65 2d 30ÂÂTENDO:Firmware-0
0004a40: 32 5f 32 37 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63ÂÂ2_27].[SDK+MobicÂÂÂÂ[SDK+Mobiclip:Deblocker_1_0_2]
0004a50: 6c 69 70 3a 44 65 62 6c 6f 63 6b 65 72 5f 31 5fÂÂlip:Deblocker_1_
0004a60: 30 5f 32 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 6cÂÂ0_2].[SDK+MobiclÂÂÂÂ[SDK+Mobiclip:ImaAdpcmDec_1_0_0]
0004a70: 69 70 3a 49 6d 61 41 64 70 63 6d 44 65 63 5f 31ÂÂip:ImaAdpcmDec_1
0004a80: 5f 30 5f 30 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63ÂÂ_0_0].[SDK+MobicÂÂÂÂ[SDK+Mobiclip:MobiclipDec_1_0_1]
0004a90: 6c 69 70 3a 4d 6f 62 69 63 6c 69 70 44 65 63 5fÂÂlip:MobiclipDec_
0004aa0: 31 5f 30 5f 31 5d 00 5b 53 44 4b 2b 4d 6f 62 69ÂÂ1_0_1].[SDK+MobiÂÂÂÂ[SDK+Mobiclip:MoflexDemuxer_1_0_2]
0004ab0: 63 6c 69 70 3a 4d 6f 66 6c 65 78 44 65 6d 75 78ÂÂclip:MoflexDemux
0004ac0: 65 72 5f 31 5f 30 5f 32 5d 00 00 00 00 00 00 00ÂÂer_1_0_2].......
0004ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ÂÂ................
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ÂÂ................

Credit goes to Neimod and all people who worked on this document

http://3dbrew.org/wiki/CXI

 

[AlanJohn]

I don't understand a thing in hacking so I thinks its normal that I have no idea what your talking about.

 

[Quincy]

I don't understand a thing in hacking so I thinks its normal that I have no idea what your talking about.

As I said, it's a nerd read

 

[Keva]

Hasn't that been on there for a while now?

Still.. glad to see that people are getting to understand how it works

 

[Quincy]

Hasn't that been on there for a while now?

Still.. glad to see that people are getting to understand how it works

That info h as been documented yesterday iirc

 

[FAST6191]

Nice info, naturally it left me with more questions but early days stuff always does.

Mobiclip is back.... interesting although I think I might have to try my hand at knocking together some form of decoder as and when rom hacking gets to kick off. Some of those might just be decoders of known formats though rather than the proprietary stuff mobiclip is usually associated with.

Back on topic so to speak it looks like they furthered the DS model somewhat and maybe looked at the wii at the same time. I wonder where the SVC calls will land; GBA/DS SWI grade, Wii IOS stuff or something more akin to the DS ARM7 commercial rom stuff.

"0x108 8 Partition ID" caught my eye; although it says nothing of the implementation I am drawn to wonder how that will work in practice. This being said we were brushing up against limits on the DS with direct addressing so it was inevitable with 3d and increased power.

"followed by an embedded executable filesystem (ExeFS)," and other things most notably that it contains application code and seemingly kicks assets to another filesystem.
I am hesitant to throw a phrase around like poor man's harvard architecture or hypervisor but I wonder if/how this will play with some of the scripting languages (especially the JIT stuff)- these have the potential to compromise security but on the flipside they are quite powerful and easier to learn (Puzzle quest is written in a form of lua if looking at the DS and we have all seen some of the stuff going on elsewhere with scripting languages). Of course I guess it could all be packed in the binary.
Also some of the dynamic recompilation type arrangements (this device is certainly powerful enough to do some decent emulation where such techniques are quite potent- why port when you wrap it in an emulator) although I guess that is more of a memory issue (head in the 360 still).

Thanks for pointing me at this Quincy; I shall look it over for a while.

 

[Pong20302000]

hmmm

is this not proof of 3DS rom dump?

because of star wars III header data?

that the data has been decrypted?

that region changing is possible?

same sort of offsetting used for DS Anti-Piracy

 

[FAST6191]

It could just as easily have been pulled from a memory dump Pong20302000; even on the DS the header and stuff like it is copied to memory on boot* and memory is usually in plaintext so to speak (cheat makers have long been familiar with obfuscation techniques for values of interest but pretty much only the 360 has large scale encrypted memory).

*"Header Overview (loaded from ROM Addr 0 to Main RAM 27FFE00h on Power-up)" from http://nocash.emubase.de/gbatek.htm#dscartridgeheader

This being said that is quite a bit of info and although it could be inferred encryption aside a rom dump would probably be easier to pull info from.

 

[pachura]

So when will it be hacked ?

Just joking. This is definitively interesting - this information must have been extracted either:
- directly from the cartridge
- from RAM after the cartridge is loaded
- using 3DS SDK

Whichever's the case, the hackers are moving forward.

Some more observations:
- it seems Nintendo is still using the Mobiclip/ActImagine codec for video & IMA ADPCM codec for sound, just like the original DS. These codecs are quite outdated and not that great quality
- is it now confirmed that 3DS runs on two ARM11 cores ?
- the syscore/appcore thing... does it mean that games can use just one core, and the second one is always running some kind of "system services" ? That would be a giant waste of processing power...
- Pong20302000: the data has been decrypted? - no, they are saying explicitly that "the plain region" area is unencrypted, but the rest is encrypted using AES and signed with SHA-256 hashes

 

[ilman]

so this means that the 3ds system menu and lego star wars have been extracted and encrypted?
if it is so, then this will be a huge step forward for hackers.

 

[Tom Bombadildo]

So when will it be hacked ?

Just joking. This is definitively interesting - this information must have been extracted either:
- directly from the cartridge
- from RAM after the cartridge is loaded
- using 3DS SDK

Whichever's the case, the hackers are moving forward.

Some more observations:
- it seems Nintendo is still using the Mobiclip/ActImagine codec for video & IMA ADPCM codec for sound, just like the original DS. These codecs are quite outdated and not that great quality
- is it now confirmed that 3DS runs on two ARM11 cores ?
- the syscore/appcore thing... does it mean that games can use just one core, and the second one is always running some kind of "system services" ? That would be a giant waste of processing power...
- Pong20302000: the data has been decrypted? - no, they are saying explicitly that "the plain region" area is unencrypted, but the rest is encrypted using AES and signed with SHA-256 hashes

I would assume it's running the Home menu, so you can easily access it with the home button.

 

[Coto]

Exe FS more like system menu access libraries. RomFS reads from ROMexternal carts incluiding external storage.

Tempflag variables caught my attention, wonder what´d do them. I pseudo believe 3DS has somekind of kirk´s psp security chip. Which will always read the same very offsets from RomFS addresses, in case of flashcards, those values always change.

 

[WiiUBricker]

What an aweful icon.

 

[SifJar]

- the syscore/appcore thing... does it mean that games can use just one core, and the second one is always running some kind of "system services" ? That would be a giant waste of processing power...

It seems to me to be similar to how the DS worked (with ARM7 and ARM9 - not sure if they were designated one for "application code" and one for "system code") and the Wii (with PPC being equivalent to "appcore" and ARM equivalent to "syscore"). Seems to be how Nintendo like to do things. It's not really a waste at all. Presumably the syscore provides access to hardware, the way IOS running on ARM does on the Wii. And implements the security system while they're at it (i.e. preventing unauthorised access to hardware). It is in Nintendo's interests to prevent games from being pirated, which will inevitably follow a hack, so from their point of view it is not all a waste of processing power to dedicate a core to this type of thing. And I guess it makes life easier for developers having hardware stuff handled by one core, and having one core purely dedicated to running actual applications.

 

[pachura]

It seems to me to be similar to how the DS worked (with ARM7 and ARM9 - not sure if they were designated one for "application code" and one for "system code")

As far as I remember, ARM7 was responsible for sound and touchscreen input, and ARM9 for the rest.

 

[Melter]

seems like kind of a waste to dedicate an entire ARM11 core to the system menu. How did neimod get this information though? Logic analyzer?

 

[popoffka]

Here's an interesting quote straight from the discussion page on the wiki:

How did you get this data? Did you find some way to dump 3DS cartridges? --Popoffka 09:15, 1 June 2011 (CEST)
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. Neimod 10:03, 1 June 2011 (CEST)

 

[SifJar]

seems like kind of a waste to dedicate an entire ARM11 core to the system menu. How did neimod get this information though? Logic analyzer?

Not system menu. System processes. i.e. the code providing access to hardware for the code running on appcore. As I said before, this is very similar to what happened on the Wii. There were two processors in the Wii, one for system processed (IOS) and one for actual games etc.

 

[Keva]

Here's an interesting quote straight from the discussion page on the wiki:

How did you get this data? Did you find some way to dump 3DS cartridges? --Popoffka 09:15, 1 June 2011 (CEST)
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. Neimod 10:03, 1 June 2011 (CEST)

I wonder why he can't disclose it

Many hands make light work after all.

 

[Melter]

Here's an interesting quote straight from the discussion page on the wiki:

How did you get this data? Did you find some way to dump 3DS cartridges? --Popoffka 09:15, 1 June 2011 (CEST)
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. Neimod 10:03, 1 June 2011 (CEST)

I wonder why he can't disclose it

Many hands make light work after all.

probably so nintendo does not patch/fix the exploit.