1
00:00:28,680 --> 00:00:29,860
All right.

2
00:00:30,020 --> 00:00:39,860
We are here with our next QA session with Jiska and Francesco for the Spectra wireless, new wireless escalation targets talk.

3
00:00:40,180 --> 00:00:43,280
Do you guys want to give yourself a little bit of an intro?

4
00:00:43,980 --> 00:00:45,520
Jiska, do you want to start?

5
00:00:48,200 --> 00:00:50,440
Yeah, okay, then I'll start.

6
00:00:50,620 --> 00:00:59,680
I'm a postdoc at TU Darmstadt in Germany at the Secure Mobile Networking Lab, and I've been, yeah, recently working a lot with Bluetooth.

7
00:00:59,680 --> 00:01:07,260
Before, I've been working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication.

8
00:01:10,440 --> 00:01:12,740
Hi, I'm Francesco Gringoli.

9
00:01:13,020 --> 00:01:21,540
I'm an assistant professor at the University of Brescia and have been playing with wireless technologies in the last 15 years.

10
00:01:21,540 --> 00:01:22,920
That's great.

11
00:01:23,020 --> 00:01:24,520
Thank you both.

12
00:01:24,860 --> 00:01:30,520
So, I mean, I'm going to start off with some a little bit simpler questions.

13
00:01:30,540 --> 00:01:35,920
So, you talked a lot about this new vulnerability that's between the two cores.

14
00:01:35,920 --> 00:01:37,820
Is this something that can be patched?

15
00:01:38,500 --> 00:01:39,820
It's hard to say.

16
00:01:39,820 --> 00:01:48,040
So, there are parts that definitely are not patchable because they are for the performance improvements.

17
00:01:48,040 --> 00:02:01,440
So, the stuff that goes, like, between the U-code that Francesco modified and the communication with the serial interface on the Bluetooth side, this is something that you need, at least if you don't want to lose performance.

18
00:02:01,440 --> 00:02:04,160
And this is also all in hardware, I guess.

19
00:02:04,160 --> 00:02:17,560
So, this is something, like, in a future chip, it might be changed in a way that you can infer less information, but it's probably not patchable in that sense or not easily patchable.

20
00:02:17,560 --> 00:02:22,940
The shared RAM is something that they should remove, but I didn't see them remove it yet.

21
00:02:22,940 --> 00:02:29,560
And I don't know if they can actually unmap it in the generation of chips or if this also needs a new generation of chips.

22
00:02:29,660 --> 00:02:32,680
I didn't see the shared RAM actually being used anywhere.

23
00:02:32,680 --> 00:02:34,740
So, that's the weird thing, right?

24
00:02:34,740 --> 00:02:37,280
The shared RAM exists.

25
00:02:37,420 --> 00:02:38,040
Yeah.

26
00:02:38,040 --> 00:02:44,500
So, it exists, but it's really not being used for anything or at least for nothing that I could see.

27
00:02:45,640 --> 00:02:50,580
So, this is the thing that they should remove, because it's the most dangerous part.

28
00:02:51,660 --> 00:02:56,180
So, we got a question from Cooper Q, and this was actually something that I was interested in as well.

29
00:02:56,180 --> 00:03:06,380
You mentioned LTE is on some of the same frequencies, and I know that there are some all-in-one chips that include LTE in addition to their Bluetooth and wireless stacks.

30
00:03:06,380 --> 00:03:14,190
Have you tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio?

31
00:03:15,100 --> 00:03:16,220
Not yet.

32
00:03:16,220 --> 00:03:20,800
So, what we tried is we tried to see if this connection exists at all.

33
00:03:20,800 --> 00:03:28,980
And I can tell that in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS something.

34
00:03:29,480 --> 00:03:35,820
And then I also took some logs on an iPhone and like iPhone 7 and newer.

35
00:03:35,820 --> 00:03:39,780
And on those devices, what you can see is that there are HCI commands.

36
00:03:39,780 --> 00:03:49,200
So, that's from the operating system Bluetooth daemon to the chip that include MWS, which is the configuration for the LTE coexistence.

37
00:03:49,200 --> 00:03:51,340
So, they are definitely using it.

38
00:03:51,340 --> 00:03:54,520
I just didn't try to exploit it yet.

39
00:03:55,800 --> 00:03:56,400
Cool.

40
00:03:56,400 --> 00:03:57,180
Fair enough.

41
00:03:58,400 --> 00:04:03,660
This one, this one's one I'm going to, I'm going to have to read verbatim because it's a little out of context.

42
00:04:03,660 --> 00:04:05,400
I don't know what it was.

43
00:04:05,400 --> 00:04:07,160
In the talk, you mentioned Frankenstein.

