Pwning Electric Motorcycles

Hello. Hello. >> Good morning. >> Well, thanks everyone for coming to our session. Uh, this talk documents our adventures into researching vulnerabilities into different bikes manufactured by a certain electric motorcycle manufacturer. But which electric motorcycle manufacturer are we talking about? Well, we can't say for reasons that we'll get into uh later in this talk. Uh the manufacturer themselves uh we're not allowed to talk about at this point. So, we've changed the names to protect the guilty. Uh so, you will see Moto Motorcycles throughout this entire talk. And just know that this is a standin for the actual company. Now, if you think you can guess who we're talking about, you can't. Can't do it. But if you were able to

hypothetically guess who we were talking about, you would actually be able to follow the steps that we're going to talk about in this uh presentation and reproduce the uh or identify the vulnerabilities still present. Uh okay. So uh to begin with we need to understand why Panie and myself chose uh this particular manufacturer to go into. Uh so first a little background we need to understand how a lot of modern motor uh not not motorcycles just vehicles in general modern vehicle manufacturers how they like to push updates. Uh so making your customer come into a dealership every time you've got a firmware update on your uh you know new vehicle that's really expensive and in today's world of

just constant updates on everything all the time it's just unacceptable. So, what if manufacturers instead just push these updates straight to their vehicles? This is a process known as overtheair updates or OTAA. And this is especially common on modern electric vehicles. Now, unfortunately, our employer, Veraritoss, who sponsored this project, they didn't want to buy us a $60,000 electric car for research. Uh, well, what about motorcycles then? Well, there are quite a few electric motorcycle manufacturers doing OTAA as well. And that brings us to our target. So, here is Moto Motorcycles page talking about their newest vehicles that support this feature. They have the ability to push updates straight over a 4G cellular connection. So, uh what if we manage to find some

vulnerabilities in this process? uh malicious firmware on vehicles has serious consequences. If an attacker can modify the firmware on a safety critical fun uh system, they could potentially injure or even kill someone. So to understand these kinds of safety concerns, we first need to dig into this firmware update process, see if it has any potential vulnerabilities. And if we do find vulnerabilities that would allow someone to upload their own unauthorized firmware, we would need to understand what these systems actually control in order to evaluate their impact. But where would we even start with this? Well, initial research into this company revealed something called the main bike board. And this appears to be responsible for controlling the main

functions of these electric bikes. And it's kind of the equivalent of an ECU on a traditional gas powered motorcycle or car, but quite a bit smarter and handling quite a bit more functionality. >> So, so our first thought was to attack this sort of at the source and go and attack it on the hardware level. Um, we tried to get uh MBB main breadboard from a licensed retailer. This is the official way to get replacement parts if you're a technician or dealer. Um, and we'd know in this case exactly what model we got it from. Um, but unfortunately after a long back and forth with the retailer and by proxy their contact at Moto, uh, we found that

they will only sell you parts, at least for these motorcycles, if you have a VIN number, which we don't. Um, thankfully they eventually refunded us the $400 that we tried to pay for it, but eBay exists. Um, so when it arrived, we got started opening it up. Uh, it turns out that it's sort of structured like a Matrioska doll, uh, in that it has this ABS shell encapsulating a resin encased brick, which itself is around the actual uh, PCB. So, I'd read online at this point that methylene chloride would melt epoxy and excitedly went to a chemicals retailer and got some methylene chloride and immersed the board in the in the methylene chloride and nothing happened.

Um, so turns out after much more research that uh the the article I'd read had been kind of wrong um or I'd misread it after um after researching more. Turns out that methylene chloride is pretty good at dissolving epoxies that are cured but which is the most common type of potting resin but not so good at uh at other resins. Yeah, excuse me. like polyurethane. Polyurethane much harder to dissolve, much more annoying. Uh it turns out that you need either methylethyl ketone or a specialized mixture which has been patented. Found the patent. Uh it's 70% by volume dchlorommethane, 20% byol dimethylformmide and 10% by volume methanol which turns out is a class 2 carcinogen class one skit and

