Difference between revisions of "ARM binaries"
(clarified different formats available.) |
|||
| Line 44: | Line 44: | ||
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ELF file | | style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ELF file | ||
|} | |} | ||
| + | |||
| + | === BOOT2 elf loader === | ||
The BOOT2 elf stub loader sets up a stack, calculates its own address, and switches to THUMB mode. Then it does the following: | The BOOT2 elf stub loader sets up a stack, calculates its own address, and switches to THUMB mode. Then it does the following: | ||
| Line 53: | Line 55: | ||
0xD800000 seems to be the start of the (a?) hardware register space. | 0xD800000 seems to be the start of the (a?) hardware register space. | ||
| − | After this, it loads the ELF file, and then '''zeroes out the memory area where the ELF file resides'''. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 code seems to be | + | After this, it loads the ELF file, and then '''zeroes out the memory area where the ELF file resides'''. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 code seems to be position-independent: it can be loaded at any address and will still work, as long as it doesn't overlap with the destination of the ELF load. The entire BOOT2 file cleartext is loaded and then the loader is called, so the loader can calculate the offset of the header simply by subtracting 0x10 from the PC at its entrypoint. |
Revision as of 12:16, 24 January 2008
ARM binaries are contained inside .wad files in update partitions. The .wad format and how to decrypt it is described in WAD_Files.
ELF format
IOS modules, at least, use bare ELF files. The files seem to be compiled with GCC 3.4.3, and they are EABI compliant.
ELFLOADER format
The ELFLOADER ARM binary format is used for the "bootup" files, including the IOS kernel (or the entirety of the IOS in earlier versions which are monolithic) and BOOT2. Once decrypted, the data has the following format:
| Start | End | Length | Description |
| 0x000 | 0x004 | 0x004 | Header size = 0x0010 |
| 0x004 | 0x008 | 0x004 | Offset to ELF file after header |
| 0x008 | 0x00C | 0x004 | Size of ELF file |
| 0x00C | 0x010 | 0x004 | 0x00 padding / unused |
| 0x010 | variable | variable | ELF file stub loader binary |
| variable | variable | variable | ELF file |
BOOT2 elf loader
The BOOT2 elf stub loader sets up a stack, calculates its own address, and switches to THUMB mode. Then it does the following:
if( ! (*((u32 *)0xD800060) & 0x20) ) {
*((u32 *)0xD800060) |= 0x20;
}
0xD800000 seems to be the start of the (a?) hardware register space.
After this, it loads the ELF file, and then zeroes out the memory area where the ELF file resides. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 code seems to be position-independent: it can be loaded at any address and will still work, as long as it doesn't overlap with the destination of the ELF load. The entire BOOT2 file cleartext is loaded and then the loader is called, so the loader can calculate the offset of the header simply by subtracting 0x10 from the PC at its entrypoint.