44
00:04:07,160 --> 00:04:08,680
Can you talk a little bit about it?

45
00:04:10,880 --> 00:04:11,360
Yeah.

46
00:04:11,360 --> 00:04:13,320
So, that's another paper.

47
00:04:13,320 --> 00:04:21,420
So, actually, the main work of this is from Jan, who is not here, but that's one of my former students.

48
00:04:21,860 --> 00:04:28,720
And he made some snapshotting for Bluetooth chips of Broadcom and then also emulation.

49
00:04:28,940 --> 00:04:41,220
And the interesting part about this emulation is that it includes thread switches and a virtual modem so that you can attach it to your Linux host and you actually can start scanning for devices and get back random devices.

50
00:04:41,220 --> 00:04:45,920
So, you have like a full stack emulation in that sense.

51
00:04:46,820 --> 00:04:51,880
And this is something that we are going to present next week at USENIX security.

52
00:04:52,860 --> 00:04:54,900
The paper is already public.

53
00:04:55,080 --> 00:04:59,420
And also, the software is on GitHub since a while.

54
00:04:59,620 --> 00:05:00,440
Cool.

55
00:05:00,440 --> 00:05:04,340
Could you send me links for that information?

56
00:05:04,460 --> 00:05:06,860
You can do it after the Q&A.

57
00:05:06,880 --> 00:05:11,700
I just want to be able to drop it in track one for anyone that's interested in following up with that information.

58
00:05:12,440 --> 00:05:23,880
So, anyone that's paying attention, if you want the extra information, the links to the paper and everything else will be in the track one room as soon as this is over.

59
00:05:25,420 --> 00:05:28,500
Okay, on to the next question.

60
00:05:28,860 --> 00:05:38,420
So, regarding the CVE-2019-15063 denial of service Bluetooth Wi-Fi exploit, was that the specific one that you guys were working on?

61
00:05:38,420 --> 00:05:41,040
I don't remember CVE numbers off the top of my head.

62
00:05:41,380 --> 00:05:46,280
Anyways, the question is, how are you manipulating the register that results in crashes?

63
00:05:46,280 --> 00:05:47,800
Are you physically accessing the chipset?

64
00:05:47,800 --> 00:05:49,180
Or can this be done remotely?

65
00:05:50,200 --> 00:05:53,460
Ah, so yeah, that's, so it's kind of two stages, right?

66
00:05:53,460 --> 00:05:57,220
So, you first need some remote code execution, either on Wi-Fi or on Bluetooth.

67
00:05:57,220 --> 00:05:59,540
And then you could write to the register.

68
00:05:59,760 --> 00:06:16,240
And what we do for debugging is actually, so for Bluetooth, when we modify Bluetooth, then we have internal blue, which is a framework that supports the vendor specific commands from Broadcom to manipulate the Bluetooth part.

69
00:06:16,240 --> 00:06:22,540
And for Wi-Fi, there's another thing next month, I think Francesco can tell a bit more about next month.

70
00:06:22,840 --> 00:06:35,460
Yeah, it's a project that allows people to do binary patching of the wireless driver, so that you can modify and then add functionalities.

71
00:06:35,460 --> 00:06:42,840
But of course, this is not the remote execution, it's just for modifying the binary image without having access to the source code, which is a proprietary.

72
00:06:43,420 --> 00:06:52,720
And this allows to modify both the ARM, the ARM core, and also the U-code part that is the lowest part accessible in the hardware.

73
00:06:53,080 --> 00:06:54,280
That's really cool.

74
00:06:54,280 --> 00:06:58,820
Is that a tool that is going to get released like upcoming?

75
00:06:58,820 --> 00:07:01,160
Is that part of the Usenix talk?

76
00:07:01,400 --> 00:07:06,580
No, next one is, I just pasted it also in our private chat, so you can copy it later.

77
00:07:06,640 --> 00:07:09,660
Next one is something, since when is it public?

78
00:07:09,660 --> 00:07:11,940
I don't know, 2016, 17?

79
00:07:12,140 --> 00:07:12,700
Yeah.

80
00:07:14,080 --> 00:07:24,260
And the interesting part about next month is so next month was just built to actually modify the Wi-Fi firmware without the intention to really hack it.

81
00:07:24,260 --> 00:07:29,540
So like, more for sending arbitrary signals, turning your smartphone into an SDR.

82
00:07:29,540 --> 00:07:40,500
And the interesting part here is that back then in 2017, actually, Google Project Zero and Itay Eisenstein used this knowledge to dig a bit further into the Broadcom chips.

83
00:07:40,500 --> 00:07:50,080
So like Broadcom and stuff like this was also not only but also based on next month, and also later work, they always use next month.

84
00:07:50,200 --> 00:07:53,960
So that's a very interesting thing about this.

