1
00:00:11,570 --> 00:00:21,570
Okay, so today we've got Christopher Wade presenting on BeyondRoot custom firmware for embedded mobile chipsets.

2
00:00:21,570 --> 00:00:28,770
So thank you for joining us, Christopher, and I'll let you do any opening remarks, and then we'll go right into the questions.

3
00:00:32,080 --> 00:00:32,960
Excellent.

4
00:00:33,780 --> 00:00:34,580
Hello, everyone.

5
00:00:34,580 --> 00:00:36,400
Thank you for coming to my talk.

6
00:00:38,300 --> 00:00:39,840
Yeah, that's pretty much all I can say.

7
00:00:39,840 --> 00:00:40,440
Thanks very much.

8
00:00:40,440 --> 00:00:41,500
It's definitely...

9
00:00:43,400 --> 00:00:48,860
Could you tell us a little bit about yourself and just like a quick intro summary for your talk?

10
00:00:50,360 --> 00:00:52,400
Yep, so quick introduction.

11
00:00:52,400 --> 00:00:56,000
This talk is mainly about custom firmware for embedded mobile chipsets.

12
00:00:56,060 --> 00:01:03,360
This is essentially me hacking chips inside my phone, which aren't the core ARM chip used to run the thing, in order to make it do different things in the hardware.

13
00:01:03,360 --> 00:01:06,440
In particular for this talk, it's going to be NFC chips.

14
00:01:06,440 --> 00:01:12,060
So I reverse-engineer the firmware of an NFC chip, break the signature checking, and then implement my own firmware onto it.

15
00:01:13,920 --> 00:01:14,720
Excellent.

16
00:01:14,720 --> 00:01:15,220
Great.

17
00:01:15,220 --> 00:01:18,220
So we have one question already queued up.

18
00:01:18,540 --> 00:01:22,080
So how did Samsung react to the disclosure of vulnerabilities?

19
00:01:23,120 --> 00:01:25,720
Yeah, so Samsung reacted very positively.

20
00:01:25,720 --> 00:01:33,540
So I submitted it to their mobile security team initially, and they accepted it, even though it was technically part of their Samsung team.

21
00:01:34,580 --> 00:01:40,240
So I sent them the disclosure, and they delayed with their interdepartmental systems or whichever.

22
00:01:40,540 --> 00:01:47,320
And initially, because I submitted the Samsung S6 vulnerability, they said that this wasn't really something they were going to remediate, just because it was out of scope.

23
00:01:47,320 --> 00:01:49,280
The Samsung S6 is no longer supported.

24
00:01:49,420 --> 00:01:55,560
But when I submitted the Samsung S9, they happily took it and started the remediation process, which was pretty good.

25
00:01:56,600 --> 00:02:01,620
And chips that have been manufactured, I believe you said, after April aren't vulnerable to this?

26
00:02:01,620 --> 00:02:02,340
Yes.

27
00:02:02,340 --> 00:02:14,880
So what they have done is essentially, while they can't really patch the bootloaders of existing chips once they've already been manufactured, as outlined in the talk, what I have done is discussed with them about how they're going to remediate this.

28
00:02:14,880 --> 00:02:20,920
And what they said was they're going to remediate all of the chipsets of the current versions in the manufacturing plant.

29
00:02:20,920 --> 00:02:25,060
So all of the bootloaders can be patched as chips go out from now onwards.

30
00:02:25,220 --> 00:02:28,160
However, all historical chips will still be affected.

31
00:02:28,160 --> 00:02:31,260
So that's why I decided to make a custom firmware for them.

32
00:02:31,260 --> 00:02:33,420
They'll still have the vulnerable bootloader.

33
00:02:33,420 --> 00:02:34,520
Yes, exactly.

34
00:02:34,760 --> 00:02:36,540
Which is very useful.

35
00:02:36,900 --> 00:02:41,120
So near the end of the talk, there was a problem with a parity bit.

36
00:02:41,120 --> 00:02:42,700
Did you ever get that worked out?

37
00:02:42,980 --> 00:02:45,420
Yes, so the parity bit was an interesting one.

38
00:02:45,520 --> 00:02:55,860
What they tended to do in the initial firmware or the firmware reverse engineering is load all their 8-bit buffers as they should into the 8-bit buffer in the hardware registers.

39
00:02:55,860 --> 00:03:05,160
This is done because that way the hardware itself can pick up the slack with the set and unset bits, which is done to sort of calculate parity between each set of bytes that are sent.

40
00:03:05,160 --> 00:03:13,500
What I did was find a very specific hardware address and a very specific bit in that hardware address set, which let me essentially control that parity bit.

41
00:03:13,500 --> 00:03:22,120
What this meant was I set up 9-bit values, so that includes the 8 bits of the byte followed by the 1-bit parity bit, which need to be encrypted, and that's the start of the process.

42
00:03:22,120 --> 00:03:34,460
I had to sort of bit shift everything around by one on each part, because the buffer was 8 bits, but I had 9 bits of base to shove, so essentially I just had to bit shift that around, which was a bit strange, but it did work.

43
00:03:35,100 --> 00:03:40,520
Did you get NFC tag cloning working?

44
00:03:41,280 --> 00:03:58,680
Yes, so what I ended up doing in the end was literally being able to read an NFC tag using the standard reader application that existed, and use my tool to upload binary data through the I2C interface that I had, so I could set each block of the data of the NFC tag as I wanted it,

45
00:03:58,680 --> 00:04:13,000
including the UID, the write and read bits, etc, all parts that I could upload and download as needed, and I also hooked into the I2C interface, so that every time some reader wrote to the tag as well and authenticated it properly, it would then also write that via I2C,

46
00:04:13,000 --> 00:04:30,440
so I could modify the binary file I had, this would mean things like access control systems and things, I would be able to keep a check of what was going on, so some access control systems had logs for how many things had been read, and some other imperative information to make sure that no tags had been cloned or reused,

