 So, Dennis, the left speaker, finished his Masters of Science and IT Security this year. The next talk is based on his Master Thesis, Internal Blue, which is a Bluetooth Experimentation framework for which he even received a prize. Yiska, the right speaker, for you left speaker, has been his supervisor during the Thesis and she loves breaking things. After several talks about wireless security, software defined radio and fixed bits, she's now talking about Bluetooth. Please welcome on stage Dennis Manns and Yiska Klassen to their talk, Dissecting Broadcom Bluetooth. Thank you for the introduction and welcome you all to our talk. I'm Dennis and as said, I choose Bluetooth as the topic for my Master Thesis. The outcome basically was I reverse engineered the firmware of a Bluetooth controller, which was manufactured by Broadcom, and I built a little experimentation framework around it. And today we are not only going to present the framework, but also various kinds of use cases around it, and we also brought along some demos. Now if you start such a big reversing project, you certainly know that this will not be an easy task and also quite time consuming, so you might want to ask, why did we do that in the first place? So there are several good reasons. One, dissecting the firmware and exploring it through reverse engineering is really helpful if you want to get insights from a security perspective, and this is what I had in mind when I first started my thesis. But then secondly and even better, once you're able to modify the firmware, you can actually leverage this fully featured and working Bluetooth implementation to be your very own experimentation platform, where you can add new features or can also alter existing behavior. And it almost feels like you can add a kind of an open source touch to a closed source and proprietary platform, which I really like about this project. Certainly this requires certain background in like many different departments like security, code analysis, wireless signals, embedded programming, and also not every researcher has resources and time to do such a reverse engineering project. But we think that the outcomes of this project are really helpful and beneficial for the security community. So, and last but not least, we actually really like reverse engineering. So we already had great experiences with similar projects in the past. For example, some of you might know the next month project where we reverse engineered and also modified the firmware of a Wi-Fi controller. OK, before we show our work, we first have to introduce a few Bluetooth protocols, which we will be mentioning quite a lot throughout this talk. So the first one would be the host controller interface. Some of you might know that it's the HCI and it's a protocol layer between the Bluetooth controller and the host system, where the host system would be, for example, an Android phone or iOS or Linux or any other operating system, which implements those upper layers of the Bluetooth protocol stack. And all the lower layers are actually implemented inside the Bluetooth controller and one of them would be, for example, the link manager protocol, the LMP. And this one is also really interesting. It actually manages connections to other remote Bluetooth devices. For example, pairing is also done on this protocol layer. And what's an interesting difference is that the link manager protocol is actually transmitted over the air to communicate with other devices, whereas the HCI protocol is only used locally to communicate between the operating system and the Bluetooth controller. And another interesting fact to know is that the HCI is actually able to be observable from the host side. So if you maybe tried to capture on a Bluetooth interface in Linux before or if you turned on the BT Snooplock feature under the development settings in Android, you probably have seen HCI packets in Wireshark before because this is an easy task to do. However, you probably did not see LMP packets in Wireshark before because this protocol layer is actually implemented inside the controller and it's not observable from the host side. You won't see those packets if you just capture on a Bluetooth interface because you can only see what's above the HCI layer. And so the other thing is that you cannot also simply sniff this from the air because Bluetooth has frequency hopping and encryption, so it's a lot harder to sniff those packets from the air just as with Wi-Fi, for example. But today we try to change that. Now I will introduce the framework I developed and show its features and then later we go into more details and also present some demos. As already mentioned, we named the framework internal blue. It's open source and you can find it on GitHub. Currently it's only compatible with the Nexus 5 if you want to use all of its features, but we are also working to port it to other Bluetooth chips and other smartphones and also other platforms like the Raspberry Pi. And soon you will have more devices which are supported by this framework. We also already gave a talk where we introduced the framework and give some details about internals and how it works. So if you're interested and want to learn more, then you should check out our previous talk which was also recorded and you can find the link down at the bottom of the slide as well. Basically in the nutshell we use vendor-specific HCI commands which are implemented by Broadcom and allow us to read out and modify the firmware while the chip is actually running. And on top of this we basically implemented a Python API to interact with the firmware and we used this API to then implement all kinds of features which we find interesting. For example, one of the first things we did was implementing such a LMP monitoring mode so that we can finally see LMP traffic on our laptop in Wireshark. And what comes along with this is that we are also able to inject arbitrary LMP packets inside existing Bluetooth connections. And this turned out to be also very interesting because then we can test how other devices react to maybe packets they don't accept or at least it's very good for experimentation. And for example, we used this to write a little proof of concept script for the fixed coordinate invalid curve attack that was released this summer, not by us but by other researchers. And we were able to actually prove that other devices are vulnerable to this attack. So this is a really helpful and practical tool. Also, at some point, we found Crash our own. So we found a bug in some older Broadcom firmwares which allows us to remotely crash the firmware in some of the Broadcom chips. And in some cases, we're even able to execute a limited set of functions. So this might be even more interesting than just a crash but more on that later. Now, if you first start with the main thing about this is how do we actually modify the firmware? How is patching done? And I already said that Broadcom uses those vendor-specific HCI commands to read them out, their read RAM, write RAM, and launch RAM. And they do exactly what you think they would do. So basically, we're able to read and write in the address space of the firmware and also to execute arbitrary code snippets in the context of the firmware. And this is pretty powerful. Broadcom actually uses this to do their firmware updates. So they ship so-called HCD files which are files that contain firmware updates. If you have a Broadcom chip inside your laptop or inside your phone, you should find such a file with the extension HCD on your file system. And those files actually contain just a sequence of those commands to upload all the changes and patches. And they're even able to do temporary patches to the ROM of the firmware by another mechanism that they call PatchRAM. We also had to reverse engineer this and now we are finally able to do all those patching ourselves. Now, what is also interesting is that those files, the HCD files are neither encrypted nor signed. So it's quite easy to actually modify them once you understand how they work. And also the firmware itself on the controller is not obfuscated. So there are basically no major attempts done by Broadcom to prevent anyone to reverse engineer and modify this firmware. Currently, we write our code in assembler. So we write assembler patches, but we're working on including this in our next month project to finally be able to write patches in C code, which will be more comfortable and portable. First, of course, we have to do the reversing. Yeah, so as Dennis told you, the code is not obfuscated, but there is no strings and no function names. So you end up with thousands of functions that just have no name. It's just sub one, sub two, sub some thousand something. And then there is a tool that I used which is called CodeCard to try to separate those function into modules. But also the modules don't really tell you that much because the problem is then you have hundreds of modules and then you know which modules are central and you might to start reversing, but it's not really fun. You have 2,800 pages of Bluetooth standard. You might have some parameter checks in there. So we have bounds which the parameters should be in. And then you search for those numbers again in assembly code and you might find some matches and then you have a concrete functions. So that's what we both did for months, staring at standards, staring at the code. Then people asked me, yes, yes, yes, that's not nice, but does it work on recent devices? And now the problem is even the Nexus 6P has a firmware from end of 2014. So I just decided to buy a development board which has also a slightly outdated firmware, I mean just one year old. Meanwhile, this part of Broadcom was acquired by Cypress so it's called Cypress, but it doesn't matter, it's still the same mechanisms in there. And I was able to use the same HCI commands. So I can still modify the firmware on this. I can extract the firmware. And actually I just got that on December 6th and three days later I had all function names because somewhere someone forgot a patch.elf with all function names in the development kit. So that's 11,000 function names, 3000 object names. Nice, yeah. So by development kits earlier. Okay, let's get closer to the first demo. So as mentioned, we have this link manager protocol which does interesting things like pairing and all kinds of stuff. And it's implemented in the firmware so we cannot really see it from outside, we cannot capture it in Wireshark. And we wanted to change that, so we wrote a patch that will actually hook some of the functions inside the firmware, those that are handling LMP to actually forward all the traffic over the HCI interface back to our Android phone. And then on the Android phone we use an Android Bluetooth stack which has debugging features compiled into it so that we can also forward all the HCI traffic via TCP to our host computer. And from there we can then show it in Wireshark. We use a custom LMP dissect the plug-in which we borrowed from the Ubertooth project. And yeah, that's it, we have a LMP monitor mode. I will show that in just a second. We also have an LMP injection mode. So we can simply invoke functions inside the firmware and so we can also invoke the function which actually sends LMP packets to other devices which are connected to our Nexus 5. And so yeah, with this we have both channels of the communication and can actually send arbitrary traffic to other devices. So for this, let's go into a command line, start the framework. The framework has a command line interface where you can use all of its features and like interact with the firmware and to start the monitor mode I can just type this command which will start a Wireshark instance and also install all the patches which we need into the firmware of the phone. And now from this time on we actually have all LMP traffic forwarded and shown in the Wireshark frame but currently we don't have a Bluetooth connection that's why you don't see anything. Okay. Okay. Yeah, so we still need a Bluetooth connection, right? I could just pair those devices to create a connection and then we would see LMP traffic but I wanted to show something else. So this will be a combined demo actually because Bluetooth has some more interesting features which maybe not everyone knows, at least for me that was a surprise when I first learned about it. So even if your device is not being said to be discoverable by other devices it still accepts connections from any other device. The other device just needs to know your MAC address and can simply connect to you without even being paired before. You don't even notice this because the device doesn't have to trigger the pairing process and then the user won't be notified. And so by just finding out the MAC address of any other device, I can connect to it on this LMP layer and start communicating with it. And finding out the MAC address is also not that hard. There was another talk which we mentioned down at the bottom of the slide. It's called Bluetooth Smells Like Chicken by Dominic Spill, Michael Osman and Mark Stewart which shows that this is actually possible and not hard to do. So I can actually just type connect and give it the MAC address of another phone. So we need it again, we need it, yes, great. Yeah, perfect. So on the right side you actually see an Exos 6P which will be our target. You can hopefully barely read the MAC address which is shown there. On the left side is the Nexus 5 which is the phone we use for testing like the phone which is connected to my laptop here and is used for internal blue. And as you also can see, the Nexus 6P is currently not in the Bluetooth menu so it's not actually discoverable by means of Bluetooth. I still can connect to it when I actually type connect and the MAC address. This might maybe take a few, no, worked directly, perfect. So now you can see that we actually have traffic on the LMP layer. What you also might notice that on the Nexus 6P there wasn't anything. So the user didn't notice but I have now an established connection to this other phone and you can see the LMP traffic which is going on this protocol layer. As you can see, this is quite a lot. There are feature requests, version requests, also name requests so that the phones know how the name of each other is. And yeah, from now on I can also try and inject arbitrary LMP packets. For example, I can send an LMP packet with opcode one which would be a name request and ask for the name at offset zero. And you should see that the name request has popped up here and the other device even answered with its name if we scroll down here. You should at some point see that we have the name Nexus 6P because we don't rename our devices. But I can also send like arbitrary LMP packets so I'm not bound to anything that is in the specification. You've already got the detach. So the other device actually detached which happens from time to time can reconnect. So if we don't do anything in between we will get a detach from the other device because we didn't do a pairing or something so we reestablished the connection and now Dennis is going to send something that is not specified just LMP 99. So it's even saying here this is unknown but as you can see the payload is actually sent and the other device correctly answers with this is not accepted, I don't want this. But you can probably see that this is very interesting for a security researcher because now you can see how the other device happens in certain conditions if you send them certain packets and yeah, quite nice to actually experiment with. Okay, I think that's it for the first demo. Let's stop this and go back to the slides. You don't need to in-screen anymore? Yep, great. Okay. Thank you. Another thing in a Bluetooth standard is that you need a possibility to pair devices which have no input and no output capabilities so they cannot show a pin and you cannot enter a pin and this is the standard for any headset but also a man in the middle can change the input-output capabilities and then you might just get displayed this yes-no pairing without a pin request even though your smartphone could show more than this. And I have a demo video again of the same thing that's this one so on the left-hand side I have again a Nexus 5, on the right-hand side I have an iPhone and I'm pairing them. I just changed the request in the capabilities that I'm not having input-output capabilities so you can see on the right-hand side on the iPhone it's just showing this yes-no question and on the left-hand side you still have the same algorithm which just does the same thing. So pairing will succeed. There's the same cryptographical routines but you are not being warned on the iPhone and that's a bit critical so the standard is not saying please warn the user to check if the other phone really has no input-output. So I just say pair and it pairs. Yeah. So far that's only things that are as they are in the standard so it's not too surprising. So the question is can we find more bugs? Yeah, finding bugs in Bluetooth. Actually, I didn't even want to find bugs in the beginning I just wanted to understand how everything works so I went through the handlers and I checked there's this checks of the parameters so there is a parameter check in the beginning of each handler that shows me a bit which handler it could be according to the standard and suddenly there is a handler which does not have any check so there's just a missing if somewhere. And then I compared the firmware versions that I had and found out they silently patched that already someone between June 2nd and August 19th in 2014 but they never updated all the devices so they never shipped an HCD patch. So I contacted Broadcom and said yeah you have a problem and they said no we don't and I said you really have a problem there and so on and then they said nah it doesn't exist and then I showed them more and then they said yeah okay but it's not compliant to the standard what you're doing. I'm sorry my next exploit will be standard compliant. And then we discussed a bit more and then they said it does not affect Wi-Fi performance well in my test it did whatever. Doesn't matter. So basically you can switch off Bluetooth on another device and then Bluetooth restyles typically depending on configuration. And as Broadcom didn't tell me much about this I started testing out things on my own so which devices actually still have a firmware that is affected in their Broadcom chip. It's quite a lot. So it's like the iPhone 6 MacBook Pro from 2016. Of course my Nexus 5, Raspberry Pi 3 and so on. And this list is really not complete this is just like I asked my students can I test your smartphone some of them said no are you crazy. And that's the list I got just during the last weeks. And this is the one I'm going to demo. I just named it BTB Gun so you can kill the Bluetooth of annoying songs or something. Yep so I need to go into the Bluetooth here. That's great I even had a Bluetooth is not real and so on that's really great what is going on here. Yeah let's go for the demo. So first we are going to patch the Nexus 5 with our funny attack and then I just press enter and now it takes a while until the iPhone is realizing like oops my Bluetooth is gone. So if I'm playing music you will see it faster the music would already stop playing. Let me just enter another time just yes and there it's gone. Oops. And then it appears again. And so now I can just do it again and again and again and it's actually so fast that the other person could not play music because music also stops playing after this disconnect. Yeah that's that demo. Now we were wondering what is actually happening. So actually the crash is the best case. So there is a handler I call it handler A because I'm not leaking the actual problem here. Broadcom didn't fix it yet. So there is this handler which just should take let's say two arguments or something but it doesn't check the parameter range and the compiler likes to put one handler after the other and then we just go into the next handler and so we have something like 250 functions that we can call from the next handler but with wrong parameters so it's a bit buggy and sometimes if a function expects to get other parameters it just crashes but otherwise we can execute functions and on the Nexus 5 we looked a bit more into this and I found out that I can enable test mode. So test mode should be something only locally to be enabled on a phone if you have root access to the driver and then you tell the driver I'm now going to test your frequencies and so on please go on test mode but I can now do this remotely. So I didn't bring this one as a live demo. I mean I have a hack RF with me if you can do that during Q and A because the problem is there's probably too much going on in the spectrum here and you wouldn't see the test mode starting anyway. So I'm just doing the attack and then on the left hand side I just do the quick pass you can see the test mode so that's just the default test mode hopping around in all channels. The packets now appear a bit out of order because I just put them into a queue, send them. This question mark payload is the malicious payload. I just say test control and test activate and first they get this not accepted and then after this question mark payload you can see that it's accepted and on the left hand side you can still see that there is the test mode going on so really block things for a longer time and then it's accepted magic. Yeah. If you combine this with disabling adaptive frequency hopping you can even force the other device which is also done in test mode to stop hopping for a while and then just jam a selected frequency so you could also jam a selected Wi-Fi frequency that this device is currently using and it's a combo chip so you would really be on the same antenna. We can confirm this works on Nexus 5 and Xperia Fats set three because they both have this BCM 4339 chip it might also work on other devices with that chip. It's a bit random to find out what is in there. You need to find teardowns and so on. So when finding this bug we started developing a tool chain so Dennis added a feature for trace points you can add now a trace point to a function which is then called once and dumps all the registers and the stack and heap. I then fed this into an emulation framework which is currently quite slow with Unicorn and Radary 2 but I get a full call trace which is very nice to look at so I have an idea of what is going on what is changed in the memory and I currently also have a student working on QEMO-GDAB set up which is faster but producing less output just to fast more efficiently. However, you get really a lot of output that we weren't able to completely analyze yet so there's probably more maybe tell you something later. Now you need to somehow fix that bug and that's really a problem and that's also why I didn't tell you the exact payload that is causing these issues because the fix would be in one of those HCD files it would be plain text, it would not be signed and it would just tell you directly this handler is vulnerable in exactly this position and so on. The patch is just 14 bytes but you need to install it and then it's easy to understand what it does, right? So I had the idea, let's do some more generic fix so what I planned to do was having a generic filter filtering some packets like that you won't reply to Pings connection establishments and so on to entrusted devices and then just over Christmas I started testing that one with bigger setups or with more phones and so on and then I realized, okay, if I throw away some packets and the other device does not expect me to throw away packets then the Bluetooth stack of device which now tries to connect to me is going to crash. So I had the next bug so I try to fix one bug, I get the next bug, you know this. So I actually cannot release any fix because all of them still cause the next bug and so on. So how long will this bug be around pretty long probably because there is some devices which are no longer getting vendor updates. It needs to be in the vendor update, it needs to be this special HCD file and so on. I mean, we can also publish HCD files if needed. That's possible with our framework, that's the good news but it will probably never be an official update and the vendor updates will obviously leak the vulnerability so it's chicken egg. As we found this bug still to be present in devices that were produced in 2016, we recommend you to turn off Bluetooth, especially if you have a Broadcom chip set produced before 2017 but in general just turn it off, that's probably the safest option. And we found out that very old devices having something like Bluetooth 3.0 are not vulnerable because that feature that we used didn't exist back then but still it's a large number of devices having this issue. So thanks for listening. And again, if you have questions, we have eight microphones in the hall. Please line up at the microphones and you can ask your questions. The signal angel has the first question from the internet. Yes, so from the internet, ask whether you can guess the Bluetooth MAC address from the Wi-Fi MAC address of a device. So if I go into, can we switch the camera on again on my magic box here? Is that possible? Yes, so actually if you go to the settings about and then you will see that the Wi-Fi and Bluetooth MAC address they are just off by one. So yeah, you have to know, however, that this is not the case with every phone. So usually I think newer phones actually try to randomize their Wi-Fi MAC address to be not traceable anymore. I'm not sure which devices do that. I think the Nexus 6P does that. So the first part will be the same because it specifies which vendor this chip was made from but then the lower and least significant bits will change. So it's sometimes possible, sometimes not. Yeah, I think that's the answer to this question. Okay, the next question was from the microphone eight at the very end of the hall. Hello, thanks for your talk. I was wondering in your second demo, you showed us how you connect to a device just using the MAC address and this device was not advertising his name. How do you plan the MAC address if it's not advertising? Yeah, so there are ways to find out the MAC address of devices which are nearby you. So for example, if your device has Bluetooth turned on but it's not discoverable at the moment but you're listening to music on your headphones or if you have a smartwatch connected or any other Bluetooth device connected, then you will certainly send Bluetooth traffic and you can sniff that from the air. For example, if a software defined radio or an Uber tooth and so in the talk we mentioned and we also have a link to this in the slide, I guess it was here, Bluetooth smells like chicken, Michael Osman and Dominic Spill, they actually explain very detailed how you can then infer the MAC address from those packets you sniffed. And yeah, it's doable, it's not as easy as with Wi-Fi but it's certainly possible. Thank you. Okay, the next question was at microphone number one. Thanks for your talk and for demos. The question is, does this firmware have any mitigations against exploitation? And if we imagine that it has, would it help against such bugs? So there's no real address randomization, kind of the obvious way because most of the things are actually global offsets inside a firmware so everything is at fixed addresses like you would use global variables all over. There's also the RAM is actually executable so you can execute on the stack, you can execute on the heap everywhere so there's no real mitigations for such an exploitation. It's like, I don't think even the newer ones have this for the Nexus 5 obviously. And another thing that really helps is so LMP has a version request, version response which is always sent so I can ask a device, do you have a vulnerable firmware and which version and then I can run exactly the exploit and the firmware is standard and I can just run with the addresses that I know for the certain firmware. Okay, the next question was at microphone number two. Then again number one, three and five. Hi, thanks for the work especially for BTBGUN, seems like it's the new TVBGUN. I'm not sure with which kind of iPhone that works because you had a slide about iPhone up until six and then you had a slide that's saying if the chip is older than 2017. So does that work with the last phones as well? Only up to iPhone six that was the newest iPhone I could get so if you have an iPhone eight or something our attack does not work. Sorry? Are you gonna work on it because a lot of people are playing very bad music they have newer phones. You mean, so the attack, the attack is not working on iPhone six but the general framework like patching, HDD files or changing the firmware will obviously work on any Broadcom chip. Okay, thanks. Broadcom actually uses this mechanism for all their chips, all their Bluetooth chips. So you can use this framework for every Broadcom chip, every device that has a Broadcom chip. You only need to do the reverse engineering to get like the real addresses and offsets inside the firmware to do meaningful patches. But for this you always need to be to have a router device, you need root access on device to run our patching framework. Okay, thanks. Okay, now the question at microphone number one. Do you have a list of vulnerable chipsets so I can check if my phone is vulnerable if it's not in like, in the slides? Yeah, but it's very incomplete. So I also have the version numbers and subversion numbers of those phones but just consider the time range. So if your smartphone does Bluetooth 4.0 to Bluetooth 4.2 and has a Broadcom chip then it's very likely to be vulnerable. Okay, now the question from microphone number three. Thank you for the code and the talk. Quick question. So have you looked at car Bluetooth? And if not, are you thinking about it? So I actually used this tool. As I mentioned previously, we are also able to test other vulnerabilities. For example, this fixed coordinate invalid curve attack. And so I used my tool to actually check if a car radio was vulnerable to this fixed coordinate invalid curve attack that was released this summer. So it's basically patched since half a year but the car was still vulnerable to this. So the framework is basically usable to test car radios as well but I haven't like specifically looked into car radio. Thank you. Okay, now the question from microphone number five. Then we will take a question from the internet and microphone number six. What is the attack surface exposed by your exploit? What's the worst case? Could you manipulate memory or something? The worst case is hard to estimate. I mean, we can change some memory addresses at least in the Nexus 5. And for each smartphone, there are other functions by the compiler put there. So to really know what is happening, we would now need to analyze like really tons of firmware and check what is in there and do some fuzzing. We already found out that some things only happen if you combine multiple packets and so on. So it's really hard to estimate what is the worst case. So the very worst case would be so to say that you can run arbitrary code in the Bluetooth firmware itself. And then the next worst case would be if there would be another vulnerability in the driver that you could escape the firmware. So that would be the next step, but that really requires an exploit chain. So the very worst case would be something similar. So there has been vulnerabilities in the Wi-Fi part of a program chips where you had the possibility to really run an exploit chain which then rooted a device in the end. But it's hard to estimate if you can do it with this or not. Okay, now the question from the internet, please. Do you know if any older but still supported devices like old MacBooks are patched and can the US actually detect this in any way other than the chip crashed? Not really. So we can try to not crash the chip by first checking if it is sending appropriate answers, but typically the really only thing to be sure is that it crashes. So that's so far the only way because I mean, obviously if Broadcom would tell the following chips are vulnerable, which they didn't so far because that's also to protect themselves probably, then you could be sure. But yeah, as of now, that's the only way to check it. Thank you. Now the question from microphone number six, please. Yeah. Would it be possible to increase the Bluetooth radio transmission power by patching the firmware? So that Bluetooth works across entire buildings and not only in a similar room. Yeah, so the thing is we are actually now patching the firmware of the chip and the firmware does like all the link layer stuff of Bluetooth. The real physical part is probably done in another component inside the chip, which may be running another kind of small real-time firmware and we haven't found that yet. We're still looking for it because it must be in there somewhere like the Bluetooth modem. And maybe we can actually change the settings for this modem. I don't think it will be too drastically, but maybe if you're in different areas of the world and like your Bluetooth has different strengths and different areas of the world, you can maybe manipulate that. But we haven't found it yet. Okay, thank you. Okay, next question is coming from microphone number four. Does Bluetooth chip set have access to system rain? Sorry, I didn't get the last word. The system writes or what do you mean? System rain, memory. You mean the memory of the main processor like where Android or iOS running on? Yes. No, it's not like as with Wi-Fi where you have direct memory access, but Bluetooth, the HCI interface is the only interface between those two processors and this is usually done over either USB or in the Nexus 5 is actually UART. Okay, next question is coming from microphone number three. Many thanks for the enlightening and scary talk. I missed a little bit of the beginning, maybe that question was inside there. Did you or do you consider to disclose this vulnerability, for example, to BSI, Bundesamt für Sicherheit und Informationstechnik? As I would consider their obligation to inform general public like put a note on their website saying, look, if you are running a certain smartphone, you are vulnerable to a certain attack and that would put much more stress on the vendors to really look into this. Yeah, that sounds like a good option. So far we are, so we asked Broadcom when we can publish things and at least they agreed that it's no problem to publish it in summer, then it would be public for everyone, but yeah, BSI would also be a nice option. Thank you. Okay, is there another question from the internet? Only. Please switch on the microphone for the internet. Hello. Hey, so do you know if any devices have been patched yet, which have not been released after 2017 or are there no rolled out patches? I don't think so. So it took Broadcom two months to actually confirm that there is this vulnerability. So on December 3, they said, oops, it really exists. And then on December 9, they were like, ooh, do you really plan to do that talk here? And I did the most recent iOS update on the iPhone 6 that I just showed you. And this one is still vulnerable. I think it takes some time for testing. So I would say the first patches will come out maybe in one, two months, but we don't know. Okay, one last quick question from microphone number one. So is it, do you think if it's possible to trace back when was this vulnerability introduced so we can go back and try to hack all devices that probably have the same firmware or firmware vulnerability because they should be backward compatible, right? So if the same handler is implemented, I don't know, in 2012 for the first time, then probably the devices can be narrowed down, right? So at least, so the Nexus 5 has a firmware from 2012 actually. So somewhere, so the Thune 2 is when it still existed in 2014, I don't know. So in each firmware, there's a build date and I would then need to extract the firmware of vulnerable devices and so it's a long process, but at least the vulnerability was there for multiple years. Okay, now give please a huge round of applause for Jeska Klausen and Dennis Mons for their talk. Thank you.