[00:28.680 --> 00:36.800] All right. We are here with our next QA session with Jiska and Francesco for the Spectra wireless, [00:36.800 --> 00:43.280] new wireless escalation targets talk. Do you guys want to give yourself a little bit of an intro? [00:43.980 --> 00:45.520] Jiska, do you want to start? [00:48.200 --> 00:54.520] Yeah, okay, then I'll start. I'm a postdoc at TU Darmstadt in Germany at the Secure Mobile [00:54.520 --> 01:00.500] Networking Lab, and I've been, yeah, recently working a lot with Bluetooth. Before, I've been [01:00.500 --> 01:07.260] working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication. [01:10.440 --> 01:16.780] Hi, I'm Francesco Gringoli. I'm an assistant professor at the University of Brescia and [01:16.780 --> 01:21.540] have been playing with wireless technologies in the last 15 years. [01:21.540 --> 01:29.480] That's great. Thank you both. So, I mean, I'm going to start off with some a little bit simpler [01:29.480 --> 01:35.920] questions. So, you talked a lot about this new vulnerability that's between the two cores. [01:35.920 --> 01:41.860] Is this something that can be patched? It's hard to say. So, there are parts that [01:41.860 --> 01:48.620] definitely are not patchable because they are for the performance improvements. So, [01:48.620 --> 01:55.200] the stuff that goes, like, between the U-code that Francesco modified and the communication [01:55.200 --> 02:00.020] with the serial interface on the Bluetooth side, this is something that you need, at least if you [02:00.020 --> 02:05.220] don't want to lose performance. And this is also all in hardware, I guess. So, this is something, [02:05.220 --> 02:12.900] like, in a future chip, it might be changed in a way that you can infer less information, [02:12.900 --> 02:17.560] but it's probably not patchable in that sense or not easily patchable. [02:17.560 --> 02:22.940] The shared RAM is something that they should remove, but I didn't see them remove it yet. [02:22.940 --> 02:28.100] And I don't know if they can actually unmap it in the generation of chips or if this also needs [02:28.240 --> 02:32.820] a new generation of chips. I didn't see the shared RAM actually being used anywhere. So, [02:32.820 --> 02:39.640] that's the weird thing, right? The shared RAM exists. Yeah. So, it exists, but it's really [02:39.640 --> 02:47.600] not being used for anything or at least for nothing that I could see. So, this is the thing [02:47.600 --> 02:50.580] that they should remove, because it's the most dangerous part. [02:51.660 --> 02:55.620] So, we got a question from Cooper Q, and this was actually something that I was interested in [02:55.620 --> 03:00.780] as well. You mentioned LTE is on some of the same frequencies, and I know that there are some [03:00.780 --> 03:06.640] all-in-one chips that include LTE in addition to their Bluetooth and wireless stacks. Have you [03:06.640 --> 03:14.190] tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio? [03:15.100 --> 03:21.880] Not yet. So, what we tried is we tried to see if this connection exists at all. And I can tell that [03:21.880 --> 03:28.080] in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS [03:28.080 --> 03:36.820] something. And then I also took some logs on an iPhone and like iPhone 7 and newer. And on those [03:36.820 --> 03:41.880] devices, what you can see is that there are HCI commands. So, that's from the operating system [03:41.880 --> 03:49.200] Bluetooth daemon to the chip that include MWS, which is the configuration for the LTE coexistence. [03:49.200 --> 03:54.520] So, they are definitely using it. I just didn't try to exploit it yet. [03:55.800 --> 04:02.560] Cool. Fair enough. This one, this one's one I'm going to, I'm going to have to read verbatim [04:02.560 --> 04:06.240] because it's a little out of context. I don't know what it was. In the talk, you mentioned [04:06.240 --> 04:08.680] Frankenstein. Can you talk a little bit about it? [04:10.880 --> 04:18.700] Yeah. So, that's another paper. So, actually, the main work of this is from Jan, who is not here, [04:18.700 --> 04:26.020] but that's one of my former students. And he made some snapshotting for Bluetooth chips [04:26.020 --> 04:31.240] of Broadcom and then also emulation. And the interesting part about this emulation is that [04:31.240 --> 04:37.300] it includes thread switches and a virtual modem so that you can attach it to your Linux host and [04:37.300 --> 04:42.440] you actually can start scanning for devices and get back random devices. So, you have like a full [04:42.440 --> 04:50.000] stack emulation in that sense. And this is something that we are going to present next week [04:50.000 --> 04:59.420] at USENIX security. The paper is already public. And also, the software is on GitHub since a while. [04:59.620 --> 05:07.380] Cool. Could you send me links for that information? You can do it after the Q&A. I just want to be [05:07.380 --> 05:11.700] able to drop it in track one for anyone that's interested in following up with that information. [05:12.440 --> 05:16.880] So, anyone that's paying attention, if you want the extra information, the links to the [05:17.540 --> 05:23.880] paper and everything else will be in the track one room as soon as this is over. [05:25.420 --> 05:34.180] Okay, on to the next question. So, regarding the CVE-2019-15063 denial of service Bluetooth [05:34.180 --> 05:40.040] Wi-Fi exploit, was that the specific one that you guys were working on? I don't remember CVE numbers [05:40.040 --> 05:45.300] off the top of my head. Anyways, the question is, how are you manipulating the register that [05:45.300 --> 05:49.180] results in crashes? Are you physically accessing the chipset? Or can this be done remotely? [05:50.200 --> 05:55.140] Ah, so yeah, that's, so it's kind of two stages, right? So, you first need some remote code [05:55.140 --> 05:59.540] execution, either on Wi-Fi or on Bluetooth. And then you could write to the register. [05:59.760 --> 06:07.640] And what we do for debugging is actually, so for Bluetooth, when we modify Bluetooth, [06:07.640 --> 06:13.020] then we have internal blue, which is a framework that supports the vendor specific commands from [06:13.020 --> 06:19.140] Broadcom to manipulate the Bluetooth part. And for Wi-Fi, there's another thing next month, [06:19.140 --> 06:25.820] I think Francesco can tell a bit more about next month. Yeah, it's a project that allows people to [06:25.820 --> 06:35.460] do binary patching of the wireless driver, so that you can modify and then add functionalities. [06:35.460 --> 06:39.760] But of course, this is not the remote execution, it's just for modifying the binary image [06:39.760 --> 06:45.280] without having access to the source code, which is a proprietary. And this allows to modify both the [06:45.280 --> 06:52.720] ARM, the ARM core, and also the U-code part that is the lowest part accessible in the hardware. [06:53.080 --> 06:57.340] That's really cool. Is that a tool that is going to get released like [06:58.120 --> 07:04.420] upcoming? Is that part of the Usenix talk? No, next one is, I just pasted it also in our [07:04.420 --> 07:09.840] private chat, so you can copy it later. Next one is something, since when is it public? I don't [07:09.840 --> 07:18.520] know, 2016, 17? Yeah. And the interesting part about next month is so next month was just built [07:18.520 --> 07:25.260] to actually modify the Wi-Fi firmware without the intention to really hack it. So like, [07:25.260 --> 07:31.080] more for sending arbitrary signals, turning your smartphone into an SDR. And the interesting part [07:31.080 --> 07:37.060] here is that back then in 2017, actually, Google Project Zero and Itay Eisenstein used this [07:37.060 --> 07:42.800] knowledge to dig a bit further into the Broadcom chips. So like Broadcom and stuff like this was [07:42.800 --> 07:50.080] also not only but also based on next month, and also later work, they always use next month. [07:50.200 --> 08:01.060] So that's a very interesting thing about this. And then for the Bluetooth stuff, we said like, [08:01.580 --> 08:08.900] well, how do you guys go about researching phones, since for the most part, everything [08:08.900 --> 08:13.080] seems to be closed source? They're asking to talk about like the research process, [08:13.080 --> 08:16.060] like if you were going to try and exploit a new phone? [08:17.640 --> 08:26.060] Ah, yeah, so that's, that's the thing. So the first part is, I mean, if you don't have, [08:26.060 --> 08:30.480] already have a working over the air exploit, which is hard to get, especially if you don't [08:30.480 --> 08:35.440] have the ROM of a device and so on, even if you had an exploit, like getting it working on a new [08:35.440 --> 08:44.580] device would be hard. So usually we start with a rooted smartphone, or a jailbreak. Or, I mean, [08:44.580 --> 08:51.840] also MacBooks have Broadcom chips. So and there you are already root. So it depends a bit. And [08:51.840 --> 08:57.100] then we would dump the ROM. And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the [08:57.100 --> 09:02.520] same. And for Wi Fi, the ROM also contains the U code. And the U code is the thing that runs in [09:02.520 --> 09:08.420] the D11 core. So what Francesco modifies, and for me, it's more the Bluetooth firmware. [09:09.820 --> 09:14.220] And then it's very annoying, because like the stuff is still without any symbols. And [09:14.220 --> 09:18.540] especially Bluetooth also doesn't have any debug strings, the U code doesn't have any [09:18.540 --> 09:24.940] debug strings, the Wi Fi firmware has a few debug strings. And since this is like, [09:24.940 --> 09:29.440] so even the memory layout is somewhat unknown, and you need to get it and so on. And because of [09:29.440 --> 09:38.020] this really horribly loads into IDA. So it really looks ugly. Yeah, fair. And I think Francesco, [09:38.020 --> 09:43.760] for you, it's even the case that you get new instructions, right? Yes, for the U code, [09:43.760 --> 09:52.280] there is no actually corresponds between the U code and the any known CPU. So we had to do this [09:52.280 --> 09:58.180] reverse engineering for understanding the meaning of these instruction set, and then adding [09:58.180 --> 10:04.640] instructions, because Broadcom, during the years, added new instructions. And yeah, the reason this [10:04.640 --> 10:10.480] was very difficult, because it's not ARM that you compile or disassemble, but you have to develop [10:10.480 --> 10:19.760] your own tool chain for this. So what helped is that Broadcom didn't change much the platform, [10:19.760 --> 10:26.640] since they introduced it 15 years ago. So they are additionally adding instructions. And [10:26.640 --> 10:31.560] also what helps is that the U code is very short is less than 64 kilobytes. [10:33.640 --> 10:39.780] Have you either of you looked into any of the newer, like mesh Bluetooth protocols? [10:40.900 --> 10:46.140] Bluetooth mesh. So a colleague of mine did that Lars, and he looked into the friendship together [10:46.140 --> 10:52.100] with a few other people in our team. So it's so yeah, we did it in our team. But the mesh is not [10:52.100 --> 10:56.880] really interesting. I mean, it's just using Bluetooth LE advertisements. So from a, at least [10:56.880 --> 11:03.460] from a lower level perspective, it's nothing special. I mean, of course, implementations on [11:03.460 --> 11:11.200] top are interesting then. But I mean, I do a lot of lower layer stuff. He just showed that the [11:11.200 --> 11:18.620] encryption and so on in the, in the friendship of groups is broken, and Bluetooth SICK send funny [11:18.620 --> 11:28.980] responses. Of course it is. Someone else is shouting out that a lot of your and related [11:28.980 --> 11:35.960] work on BLE is also available as pre prints from YSEC 2020. And they also threw through a link in [11:35.960 --> 11:40.500] there. I just wanted to shout that out. Francesco also has done stuff with Bluetooth sniffing, [11:40.500 --> 11:46.140] right? You've built a Bluetooth sniffer. Yeah, this real time sniffer using a software defined [11:46.140 --> 11:51.920] radio for capturing all the channels at the same time and GPU for decoding and brute forcing [11:52.700 --> 11:57.040] lowest address part address and low energy session ID. [11:57.040 --> 12:02.320] Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff. Is [12:02.320 --> 12:07.540] there like a minimum requirements for the SDR hardware to do that level of sniffing and [12:09.240 --> 12:11.120] for Bluetooth? [12:13.060 --> 12:21.500] Well, if you have SDR that can sniff 80 megahertz is better. But for sniffing Bluetooth classic, [12:21.500 --> 12:28.580] we demonstrated that it's enough to capture only 16 channels out of 80. Then you can also use one [12:28.580 --> 12:37.260] of these cheap SDR like, like Hacker F or Blader F. So you do not need to buy a very expensive [12:38.080 --> 12:42.840] 1000 euro 80 megahertz, but you can buy one of these for 100 bucks. [12:43.840 --> 12:44.800] That's awesome. [12:44.800 --> 12:45.700] It should work. [12:45.700 --> 12:48.340] Yeah, accessible hacking. It's nice. [12:49.380 --> 12:54.600] Got one person asking, do you think Broadcom is relying a little bit too much on security [12:54.600 --> 12:56.560] through obscurity with some of these chips? [12:58.500 --> 13:02.480] I mean, so what you can actually see, and that's an interesting development. So [13:02.480 --> 13:09.440] on the first bug that Jan discovered with Frankenstein is one in the enhancing viral [13:09.440 --> 13:15.900] response. And when he submitted that one, they said, we already know the bug, and we just didn't [13:15.900 --> 13:21.800] find it anywhere. And then I got like the newest Samsung Galaxy S10e and extracted the ROM. And [13:21.800 --> 13:28.460] this one actually had a patch and it had a compile date of April 2018. And that also means like they [13:28.460 --> 13:33.600] cannot change the ROM, so they cannot tell us lies about the ROM. And we reported it afterwards. [13:33.600 --> 13:40.480] So that actually means they knew it before. But, and now that's the interesting part of the story. [13:41.140 --> 13:45.420] They didn't patch it backwards in the older devices because it was not publicly known as [13:45.520 --> 13:52.340] a bug and you could easily unroll the patches. Now, the thing is, they definitely increased [13:52.340 --> 14:01.180] the security, I would say, after the bugs in 2017 were public. So, I mean, it took them a year [14:01.180 --> 14:06.540] probably to do some pen testing and so on. But you can see like 2017, the first public incidents [14:06.540 --> 14:14.160] happened. 2018, the first kind of secret patches make it into the firmware. And also they started [14:14.160 --> 14:20.420] using like, I don't know, stuff like secondaries. They didn't have it before. So this is things that [14:20.420 --> 14:25.180] now are going into the firmware. It's still not like super perfect and everything. It's still, [14:25.180 --> 14:31.340] of course, closed source. But I mean, most firmware in wireless chips is closed source. [14:31.340 --> 14:37.740] Yeah. So at least they are trying to work on it. And I think they are there on that, [14:37.740 --> 14:40.700] like security by obscurity doesn't really work. [14:41.240 --> 14:50.280] Fair enough. So someone is asking where people could find the source code for that Bluetooth [14:50.280 --> 14:58.590] sniffer. Francesco, I think that's it. Yeah, I can send you. Yeah, I can send you a link. [14:58.590 --> 15:01.690] If you send me a link, I will post that with everything else. [15:02.530 --> 15:10.910] Yeah. And another one. Do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or [15:10.910 --> 15:14.690] interoperability between implementations too difficult to bridge? [15:15.030 --> 15:20.410] So I think for Wi-Fi, it's hard because for most stuff, you need to actually join an access point [15:20.410 --> 15:25.590] or something like this. But for Bluetooth, you have this master slave mode. So you can actually [15:25.590 --> 15:30.090] have a device like a smartphone is usually capable of being master and slave. Some like [15:30.090 --> 15:34.750] cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master. [15:34.750 --> 15:39.710] But if you can be slave and master, then you can be part of this, let's say, [15:39.710 --> 15:48.710] network and distribute the malware. And I think there is, let's say, a sufficient fraction of [15:48.710 --> 15:54.950] popular devices. So it depends if it's in the operating system, then it would have to be like [15:54.950 --> 16:00.470] compatible iPhones or something. And I mean, if you just there's not much diversity in iPhones. [16:00.470 --> 16:05.650] So if you just take like the top selling iPhones or something that also would work on the chip [16:05.650 --> 16:11.490] base. On Android, you have more diversity. But still, if you would say you just pick the top [16:11.490 --> 16:20.010] Samsung and Galaxy, and maybe the pixels or something. Yeah, that could work. So Jan actually [16:20.010 --> 16:27.670] uncovered vulnerability in the Android Bluetooth daemon. And that one would have been vulnerable. [16:27.670 --> 16:35.630] And it was fixed in February. I mean, still, yeah. So you couldn't infect like 100% of devices. [16:36.020 --> 16:41.710] Considering that you have your Bluetooth on and walk around and so on, that would be a threat. [16:41.930 --> 16:47.570] So the reason why I think people wouldn't build it is how do you control it? Because then you need [16:47.570 --> 16:52.610] to have some communication over the internet or something like how do you do like a command and [16:52.610 --> 17:00.270] control server for Bluetooth form in a way that is like stealthy and really, I don't know. So I [17:00.270 --> 17:07.030] think it's really more the bigger threat is definitely taking over nearby devices or like [17:07.030 --> 17:12.410] hacking someone or like going next to an office train station somewhere where you know, like [17:12.410 --> 17:17.310] interesting people are and taking over their devices. But I think even if it's vulnerable, [17:17.310 --> 17:23.910] I think this is nothing that people would build. But I mean, maybe someone builds it someday. [17:23.910 --> 17:29.770] So I won't build it because, well, I wouldn't. But I mean, maybe someone is crazy enough to do [17:29.770 --> 17:34.590] this, right? It's just true. I mean, you could potentially just do it without a financial [17:34.590 --> 17:41.970] motivation, just to see if it works or something. Yeah. So switching gears just a little bit. [17:42.570 --> 17:46.530] Did you guys report this to vendors? Like how was how did that communication like turn out? [17:46.530 --> 17:55.670] Was it positive? Was it negative? Was it? Tell me. Yeah, so the very first report about this [17:55.670 --> 18:01.290] denial-of-service was in August last year. So that's like a year ago. And I think they didn't [18:01.290 --> 18:05.410] really take it serious because it was just denial-of-service, right? And even if you have [18:05.410 --> 18:09.970] denial-of-service with an operating system reboot, it's like nothing that you could really control, [18:09.970 --> 18:14.490] right? So like writing FF to one register, it reboots. Okay. But who cares? Because you need [18:14.490 --> 18:22.250] RCE first. It's just it's hard to control. And interestingly, in September that year, [18:22.250 --> 18:29.310] the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me. So and so [18:29.310 --> 18:33.030] Jan was working mainly on Frankenstein. I also worked a bit on Frankenstein. And [18:33.870 --> 18:38.170] the coexistence was what I did with Francesco. So I was like, okay, if they also mentioned [18:38.170 --> 18:42.990] Francesco and me, they should have fixed it. But they didn't. So I was a bit confused that [18:42.990 --> 18:47.490] all the names were mentioned there in the iOS 13 update. And also a month is a bit too short. [18:47.490 --> 18:52.330] And everything that they patched but silently already before was the enhanced inquiry response [18:52.330 --> 18:58.170] issue. And then like I poked them from time to time, did you already patch it? Why didn't you [18:58.170 --> 19:08.190] patch it? And so on. And at 3063 on stage, I also showed that this is still unpatched and so on. [19:10.030 --> 19:15.170] And they still didn't patch it. And back then I already had in mind. So that was when I already [19:15.170 --> 19:20.210] called Francesco and said, like, in January, we are going to build speculative transmission. [19:20.250 --> 19:24.490] So that was, I was like, please get things in that direction of a text [19:25.130 --> 19:29.750] fixed. But yeah, and then end of January, I actually knew that this is probably unpatchable. [19:29.750 --> 19:34.990] And that was when I sent Apple that email, you know, why Broadcom didn't send you a fix because [19:34.990 --> 19:44.610] it's unpatchable. What are you telling us? And yeah, so at least so that that means like Broadcom [19:44.610 --> 19:50.130] and also like some of their customers got like some, some notice already in January, about those [19:50.130 --> 19:55.570] things like that they are broken. And I mean, also like the ones before just about denial of service. [19:55.690 --> 20:00.650] And then I was building a few more pox beginning of March, because I was very busy in between. [20:00.650 --> 20:05.190] But that were like the final proof of concepts like that there's even this ram sharing and it [20:05.190 --> 20:10.030] is exploitable and stuff like this, which I mean, Broadcom should have known it already. [20:10.030 --> 20:15.190] And they already introduced this, this one patch that you no longer can write [20:15.710 --> 20:20.030] to the Bluetooth ram after drive initialization that one was already pushed to devices [20:20.030 --> 20:26.110] somewhere around March. So this is like the thing that they did against it and that they could [20:26.110 --> 20:32.810] easily do because they were like informed quite a long time before. And then in March, when all [20:32.810 --> 20:38.790] the proof of concepts were also like, easy to run running and so on. Then I also started informing [20:38.790 --> 20:44.710] the other vendors who I found to have coexistence in their data sheets mentioned. So [20:45.190 --> 20:50.450] it's probably not everyone who uses it, but at least people I know that they use it. [20:51.850 --> 20:56.610] So this is something that like if other people were going to go look at other chipsets, [20:56.610 --> 21:01.290] the coexistence is what they'd be looking for, for a similar style of vulnerability. [21:02.450 --> 21:06.650] I'd be something else. So I'm not sure how it is with all the other devices, [21:06.650 --> 21:12.270] but it's definitely existing in a couple of devices and all proprietary. [21:12.650 --> 21:18.290] And that coexistence is controlled by that one. Was it CC10 chip? [21:18.290 --> 21:23.250] I forget the name of the chip. It was the microcode portion that... [21:26.090 --> 21:28.330] Ah, the D11, you mean? [21:28.330 --> 21:29.770] Yes, that's the D11. [21:29.770 --> 21:35.090] Yes, it's controlled by this low level stuff, because it must be real time. So it's an [21:35.090 --> 21:39.630] arbitration between the Bluetooth and the wireless, and the wireless needs to run this [21:39.630 --> 21:44.810] into the lowest part of the stack that is directly on this microcontroller. [21:45.570 --> 21:49.410] Could you... is there anything else about that microcontroller that you [21:49.410 --> 21:52.470] want to talk about or share with people that are watching right now? [21:53.550 --> 21:58.850] Well, I think that it's very interesting if you can have the ability to hack this, [21:58.850 --> 22:06.410] because it's the part that can decide what to transmit and whether the received frame should [22:06.410 --> 22:11.850] be pushed to the host. So it's very interesting because you can also develop a very small stack [22:11.850 --> 22:19.150] over there, and the behavior of this stack would be completely not detectable by the host. So there [22:19.150 --> 22:25.210] is no way for the host to understand what the U-code might do. So if you find a way for changing [22:25.210 --> 22:29.310] the U-code over the air, then wow, that's amazing what you can do. [22:29.310 --> 22:34.310] But so is this something that could like proactively drop packets with like a magic value [22:34.310 --> 22:35.990] or something like that? [22:35.990 --> 22:40.650] Yeah, yeah, yeah. For this test that we were doing with the coexistence, we were [22:41.450 --> 22:47.850] sending command to the wireless interface over the air, and the U-code is the D11 core is receiving [22:47.850 --> 22:53.390] them, then dropping them, and changing the configuration of the wireless interface. [22:53.390 --> 22:56.050] This is totally unnoticed by the host. [22:58.970 --> 23:05.850] That's awesome. What are the next areas that you guys are looking into for like future research? [23:05.850 --> 23:09.030] Do you have anything already lined up? Anything you can talk about? [23:09.610 --> 23:16.170] Probably the can talk about is the part, right? I mean, obviously like wireless security, but [23:16.170 --> 23:22.810] yeah. So there will be stuff coming up. So I will definitely do further research [23:23.730 --> 23:28.010] and I mean, Francesco has been doing this for so many years, probably nobody else is like [23:28.010 --> 23:34.610] questioning what he's going to do in the future when he has been doing it for the last 15 years. [23:37.970 --> 23:43.670] Fair enough. Yeah, I'm running out of questions. We do have a couple more people that are [23:43.670 --> 23:50.690] are typing now. Yeah. So I mean, we've got a few moments. Is there anything that you guys [23:50.690 --> 23:53.970] want to talk about proactively that we haven't already covered? [23:55.610 --> 24:01.450] I mean, so something that is kind of interesting is that like people currently like also if you [24:01.450 --> 24:06.910] look into the first YouTube comments of the talk, it's like they are like, you are just publishing [24:06.910 --> 24:12.310] this because I don't know there is this exposure notifications for Corona and stuff like this. [24:12.310 --> 24:18.270] But actually, we have been working on this, I mean, since much longer time than this. So it's [24:18.270 --> 24:25.690] nothing that's like connected to Corona or something in that sense. And also, I think like, [24:25.690 --> 24:32.390] for average people who just keep their system up to date and just use it. I don't think that it's [24:32.390 --> 24:37.570] like a big threat in that sense. I mean, of course, like if you go on DEF CON, where a lot [24:37.570 --> 24:41.810] of hackers are around you, you might want to disable Bluetooth and Wi Fi, but like disabling [24:41.810 --> 24:51.390] Wi Fi also has been a well known practice in the past. So yeah, it's in your experience, [24:51.910 --> 24:56.570] in your experience, does disabling like Bluetooth and Wi Fi in the device actually turn off the [24:56.570 --> 25:04.250] full radio? It doesn't turn off the chip, but it disables the host deck usually in a way [25:04.250 --> 25:11.610] that you cannot establish active connections anymore. It depends. But so yeah, I mean, [25:11.610 --> 25:17.710] of course, like switching off your device if you don't want it to be hacked is a good practice, [25:17.710 --> 25:23.130] probably even taking out the battery. It really depends. It really depends on your on your level [25:23.130 --> 25:29.990] of paranoia, of course. But so yeah, so those those people who who are afraid because they [25:29.990 --> 25:34.010] have like, I don't know if you if you have something on your smartphone that's like worth [25:34.630 --> 25:40.590] 100,000 bucks or something, then maybe consider being hacked because this is like the range where [25:40.590 --> 25:47.550] exploits for those devices start, right? So yeah, so that's probably the threat model here. [25:47.550 --> 25:53.330] And I don't think that like, I mean, until someone writes that Bluetooth form, who knows? [25:53.330 --> 26:00.110] But I don't think that until then, like, Bluetooth would be the preferred way to hack people. [26:00.310 --> 26:07.870] What I still don't like about like, or how all this stuff like goes is that still Wi Fi and [26:07.870 --> 26:13.670] Bluetooth are like, I mean, they have been exploited back in 2017, very publicly, and they [26:13.670 --> 26:19.130] are still very insecure. And that's, that's the part here, like they have been insecure for years. [26:19.130 --> 26:25.310] And there's, I mean, some things are happening, but really vendors and so on, they really need [26:25.310 --> 26:32.050] like some motivation to fix stuff even further. And so I wouldn't really say like, we are making [26:32.050 --> 26:37.670] it more insecure. It's really like kicking them somewhere and saying like, please, please fix it, [26:37.670 --> 26:43.970] make it better. Like we have seen like at least some improvements within the Broadcom firmware, [26:43.970 --> 26:48.410] it's still not super secure, but it's secure after the things that happened in 2017. And [26:48.950 --> 26:52.230] yeah, so I hope to move it a bit more in this direction. [26:52.310 --> 26:56.130] Do you have a general feeling for like, if there's any particular chips that [26:56.130 --> 27:00.390] are seen more secure than others, like a better coding practices or [27:00.870 --> 27:04.010] anything like that? Or are they all kind of roughly the same? [27:05.050 --> 27:09.970] There are at least some that are more obscure than others. I mean, Qualcomm has their own [27:09.970 --> 27:17.030] hexagon DSP, which you can emulate, but there are, I think there's a disassembler plugin for [27:17.030 --> 27:22.930] Ghidra, which partially works. And then there is two for IDA, but they also don't support like [27:22.930 --> 27:28.070] all commands. Then you just have disassembler and not the compiler, Ghidra you would also have [27:28.070 --> 27:34.250] the compiler. So it's really bad quality of those tools for Qualcomm. And then still [27:34.250 --> 27:39.650] last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug. And they, [27:39.650 --> 27:42.690] so after the talk, I just went to them, I was like, how did you find it? I said, [27:42.690 --> 27:50.290] just like static reverse engineering. I was like the hexagon, right? But yeah, so [27:51.530 --> 27:57.150] not sure if Qualcomm is more obscure or really more secure, at least they have more people on [27:57.150 --> 28:05.030] security conferences and, but yeah, it's, it's hard to tell. So I think in general, [28:05.030 --> 28:10.010] if you have newer hardware, then you have more security measures in it and like newer chips. [28:10.010 --> 28:17.610] So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure [28:17.610 --> 28:23.490] than if you buy some very cheap smartphone with cheap chips that didn't have so much money for [28:23.490 --> 28:29.190] development, but it's still no guarantee. So it just, it could have the budget to make it secure [28:29.190 --> 28:36.570] if they wanted to make it secure. It's no guarantee, right? Right. Fair. And the last [28:36.570 --> 28:42.150] question that I think that we can take, and this one's not directly about your presentation. Someone [28:42.150 --> 28:46.970] wants to know how you displayed your hand behind your presentation in the actual recorded video. [28:48.210 --> 28:55.430] So that's actually a method that I stole from Daniel Crusoe, the guy who did the spectra. [28:55.490 --> 29:01.310] So for his lectures, he's using OBS and he has a white wall. I mean, I also have the white wall [29:01.310 --> 29:05.570] behind me, right? And then I point with my hand and this is the part that I'm filming. And so [29:05.570 --> 29:11.410] this, this part would be like behind the slide and in the slide, I said white as an opaque color, [29:11.410 --> 29:16.670] and then I put my hand off. So behind it, so then I have the layers and I can do the [29:16.670 --> 29:19.390] the pointing. So this would be the pointing. [29:20.010 --> 29:23.710] Nice. I'm sure some other presenters will appreciate that touch. [29:24.970 --> 29:29.650] Okay. Well, that's all the time that we have for you. Thank you both for joining us for the Q&A [29:29.650 --> 29:39.210] session. Thank you both for getting content into the virtual DEF CON and yeah, have a nice day. [29:40.270 --> 29:41.170] Thank you, too. [29:42.090 --> 29:42.670] Take care. [29:42.670 --> 29:43.390] Thank you, too.