47
00:04:30,440 --> 00:04:41,360
and I basically did that so that I could clone the tags while also allowing the data to be modified persistently, even if I stopped running the resource, and this was quite slow in the end.

48
00:04:41,920 --> 00:04:46,080
So do you have any questions?

49
00:04:46,100 --> 00:05:10,060
Yeah, so not on the track yet, but I did notice that your talk was mostly a tutorial on reverse engineering, and I think it seemed like you were starting out because you were curious about the NFC firmware and wanted to take a whack at customising it,

50
00:05:10,060 --> 00:05:12,280
is that, am I catching your motive correctly?

51
00:05:12,900 --> 00:05:27,460
Yeah, so that is essentially how I started, what really started this off was I had an old Samsung S6 that we started with at the start of the talk, which I was essentially using to just mess around with different custom ROMs on, and one of the things I did was port Debian to this,

52
00:05:27,460 --> 00:05:37,640
so I scraped up all of the Android operating system and shoved the Debian root file system into place, so instead of having it as a shroof as I outlined in the talk, it was more of a full operating system on the device.

53
00:05:37,640 --> 00:05:41,960
Now, this afforded quite a lot of functionality, but also meant that things like the screen didn't work so well.

54
00:05:42,220 --> 00:05:52,500
I quite enjoyed this because I was going to add some sort of hacking tools, modify the USB interface and things, so that I could use GadgetFS, et cetera, but I thought it would be interesting to see where I could push things like the NFC side.

55
00:05:52,500 --> 00:06:01,940
So I redeployed LineageOS to the Samsung S6 phone, which is a very standard custom ROM, and then started looking at the NFC chip, and that's sort of where the project sprung off from there.

56
00:06:01,940 --> 00:06:09,760
So it started off as more of a standard custom ROM project, then it started off as a standard reverse engineering project, but because I like reverse engineering, it sort of went on from there.

57
00:06:09,760 --> 00:06:11,480
It just sort of slid into it.

58
00:06:11,480 --> 00:06:12,600
Yeah, that happens.

59
00:06:14,820 --> 00:06:17,120
So have you looked at any other chips inside of phones?

60
00:06:17,120 --> 00:06:23,500
This seems like a really deep and hyper-specific long chain that you went through to patch in this functionality.

61
00:06:24,040 --> 00:06:25,580
Um, yes.

62
00:06:25,900 --> 00:06:30,300
Unfortunately, due to responsible disclosure, I can't discuss those at the moment.

63
00:06:30,300 --> 00:06:31,020
Fair enough.

64
00:06:31,020 --> 00:06:32,680
I'm very sorry about that.

65
00:06:32,680 --> 00:06:36,800
So maybe I'll sort of ask around this.

66
00:06:36,800 --> 00:06:43,280
Was this the first one, and you've just been able to successfully, responsibly disclose this one?

67
00:06:43,360 --> 00:06:48,700
Or what has your experience in the past led you, that brought you to this kind of point?

68
00:06:49,780 --> 00:06:51,560
Yeah, so this is definitely the first one.

69
00:06:52,420 --> 00:06:59,340
Unlike most of us, we have a habit of routing our last phone that we're using, not our current phone, because walking around with a routed phone is not the best idea.

70
00:06:59,640 --> 00:07:06,880
So I'd had a lot of older phones, and then I'd got a Samsung S6 for a few years, and then replaced it with a new phone, and just had it lying around.

71
00:07:06,880 --> 00:07:10,080
So the first thing I did was route it, and then start looking at seeing what I've been doing.

72
00:07:10,120 --> 00:07:12,460
I also looked at a few older phones at the same time.

73
00:07:12,460 --> 00:07:19,320
So for instance, I had a very old Samsung Galaxy Mini, which has FM radio capabilities based on a Broadcom chipset.

74
00:07:19,440 --> 00:07:20,340
Now, that was very interesting.

75
00:07:20,860 --> 00:07:24,840
Because it didn't seem to have any code signing with some of the binary files on there.

76
00:07:25,780 --> 00:07:29,420
It looked like it wasn't just an FM radio receiver, but also a transceiver.

77
00:07:29,420 --> 00:07:32,900
So I wanted to see if I could push it into doing FM transceiving.

78
00:07:32,980 --> 00:07:39,280
Sadly, that didn't really go anywhere, because quite frankly, working on old Android versions like that is incredibly tedious.

79
00:07:39,300 --> 00:07:44,200
They don't always use device file appropriately, and they often route their circuitry around in ways that just...

80
00:07:44,200 --> 00:07:51,240
It doesn't work very well by comparison to more modern phones, where everything's laid out, everything's documented, everything's open source in really nice ways.

81
00:07:51,560 --> 00:07:52,560
That's super unfortunate.

82
00:07:52,560 --> 00:07:58,370
I do remember some really old phone hacks that they were...

83
00:07:59,520 --> 00:08:03,840
I think they were actually MP3 player hacks that you could turn them into FM transmitters.

84
00:08:05,320 --> 00:08:07,520
Yeah, that would be cool to get your phone to do it too.

85
00:08:09,260 --> 00:08:14,560
Sadly, I'm stuck with a Raspberry Pi with a wire sticking out of one of the pins at the moment, which is good enough for now.

86
00:08:15,240 --> 00:08:16,260
Fair enough.

87
00:08:23,180 --> 00:08:27,860
Is there any other active projects that you're working on that you can talk about?

88
00:08:28,900 --> 00:08:31,560
Yeah, so I'm still looking at different phone chipsets.

89
00:08:31,560 --> 00:08:33,900
I've been looking around to see what other NFC chips that are used.

90
00:08:33,900 --> 00:08:37,260
There's only a handful of manufacturers, and that's something I'm looking into.

91
00:08:37,260 --> 00:08:43,840
But the big problem there is obviously price point, because phones are expensive things, and it's not something you want to buy randomly.

