Network Analysis of the HMU and Data Extraction Link to heading

In this post we will look at the communication interfaces of the HMU with the manufacturer’s servers. Chronologically and due to my poor soldering skills, this happened right after eavesdropping the UART communication between the microcontroller and the modem as detailed in part 2 and before I managed to connect to the JTAG interface. As mentioned in the introduction post, the CardioMessenger II-S HMU exists in two flavors: T-Line and GSM. As their names indicate, they defer in the way they communicate with the backend servers. In this post, we will first look at the T-Line version and show how to exploit the lack of mutual authentication to extract data from the device, and then how to achieve the same on the GSM version.

Analyzing the Telephone Line interface Link to heading

As a reminder, in the second post of this series on the finding the debugging interfaces, we also took a look at the communication link between the microcontroller and the modem. What happens is that the microcontroller sends AT commands to the modem to configure it, more specifically, it asks the modem to establish a connection to the Internet Service Provider using the Point-to-Point Protocol (PPP). This is done using PAP as authentication type, thus the credentials being set as well before starting the communication. The listing below shows the full exchange of AT commands sent by the microcontroller to the modem.

 
[2019 -03 -30 11:43:24] at atii5#vversion 
AT#MCOUNTRY? 
at 
AT+WOPEN=1 
AT#DIALSELECT=1 AT#AUTHENT=PAP  
at#atcmd=0,"-STE=7"  
at#atcmd=1,"+A8E=6,5,0,1,0,0"  
at#atcmd=2,"X3" 
at 
AT#DIALN1="T9W[REDACTED]"  
AT#ISPUN="[REDACTED]@cm3-homemonitoring.de"  
AT#ISPPW="[REDACTED]" 
at#atcmd=0,"-STE=7" 
[2019-03-30 11:43:26] AT#CONNECTIONSTART  
[2019-03-30 11:43:28] at#connectionstop 

An interesting thing to notice here is that the connection is closed right after it is started, and for a good reason: the HMU was not plugged in any telephone line! Now, there was no telephone line available to me when I did the testing, and in addition the goal was to not interact with the backend servers anyway.

As it can be seen from Figure 1, the modem can be removed from the PCB very easily, so I decided to simply plug my computer in instead, using a regular USB-to-TTL adapter, and to emulate the modem.

To do so, I wrote a small python script using PySerial to interact with the UART and to reply to the commands sent by the microcontroller. I got the expected responses for the first command by eavesdropping at the responses of the legit modem to the microcontroller, and the remaining ones by looking at the references for AT commands. The AT#connectionstart command expects to see the CONNECT [BAUDRATE] message, followed by an IP address attributed to the HMU and finally the OK_Info_PPP message. The HMU will wait explicitly on this last message before sending the next (new) command: AT#TCPSERV. TCPSERV as its name indicates, opens a TCP socket to a given IP:Port. In our case, the HMU opens a socket to 172.16.14.1:4242. In response to the TCPSERV command, we send the OK_WaitingForData message which tells the microcontroller that the modem is ready to receive data (and thus has switched to data mode). Once we send that command, the microcontroller sends a bunch of hexadecimal data… hurrah! The listing below shows the full exchange.

 
< [2019-03-27 22:54:03] AT#DIALN1="T>W[REDACTED]" 
> [2019-03-27 22:54:03] OK 
< [2019-03-27 22:54:04] AT#ISPUN="[REDACTED]@cm3-homemonitoring.de" 
> [2019-03-27 22:54:04] OK 
< [2019-03-27 22:54:05] AT#ISPPW="[REDACTED]" 
> [2019-03-27 22:54:05] OK 
< [2019-03-27 22:54:06] at#atcmd=0,"-STE=7" 
> [2019-03-27 22:54:06] OK 
< [2019-03-27 22:54:09] AT#CONNECTIONSTART 
> [2019-03-27 22:54:09] DIALING 
> [2019-03-27 22:54:09] TW[REDACTED] 
> [2019-03-27 22:54:09] CONNECT 115200 
> [2019-03-27 22:54:09] 172.16.14.80 
> [2019-03-27 22:54:09] OK_Info_PPP 
< [2019-03-27 22:54:12] AT#TCPSERV=1,"172.16.14.1" AT#TCPPORT =1,4242AT#OTCP=1 
> [2019-03-27 22:54:12] OK_Info_WaitingForData 
 ---------- Switching to data mode ------------- 
< [2019-03-27 22:54:12] [REDACTED]@cm3-homemonitoring.de 
 [REDACTED] 
