camp2023-57032-eng-Demystify_Mach-O_opus.srt

1
00:00:00,000 --> 00:00:10,000
 [MUSIC]

2
00:00:10,000 --> 00:00:20,000
 [MUSIC]

3
00:00:20,000 --> 00:00:32,760
 >> Good morning.

4
00:00:32,760 --> 00:00:38,240
 Welcome back on the Millivay stage for the second talk on day three.

5
00:00:39,240 --> 00:00:42,960
 We welcome here our speaker,

6
00:00:42,960 --> 00:00:47,600
 Gary Ginn and he will talk about demystifying Mach-O.

7
00:00:47,600 --> 00:00:52,520
 Please give him a warm welcome and enjoy the talk.

8
00:00:52,520 --> 00:00:56,440
 >> Howdy. Everyone can hear me?

9
00:00:56,440 --> 00:00:59,240
 Cool. Let's start with who I am.

10
00:00:59,240 --> 00:01:00,800
 I am Gary Ginn. I work on

11
00:01:00,800 --> 00:01:04,640
 an iOS cybersecurity framework over in states.

12
00:01:04,640 --> 00:01:07,680
 This isn't too important though.

13
00:01:07,680 --> 00:01:09,680
 Let's talk about what we're going to talk about.

14
00:01:09,680 --> 00:01:11,800
 So first, we're going to look at what is Mach-O,

15
00:01:11,800 --> 00:01:14,120
 and why you should maybe look at it if you want to.

16
00:01:14,120 --> 00:01:16,120
 Then we're going to go into the deep dive into

17
00:01:16,120 --> 00:01:18,680
 the file format and the specification for it,

18
00:01:18,680 --> 00:01:21,240
 and then in with a little code example about how you

19
00:01:21,240 --> 00:01:24,560
 could parse a Mach-O file to get some information from it.

20
00:01:24,560 --> 00:01:29,560
 So first, Mach-O is the executable file format for Darwin systems,

21
00:01:29,560 --> 00:01:34,160
 think iOS, Mac OS, TV OS, all of those systems.

22
00:01:34,160 --> 00:01:37,840
 It's very similar to ELF if you've ever used that for Linux,

23
00:01:37,840 --> 00:01:39,560
 but it's a bit different.

24
00:01:39,560 --> 00:01:42,040
 It's an architecture independent file format,

25
00:01:42,040 --> 00:01:45,320
 and essentially any iOS app or

26
00:01:45,320 --> 00:01:50,120
 Mac OS app that you create or want to reverse engineer or look at,

27
00:01:50,120 --> 00:01:52,360
 will end up as this file format,

28
00:01:52,360 --> 00:01:57,440
 generally speaking on the device or on your machine.

29
00:01:57,440 --> 00:02:00,880
 So there's a few reasons why you might want to look at these files.

30
00:02:00,880 --> 00:02:03,000
 First is if you want to read executables at runtime,

31
00:02:03,000 --> 00:02:05,280
 such as doing metaprogramming on your own code,

32
00:02:05,280 --> 00:02:08,120
 or if you want to do integrity checks in your own code,

33
00:02:08,120 --> 00:02:10,880
 or maybe you want to do something like Frida and

34
00:02:10,880 --> 00:02:12,920
 install trampolines on other people's code,

35
00:02:12,920 --> 00:02:16,400
 and that requires being able to parse through these files.

36
00:02:16,400 --> 00:02:21,080
 Custom build tooling, so if you want to inject data into

37
00:02:21,080 --> 00:02:26,440
 your executables in specific parts of the segments,

38
00:02:26,440 --> 00:02:27,840
 so that you can have the loader

39
00:02:27,840 --> 00:02:30,120
 automatically map data really quickly for you,

40
00:02:30,120 --> 00:02:31,800
 or you can have special hashes for

41
00:02:31,800 --> 00:02:34,120
 integrity checks inside your executable files.

42
00:02:34,120 --> 00:02:36,200
 Any disassembly or reverse engineering,

43
00:02:36,200 --> 00:02:37,680
 you're going to have to look at these things.

44
00:02:37,680 --> 00:02:40,040
 Like for example, you want to see what Apple code looks like.

45
00:02:40,040 --> 00:02:42,360
 A really good way to do that is to load one of

46
00:02:42,360 --> 00:02:44,640
 these files by linking the dial-up into memory,

47
00:02:44,640 --> 00:02:48,280
 and then just dumping this executable file and disassembling it yourself,

48
00:02:48,280 --> 00:02:51,000
 so you can see what's under the hood for

49
00:02:51,000 --> 00:02:54,840
 these types of system libraries that Apple usually hides pretty well.

50
00:02:54,840 --> 00:02:57,600
 So yeah, those are various reasons why you

51
00:02:57,600 --> 00:03:00,000
 might want to look at these files and how you would get to them.

52
00:03:00,000 --> 00:03:02,600
 So it's a binary format,

53
00:03:02,600 --> 00:03:05,240
 so as we go through we're going to fill in just this block of bytes to

54
00:03:05,240 --> 00:03:06,920
 show what the structure of the file looks like,

55
00:03:06,920 --> 00:03:09,320
 and how you might get to various parts of it.

56
00:03:09,320 --> 00:03:12,800
 So first, we have to talk about what are called fat binaries.

57
00:03:12,800 --> 00:03:16,760
 So fat binaries are essentially a way to contain

58
00:03:16,760 --> 00:03:20,680
 multiple executables of different architectures in the same file.

59
00:03:20,680 --> 00:03:23,640
 So essentially you have like a program,

60
00:03:23,640 --> 00:03:27,280
 and you want it to have x86 and arm64 instructions on it,

61
00:03:27,280 --> 00:03:31,720
 so you can run it or maybe 32-bit and 64-bit applications on the same space.

62
00:03:31,720 --> 00:03:34,400
 You just put them right next to each other.

63
00:03:34,400 --> 00:03:39,600
 Once it's loaded, it only actually loads the architecture for the current machine,

64
00:03:39,600 --> 00:03:42,280
 so the loader will know not to pick up the entire file,

65
00:03:42,280 --> 00:03:45,000
 but only the one for the current machine you're on.

66
00:03:45,000 --> 00:03:49,680
 You can have a fat binary that is only one architecture,

67
00:03:49,680 --> 00:03:54,200
 but the existence of the fat header is very optional.

68
00:03:54,200 --> 00:03:58,360
 It's not required, but it is possible for it to be there,

69
00:03:58,360 --> 00:03:59,960
 even if there's only one architecture.

70
00:03:59,960 --> 00:04:03,520
 It is important to note that these are kind of going away.

71
00:04:03,520 --> 00:04:05,320
 Fat binaries were used for a very long time.

72
00:04:05,320 --> 00:04:10,360
 You still use them on applications you find on the internet for Mac,