92
00:08:43,880 --> 00:08:50,600
The key thing I've been looking at is downloading custom ROMs for random phones that I thought would be interesting, not just for NFC chips, but other firmware binaries.

93
00:08:50,600 --> 00:08:58,040
Because if you download the ROMs and unpack them, then you can find quite a lot of information about the hardware that you wouldn't be able to get just from a teardown, for instance.

94
00:08:58,060 --> 00:09:03,600
For instance, if you go in the vendor partition, there's all sorts of firmware blobs for things like Wi-Fi chipsets, etc.

95
00:09:03,640 --> 00:09:08,520
And that's where it led me to things like... so I've got a Xiaomi Mi Note 3, which is an old phone.

96
00:09:08,700 --> 00:09:17,580
And while this isn't necessarily a firmware hack, being able to echo a single number into the sys files and turn that into a monitor mode phone is very powerful.

97
00:09:17,780 --> 00:09:22,500
Like full-on passive monitor mode, no injection, but still full-on monitor mode that works really effectively.

98
00:09:22,500 --> 00:09:28,340
Things like that is just something I keep looking through and looking through as much as I can, because it's quite fun to mess around with phones in that way.

99
00:09:28,340 --> 00:09:29,220
That's awesome.

100
00:09:29,260 --> 00:09:36,440
So part of your project, you used... I believe it was called the Unicorn Engine for hardware emulation.

101
00:09:36,600 --> 00:09:39,980
What level of emulation is actually happening there?

102
00:09:39,980 --> 00:09:41,640
Is it just like the CPU?

103
00:09:41,640 --> 00:09:44,200
How does it handle peripherals and stuff?

104
00:09:44,440 --> 00:09:45,000
Okay, yeah.

105
00:09:45,000 --> 00:09:47,420
So the Unicorn Engine is a really powerful tool.

106
00:09:47,420 --> 00:09:50,100
And I've seen a few talks on this by the people who've actually developed it.

107
00:09:50,100 --> 00:09:51,780
I'm sure it was at Defcon as well.

108
00:09:53,360 --> 00:09:56,640
As it's a library that's purely used for loading into other things.

109
00:09:56,640 --> 00:09:59,160
Now, I always write my stuff in C, so I load it into C.

110
00:09:59,940 --> 00:10:02,680
All it does is emulate the core architecture you want to go for.

111
00:10:02,680 --> 00:10:04,120
So in my case, it was ARM sum.

112
00:10:04,260 --> 00:10:06,560
Then it lets you map out memory mapping as you want.

113
00:10:06,560 --> 00:10:09,640
So in order to write and read memory to start things up.

114
00:10:09,640 --> 00:10:14,840
And then you can hook both operations and reads and writes of memory.

115
00:10:14,840 --> 00:10:17,420
So when you hook into operations, you can make them act in weird ways.

116
00:10:17,420 --> 00:10:25,840
For instance, one of the problems I had with my hardware was it would sometimes hit the wait for interrupt operation, which wasn't supported by Unicorn.

117
00:10:25,840 --> 00:10:29,060
And I could override that just to a standard NOP because I didn't need to think about it.

118
00:10:29,520 --> 00:10:33,220
But hooking into the memory reads and writes was what was really key for me.

119
00:10:33,260 --> 00:10:37,240
Because I can map out to say there's actually hardware addresses at certain points.

120
00:10:37,240 --> 00:10:42,640
I could then just put an if statement, a switch statement, just saying if it hits this address, mess with it in this way.

121
00:10:42,640 --> 00:10:47,940
For instance, in the I2C interface, it was when it hits the I2C status buffer, I want it to return random data.

122
00:10:47,940 --> 00:10:51,220
So it eventually hits the OK status or sometimes the busy status.

123
00:10:51,440 --> 00:11:01,660
And then when it hits the read and writes, I wanted it to read in data that I was writing to it as if it was the physical chip and then write data back when it was the physical chip, which is how I got that initial fuzzing working.

124
00:11:01,660 --> 00:11:03,420
So it's really powerful for that.

125
00:11:03,420 --> 00:11:08,700
But it has no integration for actual realistic hardware, just the processing as it's going along.

126
00:11:08,700 --> 00:11:11,520
So just the core operations, which is really cool.

127
00:11:11,520 --> 00:11:18,560
But you can write basically functions that are at those memory addresses just to pretend to be that hardware, right?

128
00:11:18,560 --> 00:11:22,220
Yeah, so you can literally set R0, R1, R2, you know, the command.

129
00:11:22,420 --> 00:11:25,140
And then the program counter will say go into this.

130
00:11:25,160 --> 00:11:26,920
And you can also set the address to tell it to finish.

131
00:11:26,920 --> 00:11:28,880
They can stick that at the end of the function.

132
00:11:29,020 --> 00:11:34,560
And that way you'll run through the function, call the functions it needs to, but also then stop when it's ready.

133
00:11:34,600 --> 00:11:36,620
And you'll then be able to read out memories you want.

134
00:11:36,740 --> 00:11:45,880
So for instance, what I wanted to do before I started up, part of the project I didn't really mention was I start off emulating the actual firmware binary that I had rather than the bootloader.

135
00:11:46,020 --> 00:11:50,580
And what I did was load that in and let it run so that I could set up all the hardware addresses I needed.

136
00:11:50,580 --> 00:11:53,960
So RAM, et cetera, to see how that was laid out, to see if I could see anything.

137
00:11:53,960 --> 00:11:59,980
Because you can let it start and then let it stop and then dump the memory out as you need to without really any problems.

138
00:11:59,980 --> 00:12:01,720
Oh, cool.

139
00:12:01,720 --> 00:12:03,860
That's actually really, really slick.

140
00:12:03,900 --> 00:12:05,640
It's really powerful, yeah.

141
00:12:05,640 --> 00:12:06,400
Yeah.

142
00:12:06,560 --> 00:12:19,440
So how do you go about making the jump from these accessing a particular hardware address to saying, okay, this is an I2C chip, external peripheral.

