Difference between revisions of "NSO"

From Nintendo Switch Brew
Jump to navigation Jump to search
Line 2: Line 2:
  
 
It starts with the "NSO" header and mainly describes .text, .rodata, and .data segments (like a short-form of ELF program headers):
 
It starts with the "NSO" header and mainly describes .text, .rodata, and .data segments (like a short-form of ELF program headers):
 
=== SegmentHeader ===
 
{| class="wikitable" border="1"
 
|-
 
! Offset
 
! Size
 
! Description
 
|-
 
| 0x0
 
| 4
 
| file offset of data
 
|-
 
| 0x4
 
| 4
 
| memory offset loaded to
 
|-
 
| 0x8
 
| 4
 
| size of data copied to memory offset (i.e. size after decompression)
 
|-
 
| 0xC
 
| 4
 
| alignment used on memory size / size of .bss in the case of .data segment
 
|}
 
  
 
=== .rodata-relative extent ===
 
=== .rodata-relative extent ===
Line 56: Line 32:
 
| 0x4
 
| 0x4
 
| 4
 
| 4
|  
+
| Version
 
|-
 
|-
 
| 0x8
 
| 0x8
 
| 4
 
| 4
|  
+
| Reserved1
 
|-
 
|-
 
| 0xC
 
| 0xC
 
| 4
 
| 4
| Always 0x3f?
+
| Flags: TextCompress = 1, RoCompress = 2, DataCompress = 4, TextHash = 8, RoHash = 0x10, DataHash = 0x20
 
|-
 
|-
 
| 0x10
 
| 0x10
| 0x10 * 3
+
| 4
| SegmentHeader for each segment
+
| TextFileOffset
 +
|-
 +
| 0x14
 +
| 4
 +
| TextMemoryOffset
 +
|-
 +
| 0x18
 +
| 4
 +
| TextSize
 +
|-
 +
| 0x1C
 +
| 4
 +
| ModuleNameOffset
 +
|-
 +
| 0x20
 +
| 4
 +
| RoFileOffset
 +
|-
 +
| 0x24
 +
| 4
 +
| RoMemoryOffset
 +
|-
 +
| 0x28
 +
| 4
 +
| RoSize
 +
|-
 +
| 0x2C
 +
| 4
 +
| ModuleNameSize
 +
|-
 +
| 0x30
 +
| 4
 +
| DataFileOffset
 +
|-
 +
| 0x34
 +
| 4
 +
| DataMemoryOffset
 +
|-
 +
| 0x38
 +
| 4
 +
| DataSize
 +
|-
 +
| 0x3C
 +
| 4
 +
| BssSize
 
|-
 
|-
 
| 0x40
 
| 0x40
Line 75: Line 95:
 
|-
 
|-
 
| 0x60
 
| 0x60
| 0x4 * 3
+
| 0x4
| file size of each segment (i.e. LZ4-compressed size)
+
| TextFileSize
 +
|-
 +
| 0x64
 +
| 0x4
 +
| RoFileSize
 +
|-
 +
| 0x68
 +
| 0x4
 +
| DataFileSize
 
|-
 
|-
 
| 0x6c
 
| 0x6c

Revision as of 16:07, 3 August 2017

NSO is the main executable format.

It starts with the "NSO" header and mainly describes .text, .rodata, and .data segments (like a short-form of ELF program headers):

.rodata-relative extent

Offset Size Description
0x0 4 offset (relative to .rodata)
0x4 4 size of region

NSO Header

Offset Size Description
0x0 4 Magic "NSO0"
0x4 4 Version
0x8 4 Reserved1
0xC 4 Flags: TextCompress = 1, RoCompress = 2, DataCompress = 4, TextHash = 8, RoHash = 0x10, DataHash = 0x20
0x10 4 TextFileOffset
0x14 4 TextMemoryOffset
0x18 4 TextSize
0x1C 4 ModuleNameOffset
0x20 4 RoFileOffset
0x24 4 RoMemoryOffset
0x28 4 RoSize
0x2C 4 ModuleNameSize
0x30 4 DataFileOffset
0x34 4 DataMemoryOffset
0x38 4 DataSize
0x3C 4 BssSize
0x40 0x20 Value of "build id" from ELF's GNU .note section. Contains variable sized digest, up to 32bytes.
0x60 0x4 TextFileSize
0x64 0x4 RoFileSize
0x68 0x4 DataFileSize
0x6c 0x24 Padding
0x90 8 .rodata-relative extents of .dynstr
0x98 8 .rodata-relative extents of .dynsym
0xA0 0x20 * 3 SHA256 hashes over the decompressed sections using the above byte-sizes: .text, .rodata, and .data.
0x100 Compressed sections

Most data in Switch binaries are standard ELF structures, however some are custom. For example, the MOD header is essentially a replacement for a PT_DYNAMIC program header.

MOD

All offsets are signed 32bit values relative to the magic field. The 32bits at image base + 4 must point to the magic field. The MOD structure is designed such that it can be placed at image base and point to itself. The 2 fields preceding the magic field get copied around with the structure, even if it is relocated to somewhere besides the image base. If MOD is not located at image base, the value at offset 4 must still point to the MOD magic. In the case of .text being at image base, this implies that the first instruction can only be an unconditional branch over the offset literal.

Offset Size Description
0x00 4 zero padding
0x04 4 offset to magic. Always 8 (so it works when MOD is at image_base + 0).
0x08 4 magic "MOD0"
0x0C 4 .dynamic offset
0x10 4 .bss start offset
0x14 4 .bss end offset
0x18 4 .eh_frame_hdr start offset
0x1C 4 .eh_frame_hdr end offset
0x20 4 offset to runtime-generated module object. typically equal to .bss base.