Symbian OS Internals/Appendix 2: The E32ImageHeader

Comments

(no comments yet)

Log in or Join to leave comments.

Article Metadata

---

Article

Created: hamishwillee (17 Jan 2011)

Last edited: hamishwillee (26 Jul 2012)

• Symbian OS Internals Table of Contents

This section describes the image header for Symbian OS executable files, as defined in the file F32IMAGE.H. There are three formats for the E32ImageHeader:

• Basic format - header contains no compression, security or version number information
• J-format - header may contain compression information. In addition to the basic format fields, if the compression type (at offset 1C) is nonzero, the header includes an extra field holding the uncompressed size of the file
• V-format - the executable contains versioning and security information. In addition to the basic and J-format fields, the header includes extra security and versioning related fields.

Basic format fields:

Offset (hex)	Description of field
00	UID 1
04	UID 2
08	UID 3
0C	Checksum of UIDs.
10	Signature (EPOC = 0x434F5045).
14	CRC-32 of entire header for V-format, CPU identifier for original and J-formats.
18	Version number of this executable - a 16-bit major and a 16-bit minor version number. This is used in link resolution (V-format only). In original format, this contained a checksum of the code, but this was never used.
1C	Type of compression used (UID or 0 for none).
20	Version of PETRAN/ELFTRAN which generated this file.
24	Time at which file was generated, in standard EPOC encoding (microseconds since 00:00:00 01-01-00AD).
2C	Flags field - see later in this appendix for more details.
30	Code size (includes constant data, IAT and export directory).
34	Initialized data size.
38	Heap minimum size (only used for EXEs).
3C	Heap maximum size (only used for EXEs).
40	Stack size (only used for EXEs).
44	BSS (zero-filled data) size.
48	Offset in code of entry point.
4C	Code base address (where code is linked for).
50	Data base address (where data is linked for).
54	Number of DLLs referenced.
58	Offset into the file of the export address table.
5C	Number of entries in export address table.
60	Size of text section (offset of IAT within code section).
64	Offset in file to code section.
68	Offset in file to data section.
6C	Offset in file to import section.
70	Offset in file to code relocations.
74	Offset in file to data relocations.
78	Priority of this process (only used for EXEs).
7A	CPU (0x1000 = X86, 0x2000 = ARM).

For J-formatted headers, if the Type of compression field is nonzero, then the following field will be present. For V-formatted headers, it is always present:

7C	Uncompressed size of the file.

For V-formatted headers, the following fields will be present:

80	Security information (capabilities, secure ID, vendor ID).
90	Offset from start of code section to exception descriptor (for C++ exception unwinding) + 1. Bit 0 is set if this is valid, bit 0 is clear if there is no exception descriptor.
94	Spare.
98	Size of bitmap description holes in the export table.
9A	Format of bitmap describing holes in the export table (described later in this appendix).
9B	Bitmap describing any holes in the export table. This is a variable length field.

The flags field at offset 2C in the header is a bitmapped field, defined as follows:

Bits	Size in bits	Description
0	1	Executable type: 0 - EXE 1 - DLL
1	1	Whether to call entry point (not used in EKA2): 0 - call entry point 1 - don't call entry point
2	1	Whether this is a fixed address EXE: 0 - not fixed address 1 - fixed address
4-3	2	ABI: 0 - GCC98r2 1 - EABI
7-5	3	Entry point type: 0 - EKA1 1 - EKA2
23-8	16	Reserved
27-24	4	Header format: 0 - Basic 1 - J-format 2 - V-format
31-28	4	Import format: 0 - Standard PE format 1 - ELF format 2 - PE format without redundant copy of import ordinals. Standard PE format is only used with original and J-format headers. V-format headers are either ELF or PE without redundant import ordinals.

For V-formatted headers, the field describing the format of the export table bitmap may have one of the following values:

Value	Description
00H	No holes, all exports are present.
01H	A full bitmap is present, that is, there is one bit for each export directory slot - a 1 indicates export present, a 0 indicates export absent.
02H	A sparse bitmap is present (granularity 8). This consists of two sections. The first section contains one bit for each group of eight consecutive export directory slots. A 0 bit indicates that all these slots contain valid exports and no further description of them is necessary. A 1 bit indicates that at least one of the eight exports is absent, and there is a bit mask byte in the second section describing which of the eight is present. The bytes in the second section occur in the same order as the bits in the first section.
FFH	XIP file.