73
00:04:10,360 --> 00:04:14,280
 but most iOS applications do not use fat binaries anymore

74
00:04:14,280 --> 00:04:19,640
 because there was a conflict in the iOS 16 arm64 simulator

75
00:04:19,640 --> 00:04:21,880
 that made it so that they couldn't,

76
00:04:21,880 --> 00:04:23,280
 essentially there was a naming conflict.

77
00:04:23,280 --> 00:04:25,840
 So they had to reintroduce Xe frameworks,

78
00:04:25,840 --> 00:04:27,680
 which are essentially a better version of this.

79
00:04:27,680 --> 00:04:29,440
 But yeah, this is a way that you can have one file

80
00:04:29,440 --> 00:04:33,240
 represent multiple architectures and not have to worry about

81
00:04:33,240 --> 00:04:37,360
 giving people the x86 or the arm64 version.

82
00:04:37,360 --> 00:04:42,240
 So a fat binary starts with a fat header.

83
00:04:42,240 --> 00:04:43,640
 You can define these definitions.

84
00:04:43,640 --> 00:04:45,640
 I'll list the headers as we go along.

85
00:04:45,640 --> 00:04:50,120
 They're all in the system headers for iOS and macOS and all that.

86
00:04:50,120 --> 00:04:52,480
 If the file is a fat binary, it'll start with a fat header,

87
00:04:52,480 --> 00:04:56,000
 and you check that by looking at the magic number there.

88
00:04:56,000 --> 00:04:58,280
 It gives you both fat magic and fat SIGAM,

89
00:04:58,280 --> 00:05:00,800
 so you can determine the Indian-ness of the data

90
00:05:00,800 --> 00:05:02,120
 that you're about to look at.

91
00:05:02,120 --> 00:05:03,680
 That's very important for the fat header

92
00:05:03,680 --> 00:05:07,000
 because it may be produced on a machine completely different.

93
00:05:07,000 --> 00:05:09,200
 Like for example, you could be reading this on iOS,

94
00:05:09,200 --> 00:05:14,680
 but it was produced on an x86, 64 Intel machine like a Mac.

95
00:05:14,680 --> 00:05:17,040
 And so you use that to determine India,

96
00:05:17,040 --> 00:05:19,360
 so you can actually read the header correctly.

97
00:05:19,360 --> 00:05:23,280
 It then tells you the type of the header,

98
00:05:23,280 --> 00:05:25,920
 tells you how many architectures there are.

99
00:05:25,920 --> 00:05:28,960
 Each architecture tells you the CPU type and subtype

100
00:05:28,960 --> 00:05:32,520
 that it belongs to, as well as the offset into the file

101
00:05:32,520 --> 00:05:34,440
 that architecture belongs.

102
00:05:34,440 --> 00:05:37,440
 And then it also tells you the size and the alignment.

103
00:05:37,440 --> 00:05:39,720
 The size will always be an integer multiple

104
00:05:39,720 --> 00:05:42,880
 of the underlying page size of that architecture, right?

105
00:05:42,880 --> 00:05:47,120
 So I think for arm64, that's 512 bytes, or yeah, I think so.

106
00:05:48,920 --> 00:05:53,760
 Yeah, and then of course, it's a 64-bit variant.

107
00:05:53,760 --> 00:05:57,080
 There's also APIs you can use in machine.h

108
00:05:57,080 --> 00:06:00,800
 to determine which CPU type belongs on either your machine

109
00:06:00,800 --> 00:06:04,320
 or if you want to try and grade-- it's the same thing

110
00:06:04,320 --> 00:06:06,040
 that all operating system uses to choose

111
00:06:06,040 --> 00:06:09,000
 which architecture to load, but it'll grade slices

112
00:06:09,000 --> 00:06:10,480
 and then determine which one to load.

113
00:06:10,480 --> 00:06:12,680
 You can dab those available in machine.h.

114
00:06:12,680 --> 00:06:17,520
 So if you're opening a framework up on disk

115
00:06:17,520 --> 00:06:19,160
 and you want to check which one to use,

116
00:06:19,160 --> 00:06:22,200
 you can use those to make sure you're loading the correct one,

117
00:06:22,200 --> 00:06:25,480
 or at least looking at the correct one.

118
00:06:25,480 --> 00:06:27,080
 You can use lipo and oTool.

119
00:06:27,080 --> 00:06:28,760
 These are two little command line utilities

120
00:06:28,760 --> 00:06:30,680
 that come in the box.

121
00:06:30,680 --> 00:06:34,720
 And you can use them to kind of see fat headers.

122
00:06:34,720 --> 00:06:39,200
 And also lipo lets you inject or remove various slices

123
00:06:39,200 --> 00:06:42,680
 into a universal or fat binary.

124
00:06:42,680 --> 00:06:45,040
 You can see here, we can see the header and all the type

125
00:06:45,040 --> 00:06:46,040
 of stuff within it.

126
00:06:47,040 --> 00:06:50,720
 So yeah, so this is the structure at this point.

127
00:06:50,720 --> 00:06:53,640
 We have a fat header, two fat architectures.

128
00:06:53,640 --> 00:06:56,320
 You could say this is 32-bit, 64-bit.

129
00:06:56,320 --> 00:06:58,880
 And then we have two Mach-O objects,

130
00:06:58,880 --> 00:07:01,680
 which define executables at the same time.

131
00:07:01,680 --> 00:07:03,280
 Theoretically, these are two programs,

132
00:07:03,280 --> 00:07:07,440
 just different architectures-- same program, two architectures.

133
00:07:07,440 --> 00:07:11,240
 So a Mach-O object is then kind of the way

134
00:07:11,240 --> 00:07:15,040
 that if you are familiar with how segmentation originally

135
00:07:15,040 --> 00:07:18,320
 worked in memory for operating systems,

136
00:07:18,320 --> 00:07:21,120
 this influences how this works here.

137
00:07:21,120 --> 00:07:23,000
 The object is split into segments,

138
00:07:23,000 --> 00:07:24,880
 which are effectively memory ranges that

139
00:07:24,880 --> 00:07:28,520
 will exist in virtual memory when your program is running.

140
00:07:28,520 --> 00:07:30,960
 Each of those have their own memory protections and a space

141
00:07:30,960 --> 00:07:34,160
 that the loader will then map into your process's

142
00:07:34,160 --> 00:07:36,360
 virtual memory space.

143
00:07:36,360 --> 00:07:38,120
 They all begin with the header, and they're

144
00:07:38,120 --> 00:07:39,680
 followed by a list of load commands.

145
00:07:39,680 --> 00:07:42,040
 Load commands define everything else about the file.

146
00:07:42,040 --> 00:07:43,600
 So once you read the load commands,