143
00:12:19,960 --> 00:12:22,200
How do you make that inference?

144
00:12:22,420 --> 00:12:23,860
Well, it was definitely inference.

145
00:12:23,860 --> 00:12:26,160
I was pretty much guessing when it came down to it.

146
00:12:26,640 --> 00:12:29,600
So what I was doing was when it hit that first...

147
00:12:29,600 --> 00:12:33,020
I'll go step-by-step with what I did, because it was pretty much as I outlined in the talk.

148
00:12:33,020 --> 00:12:39,540
It hit that first address and would just keep looping and reading and doing a few other operations before jumping back to the start where it read that address again.

149
00:12:39,680 --> 00:12:45,700
And I already knew that that was the correct hardware address because it was at 400000, which is where the hardware addresses are.

150
00:12:46,000 --> 00:12:48,660
So as it was reading, it was literally bit shifting.

151
00:12:48,660 --> 00:12:55,260
What some code can pass to often is shifting values down to hit a certain bit to check them.

152
00:12:55,460 --> 00:12:59,140
And I thought, okay, so it's probably checking for certain bits in some sort of order.

153
00:12:59,660 --> 00:13:01,220
And so I just randomized that.

154
00:13:01,540 --> 00:13:03,160
And then it started trying to read in bytes.

155
00:13:03,160 --> 00:13:04,760
I was loading them into a buffer in RAM.

156
00:13:04,760 --> 00:13:06,620
And I could see this in the emulation.

157
00:13:06,620 --> 00:13:09,740
And I thought, what happens if I start writing my code into it?

158
00:13:09,740 --> 00:13:12,000
So I started writing different operations in.

159
00:13:12,000 --> 00:13:15,920
And there was sort of a staggered approach because I didn't have interrupts, I think.

160
00:13:15,920 --> 00:13:17,560
But for some reason, it wouldn't response right away.

161
00:13:17,560 --> 00:13:19,820
So I gave it a whole list of commands I wanted to run.

162
00:13:19,820 --> 00:13:21,540
And then it had like three of them.

163
00:13:21,540 --> 00:13:23,260
And then it would start pumping out the responses.

164
00:13:23,480 --> 00:13:25,060
So eventually that worked really nicely.

165
00:13:25,060 --> 00:13:26,760
So it was quite cool in the end.

166
00:13:27,660 --> 00:13:29,560
That is really what it looks like.

167
00:13:29,860 --> 00:13:31,600
Yeah, but it's all assumption, essentially.

168
00:13:31,600 --> 00:13:32,280
It's all guessing.

169
00:13:32,280 --> 00:13:33,000
It's all guesswork.

170
00:13:33,000 --> 00:13:34,300
And eventually it gets there.

171
00:13:34,480 --> 00:13:43,000
And I imagine that interacting with those pieces of hardware might allow you to say, okay, this is clearly a memory buffer that's being shared with something else.

172
00:13:43,000 --> 00:13:45,860
That kind of thing, just experience, will just help you with that kind of thing.

173
00:13:45,980 --> 00:13:48,020
Yeah, and I sort of stepped through some of the parts of the code.

174
00:13:48,020 --> 00:13:51,860
So I stepped through because there was that infinite loop that started, which was constantly reading.

175
00:13:51,880 --> 00:13:53,540
And I jumped into there and a few functions in.

176
00:13:53,540 --> 00:13:56,660
And that's where I found the state machine command 0, 1, 2, and 6.

177
00:13:56,760 --> 00:14:02,580
Which were the first commands that the chip would see at the start of a firmware update.

178
00:14:02,580 --> 00:14:03,940
So 0 was a reset.

179
00:14:03,940 --> 00:14:05,780
1 was get some version information.

180
00:14:05,780 --> 00:14:10,440
And 2 was start sending the SHA-1 hash and the signature.

181
00:14:10,460 --> 00:14:14,520
And then command 6 was the secret one, which dumped any memory I wanted, which was correct.

182
00:14:14,520 --> 00:14:17,900
But the fact that that existed was quite surprising.

183
00:14:20,760 --> 00:14:22,300
Yeah, but I mean, it worked out.

184
00:14:22,300 --> 00:14:23,920
It's like being able to find that.

185
00:14:23,960 --> 00:14:29,260
So if you didn't have that command, you briefly mentioned about doing that kind of reversing blind.

186
00:14:29,260 --> 00:14:31,380
You already had the previous version.

187
00:14:31,380 --> 00:14:36,040
You were able to use the knowledge you gained from that first stage to attack later on chip.

188
00:14:36,340 --> 00:14:40,700
If you wanted to go about doing something like this blind, could you?

189
00:14:40,700 --> 00:14:43,260
Would it just be just an enormous amount more effort?

190
00:14:43,260 --> 00:14:45,160
Or is it just not possible?

191
00:14:45,580 --> 00:14:48,380
It probably would have been an enormous amount more effort, yes.

192
00:14:48,380 --> 00:14:53,460
Because I had that bootloader to emulate, and I could make assumptions about the two size values that made it a lot simpler.

193
00:14:53,460 --> 00:14:57,160
It wasn't the full process, but it was helpful enough.

194
00:14:58,180 --> 00:15:04,020
The blind part was very simple in the end, because the bootloader had changed just enough that I could guess anyway.

195
00:15:04,020 --> 00:15:11,520
So I could make inferences about where I'd overwritten the stack and where I'd overwritten the memory, which would have different kinds of responses over the I2C bus.

196
00:15:11,520 --> 00:15:18,960
Because I could get the size of the stack, I could overwrite it all with whatever addresses I wanted, because eventually one of those would be the link register.

197
00:15:19,200 --> 00:15:22,740
And when it jumped in, I literally just would have jumped through them in the same way, essentially.

198
00:15:22,740 --> 00:15:26,560
But it would have been a lot more difficult to find the initial vulnerability, I think.