85
00:07:54,620 --> 00:08:10,480
And then for the Bluetooth stuff, we said like, well, how do you guys go about researching phones, since for the most part, everything seems to be closed source?

86
00:08:10,580 --> 00:08:16,060
They're asking to talk about like the research process, like if you were going to try and exploit a new phone?

87
00:08:17,640 --> 00:08:20,720
Ah, yeah, so that's, that's the thing.

88
00:08:20,720 --> 00:08:36,640
So the first part is, I mean, if you don't have, already have a working over the air exploit, which is hard to get, especially if you don't have the ROM of a device and so on, even if you had an exploit, like getting it working on a new device would be hard.

89
00:08:37,260 --> 00:08:42,260
So usually we start with a rooted smartphone, or a jailbreak.

90
00:08:43,240 --> 00:08:46,400
Or, I mean, also MacBooks have Broadcom chips.

91
00:08:46,460 --> 00:08:48,320
So and there you are already root.

92
00:08:49,140 --> 00:08:50,860
So it depends a bit.

93
00:08:51,440 --> 00:08:53,840
And then we would dump the ROM.

94
00:08:54,060 --> 00:08:57,680
And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the same.

95
00:08:57,960 --> 00:09:00,940
And for Wi Fi, the ROM also contains the U code.

96
00:09:00,940 --> 00:09:03,580
And the U code is the thing that runs in the D11 core.

97
00:09:03,580 --> 00:09:08,420
So what Francesco modifies, and for me, it's more the Bluetooth firmware.

98
00:09:09,820 --> 00:09:14,040
And then it's very annoying, because like the stuff is still without any symbols.

99
00:09:14,040 --> 00:09:22,040
And especially Bluetooth also doesn't have any debug strings, the U code doesn't have any debug strings, the Wi Fi firmware has a few debug strings.

100
00:09:22,600 --> 00:09:28,980
And since this is like, so even the memory layout is somewhat unknown, and you need to get it and so on.

101
00:09:28,980 --> 00:09:32,520
And because of this really horribly loads into IDA.

102
00:09:32,680 --> 00:09:35,060
So it really looks ugly.

103
00:09:35,340 --> 00:09:36,700
Yeah, fair.

104
00:09:36,900 --> 00:09:42,520
And I think Francesco, for you, it's even the case that you get new instructions, right?

105
00:09:42,520 --> 00:09:49,580
Yes, for the U code, there is no actually corresponds between the U code and the any known CPU.

106
00:09:49,720 --> 00:10:02,400
So we had to do this reverse engineering for understanding the meaning of these instruction set, and then adding instructions, because Broadcom, during the years, added new instructions.

107
00:10:02,540 --> 00:10:13,140
And yeah, the reason this was very difficult, because it's not ARM that you compile or disassemble, but you have to develop your own tool chain for this.

108
00:10:13,980 --> 00:10:24,460
So what helped is that Broadcom didn't change much the platform, since they introduced it 15 years ago.

109
00:10:24,460 --> 00:10:26,520
So they are additionally adding instructions.

110
00:10:26,520 --> 00:10:31,560
And also what helps is that the U code is very short is less than 64 kilobytes.

111
00:10:33,640 --> 00:10:39,780
Have you either of you looked into any of the newer, like mesh Bluetooth protocols?

112
00:10:40,900 --> 00:10:41,840
Bluetooth mesh.

113
00:10:41,840 --> 00:10:47,840
So a colleague of mine did that Lars, and he looked into the friendship together with a few other people in our team.

114
00:10:47,840 --> 00:10:50,900
So it's so yeah, we did it in our team.

115
00:10:50,900 --> 00:10:53,100
But the mesh is not really interesting.

116
00:10:53,100 --> 00:10:55,620
I mean, it's just using Bluetooth LE advertisements.

117
00:10:55,620 --> 00:11:01,880
So from a, at least from a lower level perspective, it's nothing special.

118
00:11:01,880 --> 00:11:05,120
I mean, of course, implementations on top are interesting then.

119
00:11:05,120 --> 00:11:08,760
But I mean, I do a lot of lower layer stuff.

120
00:11:09,660 --> 00:11:19,500
He just showed that the encryption and so on in the, in the friendship of groups is broken, and Bluetooth SICK send funny responses.

121
00:11:19,500 --> 00:11:21,500
Of course it is.

122
00:11:23,240 --> 00:11:33,080
Someone else is shouting out that a lot of your and related work on BLE is also available as pre prints from YSEC 2020.

123
00:11:33,860 --> 00:11:36,200
And they also threw through a link in there.

124
00:11:36,200 --> 00:11:37,660
I just wanted to shout that out.

125
00:11:37,900 --> 00:11:40,800
Francesco also has done stuff with Bluetooth sniffing, right?