irritant and highly flammable and also $200 per liter. So I didn't really want to do that. So we put that avenue of ingress on pause for the moment. >> Okay. So, so Moto really went overboard on this potting. Even if we could cleanly remove the polyurethane without damaging the chip, it's possible that there would be even further obstacles like chip read protections on the actual components that have the firmware in them. So, we need some other way to get this firmware. Well, what if we could intercept the firmware instead? That's the whole point of this. Why don't we just grab that firmware? Uh, but unfortunately, we don't have a cellular module. You also needed a cellular

module to pull the updates into the main bike board. And it turns out intercepting uh 4G communications is complicated and potentially illegal. But what if there was another way to forform updates on these bikes? So before they started updating their bikes over cellular, Moto actually used an app and a Bluetooth update process to push these updates. In fact, you can still do this process on modern bikes if the cellular update process isn't working. And this is exciting because it means the firmware is now passing through something we can control, a phone. Ideally, we would push a firmware update to a real bike and simply intercept the communication using say a rooted phone that's passing all of its

network traffic through a uh interception proxy. But since we didn't have a real bike, uh why don't we just reverse engineer the app and understand how it's connecting to the firmware update server and see how is it fetching it to stream it into the main bike board. Uh so yeah, like I said, let's just see if we can spoof that request instead rather than, you know, having to actually have a real physical bite. So first we'll just create a virtual Android device and download the latest version of the app on it. So I'm using Aurora Store since this is a non- Googlele Services virtual device that we can grab that APK later. But this is a

real app being pulled from Google Play servers. So, we just need to grab that APK off the virtual device, pull it down to the virtual machine, excuse me, or to our physical machine for analysis. Uh, like pretty typical just ADB stuff at this point. But with that, we now have the fun part can begin. Uh, so we can open this APK in Jad X, which can extract. I'm I'm moving the wrong microphone. Thank you. I appreciate it. Thanks. Uh yeah, so we can take this APK, bring it into Jadex and it will extract the DEX files from the APK and decompile it into Java. And the great thing about this process is that the name spaces and symbols

uh from the decompiled code are uh they're preserved in the actual DEX files. So, Jadex is able to show us the actual function names that the developers included. And so, for those of you who do a lot of reverse engineering, you know that if you actually have the original symbols, that's a huge benefit. So, that made this uh reverse engineering the app itself a lot easier. And thankfully, they weren't doing any sort of additional things to obfiscate those names or, you know, strip the original symbols. So, we've got it in addex. We've got the uh decompile Java. But where do we begin with? Well, first we need to figure out what kind of URLs we

think that it might be trying to pull these updates from. And uh an obvious one is that there's this fo-server. Motorcycles.com. And again, I'm I'm replacing I'm redacting this URL, but you know, if you knew the real name, you replaced it. This is a real server on the internet. It's not we're not just uh making this up. So, we know that base URL uh but we have no idea how to interact with it. And maybe maybe we need a motorcycle like a physical motorcycle in order to be able to get some sort of authentication data to interact with it. So, we're still not we're still not there yet. Uh so, let's just look at what references that constant. What

references that firmware update constant? Well, we see this API call for firmware within the APK. So, that looks pretty promising. Uh so the actual request is happening right here. It's happening against the URI update. So it's uh fa-server.mmoto motorcycles.com/update. Okay, so we're quite a bit closer. And then it looks like we see what looks like maybe a uh custom moto 1.0 user agent. Well, if we're going to pretend to be the app, then we better spoof that, too, just so that we're a little bit more stealthy and maybe maybe the app uh or the firmware update server won't respond to us unless it thinks we're really the app. Uh so, we'll spoof that as well. So, this information, it

gets passed into a retrofit call. Retrofit is a library that makes interacting with REST APIs from Java or Cotlin a lot easier. And the important components we need to locate in this uh call is the URL which we already have. We already got that. It looks like there's this authorization header. We still need to figure out what that is. And then there's the user agent which we've noted down previously. So here's the parameter for that authorization header. Let's see where it's coming from. Uh so here's that function that it's pulling from. Oh, it's a static bearer token. Uh so they actually did have another set of APIs that are doing things a lot more intelligently but for the update process