199
00:15:27,300 --> 00:15:28,020
Fair enough.

200
00:15:28,660 --> 00:15:42,920
So you could potentially use your custom firmware function to re-implement that kind of memory dumping, though, by jumping into that and then dumping everything back out to get the updated firmware version?

201
00:15:44,240 --> 00:15:46,140
Yes, so that's exactly what I did in the end.

202
00:15:46,140 --> 00:15:52,100
So that was my first port of call when I started making the custom firmware, was adding arbitrary reads to the core firmware.

203
00:15:52,100 --> 00:15:55,620
Instead of it being in a bootloader, I made my own custom firmware capable of doing that.

204
00:15:56,240 --> 00:16:08,300
It was a few steps, so I had to essentially find an I2C function I wanted to mess with that worked via NCI, and then modify that so I could send NCI responses with whatever I wanted and override those functions.

205
00:16:08,300 --> 00:16:20,200
So it was a good jumping off point, and then I could modify my exploit to not load data from random addresses to start off the exploit, which was a bit scary when I actually saw what was working in the exploit in the live version.

206
00:16:21,540 --> 00:16:23,440
So we got a question from the channel.

207
00:16:23,780 --> 00:16:31,100
When starting your research, weren't you afraid to find old vulnerabilities on your chip that were already patched since you started on an old phone?

208
00:16:31,360 --> 00:16:34,400
Yes, so I thought it would have been patched, to be honest.

209
00:16:34,800 --> 00:16:42,700
So I started with the Assumption S6, and I wasn't really doing it from a security perspective, which is more of a reverse engineering thing that's fun.

210
00:16:42,840 --> 00:16:52,440
But because they told me they weren't going to patch it because it was so old, which was valid, I thought, I don't think anyone's ever bothered looking at something so innocuous as an NFC chip on a phone.

211
00:16:52,620 --> 00:17:02,000
So I thought, if I bought a later phone, which I was in the market for at the time anyway, I'd be able to find something just the same, and I did, which was excellent.

212
00:17:02,000 --> 00:17:12,960
And it meant that, because there was firmware, there were different chip versions between the two as well, so this is just the latest version, it was likely that all the ones in between were also vulnerable to the same thing.

213
00:17:12,960 --> 00:17:16,100
It wasn't just a one-to-one comparison, which was quite cool.

214
00:17:16,100 --> 00:17:24,880
Do you know if Samsung took the approach that all those middle versions were likely vulnerable as well, and they're only going to be releasing the updated version at this point?

215
00:17:25,020 --> 00:17:34,720
I don't know a huge amount, but I do know which chips are in which phones, so I can assume the ones that are supported by them are going to be updated more than anything, because they do seem very good about updating these things.

216
00:17:34,740 --> 00:17:35,400
Cool.

217
00:17:35,700 --> 00:17:39,540
So we got sort of a comment from someone in the channel.

218
00:17:39,980 --> 00:17:43,080
I really want to understand firmware and boot much more in depth.

219
00:17:43,080 --> 00:17:46,140
Looking for the more established projects can be somewhat overwhelming.

220
00:17:46,140 --> 00:17:50,460
Should I just grab a Pine phone or Pine Time and tinker around old Thinkpads?

221
00:17:50,460 --> 00:17:53,480
What kind of more entry-level paths might you suggest to learn more?

222
00:17:53,520 --> 00:17:54,660
Okay, yeah, excellent.

223
00:17:54,660 --> 00:17:56,920
So it very much depends on which path you want to go through.

224
00:17:56,920 --> 00:18:11,520
If you want to learn into custom ROMs and things on phones and modifying phones in that manner, then yes, something more like a standard Android device, like a Pixel or something, which has the capabilities with custom ROMs and OEM unlocking, is the best port of call.

225
00:18:11,520 --> 00:18:14,100
You can mess with the operating system as you want, learn a lot.

226
00:18:14,100 --> 00:18:22,320
There's a lot of tutorials that people have for things like compiling, things like Lineage OS, which can be modified in certain ways.

227
00:18:22,320 --> 00:18:31,360
For instance, you can unpack the zip files of some of the custom ROMs and then just modify the boot script and things as you want, or add your own things into the system image.

228
00:18:31,360 --> 00:18:32,300
You can add these things.

229
00:18:32,300 --> 00:18:35,200
That's sort of... it's kind of a big question on that side.

230
00:18:35,200 --> 00:18:43,220
If you're looking at learning how to reverse engineer much smaller chips, things like the NFC chip, you should start looking at chipsets like the STM32.

231
00:18:43,680 --> 00:18:50,120
These are probably the most used Cortex-M and ARM-embedded chipsets around.

232
00:18:50,120 --> 00:18:53,160
There's huge numbers of very cheap development boards for them.

233
00:18:53,160 --> 00:18:55,280
And you can write code for them using free tools.

234
00:18:55,280 --> 00:19:00,640
There's also tools like the STM32 Cube, which allows you to set specific pins and configurations.

235
00:19:00,640 --> 00:19:07,160
You can create your own USB device, access the mouse, whatever, in minutes using some of these tools, and just deploy them to the phone.

236
00:19:07,160 --> 00:19:10,800
And that's where you would go if you wanted to start learning about how to develop firmware for these things.

237
00:19:10,800 --> 00:19:15,020
To reverse engineer them, all you need to do is take those binaries and look at how they work more than anything.

238
00:19:15,020 --> 00:19:20,160
Chuck them in EIDR or RADAR or, you know, Ghidra, whichever one you like, and start looking around them.

239
00:19:20,180 --> 00:19:25,320
There's a huge number of really good tutorials about how to do this, but mostly all I can say is just dive in and try things.

240
00:19:25,320 --> 00:19:28,500
And if you get frustrated too much, then you're probably going the right way with it.

241
00:19:33,720 --> 00:19:40,380
I mean, I don't want to tell you how hard it was to find all the addresses and things in the firmware that I reverse engineered for this project.