147
00:07:43,600 --> 00:07:44,840
 you know where everything is.

148
00:07:44,840 --> 00:07:50,560
 Each segment can have sections inside of it

149
00:07:50,560 --> 00:07:51,840
 so that it can have a little more

150
00:07:51,840 --> 00:07:53,880
 information on where things are.

151
00:07:53,880 --> 00:07:57,520
 And we'll go through the definition of a lot of these

152
00:07:57,520 --> 00:07:58,200
 going through.

153
00:07:58,200 --> 00:08:00,120
 We're not going to look at every segment in every section,

154
00:08:00,120 --> 00:08:03,280
 because technically, you can make your own segments

155
00:08:03,280 --> 00:08:04,280
 and your own sections.

156
00:08:04,280 --> 00:08:07,360
 There's also just a lot of them.

157
00:08:07,360 --> 00:08:10,960
 You can use O-Tool to look through these on various files

158
00:08:10,960 --> 00:08:13,120
 that you already have.

159
00:08:13,120 --> 00:08:14,160
 And yeah.

160
00:08:14,160 --> 00:08:17,480
 So if we look at some common segments--

161
00:08:17,480 --> 00:08:20,000
 so these probably should be familiar.

162
00:08:20,000 --> 00:08:23,600
 Page 0 is a null pointer trap.

163
00:08:23,600 --> 00:08:28,560
 On Mac, I know different OS is handled a little differently.

164
00:08:28,560 --> 00:08:31,440
 But on Darwin, they actually don't map page 0.

165
00:08:31,440 --> 00:08:34,680
 They just claim it to have no protections at all,

166
00:08:34,680 --> 00:08:37,000
 which that gives you your nice behavior,

167
00:08:37,000 --> 00:08:40,160
 where if you try to do reference a null pointer,

168
00:08:40,160 --> 00:08:44,000
 it crashes instead of just doing whatever.

169
00:08:44,000 --> 00:08:46,080
 And so there might be a change to this.

170
00:08:46,080 --> 00:08:47,720
 I remember reading somewhere that they were looking at

171
00:08:47,720 --> 00:08:49,200
 actually mapping it.

172
00:08:49,200 --> 00:08:51,600
 Not like allocating memory for it, just mapping it,

173
00:08:51,600 --> 00:08:53,960
 because apparently there's a null pointer exploit,

174
00:08:53,960 --> 00:08:57,000
 because of the fact that it's not actually mapped.

175
00:08:57,000 --> 00:08:59,920
 And for 64-bit applications, this

176
00:08:59,920 --> 00:09:02,760
 doesn't just map the first page of the process space.

177
00:09:02,760 --> 00:09:05,960
 It also maps all of 32-bit application space.

178
00:09:05,960 --> 00:09:09,400
 So on 64-bit apps on Darwin, you cannot dereference

179
00:09:09,400 --> 00:09:10,920
 a 32-bit pointer.

180
00:09:10,920 --> 00:09:14,120
 And it also means you can't load a 32-bit library

181
00:09:14,120 --> 00:09:15,200
 into 64-bit space.

182
00:09:15,200 --> 00:09:18,800
 So that's a neat little thing they did there.

183
00:09:18,800 --> 00:09:21,480
 The text segment is usually the first segment.

184
00:09:21,480 --> 00:09:24,040
 It is the first segment, and it always contains the mock

185
00:09:24,040 --> 00:09:24,640
 header.

186
00:09:24,640 --> 00:09:27,400
 The reason it does that is so that when you're code signing

187
00:09:27,400 --> 00:09:31,640
 your stuff, the code signing only looks at the text segment.

188
00:09:31,640 --> 00:09:34,200
 So whenever you have signed executables from the iOS app

189
00:09:34,200 --> 00:09:36,680
 store or whatever, it's just looking at that first text

190
00:09:36,680 --> 00:09:36,960
 segment.

191
00:09:36,960 --> 00:09:39,760
 That's the only thing executable that gets code signed.

192
00:09:39,760 --> 00:09:43,520
 That also means that if you have data

193
00:09:43,520 --> 00:09:46,840
 that you want to be code signed and have integrity protection

194
00:09:46,840 --> 00:09:50,680
 on it from Apple systems, you can put it in the text segment.

195
00:09:50,680 --> 00:09:54,400
 You can either be a C string, or you can actually just

196
00:09:54,400 --> 00:09:56,000
 explicitly tell the compiler, hey,

197
00:09:56,000 --> 00:09:58,560
 put this in the text segment.

198
00:09:58,560 --> 00:09:59,640
 Watch out, though.

199
00:09:59,640 --> 00:10:01,400
 It means it will also be executable.

200
00:10:01,400 --> 00:10:03,240
 So I don't know.

201
00:10:03,240 --> 00:10:05,760
 Take your risk there.

202
00:10:05,760 --> 00:10:09,560
 Data, that's where all your common data, immutable state

203
00:10:09,560 --> 00:10:11,480
 will be.

204
00:10:11,480 --> 00:10:16,920
 Data const is a bit interesting.

205
00:10:16,920 --> 00:10:19,240
 So yeah, the way these protections work is left

206
00:10:19,240 --> 00:10:20,440
 is the initial protection.

207
00:10:20,440 --> 00:10:22,280
 So you can see on text, it's read execute,

208
00:10:22,280 --> 00:10:24,280
 and then right is max protections.

209
00:10:24,280 --> 00:10:26,520
 So that's what you can theoretically

210
00:10:26,520 --> 00:10:28,720
 upgrade the segment to.

211
00:10:28,720 --> 00:10:32,720
 So on Mac, you can make your text segment writable.

212
00:10:32,720 --> 00:10:34,160
 Data const is a bit weird.

213
00:10:34,160 --> 00:10:36,640
 So data const was a section that was added,

214
00:10:36,640 --> 00:10:41,480
 because originally, there was no const data on Darwin

215
00:10:41,480 --> 00:10:43,280
 or any Mac system like that.

216
00:10:43,280 --> 00:10:45,640
 They just had a section in data that

217
00:10:45,640 --> 00:10:49,200
 was assumed const for the global offset table.

218
00:10:49,200 --> 00:10:51,600
 That isn't great, because you can just go in and--

219
00:10:51,600 --> 00:10:54,480
 for example, an attacker can go in and change the global offset

220
00:10:54,480 --> 00:10:57,520
 table, and then suddenly all your calls to any system

221
00:10:57,520 --> 00:11:00,760
 functions can be easily detoured.

222
00:11:00,760 --> 00:11:03,480
 They kind of fix this by adding data const,

223
00:11:03,480 --> 00:11:05,840
 which is also not const.

224
00:11:05,840 --> 00:11:10,560
 But instead, what happens is it starts out as read/write.