they're just you know hard- coding that key. So that's fantastic. So we've got everything we need. We've got uh all the parameters that we need to spoof a call to the update server as if we were the app. Uh and we'll just use a crawl command to do that. And what do we get back? We get a zip file. So, let's extract this and uh see what we've got. So, it looks like this zip file has multiple has multiple versions of the firmware, which is exactly what we've been looking for. Uh, but it gets even better. For reasons that are still unclear to us, they are shipping ARMLink dump files used to build this firmware. As you

might be able to guess from the name or maybe already are familiar with the uh tool chain, ARMLink is a tool used to compile uh compiled object files, link it into the final firmware blob that gets put onto the device physically. What's great about this dump file is that it actually includes memory table information and symbols mapped to the function addresses uh in the final blob. And remember I was talking earlier about if you're doing reverse engineering, it's a huge pain in to uh to figure out infer a function's meaning by looking through the logic. So it was really nice of them to include this for us to reverse engineer it. Uh so we're nearly ready to pull this into

Gedra for some serious static analysis. But first we need to figure out what the architecture is. And there are huge number of ways to figure this out, but in the ARMLink files, there are references in the symbols to XMC 4500 and XMC 4800. Those are both automotive chips. That makes sense. And both of those are Cortex ARM systems. So that's all the information we need. We'll uh import one of these.bin files. We'll tell Gedra that it's an ARM Cortex binary. And we'll use some uh some of the information from the memory tables in the armling files to set the correct base address. But we can do another step to make it even better. uh we'll write a quick

gedra jyon script that imports those function names from the armlink dump file and we'll actually label them in gedra so that after that we end up with some really nicely decompiled code uh that actually has the original function names it's not perfect we don't have variable symbols we don't have comments but it looks pretty nice so what was in the firmware first thing we found to do changed this s uh which we figured out later is the static salt of an authentication header that handles developer access to the firmware. So that's a good start. Uh digging deeper into the off function, which is a challenge response flow, I found some instructions for how to generate the

correct response for the challenge and helpfully a note on who to talk to if you can't generate one. Uh Mitchell immediately found this person on LinkedIn. It's not his actual picture, but it looks very similar. Uh, looking more into the authentication for the challenge response flow to see if it was vulnerable. Uh, it's pretty simple. If you you tell it to authenticate to one of the four privilege levels, it generates a challenge code. You type that challenge code into your authentication server that's running uh at that URL we just showed you and it gives you back a response that you type in and it authenticates you. But the whole process uses symmetric cryptography based on a

simple salted hash of the challenge with the hard-coded salt that we just showed you. So you can trivally trivially write your own challenge response generator. I am not really a C person, so that wasn't something I immediately wanted to jump into. So around this time, I was also poking around the unofficial service manual wiki. And like we said at the beginning, there's some screenshots of the mobile app uh saying that you can update the firmware via the app. So we start so we decided to start looking into that as well because I like Jadex more than I like C. So around this time we had about five attack vectors potentially. Could patch the firmware, could try and hack

the phone app, could try and spearfish Will specifically, could try and make a malicious app that and get someone to download it, or we could try and hack the OTAA firmware delivery server. The last three are outside the scope of the project. >> Uh so we we're left with the first two and of those, hacking a phone app is the easiest. So let's look at the app again. Opening it up in Jadex, we see some activities in the manifest that seem to be handling the firmware updates. Uh we can decompile those to see how they work. Um now blank slide for a moment while I get on soap box. I am lazy by nature. Um and around this time my

manager had been getting on me to start using MCP tools. I don't like AI. AI is bad. But also I don't want to spend like 10 hours reading Cotlin. So I installed the J Gedra Jadex and Freda MCP servers and told Claude to look at them and it made me stupider. Um but what did we find? Static firmware signing salt which is hardcoded and the same across all byes. The signature is the same is just a shaw 512 hash of the firmware and the salt and is stored in the metadata of the firmware file. So knowing the salt we can sign our own arbitrary firmware. Two, absence of symmetric cryptography across the entire system. Uh

