 Okay. Can you hear me? Is that okay? Welcome everybody to our talk playing with Bluetooth. For the beginning, a quick question. Who was here last year when I gave the talk about Bluetooth? Is there anybody who already saw the talk? At least a few hands. Cool. So there will be some things that we repeat, but other things that are definitely new, because in this year there was a lot going on with Bluetooth. Basically, last year I was here talking about Bluetooth, talking about my master thesis, and since then Yiska took over the project, and also many other students joined the project, and so this will be like a wrap-up of everything we did. And yeah, my name is Dennis. I'm a security analyst at ERW, a company in Heidelberg, and I was a former student here at the TU with Yiska as my supervisor. Yeah, I'm Yiska. I work here, so it's the lecture hall where I sometimes give lectures, so it's very nice to be here. Yeah, so the motivation. Since I started doing this Bluetooth stuff, I'm following the Bluetooth SIG on Twitter, more for the fun, because they have like really funny tweets. I think according to their Twitter account, I would assume that they gained the power over all of the world just with Bluetooth, so it's really hilarious tweets. And if you follow their Bluetooth market update, it is like four billion device sales just in 2019, which they approximate, and then it was like, wait, what is world population? So you would buy something like half a Bluetooth device a year. I definitely buy more, but it's only for research. So what is Bluetooth actually? So I've been working with Bluetooth for a year, and so I still don't know. I really still don't know what Bluetooth is, I have to say, but it is blue. So can you tell me, what is Bluetooth? You've been also working with this? Yeah, I actually wrote a thesis about this. Yeah, you have to know, you need to tell me. Basically, as you already said, it's a 3,000 page long standard, trying to define a wireless communication protocol or protocol stack that can be used to like communicate between personal devices. And yeah, in the standard, basically it's everything you should imagine when you think about Bluetooth that it's a system compared to like the TCP IP stack, but you put in there also the physical layer. So for example, put in the whole Wi-Fi physical layer and then also put in things from the application layer, for example, HTTP, and then put it all together and then you have a system like Bluetooth. And yeah, what could possibly go wrong? So basically, many things did go wrong, and we tried to categorize them in different layers and different sections where we could basically, yeah, take the root cause of them. And we begin with the user itself. So in Bluetooth, it's still the user has to burden of also contributing to the security of its connections. So for example, if you pair with a Bluetooth device, you usually get presented with a pin. And if you don't do this pin comparison correctly, then you might be man in the middle, for example. Then there's other things and problems with, for example, the implementation of Bluetooth inside the various operating systems, because a huge part of Bluetooth is basically implemented for each operating system. So Android, iOS, Windows, Linux. And one famous incident was basically the release of many vulnerabilities under the code name Blueborn. Some of you might remember that. That was quite a shock because there were so many different vulnerabilities targeting all kinds of operating systems. So Windows, Linux, iOS and Android all were affected, some more than the other. So for some, they were remote code execution over Bluetooth. For others, there was things like you could basically intercept IP traffic from the device over Bluetooth. And there are also other kinds of attacks. So for example, the Nino attack we already showed in some of our previous talks, which is the no input, no output attack, where you basically just try to man the middle, pairing set up by manipulating how the devices communicate with each other, because basically what they do when they pair to each other is they tell each other, okay, I have a display or I have a keyboard. And based on that, they decide how secure the connection can be. Because if both devices say, hey, I don't have a display, I don't have a keyboard, how should you compare a pin? And basically an attacker can just go into this connection before even the encryption starts and say, okay, we manipulate this communication. And both devices think the other has no display. Things like that. Then there's other things that did go wrong with the standard itself. So as I said, the standard is almost 3000 pages long. There's a lot that could go wrong there. And also Bluetooth is quite old. Back in the days, they use crypto, which was not as secure as today. So for example, they use this safer plus cipher, which was not secure and broken in 2005. Then later, they when they introduced Bluetooth low energy, they, they introduced it less secure than the current Bluetooth standard was already. So it's Bluetooth, Bluetooth low security. You could say that. Okay. Not only low energy. So basically Bluetooth, the classic Bluetooth and Bluetooth 4.0 was already using a very good pairing mechanism, which based on authenticated Diffie Helman, and then with low energy, they tried to make it more usable and also less secure. And later they fixed that again. And then, for example, if you were here at my talk last year, I showed a demo of this fixed coordinate invalid curve attack. This is basically also an attack that can be backtraced to the standard because in the standard to define how the pairing mechanism works, it's elliptic curve Diffie Helman. And basically they did not specify that a certain key parameter should be checked on both sides after they exchange keys. And because they left out this important note, most of the vendors just didn't check. And so all of them were vulnerable for this attack, which I showed last year. So if you want to see a demo of it, you should go back to the stream we had last year. And then quite recently, there was also another attack called the knob attack, where an attacker can basically force the device to just use one byte of entropy for its key, which is also ridiculous. And last but not least, there is implementation issues in the firmware itself. So this is also some things that are quite hard to do research, but it's place where we also did a lot of research because we tried to dig into this Broadcom firmware and find out how it works and also if there's things that could go wrong. Yeah, in one second, so now to say for the knob attack, so it was not us doing this, but they used internal blue. So it's a good thing that we did it. People are using our assembly handwritten code. It's great. So there's a lot of things that are not really a security feature. In Bluetooth 5, they introduced this fancy hopping scheme. So usually you would have something like 37 data channel and then you just hop around them. And once you reach the last, you begin again with the first and go in circle. And then they said, yeah, let's do it a bit more random and let's implement a funny pseudo random number generator. But basically, if you know the connection parameters, you can pre calculate the whole sequence, which is 65,000 entries, and then you can filter for this and actually do the hopping as an attacker and still do sniffing and injection. Actually, the guy who builds this BTLE jack tool, he found out how that works and how he can implement it to follow the newer Bluetooth connections. So it's not really a security feature. It's more there to have like a more reliable hopping that is better distributed over the spectrum or something like this. So let's continue with stuff that is obviously not a security feature. So on top of this 3000 page standard, someone thought let's do another 300, 400 pages of a bed specification, which is the Bluetooth mesh specification. And they have the model of friendship so nodes can become friends. And then there's super, super sad attacks, which are denial of friendship, for example. And so the reason for this is that they did not build the encryption properly, of course, so they're using a lot of encryption keys. And the colleague of mine who found that he was calling Bluetooth six saying like, hey, guys, something is broken with your security and they were like, do you want to become a Bluetooth stick member? No, I want to report issue. Then use our web form. The web form is do you want to become a Bluetooth stick member? No, I just want to report something. And then the feedback in the end was like, you know, we are using a lot, a lot, a lot of encryption keys. But it's really just for reliable communication. Okay, okay, I guess. And then even better, so there's a text, there's no Bluetooth 5.1 hardware yet, I think the new iPhone might have it or something, but there's currently none available. But let's break things just as they are specified in the standard, why not? So what the Bluetooth angle of arrival idea is, you want to save money, so you are not physically building a receiver that has multiple antennas for localization. But what you do is you have two antennas. And for the direction finding, you need to see the difference of the signal how it arrives at the two antennas. But since you only have one RF switch connected to one physical receiver, what you do is you first measure the one signal on the one antenna, and then on the other antenna, and the time when you switch is actually fixed in the standard. So an attacker would know the time when the receiver is switching the two antennas, so the attacker can actually inject two different signals to the two antennas and fake the location, which is really nice. I mean, it's a super secure location finding, I guess. And so Francesca was building this kind of things together with some other people in an SDR and people were like, yeah, but since it's a theoretical attack, you didn't write on real hardware, which is building it in SDRs. So I guess it's not really an issue, right? It's just we are building those devices right now, but it's not an issue. Yeah, so let's talk about Bluetooth 5. That's the thing that's in the devices right now. And we always try to buy cool hardware that has Bluetooth 5. And I was really happy when they said the new Raspberry Pi is going to have Bluetooth 5. I was like, oh, cool, a cheap device that has Bluetooth 5. Let's just buy hundreds of them. And the cool thing also is like, if I need to tell people, yeah, to test this, you need to buy an XS5. Yeah, you don't get an XS5 anymore. To test this, you need to buy a Samsung Galaxy S 10e. They are like, yeah, I don't have this money. No. But if you tell them buy an evaluation board, they might do that. But then it's really just for this specific case. And people really do have the Raspberry Pi already. So it's a good option for testing. And I was really, really checking like when will it appear? When is it there? When is it there? And so on. And then suddenly, someone was featuring, during recon at Montreal, someone was featuring my Raspberry Pi 4 arrived. And I knew that person, I was like, can you install internal blue? And he installed internal blue and he was like, can you hex down the compile date? And he was like, August 2014, I was like, no, Bluetooth 5 that was released 2016, December 2016, cannot be true. And then he said like, but I have a Raspberry Pi 4 and like look into D-mask and everything. I was like, yeah, no way this thing has Bluetooth 5. And so I logged in, just sitting in Montreal as a budget, like because I wasn't so before and I really couldn't believe my eyes. It was like, yeah, it says it's Bluetooth 5, but it says compile date 2014. Can we now do something like having a new physical layer that would be really awesome, like patching the chip to have a new physical layer because that's defined in Bluetooth 5 that would be cool was inside the patch. The main thing that's inside the patch is return Bluetooth version 5. Next thing that changed is vendor ID from Broadcom to Cypress, also very important. But I don't know, I don't know. Then next week I was like in class with some people who also like to play with Bluetooth and we paired with another Bluetooth device checked what it's like exchanging over the air, the feature mask and everything. It's it didn't have any, any Bluetooth 5 features. Also, if you ask locally and so on, it did not really have the cool Bluetooth 5 features we were looking for. So I was just walking around in class and asking the people who work a lot of like what is mandatory to be Bluetooth 5 compliant? What is the feature that really need? And they were like, Oh, mandatory. Oh, I don't know. I don't know. I don't know either. Okay. So yeah, it's it returns version 5. At least something. At least something. Yeah, we could have done that. We could have done it too. Yes. Yes. Because we're basically able to patch the firmware ourselves. So this is one of the parts you might find familiar if you were here last year. So just for everybody else, a quick wrap up with our project, we found out that basically those Broadcom chips, they have an update mechanism because basically when those chips ship, they have the firmware built into the ROM. So read only memory. They cannot actually do anything about that. So they came up with a patching mechanism, which is called patch RAM, so that they can ship updates and smaller patches to the devices once they are already built and also built into the devices. And yeah, for the Nexus 5, there were 128 patch ROM slots, which is basically one slot you can use to patch four bytes in the ROM, which is only temporarily. It's a feature of the memory management unit. And yeah, basically you have 128 of such slots, which is not much, but each slot basically could be used, for example, to insert a branch instruction in some function that you want to patch so that you just branch away from the function into the ROM, which is executable. And then you put just your other updated function or whatever you want to do inside the ROM and later branch back. So this is how they use it to basically ship updates. And we found out how it works, reverse engineered it, and now we're also able to do that ourselves. Now you might think there's a problem because it's only 128 slots and I'm not sure how they calculated the size, but I guess they were a bit off. The other limitation is basically the free ROM that you also need because you need to put new machine code on this device, which basically replaces the old functions. And when the device is executing its normal Bluetooth operations, most of the ROM is already in use. So it's pretty limited in its updating capabilities. And the full extent, Jiska found out later, because I was working with the Nexus 5 and saw, okay, 113 of those slots were already in use, which made me a bit sad because I wanted to play with this a lot, and so I didn't have much space for putting my patches there, but all the other devices are actually way worse. So what happens if now a serious vulnerability would occur in the code base? They would have to update it, but then other updates, which already got shipped, must be now like dropped because they don't have much slots left for most of those devices. Yeah, so I looked a lot into those, those patches recently, and I think the greatest one is the Samsung Galaxy S8. So this one came out as the first Bluetooth 5 device, but so actually the compile data is like a few months before the new Bluetooth 5 specification was released, and the cool part is that the patches are basically overwriting all the BLE5 functions. So BLE5 reception transmission is like all patched. It's all full. So I think it's fine. I mean they can still, they can still prioritize. You mean you know like functionality, security, and they have like 128 options, or I mean on the Samsung Galaxy S8 they have 256 options. If you buy the new Samsung Galaxy S10e, you still have like almost almost 50 patches to go. Yeah, why not? Why not? I mean that's great. So if there is something wrong with your Bluetooth, the operating system vendor definitely has a good option you can go for. It's flight mode. I originally planned to leave it at this slide, and recently I was giving an IoT lecture and I said like IoT is best without IoT, or at least without internet, and students were answering this in the exam, and my colleagues were like, did you really tell that in your lecture? And I was like, oh it might be that I did that. So yeah, so I'm not leaving at this slide, I would say. So what is the alternative approach to like not use Bluetooth? Buy the most recent and most expensive smartphone. So yeah, support this industry. Whenever a new smartphone with newer chips is released, trash the old one. So never sell the old device of course on eBay. I mean you're paranoid and there's data on the chips. Just put it in a blender, it will blend. Still, still disable the wireless chips if not needed. And best option, very tinfoil head, like my unicorn is the most secure unicorn here in the room, I would say. So yeah, let's talk a bit about security. I'm using this great iPhone SE, so it has all the patch drums not used. I was rude on this during CCC cam, I was like shit, okay. I need a new smartphone, but on the other on the other end I have tiny hands, I have tiny hands, I need an SE. Yeah, and then, okay, I mean, I just disable Bluetooth, I disable Wi-Fi just because that's also Broadcom. And then I'm not sure if it's a Qualcomm or an Intel chip, I think it's an Intel chip and then there is a guy, he just calls himself guy, he gave a talk at recon, how he hacked into cellular stuff. So maybe not the best. What's your smartphone? I have a Pixel. Yeah, is it secure? I'm not sure about, but I definitely know that there's no Broadcom chip in it. So that was fine for me, but yeah, I can sleep better now, but Qualcomm is probably not better. Yeah, I mean, on Defcon, they had this, there were those Chinese people, they had this funny hack on Wi-Fi, so Qualcomm has secure boot and they bypass secure boot because they first checked the file and then they were using the file which could be modified later and then you could boot with insecure contents and then they were extracting stuff from the firmware and just the usual thing, buffer overflow, pound and so on. You know it. Yeah, yeah. You never know. So yeah, I was testing. I had a student who made an IOS proxy and I was like, yeah, okay, it's cool to have it. I might need it at some point in future. He's actually sitting there. So I was like, yeah, okay, cool, but let's see when I need it. And first of all, I was like, okay, but it's hard to be root on an iPhone and so on, so I don't have that many jailbroken iPhones. What do I do? That's just wait. That's the best option. That's just wait for jailbreaks. Yeah, so iPhones, which one should you buy? I don't know. There's many colors, minus base gray. Yeah, which color? I don't know, like red, black. One of those might be more secure. Then you go to compare iPhones. You go to the website, compare iPhone models. It's all about the colors. So first option is choose your color. I don't know. You scroll a bit down, but it says blue to five, so nothing too specific. So what you do is obviously you take your Nexus 5, open the BT Snooplock in your Hex editor, pair with smartphones and check the LMP minor version. That works great. So I really can recommend stores that are no official Apple stores. So no customer support is a good thing. You could go there, scan smartphones for one or two hours, maybe have someone who asks you what you're doing and then you might answer, yeah, you know, I'm undecided which one to buy. I need to know the Bluetooth version and I would just let you do that. Okay. So yeah, yeah, it's okay. It's fun. Yeah, so I collected some versions and fun part is the iPhone XR is having the old chip. So, okay. Yeah, let's save some money. I mean, if you buy, if you sell a couple of hundreds of million of iPhone, then it's okay to go with an old chip. I wasn't root on one of the most recent iPhones, so I don't know the build date of those. It would be great to have an estimation on the security of those chips. The XR I would probably not consider it secure, but okay. I mean, it's three years old. Yeah. At least one good thing about the iPhone, that's always a positive thing. I have seen that they prevent a knob attack, so that's really cool. It works. So even on the old iPhone 6, you would see that someone is running the knob attack against you. And we released the test tool. So the original author of knob had a very complicated test tool and ours works at least on four devices, so you can have your Raspberry Pi and test against knob if you want. So, yeah, let's do some demo. I have this iPhone 6 with me. So first thing you need to do is being root on your iPhone. And then you would just do this, I don't know. It's funny. I hope it works instantly. Let's see. Yes, it works instantly. So this one is pretty old and I didn't build too much of support into it. So for some stuff, we would need to put some assembly snippets into internal blue, which I didn't do yet. But what I always do when I start with such a firmware, I do a hex dump on the zero position. And if the smartphone is a bit newer, then let's say 2011, 2012. So that's when it starts to have this four bytes here, which is called internally in the symbols. It's called the boot check. So let's dump this one pretty cool because it tells you the build date. So this is how I get the build dates. So, yeah, July 15 in 2013. And even nicer. So this one is saying I'm using the firmware this and this because the chip identifier is this and that. So that's the LMP minor version. And it's also in here. You would also get this version string. Yeah, next thing, which I just know because I know the date. So I'm starting to look like in those, I don't know, matrix films or something where they like have those or all these hacker films like tons of hex code and you start to estimate what's in it. So 2013, it's like the old memory layout where the patch RAM is like in the very beginning of the chip, which is actually this position, the 000. You can basically check out some of the firmware files of internal blue to see where the patch RAM is. And the specific thing about patch RAM is that it's just this branches into other locations, which are not written into the position d 000, but into another position earlier in ROM. So this branch here is not to this address, but it's actually within the patch RAM, the something and so on. So you can start estimating. So this is patches. So you go a bit further, like 100 is still patches. I don't know, 200. This is no patches. So this is actually patch code. So I go back to, I don't know, 180 something. And then this is the end of the patches, I think, but for this I would need to look into the exact patches that this breakpoint might also be a patch. So let's go for this number, d 0 1 f c. And then I would go into Python, do something like this. So Syrix d, what is the address? 1 f c minus the base address and divide this by four because four bytes by patch RAM slot. And then it's the 127 patches. So pretty full. Yeah, almost all patch RAM slots used. Yeah, for some reason they seem not to use the last one. I don't know if that's like a technical limitation or whatever. So I think on the Raspberry Pi 4 you would still have like one slot left or something and you can really use it. I don't know. It's a bit strange, but so it's plus minus one or so. I don't know why. But yeah, basically that's it. Yeah, so you can do this on iOS devices or on other devices, which is quite cool. And just look a bit into the chip and the patch level. The patches itself, it's harder to analyze them. So you need like a lot of source code to compare and so on. But yeah. Yeah, Android testing. Also cool thing. So we started with Android. I didn't you say like Android was maybe not the best idea, right? Yeah, when I started building internal blue, I was building it for Android because basically my supervisor back then, which was Matthias Schultz, he came up with this idea to look into Bluetooth because he had looked into the Wi-Fi chips, which is basically the same chip because they're Bluetooth and Wi-Fi combo chips. And he built Nexmon, so the Wi-Fi part of those chips. And then he said, yeah, take a look at Bluetooth. And so I took a look at Bluetooth in the Android smartphones, but it would have been way easier to just take a Raspberry Pi and yeah, just do it from a normal Linux distribution, then go through the Android system and do that. But I managed to do it and now we basically have this running on all platforms like on Linux, on Windows, no, not Windows. No, I didn't find any IT security student who has Windows knowledge. Yeah, but at least we've got iOS and we have Android. Yeah, yeah, so yeah, so Android testing is also a bit, yeah, hard actually, so you go into a store, you still, you again don't know like what is in a device. It's also a bit specific for the market, so what you buy here in Europe might be a different thing and so on, then somewhere else. So you need to check what is in the device, so I again go into the store and do the thing. So the Samsung S series is one of those who has Broadcom chips over here and yeah, it's pretty cool. They even have tin foil color as an option. So I would recommend that of course, and it's actually, so you go to the specifications and the first thing, like for the iPhones, is once again first decision is the color. It's really the first thing in the specs, you can check, it's the color. Yeah, so the first internal blue version, so how did it work? Yeah, this is also recap from last time, so when I started looking into this I had the Nexus 5 and I knew there was a Broadcom chip in there and basically what I also found out pretty early in this process is that the Android Bluetooth stack, which basically is this bluetooth.default.so file on your Android smartphone, it's a shared object, which contains all the Bluetooth stuff of Android. This has several debug functions which are usually not compiled into the Bluetooth stack when the Android version is shipped, but it's only for developing. So one of the first projects I did was basically recompiling this Bluetooth stack for the Nexus 5 and enabling all those debug functionalities and this took quite a while because basically for this old Android version you couldn't just build Bluetooth, you had to build the whole Android ROM which took 100 gigabytes of storage and I had to get me an Amazon instance because my laptop wasn't that as good. And yeah, basically when you have those debug functionalities the Bluetooth stack would open up two TCP ports which let you interact with the HCI protocol layer and the HCI is basically the host controller interface, so it's the protocol that is spoken between the host, which is the Android system in this case, and the controller, so the Broadcom Bluetooth chip. And yeah, basically through those two ports you can sniff and also inject into this protocol layer and are therefore directly enabled to talk to the chip yourself, basically in parallel with the Android Bluetooth stack. And what I then did is just forward those two ports to my host system and was able to basically access them through the internal blue framework which was written in Python. And the problem with this is for me it was working fine. I did that for the Nexus 5 and then it was all good. I just had to replace the Bluetooth default.so file and then everything was fine. However, if you wanted to do that on another Android version like if you update the Android version of this Nexus 5 or if you go to another device and there on another Android version you would have to do this process all over again with recompiling, enabling debug. And so it was quite cumbersome. We did it for several different devices which you can now download the pre-compiled Bluetooth stack on GitHub, but there's still a lot of devices basically missing where you would have to do that yourself. And this is the problem that Yiskar didn't face. Yeah, I mean a good thing with this compilation is that you could also add the diagnostic messages where you can see LMP and LCP, which is the layer 2 of Bluetooth, so to say. But they made this ABI, the binary interface, fixed so that you could no longer add diagnostic messages since Android 8 without breaking it. So I couldn't compile it the way I liked it either way since Android 8. So I was like, okay, Bluetooth default.so does not run out of the box on a rooted Android. Also on a more recent Android it would not run the way I like it with the diagnostic messages. So I take whatever crappy support I can get because what I did recently is like I have a pile of smartphones and I update them and after the update I route them once again and I want to check did they get a specific security update? Yes or no. And you wouldn't recompile the Bluetooth default as our each time and you also wouldn't do that probably for some Samsung stock ROM and so on. So what do you do? Well, hacker mode on. You install a busy box. You net cut the Bluetooth snoop lock somewhere and you just directly echo into the serial interface. This works on Android not on other devices because this serial interface of the Bluetooth chip is non-blocking so you can just echo something despite Bluetooth is still running and it works on Android 8 and 9. I didn't test 10 yet. I don't have any Android 10 supported device that has a Broadcom chip so far. So it's a bit slow in case of like it takes a few moments until the Bluetooth HCI lock is written and then net cut it over that point. So if you want to dump the full ROM I would recommend you some shell scripting that echoes into TTY and so on and then you parse this with Python afterwards. But for everything else just like checking how many patch ROM slots are used what is in a specific ROM position during runtime and so on it's perfect. So I have the Bluetooth versions of several Broadcom chips here. The first one is pretty interesting the Samsung Galaxy S10e. So I did not even buy it because it was one of the most recent ones but over the air it says this 4208 and this is the version that I also had for one of the evaluation boards and I was like oh damn if I have this phone I might have a ROM for that I have symbols and that would be awesome. And then you connect locally over HCI and then you get the version 1111 and all the symbols are in different positions so damn. But still it's the newest one that I could get so far and I definitely have two things fixed in there that are worth fixing. So I would say like if you really want to have a Broadcom chip and if yeah just take the newest one so this one I would kind of recommend in terms of being okay not in terms of being good but okayish. And then there's a lot of other versions which are obviously older and DSA with all this the first Bluetooth 5 phone that has like all the Bluetooth 5 patches so hilarious. Yeah. And then another thing once you're on the film where you want to start debugging. Debugging is really important to understand what is going on and while you're debugging one thing that happens on all the chips if they crash they produce a stack dump. And just sorry and the stack dump is so they don't always occur just on certain crashes and they have a different output for each and every chip version so the Nexus 5 you reversed how it works then the Nexus 6p has another variant of this. Then I'm on the evaluation board where I have symbols so I know at least what is going on and why they are so different and on the evaluation board I would get the top part of this listing but then if I'm on a Samsung Galaxy S10e which is almost the same generation I would get another format of a stack dump which is slightly different but almost the same almost the same and this is the reason why currently internal blue is parsing some of the stack dumps duplicate and might provide you a duplicate output or something it's still better to have a duplicate output than none and that's the reason why because I don't know what I'm running on I'm just trying to interpret those events and hope for the best. Yeah, but a stack dump that's the thing like when it crashes and it's cooler to do it a bit more defined and that's something that you were I think building after your talk back then or like around this time so definitely after your thesis. Yeah, so this was added after I already had it in the thesis I think it was added after my talk last MRMCD so it's a trace point feature which is basically there to replace debugging because you can debug the chip when it's in the smartphone so what we thought what would be really nice is to know the exact state of the firmware of the processor on a certain line of code for example we found a function that is pretty interesting but we don't know how it was called with which like with parameters and what's the current state of the stack and usually when you would reverse engineer something like that you would set a break point and just look at registers but you can't do it like this so basically what we do now is just insert a patch at the specific line of code where we are interested in which will just branch away from the current function into the ROM then record all the registers basically so dump all the registers and the processor state and the ROM the complete stack and send it over to the host then remove the trace point like the patch and then jump back to the original function so that the function can continue like there wouldn't have been any trace point but at least you got a snapshot of how the state looked like when the function hit this point and that helped a lot during reverse engineering and also when we found like weird behavior or only if you want to know if this function is actually hit or not it already helps yeah and then I was adding the break point so as there is no debugger connected that one would just produce a straight crash but it's sufficient for most analysis and this one I don't need to pour it it just works on any of the devices but the trace point it's really smoother because you can also remove the RAM dump from the trace point just this part and then it would usually never crash you would just continue, continue, continue and see what is happening yeah so the thing is to add those trace point features you basically need to already know some things about the firmware for example the trace point must be able to like the code which is inserted with the trace point must be able to communicate back to the host so it must know where the HCI functions are in the firmware and how to call them and if you don't know that about any firmware like if you are on the new firmware version then you can basically not use this feature so if you just insert a usual break point that the chip would basically just crash because there's no break point handler but it's enough because it produces a stack dump and you also know the processor state you just cannot continue afterwards yeah so that's it so long and thanks for all the chips thank you any questions and doing the Q&A we are going to show you a video that is not streamed I think did you stop the video but you can continue with the tone and everything and filming us just not the I have an awesome video it's about how to disable Bluetooth properly let me just why we are doing Q&A so if you have any questions feel free to ask while this video is playing because it takes a while I think Bluetooth is still working on this one yes yes yes takes a moment takes a moment no questions really who of you has a a phone that probably has a Broadcom chip yes one two it must be more it must any anyone who has an iPhone that's a straight yes anyone with a Samsung would also be a straight yes probably so at least the Samsung S series is not the A series that might be mixed yeah Huawei I think so I think like maybe Huawei also has another sorry Huawei has now Bluetooth is definitely off I think even their own chips isn't it high-slick and something yeah yeah the planner is amazing amazing so I think Bluetooth disabled now let's let's do the same with the Samsung Galaxy S8 really no no questions ah yeah one yes awesome this one is more robust yeah but also the planner was already used I think it's hard to compare it's really hard to compare it's a bit unfair competition so the question is if you looked a bit into the iOS 13 so the problem with iOS 13 is like you don't have a jailbreak what you can do is you can enable the debugging so you can install this Bluetooth profile and with this in iOS 13 you can even do some live vlogging actually this is pretty cool so you would live see all the messages being exchanged on the iPhone so you can get an idea of what the chip does but you cannot interact in that sense I cannot tell you about this I can only give you kind of recommendations switch phones not to buy yeah yep that's correct so if they are for some reason ship the patch that itself contain a vulnerability or like a bug then of course this would not need another patron slot because they could just change that also if they already patch something in a function they can just like add another patch with the same patron slot in there and branch back later so yeah there's probably a lot of things they can do to trick this system to to even squeeze more out of it but I guess I really would like to see those engineers because they're probably dying to squeeze in all the patches in those slots return five yeah but Cypress instead of Broadcom yeah yeah well when I was reversing the Nexus 5 I stopped trying to reverse what those patches are because it was pretty cumbersome to reverse what they mean without knowing the whole context and I didn't have that much time so basically with a lot of time you could probably see what they they actually patched and what things they added but yeah it would be quite time consuming and I did not do it I think you only know about a few and cannot tell I know only about a few so the thing is what I did is I knew about certain things that I wanted to see in the patches and checked if they are there and then there's other stuff that I stumbled about just like randomly so the fact that the 7th Galaxy S8 is like having patched all the BLE5 is because I had a special thing that I wanted to do with BLE5 so a feature that will probably be published in a few months I don't know so just a cool feature for debugging and sniffing and I was looking for those function and just didn't find them and then they were suddenly in Petrum yeah three questions then I think he started then I don't know and yeah some months ago I worked on a Raspberry Pi and I used the Nexmon project which is developed here in Darmstadt and when I remember me you can increase the RAM the internal RAM in the BOTCOM chip in the Wi-Fi yeah in the Wi-Fi and can you then increase the slots too with this possibility I don't think so I'm not sure so I didn't I didn't see that yet I know that in the configuration of the evaluation board it's a flag that you set but I think it's fixed I mean otherwise Wi-Fi is still at 128 patches on an iPhone 6 and SE if they could do it differently also so the patching works very different differently between Wi-Fi and Bluetooth in terms of how the patch is generated and applied it's both arms so there's even a Nexmon minus BT branch work in progress whatever I should I should finish that one I just didn't find time yet so there will in the future there will be Bluetooth and Wi-Fi in the Nexmon project I was curious why the change by enabling the debugging in Android 8 was breaking the Bluetooth driver what's happening there ah okay so Bluetooth has four message types HCI command which is number one two and three are ACL and SCO and four is the event that comes back and the ABI only knows those four message types and the diagnostic message is seven for whatever reason and then you would need to add a new message type with a new prefix or embed the other messages into something but then it would not no longer be so it just breaks this this assumption that you have four message types which is hard-coded in the ABI okay thanks yeah I can also just repeat the question the best security improvement was Bluetooth I mean we showed the video right apart from that there is a lot of legacy stuff but you need to have it in there to support all devices yeah it's it's hard so this secure simple pairing was even proven to be secure and just recently we had like two attacks on this because of this non-checking of some parameters and so on so it's hard it's hard to tell like what to do properly I mean maybe they should hire a cryptographer in their team to not have all this insecure encryption I don't know it's better which separate legacy stuff from like good photographer stuff and do some proper security yeah do proper security is one thing but you need to support legacy devices yeah yeah you could put you have already kind of special bits because during the pairing they tell the Bluetooth version and then you would know the version that you're talking to the device but this part is not authenticated once again I don't know it's hard also another problem is that most vendors if they develop a Bluetooth product they want it to be compatible with almost all devices and so they actually allow that you are pairing with older Bluetooth versions and if they would deny that they would probably cut off half their customers so this is another problem that we still have a lot of old cheap IoT devices which only support Bluetooth 4.0 or 4.1 which use the less secure Bluetooth LE pairing for example so yeah the solution would be to switch over to newer devices which only support newer Bluetooth and also to make them so that they are not compatible anymore with the older or at least warn the user hey this is insecure yeah but how long did WEP stick around how like your question was okay we have the same problem with Wi-Fi and they at some point found a way to make it secure but yeah if you look back how long did WEP stick around and was still a problem and you couldn't like if you would connect to a network it wouldn't tell you if it was like WPA or WEP so the same thing we wouldn't need now for Bluetooth that it warns you hey this is an old device you're connecting to are you sure you want to connect to it it's unsecure yeah must be user awareness I guess and even worse so the BLE 4.1 and 4.0 pairing that is insecure has exactly the same user experience in terms of comparing six numbers which is the secure part in the new one so it would feel the same for the user you wouldn't feel any difference between an insecure and a secure pairing mode okay so there was yeah that's one question yes great right so I wonder it makes sense to flash the firmware into ROM at the factory if you really don't need to change later but it seems that the Bluetooth firmware changes rather often so why don't they use similar to mechanisms to Wi-Fi where the whole firmware is loaded I'm not sure if that is going to come so I think they just didn't have to do so many patches in the past so there hasn't been a lot of security research in the past or not sufficient security research in the past so they didn't need to do so many patches and now this is happening and this is becoming true and they need to patch all of this and they cannot do it so maybe they will switch to the mechanism that I have for Wi-Fi okay thanks so hacking the MMU was probably cheaper than loading the entire firmware we'll see yeah okay so we will be here the remaining days so if you have any questions we can do some offline follow-up also yeah if you check out on the Github the internal loop project there's also some examples and also many links to other conferences we already gave talks where there are recordings and also papers so if you're interested in the details then on the Github page you would probably find what you need otherwise contact us yeah and something that I always push into Github is new device support so I'm not pushing all the features for like I mean I do research and then it has some periods until I publish this but all the new device support like iOS and coming soon macOS will be there