 Right, so this is redeploying the same vulnerabilities. This is a talk about EV security work that we've been doing for a little while together, and some of how we're seeing the same vulnerabilities that have existed for a long time coming back in modern standards. So this is Sebastian, and I'm Richard. We both work at Oxford University. We've been doing vehicle security stuff, among other stuff, for about five years now, really focusing on EVs and charging security, the security when you plug it into charge. And that's all we're going to be talking about today, and then some thoughts about where that field is going. Right, so we've probably all seen something like this, like a charging park, as shown on this slide. Actually, back in December 2022, this was supposed to be the largest charging park in Europe, with, I believe, 56 charging outlets, DC fast charging outlets, but this keeps changing. So every week, we hear about the new largest charging park. But EV charging is not just for cars. We can now see electric trucks, like this one here. Buses, so public transport, is currently electrified. This shows a bus depot in Hamburg, and I don't know if you can see, but there are wires actually hanging down from the ceiling, and these are charging cables. So all these buses you can see here are fully electric. Another example is this, sorry. Another example is this ferry. I'm gonna switch to this, yeah, this ferry. You can see it charges also with, it's electric, and it has 28 charging cables, so they charge simultaneously with 28 charging cables. But there's also now a move in the mining industry, so making mining greener, so electrifying mining equipment, and yeah, why did I tell you all this? Well, all of these examples use actually the same charging standard, which is known as the combined charging system, or short CCS. So I don't know, most of the people are probably familiar with the left one, which is the combined charging system, plug type one, which is used in the US, and on the right is the one that is used in Europe. It's exactly the same technology, underlying technology, it's just a different plug type. So of course there are much more charging standards, as we can see on this overview here, but in this talk we are gonna focus on DC charging using the combined charging system. So why is CCS so interesting for us? Well, CCS is actually using a power line communication, so the car and the charger are communicating during a charging session all the time. So the car is telling the charger, hey, this is how much electricity I need, this is the maximum current, the maximum voltage, this is my state of charge, and the charger actually confirms these messages and also, yeah, exchanges information about the charging session. There is more communication actually going on. For example, with plug and charge, you can actually plug in your car and leave without tapping a card or using an app. It will automatically send your credentials to the charger, and the charging session will be authenticated. So yeah, it's quite a detailed charging standard. There's a range of open standards that underpin it, and this is why it was quite interesting to us. It was also getting deployed very, very widely, even when we first started working on this. And that's a lot of infrastructure that's being built, gonna be expensive, gonna be hard to change, so keen to get in early. And even then, and ever since, we've been finding insecurities in a lot of charging infrastructure, and that made us concerned about the kind of things we were deploying. So particularly for CCS, we were interested in this power line communication because it comes from a system called Home Plug, which was originally these little plug-in adapters you'd use at home for Wi-Fi extension, and there were some issues known about these in the past, and particularly, they were built for a different threat model. In home, shared keys, not a kind of open public access network. Also, they were known decades ago, frankly, to leak their signal radiatively out of cables, and this wasn't necessarily too much of a problem at home, but it's interesting when you see this deployed in a different setting. And of course, it's part of the deploying CCS, and the new world of connected charging was that there are lots more services. There's not just talking car to charger, but also out to behind systems behind the scenes, providing additional services, automated billing, reactive charging, load balancing, all of these things that depend on having a nice secure link. And so it was kind of quite interesting to us. So we'll talk about a couple of bits of work here. We started with just a purely passive threat model. So what is it that someone just eavesdropping might want to do? Well, as ever, lift some fingerprints and have some privately identifiable information, of course, and then also we thought maybe there'd be some opportunity for billing fraud here. So there is a system called Auto Charge, which a couple of networks implement, which just uses identifiers that are pretty much public. If someone could lift these, then they could use them to start to pretend to be people. And threat model is fairly simple. It's a kind of motivated hobbyist, not a lot of information or not a deep technical knowledge to fully build systems from scratch, but someone that can run some code and has access to off the shelf hardware. Not much more than that. So for a particular attack, like one example, we had a look at signal level attenuation characterization, Slack. It's a Slack attack. And this is a system that, in my opinion, probably shouldn't have existed in the first place. This is part of the initialization routine of a charging session, where the car and the charger need to make sure that even though they're connected with a big cable, they're actually talking to the right charger because there's so much potential for crosstalk conducted or radiative that you could just be talking to the charger next door, like two, three meters away. That seems a little bit a bad smell in designing the system. Also, there's a big long protocol here. I mean, you initiate the Slack session, you test the attenuation and all the charges that can here respond, and then you pick the one that has the lowest attenuation. So that's probably the one you're talking to. In step six and seven, you say, oh, okay, I've picked you. You're the charger for me. Can I join? And he goes, yeah, sure. The shared key is this. And that's just in the clear. Unless you've got this security mode turned on, which we've never seen happen, this is just given to the car. And to anyone that can lift that has a key for the network. There's some authentication later, but once you've got the master key, you're in. So can we do this in the world? Well, we set up an experiment. So we got a car, we were in around some charging stations, and then we just set up software-defined radio. We've done this with different equipment set up over time, and just put the antenna at various points in the car, round nearby, a bit of an exploratory thing, to just see what kind of signal we could collect and whether we could use that for something. And we did quite a sort of long evaluation. 800 miles of driving, there were three cars at the time. Every now and then we pick up an electric car rental and we tested a bit further. But even then, 14 locations, six networks, enough to have a good overview of what was happening in the industry, all in the UK, where we're from. But all kinds of places, service stations, hotels, wherever we could find a CCS charger. And to put it into a bit of perspective, so these are places where we're placing the SDR and the antennas. Some of it was super, super close range. You're inside the car, we're interested in whether the signal is leaking out from the cable, whether it's leaking out from the car, which part of the electronics. Some of it was further away. You'll notice it's even sunny in England sometimes, as this picture shows. Here we've got someone just behind the car, in a bay behind, probably five meters away. And you're not going to suspect someone there for picking up your signal. And the other one on the right, it's about four meters away, next bay. But this is a reasonable short distance. And even some with two vehicles. So this is when we had the I-PACE and the GOLF at the same time. And we just went to, at this point, one of the bigger charging parks we could get to. Of course, now that's changed and you have easily 50. But here two was enough, and just one radio shared between and multiple sessions being picked up. And so the end result was, we picked up a signal basically every OEM. You could certainly see on like a frequency plot. So these plots in the top right, they're all spectrums. You can see this distinctive frequency usage that you get with home plug. So you notice these deep notches, they're in there to not interfere with amateur bands. The fact that you've got this little visual fingerprint kind of already tells you that you're picking up the signal. The other thing to say is it vastly varied between location, between site, between charger hardware, how much of the signal came through, and how much noise. You've got all of these noise spikes around. You've got a lot of high power electrical devices working there to provide the charging. So you get a lot of noise when the charging starts. But point is we could pick up the signal everywhere we went. And then we built a receiver. So this is open source, this is entirely software receiver. It takes a file in of just the raw signal and it processes it and pulls out the packets it can find. And this is pretty much just doing what a normal mode then would do, but it's open instead of in a proprietary GIC. So it detects the packets, it synchronizes on them, it does all the OFDM, and then at the end, spits out everything it possibly can. So messages, keys, messages that fail to decode, but you might be able to get some data out of all of these, dumps them into a big database. And as I say, it's available. If it's useful to community, please use it, please build on it. So, I mean, this is a big table of numbers, don't really need to read or parse it very much. The important things are probably left-hand column, lots and lots of messages, thousands, big variation, some sites very bad, some sites much better, but lots of messages. Column on the right, these are messages that fully validated their CRCs, and so these are ones that are good. So these are both metrics of how well we were able to pick it up. So for two examples there, next to the cable, beautiful clean signal, very easy, and is nearly 100% of the messages for the valid. And they're all modulated slightly differently depending on which bit of the protocol they're in, so some of them are easy to pick up than others, but overall you can pick up enough to have a whole session. A bit further away, of course, the performance falls down. We're still picking up some, you know, the bay next door or the bay behind, and I think with more equipment optimization, this was just stuff we had in the lab, you could increase this number further. And then from that we had, we ran off the code, it took a long time to perfect, but then out of individual messages, we just dumped out values. And so what we're seeing here are messages we receive from the end of this Slack protocol. So in the, you can see in this sort of key column, which messages is coming out of and which value we're getting. And two are interesting here. One, for this privacy and fingerprints or identifiers issue, there's a vehicle Mac. We ended up getting the same cars multiple times over a period of months, these didn't change. I mean, the Mac addresses, you could rotate them fine, but they weren't being rotated. Some manufacturers and some batches of cars did not have vehicle unique identifiers, and we see this happening in auto charge, actually. Some vehicles are not compatible because some of the Macs are zeroed. The majority that we saw did have complete unique Macs. You can identify that car forever from that and you can pick it up later sessions as normal. Then there's also, of course, the key. This arrives a few seconds into starting a session and you pick it up. I mean, that's the key in plain text there. You also get it in Wireshark. And then from then on, the code automatically starts to decrypt the rest of the session once it's got that key. We're also outwitting traffic to Wireshark. It's a little bit of a messy capture here, but you can kind of see the process evolving. So at the top, there's this request to get the master key. That's the stages six and seven I was talking about before, getting it back and then trying to find the control that's actually going to initiate the charge. Keen observers on the blue lines, it talks support 15, 118. That's the ISO number of the standard. That was a kind of fun little Easter egg. And then it sets up a tunnel and then sets up higher communication where there's a whole stack of things. It's IP communication. Then there's TCP on top. Then maybe there's crypto on top of that. And then there's just sending XML back and forth for state of charge, for charging speed, temperature and all these other things. That's also up where you would have like automated billing and stuff per the standard. All of those would require you to have a TLS session. So I'm not saying that there is traffic for that that we've ever seen unencrypted or accessible from here. You're only getting the lower layers. There's also a lot of support though for external additional services to be built on. This is ultimately an IP link, right? With two Linux boxes either end, you could put any services you want. You can open additional ports, you can have a web interface and so on. And there's some talk about that, although we haven't seen it much in the wild being deployed. But any of that, you're then back into whether the developer secures that as well as they should. For the simplest standard, DIN70121, this is just charging. There's no security on top of that. But there's also only so much you can learn. You can get the identifier out, you can listen to traffic, but there's not too much important stuff going over it. There has been latterly some talk about different approaches to trying to cure this. Some people, one particularly big manufacturer is talking about just establishing a VPN on top, which maybe goes back to your own charging provider. I mean, that or TLS is providing you some crypto either way. I think the big problem is doing the PKI to support this and having the right keys for every charger, for the car, for the driver, for everyone involved. Still ongoing. Right, so as Richard just told us, he basically found that there is a unique high quality unintentional wireless channel when you use PLC charging or when you use CCS and that uses PLC. So the main question we asked ourselves was, can we actually also inject? Because the charging cable is a perfect antenna, right? We can receive, it emits the signal. So can we also inject into the antenna? So we looked at what can someone do, like a threat model about active attack? So how can you actually interact with this communication and what can you do? So since CCS or in general electric vehicles are becoming part of critical infrastructure, so they will be acting as battery buffers for renewable energies. We will have vehicle to grid communication and feed electricity back into the grid. It's kind of important that they are available. So we need this communication, otherwise we will not be able to use these services. So we looked at, can we disrupt an individual vehicle? So this actually is probably the weakest motivation, but we just had it yesterday actually when we drove here from LA. We wanted to charge our car and all of the chargers were occupied. So could you interrupt actually one of the chargers and get the cable? I mean, no one would notice, right? So most of the cars, don't know if you're aware of that, but most of the cars actually unlock the charging cable if the charging has stopped or is interrupted. We assume it's a safety feature, but yeah, most of the cars we tested, actually all of the cars I believe, implemented this feature. So yeah, you could just disrupt a single vehicle, get the charging cable, charge yours and be happy. But of course, there could be another motivation, a financial motivation for example, back in Oxford in the UK, DPD has fully electric fleet now. I believe 40 to 50 vehicles fully electric. So if you can just knock out their entire fleet, so they can't charge, let's say during the night, you could just blackmail them. They will turn up in the morning and the cars are not charged. Another motivation could be unspecific disruption. So you try to disrupt as many cars as possible or as many charging parks as possible, to for example, disrupt supply chain. We saw earlier buses are getting electrified, ferries and trucks. So if you just cause widespread disruption, that's gonna be an issue. Especially if we then go a few years further and look at vehicle to grid communication and bi-directional charging. Oh yeah, I should mention maybe for this threat model or for these goals, we assume exactly the same capabilities. So just access to software defined radio or transmitter off the shelf you can get from Amazon and a little bit of knowledge about digital signal processing. So we found Brokenwire and Brokenwire exploits the CSMA-CA mechanism used by Homeplug Greenfy. So how did we actually find this? Well again, we had this, there is an unintentional wireless channel, can we inject? And then we looked at the standard actually and we found this interesting phrase. And this phrase basically says that the modem should consider someone else communicating if they receive a preamble with 2DB above noise. What this means is basically the receiver or the transmitter would actually stop transmitting when someone else is already transmitting to make sure there's no interference happening. For some of you who might not be familiar with CSMA-CA, here's just a diagram how this usually works. So let's assume you have a car and a charger and they don't have, or wouldn't have CSMA-CA, the car would send a message, charger replies, all are happy. But if they send at the same time, you would have interference. So instead, actually the Home Plug Green Fire Modem checks if the channel is clear to send. And if it is clear to send, it would send the message and so on. And if it is actually not clear to send, and you can see it here, it waits for a random period of time. So it backs off and then tries again and checks is the channel now clear. And if it is, it sends the message. So on the previous slide, I just showed you the standard says someone is communicating or the channel is busy if we see a preamble 2 dB above noise. And so what someone could do, actually if we now have an attacker, someone could just during a communication, which is happening just fine, start sending a signal to make the channel look busy. So in our case actually, that is the preamble. So here you can see Home Plug Green Fire Frame. We collected by just plucking a modem into a software defined radio. So this is in the time domain. And the first bit you can see is the preamble. So that is used to detect if someone is communicating and also do frequency offset correction and timing. And then you have the frame control and yeah, the legacy frame control and the AV frame control. And then you have the payload. And as I said, this was collected while plucking the modem actually into our receiver. And there is also some noise, of course. And you might have already spotted it, but there is also another preamble in there. And this is a preamble which is 2 dB above noise. And this preamble actually already caused the modems to back off because they consider this as, oh, someone is communicating. I need to stop. I need to wait until this communication has ended. So when we found this vulnerability, we initially tested it in our lab. We got these development boards. These boards have exactly the same Qualcomm chip as you can find it in charging stations. It's a QCA 7000. And yeah, as I said, it's exactly the same chip. We connected one to a Raspberry Pi and this was our electric vehicle and then the other one, which was our charging station. So the Raspberry Pi was actually just providing some traffic so we can measure packet loss and the quality, like, examine the quality of the channel basically. Yeah, we connected them with a charging cable and then we had an attacker, which you can see in the lower part. We used just a super simple antenna. It's a very low frequency. So PLC is communicating at around two to 28 megahertz, like in this band. So we set the center frequency to 17 megahertz. So we have a pretty high or large wavelengths. So our antenna was actually just a bunch of wires. And I'll have a photo later where you can see it. We connected this to a small amplifier and the LimeSDR. So this setup costs you maybe, I mean, now the LimeSDR actually got quite expensive, but it was maybe $250, $300 before the chip prices, yeah. Right, so we did some experiments in our lab, like in the university. You can see the home plug green fire modems in the back. Our attacker set up in the front and this was roughly, I don't know, maybe eight, nine meters and we successfully disrupted it. So we plotted some graphs. We basically tested for a given distance, how much power do we need to disrupt this charging communication? I mean, just a home plug green fire communication. And as you can see, so it's plotted in DBM and milliwatts on the left DBM. You can see that for a distance of 10 meters, we actually were able to disrupt this communication with less than 10 DBM or 10 milliwatts. So your Wi-Fi router is probably transmitting at around 100 milliwatts. So just to give you an idea, this is like very, very low output power and this was from 10 meters away. So we also wanted to test, can we actually disrupt between floors just for the sake of it? And yeah, we were able to do it. So you can see on the first floor, we put the modems there. We didn't even stretch out the charging cable. So it was like a bunch of wires or just like a pile of wires. And then we were the floor below and we had the antenna lined up and just transmitted. I can't remember exactly how much power we had for this experiment, but it was on the order of like 70 to 100 milliwatts. So of course we were curious actually, I mean, we only tested it so far in the lab. Can we actually target charging stations out in the wild? Can we test it on real cars? So we got all of our equipment into the boot of a car. Here actually you can see our antenna, which is just a bunch of wires, as I mentioned. Amplifier, LIME-SDR, bench power supply, which we powered with a UPS, but we changed the setup. So now we actually just use a power bank with the step-up converter because we need 12 volts for the amplifier. So you can easily fit this in your backpack, for example. And yeah, we tested different scenarios. So for example, can I just attach the antenna to the side of the car or just in the boot and then drive or pass by a charger? Can we do a scenario where I'm behind some like bushes and then disrupt the charging? This is, so I would say scenario two, three and four are commonly seen at supermarkets, for example. And then we did another one, which was just focusing on distance. So we wanted to see how far can we actually go, given our power budget of one watt, which was limited by government regulations. So we couldn't bring Smith higher than one watt. I also want to say we don't reveal which cars we tested and which chargers, just because we want to stress it's a standards issue. It's not an individual car manufacturer who implemented it wrong. They follow the standard and the standard, like Home Black Green Fire, is just vulnerable. So these were the cars we tested. This overview just shows you, it's not just cheap cars. It goes up to $150,000 cars. So it was actually quite sad. We had to drive all these cars for quite a while and then run down the batteries, charge them again, run down the battery. So it was quite fun driving the shooting break. But yeah, and so yeah, as you can see, all of them are vulnerable. It also doesn't matter what the charging capacity is. So of course, if you charge with the higher capacity, you might have more noise, but didn't really matter, it still worked. So we did the distance experiment. Again, one watt of amplification. So roughly one watt, it was just below. And we were able to disrupt it from around 50 meters. So what can we do to prevent this? So to prevent leaking the signal or actually having the antenna or the charging cable acting as an antenna, of course shielding would be the way to go. But actually shielding doesn't work here very well because the cable is already quite stiff and heavy. Adding shielding might reduce the vulnerability or susceptibility to EMI, but actually in the end, you just increase the power. And since we were talking about super low transmission power here, you can buy a 10 watt, 70 watt or 600 watt amplifier in this band and you would still be good and then yeah, you would need to add more shielding. So it's an arms race. Another idea would be upgrade the firmware of the Qualcomm chip. And if anyone from Qualcomm is here by any chance, I mean, we would be happy to chat about this because it would be quite interesting to know if actually the preamble detection and the 2DB, if this is a threshold which is set in firmware, or if it's a hardware limitation. And then finally, one thing we noticed, once you disrupt the charging session, it stays disrupted. So you would need to walk there, unplug the cable, plug it in again, tap your card or activate via the app or if you have plug and charge, I guess it would do it automatically, but you would need to re-authenticate, which is a pain because if you have a depot, like the DPD fleet I mentioned earlier, you'd need to go there, disrupt it, it takes 20 seconds and then you leave and it will be disrupted for the whole night. It automatically doesn't re-authenticate or re-continue the charging session. So we said redeploying the same vulnerabilities. So why was this the title of our talk? Well, what is next? That's the big question. And currently there is work going on on the MegaWatt charging system, MCS. And interestingly, so it has almost four MegaWatt charging capacity, but interestingly, it also uses power line communication again. It uses differential PLC, which should be, yeah, not as easy to disrupt, but we haven't tested it yet because it's not widely deployed yet. Just for your information, this is like the plug. Compared to CCS, I mean, it looks quite similar, but you now have a communication interface in the middle for a twisted pair. Yeah, so the differential signaling should significantly improve like the EMC compatibility of the PLC communication. But yeah, as I said, we haven't tested this yet. And using a shielded, unshielded twisted pair, UDP wire should also help to increase noise immunity. Roughly 40 dB higher is Jarin saying on their website. So Jarin is the standardization body of CCS and MCS. But I would like to highlight here that even if you shield the cable, you use differential PLC and you use twisted pair, the signal could just couple into some other bits, right? Like onto the PCB directly, so you could modulate your signal into a higher carrier, high frequency carrier. And so it's not, if you just make the wire not attackable, it doesn't mean the system is not attackable. And now there is also the North American charging standard. I guess you all know it, it's the Tesla plug and they say basically that for DC charging, the electric vehicle should or NACS should support power line communication to make it compatible with DIN7121. And it should also support ISO 5118, which means if it needs to support ISO 5118, it needs to support PLC communication. So what is the conclusion? Well, CCS is vulnerable to wireless attacks. We show that we can e-drop on it, but we can also inject. Roughly 20 million vehicles are currently vulnerable because CCS is mainly used or is the DC charging standard in Europe. It's also widely used in the US and in some parts of Asia. And we just think PLC is just not a good technology to use in such a critical communication. So I just have a video for you. Just ignore the Renault Saria on the left. As I said, I didn't want to reveal which car we tested on, but yeah. So the car was charging as you could see. And we put the equipment as you saw in one of the photos in the back of the car. And then as soon as we pass by, you will see that the charging stopped. Yeah, and this is the error where you need to go unplug it, plug it in again so it doesn't go away automatically. Right, that's it. If you have any questions, feel free to reach out to us on brokenwire.fail. We have more information. There is also the paper available and there is also some information on Nest. Yeah, for the CDE we got. But yeah, happy to take any questions. Thank you. Oh yeah, sorry. There is a microphone right here if you have any questions. Hi. Just a question, were you able to also, there was a, you mentioned about the billing. You can, there's a communication between vehicle and the charging station. And there was a billing associated with it. Were you also able to get into the billing? Like able to manipulate the user to charge? Sorry, if I understood you correctly, you're talking, or you're asking about the identifier which is transmitted between the car and the charger. So there are different implementations I would say. There is one which is called auto charge which is basically the MAC address of your EV charging controller. And so if you have the MAC address, yeah, you can, so if I e-stop on your communication and get your MAC address and spoof my MAC address, I could charge and you would be paying for it. Okay, so basically we can sniff MAC address from the car between the charger during the session. And then we can use this to bill for that user that we sniff. Is that correct? Sorry, could you speak up a bit? It's hard to hear. So the car connects to the charging station during the initial session, we sniff the MAC address and then can we replay that to charge the user? Right, if we can replay, sorry, do you want to? Yes, yeah, you capture that MAC address, you set your MAC address, that's associated with someone's billing account and then you just go and charge until they cancel it because they realize they're being charged. It doesn't, it's not the same for plug and charge and this is the sort of gold standard thing. Auto charge was just a couple of industry players wanting to get in on this kind of frictionless experience early, plug and charge, no, their certificates both sides, there's as far as we know, good crypto, it's not very widely deployed yet, but yeah, that's safe. Thanks a lot. Dumb question, will the slide deck be available on the GitHub site? The, this slide deck? That slide deck. It could be, yes. It's not currently, but it could be. There's certainly slides from other talks we've done on it. This one has a little bit of extra content, but yeah, that paper, codes, you can, yeah. Some appropriate slide deck, I know some folks where the slide deck would be great for explaining. Yeah, of course, yeah, I think you'll find all the resources there, no worries. One question, please. The MAC address that you identified, this is the MAC address of the vehicle of the charging system of the vehicle. There are two, and you get both of them in different messages. Are you sure it's the same one? So there's a modem one, and then there's one for the, where is it, the charge controller, and we've observed different behavior in different vehicles. Some of them have one bit different, some have the same MAC address in both, some have one of them blanks and one of them not, it depends on which one you're going to have. It's totally different DCUs, the MAC address, what you'll be in part of the TCU, and not part of the charging system. I'm sorry, I missed that bit, the MAC address. The MAC address will come from the TCU. From the controller on the EVCC. Yes, not from the charging system. But we have one from the modem and one from that, from the EVCC. So I could show you in some captures, and it does, as I say, vary between, but yeah, they establish a communication between the two high level entities, and then the very early initialization messages are modem to modem, so we have one for those as well. Okay, thanks. Hi, thank you. You were talking about NACS and similar vulnerabilities. Seeing as Naxx is coming up, what Sharon is trying to standardize it now, is this an opportunity to kind of address some of the vulnerabilities with some of your suggestions? Yes, would be our opinion. There's, I mean, some things are very difficult to change, right, you've got a standard that has this communication which possibly not the best choice baked into it, that's probably gonna be difficult to do. Some changes are coming that are really good, like MCS having this differential PLC, or changes you could deploy later, like firmware differences, or additional sort of detection systems for just constant preamble, something. But yeah, I mean, as a general rule, yes, let's try to fix this, and hence why we're sort of doing this talk now. And we'd be happy to engage with anyone that's doing work on any new charging standards. We are. Thank you. Sorry, if you need to, if you wanna need to. Yeah, so the question I have is like, the SDR you guys used to do this attack is kind of unique, because to do this you need something that has at least 28 megahertz of RF bandwidth. I'm sorry, I'm having difficulty hearing you. Probably just close to the mic is fine. Okay, so the SDR you guys used to do this is somewhat unique in the fact, because you need like about 28 megahertz of RF bandwidth in order to do this attack. But so like things like a hack RF won't work because they've only got 20 megahertz. Now the new LIME SDRs don't have this nice wide band that the original one did, and hence that's why the price of these have gone up. But I'm kinda curious, have you guys found anything other than like a high end USRP that will do this? Has it required RF bandwidth? Cause I'd love to hear about that. Yeah, so we played with a couple of different ones. I mean, I think prices went up a little bit across the board, at the time the big LIME SDR was what, a couple of hundred dollars. And that was really good, that was why we had it. And it also worked natively in that band. The previous work, the eavesdropping, I was using a Blade RF, which was reasonably inexpensive at the time, but it didn't tune to that band, so we had an up converter to bring up to there. And basically we've had pretty good success with those. I will, I'm not quite sure exactly what's gonna be the best buy at the moment, but my gut feeling is probably still a LIME SDR. They've got more expensive, but they're still not quite USRP territory. So the current, are you talking about the old version and trying to get it off eBay? Frankly, either, I would probably, a V2 would should work fine. We haven't tested the V2 ourselves, but you know, it- Well the V2 does have the required bandwidth? Yes. And it'll tune down to, you know, tune down to 22 to 30 megahertz. And in fact, I mean, depending on what attack you want to do, whether you're, you know, you could just do up conversion, down conversion and use something else, that might be quite a good route. I mean, if you wanted the recommendation what to buy, we could perhaps have a little offline chat, but most of the things that are above, you know, an RTL or something should work fine. I will also say, you might have some excess, even with the 20 megahertz from a hack RF, for two reasons. One, we did test broken wire with less of the preamble, you know, because some of this will get attenuated anyway, and I can't remember how low we went, but you could cut off a surprising amount and still have the preamble's register as accurate. Although the preambles don't use all the OFDM channels? They do, but even if some of it is horribly attenuated, there's enough signal for it to correlate well and trigger as a preamble. Oh, sweet. In theory, you should be able to do some eavesdropping because Greenfy replicates all across the band. So there's five copies or sort of seven copies, depending on which message you're talking about, for exactly the same problem. You know, it's a very, very hostile network if your hostile transmission environment on these wires, and so it's built to be robust against that and you could lose a whole chunk of the subcarriers and still recover messages. Of course, your mileage may vary, but you might have some excess with the hack RF, if not, yeah, probably swapping for a LimeSDR or the later RF in UpConverter. Very interesting, thank you. I didn't know that about it. I thought it was using all the audience. Yeah, of course, I mean, it tries to, but it's surprisingly resistant to loss or noise or whatever. Okay. Happy to talk more afterwards, yeah. Okay, okay, cool. Hi, I'm not really knowledgeable about the protocol, but it has Qualcomm implemented something like a spread spectrum or something that can mitigate the radiations. I mean, whenever we do EMC testing, we basically look for, if we have this type of radiations, we reduce the speed, reduce the slew rates or also doing some spread spectrum on the transceivers to mitigate the radiations. Has this been already placed on the table? So, no, it's an RF-EM system and there's certainly per-carrier control to stay under EMC limits. So part of it was, of course, that distinctive spectrum template that I showed, you know, notching out the amateur bands and you could power control there or notch more of them out if you needed to and for EMC purposes, fine. It is just under the threshold for radiation. I think realistically, it's just that if you turn up your LNA enough, you can kind of still pick it up, but it's still compliant. Okay, so. And then there's Plainty on above that in terms of varying modulation to try to get the best rates and so on, but that's less of a compliance thing and more of a throughput issue. Okay, so yeah, so only through differential wires canceling the fields and that will be enough for the mitigation right? Yeah, I mean, so some limitations of this are a wire, at which point it's just going to be leaking out all over the place. The differential down a twisted pair, yeah, that's probably going to be very helpful, but bear in mind, this is a technology that's coming from an in-home environment and genuinely people's power wiring, which is just wires randomly laid over 50 years by different electricians and so on. So it's not, it wasn't really built as a communication protocol for a purpose built environment, but rather making the best use that it could have of the conditions it had. And that's why it's not ideal there. And is the amount of information that you do during the handshake really needs the amount of speed or why not use lean or tech? Yeah, I mean, all the other charging standards do not, I typically use a canvas link and do fine. I think a lot of it was a future-proofing idea and there was some really nice design choices. Have an IP link, you can just do whatever, you can deploy the same technologies you have, there's no reinventing the wheel. Personally, I'm not sure PLC was the best underpinning for that, but no, it's hard to make a case, it was more to just create the capability to deploy whatever we might need in the future rather than because you need that much data. Okay. Well, thanks. Thanks very much. And thanks everyone for coming.