discoverable salts rather than RSA extra signatures which means we can forge any firmware or authentication response. Three, there's no root detection and we can bypass any authentication of the firmware upload uh by doing a free to hook of the app. For unauthenticated CANbus flashing, if doing a free to hook of the app is too hard for you, you can just plug directly into the canvas, which has no authentication whatsoever. And five, hard-coded dev credentials. So, putting this all together, there's at least two really easy exploit changes, getting back on my soap box because I got wooed before. Um, AI is both bad for the environment and for your mental health and is currently being used to generate CSAM on Twitter.

Uh, you don't need to build the Torment Nexus, but I used it anyway. And so, this has all been virtue signaling. Um, >> mostly I just didn't want to uncritically endorse its use when you don't need it. Hurry up. Okay. Secondly, vibe coding is not real coding. It makes you lazy and I don't really respect people who vibe code. So, here's some vibe code. Um, this is a 1200 line Freda hook that uh when you open the app, it force navigates to the Bluetooth pairing activity. Uh then using the app's own imported Bluetooth handling libraries, it scans for nearby Bluetooth enabled moto motorcycles. It then spams BLE connection requests to all the motorcycles it found.

And then finally, it makes sure that the custom firmware you gave it is signed correctly and uploads it via firmware update. The bike needs to be in pairing mode for this to work. Uh but that takes all of 5 seconds, literally. Um, and if it's never been paired with a different phone before, you don't actually even have to have it explicitly in pairing mode. Tool two, canvas abuse. Uh, for about $100, you can build a tool with a Raspberry Pi Zero that uh connects to the bike's uh canvas, which goes directly into the battery management system, BMS, over the OBD2 port and uploads arbitrary firmware. Uh, like I said, this is completely unauthenticated and $100, well, like slightly annoying

of a price is more is less than onetenth the price of buying a commercial harness to do the same thing. We'll get to what you can do with the canvas later. It's not great. Uh, I also made a controller script for this for the Raspberry Pi that I had. Do they work? Because we couldn't get a bike, we're not sure. But based on all of the uh all of the reversing that we did, probably. So, what's the worst that could happen? Imagine you're an afarious hacker, possibly with a motorcycle to sell, possibly with a Bluetooth connection and a test ride at the dealership. Unlike cutting brake lines or something, which is easy to spot and fix,

maliciously reflashing the firmware is potentially invisible and can be done almost without touching the bike. If you add in a C2 server or a ransomware lockout, you can essentially control a $20,000 piece of equipment for free. So, I said control. You can't fully drive by wire, unfortunately. But what you can do is control the motor torque output, regenerative braking, battery discharge, cellular connection, and GPS tracking. So, let's look at some worst case scenarios. Torque control manipulation. If you apply maximum torque all at once, you can or apply zero torque at highway speeds. You can also force the bike to go into full reverse while at highway speeds, potentially throwing the rider. Oh, I forgot to click the button. So,

now it's going to do this for a while.

could also turn on full regenerative braking all at once, also causing a sudden decrease in speed. Uh, you can also I forgot how slow these slides are. You can also tell the bike it's currently charging, which causes it to cut all motor power. None of these have lockouts for speed. So, they work if the bike is in motion. You can also disable the safety controls that allow the bike to perform an emergency shutdown in the case of a battery fire or collision. And finally, you can send heartbeat messages with your GPS coordinates to an arbitrary receiver. And again, this isn't just like theoretical whatifs. We actually scaffolded out some C++ pseudo code of what a C2 receiver for Moto would look

like.

So, here's how it works. The bike has a built-in 4G LTE cellular modem, uh, which it sends heartbeat functions to the app and to the Moto servers. We write malicious firmware update that hooks into the existing cellular communications module and MBB functions and bypass that normal heartbeat function to the Moto servers and instead send it to our controlled server. It then listens for received commands from the cell service and sends beacon packets back containing speed, GPS coordinates, time stamp, battery status, etc. and on command can do any of the vulnerable things that we just talked about potentially leading to a crash or serious injury. We thought, well, maybe it fully uses up all the space on it chip and there's no

even way to put in a C2 server. That's not the case. Um, it turns out that they're not even close to using up the entire uh space on the chip. So, inserting about 18 kilobytes of malicious code and a trampoline to get there is easy. Uh, we even found some code caves that you could put it in specifically. So, back to Mitchell. Okay, so with a handful of serious vulnerabilities identified, we decided it was time to contact the manufacturer. At this point, might not come as any surprise that there isn't a dedicated email for reporting security vulnerabilities, but there are a few general emails advertised on the official site for general inquiries. So, I guess we'll try that. So, we tried to

