How to read an ELF file. ELF and PE EXE

19.5 Generalized URL format summarizing the foregoing, we note that :? The URL begins with the instructions of the access protocol used.? For all applications, except network news and email, follows the separator: //.? Then the server host name is specified.? Finally

3.3.1. The RSS format read the news sites can be different. The easiest way is to go from time to time to the site and view new messages. You can put a program that connects to the news channel and the headlines or the news annotations itself are

MP3 format MP3 format was created to distribute music files compressed by the MPEG 1 Level code. 3. Currently, the most popular format for distributing music via the Internet, and not only. Supported by absolutely all sound recording and processing programs, for

Format MP3 sound compression method, as well as compressed format sound FilesThe Moving Pictures Experts Group (Moving Pictures Experts Group is a video recording expert group) is based on perceptual sound coding. Work on the creation of effective coding algorithms

ELF format ELF format has several types of files that have so far called differently, for example, executable file or object file. Nevertheless, the ELF standard distinguishes the following types: 1. Relocatable File, storing instructions and data that may be

The format of the numbers was finally reached to the format of numbers. I have already mentioned him again, now I will decompose everything on the shelves (although the general meaning you could already understand). The calculus in Excel can be displayed in various formats. In this section, we will talk about what the formats of numbers exist and how

Version of this answer with good Toc and large amounts of content: http://www.cirosantilli.com/elf-hello-world (click here 30K CHAR limit)

Standards

ELF sets LSB:

• core Generic: http://refspecs.linuxfoundation.org/lsb_4.1.0/lsb-core-generic/lsb-core-generic/elf-regneric.html
• core AMD64: http://refspecs.linuxfoundation.org/lsb_4.1.0/lsb-core-amd64/lsb-core-amd64/book1.html

LSB mainly refers to other standards with minor expansions, in particular:

generic (Both SCO):

• System V ABI 4.1 (1997) http://www.sco.com/developers/devspecs/gabi41.pdf, not 64 bits, although the magic number is reserved for it. The same for basic files.
• System V ABI UPDATE DRAFT 17 (2003) http://www.sco.com/developers/Gabi/2003-12-17/contents.html adds 64 bits. Only updates chapters 4 and 5 of the previous document: the rest remain in strength and still refer.

• specific architecture:

  • IA-32: http://refspecs.linuxfoundation.org/lsb_4.1.0/lsb-core-ia32/lsb-core-ia32/elf-pore32.html indicates mainly at http://www.sco.com/developers /Devspecs/abi386-4.pdf.
  • AMD64: http://refspecs.linuxfoundation.org/lsb_4.1.0/lsb-core-amd64/lsb-core-amd64/elf-amd64.html, mainly indicates http://www.x86-64.org/ Documentation / ab.pdf.

Convenient resume can be found at:

Its structure can be considered using convenient methods such as READELF and OBJDUMP.

Create example

Let me break the minimum executable example of Linux x86-64:

Section .data Hello_World DB "Hello World!", 10 Hello_World_len Equ $ - Hello_World Section .Text Global _START _START: MOV RAX, 1 MOV RDI, 1 MOV RSI, Hello_World Mov RDX, Hello_World_len Syscall Mov Rax, 60 MOV RDI, 0 Syscall

Compiled with help

NASM -W + ALL -F ELF64 -O "Hello_World.o" "Hello_World.asm" LD -O "Hello_World.out" "Hello_World.o"

• NASM 2.10.09
• Binutils version 2.24 (contains LD)
• Ubuntu 14.04

We do not use the program on C, as this will complicate the analysis that will be 2: -)

hexadecimal submissions binary

Global file structure

The ELF file contains the following parts:

• ELF header. Specifies the section title table position and program header table.

  The partition title table (optional in the executable file). Each of them has the headlines of the E_Shnum sections, each of which indicates the position of the section.

  N sections with n<= e_shnum (необязательно в исполняемом файле)

  Table of program headers (only for executable files). Each of them has an E_phnum program headers, each of which indicates the position of the segment.

  N segments, with n<= e_phnum (необязательно в исполняемом файле)

The order of these parts is not fixed: the only fixed thing is the ELF header, which must be the first in the file: General documents say:

Header ELF.

The easiest way to watch the title:

READELF -H Hello_World.o Readelf -h Hello_World.out

Byte in the object file:

00000000 7F 45 4C 46 02 01 01 00 00 00 00 00 00 00 00 00 | .ELF ............ | 00000010 01 00 3E 00 01 00 00 00 00 00 00 00 00 00 00 00 | ..\u003e ............. | 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | [Email Protected]| 00000030 00 00 00 00 40 00 00 00 00 00 40 00 07 00 03 00 |[Email Protected]@.....|

00000000 7F 45 4C 46 02 01 01 00 00 00 00 00 00 00 00 00 | .ELF ............ | 00000010 02 00 3E 00 01 00 00 00 B0 00 40 00 00 00 00 00 | ..\u003e [Email Protected]| 00000020 40 00 00 00 00 00 00 00 10 01 00 00 00 00 00 00 |@...............| 00000030 00 00 00 00 40 00 38 00 02 00 40 00 06 00 03 00 |[Email Protected]@.....|

Presented Structure:

Typedef struct (unsigned char e_ident; Elf64_Half e_type; Elf64_Half e_machine; Elf64_Word e_version; Elf64_Addr e_entry; Elf64_Off e_phoff; Elf64_Off e_shoff; Elf64_Word e_flags; Elf64_Half e_ehsize; Elf64_Half e_phentsize; Elf64_Half e_phnum; Elf64_Half e_shentsize; Elf64_Half e_shnum; Elf64_Half e_shstrndx;) Elf64_Ehdr;

Manual disintegration:

0 0: Ei_mag \u003d 7F 45 4C 46 \u003d 0x7F "E", "L", "F": Magic number ELF

0 4: EI_CLASS \u003d 02 \u003d Elfclass64: 64-bit elf

0 5: Ei_Data \u003d 01 \u003d ElfData2LSB: Bolshoi data

0 6: Ei_Version \u003d 01: Format version

0 7: Ei_osabi (only in 2003) \u003d 00 \u003d Elfosabi_None: no extensions.

