NSO

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):

NSO Header

Offset	Size	Description
0x0	4	Magic "NSO0"
0x4	4
0x8	4
0xC	4	Always 0x3f?
0x10	0x10 * 3	SegmentHeader[3]
0x40	0x20	Value of "build id" from ELF's GNU .note section. Contains variable sized digest, up to 32bytes.
0x60	0x4 * 3	CompressedSize[3]
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.

SegmentHeader

Offset	Size	Description
0x0	4	FileOffset
0x4	4	MemoryOffset
0x8	4	DecompressedSize
0xC	4	UnkOffset/UnkSize/BssSize

.rodata-relative extent

Offset	Size	Description
0x0	4	RegionRoDataOffset
0x4	4	RegionSize

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	ZeroPadding
0x04	4	MagicOffset. 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.

Arguments

It's unknown how Loader determines where to store the arguments. Official processes use argdata_addr = {page-aligned _end}. svcQueryMemory is used by official sw to verify that argdata_addr is mapped RW. Afterwards, official sw aligns the argdata_addr to 4-bytes. Structure located at argdata_addr:

Offset	Size	Description
0x0	0x4	This is the total allocated space relative to argdata_addr, used for calculating the max size of the argv ptr array.
0x4	0x4	This is the total_bytesize of the actual argdata string.
0x20	See above	Actual argdata string.

argv_ptrarray written by official processes is at (actual_argdata_string+(actual_argdata_size*2)) + 0x9 & ~0x7.