126
00:11:40,800 --> 00:11:42,400
You've built a Bluetooth sniffer.

127
00:11:42,540 --> 00:11:57,040
Yeah, this real time sniffer using a software defined radio for capturing all the channels at the same time and GPU for decoding and brute forcing lowest address part address and low energy session ID.

128
00:11:57,040 --> 00:12:02,260
Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff.

129
00:12:02,260 --> 00:12:11,120
Is there like a minimum requirements for the SDR hardware to do that level of sniffing and for Bluetooth?

130
00:12:13,060 --> 00:12:18,200
Well, if you have SDR that can sniff 80 megahertz is better.

131
00:12:18,200 --> 00:12:26,280
But for sniffing Bluetooth classic, we demonstrated that it's enough to capture only 16 channels out of 80.

132
00:12:26,280 --> 00:12:34,560
Then you can also use one of these cheap SDR like, like Hacker F or Blader F.

133
00:12:34,560 --> 00:12:42,840
So you do not need to buy a very expensive 1000 euro 80 megahertz, but you can buy one of these for 100 bucks.

134
00:12:43,840 --> 00:12:44,800
That's awesome.

135
00:12:44,800 --> 00:12:45,700
It should work.

136
00:12:45,700 --> 00:12:47,260
Yeah, accessible hacking.

137
00:12:47,260 --> 00:12:48,340
It's nice.

138
00:12:49,380 --> 00:12:56,560
Got one person asking, do you think Broadcom is relying a little bit too much on security through obscurity with some of these chips?

139
00:12:58,500 --> 00:13:02,280
I mean, so what you can actually see, and that's an interesting development.

140
00:13:02,280 --> 00:13:10,580
So on the first bug that Jan discovered with Frankenstein is one in the enhancing viral response.

141
00:13:10,800 --> 00:13:17,360
And when he submitted that one, they said, we already know the bug, and we just didn't find it anywhere.

142
00:13:17,360 --> 00:13:21,740
And then I got like the newest Samsung Galaxy S10e and extracted the ROM.

143
00:13:21,740 --> 00:13:26,700
And this one actually had a patch and it had a compile date of April 2018.

144
00:13:26,700 --> 00:13:31,780
And that also means like they cannot change the ROM, so they cannot tell us lies about the ROM.

145
00:13:31,900 --> 00:13:33,600
And we reported it afterwards.

146
00:13:33,600 --> 00:13:36,720
So that actually means they knew it before.

147
00:13:37,320 --> 00:13:40,480
But, and now that's the interesting part of the story.

148
00:13:41,140 --> 00:13:48,620
They didn't patch it backwards in the older devices because it was not publicly known as a bug and you could easily unroll the patches.

149
00:13:49,820 --> 00:13:59,260
Now, the thing is, they definitely increased the security, I would say, after the bugs in 2017 were public.

150
00:13:59,260 --> 00:14:03,380
So, I mean, it took them a year probably to do some pen testing and so on.

151
00:14:03,380 --> 00:14:07,420
But you can see like 2017, the first public incidents happened.

152
00:14:07,660 --> 00:14:12,500
2018, the first kind of secret patches make it into the firmware.

153
00:14:12,500 --> 00:14:17,300
And also they started using like, I don't know, stuff like secondaries.

154
00:14:17,300 --> 00:14:18,680
They didn't have it before.

155
00:14:19,000 --> 00:14:22,820
So this is things that now are going into the firmware.

156
00:14:22,820 --> 00:14:24,780
It's still not like super perfect and everything.

157
00:14:24,780 --> 00:14:26,940
It's still, of course, closed source.

158
00:14:26,940 --> 00:14:31,340
But I mean, most firmware in wireless chips is closed source.

159
00:14:31,340 --> 00:14:31,560
Yeah.

160
00:14:32,560 --> 00:14:35,320
So at least they are trying to work on it.

161
00:14:35,520 --> 00:14:40,700
And I think they are there on that, like security by obscurity doesn't really work.

162
00:14:41,240 --> 00:14:42,180
Fair enough.

163
00:14:44,220 --> 00:14:51,060
So someone is asking where people could find the source code for that Bluetooth sniffer.

164
00:14:54,230 --> 00:14:55,190
Francesco, I think that's it.

165
00:14:55,190 --> 00:14:57,110
Yeah, I can send you.

166
00:14:57,110 --> 00:14:58,590
Yeah, I can send you a link.

167
00:14:58,590 --> 00:15:01,690
If you send me a link, I will post that with everything else.

168
00:15:02,530 --> 00:15:03,330
Yeah.

169
00:15:05,710 --> 00:15:07,210
And another one.

170
00:15:07,210 --> 00:15:14,690
Do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or interoperability between implementations too difficult to bridge?