225
00:11:10,560 --> 00:11:14,720
 Then dyld, after it's done dynamic linking,

226
00:11:14,720 --> 00:11:16,320
 will make it read-only.

227
00:11:16,320 --> 00:11:18,720
 But you can always just go back and make it writable again,

228
00:11:18,720 --> 00:11:22,200
 because it has max protections, and dyld is in user space.

229
00:11:22,200 --> 00:11:24,320
 So it's not const.

230
00:11:24,320 --> 00:11:27,760
 But it's by default, though, const.

231
00:11:27,760 --> 00:11:30,160
 However, there is a change happening here.

232
00:11:30,160 --> 00:11:32,680
 In iOS 17, they are releasing--

233
00:11:32,680 --> 00:11:35,240
 which I should be releasing in like a month or two--

234
00:11:35,240 --> 00:11:38,240
 they added this SG read-only flag.

235
00:11:38,240 --> 00:11:44,040
 So this flag, when added to a mock header,

236
00:11:44,040 --> 00:11:47,680
 it will have the kernel make it actually read-only

237
00:11:47,680 --> 00:11:50,440
 after dyld is done.

238
00:11:50,440 --> 00:11:52,880
 If you don't want that behavior for your executable,

239
00:11:52,880 --> 00:11:54,560
 you can remove the flag.

240
00:11:54,560 --> 00:11:56,360
 But that's something you notice.

241
00:11:56,360 --> 00:11:59,600
 Or maybe if you're trying to hook another executable,

242
00:11:59,600 --> 00:12:02,440
 look for that flag, because it might break all your hooks.

243
00:12:02,440 --> 00:12:10,760
 But it will actually be const, or closer to const, in iOS 17.

244
00:12:10,760 --> 00:12:14,360
 And then there you have things like your global offset table,

245
00:12:14,360 --> 00:12:17,720
 your Objective-C class list, and const data, that kind of stuff.

246
00:12:17,720 --> 00:12:20,640
 And then link edit is at the end of most executables.

247
00:12:20,640 --> 00:12:22,720
 And it's just linker data.

248
00:12:22,720 --> 00:12:26,400
 It's where dyld will get its operation codes,

249
00:12:26,400 --> 00:12:28,600
 because dyld has its own special opcodes that

250
00:12:28,600 --> 00:12:32,600
 are used to define how to update the various dynamic linking

251
00:12:32,600 --> 00:12:34,760
 in the file.

252
00:12:34,760 --> 00:12:37,160
 So yeah, so let's look at what an actual mock header looks

253
00:12:37,160 --> 00:12:38,200
 like.

254
00:12:38,200 --> 00:12:43,480
 First, you have the magic number to make sure it is correct.

255
00:12:43,480 --> 00:12:45,880
 Similarly, it has an Indianness check in it.

256
00:12:45,880 --> 00:12:49,560
 So you can check if it's MHMagic or MH.GAM.

257
00:12:49,560 --> 00:12:52,960
 And it again contains the architecture info, the file

258
00:12:52,960 --> 00:12:55,640
 type-- we'll look at those in just a second.

259
00:12:55,640 --> 00:12:57,800
 It also contains the number of load commands

260
00:12:57,800 --> 00:13:01,360
 and the size of the entire list of commands.

261
00:13:01,360 --> 00:13:05,320
 And that's because load commands are variable size, which

262
00:13:05,320 --> 00:13:07,240
 we'll get into in a bit.

263
00:13:07,240 --> 00:13:10,680
 That has some annoying implications, but yeah.

264
00:13:10,680 --> 00:13:12,260
 And then it also has some flags on it.

265
00:13:12,260 --> 00:13:13,920
 That's where that SG read-only thing--

266
00:13:13,920 --> 00:13:15,920
 this is where this would be.

267
00:13:15,920 --> 00:13:18,600
 There's a lot of flags, and they're mostly used by the linker.

268
00:13:18,600 --> 00:13:20,400
 But here are some ones that you'll probably

269
00:13:20,400 --> 00:13:22,040
 see if you look poke around.

270
00:13:22,040 --> 00:13:23,760
 No-on-defs means that it's fully linked

271
00:13:23,760 --> 00:13:26,760
 and doesn't need to be dynamically linked.

272
00:13:26,760 --> 00:13:29,160
 Py-- every executable should have py.

273
00:13:29,160 --> 00:13:31,120
 That means position independent.

274
00:13:31,120 --> 00:13:32,960
 Don't write position-dependent executables.

275
00:13:32,960 --> 00:13:35,560
 That's really not great.

276
00:13:35,560 --> 00:13:37,680
 Has objective C just means it has objective C.

277
00:13:37,680 --> 00:13:39,880
 dYLD means use dYLD.

278
00:13:39,880 --> 00:13:44,440
 And toLevel is a feature where dYLD will create namespaces

279
00:13:44,440 --> 00:13:47,440
 for the libraries that you link against so that there's not

280
00:13:47,440 --> 00:13:49,800
 naming collisions between symbols.

281
00:13:49,800 --> 00:13:54,200
 I think that's on by default, but don't quote me.

282
00:13:54,200 --> 00:13:56,560
 Here are the various file types that are known.

283
00:13:56,560 --> 00:13:59,040
 Assumably, Apple might have some more that they just

284
00:13:59,040 --> 00:14:01,240
 don't publicly define.

285
00:14:01,240 --> 00:14:04,720
 Object-- that's like when you compile a C file.

286
00:14:04,720 --> 00:14:08,960
 It's an intermediate object representation of machine code.

287
00:14:08,960 --> 00:14:10,920
 Execute is just an executable.

288
00:14:10,920 --> 00:14:16,400
 FVM lib is an obsolete VM file for in the old days.

289
00:14:16,400 --> 00:14:17,820
 Core is for when you get core dumps.

290
00:14:17,820 --> 00:14:19,660
 So if you ever want to investigate core dumps,

291
00:14:19,660 --> 00:14:21,480
 those are also mock-o files.

292
00:14:21,480 --> 00:14:25,240
 That's how Apple gets those crash reports on them.

293
00:14:25,240 --> 00:14:27,880
 Preload is also an obsolete one.

294
00:14:27,880 --> 00:14:31,960
 Dylib is how you determine a dynamic library

295
00:14:31,960 --> 00:14:33,400
 that wants to be loaded.

296
00:14:33,400 --> 00:14:35,000
 These have to be loaded.

297
00:14:35,000 --> 00:14:40,360
 So think libObjectiveC.dylib or whatever.

298
00:14:40,360 --> 00:14:43,760
 Those are all Dylib files, Dylib executables.

299
00:14:43,760 --> 00:14:46,200
 They can only be loaded via load commands

300
00:14:46,200 --> 00:14:48,680
 inside another executable or through an explicit call

