 Hello. Hi everyone. Hi. Thanks for showing up. This talk is called, what did I call it? Reverse engineering 4G hotspots for fun bugs and net financial loss. I'm a senior work avoider at Pentes Partners. I'm also do hardware or embedded work sometimes. No one cares who the speaker is. Let's go on. So the structure of the talk today looks like this. I'm talking about why I'm talking about cellular routers and I'm going to talk about the sort of attack surface you might see on them. Then I've got two devices to look at. One made by a Chinese company, one made by a US company to sort of avoid getting everyone all over excited about it. Then I'm going to go over what was fun about each one of them and the sort of bugs that I found in them as well. Then I'm probably just going to complain until my time's up. 5G is apparently imminent. I've heard it's meant to be operational in some areas. I'm not entirely convinced by that yet. It's meant to be very quick. Consumers and business users are probably going to start using it more for their daily TCP IP activities. So there'll be more modems, dongles and routers out there in the world. There's not been that much public scrutiny on non-phone consumer cellular gear so far, which is sort of weird because there's not that many vendors or OEMs actually doing cellular kit from scratch. Because there's only a few OEMs, there's lots of code reuse. So the label on the box doesn't necessarily mean that the contents of the box are actually made by that vendor. And also code on these sort of consumer devices ends up on very similar industrial devices as well. Cellular routers are sort of interesting. They're somewhere between phones and traditional routers. And because they're just embedded computers, there's probably going to be lots of bugs in them as well. I would say at this point the bar is still pretty low for finding bugs in these sorts of things. Not as low as it used to be, but it's still pretty easy. I'm going to do a really quick cellular network refresher just to get everyone on the same page. Some people think cellular networks are safer than public Wi-Fi. It's not necessarily true. Device is connected to an APN, which is like connecting to any LAN that you don't control. Some APNs are really well configured, some aren't. It totally depends on the APN itself. Because you're essentially on a LAN, you're not going to see a lot of cellular connected devices on showdown and things like that. But if you connect to the same APN, you can start to poke around and have a look and see who else is on there. There's a few security measures you might find on public or private APNs like client segregation, web filtering, IMEI, ICCID, filtering. It's sort of like any network. There's certain security mechanisms they can put in place. We have to take that into account when we're thinking about attacking a cellular device because we don't really know where it's going to be used and the APN configuration might be really weak. So when I'm looking at something like this, I have a rough idea of what I'm trying to find. I'm always looking for higher risk issues, actual security bugs. Since we're going in with a pessimistic view of the APN, you have to assume to some extent that you can touch the WAN interface on the device if there's no client segregation on the APN or something like that. So we can't rule out the traditional RCEs as a vector. You can also think about things like if you're much more worried about state-level stuff or very, very serious actors you might want to worry about compromise like GGSNs or NGCNs or whatever they use in 5G, these sort of things that handle IP traffic on these APNs. We also can't rule out cross-site request forgery on the router web configuration interface because if you're connected to a router, you're probably looking at stuff in a browser while you're looking at it. Sometimes there's all other kinds of TCP, UDP services running traditionally DNS, UPNP, other obscure proprietary stuff that the vendor makes. Not all of it's going to get blocked off on the WAN side as well. They try these days, but it's not always the case. There's also the possibility of more traditional cellular services like SMS or MMS being exploitable as well. There's also lower-risk stuff, so the sort of thing that might get you just a shell if you're connected to something with a piece of copper. It might give you some sort of firmware access or something like that. These sorts of things are not necessarily reportable to a vendor, but they're really nice if we're looking for bugs on them. Or if we want to just mess around with some of the lower-level configurations on the modem itself, like trying to change the IMEI to bypass APN security measures, which I think is illegal basically everywhere, so don't do that. You also might want to get a privileged A T shell to lock your device to a particular band or something along those lines. There's sort of a limit to that, in my opinion, if you can permanently backdoor a device in like 10 seconds with access to a USB port, that's probably reportable to the vendor, and you might want to try and get them to fix that. Whether they do or not is who knows. They might not care at all. I also prefer if a shell doesn't survive a reboot, but a lot of these things don't check for the firmware integrity. So when I'm looking at devices like this, I have a sort of really general methodology, which is basically asking what's been done already? What public info is out there already for the same or similar devices? Can I get firmware? What does it look like if I can't get that firmware? Can I get firmware for a really similar device? Can I get a shell and start playing with that? None of that is necessarily in that order, but it's just a rough guidelines for what I'm trying to do when I start reverse engineering these things. So let's have a look at some devices. The first one's the ZT-MF910. I also had a look at the MF65+, and the MF920, which both had really, really similar code running on them as well. I'm going for a deep dive on this one because it's end of life, easy to get, really cheap. So if you're interested in looking at these, it's a really good starter. It runs a Qualcomm MDM SOC, which are really common, the MDM series in modems. ZTE are also a massive OEM slash vendor, so you tend to find there hardware and software running in lots of devices that aren't badged ZTE. There's also a few caveats. There might be, oh days ahead, definitely in the MF910 because it's end of life, so they're not going to fix anything in that. But ZTE also pretty slack following up on the reports that we sent them. So there might be issues in really similar ZTE devices because they share a lot of the same code. We originally thought it was supported because it's advertised on their website, still being sold and nothing on their website says it's not supported. Then we told them what bugs we found and then they told us it wasn't supported. We asked them how we're supposed to know that and they just said, we'll only tell you if you ask, basically. So we asked them to check their other products themselves, they didn't do that, then we found essentially exactly the same issues in a different supported device, disclosed again, then they fixed them, they gave a couple of CVEs, linked us to an advisory which they don't link to on their website. I think they're doing that thing where they're checking issues per device rather than looking at the entire code base itself or the code base genealogy or whatever. So I'm just going to do this whole talk, approach the device in the same way that ZTE did. I'm just going to treat the MF910 like everything that I talk about only affects this device and doesn't affect anything else and whatever. Let's go. So let's have a look at the hardware. It's got this Qualcomm MDM9-225 sock. Some of the newer ones are maybe 9-6-2-5s but there's much of a muchness. They run this ARM Linux core plus a baseband, the baseband's this Qualcomm hexagon microarchitecture. Other people have done a lot more intense work on that. I actually wanted to start looking at that when I started looking at these but I got totally sidetracked by looking at the really easy bugs instead. It also has this like combination RAM NAND chip which you find attached to a lot of these Qualcomm devices. It's got this really nice test pad array. If you're looking at a modem and you see some test pads that are sort of square like this, there's a really high possibility that it was made by ZTE. I've seen it on quite a few devices that have either been made by them or that aren't badged by them. And you can do things like on some of the more locked down ones you can pull these test pins low and it will boot into different modes. Sort of like GPIOs or like the volume button on a phone. There's already a bit of public information about this particular device as well. There's two ways to enable ADB over USB. So you can just get an unauthenticated root shell immediately. It's only over USB so it's not that bad. You enable it through just API calls in the web interface. So you just send a request to this USB mode switch endpoint and the USB will just go down and come up again and you just write ADB shell in your root. It's really well known. I couldn't really figure out who found it already but it's a really well known thing that's out there. It works on loads of other ZTE stuff as well, apparently not just the MF910. There's another public way to do this as well which is mode switch. Just does exactly the same thing. You just send the word factory to the switch command parameter and it'll just start ADB over USB again. So we can get a shell really easily on this. Start pulling firmware off, see how the thing works when it's running, see what binaries are running, see how they're all talking to each other as well. So the MF910 is quite bloated which also means there's quite a lot of interesting stuff about it. The underlying system is probably going to be familiar to people who are used to working with embedded devices. It's just old Linux kernel running on ARM, Android-esque, not really full-fat Android. The default root password you can find in just one of the RCS start-up scripts in a function called set passwords. It just echoes the password to a temporary file, pushes it into a changed password and then tries to delete the temporary file to cover its tracks. This kind of stuff is really common on embedded devices. It's not really revolutionary but it's quite funny when you see it. It's not hugely useful out of the box because we've already got a root shell but there's drop-bare running but you can't get in because there's default IP tables rules. Some of them have telnet running, others don't. It really depends on who badged the firmware I think. There's loads of Qualcomm stock binaries. These QC map ones are Qualcomm mobile access point binaries and there's a few DIAG binaries as well for anyone who's interested in that. There's also GDB server, just stock on it. The IP tables rules just default accept. They block TCP and UDP on everything. It's TCP and UDP 22 on everything and then block TCP 80, UDP and TCP 53 and 1900 on the one interface. That doesn't actually block everything that's actually running on it. There's still a few services exposed like Syslog D, there's that DNS mask, DHCP port and there's a custom binary called ZTE whisper which is some sort of proprietary whisper protocol service on UDP 4500. I had a really quick look at that. It's definitely using lots of unsafe C functions but I'm not going to talk about that one today. I'm going to talk about this ZTE top SW go ahead binary which is really fun to reverse. If you're not familiar with embedded web servers, the whole web server stack tends to be just custom binaries so they'll be based on some open source web server and then they'll just attach stuff to it. This one's probably based off a web server called go ahead which is just a common commercial web server. It's not directly accessible from the WAN side so you can't do any of this stuff directly over the APN but you could still attack it by cross out request forgery if someone went to a malicious page. So we're going to have a look at it with that in mind. The web APR logic is pretty standard for a router because there's a large configuration table that holds all the configuration data for this router stored in non-volatile memory somewhere. All the configuration is written to or read from that by this binary so the web server is just a broker for reading and writing that information. There's a couple of API endpoints. Goform get command process and goform set command process. Goform get is just for reading data and goform set is just for writing data to the NV RAM. Goform get takes a CMD parameter and then an optional multidata parameter. Goform set takes this goform ID parameter and then custom parameters based on what that goform ID is. So without information you can load the binary up in either or Gidger or whatever. I did it in either originally but I think Gidger is a bit easier to see in really, really quick time. There's a lot more endpoint handlers in this binary than you actually see when you're using the device normally. Not all of them are that interesting but it just means there's a lot more attack surface on it, a lot more stuff to play with. In goform set command process each goform ID points to a different function in a big look up table in the binary. So most of these functions are just wrappers around a pretty safe ZTE library function that just reads and writes data to the NV RAM and some of them are explicitly whitelisted as well so they can be used before authentication. Not all of the functions do this NV RAM reading and writing. They also tend to run other sort of sys commands. There's one more ADB mode that I found that you can enable preauthentication. So goform ID takes this set device mode parameter and just takes a debug enable, sorry, goform ID takes a set device mode as its value and takes a debug enable parameter. Checks if it's 0, 1 or 2 and then just echoes it straight to that Android USB debug enable file in sys which just brings up ADB again over USB. It's no command injection because they're actually checking the input so it's not really nasty risk but it's a nice new way to get ADB access over USB on a device you don't have the password for. As far as I know this hasn't been public before but it's quite a nice one. So there's three different ways to do the exact same thing in one web server binary. Something else that's really nice is there's lots of verbose logging so it's got this ZTE syslog append library function so you know exactly where you are in every function in the code. There's also a way to leverage this from the web server so one of those undocumented endpoints lets you set up remote syslogging. So you send a request to this endpoint and syslog data gets sent back to you on UDP 514 of the requesting IP address. It's only available post authentication but it's persistent across reboots. The function itself does a system call but there's no command injection in this particular one. I think there was command injection in it in the MF920 or the 65 plus I can't remember but they're very very similar functions just with slightly different bits of checking added. So if you open up UDP 514 you get all of this ZTE syslog data sent back to you which is useful if you're looking at a particular ZTE binary and trying to hit particular parts of the code in it. You can dump logs to a file as well download them, enable kernel logging as well. There's also a bug that I can't actually properly test and again because anything that doesn't directly affect the MF910 ZTE aren't going to do anything about so I didn't report this to them. There's all these pre-authentication HTTP share functions. They don't work by default on the MF910 because there's no SD card slot but with a bit of basic reverse engineering you can see there might be a few problems in some of the code. So in this particular one you get a 1024 length buffer, you just sprint a touch command with the user supplied variable in double quotes and just pass it straight to system. There might be a couple of problems in there. I'll leave that as an exercise for the reader but I can't really confirm this because I don't have a ZTE modem with an SD card slot but theoretically if I did the exploit would look something like this. That sort of qualifies as fun because it's not technically exploitable on the MF910 but we'll never know, we'll never know. So there's actual technically exploitable bugs. This first one is a leaky API endpoint, the GoForm get command process endpoint. There's two checks, one for authentication and one for cross-site request forgery but there's no proper authentication check if the multi-data parameter is set to zero for some reason. So we can just read arbitrary values from the configuration table as long as you can pass the C-surf check. So that includes the unencrypted admin password value. So if you set the refer to the root-ride P or 127.1 you can read things just like the admin password backwards without a C-surf bypass you have to be on the same LAN. There's also obviously command injection with code like this. There's that USB mode switch function from earlier. The USB mode parameter is injectable so it just passes whatever it gets straight to system. Those two bugs are not quite a proper exploit because we can't really, and they're not really a remote exploit because we can't really access the web server over the LAN. So to turn it into another kind of exploit we have to take some of the mitigations into account. There's this cross-site request forgery protection so it just checks the refer aheader. You can't control the refer aheader in a browser so any request that we send to another page you're going to fail even if we try to log in we're just going to fail if we're coming from another page context. I think you might be able to guess how to bypass this protection. Cross-site scripting means we can just run JavaScript in the root of page context so the refer aheader is going to be the root-ride P address. There's a really nice clean XSS in this totally inexplicable page, go form slash form test, which by default just prints name Joe Smith address 1212 Milky Way Avenue. So you send it something like this you just bypass the cross-site request forgery protection and you just run any JavaScript you want in the root of page context. So we can have an exploit that just goes like this. XSS gives us a clean refer aheader and we don't have to worry about the same origin policy so we can read the responses back as well and we can just leak the admin password, log in, exploit the command injection. The C-serve to XSS is just a form posted into an iframe because if you try to use XHR it will send this options pre-flight request and the web server just can't handle an options request so it will just fail. And the injected JavaScript just sets up a couple of functions, reads the admin password, logs in, executes arbitrary code. So let's have a look at it. So on the right there is the Windows machine just connected to the router and on the left is a sort of attacker machine that's going to open up a shell. Okay, case study number two, a high end route at this time, the Netgear Nighthawk M1. I wanted to see what an expensive 4G router looked like because the MF910 is pretty old and pretty cheap. The M1 is new, new-ish. It's been out maybe a couple of years. There's barely any public information out there about it. It's using a new Qualcomm sock so there's almost no public information about that. So it's a sort of challenge. There's also a really cool Russian subculture of just pushing them way too hard by putting heat sinks and massive antennas on them. It's also part of the Netgear bug bounty which they run on their high end routers. I absolutely hate the Netgear bug bounty so much. Before you disclose to them you've got to agree that you can't publish your findings or speak about it to anyone other than Netgear. If you do they'll be so-called entitled to some kind of performance instead of giving money back. The payout calculation is also really, really complicated. They seem to calculate the payout amount based on CVSS which is arguably not the best way to calculate risk in a piece of hardware. I had looked back through some of their recent disclosures. One of them gave a post-authentication command injection, this CVSS v3 score of 6.8 which is conveniently a medium risk. So a $300 payout rather than a high risk $600 payout. So they're also cheap skates. So I did manage to find command injection in this thing so I very briefly considered my options. Should I go through bug crowd, never talk about it in public and maybe get $300 from Netgear or speak at DEFCON, complain about Netgear in public and get $300 anyway. So yeah, I'm here. The hardware is really, really similar to the MF910. It's got a Qualcomm MDM 9250 which is pretty new. You can't really find much information about it. It's got this Nanya combination and RAM chip as well. These are really generic looking test pads. I'm sorry for all those scrapes and scratches all over them because I tapped onto them and tried to clean them up. So the main core components are pretty similar to the MF910 but a little bit more up to date. There's basically no useful information out here at all for this one. There's a really long thread on 4PDA which is this Russian phone modem enthusiast website. They all want to lock it to particular bands for some reason. No one seems to be able to do much with it. The thread was really helpful because they archived some older firmware update packages and documented some arbitrary firmware update process that I'll talk about in a minute. So thanks to them for that. There's a GPL tab all on the Netgear site that seems to be about 14 versions out of date. So there's not much else out there. This firmware on the Netgear site, but every file looks encrypted. So it's not trivial to get binaries off it and look for bugs. There really wasn't anything that obvious. There's no ADB, no telnet, no known backdoor. It's nowhere near as easy as the MF910 to get into. There's a web server on port 80 and then an AT shell on port 5510 but only if you're plugged in over USB. I could figure out it's based on Sierra Wireless technology. Sierra Wireless is just a big Canadian vendor who make really expensive industrial cellular stuff as well like modem modules. So knowing that gives us a little bit of a wider scope to look for more information outside of just the Netgear specific searches. So since the M1 was a bit more difficult to get into initially, the fun stuff was sort of figuring things out black box entirely. These test pads, I started off thinking they'd be GPIOs like the ZT stuff or on phones. I spent time pulling them up and down on boot and seeing what the USB vid-pid combos were coming up on D-message, but I put it into Qualcomm emergency boot mode a few times just because I think I went too hard on it. A little tip, I think if you treat these things badly enough, they just give up and go into emergency boot mode. It's not that helpful because we don't have any signed public load of stubs for the 9250. It turns out they're JTAG, so thanks JTAG and NUM. I really wasn't expecting them to be JTAG. It's quite rare to see something like this. That's the pin out there for anyone who's interested. You just connect as a generic cortex. I think it's A7 or something like that. But in the end I didn't really spend that much time on it. JTAG on a really complex sock with basically no data sheet is not really like a quick win to get into something. I think the memory protection unit was also stopping a lot of stuff. I figured out a few things like the boot loader starts at zero and ARM thumb gives you some insight into potentially interesting memory locations or register locations. But you can't really read those locations from JTAG because the NPU is blocking most memory reads. But it's there for anyone who's interested in JTAG on Qualcomm stuff. That AT shell as well is limited. You can see extremely small amounts of modem crash data and things like that. There wasn't this usual privileged command mode that you sometimes see on AT shells. I think the password is nulled by default, so you can't get into it even with the right password. There's nothing like this like AT bang enable or anything that you see on some other devices that would just pop open ADB for you. The only thing that came close to being useful was this AT bang boot hold. That just put it into this Qualcomm flashing boot mode. From this mode you can use this tool called FDT.exe, which is a Sierra Wireless proprietary binary. It's not that easy to track down. You can find it packed with other Sierra Wireless firmware update packages. You just sort of open them up in seven zip and the files in there. If you're used to the normal Qualcomm download mode, this one's sort of proprietary. It doesn't open up a comport. It just seems to do it all over USB. Maybe it's just some sort of Sierra Wireless specific implementation. This was a really nice tip from that full PDA.ru thread. It's still not that helpful unless we can manipulate firmware update files because they're encrypted. I used some encryption loosely. Netgear chose everyone's favorite encryption. Actually, depending on your definition of fun, this might not sound like that much fun, it's not just XOR. It's XOR and AES. The firmware follows this really generic Sierra wireless structure. The firmware is split into chunks and each chunk has a header and a body. Netgear added this encryption layer where all the chunk headers are AES encrypted and the actual data, the chunk body, is just XOR encrypted with a 1024 byte key. The AES sections also just encrypted in ECB mode as well. They're just repeating 16 byte blocks. They're really easy to spot. The general theory of it, you can derive the XOR key for these chunk data segments just by assuming that most firmware bytes are just going to be nulls. Then you can just XOR out all the data segments, get all the data, get the AES key out and just decrypt everything. I'll go over the steps so you can just sort of see really quickly. This is the nulls encrypted with AES and ECB modes. Each block is just encrypted on its own 16 bytes. It looks like XOR with a 16 byte key, but it's definitely not. When you line up the encrypted file with a generic non-encrypted Sierra wireless firmware update file, you can see the repeating blocks of nulls line up really nicely with these so-called ECB encrypted null blocks at the same offsets. The headers reshunker all the same size. You can figure out where the headers are just by looking for this known encrypted null chunk block. You can figure out where the headers end and begin just by searching for that 16 bytes. It's pretty easy to figure out the file structure and just decrypt everything. I wrote up a script to do it. You can read about it here. It's a bit too fiddly to get in too deeply right now, anyway. The script itself will just iterate over the file and just decrypt everything. Some of the chunks are nested in other chunks. The key shifts very slightly if the chunk data modulo 32 isn't zero, so it's all a bit convoluted and weird. Anyway, the firmware is pretty interesting once you've decrypted it. It's got literally everything that's running on the device in there, including the boot loader, the DSP, the Linux system, the web root, the Android splash screen, and some generic APN configuration data as well. I didn't take this to its logical conclusion. It might be possible to fiddle around with this firmware, re-upload it back and run arbitrary code that way to get in. I didn't get around to doing that in too much depth for reasons you'll see in a minute. There's other Sierra firmware file passing tools out there, so you can figure out where the checksums are in the headers and all whether size fields are in the headers and stuff like that. Anyway, Neger don't think this is a problem, so they're not going to fix it, so have fun. Okay, I found some bugs before I decrypted the firmware. These were just black box finding the bugs. If you decrypt the firmware and you might find more things. As is customary, there's command injection. I sound bored, don't I? I'm so bored of command injection. It works like this. A bunch of the endpoints after the forms handler, a handling request, there's forms.config, forms.multi-config. You send a post request with a parameter like webd.adminpassword equals password one, and it'll just change the admin password if you're logged in. The session security is quite good on the web application, so it's not that easy to bypass. I thought maybe someone else will find differently. Request look a bit like this with the sort of important parameters highlighted. I did a bit of basic fuzzing with stuff that I found when I was actually just going over the web interface totally black box, but I didn't really find that much. But there is an interesting web page at introspection.html, which is a Sierra Wireless specific page, which gives you a really long list of parameters when you're logged in, and it'll give you their expected value type as well, like Boolean or Integer or String, and sometimes the values that they're set in there as well, along with the permissions, the user permissions that you need to modify or read them. It's pretty helpful because it's just giving us a word list of valid parameters that we can try to fuzz, which we can use to find this command injection in ready.devicegear.removeUSB device. So if you send something like that, you'll just get telnet D opening up. Just log in with the default credentials. They're root OELinux123, and you get a nice clean root shell on it. This is my absolute favourite cross-site request forgery bypass of all time. So unlike the ZTE, there's no dynamic API to request data from. You read all the configuration and session data from these dynamically generated JSON files. That includes also the CSERF token. They're not JSONP, so you can't just siphon them off because the SOP will stop you. But there is another file called netgearstrings.js, which is also dynamically generated. And just after the to-do comment at the top is a big variable called netgearload data, which holds the user privilege level of the current session and the CSERF token. So you can just load this JavaScript file from any site, read the netgearload data.session.sec token, and you've just got the CSERF token. So it's the dumbest CSERF bypass I've ever found. So theoretically you can chain these in a really similar way to the MF910. I didn't find an authentication bypass, so it's not... I don't have such a clean exploit. You'd have to try and guess a weak password. After just so much hassle with it, I was just quite happy to get a shell on it, to be honest. If you just want a shell to get... So you can start trying to change stuff on the low-level configuration, you can flash any compatible firmware with that fdt.exe file, just grab a vulnerable version and get a shell by command injection. Netgear have been pretty bad to disclose to. Maybe because I avoided bug crowd, they were having a little tantrum. I reported the issues in late February. As of this morning, they haven't fixed anything, so all of that stuff was just O days back there. They're not going to fix some stuff, other stuff they're looking into. They might change the root password. Literally, who cares? Okay. It's the end. These sorts of devices are really fun. They're really easy ways to get into hacking, embedded stuff. You should go into it with a mindset that vendors are going to be really rubbish. The bounties are going to be rubbish, but you can start to at least learn how these things work on quite a low level, which is quite interesting. I've got a massive to-do list of things, because I started the whole project because I wanted to find bugs in the Qualcomm baseband, but I got obviously way too distracted by all of this stuff. I want to do things like download all the extremely dodgy looking unofficial Qualcomm tools that people have released out there, figure out how they work and what they do. There's so much stuff out there, so much work that's been put into reverse engineering and changing these things. There's just a goldmine of existing research. Vendors should be asking things like, where's my code from? What else is running? What's the root cause? How do I fix it? They don't really seem to do that. They just respond reactively to bugs that you send them and don't think about it anymore. I tried to coerced to check for similar issues and they just didn't do it. I think one of the excuses was I sent them a proof of concept that used Netcat and they hadn't installed Netcat on another vulnerable device. Despite the fact that there was still command injection in there, Netcat wasn't running, so they just gave up and thought it wasn't affected. Netgear running is slightly modified Sierra wireless stuff. I'm really not sure how much Netgear actually do on this or whether they just outsource to a third party. It's been six months since I reported to them, almost six months, and they've done absolutely nothing. I have no idea how in control they are of their own device. In all of this stuff, there's loads of rebranding, shared code, especially in some of these lower level Qualcomm libraries as well. These issues might affect other vendors or similar devices using a similar development stack. I can't buy everything and check it myself and I'm bored of a lot of this by now. That's it. Thanks to everyone who's up here. Have a look at the blog post up here. I've written up some of this stuff and another issue that I found in a TP link, pre-authentication command injection in a TP link as well, and just really basic stuff on how to use Ghidra to find stuff like that. Hustle me on Twitter if you want at no thanks with all underscores underneath everything. Thanks very much.