RomFS - Revision history

Lillehavard: /* Overall RomFS file structure */ Forgot to add the proper amounts of zeros 0x0000 -> 0x00000

2026-01-10T20:16:57Z

Overall RomFS file structure: Forgot to add the proper amounts of zeros 0x0000 -> 0x00000

← Older revision		Revision as of 23:16, 10 January 2026
Line 24:		Line 24:
	! TYPE		! TYPE
	\|-		\|-
	\| ~~0x0000~~		\| 0x00000
	\| 0x5C		\| 0x5C
	\| RomFS Header (see below)		\| RomFS Header (see below)
	\| Header		\| Header
	\|-		\|-
	\| ~~0x005C~~		\| 0x0005C
	\| 0x4		\| 0x4
	\| Padding to the 0x20-byte boundary (0)		\| Padding to the 0x20-byte boundary (0)
	\| Padding		\| Padding
	\|-		\|-
	\| ~~0x0060~~		\| 0x00060
	\| 0x20*N		\| 0x20*N
	\| SHA256's on the 0x1000-byte block(s) at 0xXX000		\| SHA256's on the 0x1000-byte block(s) at 0xXX000

Lillehavard: Added info regarding the overall structure of the RomFS, taken from "https://problemkaputt.de/gbatek-3ds-files-ncch-romfs.htm". Added to give further insight into the total RomFS file structure and its levels. Tried to match the current style of the document, but can be changed by someone with more knowledge and insight into the code aspect and the document formatting.

2026-01-10T20:14:56Z

Added info regarding the overall structure of the RomFS, taken from "https://problemkaputt.de/gbatek-3ds-files-ncch-romfs.htm". Added to give further insight into the total RomFS file structure and its levels. Tried to match the current style of the document, but can be changed by someone with more knowledge and insight into the code aspect and the document formatting.

← Older revision		Revision as of 23:14, 10 January 2026
Line 13:		Line 13:

	(There may be more implementations in the future)		(There may be more implementations in the future)

			=== Overall RomFS file structure ===
			The overall structure of the RomFS is as follows:

			{\| class="wikitable" border="1"
			\|-
			! START
			! SIZE
			! DESCRIPTION
			! TYPE
			\|-
			\| 0x0000
			\| 0x5C
			\| RomFS Header (see below)
			\| Header
			\|-
			\| 0x005C
			\| 0x4
			\| Padding to the 0x20-byte boundary (0)
			\| Padding
			\|-
			\| 0x0060
			\| 0x20*N
			\| SHA256's on the 0x1000-byte block(s) at 0xXX000
			\| Master Hash
			\|-
			\| ...
			\| ..
			\| Padding to block-byte boundary (0)
			\| Padding
			\|-
			\| 0x01000
			\| ....
			\| RomFS Directory/Files (see below)
			\| Level 3
			\|-
			\| ...
			\| ..
			\| Padding to block-byte boundary (0)
			\| Padding
			\|-
			\| 0xXX000
			\| 0x20*NN
			\| SHA256's on each 0x1000-byte block at 0xYY000 and up.
			\| Level 1
			\|-
			\| ...
			\| ..
			\| Padding to block-byte boundary (0)
			\| Padding
			\|-
			\| 0xYY000
			\| 0x20*NNN
			\| SHA256's on each 0x1000-byte block at 0x1000 and up.
			\| Level 2
			\|}

	=== Format ===		=== Format ===

Wwylele: Undo revision 21154 by Marius851000 (talk) This is not true. I opened one of RomFS of an official game I have. The root directory has the "Offset of first Child Directory" = 0x18, implying the root directory entry located at offset 0 is 0x18 bytes, which would contain the "Name Length" field. The said field also has value 0 as expected.

2020-01-24T14:58:39Z

Undo revision 21154 by Marius851000 (talk) This is not true. I opened one of RomFS of an official game I have. The root directory has the "Offset of first Child Directory" = 0x18, implying the root directory entry located at offset 0 is 0x18 bytes, which would contain the "Name Length" field. The said field also has value 0 as expected.