301
00:14:48,680 --> 00:14:52,280
 to DL open inside a running process.

302
00:14:52,280 --> 00:14:56,280
 Dylinker is a special executable file that is a dynamic linker.

303
00:14:56,280 --> 00:14:59,320
 You can make your own and have executable programs

304
00:14:59,320 --> 00:15:01,880
 point to a unique dynamic linker if you don't want to use

305
00:15:01,880 --> 00:15:04,200
 DYLD for whatever reason.

306
00:15:04,200 --> 00:15:07,320
 Image bundle-- that one is for resource bundles.

307
00:15:07,320 --> 00:15:11,960
 Those actually can only be opened via bundle APIs in code.

308
00:15:11,960 --> 00:15:15,040
 You can't open them via the loader directly.

309
00:15:15,040 --> 00:15:16,920
 dsim is for dsim files.

310
00:15:16,920 --> 00:15:20,280
 And Dylib stub-- that one's an old one.

311
00:15:20,280 --> 00:15:22,280
 It's not really used anymore.

312
00:15:22,280 --> 00:15:25,400
 Essentially, Apple doesn't want to give out

313
00:15:25,400 --> 00:15:27,480
 its source code and Xcode.

314
00:15:27,480 --> 00:15:29,400
 So the way they do that-- they used to do that--

315
00:15:29,400 --> 00:15:32,080
 was to create empty executable files that

316
00:15:32,080 --> 00:15:33,440
 just had symbol tables.

317
00:15:33,440 --> 00:15:36,440
 So you could say, oh, yes, link me to this Dylib.

318
00:15:36,440 --> 00:15:39,000
 And then on Mac, on your devolving machine,

319
00:15:39,000 --> 00:15:41,080
 it would have no code, but it would link correctly.

320
00:15:41,080 --> 00:15:43,000
 And then on the phone, it would work.

321
00:15:43,000 --> 00:15:45,560
 They've replaced that with this new text-based definition file,

322
00:15:45,560 --> 00:15:46,640
 which you won't get into.

323
00:15:46,640 --> 00:15:48,480
 So you probably won't see that around.

324
00:15:48,480 --> 00:15:50,920
 If you wanted to try and poke around Xcode

325
00:15:50,920 --> 00:15:52,640
 to see what APIs are available, you'll

326
00:15:52,640 --> 00:15:54,680
 see a lot of these text-based definition files

327
00:15:54,680 --> 00:15:57,200
 and some of these Dylib stubs, which are just essentially

328
00:15:57,200 --> 00:16:00,240
 just empty files and lists of names.

329
00:16:00,240 --> 00:16:05,480
 And yeah, and then kex bundles for macOS kernel extensions.

330
00:16:05,480 --> 00:16:07,480
 So yes, this is kind of what we're looking at now.

331
00:16:07,480 --> 00:16:10,240
 Each individual object has these load commands.

332
00:16:10,240 --> 00:16:12,960
 And we know that there's segments somewhere spread

333
00:16:12,960 --> 00:16:14,920
 about, but we don't know where they are yet,

334
00:16:14,920 --> 00:16:16,360
 and we don't know how big they are,

335
00:16:16,360 --> 00:16:20,000
 and we don't know what kind of memory protections they have.

336
00:16:20,000 --> 00:16:21,840
 But we can figure that out by looking at-- but we do

337
00:16:21,840 --> 00:16:23,160
 know where these load commands are,

338
00:16:23,160 --> 00:16:24,880
 and that's where we're going to find out

339
00:16:24,880 --> 00:16:27,400
 all this extra information.

340
00:16:27,400 --> 00:16:31,680
 So a load command defines the various segments and sections,

341
00:16:31,680 --> 00:16:35,160
 and also other various things, such as OS version and name

342
00:16:35,160 --> 00:16:36,200
 and all types of stuff.

343
00:16:36,200 --> 00:16:39,320
 There's a lot of load commands.

344
00:16:39,320 --> 00:16:42,560
 There are a variable size.

345
00:16:42,560 --> 00:16:44,120
 As you can see, the base load command

346
00:16:44,120 --> 00:16:47,560
 is just a type and a size.

347
00:16:47,560 --> 00:16:49,840
 That also means that you can't index into load commands.

348
00:16:49,840 --> 00:16:51,960
 You have to go one by one and look

349
00:16:51,960 --> 00:16:54,240
 at each individual load command as you go through.

350
00:16:54,240 --> 00:16:57,320
 So whenever you're parsing one of these things,

351
00:16:57,320 --> 00:16:59,640
 try and make it to where you only have to do it once,

352
00:16:59,640 --> 00:17:02,080
 so you don't have to do an n squared algorithm of going

353
00:17:02,080 --> 00:17:03,960
 over and over again.

354
00:17:03,960 --> 00:17:05,800
 And we're going to look at a few load commands,

355
00:17:06,640 --> 00:17:12,640
 different. There are about 47, I think, load commands currently supported, or at least

356
00:17:12,640 --> 00:17:18,500
 publicly supported by Apple on Darwin systems. However, you can make your own, and you could

357
00:17:18,500 --> 00:17:23,880
 also presumably make, if you make your own dynamic link, you could also use them somehow.

358
00:17:23,880 --> 00:17:28,920
 So we'll look at a few common ones, but if you want an exhaustive list, I think loader.h

359
00:17:28,920 --> 00:17:35,080
 has most of them, and you can also look at, Jonathan Levin has a good list that's pretty

360
00:17:35,080 --> 00:17:39,960
 exhaustive of which ones are actually used. So first we'll look at probably one of the

361
00:17:39,960 --> 00:17:43,360
 more important ones, which is the segment command. There's 64-bit versions of a lot

362
00:17:43,360 --> 00:17:48,920
 of these commands, which is _64. You'll see this pattern a lot when looking at load commands,

363
00:17:48,920 --> 00:17:53,880
 where it's basically just C-style inheritance, where you have, it's the same as the load

364
00:17:53,880 --> 00:17:57,720
 command in the first two fields, and then just adds a bunch of stuff. So first it starts

365
00:17:57,720 --> 00:18:04,440
 with the segment name, which is a 16-byte string. That's where you get things like text,

366
00:18:04,440 --> 00:18:07,480
 data, data const. So that's where you'll be looking for those things if you're looking

367
00:18:07,480 --> 00:18:12,760
 for a specific segment. Then you get the address and size and memory. Note that if you're reading

368
00:18:12,760 --> 00:18:17,560
 from file, these are zero, or at least I wouldn't trust the values if you find them here. These

369
00:18:17,560 --> 00:18:24,000
 are provided by the loader as it loads it into process space. So if you're reading it

370
00:18:24,000 --> 00:18:28,720
 off a file, this will probably be zero, or maybe some other garbage value. And if you're