<[2019-03-27 22:54:12] aa0005098e000000[REDACTED]0807204446d8b24981f356c69 ... 

Here as well we can notice some interesting points: first of all, the first thing that is sent after the socket is opened is a username and a password (which happen to be the same as the one used to establish the PPP connection). The port does not give too much information on the protocol used here, I assumed it was a sort of “telnet-like” connection. The data, apart from the credentials, does not seem to follow any known protocol.

After the data is sent, nothing else happens. Eventually, the HMU will reboot and the process will start all over again. The size of the data sent varies between 1kB and 3kB. My guess is that the microcontroller is maybe expecting an answer from the server. But this is not sure because it also never sends any command to quit the data mode. I also checked on the other pins of the RS-232 connector to see if exiting the data mode was done using hardware signals, but nothing there either.

We will leave the data aside for now as the next post focuses on it and on reverse-engineering the proprietary protocol. Let’s now have a look at how to reproduce this on the GSM version.

Analyzing the GSM interface Link to heading

Data sent through GPRS Link to heading

We saw in the second post of this series, when doing the hardware analysis, that the CardioMessenger II-S T-Line and GSM versions were sharing more or less the same PCB design, exposing the communication line of the microcontroller with the modem. When listening on that line, it is not surprising to observe the same kind of process than on the T-Line: the microcontroller asks the modem to establish a PPP connection with the vendors VPN. The listing below presents this.

[2019-03-06 14:25:12] AT 
[2019-03-06 14:25:13] AT+CGMR 
[2019-03-06 14:25:13] AT+MBAND? 
[2019-03-06 14:25:13] AT+CPIN? 
[2019-03-06 14:25:13] AT+CPIN="[REDACTED]" 
[2019-03-06 14:25:14] AT+CPIN? 
[2019-03-06 14:25:14] AT+CGSN 
[2019-03-06 14:25:14] AT+CIMI 
[2019-03-06 14:25:14] AT+CRSM=176,242 
[2019-03-06 14:25:14] ATS24=0 
[2019-03-06 14:25:15] ATS100=0 
[2019-03-06 14:25:15] ATS102=0 
[2019-03-06 14:25:15] AT+MSCTS=0 
[2019-03-06 14:25:20] AT+CREG? 
[2019-03-06 14:25:22] AT+CREG? 
[2019-03-06 14:25:24] AT+CREG? 
[2019-03-06 14:25:24] AT+COPS? 
[2019-03-06 14:25:29] AT+CGPRS 
[2019-03-06 14:25:29] AT+CGMI 
[2019-03-06 14:25:29] AT+COPS=3,2 
[2019-03-06 14:25:29] AT+COPS? 
[2019-03-06 14:25:29] AT+COPS=3,0 
[2019-03-06 14:25:29] AT+CSQ 
[2019-03-06 14:25:32] AT+CSQ 
[2019-03-06 14:25:32] AT+CREG=2 
[2019-03-06 14:25:32] AT+CREG? 
[2019-03-06 14:25:32] AT+CREG=0 
[2019-03-06 14:25:38] AT 
[2019-03-06 14:25:38] AT+CPMS="SM" 
[2019-03-06 14:25:38] AT+CMGL=4 
[2019-03-06 14:25:38] AT+MIPCALL=1,"[REDACTED]","[REDACTED]@cm3-homemonitoring.de","[REDACTED]" 
[2019-03-06 14:30:38] AT+MRST

Most surprisingly though, the connection seems to fail, and the microcontroller ends up resetting the modem after 5min and starting up all over again. This is due to the credentials that are not valid anymore to access the VPN. The modem on the CardioMessenger II-S GSM is not “plug-and-play” as the one from the T-Line version, and thus it was not possible to emulate the modem directly. Another student working on that project, Anniken Wium Lie, was however focusing on the network interface and more specifically on the GSM interface. She set up a Fake Bake Station using OpenBTS and analyzed the security issues related to the mobile network. It was then possible to use her set up and extend it to fake not only the mobile network, but the manufacturer’s server as well. Once GRPS is enabled on OpenBTS, the HMU receives an IP and thus the MIPCALL succeeds. With not too much surprised, the next command issued by the microcontroller asks for a socket to be opened to the same IP (but different port) than in the case of the T-Line version.

[2019-03-04 10:31:20] AT+MIPCALL=1,"[REDACTED]","[REDACTED]@cm3-homemonitoring.de","[REDACTED]" 
[2019-03-04 10:31:24] AT+MIPOPEN=1,3953,"172.16.14.1",2323,0

