Editing Mach-O (section)

=== Segment load command ===
Mach-O binaries that use load command type {{code|0x00000001}} use the 32-bit version of the segment load command,<ref>{{cite web |work=OS X ABI Mach-O File Format Reference |title=segment_command |date=2009-02-04 |orig-date=2003 |publisher=[[Apple Inc.]] |url=https://developer.apple.com/library/mac/documentation/developertools/conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-segment_command |url-status=dead |archive-url=https://web.archive.org/web/20140904004108mp_/https://developer.apple.com/library/mac/documentation/developertools/conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-segment_command |archive-date=2014-09-04}}</ref> while {{code|0x00000019}} is used to specify the 64-bit version of the segment load command.,<ref>{{cite web |work=OS X ABI Mach-O File Format Reference |title=segment_command_64 |date=2009-02-04 |orig-date=2003 |publisher=[[Apple Inc.]] |url=https://developer.apple.com/library/mac/documentation/developertools/conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-CJBDHJGA |url-status=dead |archive-url=https://web.archive.org/web/20140904004108mp_/https://developer.apple.com/library/mac/documentation/developertools/conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/20001298-CJBDHJGA |archive-date=2014-09-04}}</ref>

The segment load command varies if the Mach-O header is 32-bit, or 64-bit. This is because 64-bit processor architecture uses 64-bit addresses while 32-bit architectures use 32-bit addresses.

All virtual RAM addresses are added to a base address to keep applications spaced apart. Each section in a segment load command has a relocation list offset that specifies the offsets in the section that must be adjusted based on the application's base address. The relocations are unnecessary if the application can be placed at its defined RAM address locations such as a base address of zero.
{|class="wikitable"
|+ Load command (Segment load32/64)
|-
! Offset(32-bit) !! Bytes(32-bit) !!  Offset(64-bit) !! Bytes(64-bit) !! Description
|-
| 0 || 4 || 0 || 4 || {{code|0x00000001}} (Command type 32-bit)
{{code|0x00000019}} (Command type 64-bit)
|-
| 4 || 4 || 4 || 4 || Command size
|-
| 8 || 16 || 8 || 16 || Segment name
|-
| 24 || 4 || 24 || 8 || Address
|-
| 28 || 4 || 32 || 8 || Address size
|-
| 32 || 4 || 40 || 8 || File offset
|-
| 36 || 4 || 48 || 8 || Size (bytes from file offset)
|-
| 40 || 4 || 56 || 4 || Maximum virtual memory protections
|-
| 44 || 4 || 60 || 4 || Initial virtual memory protections
|-
| 48 || 4 || 64 || 4 || Number of sections
|-
| 52 || 4 || 68 || 4 || Flag32
|}

A segment name cannot be larger than 16 text characters in bytes. The unused characters are {{code|0x00}} in value.

The segment command contains the address to write the section in virtual address space plus the application's base address. The number of bytes to write to the address location (Address size).

After the address information is the file offset the segment data is located in the Mach-O binary, and the number of bytes to read from the file.

When the address size is larger than the number of bytes to read from the file, the rest of the bytes in RAM space are set {{code|0x00}}.

There is a segment that is called <code>__PAGEZERO</code>, which has a file offset of zero and a size of zero in the file. It has a defined virtual memory address and size. Its access permissions are set to zero as well, meaning it cannot be used at all (any access to this segment will cause a page fault). The purpose of this segment is to catch invalid NULL pointers (which have a value of zero). On 32-bit environments, the default size of this segment is 4KiB, while on 64-bit environments it is 4GiB (this catches invalid 32-bit NULL pointers which may have been truncated during a round-trip assignment through a 32-bit integer.) The size of this segment is configurable through the <code>-pagezero_size</code> compiler/linker flag.

When a segment is initially placed in the virtual address space, it is given the CPU access permissions specified by the initial virtual memory protections value.  The permissions on a region of the virtual address space may be changed by application or library code with calls to routines such as {{code|mprotect()}}; the maximum virtual memory protections limit what permissions may be granted for access to the segment.

{|class="wikitable"
|+ Permissions
|-
! Permission bit in binary !! Description
|-
| {{code|00000000000000000000000000000001}} || The section allows the CPU to read data from this section (Read setting).
|-
| {{code|00000000000000000000000000000010}} || The section allows the CPU to write data to this section (Write setting).
|-
| {{code|00000000000000000000000000000100}} || The section allows the CPU to execute code in this section (Execute setting).
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxx000}} || The digits marked with "x" have no use, and are reserved for future use.
|}

Then after the CPU address protection settings is the number of sections that are within this segment that are read after the segments flag settings.

The segment flag settings are as follows:

