Binary Resource

Binary Resource (or BINA) is a container format for binary data developed by Sonic Team.

Engines using Binary Resource

Engine	Version	Games
SoX	1	Sonic the Hedgehog (2006)
Hedgehog Engine	1	Sonic Colors
	2	Sonic Lost World
Hedgehog Engine 2	2

Specifications

Binary Resource has two known major versions.

Version 1

Header

The header consists of the following data structure:

Length: 0x20

Offset	Type	Name	Description
0x00	UInt32	ResourceSize	The size of the resource.
0x04	UInt32	RelocTableOffset	The offset of the relocation table relative to the end of the header.
0x08	UInt32	RelocTableLength	The length of the relocation table.
0x0C	UInt32	N/A	Unknown. Usually zero.
0x10	UInt32	ChunkCount	The total number of chunks in the data section. Only used in Sonic Colors.
0x14	Char[4]	Version	The first two characters are skipped, leaving Revision and Endianness. The endianness character is either 'L' or 'B', for little-endian and big-endian respectively.
0x18	Char[4]	Signature	Always "BINA".
0x1C	UInt32	N/A	Unknown. Usually zero.

Due to the nature of the header, you must read ahead 0x14 bytes to read the Version field to get the endianness of the file before proceeding with the rest of the fields at the start of the file.

Data Section

The data after the header is specific to each file format contained within a Binary Resource.

All offset fields inside the data section are relative to the end of the header, so you must add the size of the header to the offset to get the absolute offset to where it's pointing to in the file on disk.

MyOffset = ReadUInt32() + HeaderSize // HeaderSize = 0x20

Relocation Table

After the data section is a relocation table, which is used by the Binary Resource loader to locate offsets in the data section to make them absolute pointers. This allows the data section to be mapped directly to a structure without having to read it manually.

The relocation table must be aligned to 4 bytes before and after writing it.

Each entry in the relocation table is encoded as such:

Type Bits	Length	Minimum	Maximum	Description
0b01000000	6 bits	0x00	0x3F	The offset is stored in the remaining six bits after the type bits.
0b10000000	14 bits	0x3F	0x3FFF	The offset is stored in the remaining six bits after the type bits, including an extra byte.
0b11000000	30 bits	0x3FFF	0x3FFFFFFF	The offset is stored in the remaining six bits after the type bits, including an extra three bytes.

To encode an entry in the relocation table, first subtract the current offset with the previous offset that was encoded, then bit shift the result to the right by two bits. When encoding the first entry in the relocation table, the previous offset will be the size of the header (0x20).

EncodedOffset = (CurrentOffset - PreviousOffset) >> 2

After this, the value of the encoded offset can be used to determine which type bits are needed to fit it in the relocation table.

Footer

If the ChunkCount field in the header is non-zero, a footer must be written to the end of the file. The purpose of this footer isn't fully understood, but it only appears to be used in Sonic Colors.

Length: 0x0C

Offset	Type	Name	Description
0x00	UInt32	N/A	Unknown. Always 16.
0x04	UInt32	N/A	Unknown. Always zero.
0x08	Char[4]	N/A	Always "bvh\0".