← Older revision		Revision as of 17:58, 24 January 2020
Line 221:		Line 221:
	\| Directory Name (Unicode)		\| Directory Name (Unicode)
	\|}		\|}

	~~The root directory doesn't contain the name length of the directory name part.~~

	=== File Metadata Structure ===		=== File Metadata Structure ===

Marius851000: /* Directory Metadata Structure */

2020-01-22T17:02:53Z

Directory Metadata Structure

← Older revision		Revision as of 20:02, 22 January 2020
Line 221:		Line 221:
	\| Directory Name (Unicode)		\| Directory Name (Unicode)
	\|}		\|}

			The root directory doesn't contain the name length of the directory name part.

	=== File Metadata Structure ===		=== File Metadata Structure ===

Wwylele: Hey, it's just a common hash table

2016-10-01T02:27:04Z

Hey, it's just a common hash table

← Older revision		Revision as of 06:27, 1 October 2016
Line 146:		Line 146:
	\| 0x4		\| 0x4
	\| 0x4		\| 0x4
	\| Directory ~~HashKey~~ Table Offset		\| Directory Hash Table Offset
	\|-		\|-
	\| 0x8		\| 0x8
	\| 0x4		\| 0x4
	\| Directory ~~HashKey~~ Table Length		\| Directory Hash Table Length
	\|-		\|-
	\| 0xC		\| 0xC
Line 162:		Line 162:
	\| 0x14		\| 0x14
	\| 0x4		\| 0x4
	\| File ~~HashKey~~ Table Offset		\| File Hash Table Offset
	\|-		\|-
	\| 0x18		\| 0x18
	\| 0x4		\| 0x4
	\| File ~~HashKey~~ Table Length		\| File Hash Table Length
	\|-		\|-
	\| 0x1C		\| 0x1C
Line 211:		Line 211:
	\| 0x10		\| 0x10
	\| 0x4		\| 0x4
	\| Directory ~~HashKey~~ Table ~~Pointer~~		\| Offset of next Directory in the same Hash Table bucket
	\|-		\|-
	\| 0x14		\| 0x14
Line 250:		Line 250:
	\| 0x18		\| 0x18
	\| 0x4		\| 0x4
	\| File ~~HashKey~~ Table ~~Pointer~~		\| Offset of next File in the same Hash Table bucket
	\|-		\|-
	\| 0x1C		\| 0x1C
