1
00:00:00,980 --> 00:00:05,750
After the identity array, we have a series of multi-byte integer fields.

2
00:00:05,870 --> 00:00:11,810
The first of these is called the E type Specifies the type of the binary.

3
00:00:11,840 --> 00:00:19,340
The most common values you will encounter here are the e t indicating a relocatable object file and

4
00:00:19,370 --> 00:00:23,870
e t exec, which is an executable binary.

5
00:00:23,870 --> 00:00:26,590
So and the dynamic so e.

6
00:00:26,600 --> 00:00:30,980
T t y n e dynamic library also called the shared object file.

7
00:00:30,990 --> 00:00:40,790
So in this output, let's actually go here again we can see that it's a dynamic library here.

8
00:00:40,790 --> 00:00:46,550
So position independent executable file, it's actually executable file but in a different way here.

9
00:00:46,550 --> 00:00:50,330
And next we have the machine field.

10
00:00:50,330 --> 00:00:52,760
You can also see that field in here.

11
00:00:52,760 --> 00:00:54,170
This is architecture here.

12
00:00:54,380 --> 00:01:00,320
So which denotes the architecture that the binary is intended to run on.

13
00:01:00,320 --> 00:01:06,000
We and here, as you can see here, Advanced Micro Devices, x86 and 64.

14
00:01:06,660 --> 00:01:10,620
And for this course, this will usually be set to.

15
00:01:11,980 --> 00:01:13,330
A m.

16
00:01:13,690 --> 00:01:14,620
86.

17
00:01:15,220 --> 00:01:16,160
64.

18
00:01:16,180 --> 00:01:26,140
As you can see in this red output, since you will mostly be working on 64 bit x86 binaries.

19
00:01:26,200 --> 00:01:33,370
That's why we are getting this machine output here and other values you are likely to encounter include

20
00:01:33,370 --> 00:01:44,290
the m 386, which is 32 bit on 6086 binaries and a m.

21
00:01:46,150 --> 00:01:50,390
Arm for arm binaries.

22
00:01:51,440 --> 00:01:54,170
And the version here we have here.

23
00:01:55,850 --> 00:02:00,050
As you can see here, this tells the object file version here.

24
00:02:00,780 --> 00:02:03,120
Let's actually do that now here.

25
00:02:03,120 --> 00:02:08,370
So as you can see, it tells the object file version which.

26
00:02:09,820 --> 00:02:18,640
Um, serves the same role as the e I version by in the e ident array.

27
00:02:18,850 --> 00:02:25,810
Specifically, it indicates the version of the elf specification that was used when creating the binary.

28
00:02:25,840 --> 00:02:32,650
As this field is 32 bits wide, you might think there are numerous possible values, but in reality

29
00:02:32,650 --> 00:02:39,960
the only possible value is one to indicate version of the version one of the specification.

30
00:02:39,970 --> 00:02:48,730
And with that way you can see that in our elf output output file we have the 0X1.

31
00:02:48,730 --> 00:02:50,770
So we have the one byte here.

32
00:02:52,830 --> 00:02:55,860
And we also have the entry field.

33
00:02:56,430 --> 00:02:58,710
Let's go back to that.

34
00:02:59,160 --> 00:03:02,910
And here so we see that entry.

35
00:03:03,660 --> 00:03:04,120
It's actually.

36
00:03:05,970 --> 00:03:06,690
Go to that.

37
00:03:15,130 --> 00:03:17,970
And here the entry.

38
00:03:17,980 --> 00:03:20,110
This is an entry point virtual address.

39
00:03:20,110 --> 00:03:27,910
This entry field denotes the entry point of the binary, and this is the virtual address at which execution

40
00:03:27,910 --> 00:03:29,080
should start.

41
00:03:29,470 --> 00:03:31,870
You will see that in the next lecture.

42
00:03:31,870 --> 00:03:38,000
So for the example binary, this execution starts at entry point address.

43
00:03:38,050 --> 00:03:41,440
As you can see here, 1050.

44
00:03:41,890 --> 00:03:51,250
And this is where the interpreter typically ld dash linuxone will transfer control after it finishes

45
00:03:51,250 --> 00:03:53,710
loading the binary into virtual memory.

46
00:03:53,800 --> 00:04:00,720
The entry point is also a useful starting point for recursive disassembly, which you will learn in

47
00:04:00,730 --> 00:04:01,690
next lectures.

48
00:04:01,690 --> 00:04:10,300
And here we have the key of here program header, table file offset and we also have the section header