371
00:18:28,720 --> 00:18:32,040
 reading it off a file, you're going to want to use file offset and file size. That tells

372
00:18:32,040 --> 00:18:36,240
 you where in the file and how big it is. I also think there might be a potential difference

373
00:18:36,240 --> 00:18:41,440
 between file size and VM size, as I think VM size will always be page-aligned. Well,

374
00:18:41,440 --> 00:18:46,920
 I don't know if file size is guaranteed to be that. Then you have your maximum and initial

375
00:18:46,920 --> 00:18:52,440
 memory protections. And then, of course, you have something called sections. So each segment

376
00:18:52,440 --> 00:18:58,160
 is allowed to define sections within itself. The sections are more logical than necessarily

377
00:18:58,160 --> 00:19:07,000
 physical, but they are there to help define and separate the segment into logical sections.

378
00:19:07,000 --> 00:19:12,640
 If the insects flag is greater than zero, then that's how you know there will be that

379
00:19:12,640 --> 00:19:18,360
 many sections immediately after this segment command. So it's immediately after the command.

380
00:19:18,360 --> 00:19:22,400
 It's not located somewhere else. It's just right after it. And that's where you get these

381
00:19:22,400 --> 00:19:32,800
 section commands. A section has a 16-byte name as well. And also, you can see it has the

382
00:19:32,800 --> 00:19:37,360
 address that it's currently located at, the size of bytes in the section, as well as the

383
00:19:37,360 --> 00:19:43,040
 offset. Similarly, address may not be filled if you're reading it from disk. Use offset.

384
00:19:43,040 --> 00:19:51,240
 The alignment, the relocation entries, all that kind of simple stuff. The flags are pretty

385
00:19:51,240 --> 00:19:57,920
 interesting, but essentially the 8 LSB determines the type. So, for example, you could have

386
00:19:57,920 --> 00:20:01,200
 a section of C string literals. This is very helpful when you're trying to parse because

387
00:20:01,200 --> 00:20:05,240
 it tells you how to actually interpret the section. So a C string literal section is

388
00:20:05,240 --> 00:20:09,880
 literally a list of null terminated C strings. So when you know where that section is, you

389
00:20:09,880 --> 00:20:14,520
 can just build an array of strings pretty easily off of it. There's various types. You

390
00:20:14,520 --> 00:20:20,040
 can find them in loader.h. The other bits are used for various attributes such as you

391
00:20:20,040 --> 00:20:24,000
 could say it's a debug section, which means it has debug symbols included inside it. And

392
00:20:24,000 --> 00:20:30,920
 also, sections are naive in that there is no checking to make sure sections make sense.

393
00:20:30,920 --> 00:20:36,520
 You can have the bounds of a section are not guaranteed to overlap or not overlap with

394
00:20:36,520 --> 00:20:41,160
 any other section. They're not guaranteed to actually be ordered. There's no checking.

395
00:20:41,160 --> 00:20:46,720
 It's just off of good faith. So there might be an exploit there. I don't know. Maybe you

396
00:20:46,720 --> 00:20:50,480
 all can think of it. But there is no checking there. You can probably come up with some

397
00:20:50,480 --> 00:20:56,920
 things to fuck with sections. Or at least fuck with your disassembler. You can also

398
00:20:56,920 --> 00:21:01,880
 create custom sections inside a segment by using encode. You can just say this attribute

399
00:21:01,880 --> 00:21:06,600
 like put this section in this segment. This is also how if you wanted to put data in your

400
00:21:06,600 --> 00:21:11,000
 text segment, you could create a custom section, put the data in there, and then it will get

401
00:21:11,000 --> 00:21:17,320
 code signed. And then you can also create a section via a file by using this linker command

402
00:21:17,320 --> 00:21:25,480
 to ld. Yeah, another load command would be lcmain. This literally just tells us where

403
00:21:25,480 --> 00:21:28,840
 the main function is. So if you're ever interested in where the entry point--finding entry points

404
00:21:28,840 --> 00:21:33,840
 can be kind of hard in code. Luckily for executables, you just look at this guy. It'll tell you

405
00:21:33,840 --> 00:21:41,840
 exactly where it is. Yeah, another one is dilinker. This actually specifies the dynamic linker

406
00:21:41,840 --> 00:21:49,480
 that the operating system should use when fixing up the executable at runtime. Usually

407
00:21:49,480 --> 00:21:55,080
 it's dyld or dyld_simulator if you're working on simulator. But you can always make your

408
00:21:55,080 --> 00:22:00,560
 own. I don't know why you would, but you can. And you can always just have your executable

409
00:22:00,560 --> 00:22:04,240
 or what executable you're investigating. You can always overwrite this load command with

410
00:22:04,240 --> 00:22:08,960
 your dynamic linker, and then you're able to then capture and get the fix-ups. Maybe you

411
00:22:08,960 --> 00:22:15,960
 want to see what symbols various objects want to look at or something like that. And then

412
00:22:15,960 --> 00:22:19,240
 this is probably the other more common command you'll see is the load command. This is what

413
00:22:19,240 --> 00:22:26,720
 loads dynamic libraries into your process space. It uses this dialib struct inside of

414
00:22:26,720 --> 00:22:32,440
 it, which is this long thing of various... It's just like a bunch of data structs inside

415
00:22:32,440 --> 00:22:39,120
 of each other. It's just nested for you. And it has a command and command size. It just

416
00:22:39,120 --> 00:22:43,880
 tells you where it is. There's various versions of this one for all the types you can use

417
00:22:43,880 --> 00:22:51,120
 to import a dynamic library, such as weekly or re-exporting and all those things. Yeah,

418
00:22:51,120 --> 00:22:56,700
 so this is the basic structure of a MacO file. You have a fat header with various architectures

419
00:22:56,700 --> 00:23:01,800
 after it. Each of those architectures has a MacO object that has a header themselves,

420
00:23:01,800 --> 00:23:05,440
 followed by a list of load commands inside of the text segment. And those load commands

421
00:23:05,440 --> 00:23:10,840
 tell you where all of these segments lie within the object. And then you can use the various

422
00:23:10,840 --> 00:23:16,320
 things to go through and look at the sections and look at the various load commands as well.

423
00:23:16,320 --> 00:23:24,440
 So to give this a little more concrete example, I wrote up a little program that will extract

424
00:23:24,440 --> 00:23:33,400
 the Objective-C class hierarchy from any module loaded into a process space. And we'll just

425
00:23:33,400 --> 00:23:38,600
 go run through that so you can see what it looks like. We're assuming 64-bit because

426
00:23:38,600 --> 00:23:48,320
 I don't think Apple supports 32-bit since 2017, 2018. And also, I removed some error

427
00:23:48,320 --> 00:23:55,360
 checkings to make sure that it's not too verbose. So yeah, we're going to look at all of those--even