171
00:15:15,030 --> 00:15:21,870
So I think for Wi-Fi, it's hard because for most stuff, you need to actually join an access point or something like this.

172
00:15:21,870 --> 00:15:24,350
But for Bluetooth, you have this master slave mode.

173
00:15:24,350 --> 00:15:29,250
So you can actually have a device like a smartphone is usually capable of being master and slave.

174
00:15:29,310 --> 00:15:34,750
Some like cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master.

175
00:15:34,750 --> 00:15:43,010
But if you can be slave and master, then you can be part of this, let's say, network and distribute the malware.

176
00:15:44,610 --> 00:15:50,170
And I think there is, let's say, a sufficient fraction of popular devices.

177
00:15:50,170 --> 00:15:56,950
So it depends if it's in the operating system, then it would have to be like compatible iPhones or something.

178
00:15:56,950 --> 00:16:00,470
And I mean, if you just there's not much diversity in iPhones.

179
00:16:00,470 --> 00:16:06,470
So if you just take like the top selling iPhones or something that also would work on the chip base.

180
00:16:06,470 --> 00:16:08,350
On Android, you have more diversity.

181
00:16:08,350 --> 00:16:16,510
But still, if you would say you just pick the top Samsung and Galaxy, and maybe the pixels or something.

182
00:16:17,630 --> 00:16:19,250
Yeah, that could work.

183
00:16:19,250 --> 00:16:25,530
So Jan actually uncovered vulnerability in the Android Bluetooth daemon.

184
00:16:25,530 --> 00:16:27,670
And that one would have been vulnerable.

185
00:16:27,670 --> 00:16:29,730
And it was fixed in February.

186
00:16:30,550 --> 00:16:31,370
I mean, still, yeah.

187
00:16:31,370 --> 00:16:35,630
So you couldn't infect like 100% of devices.

188
00:16:36,020 --> 00:16:41,710
Considering that you have your Bluetooth on and walk around and so on, that would be a threat.

189
00:16:41,930 --> 00:16:46,870
So the reason why I think people wouldn't build it is how do you control it?

190
00:16:46,870 --> 00:17:00,050
Because then you need to have some communication over the internet or something like how do you do like a command and control server for Bluetooth form in a way that is like stealthy and really, I don't know.

191
00:17:00,050 --> 00:17:14,870
So I think it's really more the bigger threat is definitely taking over nearby devices or like hacking someone or like going next to an office train station somewhere where you know, like interesting people are and taking over their devices.

192
00:17:14,870 --> 00:17:21,090
But I think even if it's vulnerable, I think this is nothing that people would build.

193
00:17:21,270 --> 00:17:23,910
But I mean, maybe someone builds it someday.

194
00:17:23,910 --> 00:17:27,870
So I won't build it because, well, I wouldn't.

195
00:17:27,870 --> 00:17:30,590
But I mean, maybe someone is crazy enough to do this, right?

196
00:17:30,670 --> 00:17:31,970
It's just true.

197
00:17:31,970 --> 00:17:37,350
I mean, you could potentially just do it without a financial motivation, just to see if it works or something.

198
00:17:37,570 --> 00:17:38,150
Yeah.

199
00:17:38,890 --> 00:17:41,970
So switching gears just a little bit.

200
00:17:42,570 --> 00:17:44,570
Did you guys report this to vendors?

201
00:17:44,570 --> 00:17:46,530
Like how was how did that communication like turn out?

202
00:17:46,530 --> 00:17:47,670
Was it positive?

203
00:17:47,770 --> 00:17:48,530
Was it negative?

204
00:17:48,530 --> 00:17:49,630
Was it?

205
00:17:50,350 --> 00:17:51,170
Tell me.

206
00:17:51,870 --> 00:17:58,670
Yeah, so the very first report about this denial-of-service was in August last year.

207
00:17:58,670 --> 00:18:00,230
So that's like a year ago.

208
00:18:00,270 --> 00:18:04,450
And I think they didn't really take it serious because it was just denial-of-service, right?

209
00:18:04,450 --> 00:18:10,350
And even if you have denial-of-service with an operating system reboot, it's like nothing that you could really control, right?

210
00:18:10,350 --> 00:18:13,130
So like writing FF to one register, it reboots.

211
00:18:13,130 --> 00:18:13,270
Okay.

212
00:18:13,270 --> 00:18:13,990
But who cares?

213
00:18:13,990 --> 00:18:15,350
Because you need RCE first.

214
00:18:15,350 --> 00:18:17,410
It's just it's hard to control.

215
00:18:18,690 --> 00:18:27,730
And interestingly, in September that year, the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me.

216
00:18:27,990 --> 00:18:31,510
So and so Jan was working mainly on Frankenstein.