49
00:04:10,300 --> 00:04:12,340
table file offset.

50
00:04:12,430 --> 00:04:18,290
And as you can see here, Elf binaries contain tables of program headers and section headers, among

51
00:04:18,290 --> 00:04:19,190
other things.

52
00:04:19,190 --> 00:04:26,000
And I will revisit the meaning of this header types after I finish discussing the executable header

53
00:04:26,000 --> 00:04:26,570
in this lecture.

54
00:04:26,570 --> 00:04:35,150
But one thing I can already reveal is that the program header and the section header tables need not

55
00:04:35,150 --> 00:04:38,240
to be located at any particular offset in the binary file.

56
00:04:38,240 --> 00:04:45,590
So the only data structure that can be assumed to be at a fixed location in an Elf binary is the executable

57
00:04:45,620 --> 00:04:48,680
header, which is always at the beginning.

58
00:04:48,680 --> 00:04:54,350
So how can you know where to find the program headers and the section headers For this?

59
00:04:54,350 --> 00:05:03,380
The executable header contains two dedicated fields called a program header offset and a here we can

60
00:05:03,380 --> 00:05:11,570
see the section header table offset that indicates the file offsets to to the beginning of the program

61
00:05:11,570 --> 00:05:13,940
header table and the section header table.

62
00:05:14,060 --> 00:05:20,600
And here, as you can see, we have start of the program headers and start of the section headers.

63
00:05:20,600 --> 00:05:26,240
And we in start of program headers we have 64 bytes into file.

64
00:05:26,240 --> 00:05:37,040
And in the start of the section headers we have this 13,968 bytes into file and respectively these two

65
00:05:37,040 --> 00:05:43,850
lines here are the binary, the and offsets here.

66
00:05:43,850 --> 00:05:50,210
And the offsets can also be set to zero to indicate that the file does not contain a program header

67
00:05:50,210 --> 00:05:51,860
or section header table.

68
00:05:51,860 --> 00:05:58,250
And it's important to keep in mind here that these fields are file offsets, meaning the number of bytes

69
00:05:58,250 --> 00:06:02,480
you should read into the file to get to the headers, right?

70
00:06:02,480 --> 00:06:13,520
So in other words, in contrast to E entry field discussed earlier, the program header of and the section

71
00:06:13,520 --> 00:06:17,270
header offset are not virtual addresses.

72
00:06:17,420 --> 00:06:20,690
And here we also have the flags.

73
00:06:21,370 --> 00:06:24,580
As you can see here, processor specific flags we have here.

74
00:06:24,820 --> 00:06:28,120
Let me check if you can see the screen clearly.

75
00:06:28,120 --> 00:06:28,720
Yes.

76
00:06:28,960 --> 00:06:30,970
Let's increase the font size a little bit.

77
00:06:31,900 --> 00:06:37,150
And here we have the E flex, which is processor specific flex.

78
00:06:37,150 --> 00:06:45,670
So the E flex E flex field provides room for flex specific to the architecture for which the binary

79
00:06:45,670 --> 00:06:46,360
is compiled.

80
00:06:46,360 --> 00:06:55,330
So for instance, arm binaries intended to run on embedded platforms can set specific flags in the E

81
00:06:55,380 --> 00:07:01,750
flags field to indicate additional details about the interface they expect from the embedded operating

82
00:07:01,750 --> 00:07:08,530
system like file format, convention conventions, stack organizations and so on here.

83
00:07:08,530 --> 00:07:14,980
And Flex is typically set to zero and is not of interest here.

84
00:07:14,980 --> 00:07:22,420
And as you can see here in this example, we also our flags is also set to zero.

85
00:07:22,420 --> 00:07:25,930
And we also have the size of this header.

86
00:07:26,410 --> 00:07:31,670
We can turn this into e size, the Elf header size in bytes.

87
00:07:31,670 --> 00:07:37,430
So this field specifies the size of the executable header but in bytes.

88
00:07:37,430 --> 00:07:48,770
So for 64 bit x86 binaries, the executable header size is always 64 bytes as you can see here.

89
00:07:49,620 --> 00:07:52,950
And while it's.

90
00:07:54,340 --> 00:07:55,320
54.

91
00:07:55,540 --> 00:08:05,050
No, it's, uh, 52 bytes for, uh, 32 bit x86 binaries here.

92
00:08:05,110 --> 00:08:07,150
62 for.

93
00:08:07,800 --> 00:08:10,470
32 bits here.