Knowing that, we set up an ubuntu VM with the proper IP and listening on port 2323 (using a simple nc -lv 2323). The setup is shown in Figure 2.

As a result of the emulation, the HMU is able to open a TCP socket with the server and then to send data to it using the MIPSEND command. Like the T-Line version, it first sends the credentials, which also happen to be the same as the ones used to connect to the VPN, and then the data.

[2019-03-01 13:35:36] AT+MIPOPEN=1,6407,"172.16.14.1",2323,0  
[2019-03-01 13:35:41] AT+MIPSETS=1,1372 
[2019-03-01 13:35:41] AT+MIPSEND=1,"[REDACTED]" 
[2019-03-01 13:35:41] AT+CSQ 
[2019-03-01 13:35:41] AT+MIPPUSH=1 
[2019-03-01 13:35:46] AT+MIPSEND=1,"050DFE000000[REDACTED]080BE6E2F7AA0FCD96EC016D65E2A28E09F23E5AB69B404957EAB038A3EC4472ABF69C50F282C0A45C8F9C578315E97871828432DFD777921451993950F40FCB1EF9" 
[2019-03-01 13:35:46] AT+MIPSEND=1,"941E44938B37B27EC1E99F677293A2A08A784C4A2AEDD44873812D44183D9FD896687105326ABFAC7213347AD7398BA48D86E8A555AFA868C2862F893B7C46B9A43B01103B0A17C7C692F034" 
[Cropped] 

Data sent through SMS Link to heading

The GSM version of the CardioMessenger II-S also uses SMS to send data back to the manufacturer. This data can be collected either by using the Fake Base Station or by eavesdropping the communication with the modem. I will not speak more about the mobile network part, but I encourage you to read Anniken’s work.

Capturing SMS is similar to capturing data sent using GPRS. The only difference is that it happens a little bit randomly, and it is required to eavesdrop for a longer period of time. 56 SMS were collected over a 48h eavesdropping session. The listing below shows such an eavesdropping.

[Cropped]
[2019-03-09 02:54:14] AT+MIPCALL=1,"biotroni.ic.t-mobile","[REDACTED]@cm3-homemonitoring.de","[REDACTED]" 
[2019-03-09 02:55:11] AT+CPMS="SM" 
[2019-03-09 02:55:11] AT+CMGL=4 
[2019-03-09 02:55:11] AT+CMGF=0 
[2019-03-09 02:55:11] AT+CMGS=120 
[2019-03-09 02:55:11] [SMS HEADER REDACTED]0604FEB0555B4374D1C5EF24287FA3954CA200AFBBDC44C170DB1A8C452DC03891BD43302DAC8DA33CE225FF99E976F9B066CA00AA5A25AB8A47218D21F232ED41AED4E0F22F42E6189968D7CF6B965B73A768D7CF6B965B73A768D7CF6B965B73A7FE059B4602325756AT+CMGS=120 
[2019-03-09 02:55:12] [SMS HEADER REDACTED]0604FEB0555B4374D1C5EF24287FA3954CA200AFBBDC44C170DB1A8C452DC03891BD43302DAC8DA33CE225FF99E976F9B066CA00AA5A25AB8A47218D21F232ED41AED4E0F22F42E6189968D7CF6B965B73A768D7CF6B965B73A768D7CF6B965B73A7FE059B4602325756 
[2019-03-09 02:55:34] AT+MIPCALL=1,"biotroni.ic.t-mobile","[REDACTED]@cm3-homemonitoring.de","[REDACTED]" 
[2019-03-09 02:55:36] AT+COPS=? 
[2019-03-09 02:55:59] AT 
[Cropped]

Even if at first glance it seems that the data is different for the SMS, it is because what we see is in fact a SMS PDU, but its content is still using the same protocol as we will see in the next post. We can also notice that the same SMS is sent twice here.

Wrapping up Link to heading

In a nutshell, at that stage we managed to successfully extract data from both the CardioMessenger II-S T-Line and GSM version, emulating the modem for the former and the backend server for the latter. In addition, we got some additional data sent through SMS. Having data is nice, but we have not really made any sense of it yet. In the next post, we will analyze it and reverse engineer the proprietary protocol used by the manufacturer to send the data from the HMU to the backend server.

Go to Part 4 - Reverse Engineering of the proprietary protocol used by the HMU.