242
00:19:40,380 --> 00:19:47,040
It took days and days and days for some of them, especially when it came to things like a lot of the functionality was based on interrupts.

243
00:19:47,040 --> 00:19:52,340
And I didn't even know which interrupts were where because there's no documentation for this chip and everything is completely custom to Samsung.

244
00:19:52,440 --> 00:19:58,040
These are really difficult things to come up with, but you can start adding to your knowledge just by doing the most frustrating things you can.

245
00:19:58,040 --> 00:20:02,360
But if you're starting with embedded firmware in that style, start with an STM32 dev board.

246
00:20:02,360 --> 00:20:06,160
You can start with a Raspberry Pi and just start looking at bare metal stuff if you have one available.

247
00:20:06,400 --> 00:20:08,400
There's all sorts of ways to go into it, really.

248
00:20:08,960 --> 00:20:09,780
That's awesome.

249
00:20:09,780 --> 00:20:11,760
That's a great and very thorough answer.

250
00:20:11,760 --> 00:20:12,820
I appreciate that.

251
00:20:13,620 --> 00:20:18,600
Do you believe that Samsung will eventually start using signature verification for downloadable firmware?

252
00:20:19,460 --> 00:20:23,480
So the chip did use signature verification in this instance.

253
00:20:23,520 --> 00:20:29,640
What they should be adding to that rather than modifying the signature verification is encryption on top of that.

254
00:20:29,640 --> 00:20:36,420
So at the moment, you could take the firmware that they've deployed and analyze it in IDA with no problems because there's no encryption whatsoever.

255
00:20:36,420 --> 00:20:42,760
Now, different chips from different manufacturers, even NFC chip ones, are encrypted and signed.

256
00:20:42,760 --> 00:20:45,380
That means you can't reverse engineer them to find any exploits.

257
00:20:45,380 --> 00:20:47,660
You also can't deploy modifications to those firmware.

258
00:20:47,660 --> 00:20:50,360
And that's sort of the way they should be going more than anything.

259
00:20:50,900 --> 00:20:58,060
Do you think that that's actually a good way making it harder for reverse engineers to inspect the actual firmware?

260
00:20:58,360 --> 00:21:00,960
It's kind of a catch-22 on that point, isn't it?

261
00:21:00,960 --> 00:21:02,660
I see where you're coming from.

262
00:21:02,660 --> 00:21:16,880
The problem is, I think, especially with a threat model such as this where the only real reason someone would reverse engineer this is to make a cool NFC hacking tool rather than to damage other people, is that if you really wanted to stop people doing this,

263
00:21:16,880 --> 00:21:22,560
which I don't agree with on a moral level, but I would say encrypting it and preventing them from doing that is the best way to go.

264
00:21:22,560 --> 00:21:36,900
Because then what they'll have to go for is both guessing how the bootloader works and also guessing what things like secret vendor NCI functions are available, which aren't necessarily all vulnerable to things, but are available and people can brute force through them.

265
00:21:39,100 --> 00:21:41,300
How much time did you spend on this project?

266
00:21:42,060 --> 00:21:43,220
A lot.

267
00:21:44,240 --> 00:21:47,180
I feel like my boss has probably asked me that in the chat.

268
00:21:47,460 --> 00:21:56,680
So the project started off at the end of the last DEF CON, actually, which is when I was sitting in my hotel room looking at the original firmware.

269
00:21:56,740 --> 00:21:58,980
And then I just did it in little bits over time more than anything.

270
00:21:58,980 --> 00:22:00,640
It wasn't a solid amount of time.

271
00:22:00,640 --> 00:22:06,200
When it got to the point where I had a signature bypass on the Samsung S9 is when I really started focusing quite a lot of time away.

272
00:22:06,200 --> 00:22:13,920
So it took me about three weeks, not every day, but three weeks in total, to go through everything and start implementing every single part of that firmware.

273
00:22:13,920 --> 00:22:24,220
Because I was having to look through the entirety of the firmware image, which had no documentation whatsoever, nothing to work with, no strings at all, no function references that you'd get in that.

274
00:22:24,220 --> 00:22:25,540
It's literally just raw code.

275
00:22:25,540 --> 00:22:27,000
It's all guesswork.

276
00:22:27,180 --> 00:22:38,260
And that's sort of why it takes such a long-winded amount of time compared to some more desktop-level projects where you can reverse engineer, say, an application quite a lot more easily, I'd say.

277
00:22:41,120 --> 00:22:47,560
So other than the challenge of doing the reverse engineering and figuring things out, did you have a particular use case for the end product?

278
00:22:47,660 --> 00:22:51,520
Like a sneaky version of the Proxmark or something?

279
00:22:51,560 --> 00:22:53,920
A sneaky version of the Proxmark is exactly right.

280
00:22:53,920 --> 00:22:55,540
Yes, that's very true.

281
00:22:55,540 --> 00:22:57,840
I do have Proxmarks and I really like them.

282
00:22:57,840 --> 00:23:02,660
So I've got one right next to me, which I actually use for the reverse engineering of this project really heavily for the NFC side.

283
00:23:02,760 --> 00:23:10,840
Because it's so lax on things like the bit verification, the parity checking, it meant that I could build up the project really simply from that.

284
00:23:10,840 --> 00:23:14,140
Now, essentially, yes, I was trying to make a fakie Proxmark.

285
00:23:14,140 --> 00:23:17,300
And part of that was passive NFC sniffing.

286
00:23:17,300 --> 00:23:27,120
So one of the tools on a Proxmark is this thing where you can sniff high-frequency communication between the reader and a tag.

287
00:23:27,120 --> 00:23:29,700
This is used for breaking authentication and things.

288
00:23:29,700 --> 00:23:36,900
I wanted to add that in so you could go up someone with a phone and stick it over them as they're trying to open a door or something by accident and pick up the communication.

289
00:23:37,420 --> 00:23:43,340
Now , that feature is almost done, but it's quite complicated now because you have to switch between hardware registers.