217
00:18:31,510 --> 00:18:32,890
I also worked a bit on Frankenstein.

218
00:18:32,890 --> 00:18:36,150
And the coexistence was what I did with Francesco.

219
00:18:36,150 --> 00:18:40,610
So I was like, okay, if they also mentioned Francesco and me, they should have fixed it.

220
00:18:40,610 --> 00:18:41,510
But they didn't.

221
00:18:41,510 --> 00:18:45,490
So I was a bit confused that all the names were mentioned there in the iOS 13 update.

222
00:18:45,490 --> 00:18:47,490
And also a month is a bit too short.

223
00:18:47,490 --> 00:18:53,230
And everything that they patched but silently already before was the enhanced inquiry response issue.

224
00:18:54,210 --> 00:18:57,770
And then like I poked them from time to time, did you already patch it?

225
00:18:57,770 --> 00:18:58,570
Why didn't you patch it?

226
00:18:58,570 --> 00:18:59,330
And so on.

227
00:18:59,370 --> 00:19:08,190
And at 3063 on stage, I also showed that this is still unpatched and so on.

228
00:19:10,030 --> 00:19:12,090
And they still didn't patch it.

229
00:19:12,090 --> 00:19:13,910
And back then I already had in mind.

230
00:19:13,910 --> 00:19:20,210
So that was when I already called Francesco and said, like, in January, we are going to build speculative transmission.

231
00:19:20,250 --> 00:19:25,810
So that was, I was like, please get things in that direction of a text fixed.

232
00:19:25,810 --> 00:19:29,750
But yeah, and then end of January, I actually knew that this is probably unpatchable.

233
00:19:29,750 --> 00:19:36,290
And that was when I sent Apple that email, you know, why Broadcom didn't send you a fix because it's unpatchable.

234
00:19:37,290 --> 00:19:40,030
What are you telling us?

235
00:19:40,490 --> 00:19:51,870
And yeah, so at least so that that means like Broadcom and also like some of their customers got like some, some notice already in January, about those things like that they are broken.

236
00:19:51,870 --> 00:19:55,570
And I mean, also like the ones before just about denial of service.

237
00:19:55,690 --> 00:20:00,650
And then I was building a few more pox beginning of March, because I was very busy in between.

238
00:20:00,650 --> 00:20:10,030
But that were like the final proof of concepts like that there's even this ram sharing and it is exploitable and stuff like this, which I mean, Broadcom should have known it already.

239
00:20:10,030 --> 00:20:21,910
And they already introduced this, this one patch that you no longer can write to the Bluetooth ram after drive initialization that one was already pushed to devices somewhere around March.

240
00:20:21,970 --> 00:20:31,110
So this is like the thing that they did against it and that they could easily do because they were like informed quite a long time before.

241
00:20:31,210 --> 00:20:36,910
And then in March, when all the proof of concepts were also like, easy to run running and so on.

242
00:20:36,950 --> 00:20:44,710
Then I also started informing the other vendors who I found to have coexistence in their data sheets mentioned.

243
00:20:44,710 --> 00:20:50,450
So it's probably not everyone who uses it, but at least people I know that they use it.

244
00:20:51,850 --> 00:21:01,290
So this is something that like if other people were going to go look at other chipsets, the coexistence is what they'd be looking for, for a similar style of vulnerability.

245
00:21:02,450 --> 00:21:03,790
I'd be something else.

246
00:21:03,790 --> 00:21:12,270
So I'm not sure how it is with all the other devices, but it's definitely existing in a couple of devices and all proprietary.

247
00:21:12,650 --> 00:21:15,510
And that coexistence is controlled by that one.

248
00:21:15,890 --> 00:21:18,290
Was it CC10 chip?

249
00:21:18,290 --> 00:21:21,090
I forget the name of the chip.

250
00:21:21,090 --> 00:21:23,250
It was the microcode portion that...

251
00:21:26,090 --> 00:21:28,330
Ah, the D11, you mean?

252
00:21:28,330 --> 00:21:29,770
Yes, that's the D11.

253
00:21:29,770 --> 00:21:34,750
Yes, it's controlled by this low level stuff, because it must be real time.

254
00:21:34,750 --> 00:21:44,810
So it's an arbitration between the Bluetooth and the wireless, and the wireless needs to run this into the lowest part of the stack that is directly on this microcontroller.

255
00:21:45,570 --> 00:21:52,470
Could you... is there anything else about that microcontroller that you want to talk about or share with people that are watching right now?

256
00:21:53,550 --> 00:22:08,150
Well, I think that it's very interesting if you can have the ability to hack this, because it's the part that can decide what to transmit and whether the received frame should be pushed to the host.

