 Hi, I'm Specters. My talk is just on infotainment system hacking. I was going to initially hack 10 infotainment systems and then show you guys all of them, but then, you know, responsible disclosure and I did it in a bad time frame. So now I'm just going to teach you guys how to hack it. So my sponsors for this event are Ghost Express. It's actually a meme. They sell ghosts in a box and you can ship it to your friends. Yeah. Once again, I'm Specters. I'm a security enthusiast. I really want to hack a Tesla. So bitcork, please let me hack your Teslas and you know, shout out to Thug Crowd because they really like helped out with like the putting together like these slides. So just a quick overview. I have 30 minutes to give you guys a talk on all of this. So I may like have to cut it short. I may have to skip stuff, but pretty much we're just going to go over Q and X hacking and we're going to go over Android hacking and then we're going to do some like some basic hardware techniques and then like kind of one advanced one that I learned online from some Russians. So first off, Q and X is made by Blackberry. Just kind of an interesting fact. When we go through the Q and X high overview, we could see like your actual update package manager. This is just like how it works somewhat. So BSP is a board support package and essentially all it does is just updates your Q and X system. Car companies will take this and like integrate their own software into this to do like over their updates or like physical updates via USB. But when you're going in there and you're updating it, essentially it's going to go BSP and then the Q and X operating system. And if you have like something that's supposed to work with your phone, it'll go through the device gateway and then it'll go and update like any of the following like above it. And then like the middleware is just pretty much made to essentially like mitigate like where these packages and things go. So part of the Q and X update Q and X update process is you need like a physical device. You're pretty much going to take this package. You're going to plug it in. The system is actually going to enumerate the device and look for the specific package. If they're cert signing or if they're doing anything else, SWUD is pretty much going to read that cert and then as either they're going to update or reject it. After that, it'll pretty much set it on to the Q and X file system and it will start a reboot process. But when you start the reboot process, essentially all your active like major car parks will still be working in the background. And they'll just always be active. So one of the big attack vectors is like dossing vehicles. So if you're able to like DOS a Q and X system on a car, if you're able to DOS like one of the other systems on a car, companies usually don't like that stuff because you can cause people to die. So these are just some of the binaries that are on the system. So USB launcher is just made to like detect when you plug in your USB. MCD is a, it just mounts your file system. MM detect is multimedia detection. So it'll detect which files are on that system. And QDB is the Q and X database server that it reaches out to. So some of the ways to start off enumeration for Q and X. Let's say your radio system has like the whole nine yards, you like buy the most expensive car and you get, you know, GSM, Wi-Fi, Bluetooth, custom applications that the car manufacturer has made. You also get USB for like loading your songs and other files, like maybe movies or something onto it. Some of the things that you're able to do once you get onto their system is like, you know, connect to the Wi-Fi, do a port scan. It's not as common as much anymore. They've been starting to like push them out, but there are still some things out there that exist where like, you'll have Telnet open. Oh, Telnet drops me into a root shell. That's kind of dumb. And then like for hotspot GSM stuff, like if you like scan external IPs or like you man the middle of socket connection, sometimes you're able to just like get unencrypted data that like goes to a backend server. And now you're like able to find that backend server and poke at that, which is also very cool. For Bluetooth, BTLE Jack, Form of DOS, which cause operator distraction. And then custom applications. There's a ton of people that are storing like passwords and stuff in custom applications, endpoints. Once again, just more things to poke at things to get onto things to like kind of distract from. So one of my big tests after this was just in general is to like kind of enumerate which files work on a system. So this is a quick script. You can add more file headers to it pretty much. And all you're doing pretty much is just testing which file headers work on a system, which files read, which files don't, like which ones show up and which ones don't. So this will pretty much just like go to like a single like data file or just any text file and it'll just like change like the first couple of bytes. And then you go onto your system and it'll just error out, which is kind of interesting as well. So Android hacking, I've done a lot of bug bounties with this. So I'm trying to like steer away from all my like personal research and like my own research and stuff. So we're going to try our best here. So pretty much Android is really different from QNX and other like Linux systems in the like in the sense that like, first off, it replaced Glypsy with Bionic and it really utilizes SE Linux to separate user privileges and application privileges and things like that. And even like when you get onto a system, like some things are virtualized with can't remember that hardware or software. But pretty much like there's just a couple of other things where like they have custom versions of init, you have like your own custom versions of like the startup daemons. And although you have Android that like uses heavy like SE Linux, like like customized file, essentially to like show you the roles that you're able to do. All your like native binaries for Linux are still on that system. So you're still able to take advantage of some of those things. Most of the time Sue is not on that system though. So escalating privileges is not as easy. So we're going to talk about SE Linux a little bit. Pretty much SE Linux is just like an enforcing of like the Mac policy. So pretty much you have users, you have groups, and you're just like strictly assigning those user and groups together. Together, once you drop like a shell onto their system, you can see if SE Linux is enabled with those three commands at the bottom left, which is get enforce, see SE status. And if that doesn't work, you can try to get to the SE Linux config file. But once again, like dropping into the shell and getting access to that is not as easy. So don't worry, I'll show you how to do that in a second. So we're going to start off by downloading ADB first off. And usually when you download ADB, you're going to have to go to your device and put it into developer mode, right? So if you have initial access and you're researching the device, you can go into your car, open up the settings, put the car into developer mode, download ADB onto your Mac, Windows, Linux laptop. And then you connect either USB through the Wi-Fi or through your own hotspot. And then like the car has to connect through that. And then after that, you go to like ADB start server. And that'll pretty much start your Android bridge to the device, list your devices, make sure it's authenticating properly, make sure it's authorized. You can drop an ADB shell. And then you can also do those other commands I showed you earlier to see if SE Linux is enabled. And you kind of want to like pray for permissive. I spelled that wrong. And then you also want to see who you are. But usually the response that I get is shell. And you know, we can just drop any ADB shell, any Linux command that's on the system, and we can like out that to a file. So we're actually able to go on enumerate the system pretty quickly with that. So some of the eight Android like users, these are known as Android IDs. So some Android users pretty straightforward. You have root, you have system, you have app, you have user, and then you also have shell from when you drop the Android shell. Something interesting about ADB is it actually starts off as root. So when you're first getting onto the system, and you know, you ADB into, you know, your radio system or whatever it may be, you're actually going to like initially start off as ADB root starts process, and then it lowers its privileges, and then it just makes you a shell user. So if you find a way to interrupt that, then you can pretty much get onto the system and, you know, start a root shell. Or if you find a way to like configure the files in the process, because SE Linux isn't like, mandating properly, it's going to allow you to just write onto like file like specific file systems, and you know, once again, you get root shell. Some of the Android groups on the system, just for network configuration. And you'll also see like something that looks like users, but are actually just reading right access to SD cards and other like hardware devices on that system. So abusing ADB. So some of the things I usually try is I go to like data local prop, and I try to see if RO secure is set to one. Because if it is, then I'm pretty much like kind of screwed. So if I can modify that, then I can actually go in and drop an ADB shell that is at as root. So if I set RO secure to zero, I can get on there as root. Or if I go to RO kernel, Kimu, and set it to one, then I could also drop a shell as root. And this is kind of interesting, because there's just like a ton of attack vectors that you could use to try to get to this point, such as like, you drop a application under the system that you know, gives you a shell. And then that shell is able to modify a couple of other files and like rewrite files, right? So by doing this, you're able to like traverse file systems. But at this point, if you're able to modify those files, then you know, you're probably able to just drop a root shell in the first place. But this will give you like persistent ADB root privileges if you wanted to go and change those. So a couple of ways to get root again is you can go online and find an unlock bootloader, which is way more prominent than usual. You can configure your device to be in fast boot mode. And then once you go into fast boot mode and you update the bootloader, you can compile a binary like supersu onto their system. And then you can either privask or do anything else. Or once again, you can modify local.prop to allow root once ADB is active. So we're going to go into a little bit of hardware hacking because hardware hacking also has some like very interesting stuff that usually drops you into root shells. So you are at a very big hardware hacking one. This is actually a picture I took of one of the things I had to do and it's like awful. But bear with me. So when do you try hardware hacking? I wish I could say it was at the end of everything else I've done in these slides. But usually I go right for it right at the start and I always break something and it like ends up never working at the end. So that's why you buy multiple systems. And like a little bit about UART is like UART was probably my first introduction to hardware hacking in general. Identifying TX and RX and ground pads are pretty straightforward. More examples will be on the way. And pretty much when you like set up UART, you're all you're going to do is like solder a couple pins onto a board and connect a UART to USB cable and pretty much find like a specific baud rate, which is like a clock speed for this and then drop into some type of system shell or you're going to have to like interrupt the boot process to like drop into some system shell. So for example, this was one of the UARTs I found in a specific infotainment system owned by JVC. And pretty much you have TX, RX and then you have ground up on the top. This was before I touched it. This is what it looked like after I touched it, because I suck at soldering. So I tried to solder just TX and RX and I thought I'd be good soldering ground to somewhere else because the pads were just way too close to a lot of things on the board. And then when I went to go finally solder the ground pin, I actually broke off the pad and the pin that I soldered onto RX before. So I had to pretty much scratch out this line right here. And then I had to solder pins directly to that copper spot just to try to get like the flow of traffic again, which actually worked surprisingly. And I got the advice from someone on Twitter, which is fairly interesting. And I mean, usually once I drop into a shell, this always drops me into a rich shell. This is why I like go for this attack factor first because I could waste like 20, 25 minutes like enumerating a bunch of stuff like via ADV or like via like some QNX system or like enumerating like wireless connections that it's making or trying to intercept socket traffic to a web server. But a hardware attack is just so much faster sometimes. So why waste the time? And the reason you want to waste the time like looking forward is just because of documentation. You can go through and like document literally everything from beginning to end once you do this. But if you want to drop into a root shell immediately, you just get more system access and you get to see what everything is doing when you're trying to enumerate everything else, which is really nice. So another big method that I actually learned on a Russian forum was reflashing chips. So that chip that's actually right in front of the pins that I soldered on or the wires I soldered on pretty much, you can actually remove that and you can buy a device on Amazon for like $40. And pretty much all you do is you have to like take that cable connected to it, take this clip, put it on top of the chip, or you can desolder the chip and put it into this nice little setup here. And you're pretty much able to just dump all the flash from it. So on that flash, you pretty much get like the whole file system and you're pretty much able to modify parts of it. You can dump it, you can bin walk it, you can extract stuff, like YAS file system, things like that. And after that, you can just re upload it because this also writes to that flash. So you're able to just rewrite the file system if you wanted to. But to do that, you want to kind of do it in like the least evasive way as possible. So don't rewrite the whole file system and screw a ton of stuff up. But yeah, that's pretty much it. So I kind of had like a couple more minutes for questions or anything if anyone wanted to ask them. This is my first talk. So I'm like very nervous. So if I went too fast, please let me know. Right. That's a good question. So getting like the SE Linux policy is probably going to be your best but other than that finding global read and write files that are like running under certain users. So like looking at like processes, finding out which users are running which processes and then seeing if those files are just global read and write is also a big attack vector that a lot of people use. So like I've seen try not to break NDA once again, I've seen some systems from some very big manufacturers run a shell script that pretty much is able is like global read and write. And when you like put an APK that has a reverse shell that drops you to a system app shell, you're able to write to that shell script file and then just like pivot into a root shell after that, which is weird. I don't know why people set it up that way, but it's mostly just going after like small misconfigurations like that with an SE Linux because SE Linux is so strong if you can implement the policy properly. But yeah, mostly just going for like global read and write files is going to be like the best way to like pivot to a root shell on a system after you upload a malicious APK. Yeah, or you can like, like try to find ways to like unlock the bootloader and like pretty much upload like super sue APK and then try to sue. That's also a good one. So yeah, any other questions? All right, thank you.