28
edits
Changes
Jump to navigation
Jump to search
Create RPL page with documentation on import/export tables
RPL and RPX executables are modified ELF shared objects used by [[Cafe OS]].
They differ from regular ELF files in a few significant ways:
* some sections are zlib-compressed
* there are no program headers (section headers are used to load the executable into memory instead)
* dynamic linking imports are done with import/export tables (similar to Windows PE, according to the fail0verflow presentation)
== Sections ==
=== .fexports/.dexports sections ===
Each export table section is composed of an 8-byte header, a list of export entries (8 bytes each), 8 bytes of padding, and a nametable.
fexports is used for code; dexports is used for data.
Header:
<pre>
uint32_t num_entries; // 0
uint32_t checksum?; // 4
</pre>
Export entry:
<pre>
uint32_t addr; // 0
uint32_t name_index; // 4; index into the nametable
</pre>
8 bytes of padding: all zeroes; comes after the entries and before the nametable
nametable: a table of null-terminated strings
=== .fimport_(*)/.dimport_(*) sections ===
The section contains a header:
<pre>
uint32_t num_entries; //0
uint32_t checksum?; // 4
char library_name[]; // 8
</pre>
library_name is a null terminated string.
The rest of the section is padded with zeroes.
There are relocations into this section, which is marked alloc and execute for fimport and alloc for dimport: the runtime loader probably populates this area after load with PLT or GOT entries.
They differ from regular ELF files in a few significant ways:
* some sections are zlib-compressed
* there are no program headers (section headers are used to load the executable into memory instead)
* dynamic linking imports are done with import/export tables (similar to Windows PE, according to the fail0verflow presentation)
== Sections ==
=== .fexports/.dexports sections ===
Each export table section is composed of an 8-byte header, a list of export entries (8 bytes each), 8 bytes of padding, and a nametable.
fexports is used for code; dexports is used for data.
Header:
<pre>
uint32_t num_entries; // 0
uint32_t checksum?; // 4
</pre>
Export entry:
<pre>
uint32_t addr; // 0
uint32_t name_index; // 4; index into the nametable
</pre>
8 bytes of padding: all zeroes; comes after the entries and before the nametable
nametable: a table of null-terminated strings
=== .fimport_(*)/.dimport_(*) sections ===
The section contains a header:
<pre>
uint32_t num_entries; //0
uint32_t checksum?; // 4
char library_name[]; // 8
</pre>
library_name is a null terminated string.
The rest of the section is padded with zeroes.
There are relocations into this section, which is marked alloc and execute for fimport and alloc for dimport: the runtime loader probably populates this area after load with PLT or GOT entries.