290
00:23:43,340 --> 00:23:48,060
Now, there's one block of hardware registers that I mentioned in the talk, and that handles every single aspect of NFC.

291
00:23:48,060 --> 00:23:51,420
So that's the reader part and the acting like a tag part.

292
00:23:51,420 --> 00:23:53,860
So you have to switch between these constantly in order to get that data.

293
00:23:53,860 --> 00:23:59,260
And it sort of works, but until I've got that full functionality in place, it's really not replacement for the Proxmark.

294
00:24:00,000 --> 00:24:01,780
That was the goal, yes.

295
00:24:02,020 --> 00:24:02,760
Yes.

296
00:24:03,500 --> 00:24:04,600
That's really sneaky.

297
00:24:04,600 --> 00:24:05,700
I really like it.

298
00:24:08,960 --> 00:24:12,780
Why do you think so little has been done for...

299
00:24:12,780 --> 00:24:17,360
Why do you think so little has been reverse-engineered from a Qualcomm baseband?

300
00:24:17,360 --> 00:24:18,480
Is it more challenging?

301
00:24:19,420 --> 00:24:20,160
I'd say yes.

302
00:24:20,160 --> 00:24:24,380
I've looked at some aspects of Qualcomm as well, just from interest.

303
00:24:24,800 --> 00:24:32,240
I've looked at several different aspects of things, like how their bootloaders work, how they have the Qualcomm emergency download mode and all these sorts of features.

304
00:24:32,240 --> 00:24:34,640
They've also got the baseband, which is highly complex.

305
00:24:34,800 --> 00:24:40,760
The problem is you start looking into them and then you realize how much of a can of worms you've opened with reverse engineering.

306
00:24:40,760 --> 00:24:45,440
This project, by comparison to something like a Qualcomm chip, is very simplistic.

307
00:24:45,440 --> 00:24:48,900
It's one very small 12K firmware to look through.

308
00:24:48,900 --> 00:24:53,040
Whereas when you get to the Qualcomm baseband, which is going to be hugely complex, it's just a huge project.

309
00:24:53,040 --> 00:24:57,320
It's better suited to a multi-person team rather than just me on my own.

310
00:24:57,540 --> 00:25:03,140
Is it largely the size of the firmware on Qualcomm chips that is the limiting factor?

311
00:25:05,100 --> 00:25:10,960
Is the Snapdragon still a natural ARM core or is it something Qualcomm specific?

312
00:25:11,080 --> 00:25:13,300
It's an ARM64 core, I believe, at the moment.

313
00:25:15,660 --> 00:25:21,340
I know there's been quite a lot of research on Qualcomm in general on their chipsets because it is the focus of the phone.

314
00:25:21,340 --> 00:25:27,980
That's why I chose a chipset that was a side aspect of a phone because I thought no one would bother to look at them.

315
00:25:27,980 --> 00:25:32,220
And they haven't with this one, so I feel like the vulnerability I found would probably be found quite quickly.

316
00:25:32,440 --> 00:25:38,420
But yes, when it comes to the Qualcomm side of things, it's just such a hugely complex chipset.

317
00:25:38,420 --> 00:25:47,960
There's so much to look at and so many potentials for bugs in different places that, like any chipset of that complexity, it would take a team and quite a lot of time to find something, I think.

318
00:25:47,960 --> 00:25:49,620
Yeah, fair enough.

319
00:25:51,800 --> 00:25:55,680
It looks like we got some potential questions coming back in.

320
00:25:56,480 --> 00:26:03,720
Yeah, is there any part of the talk that you omitted because you just ran out of time?

321
00:26:04,820 --> 00:26:06,240
Yes, quite a lot.

322
00:26:06,240 --> 00:26:14,160
So I wanted to get into more details about the reverse engineering side, which was, considering it was only half the talk, was the most time-consuming part of the topic.

323
00:26:14,180 --> 00:26:19,860
But I found that it was quite dull to talk about because it's literally me going, oh, I thought this might be this.

324
00:26:19,860 --> 00:26:20,920
I thought this might be this.

325
00:26:20,920 --> 00:26:26,300
For instance, I mentioned interrupts earlier and how these work on Cortex-M chips.

326
00:26:26,300 --> 00:26:32,140
There's a big table at the start of the firmware, which includes the reset vector, which is where the chip starts from, the start of the stack.

327
00:26:32,140 --> 00:26:34,380
And then it has a bunch of interrupts for things like the hardware and stuff.

328
00:26:34,380 --> 00:26:38,540
Now, on top of this, it also has interrupts for more complex hardware, like the NFC.

329
00:26:38,660 --> 00:26:43,760
So one thing was all the NFC tag mode stuff ran off one single interrupt.

330
00:26:43,760 --> 00:26:45,520
So it hit that interrupt and would jump to some code.

331
00:26:45,520 --> 00:26:51,900
That meant the code wasn't directly referenced by anything and actually didn't disassemble when I first looked at the firmware.

332
00:26:52,160 --> 00:26:58,680
What this meant was what I started off doing was overriding that interrupt in the first place, but I had to know where it was.

333
00:26:58,740 --> 00:27:10,300
So I found the select function that I mentioned in the talk and then went back from there, found that it had no function reference, thought maybe it's an interrupt, and then searched that value, which was then found in a table, things like that.

334
00:27:10,300 --> 00:27:18,740
These are things that are very valuable from a reverse engineering perspective, but they're very boring to talk about in a talk, I think, which is probably bad because I just spoke about them for about three minutes.

335
00:27:18,760 --> 00:27:20,100
No, no, no, no, it's fine.

336
00:27:20,100 --> 00:27:21,640
We've got time and people are...

337
00:27:21,640 --> 00:27:22,660
Like, I'm interested.

338
00:27:22,660 --> 00:27:28,600
I didn't know that things pointed exclusively by the interrupt table wouldn't normally decompile.