428
00:23:55,360 --> 00:23:59,360
 all the system modules loaded into just a basic Hello World application. And we're going

429
00:23:59,360 --> 00:24:03,760
 to take a look at what their Objective-C class hierarchy is by just looking at the executable

430
00:24:03,760 --> 00:24:09,880
 images that were loaded by the system. And for reference, Objective-C only has single

431
00:24:09,880 --> 00:24:16,200
 inheritance and the root object is NSObject. So here's our main function. This first bit

432
00:24:16,200 --> 00:24:20,640
 here is just some way so that it didn't take forever. It's just parallelizing it, so don't

433
00:24:20,640 --> 00:24:26,960
 worry about it. The first important bit is that we do want to see every mock image loaded

434
00:24:26,960 --> 00:24:32,040
 into our process and we do that with doild register func for add image. What this will

435
00:24:32,040 --> 00:24:37,320
 do is it--when we first call it, it will use this callback we give it and call it for every

436
00:24:37,320 --> 00:24:44,520
 single image that has been loaded as of yet into the process. That includes our own image

437
00:24:44,520 --> 00:24:50,240
 as well. Then after it is done doing that, it will go to sleep and then any time a new

438
00:24:50,240 --> 00:24:56,840
 image is loaded into the process in the future, it will also call into our callback to let

439
00:24:56,840 --> 00:25:01,660
 us know this happened. So if you ever want to monitor what images are being loaded in

440
00:25:01,660 --> 00:25:04,920
 and out of your process, this is a really good way to do that. Maybe you're worried

441
00:25:04,920 --> 00:25:09,000
 about someone injecting themselves in there or something like that. But yeah, this is

442
00:25:09,000 --> 00:25:14,520
 a good way to do that is to use this doild API. So in our callback, this is what the

443
00:25:14,520 --> 00:25:20,040
 callback signature looks like. It gives us a mock header and the slide. The slide is

444
00:25:20,040 --> 00:25:26,240
 referring to address layout space randomization. Essentially, whenever the OS loads you into

445
00:25:26,240 --> 00:25:30,720
 memory, it chooses a random place to just plop you so that it's harder to determine

446
00:25:30,720 --> 00:25:35,680
 where your code will be so that things like stack overflows and buffer overflows are less

447
00:25:35,680 --> 00:25:43,000
 exploitable. Note that the mock header here is technically a 32 bit one. I don't know

448
00:25:43,000 --> 00:25:47,000
 why they did the API like this, but it only gives you a 32 bit one. Luckily, you can just

449
00:25:47,000 --> 00:25:53,760
 cast it to 64 bit and it works fine. Actually, you kind of have to. Yeah, so next we will

450
00:25:53,760 --> 00:25:57,320
 just go into here. We're not going to look at the export hierarchy code because it's

451
00:25:57,320 --> 00:26:03,000
 boring. So we'll just go straight into the actual mock O parsing. So at the beginning

452
00:26:03,000 --> 00:26:08,080
 we're just doing normal Ejective-C initialization stuff. This is where you can see I'm just

453
00:26:08,080 --> 00:26:12,040
 casting it to the 64 bit mock header. You just have to remember to do that. If you're

454
00:26:12,040 --> 00:26:17,240
 doing things in production, you would probably have a preprocessor defined to make sure you're

455
00:26:17,240 --> 00:26:20,760
 choosing the correct headers here. That's actually pretty common. It's just redefine

456
00:26:20,760 --> 00:26:24,400
 all of Apple's structs to be based off of preprocessor definitions so that you always

457
00:26:24,400 --> 00:26:30,720
 get the 64 bit or 32 bit version. Here we're checking that file type. We only care about

458
00:26:30,720 --> 00:26:34,920
 dialibs. We're not going to look at bundles or executables or anything like that. Note

459
00:26:34,920 --> 00:26:39,000
 that we don't need to actually check for Indianness because it's loaded into our process space

460
00:26:39,000 --> 00:26:44,400
 and so hopefully it's the same Indianness as our process. Also, we're not looking at

461
00:26:44,400 --> 00:26:47,560
 the fat header because it's also loaded into our process space. We don't need to know which

462
00:26:47,560 --> 00:26:51,640
 architecture we're looking at. Once again, to reiterate, if you are looking at fat headers,

463
00:26:51,640 --> 00:26:54,600
 you do need to check that. If you're looking at architectures that you're unsure of, you

464
00:26:54,600 --> 00:27:00,520
 really should check it so that you can swap. Yeah, and then we go to parse the binary.

465
00:27:00,520 --> 00:27:06,200
 So this is kind of the basic iteration loop of parsing the binary. First, we grab the

466
00:27:06,200 --> 00:27:11,400
 load command which is right after the mock header so we just take the next element after

467
00:27:11,400 --> 00:27:18,400
 that and cast it. Then as we iterate, we just double check that our current command as a

468
00:27:18,400 --> 00:27:25,480
 byte location is less than our size of commands. Then starting at the beginning of the first

469
00:27:27,880 --> 00:27:34,880
 load command and then to iterate at the bottom, we just add the command size from each particular

470
00:27:34,880 --> 00:27:41,080
 command. Yeah, and then at the end we return nil if we return true if we parsed it correctly

471
00:27:41,080 --> 00:27:47,520
 and all that stuff. So here's the inside of the loop. You'll almost definitely use a switch

472
00:27:47,520 --> 00:27:51,340
 structure just because it's convenient because you're going to be checking IDs of load commands

473
00:27:51,340 --> 00:27:56,400
 so it makes sense. So in this first case, we're going to see if it's a dialib and if

474
00:27:56,400 --> 00:28:02,040
 it is a dialib, we're just going to grab its name or this grabs the name of the dialib

475
00:28:02,040 --> 00:28:09,040
 that was loaded. So this lets us keep track of which images are which. Here we're grabbing

476
00:28:09,040 --> 00:28:16,240
 the segments of that image and trying to see which one. If it's a data const section, then

477
00:28:16,240 --> 00:28:21,440
 we move on because that's where the Objective-C class list is. We then iterate through all

478
00:28:21,440 --> 00:28:25,240
 the sections. So this is a very similar structure as to integrate through the load commands

479
00:28:25,240 --> 00:28:31,280
 where we just move past each section until we find the Objective-C class list, in which

480
00:28:31,280 --> 00:28:37,140
 case we can then parse that, which we can see here. Then when we're inside the Objective-C

481
00:28:37,140 --> 00:28:42,640
 class list, this is like a literal array of Objective-C class objects that the runtime

482
00:28:42,640 --> 00:28:47,080
 has already populated with the correct data since we're loaded into memory. So because

483
00:28:47,080 --> 00:28:53,080
 of that, we can actually just use the Objective-C runtime functions on these byte values that