94
00:08:12,560 --> 00:08:15,980
And also we have this.

95
00:08:16,340 --> 00:08:17,040
I'm sorry.

96
00:08:19,510 --> 00:08:20,020
Here.

97
00:08:20,020 --> 00:08:23,290
And we also have the pen size.

98
00:08:23,500 --> 00:08:30,760
And for h num here, this is a program header, table entry size and program header table entry count.

99
00:08:30,760 --> 00:08:39,640
As you now know, the E program header table entry size and a program header.

100
00:08:41,740 --> 00:08:44,170
Table entry of.

101
00:08:44,530 --> 00:08:45,070
Yes.

102
00:08:45,190 --> 00:08:45,790
Program Header.

103
00:08:46,060 --> 00:08:46,750
Table.

104
00:08:47,980 --> 00:08:51,970
No, it's actually this program header table.

105
00:08:53,420 --> 00:09:00,620
File offset and this section header table file offset points to the file offsets where the program header

106
00:09:00,620 --> 00:09:01,910
and section header table begins.

107
00:09:01,910 --> 00:09:02,420
Right.

108
00:09:02,420 --> 00:09:10,040
So but for the linker or loader or any other program handling the elf binary to actually traverse these

109
00:09:10,040 --> 00:09:12,140
tables, additional information is needed.

110
00:09:12,320 --> 00:09:18,080
Specifically, they need to know the size of the individual program or section headers in the tables,

111
00:09:18,080 --> 00:09:21,200
as well as the number of headers in each file.

112
00:09:21,200 --> 00:09:27,320
So this information is provided by the font size and for num.

113
00:09:28,930 --> 00:09:30,820
Fields for the program header table.

114
00:09:30,820 --> 00:09:35,000
And by the we have c h.

115
00:09:36,460 --> 00:09:43,060
E and T size, which is section header table entry size and section header table entry count.

116
00:09:44,050 --> 00:09:45,960
And we also have this P.

117
00:09:47,120 --> 00:09:50,390
Maybe has c h numb here.

118
00:09:52,280 --> 00:09:55,660
And c h size fields.

119
00:09:57,410 --> 00:10:03,170
We have these fields because the section header table to specify that.

120
00:10:03,170 --> 00:10:10,640
And in this example binary here we have this number of programs and here we have section header, table

121
00:10:10,640 --> 00:10:11,960
entry size and.

122
00:10:13,630 --> 00:10:16,870
The name, which is program header table entry count.

123
00:10:17,170 --> 00:10:24,760
You can find this field in the number of program headers and size of program headers here.

124
00:10:26,440 --> 00:10:36,580
And we also have the E section header, string table index, a section header string table index here.

125
00:10:37,360 --> 00:10:44,620
And this field contains the index in this in the section header file of the header associated with a

126
00:10:44,620 --> 00:10:49,990
specific and special string table section called the.

127
00:10:50,770 --> 00:10:51,780
C h.

128
00:10:51,820 --> 00:10:52,010
S.

129
00:10:52,120 --> 00:10:52,410
T.

130
00:10:52,450 --> 00:10:53,050
R.

131
00:10:55,600 --> 00:11:02,860
So this is a dedicated section that contains a table of null terminated Ascii strings which store the

132
00:11:02,860 --> 00:11:06,120
names of all the sections in the binary.

133
00:11:06,130 --> 00:11:13,630
It is used by elf processing tools such as Red Elf, as you can see here.

134
00:11:14,710 --> 00:11:17,650
Um, to correctly chose the names of sections.

135
00:11:17,650 --> 00:11:22,930
And I will describe this here section header String table index 30.

136
00:11:24,100 --> 00:11:28,270
And you will learn that this section.

137
00:11:29,240 --> 00:11:31,040
Table index.

138
00:11:31,720 --> 00:11:36,690
In this lecture, let's try this with radulf x.

139
00:11:36,830 --> 00:11:42,590
R c h s t r tab and a dot out here.

140
00:11:42,620 --> 00:11:43,400
This is output file.

141
00:11:43,400 --> 00:11:50,870
And as you can see here, we have this output here and you can see the section names like tab start

142
00:11:50,870 --> 00:11:51,500
tab.

143
00:11:51,530 --> 00:12:01,850
See HSR, str tab and so on contained in the string table at the right side of our listing.

144
00:12:01,880 --> 00:12:07,880
And now that you are familiar with the format and contents of the Elf executable header, let's move

145
00:12:07,880 --> 00:12:11,750
on to the section headers in next section.