Tech Explained: Firmware Backdoors

Last month came across a document released by US cyber defence agency and never really got time to look into in detail. I think this deserves more attention. It details that a patient monitor Contec CMS8000, used in many hospitals to track vitals like heart rate and oxygen levels, contains a firmware backdoor.

This backdoor is hardcoded into the device. When it powers on, it quietly tries to connect to a specific IP address not owned by Contec, but a university in China. Once connected, it mounts a remote file system and copies files into critical system directories, overwriting whatever is already there. There’s no integrity check, no version tracking, and no logging. The device just accepts and runs whatever it gets.

Technically, this is done using standard Linux commands like “ifconfig eth0 up” to enable the network, then “mount -t nfs” to reach the remote server, followed by “cp -rf” to replace files. These commands essentially hand over control of the device to whoever controls that IP. Even worse, patient data like ECG, SpO2, and blood pressure is transmitted to that same IP address over port 515 (normally used for old printer systems), not even using proper medical protocols. There’s no encryption, no authentication, just raw patient data streamed out. Meaning, if a remote handler wants, they can get your full data without any fuss. They can also just show any random readings/waveforms on screen with the backdoor. To me, this isn’t just a firmware bug. It’s really badly coded feature or more likely a backdoor for future remote access.

BTW this a white label device sold even in India under different resellers and brand names. Search for similar images on Indiamart or similar, you will get them. I don’t think anyone in India cares where their data ends up. Not sure why there isn’t any media outcry against this locally.

Anyway, if anyone from any hospital IT team is reading this and has this device (or any from its family), please remove network connectivity of this device. In an age where we trust machines with lives, we need to ask: who controls the code inside the box?

If you liked the post, Share it with your friends!

Back to Basics: LIN

Today, let’s talk about Local Interconnect Network(LIN). I believe it’s an essential but yet often overlooked communication protocol in automotive tech because of its big brother CAN.

LIN came in the late 1990s when automotive manufacturers needed a simpler, cost-effective solution to complement CAN. While CAN was great for critical tasks like engine control or braking. But for simpler tasks, CAN was too complicated and expensive. This is exactly where LIN shines. It operates on a single data wire (Data & GND) serial communication, making it simpler and cheaper to implement. LIN transmits at speeds up to only 20kbps which is more than enough for non-critical tasks like controlling windows, mirrors, seat adjustments, and wipers. Why use & waste the CAN bandwidth for these routine tasks?

Its architecture consists primarily of one master node and multiple slave nodes(upto 16). The master node initiates communication by sending a header; slave nodes respond based on predefined data frames. LIN has a self-synchronization feature, meaning slave nodes synchronize automatically with the master’s clock every time a message is sent in the header frame. Hence, there is no need for additional timing signals. Since communication protocol is not complex, it’s usually handled in the microcontroller and doesn’t need a dedicated controller like CAN.

The uC’s output is level shifted by specific LIN transceivers for transmission/reception in the bus. The physical layer bus voltage can be between 9V-30V, depending on the IC. They require pull-ups like I2C, but it might already be built into the IC. Although speed of communication is low, you would need to keep the bus capacitance under 10nF for good signalling. Max distance supported is around 40m. EMI/EMC problems with LIN are relatively lesser because of lower rise times/speed compared with CAN.

LIN is everywhere in modern cars. Think of them as local masters handling all the less critical work and then sends the data to the CAN when needed via the microcontroller. They do their work without any major fuss and coexist with CAN in your cars.

If you liked the post, Share it with your friends!
1 6 7 8 9 10 89