{|class="wikitable"
|+ Segment flag settings.
|-
! Flag32 in Binary !! Description
|-
| {{code|00000000000000000000000000000001}} || The file contents for this segment is for the high part of the VM space, the low part is zero filled (for stacks in core files).
|-
| {{code|00000000000000000000000000000010}} || This segment is the VM that is allocated by a fixed VM library, for overlap checking in the link editor.
|-
| {{code|00000000000000000000000000000100}} || This segment has nothing that was relocated in it and nothing relocated to it, that is it maybe safely replaced without relocation.
|-
| {{code|00000000000000000000000000001000}} || This segment is protected. If the segment starts at file offset 0, the first page of the segment is not protected. All other pages of the segment are protected.
|-
| {{code|00000000000000000000000000010000}} || This segment is made read-only after relocations are applied if needed.
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxx00000}} || The digits marked with "x" have no use, and are reserved for future use.
|}

The number of sections in the segment is a set of entries that are read as follows:

{|class="wikitable"
|+ Segment section32/64
|-
! Offset(32-bit) !! Bytes(32-bit) !!  Offset(64-bit) !! Bytes(64-bit) !! Description
|-
| 0 || 16 || 0 || 16 || Section name
|-
| 16 || 16 || 16 || 16 || Segment name
|-
| 32 || 4 || 32 || 8 || Section Address
|-
| 36 || 4 || 40 || 8 || Section size
|-
| 40 || 4 || 48 || 4 || Section file offset
|-
| 44 || 4 || 52 || 4 || Alignment
|-
| 48 || 4 || 56 || 4 || Relocations file offset
|-
| 52 || 4 || 60 || 4 || Number of relocations
|-
| 56 || 4 || 64 || 4 || Flag/Type
|-
| 60 || 4 || 68 || 4 || Reserved1
|-
| 64 || 4 || 72 || 4 || Reserved2
|-
| N/A || N/A || 76 || 4 || Reserved3 (64-bit only)
|}

The section's segment name must match the segments load command name. The sections entries locate to data in the segment. Each section locates to the relocation entries for adjusting addresses in the section if the application base address is added to anything other than zero.

The section size applies to both the size of the section at its address location and size in the file at its offset location.

The section Flag/Type value is read as follows:

{|class="wikitable"
|+ Section flag settings
|-
! Flag in binary !! Description
|-
| {{code|10000000000000000000000000000000xxxxxxxx}} || Section contains only true machine instructions
|-
| {{code|01000000000000000000000000000000xxxxxxxx}} || Section contains coalesced symbols that are not to be in a ranlib table of contents
|-
| {{code|00100000000000000000000000000000xxxxxxxx}} || Ok to strip static symbols in this section in files with the MH_DYLDLINK flag
|-
| {{code|00010000000000000000000000000000xxxxxxxx}} || No dead stripping
|-
| {{code|00001000000000000000000000000000xxxxxxxx}} || Blocks are live if they reference live blocks
|-
| {{code|00000100000000000000000000000000xxxxxxxx}} || Used with i386 code stubs written on by dyld
|-
| {{code|00000010000000000000000000000000xxxxxxxx}} || A debug section
|-
| {{code|00000000000000000000010000000000xxxxxxxx}} || Section contains some machine instructions
|-
| {{code|00000000000000000000001000000000xxxxxxxx}} || Section has external relocation entries
|-
| {{code|00000000000000000000000100000000xxxxxxxx}} || Section has local relocation entries
|}
Any of the settings that apply to the section have a binary digit set one. The last eight binary digits is the section type value.

{|class="wikitable"
|+ Section type value
|-
! Flag in binary !! Description
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00000110}} || Section with only non-lazy symbol pointers
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00000111}} || Section with only lazy symbol pointers
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00001000}}|| Section with only symbol stubs
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00001100}} || Zero fill on demand section (that can be larger than 4 gigabytes)
|-
| {{code|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00010000}} || Section with only lazy symbol pointers to lazy loaded dylibs
|}

The Mach-O loader records the symbol pointer sections and symbol stub sections. They are sequentially used by the indirect symbol table to load in method calls.

The size of each symbol stub is stored in reserved2 value. Each pointer is 32-bit address locations in 32-bit Mach-O and 64-bit address locations in 64-bit Mach-O. Once the section end is reached, we move to the next section while reading the indirect symbol table.

==== Segment number and section numbers ====

The segments and sections are located by segment number and section number in the compressed and uncompressed link edit information sections.

A segment value of 3 would mean the offset to the data of the fourth segment load command in the Mach-O file starting from zero up (0,1,2,3 = 4th segment).

Sections are also numbered from sections 1 and up. Section value zero is used in the symbol table for symbols that are not defined in any section (undefined). Such as an method, or data that exist within another binaries symbol table section.

A segment that has 7 sections would mean the last section is 8. Then if the following segment load command has 3 sections they are labelled as sections 9, 10, and 11. A section number of 10 would mean the second segment, section 2.

We would not be able to properly read the symbol table and linking information if we do not store the order the sections are read in and their address/file offset position.

You can easily use file offset without using the RAM addresses and relocations to build a symbol reader and to read the link edit sections and even map method calls or design a disassembler.

If building a Mach-O loader, then you want to dump the sections to the defined RAM addresses plus a base address to keep applications spaced apart so they do not write over one another.

The segment names and section names can be renamed to anything you like and there link will be no problems locating the appropriate sections by section number, or segment number as long as you do not alter the order the segment commands go in.