reach out uh and get a better Excuse me. Get a better uh we wanted to explain our situation, get a better point of contact because we don't want to just be sending a bunch of serious vulnerability reports just to whoever's handling these uh general inquiries. So, we wanted an actual security point of contact. We got nothing. So, we tried reaching out on one of the different email addresses that they called out and nothing. Okay. So, I I'll give them a call over their general support line. There's no way for them to ignore us now. So, I got in contact with a customer service representative and they passed me along to voicemail. So, I left a voicemail

explaining the situation and I asked for them to call me back. Did they call me back? >> Yes. >> Okay. So, this feels like it might be intentional, but we persisted for five months sending them messages on LinkedIn and other email contacts. We even got uh there were some sales people who helped us out because they're better at trying to cold call people and get contact with them. Surprise, surprise. Still haven't heard back from them yet. Okay, so what's next? Well, private disclosure didn't get us anywhere. Uh but maybe now that we're doing a public talk, we can finally get that call back. uh work with the vendor to get these issues fixed and uh and we can

eventually talk about them publicly with their real name and continue doing even more research into this unusual hardware platform. Uh so hopefully you all have learned a few new things in this uh talk about hardware hacking and formal reverse engineering. Uh next time you have a really cool security research idea, you've got extremely limited resources. Maybe you'll remember this talk because the manufacturer tried really really hard to prevent uh any kind of reverse engineering. I don't think it was specifically targeted at us, but it feels that way. Uh but you know, they refused to sell us main bike boards. Their boards were potted uh in the most annoying way possible, and they otherwise ignored all of our attempts to

contact them. Despite all this, we still found significant vulnerabilities. And just really quick, I want to say that for whatever reason, the asking for a VIN before getting equipment from them is like apparently general policy because when I was writing this, I tried to get a copy of their um of their like warranty to see how badly we'd violated the warranty by doing this hack. Uh they will not give you one if without a VIN number of a bike. >> All right. Well, I guess we'll uh pass it over to some uh Q&A. >> Mind repeating the question for the recording audio and I'll try and run the >> question. >> Yeah. So, the question was, did we

consider hunting for a VIN on eBay for or a sales record or anything like that? So, something that we sort of skimmed over that um if you read the bottom of the thing, we're going to do a unredacted blog post later. um it will be more in depth than that, but something we sort of skimmed over is that to actually get the firmware downloads, it wants you to give it um a hardware identification number and a VIN. Um what we found is that the VINs are validated on the server side based on probably a regx because the format for the VIN is public on that service wiki that I showed. And if you just randomly generate one, it completely

just passes through. Um, so we didn't try that with the manufacturer just based on they might get really mad at us, but it probably would work there as well. So the question is, uh, putting the bike into pairing mode, uh, does that require pressing a button on the bike? Yes, it does. It requires the bike being parked, having its kickstand down, and pressing the mode button for five seconds, I think. Um, like I said, 5 seconds to put it into pairing mode. And it doesn't have a uh allow list of bikes of phones that it's paired with before. So, even if it's paired with a phone before, you can still send it via a new

phone. Did we consider spear fishing will? Yes. But next question. >> So the question is, can we submit CVS if even if we can't disclose the name of the manufacturer? Um, also Mitchell, let me know if I'm taking too many of the questions. Um, so we're currently working with uh the Carnegie Melon Certis. I forget the exact acronym, but uh a coordinated disclosure organization that helps with responsible disclosure because we figured that they might be more willing to work with like a official disclosure organ with us personally. Um that's why we have a time stamp for early March because that's when that disclosure window runs out and they haven't responded yet. So probably can't get the CVE without

disclosing the name of the manufacturer, but we will try and do that once that time stamp for disclosure runs out. >> Oh, uh I'll I'll take this a simple question. I'll take that. Yeah, the question is what is a symbol? Uh so symbols in this case are referring to at least what we're talking about here is when the developer is uh you know writing a bunch of code. They're creating function names. They're creating classes. They're creating variables. Symbols are just the human readable uh what we'd call you know the the name of a variable, the name of a function, the name of a class. Depending on you know how that code got compiled or how

