2022 Jailbreak Security Summit: Marc Newlin: Your DOCSIS Modem is not a Software-Defined Radio.
Cable modems are not software-defined radios, LTE does not interfere with DOCSIS, and NDAs are an effective tool against reverse-engineering. (All lies.)
This talk explores the architecture and RF-capabilities of the Netgear CM400 DOCSIS-modem (which you can find online for $10-15). We’ll start with paths to root, enumerate the interesting RF-components and reverse-engineering targets, and demonstrate limited control of the RF transmit-chain. The target-device is an accessible platform with plenty of potential, so we’ll conclude with the release of POC code, and an enumeration of ideas for continued research.
Marc is a wireless/embedded security-researcher, and member of the reverse-engineering team at SkySafe. His greatest hits include MouseJack, several DARPA challenges, and that time he got 24 CVEs in Comcast equipment.
Transcript:
Marc Newlin: Thank you. All right, well, good morning. It's, you know, great to be here. This is the first time I've been at a podium in 2 1/2 years, and it feels a little weird being around so many other humans. But I'm also happy to be here to share some knowledge. So this talk is titled "Your DOCSIS Modem Is Not An SDR," which, itself, is a bit of misinformation. So I have a strong joy in repurposing hardware for use cases that it wasn't intended for. And kind of a canonical example of this that I like is the RTL-SDR, which started life as a digital-TV-tuner dongle.
Marc Newlin: So you plug it into your computer, and then you can watch broadcast television on your laptop. And the way this device worked was as, actually, a software-defined radio. So it would send the raw, sampled RF data to the host computer. And somebody figured out that you can actually use this as an SDR because the driver for this RTL-SDR would then do the demodulation and video decoding in host. And I think this is a great example of this type of device repurposing because it allows people who are hobbyists or don't have, you know, a research budget, to get exposed to a capability that they otherwise would not.
Marc Newlin: And so this talk is about a Netgear modem called the CM400, which I got to know for a few weeks over the summer. And I think it's a really good candidate for this type of device repurposing because it's, more or less, a software-defined radio under the hood. And so we're going to start by doing a brief introduction on DOCSIS and MoCA. These are two radio frequency protocols that are spoken by cable modems. We're then going to look at a trio of some really goofy, bizarre bugs that I found over the last handful of years, which resulted in me looking at this Netgear modem. Then we'll take a look at the modem itself and its architecture and RF capabilities. And then I'll walk through the steps required to run custom code on the modem. I've gotten as far as figuring out some basic control over the transmit chain.
Marc Newlin: And so my hope is that people would be able to take what I've learned from this and then have some cool side hackery. And another fun note about this modem - it's around 8 years old, DOCSIS 3.0. And so it's being deprecated by a lot of U.S. ISPs. And so you can buy these for 10 or 15 bucks on Amazon or eBay. And so what really excited me is that it's at the sweet spot of capabilities and price point where hobbyists can potentially get access to these SDR capabilities in a more complete way than with something like the RTL-SDR. And then we'll conclude with a bunch of ideas I have for future research with this device that I haven't had time for and that I hope someone else will be able to pick up.
Marc Newlin: So DOCSIS and MoCA are both radiofrequency protocols that are spoken by these cable modems. And you can think of this type of protocol as something called RF over coax. And so, conceivably, if you were the only person on Earth and no one else was occupying the RF spectrum, you could actually put an antenna on the back of your cable modem, put an antenna on the ISP's headend unit and then communicate wirelessly. But, of course, we don't do that because we have many other users trying to occupy the same spectrum.
Marc Newlin: And both the DOCSIS and MoCA protocol occupy the same physical medium. So that medium in the wireless space is going to be the, you know, free space in the air. For the modem, that physical medium is the coaxial wire that you plug your modem into in the wall. So in order to have both DOCSIS and MoCA share the same physical medium, they use something called frequency-division multiplexing, which just means you have one protocol operating in one band and one protocol operating in another.
Marc Newlin: And so this is a - kind of a approximate table of the frequency division used by DOCSIS and MoCA. The actual frequencies vary a bit depending on North America or Europe, as well as your version of DOCSIS, version of MoCA and the specific configuration. But, roughly, you have DOCSIS uplink, that is, going from your modem to your ISP, occupying the lowest part of the band. So in North America, with DOCSIS 3.0, it's approximately 0 to 50 megahertz. Then you have DOCSIS downlink above that at approximately 50 to 850 megahertz. And then you have MoCA further above that at approximately 850 to 1,500 megahertz. And the reason we have DOCSIS uplink at the lowest frequencies is that when you have a radio frequency transmission, the lower the frequency, the higher the transmit distance at a given power. So by having the DOCSIS uplink at the lowest frequency, you can have the lowest requirements for transmit amplifiers and cheaper hardware on the end user. MoCA, on the other hand - this is used for communication between devices within your home or office or apartment. Because MoCA doesn't have to travel as far, it uses the upper band. So I'm a really big fan of bugs that are - you know, you don't expect to find them, maybe not looking for a bug and bugs that make you ask, you know, WTF is going on? And so I've taken kind of a weird path to find an interest in this modem. And along that path has been some of these type of bugs. And my favorite thing about bugs that you don't expect is that it causes you to challenge assumptions you've held or to challenge some truth that you've held as fact. And it's humbling to discover that you were assuming something that was wrong but also valuable because it allows you to have new perspective for future research efforts.
Marc Newlin: So the kind of spiritual origin of this project is what I call the Comcast project, which was some research I was doing back in 2017. And slightly before this in 2016, I attended a talk at Hack In The Box Amsterdam by this guy who goes by the handle Blaspheme. And he was reverse engineering his ISP's modem from the vendor UPC. And he discovered this sort of technician's access Wi-Fi credential the modem would use. And the way this worked - there was an algorithm here reverse engineered on this modem, which will consume the current day as well as the serial number of the modem. And then that would go into this proprietary algorithm. It would generate a credential. That credential could be used by a technician to access his Wi-Fi network when they came to visit his home. And this makes sense because you want to, you know, have somebody be able to come and work on your modem. Maybe you don't want to share your password or so forth.
Marc Newlin: This talk was really fascinating. And I decided it would be fun to try and reproduce this on Comcast equipment, which was my ISP at the time. And so at the end of the day, I ended up with 24 CVEs in that equipment, but I was primarily looking for wirelessly exploitable bugs - so Wi-Fi and then some Zigbee RF4CE on set-top boxes. But I also purchased a bunch of just plain, vanilla DOCSIS modems which had, you know, no wireless interfaces, no MoCA - just plain DOCSIS modems. And so, you know, halfway through this project, I had a shell on the modem - well, on both Linuxes on the modem. There's one ARM and one x86 on the Comcast modem I had at the time. And I wanted to get a shell on my set-top box. And my only way to access a set-top box over the network was over the MoCA link from my modem. So from the shell on the modem, I could ping the set-top box.
Marc Newlin: So I ran an Nmap scan. And I didn't see any network services, but I had this kind of roundabout way to do command injection on the set-top box. And so the way this worked, there was, you know, eMMC or flash memory on the set-top box which hosted the Linux. But there's also a mechanical hard drive, which was used for caching media and DVR capabilities. So it turned out you could turn off a set-top box, pull out the hard drive, modify a file in the file system that got read as part of a diagnostic web UI on the set-top box. You could then modify that file, put the command you want to inject, reassemble the thing, turn it on, bring up this web UI and inject a command into the Linux. So it's also blind command injection, so you can get response. But it's super-practical if you want to, you know, have some other thing you want to trigger with this command injection.
Marc Newlin: And so my thinking was I could turn off the firewall on the MoCA interface. So I crafted an IP tables rule - or command, rather - that would allow all on this MoCA interface. And my hope was that I would then be able to, you know, see these network services on the set-top box over MoCA from the modem. So I go through this process. I pull out the hard drive, do the command injection, bring it back up, turn off the firewall. And pretty soon all of the devices that are connected to my LAN lose connectivity for a minute or two and then come back online. And so I'm hoping that, you know, something weird has happened. But, you know, maybe my set-top box has a DHCP lease from the modem.
Marc Newlin: So I, you know, do an Nmap connect scan across the subnet for my LAN. And I see some devices that I don't recognize - you know, a couple of iPhones that I don't have, a couple of Apple devices that I don't have. And it turns out that I'm actually on my neighbor's LAN. So I try to log in to the modem. My password is not accepted, of course. It's my neighbor's modem. I try the default credential. I get in. And this is, you know, not my modem. And so what's happened is that my devices are still connected to the Wi-Fi radio on my modem, but they they're getting a DHCP lease from my neighbor's modem.
Marc Newlin: And this kind of blew my mind. And I still don't know exactly what happened here. And I hope somebody can figure this out. And so as best I can tell, MoCA, which I thought was constrained to my physical premises, my apartment, is actually maybe not constrained to just that one housing unit. And so I wanted to see if I could understand, you know, how MoCA was actually functioning and, you know, what was actually happening here. But I did not want to experiment by bridging my neighbor's network or otherwise breaking the law. And so I thought it'd be fun to, you know, see if you could implement a software-defined radio receiver for MoCA. The first thing I tried was this MoCA-to-Ethernet adapter, which is a device about this big. It has a coaxial port on one end, Ethernet on the other. You plug it into your wall - into a coax port on your wall, and then it gets a DHCP piece from your modem and basically allows you to have a remote Ethernet port for your modem. Unfortunately, the MoCA-to-Ethernet adapter that I had did not have any kind of a promiscuous mode, and it did not look super-hackable. So I tabled that and tried to go the SDR route. Now, MoCA has a variety of physical layer configurations. You can have channels as narrow as approximately 25 megahertz and then up to hundreds of megahertz. So I took an SDR and attached some attenuators, plugged it into the wall and started taking some IQ captures. And I quickly discovered that the MoCA configuration that I was seeing was a 100-megahertz-wide OFDM waveform, which was considerably more complex than I would be able to do with any of the SDR hardware I had.
Marc Newlin: And so I ended up, you know, shelving this MoCA investigation in favor of other research efforts, but I still don't know what was actually happening there. And so after this Comcast project concluded, not long after that, I moved out to Los Angeles, got a different ISP. Now, different ISP is kind of a misnomer because the, you know, ISP oligopoly in the U.S. means you have the same devices, same service, same price no matter where you are. But I opted to stop subscribing to cable TV service and getting just - I agree.
(LAUGHTER)
Marc Newlin: And I got just a plain DOCSIS modem, one, so I could switch to streaming services. But also, I did not want to, you know, risk somehow my neighbor accidentally getting on my LAN because, you know, MoCA now terrifies me. So around this point, this is when Matt Knight and I were starting our work on the DARPA Spectrum Collaboration Challenge in - let's see - early 2018. And for the next year and a half, 100% of my free time went to SC2. So we had a day job and then another day job doing the DARPA challenge. And so I didn't have any opportunities for this type of research for quite a while until that challenge concluded at the end of 2019.
Marc Newlin: And around that time I had purchased - this was sometime early pandemic, but my sense of time is kind of mush these days. I had purchased a Dell XPS 13 laptop, and this has within it a type of Wi-Fi adapter from a brand called Killer Wi-Fi. This started out originally as a vendor that was modifying the drivers or microcode on Intel Wi-Fi adapters and Ethernet adapters to optimize for latency. And ostensibly, the idea is that if you have lower latency, you're better at video games or something like that.
Marc Newlin: So I get this, you know, Dell XPS 13. I unbox it, and the first thing I do is boot into windows and start downloading an Ubuntu ISO. And around 200 megabytes into the download, the internet stops. And I observe this because I'm on the couch with my wife. We're watching a movie, and then Netflix goes offline. Pretty soon all the Wi-Fi devices disconnect. And I figured for sure this has to be a coincidence. So I try it again, start the download again. And same thing - around 200 megabytes in, the router crashes. This was a kind of crappy TP-link AX1500 router. It also reproduces on an Ubiquiti Unifi 6 Lite.
Marc Newlin: So this is a cross section of the layout of the part of our apartment where I was in. On the top there, there's kind of a floating loft which has open walls on the left and right. One side goes down to the kitchen. One side goes down to the living room. This creates kind of a goofy multipath environment because you have all of these various walls for your radio frequency signals to be bouncing off of. And so this is the configuration where the devices were when I experienced this crash. And so I woke up the next morning, and I think, OK, you know, either I'm going to be setting up a laptop, or I'm going to be diagnosing some really weird Wi-Fi 6 bug.
Marc Newlin: So I wanted to be able to reproduce this while looking at the blinking lights on the router. So I bring the router downstairs, and try as I must, I can't actually get it to crash in this location. So I figure maybe there's something about the router being upstairs that causes it. So I go upstairs, and I can't get it to crash. So finally I get frustrated. I go back to the original conditions from the night before with the router upstairs, the laptop downstairs. And sure enough, in this configuration, it crashes. And so I did a bunch more experimentation, and I figured out that if you have at least a couple walls between the laptop and the router or this specific configuration where I'm on the couch and my laptop is directly underneath one end of the loft, then it reliably crashes.
Marc Newlin: And this is another bug where I don't know what's happening here. As best I can tell - you know, or my best inference is that there's some timing characteristics with this Killer Wi-Fi adapter and that they are breaking the spec and not compatible with the TP-link router. And the TP-link router was a Broadcom-based unit, and so my first thought was, you know, I'm going to swap this out for a Qualcomm-based unit. So I get the Ubiquiti unit and get the exact same bug, exact same crash. One difference with the Ubiquiti unit - I needed to send a higher rate of packets and for a longer time, but I could still achieve the crash by doing, you know, a simple Nmap port scan with the most aggressive timing options.
Marc Newlin: And so my final solution for this was just ditching Wi-Fi 6 and getting an 80211ac router. And I haven't gone back to this because it was frustrating to troubleshoot because it was limiting our ability to do normal things on the internet. But I'm still fascinated by this. And I really like the idea of experimenting with intentionally modifying the latency parameters on this or other Wi-Fi adapters to see if you can intentionally cause these sorts of crashes. And so, you know, after getting this 80211ac router, I thought everything was fine with my internet problems, and it would be smooth sailing. But that was not the case.
Marc Newlin: So before my job at SkySafe, where I am now, I was at one of the electric scooter rental companies. And all the scooters have LTE modems in them. And so I was, during the pandemic, accumulating more and more of these devices at home. And after, you know, I had accumulated, I don't know, eight or 10 of these scooters at home, I didn't realize this was related, but I started experiencing intermittent connectivity problems, where I would have my - I would stay connected to Wi-Fi - so it wasn't a problem with the Wi-Fi router, but I would lose connectivity to the internet for a few minutes every now and again. And it wasn't a super regular thing. But it happened enough that it seemed to be a pattern. So I contacted my ISP, and they told me they couldn't see any problems on their end. And this continued for two or three months. And finally, I, you know, had enough of this, and so I asked the ISP to send out a technician to see if we could troubleshoot this in site and identify what was happening.
Marc Newlin: So the technician comes out. He sees that there is some interference happening on a couple of the DOCSIS downlink channels. And he thinks it's from a, you know, degraded filter or somewhere on the line that was originally a low-pass filter to prevent people from stealing digital cable but was degraded and filtering more than it should. So we spent a couple hours wandering around the apartment complex, tracing the wires and measuring them, testing them independently. And we can't find any evidence of this filter or physically find it. So we continue, and we're, you know, kind of at our wit's end trying to figure out what's going on. And then the tech, you know, bends down and takes a really close look at the coaxial wire coming out of the wall. And it turns out there was this period of time between the advent of cable TV and then having that wiring be common in new construction and the time when cable internet became common. And there's a period where you have a poorly shielded coaxial wire that was fine for cable TV at some point but is susceptible to RF interference from emitters in the environment.
Marc Newlin: And it turns out that Spectrum has the 700 MHz band that they use for their DOCSIS downlink overlaps with the 700 MHz band that is used by Verizon for LTE. And so the tech commented on this building he was at earlier in the week, another residential building in LA. And this building was in kind of an LTE desert. And so the, you know, co-op board or HOA or whatever worked with Verizon to install a tower on the roof. I don't know what a tower means exactly but some kind of an LTE base station. And the result was that people had sufficiently good LTE service if they were Verizon customer, but the top several floors of that building could no longer use Spectrum internet because of interference from the base station.
(LAUGHTER)
Marc Newlin: And this just blew my mind because the inference that we then validated was that all of these LTE scooters that I had near my modem were actually interfering with the DOCSIS downlink channels, causing it to lose sync and go through the reconnection cycle, which would cause it to be offline for several minutes. And so this is, you know, kind of interesting 'cause I assume, you know, when you have shielded wire and you have wireless devices that these are kind of separate systems and, you know, don't interrelate. But given that I could observe interference from these LTE modems breaking my internet, I became really interested in potential side channel attacks.
Marc Newlin: And so I took a USRP B210. I put it next to a length of this unshielded coax - or poorly shielded coax - cranked up the receive gain and took an IQ capture. And sure enough, I could see, you know, the faint outline of this downlink DOCSIS waveform. And so my first thought is, OK, maybe it would be possible to build a DOCSIS SDR receiver because - well, it depends on the version of DOCSIS, but DOCSIS 3.0 has channels that are 6 and 8 MHz wide, which is pretty manageable with an SDR. Now, I wanted to not experiment by looking at live traffic from my ISP; I wanted to have a known DOCSIS transmitter where I could control what was being sent over the wire so I could have a, you know, more productive iteration cycle. So I went to my box of all of the things that I never throw away because I might, you know, need to cut a connector off the cord one day, and I had a couple of modems that were still left over from that Comcast project. And these were the Netgear CM400 and the Motorola Surfboard SB6141. These are very similar devices. They both have the same DOCSIS SoC, same RF components. The board layout looks very similar. And so I think they're just different spins of the same reference design. But the Netgear device had a populated four-pin header on the board and then an unpopulated - it says 10 there - but actually eight-pin header next to the SoC. Otherwise, they're pretty much identical devices. I went with the Netgear device because it had this UART four-bit header populated and was the easier choice.
Marc Newlin: So let's take a look at what this board actually looks like. And the first thing I did, of course, is open it up and put it on my desk. And on the right, we have the modem. On the left, we have a USRP B210. And the first thing that catches my eye is that the SoC on the modem, the kind of large black component, has the same package size as the FPGA on the USRP. And now, this is a terrible way to evaluate similarity of devices.
(LAUGHTER)
Marc Newlin: But I had this lightbulb moment of, you know, what if instead of using this modem to send DOCSIS frames that I could then decode with an SDR, you know - what if it is an SDR somehow? And so I kind of pivoted my mental thinking and started looking at it from that perspective.
Marc Newlin: So now I'd like to walk through the components that are included on this Netgear modem. We have this PUMA 5 DOCSIS SoC. So this is a component that started life being branded from TI. That IP, or business unit, was then sold to Intel. So I've observed both Intel and TI variants of this SoC in the wild. Now it's owned by a company called MaxLinear. I don't know if they still make the Puma 5 series, but they still make the Puma series of DOCSIS chipsets.
Marc Newlin: We have the MaxLinear MxL 261. This is an RF SoC. This is the receiver and the modulator. So the raw radio data comes in over the coaxial line. It gets sampled and demodulated and decoded using this, and then the decoded DOCSIS packets get sent over to the SoC, which then handles them off Ethernet. On this MaxLinear SoC, you have two tuners, each of which can cover a 96-megahertz chunk of bandwidth in the band of the DOCSIS uplink. So in this case, that's 44 megahertz to 1 gigahertz. And each of those tuners can enable up to four narrowband receive channels. And with the driver that's included on the board, you can configure these between BPSK-QAM64.
Marc Newlin: The 6- and 8-megahertz channels are specific to DOCSIS 3.0. DOCSIS 2.0 has a little bit more variance. But then DOCSIS 1.0 and 1.1 has really granular channel width. So with DOCSIS 1.0 and 1.1, you can have as low as 100-kilohertz-wide channels. And I haven't experimentally validated this, but my understanding from the specification is that DOCSIS 2 devices are supposed to be backward compatible with DOCSIS 1. On the modem are both firmware images for DOCSIS 2 and DOCSIS 3. And so I think, you know, between the two firmware images on there for this RF SoC, there's probably a lot more configurability than just the 6 and 8 megahertz channels that are known for DOCSIS 3.
Marc Newlin: And we have an 8-megabyte SPI Flash chip. This includes the Linux image for the Linux, which runs on the 400-megahertz ARM core on the PUMA SoC. We have some DRAM. And then we have this TX Amplifier chip. And this is on the transmit chain for DOCSIS. So this has data that goes out from the SoC to this amplifier and then out over the coaxial port on the modem. This is 1.25 watts, which is, you know, a nontrivial amount of power. And so with this, you can actually generate and transmit data wirelessly that you can then pick up with a antenna-connected SDR on the other side.
Marc Newlin: This is the sort of transmit filtering block. Because we have the frequency division multiplexing between DOCSIS downlink and uplink - again, we have the uplink on the low band and then the downlink on the higher band - we need to be able to use that same physical medium at the same time without stepping on each other. And so this is a low-pass filter, which only allows through RF signals up to approximately 50 megahertz. Then on the receive side, we have a high-pass filter, which only allows through signals that are above 50 megahertz. And this way you could have data go into the receive chain and out of the transmit chain at the same time without having any interference.
Marc Newlin: And one downside to this is it means you can only transmit between 0 and 50 megahertz from this modem. And I have a thought, and I'm not a double E, and so I might be making a bad assumption here. But my hope is that you can just bypass the low-pass filter on the transmit chain by, you know, bridging it with a jumper wire between the output of the amplifier and the coaxial port. The DOCSIS SoC itself will not complain if you tune as high as a gigahertz. And so I hope that means that it will be possible to break out of that 0-to-44 or 0-to-50 megahertz band that you normally have with the DOCSIS uplink.
Marc Newlin: Then we have this conveniently populated 115200 baud UART. This is one of the ways we can access a shell on the modem. We also have a 100 megabit-per-second Ethernet. The component on the far right of that box is the Ethernet controller, and there's the Ethernet PHY just above the jack there. And then this has a DMA interface between the PUMA SoC and Ethernet. This is commonly used for sending in DOCSIS frames or, rather, the eventual Ethernet frames over Ethernet out of the modem. But my best guess right now is that it would be possible to also use that DMA channel for sending non-Ethernet frames - so potentially, raw sample RF data from the receive max linear chip over to the Ethernet PHY. And so I think there's some unanswered questions there, but I think it would be possible to leverage the Ethernet PHY for getting more direct access to the receive chain.
Marc Newlin: So there are a variety of OS resources that are handy for this. Netgear is nice in that they have GPL releases for most of their Linux-based devices. The GPL code is incomplete as most of the Puma 5 kernel, not all of it, it's missing a bunch of, you know, registers, memory addresses. So you can't just directly compile it. But it is very helpful for understanding the memory layout of the DOCSIS SoC. There's also some MaxLinear code for a similar SoC, which has shown up on GitHub. So this is the MxL241. This a - it's not a DOCSIS SoC, but it's for a similar frequency band for similar types of devices. And so I observed that the function names and API signatures from this code on GitHub lined up pretty closely to what I observed from the drivers on the modem. And so it's a very helpful resource for understanding what's actually happening there in the drivers.
Marc Newlin: So there are a bunch of pretty useful reverse engineering targets on the file system for Linux. We have the MaxLinear drivers for the MxL261, which is the component on the board, but also for that MxL241, which is from that GitHub repo, and then the MxL201. And these are all binaries which are stripped, so they don't have debug symbols, but they do have extremely verbose debug strings. And so I found I was able to open any of these up in Ghidra and very easily follow the flow control. And it's, you know, a surprisingly easier reverse engineering target all over. The same goes for the DOCSIS CLI. The DOCSIS CLI is intended for use for either technicians locally or for your ISP remotely to inspect RF properties of the DOCSIS connection. With this you have, I mean, tons of debug strings because it's meant for human interaction. It's a fairly rich RE target, but the CLI has the feature where it's made for not this modem specifically. So it has a lot of code paths which don't actually work on this SoC. They might be, you know, intended for other modems, or perhaps this is just an old version of it.
Marc Newlin: When you have your modem connect to your ISP and it does a registration process, the ISP actually pushes down firmware for your modem over DOCSIS. And this is why you don't commonly see DOCSIS modem firmware images up on vendor sites because they actually come directly from your ISP. And so my guess is this CLI, you know, gets replaced by a newer version once you register with your ISP. We also have images for the DSP core on the PUMA SoC. This is a TI DSP core. And this is used for the uplink. So when you're generating the DOCSIS frames that are sent over the wire, this TI DSP is used. And this is running the ThreadX RTOS. And I haven't gotten as far as running custom code on this, but I'm very confident that that would be possible.
Marc Newlin: So to actually access the modem and start our process of running custom code on it, we start with a root shell that we get over the UART. Now, this is a sort of limited boot shell. So the way this works - you reboot the modem, you're listening over UART, and there is a BusyBox prompt which flashes for just a very brief period during boot. From the time that BusyBox prompt flashes until the time the boot process is finished, it functions as an interactive shell. So you can send commands over the UART, and you can receive responses. Now, the responses are muxed with the normal boot output, and so it's a little bit messy sometimes. But in general, you're able to do this cycle of rebooting the modem, sending a command and then getting a response. And with that capability, we can inject some commands which put the modem into factory mode. In factory mode, it has this feature where it runs a passwordless route Telnet server on the LAN. So we can use a UART shell to put the modem in factory mode. And then we're able to actually access the Telnet root shell from the LAN without needing UART. This is kind of a tedious process. So as part of the code release that I'll be publishing to GitHub today, I have a convenience helper script to sort of auto root the modem and put it in this factory mode.
Marc Newlin: From there, we can read off the flash partitions. And we need to do this before we want to compile, you know, interesting custom code for the modem because we need to link against shared libraries that are on the modem and that we can't build from the GPL dump. And so for convenience as well, I have a Python script which will read off all the flash partitions over Telnet, and then we can extract that using binwalk, and that gives us the shared libraries for the MaxLinear ship as well as the DOCSIS SoC, and we can link against those locally on our host to cross-compile code for the modem to then run on the modem.
Marc Newlin: So this is kind of the minimum hello world of exercising TX control on the modem. So we have this first function here, HAL Connect, that just initializes our pointers to the SoC memory space. We have the really helpfully named PHY Upstream Set Frequency. And this is a function that I pulled out of the DOCSIS CLI that are all named approximately like this, very verbose, very helpful. And then the final call there to restart upstream section, this commits the frequency change to the SoC. This is one feature that we can change the frequency, but there's also control over the transmit power within the DOCSIS SoC itself. And then we can also control the amplifier chip. I haven't experimented much with the power because I found that even at low-transmit powers from the modem, I was getting close to saturating the input on a HackRF. I haven't done range testing over the air, but I believe this is going to be a pretty capable device for long-range transmission.
Marc Newlin: So then to actually run our custom binaries on the modem, I have an example project - part of the GitHub repo - which builds this binary, which will control the frequency on the DOCSIS SoC uplink. We can first use the CLI to enable a test waveform, which is just a sinusoid that's turned on at the middle of the uplink frequency. Then we can then move that around. They have a couple other test waveforms that you can turn on. I haven't figured out how to control input to those test waveforms. So one of them is a pseudo-random number generator which goes into the modulator. You can control the configuration of the modulator - so the type of modulation as well as the bandwidth. I don't know where that random number generator is located, but my speculation is that if we can locate that, then it will be possible to control the input to this modulator, and we could transmit modulated data over the air.
Marc Newlin: So here we have a brief example of how we're going to actually transfer data or transfer our compiled binary to the modem. It's a pretty sparse Linux, but it does have Wget. So we can tell that to the modem, serve up our compiled binary with a simple HTTP server. And then we're able to get that onto the modem, make it executable and invoke our binaries. The /dead partition on the modem is a temp FS file system that is backed by that 32 megabytes of RAM. And so we have enough scratch base for putting some code on the modem and executing it without needing to modify the file system.
Marc Newlin: And now I have a handful of ideas which I think would be really interesting for continued research with this device. I think it would be interesting to explore bypassing the analog transmit filter. I've verified that we can go between around 5 megahertz and 45 megahertz, and then we start to see the roll-off from that analog low-pass filter. My hope is that we can bypass that - and I don't know what else that would break - but to transmit above that bar. The MxL261 has some limits on the tuner which claims that it can go down to 44 and up to 1,000 megahertz. I don't know if that's accurate. They have some similar products which have broader frequency limits. So I think it would be fun to explore that.
Marc Newlin: I think one kind of low barrier to entry project would be implementing a LoRa transmitter in that 0-to-50-megahertz band, and LoRa is a chirp spread spectrum 5. And so the way you can potentially generate it is with that test sinusoid and then writing some code to just modify the frequency of that test sinusoid. I don't know what latency there is between sending the frequency update command and the radio retuning. So if that latency is too high, that might not be possible. But I believe it would be possible to generate some kind of a chirp waveform with that.
Marc Newlin: I also haven't got custom code running on the DSP or the MxL261. Both of the components have firmware images which are not encrypted. And I haven't seen evidence of signatures. So I think it would be possible to simply compile custom code for the correct architecture and run it. I don't know what the difficulty is, but it appears to be a commodity widely available TI DSP on the transmit side, so I think that would be doable for somebody who has experience with that DSP. I also think it would be fun to try putting an antenna on the modem and using the modem itself as an over-the-air DOCSIS sniffer. So like that side channel experiment with a B210, maybe you can just use the modem itself for that with an antenna.
Marc Newlin: And finally, I wanted to - I think it would be useful to understand how to use the ethernet DMA interface to get IQ data sampled by the DOCSIS SoC after it goes to the MxL261 over to the LAN. In the CLI, they have a capability for doing ADC sampling with either a 60- or 72-megahertz ADC. I've POC'd this enough to get some samples out, but you can only - well, in my test I could only do this from the 400-megahertz armed core, and so I wasn't able to sample much data for very long. And so I haven't had a good way to do a validation that the data I'm getting is in fact the IQ that I think I am. But I believe it would be possible to have that ADC output, the 60-megahertz output, go into the ethernet file because it's within the constraints of that 100-megabit ethernet connection.
Marc Newlin: And, you know, along these lines of wanting to get capabilities into the hands of hobbyists and repurpose devices, I really think this is a rich platform with a lot of opportunity and I hope that some of you are able to buy some of these modems and continue the hackery. And with that, I will take some questions.
(APPLAUSE)
Unidentified Person #2: Any questions?
Unidentified Person #3: I'll ask. Did you try moving the couch to the loft?
(LAUGHTER)
Marc Newlin: So the question was, did I try moving the couch to the loft? I did not, but, you know, maybe next time.
(LAUGHTER)
Marc Newlin: All right. Well, thank you.
(APPLAUSE)