339
00:27:29,460 --> 00:27:30,320
Not unless it...

340
00:27:30,320 --> 00:27:38,520
Well, Kahidra is quite good at this, I've found, because it understands Cortex-M, whereas Ida sort of is quite hands-off when it comes to things like Cortex-M chips.

341
00:27:38,520 --> 00:27:41,700
It allows you to work it out for yourself, essentially, a lot of the time.

342
00:27:41,700 --> 00:27:43,060
Fair enough.

343
00:27:43,400 --> 00:27:49,220
Which would you say are other interesting targets, like not-complex-and-wildly-used chips?

344
00:27:50,880 --> 00:28:00,240
What I would recommend is something that I work with quite heavily, which is embedded IoT chips, which are not custom chipsets in the first place.

345
00:28:00,240 --> 00:28:04,060
They're usually STM cores or EFM cores and these sort of things.

346
00:28:04,260 --> 00:28:10,040
Why these are interesting is they're a good jumping-off point to learn these things because you're not guessing, you've got documentation in place.

347
00:28:10,040 --> 00:28:15,180
But also people implement bootloaders and things, which you can then try and break.

348
00:28:15,180 --> 00:28:26,400
Now , I did a talk at 44Con a while ago, which is about breaking one of these bootloaders by breaking the encryption mechanisms on the firmware update by dumping RAM off an STM32 chip as it was doing the firmware update.

349
00:28:26,400 --> 00:28:34,200
Things like this are things you shouldn't start looking at because there's millions of these IoT devices out there with all sorts of different chipsets, and they're the really fun targets.

350
00:28:34,200 --> 00:28:40,660
When it comes to custom chips like this, you're really not going to find much information online about them just because they're hidden away.

351
00:28:40,660 --> 00:28:47,120
There's about two links if you search for some of these Samsung chips online, apart from their accreditations from the NFC forum.

352
00:28:47,240 --> 00:28:52,720
So, finding these chips in the first place is probably your greatest goal when you're starting off something like this, more than anything.

353
00:28:53,660 --> 00:28:54,580
Cool.

354
00:28:55,040 --> 00:29:04,460
And someone wants to know if the firmware was based on an RTOS or more along those lines, which is like a standard raw microcontroller target.

355
00:29:04,620 --> 00:29:05,840
Yep, great question.

356
00:29:05,840 --> 00:29:13,580
So, you often find embedded projects like this using RTOS like VxWorks or FreeRTOS or Ecos and these sorts of things.

357
00:29:13,740 --> 00:29:18,860
Now, they weren't because it was literally a straight firmware that they had compiled.

358
00:29:18,860 --> 00:29:19,620
They had their own tool.

359
00:29:19,800 --> 00:29:22,080
Presumably, they had their own tool chains at Samsung.

360
00:29:22,080 --> 00:29:23,120
They compiled it up.

361
00:29:23,120 --> 00:29:33,600
They had to have everything sorted as they wanted to and laid out as they wanted to because they had their firmware as they wanted.

362
00:29:33,600 --> 00:29:38,240
And RTOSs are usually built for certain chipsets or certain families of chipsets or certain styles.

363
00:29:38,240 --> 00:29:40,880
It just wasn't really meant to be on that point.

364
00:29:40,880 --> 00:29:44,520
Often, these RTOSs have a lot of overhead as well, like they include debug strings, for instance.

365
00:29:44,940 --> 00:29:55,280
VxWorks are the table that's, I think, can be compiled out, but it's at the end of pretty much all their firmware, which includes all the function names, which you can then reference back to all the functions in the firmware, which saves you a lot of time reverse engineering,

366
00:29:55,280 --> 00:29:58,880
but it's also, from a security perspective, quite bad.

367
00:29:59,300 --> 00:30:00,280
It didn't use an RTOS.

368
00:30:00,280 --> 00:30:01,640
It was just a straight running firmware.

369
00:30:01,640 --> 00:30:03,800
They'd put their own function calls in and all that sort of thing.

370
00:30:04,380 --> 00:30:09,280
Other chipsets I've looked at that are similar or custom often implement their own custom RTOSs for this.

371
00:30:09,280 --> 00:30:10,480
But in this case, there was none used.

372
00:30:10,480 --> 00:30:14,560
It was literally just running as it needed to and relying on interrupts more than threads.

373
00:30:16,280 --> 00:30:16,900
Awesome.

374
00:30:16,900 --> 00:30:18,580
That was a great answer, by the way.

375
00:30:18,580 --> 00:30:19,340
Thank you.

376
00:30:21,960 --> 00:30:27,900
Well, it looks like we are running out of questions and we're just about the end of our time anyways.

377
00:30:28,400 --> 00:30:35,860
Is there any additional links you want to share or code or anything like that that you want to get out there?

378
00:30:35,860 --> 00:30:43,560
Yeah, so if we're doing links and that sort of thing, you can follow me at Twitter at Iscuri1.

379
00:30:43,560 --> 00:30:48,600
So that's my username and then one at the end because I didn't get the one without the number first.

380
00:30:49,020 --> 00:30:51,420
For GitHub, it's just Iscuri.

381
00:30:51,460 --> 00:31:01,460
And I should be putting out a blog in the next couple of days outlining all of these details as well as linking to the YouTube video of this at pentestpartners.com, which is my company website.

382
00:31:01,460 --> 00:31:05,340
So definitely feel free to have a look if you want the really nitty-gritty technical details.

383
00:31:05,860 --> 00:31:06,500
Awesome.

384
00:31:07,080 --> 00:31:09,480
Well, thank you so much for joining us for this QA session.

385
00:31:10,240 --> 00:31:11,460
It's been great talking to you.

386
00:31:11,460 --> 00:31:17,220
Thank you for providing content to our virtual DEF CON safe mode and have a nice day.

387
00:31:17,260 --> 00:31:17,700
You too.

388
00:31:17,700 --> 00:31:18,720
Thank you very much, guys.