Line 261:		Line 261:
	\|}		\|}

	=== ~~HashKey~~ Table Structure ===		=== Hash Table Structure ===

	For both files and directories, a ~~HashKey~~ table is created for ~~MetaData verification~~.		For both files and directories, a [https://en.wikipedia.org/wiki/Hash_table#Collision_resolution separate chaining hash table] is created for quick lookup.

	A ~~HashKey~~ table consists of a number of ~~uints~~, all initialized to 0xFFFFFFFF. The size of the table is dependent on the number of entries in the relevant MetaData table (it's probably intended to always be the smallest prime number greater than or equal to the number of entries, but the implementation was lazy), illustrated by the following code (C#):		A hash table consists of a number of buckets, all initialized to 0xFFFFFFFF. The size of the table is dependent on the number of entries in the relevant MetaData table (it's probably intended to always be the smallest prime number greater than or equal to the number of entries, but the implementation was lazy), illustrated by the following code (C#):

	<pre>		<pre>
	public static byte[] ~~GetHashKeyTableLength~~(uint numEntries)		public static byte[] GetHashTableLength(uint numEntries)
	{		{
	uint count = numEntries;		uint count = numEntries;
Line 292:		Line 292:
	</pre>		</pre>

	~~Once the table~~ is ~~initialized, each File/Directory has a hash taken~~ based off ~~its~~ name (byte array taken from Metadata entry) and Parent Directory's offset (C#):		The hash function is based off directory/file name (byte array taken from Metadata entry) and Parent Directory's offset (C#):

	<pre>		<pre>
Line 307:		Line 307:
	</pre>		</pre>

	Each hash ~~is then~~ taken modulus ~~the number~~ of ~~uints~~ in the ~~HashKey Table. If~~ the ~~HashKeyTable's~~ value ~~at that index is 0xFFFFFFFF (unused),~~ the offset ~~for~~ the ~~relevant directory/file is inserted into~~ the table ~~at that offset. Otherwise~~, ~~after inserting the relevant~~ directory/file~~'s offset,~~ the ~~directory/file has its HashKey Pointer set to the offset~~ of the ~~directory/file that previously occupied the HashKey Table at that index~~.		Each directory/file is put into the ''i''th bucket, where ''i'' is the hash taken modulus of bucket count. The directories/files in the same bucket form a linked list, with the value in hash table as the offset to the head element. When creating the hash table, a latter added directory/file is always added as the head element of the linked list.

Yellows8: /* File Metadata Structure */

2015-09-22T20:37:06Z

File Metadata Structure

← Older revision		Revision as of 00:37, 23 September 2015
Line 248:		Line 248:
	\| Length of File's Data		\| Length of File's Data
	\|-		\|-
	\| ~~0x10~~		\| 0x18
	\| 0x4		\| 0x4
	\| File HashKey Table Pointer		\| File HashKey Table Pointer
	\|-		\|-
	\| ~~0x14~~		\| 0x1C
	\| 0x4		\| 0x4
	\| Name Length		\| Name Length
	\|-		\|-
	\| ~~0x18~~		\| 0x20
	\| Name Length (rounded up to multiple of 4)		\| Name Length (rounded up to multiple of 4)
	\| File Name (Unicode)		\| File Name (Unicode)

SciresM: Add format descriptions for everything else in a RomFS, remove stub tag.

2015-07-12T22:07:13Z

Add format descriptions for everything else in a RomFS, remove stub tag.

Show changes

Guiand: /* Overview */

2014-11-04T08:56:07Z

Overview

← Older revision		Revision as of 11:56, 4 November 2014
Line 7:		Line 7:
	*in conjunction with the [[ExeFS]] of a NCCH		*in conjunction with the [[ExeFS]] of a NCCH

	*to contain the game manual accessible from the [[Home Menu]])		*to contain the game manual accessible from the [[Home Menu]]

	*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]])		*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]])
Line 14:		Line 14:

	(There may be more implementations in the future)		(There may be more implementations in the future)


	=== Format ===		=== Format ===

Guiand: Remove decrypted examples of some RomFS data

2014-11-04T08:55:50Z

Remove decrypted examples of some RomFS data

← Older revision		Revision as of 11:55, 4 November 2014
Line 7:		Line 7:
	*in conjunction with the [[ExeFS]] of a NCCH		*in conjunction with the [[ExeFS]] of a NCCH

	*to contain the game manual accessible from the [[Home Menu]~~] ([http://depositfiles.com/files/foepo16an Decrypted Example~~])		*to contain the game manual accessible from the [[Home Menu]])

	*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]~~] ([http://depositfiles.com/files/6vw2guvjp Decrypted Example~~])		*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]])

	*or to contain game cartridge update data		*or to contain game cartridge update data

3dsguy: examples

2012-11-29T12:04:50Z

examples

← Older revision		Revision as of 15:04, 29 November 2012
Line 7:		Line 7:
	*in conjunction with the [[ExeFS]] of a NCCH		*in conjunction with the [[ExeFS]] of a NCCH

	*to contain the game manual accessible from the [[Home Menu]]		*to contain the game manual accessible from the [[Home Menu]] ([http://depositfiles.com/files/foepo16an Decrypted Example])

	*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]]		*to contain the [[Download Play#Broadcasted application data\|DLP Child CIA]] ([http://depositfiles.com/files/6vw2guvjp Decrypted Example])

	*or to contain game cartridge update data		*or to contain game cartridge update data