0x01 对HMU的网络分析和数据提取
在本文中，我们将研究HMU与制造商的服务器之间的通信接口。如引言中所述，CardioMessenger II-S HMU有两种形式：T-Line和GSM。顾名思义，它们会延迟与后端服务器的通信方式。在本文中，我们将首先介绍T-Line版本，并展示如何利用缺乏相互认证的功能从设备中提取数据，然后在GSM版本上实现相同的目的。
1.分析Telephone Line界面
在本系列的第二篇有关查找调试接口的文章中，我们还研究了微控制器和调制解调器之间的通信链接。发生的是微控制器向调制解调器发送AT命令以对其进行配置，更具体地说，它要求调制解调器使用点对点协议（PPP）建立与Internet服务提供商的连接。这是使用PAP作为身份验证类型完成的，因此在开始通信之前也要设置凭据。下面的清单显示了微控制器发送给调制解调器的AT命令的完整交换。
[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
这里要注意的一件有趣的事是，连接在启动后就立即关闭，这是有原因的：HMU没有插入任何电话线！现在，进行测试时没有电话线可用，此外，目标是无论如何都不与后端服务器进行交互。
从图1可以看出，可以很容易地从PCB上卸下调制解调器，因此，我决定使用常规的USB-to-TTL适配器简单地将计算机插入电源，并模拟调制解调器。
图1：CardioMessenger II-S T线调制解调器
为此，我使用PySerial编写了一个小的python脚本来与UART交互并回复微控制器发送的命令。通过监听合法调制解调器对微控制器的响应，我得到了第一个命令的预期响应，通过查看AT命令的参考，我得到了其余的响应。该AT#connectionstart命令希望看到CONNECT [BAUDRATE]消息，然后是归属于HMU的IP地址，最后是OK_Info_PPP消息。HMU将在发送下一个命令之前显式等待最后一条消息AT#TCPSERV。顾名思义，TCPSERV打开到给定IP：Port的TCP套接字。在这种情况下，HMU打开一个指向172.16.14.1:4242的套接字。为了响应TCPSERV命令，我们发送了OK_WaitingForData消息告诉微控制器调制解调器已准备好接收数据（因此已切换到数据模式）。一旦我们发送了该命令，微控制器就会发送一堆十六进制数据。下面的清单显示了完整的交换。
< [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 ...
在这里我们也可以注意到一些有趣的地方：首先，打开套接字后发送的第一个信息是用户名和密码（恰好与用于建立PPP连接的用户名和密码相同）。该端口未提供有关此处使用的协议的太多信息，我认为这是一种“类似于telnet的”连接。除凭据外，数据似乎未遵循任何已知协议。
发送数据后，没有其他任何反应。最终，HMU将重新启动，并且该过程将重新开始。发送的数据大小在1kB和3kB之间变化。我的猜测是微控制器可能期望服务器提供答案。但这并不确定，因为它也从不发送任何命令来退出数据模式。我还检查了RS-232连接器的其他引脚，以查看是否退出数据模式是使用硬件信号完成的，但那里也没有。
我们将暂时保留数据，因为下一篇文章将重点介绍数据以及对专有协议进行逆向。
2.分析GSM接口
通过GPRS发送数据
在此系列的上一篇文章中，我们在进行硬件分析时看到，CardioMessenger II-S T-Line和GSM版本或多或少地共享相同的PCB设计，从而暴露了微控制器与调制解调器的通信线。在该线路上侦听时，观察到与T线路上相同的连接也就不足为奇了：微控制器要求调制解调器与供应商VPN建立PPP连接。下面的清单展示了这一点。
[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
但是连接似乎失败了，微控制器最终在5分钟后重置了调制解调器并重新启动。这是由于凭据不再有效，无法访问VPN。CardioMessenger II-S GSM上的调制解调器不能像T-Line版本那样“即插即用”，因此无法直接模拟调制解调器。另一个从事该项目的学生Anniken Wium Lie，他专注于网络接口，尤其是GSM接口。他使用OpenBTS建立了一个假站点，并分析了与移动网络有关的安全性问题。这样就可以使用他的设置并将其扩展到不仅可以伪造移动网络，而且可以伪造制造商的服务器。一旦在OpenBTS上启用GRPS，HMU就会收到IP，从而MIPCALL成功。毫不奇怪，微控制器发出的下一条命令要求将套接字打开到与T-Line版本相同的IP（但端口不同）。
[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
知道了这一点，我们设置了具有正确IP的ubuntu VM，并在端口2323上侦听（使用简单的nc -lv 2323）。设置如图2所示。
图2：仿真网络的网络图
作为仿真结果，HMU能够使用服务器打开TCP套接字，然后使用该MIPSEND命令向其发送数据。与T-Line版本一样，它先发送凭据（也恰好与用于连接VPN的凭据相同），然后发送数据。
[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]
通过短信发送数据
GSM版的CardioMessenger II-S还使用SMS将数据发送回制造商。可以通过使用伪基站或通过窃听与调制解调器的通信来收集此数据。我不会再谈论移动网络部分，但我鼓励您阅读Anniken的著作。
捕获SMS类似于捕获使用GPRS发送的数据。唯一的区别是它是随机发生的，并且需要长时间监听。在48h的监听期间收集了56条SMS。下面的清单显示了这种窃听。
[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]
即使乍看之下，SMS的数据似乎不同，这是因为我们看到的实际上是一个SMS PDU，但是其内容仍然使用与我们在下一篇文章中看到的相同的协议。我们还可以注意到，同一条SMS在这里发送了两次。
3.分析总结
在这个阶段，我们成功地从CardioMessenger II-S T-Line和GSM版本中成功提取了数据，模拟了前者的调制解调器和后者的后端服务器。此外，我们还通过SMS发送了一些其他数据。获得数据很好，但是我们还没有真正理解它。在下面的分析中，我们将对其进行分析和逆向使用了制造商从哈医大到后端服务器发送数据的专有协议。
0x02 对HMU专用协议的逆向分析
在上一部分中，我们利用设备与后端服务器之间缺乏相互身份验证的优势，通过模拟调制解调器或后端服务器从家庭监视单元中提取了数据。我们发现设备在发送一些原始数据之前首先要对后端服务进行身份验证。在本文中，我们将对用于发送数据的专有协议进行逆向，然后使用此知识来解密我们提取的信息。
1.对协议进行逆向分析
在深入分析数据之前，我需要提供更多有关为什么我们开始进行二进制分析的详细信息。当我收集这些二进制文件时，我还没有固件（实际上甚至还不确定要在某个时候获得它），因为我准备将连接器焊接到板上获取。因此，我决定仅通过分析获得的原始数据来尝试理解协议。
二进制分析
我们首先可以查看数据是否以某种方式进行了编码，压缩或加密。为此，strings实用程序非常方便，可以检查数据中是否有任何ASCII文本。在这种情况下，什么也没给出。我们还可以binwalk用来查看二进制文件中是否有任何已知的头文件（例如压缩文件），但是在这种情况下也没有结果。最后，我们可以计算数据的熵，以了解数据是压缩的还是加密的。
$ cat hex_data.txt | xxd -r -p | ent Entropy = 7.926409 bits per byte.
如上面的清单所示，熵非常接近每字节8位，这意味着它要么是随机数据（那时候我不能排除）要么是加密数据。以我的理解，可以使用该通信通道发送三种数据：
· 患者资料
· 与软件更新或HMU配置有关的通信
· 日志
但是，我当时不太可能发送患者的数据，因为我们没有与HMU连接的起搏器。我的猜测主要是在日志上，因为HMU手册中从未提及“ OTA”更新机制。
在计算机模拟调制解调器的过程中，从那里通过HMU的48小时监视会话收集了更多数据样本。这样，我既有来自同一会话的数据（即与HMU一起发送，则可自行重启进程），也有来自不同会话的数据（即手动重启设备）。在下面的列表中显示了在不同会话中捕获的数据，并且可以清楚地看出，它不是完全随机的！
05072e00000d[REDACTED]08090d909787d0c71d... # session 1 (msg13) 0502fe000000[REDACTED]0802b5742b63f5343d... # session 2 (msg1) 05030e000001[REDACTED]080d4caa019dee6028... # session 2 (msg2) 05030e000002[REDACTED]080db29ad304f90ffe... # session 2 (msg3)
的确，如表1所示，前12个字节显然不是随机的，而是很可能属于首部。但是，它似乎没有遵循任何已知协议。
基于该表，我对协议头做了以下假设：
图1：专有协议头的猜测
除了潜在的填充数据之外，我们在这里可以得出的另一个观察结果是，数据包的潜在长度（字节2和3）始终等于14模16（并扩展为6模8），换句话说，表示数据很可能是使用块密码（例如DES，3DES，AES或Blowfish）加密的，它们均具有64位或128位密钥。
我对这一发现很有信心，但有一点困难：即使算法是DES，对我来说也很难对个人计算机上使用的密钥进行暴力破解。幸运的是，我很快就接触到了固件，并且能够继续分析。
使用Ghidra逆向分析
这是我第一次必须处理嵌入式设备的固件，而论文的截止日期临近。幸运的是，我在学校里有一个关于微控制器的入门实验室，在项目的这个阶段中，我非常依赖它。
设置Ghidra
为了与我的项目目标（仅使用COTS设备和软件）保持一致，我决定选择Ghidra作为逆向工具。Ghidra于2019年4月开始被NSA在GitHub上开源，这是我开始从事固件工作的一个月。Ghidra的一个明显好处是，它被称为等效于IDA的开源工具，但另一方面，当时可用的文档和教程很少。我必须说，Ghidra非常人性化，完全符合我的需求。
提醒一下，在本系列的第二篇文章中，我们设法转储了部分内存。因此，下一步就是将这些二进制文件加载到Ghidra中，并且像往常一样，在微控制器中，可以使用内存映射在数据表中找到此信息。对于AT91RM9200，这可以为我们提供：
· 引导加载程序：0x0000 0000
· SDRAM：0x1000 0000
· 闪存：0x2000 0000
另外，由于有了数据表，我们知道我们正在面对ARM v4t，而且这是很少的字节序。为了进行设置，我遵循了Travis Goodspeed的这个Wiki，以获取GitHub上可用的项目md3801toools，这被证明是非常有用的。
寻找感兴趣的函数
鉴于我只有不到3周的时间来完成我的项目，我知道不可能对固件进行彻底的分析，因此我决定对用于与之通信的专有协议进行逆向后端服务器。为此，我们可以利用固件中日志/调试字符串的用法。例如，对RAM或Flash的字符串输出上的“ get”进行grepping处理，将在下面的列表中给出有趣的结果：
$ cat sdram.img | strings | grep -i "get" ... Error: GetContainerFromGroup: sanity check failed Error: GetContainerFromGroup: CRC error in msg container GetDataFromMessageLayer sanity: status not OK Wrong frame ID in GetDataFromMessageLayer CRC check in GetDataFromMessageLayer GetDataFromCompressionLayer sanity GetDataFromEncryptionLayer: too many padding bytes GetDataFromTransportLayer sanity CRC check in GetDataFromTransportLayer GetDataFromTransportLayer:start TransportLayerToFifo: GetDataFromTransportLayer() GetDataFromEncryptionLayer:start TransportLayerToFifo: GetDataFromEncryptionLayer() GetDataFromCompressionLayer:start TransportLayerToFifo: GetDataFromCompressionLayer() GetDataFromMessageLayer:start TransportLayerToFifo: GetDataFromMessageLayer() Get Container from Group:start ... GetDataFromEncryptionLayer: wrong ID byte (%02Xh): expected TRIPLE_DES_CBC (%02Xh) or AES_CBC (%02Xh)! GetDataFromEncryptionLayer: wrong ID byte (%02Xh): expected DES (%02Xh), TRIPLE_DES_CBC (%02Xh) or AES_CBC (%02Xh)! ...
这些不同的字符串确实证实了我的想法，即这里确实使用了专有协议。获得字符串很不错，但是现在我们需要转到相应的代码。为此，我们可以使用Ghidra的“显示引用”函数（右键单击存储字符串的地址>引用>显示对地址的引用）。在与与加密错误相关的字符串相关的字符串上应用后，我们得到一个大函数（实际上有两个函数：GetDataFromEncryptionLayer和PackToEncryptionLayer）。使用Ghidra的反编译器，我们可以看一下重构的C代码，其中包含一个有趣的模式：
int var;
FUNCTION_P(start_string_A);
var = FUNCTION_A(something);
if (var == 0) {
// Do something
}
else {
FUNCTION_P(error_string_A);
}FUNCTION_P显然是“类似打印”的函数，而FUNCTION_A是在start_string_A和error_string_A中引用的函数。图2显示了反编译代码的各个部分，其中最重要的函数和变量已重命名，并带有注释以突出显示协议的不同层。
图2：反编译的PackData函数
可以重复此过程以标识固件中的更多函数，从而更好地理解代码。我不会在这篇文章中提供更多细节，但是论文中提供了更多信息。
综上所述，我们可以确定以下内容：
· 负责打包数据的一般函数（其代码在图2中部分暴露）
· 处理每一层封装的函数：
· PackToMessageLayer
· PackToCompressionLayer
· PackToEncryptionLayer
· PackToTransportLayer
· 使用的压缩格式为“deflate”，这是RFC 1951中定义的“无损压缩数据格式”。
· 使用的加密算法：DES，3DES CBC和AES CBC。
如果我们查看PackToEncryptionLayer的一部分（图3），我们会看到用于加密的不同算法，以及用来表示它们的“操作码”：6代表DES，7代表3DES CBC，8代表AES。
图3：反编译的PackToEncryptionLayer函数，AES CBC部分
有了我们掌握的新信息，我们现在可以全面了解此处使用的协议，如图4所示：
图4：通信协议数据包的详细结构
2.数据解密
调制解调器和GPRS数据
现在，我们有解密从HMU提取的所有数据，除了AES密钥。有了固件，我确信我能理解密钥的来源。如图4所示，可以在PackToEncryptionLayer函数中标识该密钥，因此可以看到它的来源，我这样做了。我还编写了一个python脚本来自动化数据分析过程。
我还不能放弃，因此决定“强行使用” AES密钥。我的推理如下：“鉴于板上的组件，必须在执行加密之前的某个时刻将密钥加载到RAM中，因此，如果我在执行PackToEncryptionLayer函数之前设置一个断点，并转储RAM此时，必须在其中包含AES密钥。如果在其中，那么我只需要尝试所有可能的键，对于2MB RAM来说就是……2097152键，即使在使用python的个人笔记本电脑上，也可以测试大约200万个键。”
但是下一个问题是：我们如何才能检测出正确的密钥呢？因此，到那时我们知道压缩层已封装在加密层中。我们还知道，压缩层的数据将以一个已知的头开始：（0x9F压缩层的“操作代码”）+ 0x1F8B（gzip文件的头）。因此，我在自己的脚本中实现了这一点。出于好奇，我直接查看代码，将获得的密钥与我发现的密钥进行了对照，结果是相同的。我仍然不确定为什么我第一次错了，后来发现我忘记了考虑字节顺序…
无论如何，我对我的脚本感到非常满意，因为它可以在不到一分钟的时间内在RAM和Flash中找到密钥（在Flash中要少得多）：
$ python3 cm-decrypt.py validation -tests/file_modem.bin -b validation -tests/ram_dump/ram_b_PackToEncryptionLayer.img ** CM DECRYPT v1.0 ** [*] Opening validation -tests/file_modem.bin... -- FILE INFORMATION -- File size: 2514 bytes (hex: 9D2) File created: Sat May 18 00:42:41 2019 File modified: Sat May 18 00:42:41 2019 File entropy: 7.91 bits per byte [*] Data sanitized! [*] Brute force mode [*] Binary: validation -tests/ram_dump/ram_b_PackToEncryptionLayer.img ** Transport Layer ** Type of packets: 5 (hex: 05) Length: 2478 bytes (hex: 09ae) Unknown: 2 (hex: 02) Packet ID: 0 (hex: 0000) CM ID: [REDACTED] (hex: [REDACTED]) Checksum: 47070 (hex: b7de) [*] Brute forcing the AES key ... [*] 2097152 keys to try .............................................................. .............................................................. .................. [*] Key Found in 37.69s! Key: [REDACTED] Addr: 0x0015d180
处理完解压层后，我们便得到了消息层。但是，该层主要包含日志消息（指示HMU版本和各种网络连接错误）。因为没有起搏器连接到HMU，所以这是意料之中的。但是，该层也将包含患者数据。
$ python3 cm-decrypt.py -k [REDACTED] validation -tests/ file_modem.bin ** CM DECRYPT v1.0 ** [*] Opening validation -tests/file_modem.bin... -- FILE INFORMATION -- File size: 2514 bytes (hex: 9D2) File created: Sat May 18 00:42:41 2019 File modified: Sat May 18 00:42:41 2019 File entropy: 7.91 bits per byte [*] Data sanitized! [*] Decrypt mode ** Transport Layer ** Type of packets: 5 (hex: 05) Length: 2478 bytes (hex: 09ae) Unknown: 2 (hex: 02) Packet ID: 0 (hex: 0000) CM ID: [REDACTED] (hex: [REDACTED]) Checksum: 47070 (hex: b7de) ** Encryption Layer ** Length of the packet: 2466 (hex: 9a2) (div by 16? No) Type of packet: 8 (hex: 08) => AES_CBC Padding: 15 (hex: 0f) IV: 5c8aff9dd3a7bb54f04915bc18e96fbb Key: [REDACTED] ** Compression Layer ** Compression packet: Yes Magic header: 0x1f8b => gzip compressed data, from Unix Entropy: 7.72 ** Message Layer ** Size of the recovered data: 28538 bytes Number of packets: 105 Entropy: 3.94
所有这些操作都是在T-Line版本上执行的，还有一件事需要尝试：在GSM版本上是否使用相同的密钥？因为我们也有一些来自GSM版本的数据，所以我尝试使用从T-Line版本获得的密钥解密它，但是没有成功，这是一件好事！但是，现在知道密钥已存储在闪存中，我们尝试转储GSM版本的固件。如果没有合适的连接器，我们只能使用由两个人将跳线保持在引脚上的方式，而第三个人则要启动OpenOCD“脚本”。几秒钟后，由于难以保持静止，操作崩溃了，我们未能获得完整的固件（我们购买了更好的设备后，我们就获得了固件）。
短信数据
如前一篇文章所述，通过窃听微控制器和调制解调器之间的通信线路，我们不仅可以提取通过GPRS发送的数据，还可以提取SMS数据。仅从SMS中获取有效负载，我们剩下以下原始数据（例如）：
0604cac0441230acf7b8ef24287fa3954ca200afbbdc44c170dbca0f125cda043f298b476f6377c4f22f2 5ff99e976f9b066ca00aa5a25ab8a47218d21f232ed41aed4e0f22f42e6189968d7cf6b965b73a768d7cf 6b965b73a768d7cf6b965b73a7f6beb75a443cfcfe
无需重新进行整个分析过程。在这里，我们似乎正面临采用DES加密的加密层（由开头的“ 06”表示）。我认为我可以简单地使爆破脚本进行DES加密而不是AES CBC。我尝试了一下，但是在尝试了所有键之后都没有结果。那可能意味着两件事：
· DES密钥不在我们获得的部分转储中。
· 加密的数据未压缩，因此不是从魔术头0x091F8B开始的。
考虑到我有AES密钥，我认为第二种选择更有可能，并且还假定我可以使用解密数据的熵而不是魔术头确定密钥。这样做的缺点是必须尝试所有密钥，因此需要更长的时间才能完成。但是，按照上面的解释，这并不是真正的问题，尤其是在部分转储的情况下。因此，该想法是尝试所有可能的密钥，计算解密数据的熵，并始终保持最低的熵（最终约为4）。
这种方法的效果出奇的好：脚本找到了DES密钥，并且我能够解密数据。同样，它是日志消息，主要包含应用程序版本以及错误。使用DES加密这些数据的安全性更多，因为它不需要物理访问设备。但是，我后来在与制造商讨论时获悉，SMS不用于发送患者数据，仅用于发送HMU日志。
3.结论
该项目的这一部分可能是我最喜欢的部分：我一直对密码学感兴趣，并且有能力在CTF之外的其他地方面使用它，这非常令人兴奋。在此过程中，我也学到了很多东西，特别是在逆向方面。
现在，你可能想知道，对于以前的帖子中显示的不同发现，该怎么办？在下面的部分中，我们将看到如何使用获得的信息在HMU和后端服务器之间发起中间人攻击。
0x03 攻击面分析总结
在前面的部分中，我们分析了家庭监视单元的不同范围，并通过利用相互身份验证和硬编码凭据的不足来设法从设备中提取和解密数据。在这部分中，我们将看到如何将当前的漏洞形成攻击链，以修改起搏器发送到后端服务器的数据。
重要的是要注意，本文中描述的攻击在技术上是可行的，但并不实际。这意味着即使可以进行攻击，也不能将其用于伤害患者或危及患者安全。我将在帖子结尾处回到这一点。此外，提出的攻击仅在CardioMessenger II上可行，即使它仍在使用，它也不是制造商的HMU的最新版本，也不再在市场上出售。
1.攻击思路
攻击者的想法是修改起搏器发送到后端服务器的数据，而不触发任何警报/警告系统。以不触发任何警报的方式修改数据本身就是一个挑战，而且由于我无法使用正在工作的起搏器，因此我只能假设具有生物医学知识的人可以弄清楚该如何做。为了能够修改这些数据，有几种方法具有不同的要求。图1以最简单的方式总结了攻击的概念：攻击者的目标是将布尔值从“ true”修改为“ false”。
图1：攻击者的目标
2.方法1：通过JTAG访问
攻击者可以用来实现其目标的第一种方法是利用对设备的JTAG访问，从而控制内存，以便在数据打包和加密之前更改数据。如果我们考虑最简单的情况，即攻击者只想对数据进行一点翻转，那么她将在数据打包之前设置一个断点，对其进行修改，然后继续执行，这样就可以了。
显然，这种方法要求攻击者在整个攻击过程中都可以物理访问设备（更具体地说是JTAG引脚），因此不太实用。
一个可能的解决方案是将Raspberry Pi设置同时插入为JTAG连接器和HMU内的访问点，从而提供“远程物理访问”（一个人可以连接到RPi，然后通过JTAG与MCU交互）。
3.方法2：通过网络访问
第二种方法还要求攻击者至少对HMU进行一次物理访问。攻击者的想法是转储足够的内存以获取设备的密钥。一旦攻击者拥有了这些材料，就可以在HMU和后端服务器之间的任何位置进行攻击，只要攻击者可以拦截流量即可。这里的一个典型示例可能是移动运营商的内部攻击者。
这次，攻击者可以截获通信，使用先前收集的密钥和与上面相同的脚本对其进行解密，修改数据，再次加密和打包并将其转发给后端服务器。
4.方法3：欺骗HMU
最后，攻击者可能想要完全欺骗HMU。这也需要对设备进行物理访问，以收集凭据和密钥。除此之外，攻击者还需要访问VPN，VPN需要有效的SIM卡或电话线（我不确定该设备的版本是否仍在使用中）。这样，攻击者可以连接到VPN，然后再连接到后端服务。然后，她可以使用HMU的密钥将数据发送到服务器以加密消息。这里的困难是整个消息都需要伪造，如果攻击者一开始不知道其外观，这可能是一个挑战。因此，这将需要一些“监视”时间来收集有效消息，以便以后创建看上去有效的假消息。
5.攻击实用性
现在，让我们回顾一下为什么这种攻击不切实际。第一个也是最好的论据是，这种攻击只会使家庭监护无用，即就像根本没有家庭监护，只是让患者和医生相信那样。为了使攻击有针对性地伤害患者（将一个特定的人作为目标），攻击者将需要进行很长时间的攻击，并且依靠“运气”使患者的病情迅速恶化。足以使常规医生的约会无法检测到。
第二点是，攻击需要对设备进行物理访问，对发送到后端的数据有充分的了解，才能在不触发警报的情况下欺骗它并长时间进行攻击以产生潜在影响。从安全研究的角度来看，这增加了攻击的难度和有效性，从而降低了有人甚至尝试将其分开的可能性。
的确，即使这种攻击不能对患者造成任何伤害，它也突出显示了能够信任来自医疗设备的数据的需要。这不是一个容易的问题，当面对起搏器之类的低功率设备时，问题甚至更少。
0x04 研究总结
如引言中所述，此处的想法是介绍可以使用以前的帖子中发现并介绍的各种漏洞来完成利用。更具体地说，目标是表明可以单独链接影响多个漏洞来进行攻击。在与制造商讨论后，我们决定公开我们的发现，明确表明不能将其用于伤害任何患者，这当然是当务之急。
对我来说，从事这个项目是一次很好的学习经历，希望这个博客系列能对我有所帮助。如前所述，我是硬件和嵌入式安全性的入门者（现在仍然是），因此几乎所有工作对我来说都是新的。此外，我有机会与CISA和BSI一起参与了协调披露流程，这对我也是第一次。我很高兴BIOTRONIK认真对待我们的发现并接受讨论：他们为我们提供了对我们报告的详细答复，其中他们解释了为减轻所报告问题而做出的改进。“起搏器黑客计划”的目标是为起搏器生态系统的安全做出贡献，从这个意义上说，这是成功的。
本文翻译自：https://guillaumebour.fr/articles/security_testing_pacemaker_ecosystem/part_3_network_analysis_hmu_data_extraction/ https://guillaumebour.fr/articles/security_testing_pacemaker_ecosystem/part_4_re_proprietary_protocl_hmu/ https://guillaumebour.fr/articles/security_testing_pacemaker_ecosystem/part_5_full_attack_scenarios_implications/如若转载，请注明原文地址：
如有侵权请联系:admin#unsafe.sh