257
00:22:08,230 --> 00:22:18,930
So it's very interesting because you can also develop a very small stack over there, and the behavior of this stack would be completely not detectable by the host.

258
00:22:18,930 --> 00:22:22,610
So there is no way for the host to understand what the U-code might do.

259
00:22:22,610 --> 00:22:29,310
So if you find a way for changing the U-code over the air, then wow, that's amazing what you can do.

260
00:22:29,310 --> 00:22:35,990
But so is this something that could like proactively drop packets with like a magic value or something like that?

261
00:22:35,990 --> 00:22:36,730
Yeah, yeah, yeah.

262
00:22:36,730 --> 00:22:53,390
For this test that we were doing with the coexistence, we were sending command to the wireless interface over the air, and the U-code is the D11 core is receiving them, then dropping them, and changing the configuration of the wireless interface.

263
00:22:53,390 --> 00:22:56,050
This is totally unnoticed by the host.

264
00:22:58,970 --> 00:23:00,650
That's awesome.

265
00:23:01,690 --> 00:23:05,850
What are the next areas that you guys are looking into for like future research?

266
00:23:05,850 --> 00:23:07,530
Do you have anything already lined up?

267
00:23:07,530 --> 00:23:09,030
Anything you can talk about?

268
00:23:09,610 --> 00:23:12,410
Probably the can talk about is the part, right?

269
00:23:12,410 --> 00:23:17,110
I mean, obviously like wireless security, but yeah.

270
00:23:17,110 --> 00:23:19,670
So there will be stuff coming up.

271
00:23:20,310 --> 00:23:34,610
So I will definitely do further research and I mean, Francesco has been doing this for so many years, probably nobody else is like questioning what he's going to do in the future when he has been doing it for the last 15 years.

272
00:23:37,970 --> 00:23:39,010
Fair enough.

273
00:23:40,330 --> 00:23:42,170
Yeah, I'm running out of questions.

274
00:23:42,170 --> 00:23:45,130
We do have a couple more people that are are typing now.

275
00:23:45,770 --> 00:23:46,450
Yeah.

276
00:23:47,670 --> 00:23:49,330
So I mean, we've got a few moments.

277
00:23:49,330 --> 00:23:53,970
Is there anything that you guys want to talk about proactively that we haven't already covered?

278
00:23:55,610 --> 00:24:12,310
I mean, so something that is kind of interesting is that like people currently like also if you look into the first YouTube comments of the talk, it's like they are like, you are just publishing this because I don't know there is this exposure notifications for Corona and stuff like this.

279
00:24:12,310 --> 00:24:17,670
But actually, we have been working on this, I mean, since much longer time than this.

280
00:24:17,670 --> 00:24:22,550
So it's nothing that's like connected to Corona or something in that sense.

281
00:24:23,730 --> 00:24:30,890
And also, I think like, for average people who just keep their system up to date and just use it.

282
00:24:30,970 --> 00:24:34,330
I don't think that it's like a big threat in that sense.

283
00:24:34,330 --> 00:24:45,770
I mean, of course, like if you go on DEF CON, where a lot of hackers are around you, you might want to disable Bluetooth and Wi Fi, but like disabling Wi Fi also has been a well known practice in the past.

284
00:24:46,990 --> 00:24:57,810
So yeah, it's in your experience, in your experience, does disabling like Bluetooth and Wi Fi in the device actually turn off the full radio?

285
00:24:58,370 --> 00:25:08,450
It doesn't turn off the chip, but it disables the host deck usually in a way that you cannot establish active connections anymore.

286
00:25:09,070 --> 00:25:10,210
It depends.

287
00:25:10,210 --> 00:25:19,650
But so yeah, I mean, of course, like switching off your device if you don't want it to be hacked is a good practice, probably even taking out the battery.

288
00:25:20,270 --> 00:25:21,250
It really depends.

289
00:25:21,250 --> 00:25:24,610
It really depends on your on your level of paranoia, of course.

290
00:25:24,610 --> 00:25:42,230
But so yeah, so those those people who who are afraid because they have like, I don't know if you if you have something on your smartphone that's like worth 100,000 bucks or something, then maybe consider being hacked because this is like the range where exploits for those devices start,

291
00:25:42,230 --> 00:25:42,610
right?

292
00:25:42,610 --> 00:25:47,550
So yeah, so that's probably the threat model here.

293
00:25:47,550 --> 00:25:53,330
And I don't think that like, I mean, until someone writes that Bluetooth form, who knows?

294
00:25:53,330 --> 00:26:00,110
But I don't think that until then, like, Bluetooth would be the preferred way to hack people.

295
00:26:00,310 --> 00:26:15,510
What I still don't like about like, or how all this stuff like goes is that still Wi Fi and Bluetooth are like, I mean, they have been exploited back in 2017, very publicly, and they are still very insecure.

