3dbrew - User contributions [en]

Anti Time-Travel

2016-04-20T09:22:59Z

LIT:

Many commercial games, such as Tomodachi Life, all Pokèmon games, etc are capable of '''telling whether the clock was adjusted''' while they weren't running, '''even for realistic progress of time''' (new setting in the future from last save).

This is achieved through a peculiarity in the implementation of the real time clock.

The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.

When the time is normally set, the date in the RTC is set to the start of 2001 (''and so is the time?''), and the console saves to NAND (''where?'') the time and date difference between the programmed time and the hardware one.

:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection|multiboot scenarios]] often results in incorrect values in other OS instances.

Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.

BCSAR

2015-08-16T11:13:45Z

LIT: /* BCSAR Header */

[[Category:File formats]]
== Overview ==

The BCSAR (CTR Sound ARchive) format is the 3DS's equivalent of the Wii's BRSAR format. They're not the same structures, though, but they do have the same purpose.

BCSAR are located in the RomFS, this is usually stored under "romfs:/sound/<name>.bcsar". This contains various audio formats, such as CSTM, CWSD, and CWAV.

== BCSAR Header ==

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| MAGIC "CSAR"
|-
| 0x4
| 0x2
| Byte order mark (0xFEFF = Big Endian, 0xFFFE = Little Endian)
|-
| 0x6
| 0x2
| Length of BCSAR header
|-
| 0x8
| 0x4
| Version
|-
| 0xC
| 0x4
| Length of the entire BCSAR (starting from 0x0)
|-
| 0x10
| 0x4
| Amount of main partitions in the BCSAR [STRG + INFO + FILE = 0x03 (= 3)]
|-
| 0x14
| 0x4
| Partition header length [same for each partition? (ie STRG,INFO,and FILE header lengths)]
|-
| 0x18
| 0x4
| Location of STRG partition
|-
| 0x1C
| 0x4
| Length of STRG partition
|-
| 0x20
| 0x4
| Unknown (always 0x01200000?)
|-
| 0x24
| 0x4
| Location of INFO partition
|-
| 0x28
| 0x4
| Length of INFO partition
|-
| 0x30
| 0x4
| Location of main FILE partition
|-
| 0x34
| 0x4
| Length of main FILE partition
|-
| 0x38
| 0x4
| Reserved for 4th main partition location?
|-
| 0x3C
| 0x4
| Reserved for 4th main partition length?
|-
|}

== Partitions ==

=== STRG ===

STRG contains the names of the audio files in the BCSAR.

Header:

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| MAGIC "STRG"
|-
| 0x4
| 0x4
| Length of STRG partition (also in CSAR header)
|-
| 0x18
| 0x4
| Count of audio names (since each file should have a name you could also say this is essentially a file count)
|-
|}

Then for each name:

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Type of the file...?
|-
| 0x4
| 0x4
| Offset of the filename...?
|-
| 0x8
| 0x4
| Size of the filename
|-
|}
Then every filename is rawly setted. You can set up a dictionary that contains, using a simple counter, the size of every filename in order. Then, using the same type of counter, get the values of the size of the filename in a correct order.
=== INFO ===

INFO presumably contains information on the audio files? Possibly used to connect names from STRG to data from FILE?

For now I only know some information in the header for this partition, but I'm working on figuring the rest out.

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| MAGIC "INFO"
|-
| 0x4
| 0x4
| Length of INFO partition (also in CSAR header)
|-
|}

=== FILE ===

FILE contains all of the audio data in the BCSAR.

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| MAGIC "FILE"
|-
| 0x4
| 0x4
| Length of FILE partition (also in CSAR header)
|-
|}

There isn't a whole lot else I can document about the FILE partition, since the data in it will most definitely vary depending on the game. (since audio is more than likely to change in each game)

There is no table in FILE so a different partition (presumably INFO) must be used to connect the data in FILE with the names from STRG.

After some more research, there are multiple FILE partitions, but only 1 of them is the 'main' FILE partition (it's the one you get from the BCSAR header). The 'main' FILE partition contains all of the other sub FILE partitions.

DARC

2015-03-02T15:46:53Z

LIT: /* File table */

[[Category:File formats]]
This page documents the format of DARC.

== Overview ==

DARC files are archives. Containers of files.

This is very similiar to NARC (the DS archives).

== ARC header ==
{| class="wikitable" border="1"
! Offset !! Size !! Type !! Description
|-
| 0x000 || 4 || char[4] || Magic Number 'darc'
|-
| 0x004 || 2 || uint16 || Endianess (=0xFFFE: Little)
|-
| 0x006 || 2 || uint16 || Header's length
|-
| 0x008 || 4 || uint32 || Version
|-
| 0x00C || 4 || uint32 || File's length
|-
| 0x010 || 4 || uint32 || [[DARC#File_table|File table]] offset (from the beginning of the file)
|-
| 0x014 || 4 || uint32 || [[DARC#File_table|File table]] length
|-
| 0x018 || 4 || uint32 || [[DARC#Files_data|Files data]] offset
|}

=== File table ===

The file table starts at 0x01C.

Each file struct consists of 3 uint32:
{| class="wikitable" border="1"
! Offset !! Size !! Type !! Description
|-
| 0x000 || 4 || uint32 || File name offset (from the end of the table)

if (offset & 0x01000000) then this is a folder (i.e. first two nodes 'null' & '.')
|-
| 0x004 || 4 || uint32 || File offset
|-
| 0x008 || 4 || uint32 || File length
|}

* Folder's length is the file count.

DARC

2015-01-23T12:19:37Z

LIT:

[[Category:File formats]]
This page documents the format of DARC.

== Overview ==

DARC files are archives. Containers of files.

This is very similiar to NARC (the DS archives).

== ARC header ==
{| class="wikitable" border="1"
! Offset !! Size !! Type !! Description
|-
| 0x000 || 4 || char[4] || Magic Number 'darc'
|-
| 0x004 || 2 || uint16 || Endianess (=0xFFFE: Little)
|-
| 0x006 || 2 || uint16 || Header's length
|-
| 0x008 || 4 || uint32 || Version
|-
| 0x00C || 4 || uint32 || File's length
|-
| 0x010 || 4 || uint32 || [[DARC#File_table|File table]] offset (from the beginning of the file)
|-
| 0x014 || 4 || uint32 || [[DARC#File_table|File table]] length
|-
| 0x018 || 4 || uint32 || [[DARC#Files_data|Files data]] offset
|}

=== File table ===

The file table starts at 0x01C.

Each file struct consists of 3 uint32:
{| class="wikitable" border="1"
! Offset !! Size !! Type !! Description
|-
| 0x00C || 4 || uint32 || File name offset (from the end of the table)

if (offset & 0x01000000) then this is a folder (i.e. first two nodes 'null' & '.')
|-
| 0x004 || 4 || uint32 || File offset
|-
| 0x008 || 4 || uint32 || File length
|}

* Folder's length is the file count.