WEBVTT 00:28.680 --> 00:29.860 All right. 00:30.020 --> 00:39.860 We are here with our next QA session with Jiska and Francesco for the Spectra wireless, new wireless escalation targets talk. 00:40.180 --> 00:43.280 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:50.440 Yeah, okay, then I'll start. 00:50.620 --> 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. 00:59.680 --> 01:07.260 Before, I've been working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication. 01:10.440 --> 01:12.740 Hi, I'm Francesco Gringoli. 01:13.020 --> 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. 01:21.540 --> 01:22.920 That's great. 01:23.020 --> 01:24.520 Thank you both. 01:24.860 --> 01:30.520 So, I mean, I'm going to start off with some a little bit simpler questions. 01:30.540 --> 01:35.920 So, you talked a lot about this new vulnerability that's between the two cores. 01:35.920 --> 01:37.820 Is this something that can be patched? 01:38.500 --> 01:39.820 It's hard to say. 01:39.820 --> 01:48.040 So, there are parts that definitely are not patchable because they are for the performance improvements. 01:48.040 --> 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. 02:01.440 --> 02:04.160 And this is also all in hardware, I guess. 02:04.160 --> 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. 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: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. 02:29.660 --> 02:32.680 I didn't see the shared RAM actually being used anywhere. 02:32.680 --> 02:34.740 So, that's the weird thing, right? 02:34.740 --> 02:37.280 The shared RAM exists. 02:37.420 --> 02:38.040 Yeah. 02:38.040 --> 02:44.500 So, it exists, but it's really not being used for anything or at least for nothing that I could see. 02:45.640 --> 02:50.580 So, this is the thing that they should remove, because it's the most dangerous part. 02:51.660 --> 02:56.180 So, we got a question from Cooper Q, and this was actually something that I was interested in as well. 02:56.180 --> 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. 03:06.380 --> 03:14.190 Have you tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio? 03:15.100 --> 03:16.220 Not yet. 03:16.220 --> 03:20.800 So, what we tried is we tried to see if this connection exists at all. 03:20.800 --> 03:28.980 And I can tell that in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS something. 03:29.480 --> 03:35.820 And then I also took some logs on an iPhone and like iPhone 7 and newer. 03:35.820 --> 03:39.780 And on those devices, what you can see is that there are HCI commands. 03:39.780 --> 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. 03:49.200 --> 03:51.340 So, they are definitely using it. 03:51.340 --> 03:54.520 I just didn't try to exploit it yet. 03:55.800 --> 03:56.400 Cool. 03:56.400 --> 03:57.180 Fair enough. 03:58.400 --> 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. 04:03.660 --> 04:05.400 I don't know what it was. 04:05.400 --> 04:07.160 In the talk, you mentioned Frankenstein. 04:07.160 --> 04:08.680 Can you talk a little bit about it? 04:10.880 --> 04:11.360 Yeah. 04:11.360 --> 04:13.320 So, that's another paper. 04:13.320 --> 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. 04:21.860 --> 04:28.720 And he made some snapshotting for Bluetooth chips of Broadcom and then also emulation. 04:28.940 --> 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. 04:41.220 --> 04:45.920 So, you have like a full stack emulation in that sense. 04:46.820 --> 04:51.880 And this is something that we are going to present next week at USENIX security. 04:52.860 --> 04:54.900 The paper is already public. 04:55.080 --> 04:59.420 And also, the software is on GitHub since a while. 04:59.620 --> 05:00.440 Cool. 05:00.440 --> 05:04.340 Could you send me links for that information? 05:04.460 --> 05:06.860 You can do it after the Q&A. 05:06.880 --> 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. 05:12.440 --> 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. 05:25.420 --> 05:28.500 Okay, on to the next question. 05:28.860 --> 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? 05:38.420 --> 05:41.040 I don't remember CVE numbers off the top of my head. 05:41.380 --> 05:46.280 Anyways, the question is, how are you manipulating the register that results in crashes? 05:46.280 --> 05:47.800 Are you physically accessing the chipset? 05:47.800 --> 05:49.180 Or can this be done remotely? 05:50.200 --> 05:53.460 Ah, so yeah, that's, so it's kind of two stages, right? 05:53.460 --> 05:57.220 So, you first need some remote code execution, either on Wi-Fi or on Bluetooth. 05:57.220 --> 05:59.540 And then you could write to the register. 05:59.760 --> 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. 06:16.240 --> 06:22.540 And for Wi-Fi, there's another thing next month, I think Francesco can tell a bit more about next month. 06:22.840 --> 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. 06:35.460 --> 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. 06:43.420 --> 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. 06:53.080 --> 06:54.280 That's really cool. 06:54.280 --> 06:58.820 Is that a tool that is going to get released like upcoming? 06:58.820 --> 07:01.160 Is that part of the Usenix talk? 07:01.400 --> 07:06.580 No, next one is, I just pasted it also in our private chat, so you can copy it later. 07:06.640 --> 07:09.660 Next one is something, since when is it public? 07:09.660 --> 07:11.940 I don't know, 2016, 17? 07:12.140 --> 07:12.700 Yeah. 07:14.080 --> 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. 07:24.260 --> 07:29.540 So like, more for sending arbitrary signals, turning your smartphone into an SDR. 07:29.540 --> 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. 07:40.500 --> 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. 07:50.200 --> 07:53.960 So that's a very interesting thing about this. 07:54.620 --> 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? 08:10.580 --> 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? 08:17.640 --> 08:20.720 Ah, yeah, so that's, that's the thing. 08:20.720 --> 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. 08:37.260 --> 08:42.260 So usually we start with a rooted smartphone, or a jailbreak. 08:43.240 --> 08:46.400 Or, I mean, also MacBooks have Broadcom chips. 08:46.460 --> 08:48.320 So and there you are already root. 08:49.140 --> 08:50.860 So it depends a bit. 08:51.440 --> 08:53.840 And then we would dump the ROM. 08:54.060 --> 08:57.680 And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the same. 08:57.960 --> 09:00.940 And for Wi Fi, the ROM also contains the U code. 09:00.940 --> 09:03.580 And the U code is the thing that runs in the D11 core. 09:03.580 --> 09:08.420 So what Francesco modifies, and for me, it's more the Bluetooth firmware. 09:09.820 --> 09:14.040 And then it's very annoying, because like the stuff is still without any symbols. 09:14.040 --> 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. 09:22.600 --> 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. 09:28.980 --> 09:32.520 And because of this really horribly loads into IDA. 09:32.680 --> 09:35.060 So it really looks ugly. 09:35.340 --> 09:36.700 Yeah, fair. 09:36.900 --> 09:42.520 And I think Francesco, for you, it's even the case that you get new instructions, right? 09:42.520 --> 09:49.580 Yes, for the U code, there is no actually corresponds between the U code and the any known CPU. 09:49.720 --> 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. 10:02.540 --> 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. 10:13.980 --> 10:24.460 So what helped is that Broadcom didn't change much the platform, since they introduced it 15 years ago. 10:24.460 --> 10:26.520 So they are additionally adding instructions. 10:26.520 --> 10:31.560 And 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:41.840 Bluetooth mesh. 10:41.840 --> 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. 10:47.840 --> 10:50.900 So it's so yeah, we did it in our team. 10:50.900 --> 10:53.100 But the mesh is not really interesting. 10:53.100 --> 10:55.620 I mean, it's just using Bluetooth LE advertisements. 10:55.620 --> 11:01.880 So from a, at least from a lower level perspective, it's nothing special. 11:01.880 --> 11:05.120 I mean, of course, implementations on top are interesting then. 11:05.120 --> 11:08.760 But I mean, I do a lot of lower layer stuff. 11:09.660 --> 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. 11:19.500 --> 11:21.500 Of course it is. 11:23.240 --> 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. 11:33.860 --> 11:36.200 And they also threw through a link in there. 11:36.200 --> 11:37.660 I just wanted to shout that out. 11:37.900 --> 11:40.800 Francesco also has done stuff with Bluetooth sniffing, right? 11:40.800 --> 11:42.400 You've built a Bluetooth sniffer. 11:42.540 --> 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. 11:57.040 --> 12:02.260 Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff. 12:02.260 --> 12:11.120 Is there like a minimum requirements for the SDR hardware to do that level of sniffing and for Bluetooth? 12:13.060 --> 12:18.200 Well, if you have SDR that can sniff 80 megahertz is better. 12:18.200 --> 12:26.280 But for sniffing Bluetooth classic, we demonstrated that it's enough to capture only 16 channels out of 80. 12:26.280 --> 12:34.560 Then you can also use one of these cheap SDR like, like Hacker F or Blader F. 12:34.560 --> 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. 12:43.840 --> 12:44.800 That's awesome. 12:44.800 --> 12:45.700 It should work. 12:45.700 --> 12:47.260 Yeah, accessible hacking. 12:47.260 --> 12:48.340 It's nice. 12:49.380 --> 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? 12:58.500 --> 13:02.280 I mean, so what you can actually see, and that's an interesting development. 13:02.280 --> 13:10.580 So on the first bug that Jan discovered with Frankenstein is one in the enhancing viral response. 13:10.800 --> 13:17.360 And when he submitted that one, they said, we already know the bug, and we just didn't find it anywhere. 13:17.360 --> 13:21.740 And then I got like the newest Samsung Galaxy S10e and extracted the ROM. 13:21.740 --> 13:26.700 And this one actually had a patch and it had a compile date of April 2018. 13:26.700 --> 13:31.780 And that also means like they cannot change the ROM, so they cannot tell us lies about the ROM. 13:31.900 --> 13:33.600 And we reported it afterwards. 13:33.600 --> 13:36.720 So that actually means they knew it before. 13:37.320 --> 13:40.480 But, and now that's the interesting part of the story. 13:41.140 --> 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. 13:49.820 --> 13:59.260 Now, the thing is, they definitely increased the security, I would say, after the bugs in 2017 were public. 13:59.260 --> 14:03.380 So, I mean, it took them a year probably to do some pen testing and so on. 14:03.380 --> 14:07.420 But you can see like 2017, the first public incidents happened. 14:07.660 --> 14:12.500 2018, the first kind of secret patches make it into the firmware. 14:12.500 --> 14:17.300 And also they started using like, I don't know, stuff like secondaries. 14:17.300 --> 14:18.680 They didn't have it before. 14:19.000 --> 14:22.820 So this is things that now are going into the firmware. 14:22.820 --> 14:24.780 It's still not like super perfect and everything. 14:24.780 --> 14:26.940 It's still, of course, closed source. 14:26.940 --> 14:31.340 But I mean, most firmware in wireless chips is closed source. 14:31.340 --> 14:31.560 Yeah. 14:32.560 --> 14:35.320 So at least they are trying to work on it. 14:35.520 --> 14:40.700 And I think they are there on that, like security by obscurity doesn't really work. 14:41.240 --> 14:42.180 Fair enough. 14:44.220 --> 14:51.060 So someone is asking where people could find the source code for that Bluetooth sniffer. 14:54.230 --> 14:55.190 Francesco, I think that's it. 14:55.190 --> 14:57.110 Yeah, I can send you. 14:57.110 --> 14:58.590 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:03.330 Yeah. 15:05.710 --> 15:07.210 And another one. 15:07.210 --> 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? 15:15.030 --> 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. 15:21.870 --> 15:24.350 But for Bluetooth, you have this master slave mode. 15:24.350 --> 15:29.250 So you can actually have a device like a smartphone is usually capable of being master and slave. 15:29.310 --> 15:34.750 Some like cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master. 15:34.750 --> 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. 15:44.610 --> 15:50.170 And I think there is, let's say, a sufficient fraction of popular devices. 15:50.170 --> 15:56.950 So it depends if it's in the operating system, then it would have to be like compatible iPhones or something. 15:56.950 --> 16:00.470 And I mean, if you just there's not much diversity in iPhones. 16:00.470 --> 16:06.470 So if you just take like the top selling iPhones or something that also would work on the chip base. 16:06.470 --> 16:08.350 On Android, you have more diversity. 16:08.350 --> 16:16.510 But still, if you would say you just pick the top Samsung and Galaxy, and maybe the pixels or something. 16:17.630 --> 16:19.250 Yeah, that could work. 16:19.250 --> 16:25.530 So Jan actually uncovered vulnerability in the Android Bluetooth daemon. 16:25.530 --> 16:27.670 And that one would have been vulnerable. 16:27.670 --> 16:29.730 And it was fixed in February. 16:30.550 --> 16:31.370 I mean, still, yeah. 16:31.370 --> 16:35.630 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:46.870 So the reason why I think people wouldn't build it is how do you control it? 16:46.870 --> 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. 17:00.050 --> 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. 17:14.870 --> 17:21.090 But I think even if it's vulnerable, I think this is nothing that people would build. 17:21.270 --> 17:23.910 But I mean, maybe someone builds it someday. 17:23.910 --> 17:27.870 So I won't build it because, well, I wouldn't. 17:27.870 --> 17:30.590 But I mean, maybe someone is crazy enough to do this, right? 17:30.670 --> 17:31.970 It's just true. 17:31.970 --> 17:37.350 I mean, you could potentially just do it without a financial motivation, just to see if it works or something. 17:37.570 --> 17:38.150 Yeah. 17:38.890 --> 17:41.970 So switching gears just a little bit. 17:42.570 --> 17:44.570 Did you guys report this to vendors? 17:44.570 --> 17:46.530 Like how was how did that communication like turn out? 17:46.530 --> 17:47.670 Was it positive? 17:47.770 --> 17:48.530 Was it negative? 17:48.530 --> 17:49.630 Was it? 17:50.350 --> 17:51.170 Tell me. 17:51.870 --> 17:58.670 Yeah, so the very first report about this denial-of-service was in August last year. 17:58.670 --> 18:00.230 So that's like a year ago. 18:00.270 --> 18:04.450 And I think they didn't really take it serious because it was just denial-of-service, right? 18:04.450 --> 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? 18:10.350 --> 18:13.130 So like writing FF to one register, it reboots. 18:13.130 --> 18:13.270 Okay. 18:13.270 --> 18:13.990 But who cares? 18:13.990 --> 18:15.350 Because you need RCE first. 18:15.350 --> 18:17.410 It's just it's hard to control. 18:18.690 --> 18:27.730 And interestingly, in September that year, the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me. 18:27.990 --> 18:31.510 So and so Jan was working mainly on Frankenstein. 18:31.510 --> 18:32.890 I also worked a bit on Frankenstein. 18:32.890 --> 18:36.150 And the coexistence was what I did with Francesco. 18:36.150 --> 18:40.610 So I was like, okay, if they also mentioned Francesco and me, they should have fixed it. 18:40.610 --> 18:41.510 But they didn't. 18:41.510 --> 18:45.490 So I was a bit confused that all the names were mentioned there in the iOS 13 update. 18:45.490 --> 18:47.490 And also a month is a bit too short. 18:47.490 --> 18:53.230 And everything that they patched but silently already before was the enhanced inquiry response issue. 18:54.210 --> 18:57.770 And then like I poked them from time to time, did you already patch it? 18:57.770 --> 18:58.570 Why didn't you patch it? 18:58.570 --> 18:59.330 And so on. 18:59.370 --> 19:08.190 And at 3063 on stage, I also showed that this is still unpatched and so on. 19:10.030 --> 19:12.090 And they still didn't patch it. 19:12.090 --> 19:13.910 And back then I already had in mind. 19:13.910 --> 19:20.210 So that was when I already called Francesco and said, like, in January, we are going to build speculative transmission. 19:20.250 --> 19:25.810 So that was, I was like, please get things in that direction of a text fixed. 19:25.810 --> 19:29.750 But yeah, and then end of January, I actually knew that this is probably unpatchable. 19:29.750 --> 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. 19:37.290 --> 19:40.030 What are you telling us? 19:40.490 --> 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. 19:51.870 --> 19:55.570 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: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. 20:10.030 --> 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. 20:21.970 --> 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. 20:31.210 --> 20:36.910 And then in March, when all the proof of concepts were also like, easy to run running and so on. 20:36.950 --> 20:44.710 Then I also started informing the other vendors who I found to have coexistence in their data sheets mentioned. 20:44.710 --> 20:50.450 So it's probably not everyone who uses it, but at least people I know that they use it. 20:51.850 --> 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. 21:02.450 --> 21:03.790 I'd be something else. 21:03.790 --> 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. 21:12.650 --> 21:15.510 And that coexistence is controlled by that one. 21:15.890 --> 21:18.290 Was it CC10 chip? 21:18.290 --> 21:21.090 I forget the name of the chip. 21:21.090 --> 21:23.250 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:34.750 Yes, it's controlled by this low level stuff, because it must be real time. 21:34.750 --> 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. 21:45.570 --> 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? 21:53.550 --> 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. 22:08.230 --> 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. 22:18.930 --> 22:22.610 So there is no way for the host to understand what the U-code might do. 22:22.610 --> 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. 22:29.310 --> 22:35.990 But so is this something that could like proactively drop packets with like a magic value or something like that? 22:35.990 --> 22:36.730 Yeah, yeah, yeah. 22:36.730 --> 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. 22:53.390 --> 22:56.050 This is totally unnoticed by the host. 22:58.970 --> 23:00.650 That's awesome. 23:01.690 --> 23:05.850 What are the next areas that you guys are looking into for like future research? 23:05.850 --> 23:07.530 Do you have anything already lined up? 23:07.530 --> 23:09.030 Anything you can talk about? 23:09.610 --> 23:12.410 Probably the can talk about is the part, right? 23:12.410 --> 23:17.110 I mean, obviously like wireless security, but yeah. 23:17.110 --> 23:19.670 So there will be stuff coming up. 23:20.310 --> 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. 23:37.970 --> 23:39.010 Fair enough. 23:40.330 --> 23:42.170 Yeah, I'm running out of questions. 23:42.170 --> 23:45.130 We do have a couple more people that are are typing now. 23:45.770 --> 23:46.450 Yeah. 23:47.670 --> 23:49.330 So I mean, we've got a few moments. 23:49.330 --> 23:53.970 Is there anything that you guys want to talk about proactively that we haven't already covered? 23:55.610 --> 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. 24:12.310 --> 24:17.670 But actually, we have been working on this, I mean, since much longer time than this. 24:17.670 --> 24:22.550 So it's nothing that's like connected to Corona or something in that sense. 24:23.730 --> 24:30.890 And also, I think like, for average people who just keep their system up to date and just use it. 24:30.970 --> 24:34.330 I don't think that it's like a big threat in that sense. 24:34.330 --> 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. 24:46.990 --> 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? 24:58.370 --> 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. 25:09.070 --> 25:10.210 It depends. 25:10.210 --> 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. 25:20.270 --> 25:21.250 It really depends. 25:21.250 --> 25:24.610 It really depends on your on your level of paranoia, of course. 25:24.610 --> 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, 25:42.230 --> 25:42.610 right? 25:42.610 --> 25:47.550 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: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. 26:15.510 --> 26:19.130 And that's, that's the part here, like they have been insecure for years. 26:19.130 --> 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. 26:29.150 --> 26:32.790 And so I wouldn't really say like, we are making it more insecure. 26:32.790 --> 26:38.970 It's really like kicking them somewhere and saying like, please, please fix it, make it better. 26:39.190 --> 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. 26:48.410 --> 26:52.230 And yeah, so I hope to move it a bit more in this direction. 26:52.310 --> 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? 27:01.810 --> 27:04.010 Or are they all kind of roughly the same? 27:05.050 --> 27:08.090 There are at least some that are more obscure than others. 27:08.090 --> 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. 27:19.630 --> 27:23.850 And then there is two for IDA, but they also don't support like all commands. 27:23.850 --> 27:28.670 Then you just have disassembler and not the compiler, Ghidra you would also have the compiler. 27:28.670 --> 27:33.710 So it's really bad quality of those tools for Qualcomm. 27:33.710 --> 27:38.970 And then still last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug. 27:38.970 --> 27:42.410 And they, so after the talk, I just went to them, I was like, how did you find it? 27:42.410 --> 27:44.230 I said, just like static reverse engineering. 27:44.230 --> 27:46.410 I was like the hexagon, right? 27:47.710 --> 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. 28:03.430 --> 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. 28:10.010 --> 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. 28:25.390 --> 28:30.810 So it just, it could have the budget to make it secure if they wanted to make it secure. 28:30.810 --> 28:32.090 It's no guarantee, right? 28:32.090 --> 28:32.730 Right. 28:32.730 --> 28:33.530 Fair. 28:34.510 --> 28:41.990 And the last question that I think that we can take, and this one's not directly about your presentation. 28:41.990 --> 28:46.970 Someone 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:00.130 So for his lectures, he's using OBS and he has a white wall. 29:00.130 --> 29:02.090 I mean, I also have the white wall behind me, right? 29:02.090 --> 29:05.330 And then I point with my hand and this is the part that I'm filming. 29:05.330 --> 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. 29:13.550 --> 29:17.630 So behind it, so then I have the layers and I can do the the pointing. 29:17.630 --> 29:19.390 So this would be the pointing. 29:20.010 --> 29:20.870 Nice. 29:20.870 --> 29:23.710 I'm sure some other presenters will appreciate that touch. 29:24.970 --> 29:25.630 Okay. 29:25.630 --> 29:27.830 Well, that's all the time that we have for you. 29:27.830 --> 29:30.250 Thank you both for joining us for the Q&A session. 29:30.250 --> 29:39.210 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.