296
00:26:15,510 --> 00:26:19,130
And that's, that's the part here, like they have been insecure for years.

297
00:26:19,130 --> 00:26:29,130
And there's, I mean, some things are happening, but really vendors and so on, they really need like some motivation to fix stuff even further.

298
00:26:29,150 --> 00:26:32,790
And so I wouldn't really say like, we are making it more insecure.

299
00:26:32,790 --> 00:26:38,970
It's really like kicking them somewhere and saying like, please, please fix it, make it better.

300
00:26:39,190 --> 00:26:48,330
Like we have seen like at least some improvements within the Broadcom firmware, it's still not super secure, but it's secure after the things that happened in 2017.

301
00:26:48,410 --> 00:26:52,230
And yeah, so I hope to move it a bit more in this direction.

302
00:26:52,310 --> 00:27:01,810
Do you have a general feeling for like, if there's any particular chips that are seen more secure than others, like a better coding practices or anything like that?

303
00:27:01,810 --> 00:27:04,010
Or are they all kind of roughly the same?

304
00:27:05,050 --> 00:27:08,090
There are at least some that are more obscure than others.

305
00:27:08,090 --> 00:27:19,630
I mean, Qualcomm has their own hexagon DSP, which you can emulate, but there are, I think there's a disassembler plugin for Ghidra, which partially works.

306
00:27:19,630 --> 00:27:23,850
And then there is two for IDA, but they also don't support like all commands.

307
00:27:23,850 --> 00:27:28,670
Then you just have disassembler and not the compiler, Ghidra you would also have the compiler.

308
00:27:28,670 --> 00:27:33,710
So it's really bad quality of those tools for Qualcomm.

309
00:27:33,710 --> 00:27:38,970
And then still last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug.

310
00:27:38,970 --> 00:27:42,410
And they, so after the talk, I just went to them, I was like, how did you find it?

311
00:27:42,410 --> 00:27:44,230
I said, just like static reverse engineering.

312
00:27:44,230 --> 00:27:46,410
I was like the hexagon, right?

313
00:27:47,710 --> 00:28:03,210
But yeah, so not sure if Qualcomm is more obscure or really more secure, at least they have more people on security conferences and, but yeah, it's, it's hard to tell.

314
00:28:03,430 --> 00:28:10,010
So I think in general, if you have newer hardware, then you have more security measures in it and like newer chips.

315
00:28:10,010 --> 00:28:25,390
So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure than if you buy some very cheap smartphone with cheap chips that didn't have so much money for development, but it's still no guarantee.

316
00:28:25,390 --> 00:28:30,810
So it just, it could have the budget to make it secure if they wanted to make it secure.

317
00:28:30,810 --> 00:28:32,090
It's no guarantee, right?

318
00:28:32,090 --> 00:28:32,730
Right.

319
00:28:32,730 --> 00:28:33,530
Fair.

320
00:28:34,510 --> 00:28:41,990
And the last question that I think that we can take, and this one's not directly about your presentation.

321
00:28:41,990 --> 00:28:46,970
Someone wants to know how you displayed your hand behind your presentation in the actual recorded video.

322
00:28:48,210 --> 00:28:55,430
So that's actually a method that I stole from Daniel Crusoe, the guy who did the spectra.

323
00:28:55,490 --> 00:29:00,130
So for his lectures, he's using OBS and he has a white wall.

324
00:29:00,130 --> 00:29:02,090
I mean, I also have the white wall behind me, right?

325
00:29:02,090 --> 00:29:05,330
And then I point with my hand and this is the part that I'm filming.

326
00:29:05,330 --> 00:29:13,550
And so this, this part would be like behind the slide and in the slide, I said white as an opaque color, and then I put my hand off.

327
00:29:13,550 --> 00:29:17,630
So behind it, so then I have the layers and I can do the the pointing.

328
00:29:17,630 --> 00:29:19,390
So this would be the pointing.

329
00:29:20,010 --> 00:29:20,870
Nice.

330
00:29:20,870 --> 00:29:23,710
I'm sure some other presenters will appreciate that touch.

331
00:29:24,970 --> 00:29:25,630
Okay.

332
00:29:25,630 --> 00:29:27,830
Well, that's all the time that we have for you.

333
00:29:27,830 --> 00:29:30,250
Thank you both for joining us for the Q&A session.

334
00:29:30,250 --> 00:29:39,210
Thank you both for getting content into the virtual DEF CON and yeah, have a nice day.

335
00:29:40,270 --> 00:29:41,170
Thank you, too.

336
00:29:42,090 --> 00:29:42,670
Take care.

337
00:29:42,670 --> 00:29:43,390
Thank you, too.