0 8: EI_PAD \u003d 8X 00: Reserved bytes. It must be installed in 0.

1 0: E_Type \u003d 01 00 \u003d 1 (Big Endian) \u003d ET_REL: Movered format

In the executable file 02 00 for ET_EXEC.

1 2: E_MACHINE \u003d 3E 00 \u003d 62 \u003d EM_X86_64: AMD64 architecture

1 4: E_Version \u003d 01 00 00 00: Must be 1

1 8: E_ENTRY \u003d 8X 00: PRINCE POINT POINT, OR 0, if applicable, as for the object file, because there is no entry point.

In the executable file it is B0 00 40 00 00 00 00 00. TODO: What else can we install? The kernel seems to put the IP directly into this value, it is not rigidly programmed.

2 0: E_PHOFF \u003d 8X 00: Displacement of the program title table, 0, if not.

40 00 00 00 in the executable file, that is, it starts immediately after the ELF header.

2 8: E_SHOFF \u003d 40 7x 00 \u003d 0x40: Displacement of the section Table file, 0, if not.

3 0: E_FLAGS \u003d 00 00 00 00 TODO. Especially for Arch.

3 4: E_EHSIZE \u003d 40 00: The size of this elf header. Why is this field? How can this change?

3 6: E_PHENTSIZE \u003d 00 00: Size of each program header, 0, if not.

38 00 in executable file: the length of the file is 56 bytes

3 8: E_phnum \u003d 00 00: Number of program title entries, 0, if not.

02 00 In the executable file: there are 2 entries.

3 A: E_SHENTSIZE and E_SHNUM \u003d 40 00 07 00: section title size and number of records

Table title sections

Array of ELF64_SHDR structures.

Each entry contains metadata about this section.

e_SHOFF The ELF header gives the starting position here, 0x40.

e_SHENTSIZE and E_Shnum from the ELF header say that we have 7 records, each 0x40 long.

Thus, the table takes bytes from 0x40 to 0x40 + 7 + 0x40 - 1 \u003d 0x1FF.

The names of some sections are reserved for certain types of sections: http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#special_sections, for example. .text required type SHT_PROGBITS and SHF_ALLOC + SHF_EXECINSTR

rEADELF -S Hello_World.o:

There are 7 section headers, starting at offset 0x40: Section Headers: Name Type Address Offset Size EntSize Flags Link Info Align [0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [1] .data PROGBITS 0000000000000000 00000200 0000000000000000 000000000000000d WA 0 0 4 [ 2] .text PROGBITS 0000000000000000 00000210 0000000000000027 0000000000000000 AX 0 0 16 [3] .shstrtab STRTAB 0000000000000000 00000240 0000000000000032 0000000000000000 0 0 1 [4] .symtab SYMTAB 0000000000000000 00000280 0000000000000018 00000000000000a8 5 6 4 [5] .strtab STRTAB 00000330 0000000000000000 0000000000000034 0000000000000000 0 0 1 [6] .rela.text Rela 000000000000000000370 00000000000018 00000000000018 4 2 4 KEY TO FLAGS: W (WRITE), A (Alloc), X (Execute), M (Merge), S (Strings), L (LARGE) I (Info), L (Link Order), G (Group), T (TLS), E (EXCLUDE), X (Unknown) O (Extra OS Processing Required) O (OS SPECIFIC), P (Processor Specific)

struct, represented by each entry:

Typedef struct (Elf64_Word sh_name; Elf64_Word sh_type; Elf64_Xword sh_flags; Elf64_Addr sh_addr; Elf64_Off sh_offset; Elf64_Xword sh_size; Elf64_Word sh_link; Elf64_Word sh_info; Elf64_Xword sh_addralign; Elf64_Xword sh_entsize;) Elf64_Shdr;

Sections

Section of the index 0.

Contained in bytes from 0x40 to 0x7F.

The first section is always magical: http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html says:

If the number of sections is greater than or equal to SHN_LORESERVE (0xFF00), E_SHNUM has the value of SHN_UNDEF (0), and the actual number of entry title table entries is contained in the SH_SIZE field of the section title with an index 0 (otherwise a member of the SH_SIZE of the initial record contains 0).

In the Figure 4-7 section: Special Section Indexes have other magic sections.

In the index 0, sht_null is mandatory. Are there any other uses for this: what is the benefit from the SHT_NULL section in ELF? ?

.data section

DATA is a section 1:

00000080 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 | ................ | 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | 000000A0 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | 000000B0 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |

Here 1 says that the name of this section begins with the first symbol of this section and ends on the first NUL symbol, making up a string.data.

Data is one of the names of the partitions that has a predetermined value http://www.sco.com/developers/gabi-0003-12-17/ch4.strtab.html

These sections are the initialized data that contributes to the program memory.

• 80 4: sh_type \u003d 01 00 00 00: SHT_PROGBITS: The contents of the partition are not specified by the ELF, only how the program interprets it. Normally, as a .data.

  80 8: sh_flags \u003d 03 7x 00: shf_alloc and shf_execinstr: http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#sh_flags, as required from section.data

  90 0: sh_addr \u003d 8x 00: In which virtual address, the section will be placed during execution, 0 if not placed

  90 8: sh_offset \u003d 00 02 00 00 00 00 00 00 \u003d 0x200: the number of bytes from the start of the program to the first byte in this section

  a0 0: sh_size \u003d 0D 00 00 00 00 00 00 00

  If you take a 0xd byte, starting with sh_offset 200, we see:

  00000200 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A 00 | Hello WORLD! .. |

  AHA! So, our row "Hello World!" Located in the Data section, as we said it is on NASM.

  As soon as we finish HD, we will look at it as:

  READELF -X .DATA Hello_World.o

  which displays:

  HEX DUMP OF SECTION ".DATA": 0x00000000 48656c6c 6F20776F 726C6421 0A Hello WORLD!.

  NASM sets decent properties for this section, because it is magically refer to K.Data: http://www.nasm.us/doc/nasmdoc7.html#section-7.9.2

  Also note that it was the wrong selection of the section: a good C compiler would place the V.Rodata string instead, because it is read only, and this will continue the OS optimization.

  a0 8: sh_link and sh_info \u003d 8x 0: Do not apply to the type of this section. http://www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#special_sections

  b0 0: SH_ADDRALIGN \u003d 04 \u003d TODO: Why is this alignment needed? Is it only for sh_addr, as well as for characters inside sh_addr?

  b0 8: SH_ENTSIZE \u003d 00 \u003d Section does not contain tables. If! \u003d 0, this means that the section contains a table of fixed-size records. In this file, we see out of the READELF output, which is the case for sections.symtab I.Rela.Text.

.text section

Now that we have done one section manually, give a graduate and use readelf -s other sections.

Name Type Address Offset Size Entsize Flags Link Info Align [2] .Text ProgBits 00000000000000000027 0000000000000027 0000000000000027 00000000000000 AX 0 0 16

Text is executable, but not available for writing: If we try to write to him Linux Segfaults. Let's see if we really have a code:

ObjDump -D Hello_World.o.

Hello_World.o: File File File Elf64-x86-64 DisaSsembly of Section .text: 00000000000000<_start>: 0: B8 01 00 00 00 MOV $ 0x1,% Eax 5: BF 01 00 00 00 MOV $ 0x1,% EDI A: 48 BE 00 00 00 00 00 Movabs $ 0x0,% RSI 11: 00 00 00 14: BA 0D 00 00 00 MOV $ 0xd,% EDX 19: 0F 05 SYSCALL 1B: B8 3C 00 00 00 MOV $ 0x3c,% EAX 20: BF 00 00 00 00 MOV $ 0x0,% EDI 25: 0F 05 Syscall

If we have Grep B8 01 00 00 on HD, we see that this is only at 00000210, which is said in this section. And the size is 27, which also corresponds. Therefore, we must talk about the right section.

It looks like the right code: A WRITE, followed by EXIT.

The most interesting part is a string A, which makes:

Movabs $ 0x0,% RSI

transfer the address of the string to the system call. Currently, 0x0 is simply aggregate. After binding it will be changed:

4000ba: 48 BE D8 00 00 00 00 Movabs $ 0x6000d8,% RSI

This modification is possible due to the data section.rela.Text.

Sht_strtab.

Sections with sh_type \u003d\u003d SHT_STRTAB are called string tables.

Such sections are used by other partitions when string names should be used. The "Use" section says:

• what line they use
• what is an index in the table of target lines where the line begins

For example, we could have a string table containing: TODO: Do I need to start with \\ 0?

Data: \\ 0 a b C \\ 0 D E F \\ 0 index: 0 1 2 3 4 5 6 7 8

And if another partition wants to use the D E F string, they must indicate the index 5 of this section (letter D).

Famous string tables:

• .shstrtab.
• .strtab.

.shstrtab.

Section Type: SH_TYPE \u003d\u003d SHT_STRTAB.

Common Name: section title title string.

Section name. SSTRTAB Reserved. The standard says:

This section contains partition names.

This section indicates the E_Shstrnd field of the ELF header itself.

The lines of the lines of this section are specified by the SH_NAME field of sections headers that indicate the lines.

This section does not specify Shf_alloc, so it will not be displayed in the executable program.

READELF -X.SHSTRTAB Hello_World.o

Hex dump of section ".shstrtab": 0x00000000 002e6461 7461002e 74,657,874 73,747,274 002e7368 ..data..text..sh 0x00000010 6162002e 73796d74 6162002e strtab..symtab .. 0x00000020 73747274 6162002e 72656c61 2e746578 strtab..rela.tex 0x00000030 7400 t.

Data in this section have a fixed format: http://www.sco.com/developers/gabi/2003-12-17/ch4.strtab.html

If we look at the names of other sections, we will see that they all contain numbers, for example. Section .Text has number 7.

Then each line ends when the first NUL symbol is found, for example. Symbol 12 \\ 0 immediately after .Text \\ 0.

.symtab.

Section Type: sh_type \u003d\u003d SHT_SYMTAB.

Common Name: Character Table.

First, we note that:

• sh_link \u003d 5.
• sh_info \u003d 6.

In the SHT_SYMTAB section, these numbers mean that:

• Strings
• which give characters names are in section 5, .strtab
• data movements are located in section 6, .rela.text

Good tool high level To disassemble this section:

NM Hello_World.o.

which gives:

00000000000000 T _START 0000000000000000 D Hello_World 0000000000000D A Hello_World_len

This, however, representing a high level in which some types of characters are lowered and in which symbols are designated. More detailed disassembly can be obtained using:

READELF -S Hello_World.o.

which gives:

Symbol table ".symtab" contains 7 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello_world.asm 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 Section Local Default 2 4: 000000000000000000 0 Notype Local Default 1 Hello_World 5: 000000000000000d 0 Notype Local Default ABS Hello_World_len 6: 0000000000000000 0 Notype Global Default 2 _START

The binary format of the table is documented at http://www.sco.com/developers/Gabi/2003-12-17/ch4.symtab.html

READELF -X.SYMTAB Hello_World.o

What gives:

HEX DUMP OF SECTION ".SYMTAB": 0x00000000 00000000 00000000 00000000 00000000 ................ 0x00000010 00000000 00000000 01000000 0400F1FF ............... . 0x00000020 00000000 00000000 00000000 00000000 .................. 0x00000030 00000000 0x00000030 00000000 0x000000 00000000 00000000 .................. 0x00000040 00000000 00000000 000000 03000200 ................ 0x00000050 00000000 00000000 00000000 00000000 ................ 0x00000060 11000000 00000000 000000 00000000 .......... ...... 0x00000070 00000000 00000000 1D000000 0000F1FF ................ 0x00000080 0D000000 00000000 00000000 00000000 ................ 0x00000090 2D000000 10000200 00000000 00000000 --............... 0x000000A0 00000000 00000000 ........

Records are type:

TypeDef Struct (ELF64_WORD ST_NAME; unsigned char st_info; unsigned char st_other; ELF64_HALF ST_SHNDX; ELF64_ADDR ST_VALUE; ELF64_XWORD ST_SIZE;) ELF64_SYM;

As in the partition table, the first record of the magic and is set by fixed meaningless values.

Recording 1 has ELF64_R_TYPE \u003d\u003d STT_FILE. ELF64_R_TYPE continues inside ST_INFO.

Byte analysis:

10 8: ST_NAME \u003d 01000000 \u003d Symbol 1 V.STRTAB, which up to the next \\ 0 makes hello_world.asm

This fragment of the information file can be used by the linker to determine which segment segments are going.

10 12: St_info \u003d 04

Bits 0-3 \u003d ELF64_R_TYPE \u003d Type \u003d 4 \u003d STT_FILE: The main purpose of this entry is to use ST_NAME to specify the file name generated by this object file.

Bits 4-7 \u003d ELF64_ST_BIND \u003d binding \u003d 0 \u003d STB_LOCAL. Required value for STT_FILE.

10 13: ST_SHNDX \u003d Symbol Table Table Headers Index \u003d F1FF \u003d SHN_ABS. Required for STT_FILE.

20 0: ST_VALUE \u003d 8X 00: required for value for STT_FILE

20 8: ST_SIZE \u003d 8X 00: no highlighted size

Now from READELF, we quickly interpret the rest.

STT_SECTION

There are two such elements, one specifies by .data, and the other on thisText (partition indexes 1 and 2).

Num: Value Size Type Bind VIS NDX Name 2: 000000000000000000 0 Section Local Default 1 3: 0000000000000000 0 Section Local Default 2

TODO, what is their goal?

STT_NOTYPE.

Then enter the most important characters:

Num: Value Size Type Bind VIS NDX Name 4: 000000000000000000 0 Notype Local Default 1 Hello_World 5: 000000000000000d 0 Notype Local Default ABS Hello_World_len 6: 00000000000000 0 Notype Global Default 2 _START Line

hello_World is located in the section.data (index 1). This value is 0: It indicates the first byte of this section.

Start is marked by the visibility of Global, as we wrote:

Global _STart.

in NASM. This is necessary, as it should be considered as an entry point. Unlike C, the default NASM labels are local.

hello_World_len Indicates a special ST_SHNDX \u003d\u003d SHN_ABS \u003d\u003d 0xF1FF.

0xF1FF is selected so as not to contradict to other sections.

sT_VALUE \u003d\u003d 0XD \u003d\u003d 13, which is the value that we have saved there on the assembly: the length of the HELLO WORLD string! .

This means that the movement will not affect this value: it is a constant.

This is a small optimization that our assembler makes for us and has ELF support.

If we used the address Hello_World_len anywhere, the assembler could not mark it like SHN_ABS, and later the linker would have an additional movement.

Sht_symtab in executable file

By default, NASM places .SymTAB in the executable file.

It is used only for debugging. Without characters, we are completely blind and need to redo everything.

You can delete it with ObjCopy, and the executable file will still work. Such executable files are called split executable files.

.strtab.

Holds strings for the character table.

In this section Sh_Type \u003d\u003d SHT_STRTAB.

Specifies on sh_link \u003d\u003d 5 section.symtab.

READELF -X .STRTAB Hello_World.o

Hex dump of section ".strtab": 0x00000000 0068656c 6c6f5f77 6f726c64 2e61736d .hello_world.asm 0x00000010 0068656c 6c6f5f77 6f726c64 0068656c .hello_world.hel 0x00000020 6c6f5f77 6f726c64 5f6c656e 005f7374 lo_world_len._st 0x00000030 61727400 art.

This means that this is a limitation of the level of ELF, which global variables cannot contain NUL characters.

.rela.text.

Section Type: SH_TYPE \u003d\u003d SHT_RELA.

Common Name: Travel section.

Rela.Text contains the movement data in which the address must be changed when the last executable file is connected. This indicates the bytes of the text area, which must be changed when binding occurs indicating the right memory places.

Basically, it converts the text of the object containing the address of the filler 0x0:

A: 48 BE 00 00 00 00 00 Movabs $ 0x0,% RSI 11: 00 00 00

to the actual executable code containing the final 0x6000d8:

4000ba: 48 BE D8 00 00 00 Movabs $ 0x6000d8,% RSI 4000C1: 00 00 00

It was indicated sh_info \u003d 6 section.symtab.

rEADELF -R Hello_World.o gives:

Relocation Section ".rela.text" AT Offset 0x3b0 Contains 1 Entries: Offset Info Type Sym. Value Sym. Name + AddEnd 00000000000C 000200000001 R_X86_64_64 0000000000000000.Data + 0

The section does not exist in the executable file.

Actual bytes:

00000370 0C 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 | ................ | 00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |

Presented struct:

TypeDef Struct (ELF64_ADDR R_OFFSET; ELF64_XWORD R_INFO; ELF64_SXWORD R_ADDEND;) ELF64_RELA;

370 0: R_OFFSET \u003d 0xC: Address to address.Text, whose address will be changed

370 8: R_info \u003d 0x200000001. Contains 2 fields:

• ELF64_R_TYPE \u003d 0x1: The value depends on the accurate architecture.
• ELF64_R_SYM \u003d 0X2: The section index, which indicates the address, therefore.data, which is located in the index 2.

AMD64 ABI says that type 1 is called R_X86_64_64 and that it represents the operation S + A where:

• S: Symbol value in the object file, here 0, because we point to 00 00 00 00 00 00 00 00 from Movabs $ 0x0,% RSI
• a: Adding present in the R_ADDED field

This address is added to the section in which movement is running.

This transmitting operation is valid for 8 bytes.

380 0: R_ADDEND \u003d 0

Thus, in our example, we conclude that the new address will be: s + a \u003d .data + 0, and thus the first in the data section.

Table title programs

Displayed only in the executable file.

Contains information on how the executable file must be placed in the virtual memory of the process.

The executable file is created by a linker object file. The main tasks that the linker performs:

determine which partitions of object files will enter which segments of the executable file.

In Binutils, this comes down to analyzing the Script linker and working with a multitude of default values.

You can get a Script linker used with LD --Verbose, and install a custom with LD -T.

move on text sections. It depends on how several sections are placed in memory.

rEADELF -L Hello_World.out gives:

Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000d7 0x00000000000000d7 RE 200000 LOAD 0x00000000000000d8 0x00000000006000d8 0x00000000006000d8 0x000000000000000d 0x000000000000000d RW 200000 Section To Segment Mapping: Segment Sections ... 00 .text 01 .data

The ELF E_PHOFF header, E_phnum and E_phentsize told us that there are 2 headers of the program that start with 0x40 and a length of 0x38 bytes each, so they:

00000040 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 |[Email Protected]@ ..... | 00000060 D7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | 00000070 00 00 20 00 00 00 00 00 | .. ..... |

00000070 01 00 00 00 06 00 00 00 | ........ | 00000080 D8 00 00 00 00 00 00 00 D8 00 00 00 00 00 00 00 | .......... `..... | 00000090 D8 00 00 00 00 00 00 00 0D 00 00 00 00 00 00 00 | .. ............. | 000000A0 0D 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 | .......... ..... | typedef struct (Elf64_Word p_type; Elf64_Word p_flags; Elf64_Off p_offset; Elf64_Addr p_vaddr; Elf64_Addr p_paddr; Elf64_Xword p_filesz; Elf64_Xword p_memsz; Elf64_Xword p_align;) Elf64_Phdr;

Sample first:

• 40 0: P_TYPE \u003d 01 00 00 00 \u003d PT_LOAD: TODO. I think it means that it will be loaded into memory. Other types may not be necessary.
• 40 4: p_flags \u003d 05 00 00 00 \u003d Perform and read permissions, do not write TODO
• 40 8: p_offset \u003d 8x 00 TODO: What is it? It seems to displace from the start of the segments. But this will mean that some segments are intertwined? You can play with him a bit: gcc -wl, -ttext-segment \u003d 0x400030 Hello_World.c
• 50 0: p_vaddr \u003d 00 00 00 00 00 00 00 00: The initial address of the virtual memory to load this segment in
• 50 8: p_paddr \u003d 00 00 40 00 00 00 00 00: Starting physical address to download to memory. Only issues for systems in which the program can establish a physical address. Otherwise, as in system systems V, it can be anything. It seems that NASM simply copies P_VADDRR
• 60 0: p_filesz \u003d d7 00 00 00 00 00 00 00: TODO VS P_MEMSZ
• 60 8: p_memsz \u003d d7 00 00 00 00 00 00 00: TODO
• 70 0: P_ALIGN \u003d 00 00 00 00 00 00 00 00: 0 or 1 means that no alignment is required TODO, what does this mean? otherwise excessively with other fields

The second is similar.

Section to Segment Mapping:

section Readelf tells us that:

• 0 - segment.Text. Yeah, so it is executable and not available for recording.
• 1 - segment.data.

1. Title (ELF Header)

2. Program header (Program Header Table)

3. Sections

4. Section header (Section Header Table)

Review dwarf.

• install the stoppoint (breakpoints) is not a physical address, but on the line number in the source code file or the function name
• display and change the values \u200b\u200bof global and local variables, as well as function parameters
• display call stack (backtrace)
• execute the program step by step is not one of the assembler instruction, but on the rows of the source code

Nodes describing data:

1. Data types:
   • Basic data types (node \u200b\u200bwith DW_TAG_BASE_TYPE), such as type int in C.
   • Composite data types (pointers, etc.)
   • Arrays
   • Structures, Classes, Combines, Interfaces
2. Data objects:
   • constants
   • parameters of functions
   • variables
   • etc.

Nodes describing code:

1. Procedures (functions) - nodes with a DW_TAG_SUBPROGRAM tag. Descendation nodes may contain descriptions of variables - function parameters and local variable function variables.
2. Compiling Unit (Compilation Unit). Contains information program and is the parent of all other nodes.

Other information:

• Row number information (Section ".debug_line")
• Macro Information (Section ".debug_macInfo")
• Frame Information Information Information (Call Frame Information) (Section ".debug_frame")

Creating ELF.

1. Initialization Libelf.
2. Creating a file header (ELF HEADER)
3. Creating a program header (Program Header Table)
4. Creating sections
5. Record file.

Initialization Libelf.

• fD - descriptor just open File
• cMD - mode (ELF_C_READ for reading information, ELF_C_WRITE to write or ELF_C_RDWR to read / write), it must match the open file mode (ELF_C_WRITE in our case)
• eLF - only needed to work with archive files (.a), in our case, you need to pass 0

Creating a header

• eLF - descriptor returned by the function Elf_begin

Some fields are filled with a standard way, some need to fill us:

• e_Ident - byte array of identification, has such indices:
  • EI_MAG0, EI_MAG1, EI_MAG2, EI_MAG3 - These 4 bytes must contain simomel 0x7F, "ELF", which the ELF32_NEWEHDR function has already done for us
  • EI_DATA - indicates the type of data encoding in the file: ElfData2LSB or ElfData2MSB. You need to install ElfData2LSB as follows: E_IIDENT \u003d ElfData2LSB
  • EI_VERSion - the file header version, already installed for us
  • EI_PAD - do not touch
• e_TYPE - File type, maybe ET_NONE - without type, ET_REL - a moved file, ET_EXEC - executable file, ET_DYN - shared object file, etc. We need to set the file type in ET_EXEC
• e_MACHINE - Architecture required for this file, for example EM_386 - For Intel architecture, for ARM we need to write here EM_ARM (40) - see ELF for the Arm Architecture
• e_VERSION - File version, you need to install in EV_CURRENT
• e_ENTRY - Address of the entry point, for us it is not necessary
• e_PHOFF - offset in the program header file, E_SHOFF - offset sections, do not fill
• e_FLAGS - Special for the Flags processor, for our architecture (Cortex-M3) you need to set 0x05000000 (ABI Version 5)
• e_EHSIZE, E_PHENTSIZE, E_PHNUM, E_SHENTSIZE, E_SHNUM - Do not touch
• e_ShstrNDX - Contains the section number in which there is a string table with sections headers. Since we do not have any sections, we will set this number later.

Creating a program header

• eLF - our descriptor
• cOUNT - the number of table elements created. Since we will have only one section (with the program code), then Count will be 1.

• p_TYPE - type of segment (section), here we must specify PT_Load - downloadable segment
• p_OFFSET - displacements in the file where the section data begins to be loaded into memory. We have this section .Text, which will be immediately after the header of the file and the program header, the offset we can calculate as the sum of the lengths of these headers. The length of any type can be obtained using the ELF32_FSIZE function:
  Size_t ELF32_FSIZE (Elf_Type Type, Size_t Count, Unsigned Int Version); Type - here the ELF_T_HXX constant, we need the dimensions of ELF_T_EHDR and ELF_T_PHDR; Count - the number of items of the desired type, version - need to be installed in EV_CURRENT
• p_vaddr, p_paddr - virtual and physical address by which the contents of the section will be downloaded. Since we have no virtual addresses, we install it equal to physical, in the simplest case - 0, because our program will be loaded here.
• p_FILESZ, P_MEMSZ - section size in the file and memory. We have they are the same, but since there are no more sections with the program code, set them later.
• p_Flags - permissions for the loaded memory segment. There may be pf_r - reading, pf_w - recording, pf_x - execution or combination thereof. Set P_Flags equal to PF_R + PF_X
• p_ALIGN - Alignment of the segment, we have 4

Creating sections

• eLF - descriptor returned earlier by the ELF_BEGIN function

• sCN is a pointer to the section that we received from the ELF_NEWSCN function.

• sh_name - section name - offset in the string table of sections headers (section.shstrTab) - see "Row Tables" Next
• sH_TYPE - the type of content section, for the program code section you need to install SHT_PROGBITS, for sections with a string table - SHT_STRTAB, for the symbol table - SHT_SYMTAB
• sh_flags - Section flags that can be combined, and we only need three:
  • Shf_alloc - means that the section will be loaded into memory
  • SHF_EXECINSTR - section contains executable code
  • SHF_STRINGS - section contains a string table
  Accordingly, for the section.Text with the program you need to install the shf_alloc + shf_execinstr flags
• sh_addr - address by which the section will be loaded into memory
• sh_offset - selection offset in the file - do not touch, the library will set for us
• sh_size - section size - do not touch
• sh_link - contains the associated section number, needed to communicate the section with the row table corresponding to it (see below)
• sh_info - additional Informationdepending on the type of section, set in 0
• sh_addralign - address alignment, do not touch
• sh_entsize - if the section consists of several elements of the same length, indicates the length of such an element, do not touch

• sCN - just the resulting pointer to a new section.

• d_BUF - pointer to the data you want to write to the section
• d_Type - data type, for us everywhere will suit ELF_T_BYTE
• d_SIZE - Data Size
• d_OFF - offset in the section, set in 0
• d_ALIGN - alignment, can be installed in 1 - without alignment
• d_VERSion - version, be sure to install in EV_CURRENT

Special sections

• .Text - Section with program code
• .SymTAB - File Symbol Table
• .strtab is a string table containing characters names from the.symtab section, since the names are not stored in the latter, but their indices
• .shstrTab - Table rows containing sections names

Section.Text

Section.symtab.

• sT_NAME - symbol name (index in the string table.strTab)
• sT_VALUE - value (input address for function or 0 for file). Since Cortex-M3 has a thumb-2 command system, this address must be odd (real address + 1)
• sT_SIZE - Function Code Length (0 for File)
• sT_INFO - type of symbol and its scope. To determine the value of this field there is a macro
  #Define ELF32_ST_INFO (B, T) (((B)<<4)+((t)&0xf))
  where b is the scope, and T - the type of symbol
  The scope may be STB_LOCAL (the symbol is not visible from other object files) or STB_GLOBAL (visible). Use STB_GLOBAL to simplify.
  Symbol type - STT_FUNC for function, stt_file for file
• sT_OTHER - Set in 0
• sT_SHNDX is a section index for which the symbol is defined (Section .Text index), or SHN_ABS for the file.
  The section index of its SCN descriptor can be determined using ELF_NDXSCN:
  Size_t ELF_NDXSCN (ELF_SCN * SCN);

Section.strtab

Section.shstrTab

Tables row

Record file.

• eLF - descriptor
• cMD - command must be equal to ELF_C_WRITE to record.

Creating dwarf.

1. Creating nodes (DIE - DEBUGGING INFORMATION ENTRY)
2. Creating an attribute of the node
3. Creating data types
4. Creating procedures (functions)

Initialization libdwarf producer

DWARF_P_DEBUG DWARF_PRODUCER_INIT_C (DWARF_UNSIGNED FLAGS, DWARF_CALLBACK_FUNC_C FUNC, DWARF_HANDLER ERRHAND, DWARF_PTR ERRARG, VOID * User_Data, DWARF_ERROR * Error)

• flags - a combination of "or" several constants that define some parameters, such as the information of the information, following bytes (Little-Endian, Big-Endian), the format of the ralocations, from which we necessarily need DW_DLC_WRITE and DW_DLC_SYMBOLIC_RELOCATIONS
• fUNC - Callback function that will be called when creating ELF sections with debug information. See below in the section "Creating sections with debugging information"
• errhand is a pointer to a function that will be called when errors occur. You can pass 0.
• eRRARG - Data that will be transmitted to the Errhand function can be set 0
• user_data - data that will be transmitted to the FUNC function can be set 0
• eRROR - Return error code

Creating nodes (DIE - DEBUGGING INFORMATION ENTRY)

• create it function dwarf_new_die
• add attributes to it (each type of attributes is added to its function to be described below)

• new_Tag - TEG (type) of the node - DW_TAG_XXXX constant, which can be found in the libdwarf.h file
• parent, Child, Left_sibling, Right_Sibling - respectively, parent, descendant, left and right neighbors of the node. You do not need to specify all these parameters, it is enough to specify one, instead of putting 0. If all parameters are equal to 0, the node will be or root, or insulated
• eRROR - will contain an error code when it occurs

Creating an attribute of the node

• name - Actually the value of the attribute (node \u200b\u200bname)

• dBG - DWARF_P_DEBUG descriptor obtained when initializing the library
• aTTR - attribute whose value is set is the DW_AT_XXXX constant that can be found in the libdwarf.h file
• value - Attribute value

Creating a compilation unit (Compulation Unit)

Main File Information

Compiler information

• producer_String - line with information text

Creating COMMON INFORMATION ENTRY

• the register is not saved in the procedure.
• the register does not change its value in the procedure.
• the register is stored on the stack at CFA + N
• register persists in another register
• the register is stored in memory at some address that can be calculated rather unlikely.
• etc.

• DW_CFA_SET_LOC - indicates the current address in the program
• Dw_cfa_advance_loc - promotes a pointer to some byte
• DW_CFA_DEF_CFA - Indicates the address of the stack frame (Numerical Constant)
• DW_CFA_DEF_CFA_REGISTER - indicates the address of the stack frame (taken from the processor register)
• DW_CFA_DEF_CFA_EXPRESSION - Indicates how to calculate the address of the stack frame
• DW_CFA_SAME_VALUE - Indicates that the register does not change
• DW_CFA_REGISTER - specify that the register is saved in another register
• etc.

• aUGMENTER is a string in utf-8 encoding, the presence of which shows that there is additional platform information to CIE or FDE. We put an empty string
• code_align - alignment of the code in bytes (we have 2)
• data_ALIGN - alignment of data in the frame (we put -4, which means all the parameters occupy 4 bytes on the stack and it grows in memory down)
• rET_ADDR_REG - Register containing the address of the return from the procedure (we have 14)
• init_Bytes - an array containing instructions DW_CFA_HXXX. Unfortunately, there is no convenient way to generate this array. You can create it manually or to high in the ELF file that was generated by the compiler with what I did. For my case, it contains 3 bytes: 0x0c, 0x0d, 0, which is decrypted as DW_CFA_DEF_CFA: R13 OFS 0 (CFA is in the R13 register, the offset is 0)
• init_Bytes_len - Array Length Init_Bytes

Creating data types

• "Name" (dw_at_name)
• "Coding" (dw_at_encoding) - means which data is described by this basic type (for example, DW_ATE_BOOLAN - logical, dw_ate_float - floating point, dw_ate_signed - a whole sign, DW_ATE_UNSIGNED - whole unsolved, etc.)
• "Size" (DW_AT_BYTE_SIZE - size in bytes or dw_at_bit_size - size in bits)

• aTTR - attribute, in this case DW_AT_TYPE
• otherdie - a type descriptor type that reference

Creating procedures

• file name with source code
• row number in this file
• column number in the file
• is the instruction on the beginning of the operator or the operator block
• etc.

• name - File Name
• dir_idx - the folder index in which the file is located. The index can be obtained using the dwarf_add_directory_decl function. If complete paths are used, you can set 0 as the folder index and do not use dwarf_add_directory_decl
• time_Mod - the file modification time, you can not specify (0)
• length - the file size, also not necessarily (0)

• creating a symbol procedure in section.symtab
• creating an attribute procedure node
• creating a FDE procedure
• creating procedure parameters
• creating information about row numbers

Creating a procedure symbol

Creating an attribute procedure node

• the name of the procedure (function dwarf_add_at_name, see "Creating a node attributes")
• the line number in the file where the procedure code begins (DW_AT_DECL_LINE attribute), the dwarf_add_at_unsigned_const function (see "Creating a node attributes")
• the initial address of the procedure (attribute DW_AT_LOW_PC), the function dwarf_add_at_targ_address, see below
• the end address of the procedure (attribute dw_at_high_pc), dwarf_add_at_targ_address function, see below
• the type of result of the result procedure (attribute DW_AT_TYPE - a reference to the previously created type, see "Creating data types"). If the procedure does not return anything - this attribute does not need to create

• aTTR - Attribute (DW_AT_LOW_PC or DW_AT_HIGH_PC)
• pC_VALUE - address value
• sym_INDEX - procedure symbol index in the table.symtab. Optional, you can pass 0

Creating a FDE procedure

• creating a new FDE (see Create Common Information Entry)
• attachment created by FDE to the general list
• adding instructions to the created FDE

• fDE - just received descriptor
• dIE - DIE Procedures (see Creating an attribute procedure node)
• cIE - CIE descriptor (see Create Common Information Entry)
• virt_addr - the initial address of our procedure
• code_Len - procedure length in bytes

• op - instruction code (DW_CFA_XXXX)
• val1, Val2 - Parameters of the instruction (various for each instruction, see Standard, section 6.4.2 Call Frame Instructions)

• fDE - Descriptor created FDE
• rEG - register that is written in the frame
• offset - its displacement in the frame (not in bytes, and in the frame elements, see Creating Common Information Entry, Data_ALIGN)

Creating procedure parameters

Creating information about numbers lines

• at the beginning of the procedure, start the instructions block with the DWARF_LNE_SET_ADDRESS function
• for each line of code (or machine instruction), create information about the source code (DWARF_ADD_LINE_ENTRY)
• at the end of the procedure, we complete the instructions block with the DWARF_LNE_END_SEQUENCE function

• oFFS - address of the procedure (address of the first machine instruction)
• sym_idx - symbol index (optional, you can specify 0)

• file_INDEX - the index of the source code file obtained earlier by the dwarf_add_file_decl function (see "Creating Procedures")
• code_Offset - address of the current machine instruction
• lineno - Row number in the source code file
• column_number - speaker number in the source code file
• is_source_stmt_begin - 1 If the current manual is the first in the code in the Lineno line (I always use 1)
• iS_BASIC_BLOCK_BEGIN - 1 If the current instruction is the first in the operator block (I always use 0)
• is_epilogue_begin - 1 If the current instruction is the first in the epilogue of the procedure (not necessarily, I always have 0)
• iS_Prologue_END - 1 If the current instruction is the latest in the procedure prologue (required!)
• iSA - INSTRUCTION SET ARCHITECTURE (command set architecture). Be sure to specify DW_ISA_ARM_THUMB for ARM Cortex M3!
• discriminator. One position (file, string, column) of the source code can be represented by different machine instructions. In this case, for the sets of such instructions, you need to install different discriminators. If there are no such cases, there must be 0

• aDDRESS - address of the current machine instruction

Creating variables and constants

• Dw_op_addr - indicates the address of the variable
• Dw_op_fbreg - indicates the displacement of the variable from the base register (usually the stack pointer)
• DW_OP_REG0 ... DW_OP_REG31 - indicates that the variable is stored in the corresponding register

• oPCode - Operation Code, DW_OP_KHXX CONSTANT
• val1, Val2 - instruction parameters (see Standard)

• eXPR - a targeted expression descriptor in which the instruction is added
• address - address of the variable
• sym_INDEX - symbol index in table.symtab. Optional, you can pass 0

• ownerDie - node to which an expression is added
• aTTR - attribute (in our case dw_at_location)
• lOC_EXPR - Descriptor of the previously created address expression

• variable / constant name (dwarf_add_at_name function, see "Creating an attribute of a node")
• the line number in the file where the variable is declared (attribute dw_at_decl_line), the function dwarf_add_at_unsigned_const (see "Creating a node attributes")
• file name index (attribute DW_AT_DECL_FILE), DWARF_ADD_AT_UNSIGNED_CONST (see "Creating a node attributes")
• data type variable / constant (attribute DW_AT_TYPE - Reference to the previously created type, see "Creating data types")
• address expression (see above) - you need to variable or parameter procedure
• or value - for a constant (attribute dw_at_const_value, see "Creating an attribute node")

Creating sections with debugging information

• first you need to call the DWARF_TRANSFORM_TO_DISK_FORM function, which will call the call the written function to create the desired ELF sections once for each section
• for each section, the DWARF_GET_SECTION_BYTES function will return to us the data you want to write to the appropriate section

• name - the name of the ELF section you want to create
• size - section size
• type - Section Type
• flags - Section Flags
• link - Section Communication Field
• info - Section Information field
• sECT_NAME_INDEX - You need to return the section index with remocions (not required)
• user_data - is transmitted to us the same as we set it in the library initialization function
• error - You can transfer the error code here.

• create a new section (ELF_NEWSCN function, see Creating Sections)
• create a section title (ELF32_GETSHDR function, Ibid)
• completely fill it (see ibid.) It is simply, since the section header fields correspond to the parameters of our function. The missing fields sh_addr, sh_offset, sh_entsize install in 0, and sh_addralign in 1
• return the index of the created section (ELF_NDXSCN function, see "Section.symtab") or -1 in case of error (installing error code in Error)
• we also have to skip the ".rel" section (in our case), returning 0 when returning from the function

• create data to write to the DWARF_GET_SECTION_BYTES function section:
  DWARF_PTR DWARF_GET_SECTION_BYETES (DWARF_P_DEBUG DBG, DWARF_SIGNED DWARF_SECTION, DWARF_SIGNED * ELF_SECTION_INDEX, DWARF_UNSIGNED * LENGTH, DWARF_ERROR * ERROR)
  • dWARF_SECTION - Section number. Must be in the range of 0..n, where N is the number returned to us by the DWARF_TRANSFORM_TO_DISK_FORM function
  • eLF_SECTION_INDEX - Returns the section index to which you want to record data
  • length - the length of this data
  • eRROR - not used
  The function returns a pointer to the obtained data or 0 (in the event that
  When sections for creating no longer left)
• create a data descriptor of the current section (ELF_NEWDATA function, see Creating sections) and fill it (see ibid.) By setting:
  • d_BUF - pointer to the data obtained by us from the previous function
  • d_SIZE - the size of this data (ibid)

End of work with the library

Conclusion

If you have on a computer installed antivirus program can scan all files on your computer, as well as each file separately. You can scan any file by right-clicking on the file and selecting the appropriate option to check the file for the presence of viruses.

For example, in this picture allocated file My-File.elfthen you need to right-click on this file, and select the option in the File menu "Scan with AVG". When this parameter is selected, AVG Antivirus will open, which will check this file for viruses.

Sometimes an error may occur as a result invalid software installationWhat can be related to the problem that occurred during the installation process. It may interfere with your operating system. tie your ELF file with proper application softwarehaving an impact on the so-called "Association of File Extensions".

Sometimes simple reinstalling Dolphin (Emulator) Can solve your problem correctly linking ELF with Dolphin (Emulator). In other cases, problems with file associations may result from bad Software Programming Developer, and you may be required to contact the developer for more accommodation.

Tip: Try updating the Dolphin (Emulator) to the latest version to make sure that the latest fixes and updates are installed.

It may seem too obvious, but often directly the ELF file itself may be the cause of the problem.. If you received a file through an email attachment or downloaded it from a website, and the download process was interrupted (for example, a power outage or for another reason), the file may be damaged. If possible, try to get a new copy of the ELF file and try to open it again.

Caution: A damaged file may entail the occurrence of accompanying damage to the previous or already existing malware on your PC, so it is very important that the updated antivirus constantly worked on your computer.

If your ELF file associated with hardware on your computerTo open the file you may need update device driversassociated with this equipment.

This problem Usually related to the types of multimedia filesthat depend on the successful opening of hardware inside the computer, for example, sound card or video card. For example, if you are trying to open an audio file, but you can't open it, you may need update sound card drivers.

Tip: If you try to open the ELF file, you get error message associated with S.Sys File, the problem is likely to be associated with damaged or outdated device driversthat need to be updated. This process can be facilitated by using software to update drivers, such as DriverDoc.

If the steps did not solve the problemand you still have problems with the opening of ELF files, it may be related to lack of available system resources. For some versions of ELF files, considerable amount of resources may be required (for example, memory / RAM, computing power) for proper opening on your computer. Such a problem occurs quite often if you use enough old computer hardware and at the same time a much newer operating system.

This problem may occur when a computer is difficult to cope with the task, since the operating system (and other services operating in the background) can consume too much resources to open the ELF file.. Try to close all applications on your PC before opening Nintendo Wii Game File. After freeing all the available resources on your computer, you will provide the best conditions for attempting to open the ELF file.

If you performed all the steps described above, and your ELF file still does not open, it may be necessary to perform equipment update. In most cases, even when using old versions of equipment, computing power can still be more than sufficient for most user applications (if you do not perform a lot of resource-intensive processor operation, such as 3D rendering, financial / scientific modeling or intensive multimedia work) . In this way, it is likely that your computer lacks the required amount of memory.(more often called "RAM", or RAM) to perform the task of opening a file.