484
00:28:53,080 --> 00:28:57,200
 we found in this list. There's a million ways you could have done this. You could have parsed

485
00:28:57,200 --> 00:29:00,440
 the Objective-C class object. You could have done a lot of things. I thought this was the

486
00:29:00,440 --> 00:29:06,480
 simplest. So we just use class get name and class get superclass to get all of the names

487
00:29:06,480 --> 00:29:13,320
 of the various classes we're trying to look at. Then we just return it. And yeah, that's

488
00:29:13,320 --> 00:29:19,720
 basically the entire parsing. Here's a little test framework I made to verify that this

489
00:29:19,720 --> 00:29:23,280
 worked. And you can see from this you can actually get a decent amount of structural

490
00:29:23,280 --> 00:29:30,660
 information, but this is a very simple case. Here is the shared with you framework. This

491
00:29:30,660 --> 00:29:38,120
 is how they do-- this is the framework that is used for screen sharing or the activity

492
00:29:38,120 --> 00:29:43,480
 controller where you do the little shared communication stuff. It's not too complicated,

493
00:29:43,480 --> 00:29:49,720
 it looks like. It just has a little bit of a radial thing here, not too many clusters

494
00:29:49,720 --> 00:29:56,600
 as you would normally see in an Objective-C stuff. Here is CloudKit. It was a bit too

495
00:29:56,600 --> 00:30:04,240
 big, but if we zoom in a little bit, we can see right here, that's where all of the database

496
00:30:04,240 --> 00:30:11,740
 operations are. So you can check this out there. And I wanted to do core data, but it

497
00:30:11,740 --> 00:30:19,480
 got really gnarly. Let's see if I can get this video working. Yeah, it was just-- there

498
00:30:19,480 --> 00:30:25,040
 was too many things in there, but you can even see there's a guy freaking out in the

499
00:30:25,040 --> 00:30:32,000
 middle. I think that's NSObject. And yeah. But yeah, so that was the little thing there

500
00:30:32,000 --> 00:30:35,840
 just as an example of what you could do with it. I'm sure you all are more creative than

501
00:30:35,840 --> 00:30:42,720
 me, so you can figure out other cool stuff. Yeah. So for resources on this, there are

502
00:30:42,720 --> 00:30:47,520
 the various headers I was referring to throughout Loader, FAT, Arch, and Machine. OTool and

503
00:30:47,520 --> 00:30:52,560
 LiPo are really helpful for working these types of files. And as for books, Jonathan

504
00:30:52,560 --> 00:30:57,880
 Levin has great books on all of this. In fact, he probably is the person for the definition

505
00:30:57,880 --> 00:31:05,560
 of-- I mean, he's the documentation for Apple and he doesn't work there. So star OS internals

506
00:31:05,560 --> 00:31:09,560
 volume one has all of this information and more. So I highly recommend it if you're interested

507
00:31:09,560 --> 00:31:16,000
 in reverse engineering Apple systems. And yeah. Any questions or-- yeah.

508
00:31:16,000 --> 00:31:17,000
 [ Applause ]

509
00:31:17,000 --> 00:31:22,000
 >> Other questions?

510
00:31:22,000 --> 00:31:38,720
 >> Hi. Thank you. That was very interesting. Earlier in the talk, you mentioned about Apple

511
00:31:38,720 --> 00:31:41,600
 code signing some parts of the thing, the text section.

512
00:31:41,600 --> 00:31:42,600
 >> Yeah.

513
00:31:42,600 --> 00:31:48,680
 >> And I think maybe I misunderstood you, but you said like it only signs the first

514
00:31:48,680 --> 00:31:50,960
 part. There was something like that.

515
00:31:50,960 --> 00:31:56,400
 >> So when Apple-- when you code sign to be released on the app store or so that your

516
00:31:56,400 --> 00:32:01,160
 Mac OS app doesn't require them to have to like click through three menus to be loaded,

517
00:32:01,160 --> 00:32:07,140
 it doesn't code sign the entire executable. It only code signs the text segment. So that

518
00:32:07,140 --> 00:32:12,240
 includes the mock header and then all your code and then anything you want to put in

519
00:32:12,240 --> 00:32:17,000
 there like C strings or whatever. They don't do the entire executable. I'm not exactly

520
00:32:17,000 --> 00:32:22,800
 sure why, but that's currently how it works. It's also what is encrypted by the iOS store.

521
00:32:22,800 --> 00:32:27,200
 So you can actually-- if you get iOS apps downloaded from the store, there's an old

522
00:32:27,200 --> 00:32:34,240
 iTunes IT app for Windows that lets you download IPAs from the app store directly onto a Windows

523
00:32:34,240 --> 00:32:38,400
 PC. You can actually look at their executables and you won't see their code because it's

524
00:32:38,400 --> 00:32:42,280
 encrypted. But that text segment will be code signed and encrypted but nothing else will.

525
00:32:42,280 --> 00:32:43,280
 Yeah.

526
00:32:43,280 --> 00:32:50,720
 >> So if I were to rewrite some parts of the Mac OS actions, would I need to re-sign the

527
00:32:50,720 --> 00:32:53,920
 binary then because the signer signature wouldn't match, right?

528
00:32:53,920 --> 00:33:00,520
 >> Yeah. So if you are using build tooling to do that, you will have to re-sign it. If

529
00:33:00,520 --> 00:33:04,880
 you're building locally, that's not a huge issue. You can just use the code sign tool

530
00:33:04,880 --> 00:33:09,280
 on command line. It does get a little more troubling if you're trying to, I don't know,

531
00:33:09,280 --> 00:33:14,960
 break into something, right? Because you don't have their certificate. I would say the easiest

532
00:33:14,960 --> 00:33:19,160
 way to fix that would be to jailbreak the phone you're on and then you don't have to worry

533
00:33:19,160 --> 00:33:25,800
 about it. Yeah, that's probably the easiest way to do it. Or there might be a way to do

534
00:33:25,800 --> 00:33:31,640
 it also using the debugger. However, I don't know the exact way you would do that. I know

535
00:33:31,640 --> 00:33:36,220
 that Frida is able to get away with breaking code signing using the debugger. So maybe

536
00:33:36,220 --> 00:33:39,400
 look at the Frida tool, which is also a very great tool for this kind of stuff.

537
00:33:39,400 --> 00:33:42,400
 >> Thank you. >> Yeah.

538
00:33:42,400 --> 00:33:51,840
 >> Are there further questions? Okay. That seems not to be the case. And you now all

539
00:33:51,840 --> 00:33:58,200
 know how these files work and have fun with some. And we thank Gary again.

540
00:33:59,100 --> 00:34:06,100
 [ Applause ]

541
00:34:07,000 --> 00:34:13,000
 [ Music ]