it's in its final form before it gets executed that might just completely get stripped away. In the example of the ARM firmware, uh it should have been or you know it was it was removed from the actual binary. There is no way to actually see within that what is the name of this variable, what is the name of this function and that makes it extremely difficult normally to reverse engineer because we have no idea what this function does. We just have to read the logic, see the math that it's doing and just kind of figure out and work our way through that. But because they included the samples now we can infer that oh this is called um Moto update

firmware uh you know things like that. that. So that's what a symbol is. Does that answer your question? >> Yeah. Thank you. >> Yeah. So the question is, have we uh considered reaching out to a national organization because this is safety relevant? Um yes, that's one of the things that the Carnegie Melon disclosure people will help us do theoretically.

>> Where are the manufacturers located? They are located near Santa Cruz, California. >> Yeah. So, so the the um company recently went through a restructuring as so many did and moved their primary offices to the Netherlands, I believe. I think their main manufacturing facility is still in California. Um and I think Will is still in California if I remember correctly. So, the question was uh physical protections you can do on the bike. Um, so the good news of this is that getting to the canvas is slightly annoying. Uh, it the location varies by bike model, but generally you have to like remove the seat or the side plating or something like that. So, it's this is

why we thought it was not necessarily feasible if you're just like walking onto a like shop floor, but if you've stolen a bike, if you're a manufacturer or a uh retailer or even just like a mechanic, you could definitely do this. Uh probably like an hour or so to get to the canvas. Um but yeah, there's best of class and also like industry standard. There are actually some uh software level protections that you can put on the canvas to prevent stuff like this that uh for example disallow replay attacks, disallow unauthenticated access. Uh none of those were in place here. And uh yeah, generally your best bet is just going to be like don't let

someone access the canvas without your knowledge um until they put any sort of protections in place. Uh the question is did we try to attack the actual firmware update server itself? Is that right? >> No, impersonate. So like >> Oh, impersonate the server. Yeah. Uh, so I mean I guess if we wanted to impersonate the server itself, we would need to do some stuff that's pretty far outside of the scope of what we we need to be able to I don't know do some DNS cache poisoning in order to get traffic to come from, you know, instead of going to the server to come to us. So yeah, that that stuff all felt like it was a

little bit uh too far outside of the scope of this pentest and what what our employer would probably be comfortable with us doing. >> I don't remember. Uh um oh wait, yes they do. They do. They say that um you can't hack the bike because the updates are all signed with the VIN number. >> I think was it around the uh they also had something around the this manufacturer. They like to lock you out of hardware functionality on your own bike and then charge you to get it back. So they like to do like subscriptions around let's say heated handlebar grips. Like it's hardware, it's there, but they'll charge you a subscription to use it. So I think a lot they've made a lot

of security claims around the safety of that which is kind of silly because I don't know that's very anti-consumer. the fact that you like the fact that they're actually using space on their website to say, "Oh, well, you can't break this because the actually the subscription information is on the server and not the bike itself." Like, okay, well, that doesn't really protect the rider. It just protects your profits on your stuff that you're locking people out of. So, the thing that I wanted to do, which is going to lead into a vulnerability that we might work on for later, um, is I wanted to turn our, uh, our C2 into a worm, um, that could propagate over

Bluetooth. But it turns out that one thing that this bike did fairly well is it distributed the control planes across different boards that are in different parts of the bike. And the boards only communicate over the OBT2 canvas. Um, so the Bluetooth controller is separate from the cellular modem and is housed in the same board as the display. Um, so we didn't have access to one of those. And if we were able to turn this into a self-propagating Bluetooth worm, we would need to have access to the Bluetooth control firmware uh to look at. So that is also why we didn't write any like hooks that do something flashy like change the change the splash screen when

