 Yeah, so welcome everyone. Yeah, so my name is Yogis and I work as a cyber security analyst analyst at TCS Cyber Security Unit India where I spent a lot of time working on IoT and mobile application security. Apart from that, I love to build and play with robots and sometimes break them very often. And today I'm here to talk about the security in Bluetooth learning devices and how to hack the fitness trackers. So let me tell you a story. It all began a year and a half back when I started getting excited about IoT security. It's just that I saw many people having IoT devices at their home. IoT was just booming up. So as a security guy, I had to focus on IoT. And then I realized I needed a device. So I got myself a fitness tracker, definitely not to stay fit, but to hack it. So once I got the fitness tracker, I started researching more and more about how does it connect to the mobile application and what are the communication protocol that it uses to interact with the mobile application. And then I realized there is a communication protocol called BLE. Far more or less different than your Bluetooth classic, but pretty much almost same. So it uses BLE protocol to communicate with the mobile application. And then I started realizing that I could do something really cool with that. So and then I started hunting for, you know, box in that fitness tracker. And then I found something really cool. So this talk will be on how I found the vulnerability in the fitness trackers and how I was able to hack into the fitness trackers. So expectations. So what can you expect from this talk? You'll be getting a basic understanding of Bluetooth. And then I'll talk about what exactly is the difference between Bluetooth classic and Bluetooth low-energy. And then after that, I'll be talking about the BLE stack and what we generally call Bluetooth mind the middle attack, which is capturing the BLE packet. So whatever conversation that you have between your mobile application and your fitness tracker. So I'll be talking about how to capture them and what hardware, what software, you need them. And then after that, I have reverse engineering the mobile application of fitness trackers. It could be anything. You know, a lot of time what happens is in these smart, so-called smart devices, they have that on mobile application. And then these hardware manufacturers forgotten to harden the security, to harden the reverse engineering process. So what happens is a lot of information could be gathered from here. So I'll tell you how exactly to reverse engineer the mobile applications. And at the end, I'll be talking about how to upload the former over the year. This is something really cool. So if you want to upload the former over the year in the BLE devices, I'll be talking about how exactly to do then. So all right, first thing, first let's talk about Bluetooth. Bluetooth is a start wireless, start-range wireless communication protocol and allows devices such as your smart phones, headset, and many other smart bulbs. It is easy to connect with each other and share the data and advice wirelessly. It was developed in 1994 by Erikson as a replacement for cables and uses 2.4 Gigahertz frequency and creates a 10 meter radius called Piconet. And for many years, what happened was it had constant data transmission. That just means high power consumption, right? When you have constant data transmission in the device, it has high power consumption. When it has high power consumption, this Bluetooth application suffered a lame battery life for many years. Until a few years ago, Bluetooth 4.0, what we can generally call Bluetooth smart came into the scene. It's basically the power efficient version of Bluetooth that has made many amazing device possible like your fitness trackers, your coffee makers, your light bulbs, and many medical devices. It is easy. If you see the applications of BLE devices, it's right now everywhere. This version of Bluetooth smart are simply called BLE is designed to be power efficient and low cost. And that's the region where you can get these BLE devices for as low as $7 to $8. You can get any BLE applications for $7 to $8. But yes, BLE is an awesome technology. It enables us to connect to everything that we thought wouldn't be possible to do. Have you ever thought that we would be any day connecting the smart suits with a mobile application? Not right. So right now, thanks to BLE, smart suits are out there in the world and you could count how many steps that you walked and you could do so much things with your smart suits, right? So now let's talk about what exactly is the difference between the Bluetooth classic and BLE? So this Bluetooth classic is generally what you see in your fitness, sorry, in your headset, in your Bluetooth speakers, and BLE is what you generally see in the smart devices. So this Bluetooth classic is great for product that requires the continuous streaming of data. Your headphone has to have the continuous streaming of data, right? Your Bluetooth speaker has to have the continuous streaming of data. So in those applications, Bluetooth classic is always preferred. So when it has, sorry, it has continuous streaming of data, it has high power consumption and needs to have a faster data rate as well. But on the other hand, I have this Bluetooth low energy. This Bluetooth low energy is great for product that not require the continuous streaming of data, like maybe in your smart bulb, just to send on or off to the bulb, right? So in that case, you don't need the device to continuously send on, on, on, on, right? You don't have to send that. So in that case, we prefer BLE over Bluetooth classic. And it has ultra low power consumption. Since it doesn't have to do the continuous data transmission, it can go for slow data rate as well. The beauty of BLE is that it is designed to operate in a sleep mode and waking up only when the connection is initiated. So what happens is you have a Bluetooth low energy device, maybe a smart bulb, the connection between your central server that is a mobile application and the Bluetooth application, the connection is on sleep mode when there is no, there is nothing to send. So it is waking up only when the connection is initiated. That's the reason why you have fitness trackers that can go on and on and on for days and days. The battery life can go on and on for days and days, right? And this is best suited for your home automation, fitness trackers, and many other things. But being said that it is not perfect. It has flaws. Almost at any point in time, it's discoverable. It's like, hey, I'm here, send me any information, and I'm going to spit out, send me anything and I'm going to spit out the information. It works in the same frequency and same channel always. There is no channel hopping. So if you want to do, you know, denial of service attack, it can happen because there is no channel hopping here. And almost at any point in time, it allows any device to connect to it. And on top of that, most of the devices do not take the benefit of Linglay security, Linglay encryption. So what happens is if they implement this Linglay encryption, the cost of the devices are going to go up high, but they have to sell a lot of them, right? So this hardware manufacturers blindly do not have this Linglay encryption. But there are a few devices like smart watches that are costly that can go for $200 and that really has the Linglay encryption. You can capture the packets in between. You can perform the man, the middle attack, but the packets are encrypted. Yes, you can keep the packets also. So now let's go back to the fitness tracker that I talked earlier. I decided to focus on the fitness tracker. It's because I saw many people using that. And I decided it would be really fun to pop up some notification, pop up some messages on my friend's fitness trackers. And to do that, we need to understand this BLE stack. So in BLE, this is the BLE stack. So in BLE stack, there are two really important that you need to remember. That is, generate attribute profile and generate access profile. So the first thing, GAT. GAT defines the way these BLE devices communicate with each other. The client and the server. The client could be your fitness tracker and the server could be a mobile application. Using something called service and characteristics. Remember these terms, service and characteristics, I'm going to use it very often. And I'll tell you what exactly is that. So here, connections are exclusive in BLE. The connections are exclusive. When I say exclusive, it's, suppose when the client, that means a BLE device, is connected to one central server at a time, it won't advertise itself, saying that, hey, I'm here. So once it is connected, it stops advertising itself. So no any other device can be connected until the connection is actually broken. So now, here in BLE, we have something called profile. Profile is actually, it doesn't actually exist in a BLE, but it's just a collection of service and characteristics. Service defines, it's a set of provided features associated with, with associated behavior to interact the peripheral. Each service has on collection of characteristics. Characteristics are defined attribute types that contain a single logical value. Now, example, in your fitness tracker, service could be something like device information. Device information is a service, and characteristic could be something like software revision number, hardware revision number, or maybe any value. And maybe your hardware name or something like that, right? So now, this is an app that is there in the place too. If you want to install, I'll talk about this app on the later slides. This is an app called NRF Connect, which allows you to scan the nearby BLE devices. So if you see here, there is something called device information down there, which has a UGU idea as well. So the device information is actually a service. Inside that, if you, you know, if you open up that, you'd see software revision number, hardware revision number, and the device name itself. So this is the actual definition of service and characteristics. So what happens is, if you really wanted to attack a BLE device, there are a few basic process. The first is step number zero, selecting the toggle. So here, what happens is you want to collect more and more information over the device. It's always better to actually refer the hardware manufacturer's manual. There is nothing as better than a hardware manufacturer's manual to grab more and more information about the devices, right? And in Linux, if you are in Linux, there are many other, many tools like BlueZestack, I'd say Tool and Gattool, which allows you to, you know, gather more information about the devices. And the step number zero, one, step number one, once you have all the information about the device, now you're good to go. So now you want to animate the service and characteristics. You want to figure out how many services are running in that particular one, and how many characteristics are running there. And you want to figure out what service does exactly what, and what characteristics does exactly what. So, yeah, the basic process is you could use the tools like AdSayTool to scan the nearby devices, and then connect using something called Gattool. And then you can list down all the services and characteristics. Sometimes, most of times what happens is your characteristics are just unknown services. If you want to figure out what exactly characteristics is doing what, you could just do Google search. There you could find many information. And the step number two, that's reverse engineering the mobile application if they have any. For reverse engineering, in Linux, we have something called APK tool. Using that, you could reverse engineering APK tool minus D. They could decompile any Android applications. So, what happens here is like I was working on hacking a smart lock that you that you generally get. So, I ordered it from somewhere from China, and once I got it, I reverse engineer the mobile application. The default password to unlock that lock, suppose if you don't have the mobile phone with you, or maybe you want to physically unlock that lock, it had some hard-coded password. So, once you reverse engineer the mobile application, the hard-coded password was there inside the mobile application. And many times a lot of information like figuring out how exactly your BLE application is connecting to your fitness track, sorry mobile application. Every information that you need to connect between a mobile application and your BLE devices is there in the mobile applications. So, if you're good at reverse engineering, there's a very good chance to start that. And then after the last one is finally doing some coolish stuff, maybe sending some notification, maybe changing the light bulbs, turning on and off your neighbor's light bulb and many other things. And in the reverse engineering, I would be surprised if you didn't get any information because all the devices that I had tested out had something at least in the mobile applications. So, step number zero, that is selecting the target. This is the very first step that you want to do. You want to find out the nearby Bluetooth devices, right? So, for that, if you're in Kali, any version of Linux distribution, you have something called bluesy stack. So, bluesy is, it is as easy as installing pseudo-up gate, install bluesy. So, all the tools that I mentioned earlier, et cetera, comes pre-installed the bluesy stack. So, you can download the bluesy stack. Once you download the bluesy stack, you can see the command there, et cetera, et cetera, lay scan. Lay scan means low energy scan. So, you can scan all the low energy devices near vicinity. And then, yeah, so, if you wanted to do, if you're Android and you want to do it from your Android mobile phone, you can download this mobile app called nrfconnect. So, it allows you to scan the nearby devices using a mobile smartphone. So, you can just go to the Google Play Store and download this app. And if you're in iOS, you can download this light blue. iOS has an nrfconnect as well as light blue. You can choose either of them. If the device is actually advertising, if it is not connected to any central server, if it is not in a sleep mode, it should pop up here. So, this is how exactly it works. At say tool, if you see the at say tool, it's listing out all the nearby devices. There is an ammaband, there's a fitness tracker. And the next, here you can see all the BLA devices that I have near my vicinity. And there's a screenshot from the light blue. You have all the health monitor, all these sort of devices out there. So, step number 0 is selecting the target. Step number 1 is animating the service and characteristics. Here, we're trying to figure out what services does exactly what. You can do this actively as well as passively. If you want to do it actively, then you can connect the device to your phone. And you can use apps like I mentioned earlier, light blue and nrfconnect to do that. Once you're connected, it's just going to tell what services are running exactly what. So, if you go back here, I didn't have the slide anyways. So, once you're connected in your nrfconnect, all the characteristics and services are going to have that name. Like the one earlier you saw, device information, right? So, like that you'll have notification service in the fitness tracker, notification service, messaging service and many other services. Or maybe in the Linux, you can have this tool called at say tool using at say tool and Kali machine or maybe any of your favorite distribution. You can connect using that tool. And if you're connected, you can list down all the primary characteristics and services using a command called primary and characteristics. This is for at say tool. So, you must have the UID and handle. If you remember in my earlier third slide, the device information had something called UID, right? So, if you wanted to send or receive any sensor value, if you wanted to send, you know, read what exactly is happening on particular sensor, you need to have a UID. So, that UID could be, you could get it from at say tool, as well as you could get it from another fconnect. But if you want to do it passively, that means you need to sniff somebody's connection. At the beginning of these devices, when they talk with each other, they're like, hey, I'm here and I have this many service and this many characteristics and my service does this and my this characteristic does that. So, what happens is, if you could, you know, sniff this communication between the daily device and the central server using some sort of hardware like ubertooth, you could know what service is doing exactly what. So, if you really wanted to sniff the BLE packets, ubertooth is a perfect solution. It's like, yeah, ubertooth is a perfect solution. It works both for classic and BLE. If you wanted to capture the classic, the one which I told if you wanted to do it for your headset, if you want to do it for your speakers, it works for classic as well. And it runs and opens those hardware and software both and it goes somewhere around $100. If you don't want to spend $100, there are cheaper alternative for that. This really cheap sniffers, CC2540, which is cheaper but with limited configuration. It doesn't have the higher data rate as much as ubertooth one. It costs somewhere around $50. So, if you're wondering how to capture the packet down to the level, down to the packet level, ubertooth is a perfect solution. I prefer not to use any sniffers at all because sniffers do drop a lot of packets. So, if you're somebody like me who doesn't want to spend any money on hardware, there's an alternative on Android phone. So, what I do is every time, there's an app available on Android called nrfconnect, which I told you, do install that and let the app communicate with it. So, if, example, you have a BLE device and you have its central application, mobile application, the fitness trackers mobile application. So, what happens is as soon as you start communicating, they're both going to share a lot of a lot of information. So, if you really wanted to see that, what you could do is you could go to your settings, developer option, and five times. So, you can go to the settings and about and tap the build number five times and you could enable this developer option. Once the developer option is enabled, you can enable this Bluetooth ACI Snublog. So, ACI just means host control interface. It's going to log all the communication that is happening between your mobile application and the BLE. So, once you get that, you can pull off the file using ADB commands. I hope you're aware of ADB. If you're not aware of ADB, it's Android debug breeze. So, you can just connect your mobile app. If the developer option is enabled, you can debug using the ADB. So, you can pull the file from sdcard and btssnublog underscore, say that log. You could take that file to any packet analyzer, maybe in the Wireshark or anything. I prefer to use Wireshark. So, once you have that in the Wireshark, you can analyze the packets. So, here you could see under which, you know, protocol it is communicating, under which, you know, UUID it is sending and what all values it is sending, you could see everything there. So, super easier, right? So, now what happens is now you're connected. You might ask me the question, hey, you guys, I'm connected to the device. Now, what's next? So, next step is authentication. The fun thing is three of, yeah, this is one of the metrics that I had. Three of the five devices that I tested didn't have link line encryption. And then two of the five devices that I tested didn't even have the authentication. Like the one I was testing out was a smart ball. So, in that smart ball, the hardware manufacturer thought it would be really fun and really cool to let your neighbor next door to allow your lights to be turned on and off. Since it's a smart ball, right? They didn't have any authentication. So, your neighbor next door could actually install the app in his phone and could just turn on and off the light. It was that simple, no any authentication. So, it's the same thing. If they implement these security measures, the cost of the devices are going to go up high, but they have to sell a lot of them. So, they're just ignoring. So, after the authentication, yeah, so this was the thing that I was able to do. Now, I was connected to the fitness tracker using my HCA tool and GAT tool. I wrote my scripts and then after that I needed to do some really cool stuff, right? So, now you have to reverse engineer the packets. So, once I was reverse engineering the packet, I got something like this. It was sending values 0, 3, 0, 1, 4, 8, 6, 9 to one particular channel, two particular characteristics. So, then I realized it's doing something really cool here. The first one byte, first two bytes are actually notification type. So, if you wanted to place a notification saying that, hey, Trump is calling you. Maybe you could just send 0, 3. Or maybe if you wanted to send somebody, hey, your email is there on the fitness tracker. You could just append 0, 1. You could replace it with a 0, 1. And maybe if it's a mystical, you could just do 0, 4, something like that. And the next one is how many notifications you want to send. So, if you want to flood the notification, sorry, fitness tracker, with the notification, you could just replace that with the number of times you want to send the notification, maybe 99, like that. And the last bytes, last bytes are for sending what you want. So, like suppose if I am sending high, it's the hex value of SI. It's just 48 and I is just 69. So, it's calculating hex value and then sending it with a particular characteristics. If you see the characteristics right now, it's 5F9B34FB. This is one particular characteristic where the notification is being sent. So, how I knew this is from the wire sark. Once you pull that log.log file, you could take it in the fitness tracker, sorry, you could take it in the wire sark and analyze this packet. And you would know that when there was actually a notification coming on your phone, on this particular 34FB characteristics, there was some value that was being sent. So, once you're using that, you could figure out it was that simple. So, then this is one of the very simple snippets of the code and tool that I built to send the notification. If you're interested in looking this tool, this tool is there in the github, github.com slash yogeshosa is spelled as y-o-g-e-s-s-o-j-h-a. If you wanted to look into the tools. So, this is an example of what I did. So, I'm writing the values to one of these services 34FB. So, if I do that, this is exactly what is going to emulate the device. So, it's going to further notification. So, what I got after that was, I was able to pop up on anybody's fitness tracker saying that Trump is calling you, maybe whatever notification that I wanted to pop up. It was that simple. So, the next thing that I wanted to do was doing something on the firmware. The real question was, why was I interested in firmware? It's because I saw many people using fitness tracker and I thought when I scare somebody with these icons or maybe images on the fitness trackers. So, let's first talk about what exactly is firmware. Firmware is a piece of software that runs on an embedded CPU typically written on C is compiled into binary and that is loaded into your device using a programmer or wired connection. But the next question is, how do I get the firmware, right? One option could be reverse engineering the mobile application that I told earlier if they have any and look into the directorical asset. Inside the asset, they're going to have everything for you. It could be a firmware, it could be resources and anything. Otherwise, capture the file doing the DOF update. Now, this fitness, these BLE devices, they have something called over the year updates, right? So, what happens is over the year, if you have something, if there is new update, it's going to first make a call to some API, maybe x.y.com, slash maybe you know, new firmware.fw or something like that. So, if you capture the firmware doing the DOF update, you could get the firmware. For me, yeah, so this is once I reverse engineer the mobile application, I think, yeah. So, once I reverse engineer the mobile application in the asset directory, this is what I got. .fw file, that is a firmware file and .race file, that's a resource file. So, firmware file, you could do a lot of things, maybe write on custom firmware for that and for the resource, like all the images that you have on your fitness tracker, everything was there inside the race. So, if you reverse engineer again, both of these, you can use any tools like Ghidra, the recent one launched by NSA or maybe your favorite hex editors, maybe whatever you want. You can use either of these tools and then reverse engineer these formwares and again for the resources as well as. So, once I got the firmware and the hunt for the firmware update service actually started, because I had to upload, now I have the firmware, I may send it to the firmware, I had to upload it to somewhere, right. So, if you remember, I mentioned an app, powerful app called nrf connect, this is one of the screens are from there. So, once I got the firmware, I was expecting it to have clear name, device firmware update and then, hey, upload the firmware here. But in reality, what happens if this hardware manufactures sometimes slightly to harden the reverse engineering process, they might have unknown services. So, it is not really difficult, you could go to GitHub and probably search for this particular UID to see what exactly this UID is doing. Or maybe just go to Google and search what exactly this UID is doing. Or maybe the hardware manufactures a specification manual, you could just go and look for this particular UID and they have some of the other information on that. So, once I got this, you know, once I found that, okay, this particular characteristics is actually except in the firmware, I started uploading the firmware. And I was wondering, I have a file called .afterview file, how do I upload the firmware over the year? Right? So, yeah. So, next thing was how to upload the firmware, right? So, I, when I reverse engineered again, same thing here, reverse engineering the packets in the wire suck is as simple as that. So, when I reverse engineered, I found out that it was first sending, it was sending 4 byte, initially it was sending 4 byte and this particular characteristic was 1531. So, the first byte it was sending X01, sorry, 01 was, you know, initiating the firmware update service. It's saying, hey, now I'm ready to send the firmware to you and this is how I send, it's using 01. And then with that, it happens the file size in 3 bytes. So, if a file size is maybe 100 kb or maybe even 3, 4 kb, it will translate that into your, the file size into the hex and then it's going to append that with 01, it's going to send it to the, sorry, characteristic number 1531. Once it's sent, it's going to, the fitness tracker is ready to accept the firmware and it on your fitness tracker it just says, hey, I'm ready to accept the firmware. So, now for the resource, the difference between the firmware and resource is that firmware actually controls the hardware, resource is something which you have, maybe your images of the scroll that I showed earlier, maybe you have, when you receive a phone call, you have that phone call image in a fitness tracker, right. So, that's actually a resource. So, for resource is actually 5 bytes. It has to tell to the DFI firmware update service saying that, hey, I'm not sending the firmware, I'm sending a resource. So, it's going to happen 02, this particular byte at the end of the, this particular packet sending that, hey, it's not a firmware, it's a resource. So, once I started operating the firmware and then I realized it was stuck in 99% is every time and it was never accepting the firmware. I spent a lot of time figuring out what exactly was happening then I realized there was something important called section. So, let's see what exactly it's section. So, what is happening there was once the firmware is being sent, it's waiting for section values. So, what exactly it's section? Section is a calculated value that is used to determine the integrity of the data during the transmission. So, that the man the middle attack doesn't happen. Check some subs is a unique identified for the data that is being transmitted. If the data is changed, that section it changes as well, right. This makes it super easy to verify the integrity of the data over the year. So, now how to verify the integrity is that the sender when it is sending the firmware before even sending the firmware it calculates some particular section. Now, receiver when it finishes accepting the finishes receiving the firmware it is waiting for something called section. Now, the sender is going to send the particular section to the receiver saying that hey, this was the section that I sent to you. Does this match with you with the high degree of confidence? If the answer is yes, it's going to accept the firmware. If the answer is no, it is not going to accept the firmware. So, if the firmware was modified over the year in between if it was the one I told you earlier like using the Ubertooth if the packet were being modified over the year it's not going to accept the firmware. So, once it has high degree of confidence it's going to accept the firmware. If it checks some matches the firmware is straight accepted. Actually, it really doesn't perform the error correction but only can perform the error detection. So, Bluetooth 5.0 that is the new version of Bluetooth it has error correction as well. There are several types of checks available but this fitness tracker that I tested had CSC16. So, this is how exactly the checks are being sent. Once you initiate the connections by sending the first 0.1 bytes and then the file size the firmware is sent and once you start sending 4 bytes at a time to the firmware upload service the firmware is up to 99% if the firmware is already sent to the fitness tracker. Now, what happens is it's waiting for you to send the checks. Now, you would say to the fitness tracker saying that hey, I'm sending the checks that is by initiating with the 0.4. byte. So, now you have a section. So, now if the section is matched with the receiver as well it is going to straight accept the firmware. So, this is how exactly it is working. At the end if the firmware is being sent you could just send 0.5 to reboot the firmware to reboot the fitness tracker. And once I loaded the firmware this is what I could do. I could change the device name from something from some vendor to the Zasper. Zasper, my dog by the way. So, I could change the device name to something else and then if you see there is something this is just a proof of concept. So, I could change the software revision number to version number 9.999. Now, the funny thing is that this fitness tracker is never going to connect to a its central mobile application. It's because what happens is right now running on the version 9.9.9.9. But the fitness tracker mobile application has the version number example 1.2.3. And it's going to think that there is already in latest software running on the fitness tracker and I don't have to upload and I don't have to connect and I don't have ability to connect. So, once you change this device name and software revision string you could never connect that particular fitness tracker to the mobile application to the central mobile application. And what about the skull icon? Yeah, this is what exactly I was able to do by uploading the form by changing the firmware and then reverse engineering the resources file. Again, this is just a proof of concept but you could do a lot of things. You could expect much more than this. Former upload update over the year is actually really cool feature that is found nearly on all the embedded devices. I demonstrated this feature how this feature could be exported to allow attackers to inject malicious firmware modification to embedded devices. The problem is that hardware manufacturers do not cryptographically sign the formers for the small devices. So, what happens is at any point in time this fitness tracker will accept firmware from anybody. That doesn't matter if that is from the particular vendor or maybe any attacker that has actually injected particular firmware. So, you don't have to be you don't have to physically toss that fitness tracker to upload that. You could just sit here and send the firmware to anybody's fitness tracker. It's just going to accept that. The solution for this could be cryptographically signing the firmware. Again, same answer. If they do all this sort of security stuff the cost of the devices is the main issue. So, I'm at the end of my talk. So, does anybody has any questions for me? If this tool is available there in the GitHub maybe you could just download that. This tool is readily available if you wanted to prank your friends or maybe anybody and if you wanted to hack any fitness tracker in every vicinity this tool is there in the GitHub as well. Yeah, this particular one I did was for MF band. You could send some other in you could send the characteristics actually. It's just that characteristics is different, right? So, you could send the characteristics and you could do the same thing on any other fitness tracker system. Any other questions? Did you get in touch with the manufacturers of this device to inform them about the possibility? Yeah, I got in touch with the device manufacturer. I got in touch with them but the problem is that they just don't want to implement that because of the device cost issues, right? This is the problem with the BLE stack where you could snip the package, right? Yes, I was in touch with the manufacturers. So, thank you. Thank you for joining me here. Thank you.