it boots up or something like that. Um so exciting things that you can do for your self. I think the easiest one that I can think of is you could disable the speed regulator because like with um which is also a safety hazard obviously, but like like with electric scooters, uh the top speed is actually mostly enforced by code rather than by mechanical issues. Um so you could just disable that and drive as fast as you wanted. >> Yeah. So the question is for the so we talked about where they're just using static uh keys for the actual firmware update process but there are another set of APIs that do more complex validation. So one of those things is what Panie

mentioned at the end of the talk around uh doing like reax to uh match the VIN. That was where we first seen that was where uh making some requests against the API pretending to be a bike with this arbitrary VIN. We don't know if the VIN really is belongs to an actual motorcycle or not. Probably unlikely. So that some of the components are using the actual VIN. That of course can be spoofed very easily. But then there are some other components that actually do require an account. I think around like the GPS mapping stuff that is that does use an account. So that would be but the correct way of doing this probably would have been to make our lives harder would

have been to have uh some kind of signing mechanism that only the bike is able to you know there's some sort of uh key or some kind of value that passes through the phone into the bike and the bike signs it somehow sends it back up. And so the only way to actually retrieve the firmware is if you actually have an actual bike. That would have made our jobs a lot more difficult. So I think that probably would have been the right way to do it. Uh um not is there anything that is the question is is there anything that a user could do to patch their own bike to make it harder for someone like us to

mess it up? um not without fully re rewriting the firmware to the MBB um because that um the the phone app just serves the serves the uh firmware updates and then the MBB receives them. It checks that signing salt that we uh did. But theoretically, if you wanted to write several hundred lines of C yourself, you could write a custom firmware that uses a lot of the same functions, implements better siding, and then also has a a like open-source phone app to drop the firmware to it or just always update over the canvas. Um, that would suck and I'm not going to do that. So, >> yeah, maybe hardware wise you can somehow remove the Bluetooth module. I

don't know. >> You had that idea, right? >> I had that idea. Um, they're Yes, they're generally very expensive and like in the $200 to $400 range per like piece and we don't really need them. Um, besides the like display module, which would be useful. Um, also it's difficult to get them online without going through official retailers, they only show up on eBay occasionally. So, that's sort of why we haven't done that. >> Yeah. We also know that they do a lot of things to try to prevent you. Yeah. They try to do a lot of things to prevent you from doing maintenance on your own bike. and they will like the reason that you

need part of the reason you need to provide a VIN to the main bike board is so that it will communicate to the other components correctly. So I think we'd have a pretty hard time even just getting them to talk to each other. >> Yeah, this is why there's an unofficial wiki on how on like replacing the manual because they won't give you a manual for your own bike. >> So they don't do parts pairing. Um, did were you interested in the MBB specifically or the BMS? I might have hallucinated that you said BMS because I was thinking about it, but uh did you have a specific part you were interested? >> Okay. >> Um, I mean the

the things that I'm most concerned about is people writing ransomware for your bike. Uh, because you could fairly easily just brick the bike. Um, You could also I've been like mentally referring to it as a stuckset for your bike because um by controlling the battery control boards you can uh turn off the like safety limiters for charging speeds or open up the capacitors at full when they're not charged which would essentially short the circuit. Um, and this would sort of invisibly degrade your bike's uh power systems uh and potentially lead to like a battery fire while you're charging your bike. >> So, that's what I was wanting to do with the worm idea. Um, and it'll it would

definitely be much easier to make a botnet if you had a like functioning self-replicating worm. Um because then anytime you had like a bike go for a test ride on the manufacturer floor or something like that, you could just spread to multiple other nearby bikes. Um as it is, uh the C2 that we pseudo coded uh can control multiple bikes, but you'd have to individually install it on each one. Yes we're it's a little bit unclear if you can send Bluetooth commands to that um board from the firmware on the MBB uh because it looks like most of the logic that we could find is just about downloading data over Bluetooth rather than sending commands out through the Bluetooth. But

if we if it is possible to do that, then that would be the place to start. Um it's definitely I think that even if you couldn't get um something going propagating from the MBB to the Bluetooth module, uh what you could probably do is get like one bike to be an attack vector um that propagates to its nearby bikes from the Bluetooth module. And also definitely you could like change the splash screen, do things with the display panel. >> That looks like it's everyone and we're about out of time. So, thank you. Thanks everyone.