0x00 简介

1.本文是由 greenluigi1 在 2022-05-22 发布在其Blog的文章，38.5搬运和翻译，版权归原作者所有，如有侵犯您的原创版权请告知我，我将尽快删除相关内容

2.本人翻译水平有限，有些地方借助翻译软件，如有错误请大家斧正

3.本文排版格式参考：https://github.com/sparanoid/chinese-copywriting-guidelines

0x01 关于这辆车

去年夏天，我购买了 2021 现代 Loniq SEL（译者注：售价约合人民币27.41万元），这是一款不错的油电混合动力车（译者注：拥有混合动力、插电式混动、纯电动三种动力模式），具有相当多的功能，如：Android Auto/Apple CarPlay、手机无线充电、天窗和座椅加热

我非常喜欢这辆车的车载信息娱乐系统 (IVI) ，正如我之前所说的，它有 Android Auto，Android Auto 这在这个价格区间内似乎并不常见，车载系统的动画非常漂亮并且流畅，说明这套系统的 CPU/GPU 并不是形同虚设，也可能是他运行的软件并不是非常臃肿

这辆车就和我之前得到的其他小玩意一样，我想折腾下看最终能实现什么功能

0x02 目标

这辆车的 IVI（车载信息娱乐系统），就像现在的大多数的车型一样，功能类似一个电脑，我的目标就是通过技术手段拿到这辆车的root权限，并且我希望可以在 IVI 上运行我自己的软件，当然，想要破解此类设备的第一步还是搞清楚他的工作原理

我查到一些公开的资料显示：

• 这个 IVI 系统运行的是什么系统？

  IVI 有两个版本，一个是基于Android的版本，另一个是基于Linux的版本

• 这套系统是否已经失陷？

  基于Android 的版本可以通过进入开发者模式并安装自定义APK即可轻松破解（https://forum.xda-developers.com/t/hack-navigation-multimedia-systems-kia-hyundai-and-install-third-party-applications.3892333/）

  基于Linux 的版本目前并没有被破解

• 车机的Linux版本是否也有开发者模式？

  是的，也有工程师模式

0x03 开发者模式

我喜欢开发者模式和测试应用，他们结合一起通常会有许多的乐趣，甚至可能我可能会很幸运的找到一个设置可以连接 SSH 服务器等

我发现我这台车上的 IVI 可以通过软件更新打开开发者模式，快速点击更新按钮的左侧十下，然后点击更新按钮的右侧一下，即可进入开发者模式

如果操作后屏幕并没有变化，多尝试几次，直到进入开发者模式

开发者模式进入前需要输入四位密码，通过官方的开发者文文档我确定密码是2400

进入开发者模式后，我浏览了全部的可用菜单，有大量的调试参数功能和隐藏设置，一些菜单引起了我的注意：

• USB 拷贝

  此页面具有将日志复制到 USB 驱动器或者可用从 USB 更新系统的分支功能

• 模块信息 > ISV 设置

  这个页面有一个ADB TCP选项，以及一个软件测试工具

基于这些功能，我通过我的 USB 驱动器收集了一堆日志，并且尝试用 ADB 连接到IVI

ADB TCP

我将我的手机和 Android Auto 连接来连接IVI的 WIFI，我对 WIFI 进行端口扫描但没有找到可以打开 ADB 的端口

日志

事实证明，这些日志是分析 IVI 系统工作的有效信息

日志显示，系统传输了一个名叫“daudio2.0v_{Date}-{Time}.tar.gz”的 .tar.gz 压缩包到 USB

此压缩包包含许多文件，包含内核日志、Top命令的输出、 logcat 日志和 BlueLink 日志

译者注：

最有意思的日志是logcat 的日志，基本上在 IVI 上运行的每个应用都被它所记录，并被写入到此日志

0x04 破解过程

首先，我知道想进入系统肯定没有打开开发者设置这么简单，我需要实际利用某些漏洞来获取访问权限

我认为进入的最佳方法是对 IVI 上运行的程序进行逆向，但要做到这一点，我需要这些程序的文件，那么最简单的方法就是获取固件更新并解压缩

固件

我浏览了许多日志并发现这台车上的 IVI 运行的是现代的D-Audio2V ，D-Audio2V 是现代Display Audio 操作系统的第二代，用于现代的各类车辆，我发现现代官网上还有一些D-Audio2V 的源码可供下载（https://www.mobis.co.kr/en/tech/rnd.do#open），我看了下，大部分都是此项目的小补丁，用来修复 WIFI 功能的错误D-Audio2V 的固件更新可在更新页面的“显示音频软件更新”下找到，但我买的车型并没有更新，所以我下载了其他车的更新来进行分析

固件在一个.zip压缩包中，其中包含了另外一个.zip压缩包，压缩包内的压缩包名为enc_system_package_{version}.zip，查看system_package zip，似乎包含着 IVI 中各种模块的固件，如GPS 和 HD Radio，以及系统镜像文件本身

这个更新看起来对我的分析很有帮助，但当我试图提取系统镜像文件时发现整个zip压缩包都被加密了

不过我并没有完全气馁，我的电脑上有一些破解压缩包的工具，比如 John The Ripper 和Hashcat ，可以用来暴力破解压缩包的密码，我尝试了八位密码下的所有可能，我的电脑只能在合理的时间内做到爆破八位密码，但没有成功，我还尝试使用了一些密码表，但是也没有成功

破解

这时，我开始思考我或许可以用其他的工具或服务对压缩包进行破解，当我发现https://github.com/kimci86/bkcrack的时候，它可以使用已知明文攻击来破解传统的 zip 加密，这就说明如果我能找到至少 12 个字节的加密 zip 文件中的一个文件，我就有可能对整个 zip 文件进行解密

为了找到与之匹配的文件，我浏览了加密压缩包的文件列表，在 MODEMus 路径下的modem_version.txt （37字节）文件发现了一组很好的攻击对象，因为它的格式是可读的

起初，我在互联网上搜索此文件，希望能找到匹配项，但是出现了许多无法访问的 FTP 连接，所以我用了另一种方法

我希望现代能在他们的 IVI 系统重用调制解调器模块，这样如果我能从另一个 IVI 找到一个未加密的调制解调器更新，我希望能找到一个匹配的 modem_version.txt 文件

从现代的更新站，我发现它有一个特殊的 IVI 更新程序

我安装了 Navigation Updater 并下载了 2020-2021 Hyundai Ioniq Navigation IVI 的最新版本更新包

我打开了更新包中的 system_package tar

里面有一个调制解调器文件夹，里面是一组看起来熟悉的文件，但是modem_version.txt文件的大小错误  

虽然如此，我依然知道里面还有很多其他文件也可能是匹配的，但问题是哪些是匹配的呢？比较这两组文件，有几个大小相同，但不能保证文件的内容相同

幸运的是，zip 压缩包成为了我的希望，我计算了压缩包所以文件的 CRC（循环冗余校验码），CRC 是一种循环冗余校验，zip 提取器程序使用它来验证文件是否正确的解压缩/加密，相同文件具有相同的 CRC ，由于更新文件存储在 tar 压缩包中而不是 zip 压缩包，我将需要的文件从压缩包解压缩并提取了出来

我找到了一组匹配的文件：“partition.mbn” ，我找到了我想要的明文

我用我新发现的纯文本加载了 bkcrack 但是…….运行错误，这是因为什么？

我最终只能把我得到的一些线索都交给它，看看我能不能拿到密钥，但正如我所看到的，工具产生了许多误报，特别是将 bkcrack 限制为至少 12 字节的明文时

但最终尝试这些错误的密钥并没有打开 zip 压缩包

我回到 Bkcrack Github 问题页面 阅读了所有问题，这时我发现需要的“纯文本”不是原始文件本身，而是原始文件的正确压缩版本

我需要弄清楚现代用于压缩此 ZIP 的原始程序和参数

我使用 Windows 中的内置 ZIP 创建器压缩了我的 partition.mbn 文件，但是并没有起到效果，之后，我尝试了 7Zip 中可以使用的所有参数组合

我甚至用 C# 编写了一个程序，用来枚举可能用来创建压缩包的每个组合，但可惜的是没有起到任何效果，我认为现代不太可能用复杂的 Windows zip 程序，因此我将我的视角转到了 Linux

我用安装 Kali 时附带的 zip 命令行工具创建了大量具有各种设置的 zip 文件

之后我逐一检查，在此期间我的 bkcrack 使用了错误的参数，正确的配置是在 zip 中指定文件条目，而我指定的是 zip 本身，在尝试了多种可能的配置之后，bkcrack 找到了正确的一种

我用 bkcrack 找到的 “万能钥匙” 制作了一个 ZIP压缩包

最终

我能够随意地从加密的 zip 中提取每个文件！

bkcrack 还允许您从它找到的主密钥中恢复 zip 的密码，所以我尝试了，但因为算力限制，它无法找到长达 16 个字符的任何内容

但是基于我现在掌握的内容，我提取了 enc_system 文件夹中的 system.img 文件。我从已知的文件中学到了很多东西，比如 Python 和 Perl 是如何安装在系统中的，我认为这对于将来进行的逆向工程意义非凡

我最终找到了应用程序的存储位置并开始对其进行逆向工程。幸运的是，由于应用程序有大量的调试信息被打印到 Logcat 文件中，因此许多重要的功能对于逆向工程来说都是唾手可得的

0x05 网络访问

我还发现这套系统安装了 RTL8152/8153 USB 以太网适配器的驱动程序

我购买了多个基于 RTL8153 的 USB 以太网适配器，希望找到一些开放的端口。我买的其中一个适配器有一个内置的 USB 集线器，它与 IVI 并不兼容，但我买的第二个是直连以太网适配器，它能够成功连接到系统。不幸的是，系统只允许我访问 CarPlay 和 Android Auto 服务器，并没有我所期待的其他可用端口

在对 automotivefw 二进制文件进行逆向工程时，我发现工程模式下的 ADB TCP 设置将 eth0 的 IP 地址设置为 192.168.7.110

通过日志我发现 eth0 的 MAC 地址应该是 “F4:50:EB:2E:58:00” 。假如我可以更改我的 RTL8153 适配器的 MAC 地址，我可以访问该网络，则有望获得 ADB 访问权限

我将我的 RTL dongle 连接到 Kali 虚拟机，并尝试使用 ethtool 烧录一个新的 MAC 地址给它，但很快我就发现 RTL8153 的 MAC 地址无法使用 ethtool 进行编辑

我在网上搜索了可以帮助我解决此问题的工具，但我找到的所有资料都让我认为这些芯片上的 MAC 地址设置无法编辑。经过了数小时的查找，我找到了 Realtek 的 RtPGtool UI 实用程序。据我的初步了解，它像是制造商用来设置这些 USB 以太网适配器的实用程序，包括烧录他们的 MAC 地址。通过阅读相关资料，我还发现其中许多适配器使用称为 EFuse 的东西而不是传统的闪存存储。如果我的适配器用了 EFuse，即使使用了这些工具，也有可能无法对其进行更新，但我仍抱有希望并继续搜索资料

（译者注：这里的 RtPGtool UI 可以理解为类似U盘的批量生产工具）

我花了无数个小时试图查找该应用程序的下载最终在一个中文论坛（译者注：不会是CSDN吧hhh）上找到了此工具的下载方式

稍微研究一下，我就能够成功地将一个新的 MAC 地址刷到我的适配器，即使它使用了 EFuse

网络请求？

我将新刷入的以太网适配器插入汽车的 USB 端口，却发现没有任何变化。我通过 Wireshark 没有看到其他的流量。MAC 地址确实已经更改成功，但它没有给我额外的访问权限，甚至没有 IPv4 地址

我扫描了指向 IVI 的 192.168.7.110 地址，但它只打开了相同的 CarPlay/Android Auto 端口

在此之后，我查看了日志并意识到 eth0 设备是某种内置的以太网适配器，是始终处于离线状态的。因此无论我使用什么 USB 适配器，总是会显示为 eth1。也是因为这点，我意识到 Wi-Fi 密码在生成时被转储到日志中，这意味着我可以使用 Wi-Fi 进行连接。连接到 Wi-Fi 产生了即可获得与以太网适配器相同的访问权限，最终我的笔记本电脑得到了正确的 IPv4 地址

由于网络访问的计划失败，我无法通过逆向工程找到任何后门或容易利用的漏洞，因此我决定尝试对固件进行更新

固件更新

如果我能弄清楚固件更新的所有安全措施，我就可以用我自己的后门修改现有的系统映像，让我拿到 IVI 的全部权限

我在分析固件更新的系统映像中找不到任何的二进制文件。一旦在设置中按下更新按钮，工程模式应用程序和设置应用程序就会使 IVI 进入恢复模式

在固件更新的 enc_system 文件夹中有一个 enc_updateboot.img 文件，我猜这个图像包含恢复系统，不幸的是，7Zip 无法像给 system.img 文件那样提取图像

没有可读的字符串，文件已加密，我猜这就是“enc_”前缀的意思  ¯ （ツ） /¯

再查看更新中的其他文件，发现所有带有 enc_ 前缀的文件都已加密

我又一次被卡住了，如果没有加密密钥，我将无法再了解系统更新过程。我决定复盘我已有的所有信息。我继续对所有可能的应用程序进行逆向工程，复看我提取的日志，并分析我之前下载的 Mobis 网站的开源代码

我没看错吧？

在浏览 Mobis 网站上的源代码时，我搜索了所有 shell 脚本文件。在结果中，我找到了一个名为 linux_envsetup.sh 的 shell 脚本文件

这个文件打开了我的思路，原来这是创建系统更新 zip 文件的脚本

原来我的硬盘上一直都有系统更新的 zip 密码

并且有效的加密方法、密钥和 IV 也在此脚本中

该脚本还反馈出正在使用 RSA 签名，但不幸的是，用于此的密钥不在源代码中

但至少我有加密密钥。为了验证没有其他人已经走到这一步，我用谷歌搜索了加密密钥

Google Git? Apple? Chegg????

事实证明该脚本中的加密密钥是 NIST 文档 SP800-38A 中列出的第一个 AES 128 位 CBC 示例密钥

现代肯定没有实际在生产环境中使用这个密钥，这只是用于测试，对吧？

难道是？不，这不可能……

我可以在 7Zip 中打开文件，但它只有一个损坏的条目

但是，在该文件上成功在 binwalk 上运行并显示出 updateboot.img 文件已成功解密而且其中包含了大量的内容

使用 the -e (extract) argument 我提取了 img 文件，赤裸裸的显示出了一个 Linux 系统配置文件

在 /usr/bin 文件夹中，我发现了一个名为 updateAgent 的二进制文件，看起来很有希望

因为我已经有了 zip 密码和加密密钥，所以我决定寻找签名密钥，幸运的是，他们不仅留下了公钥，还留下了私钥

在搜索了 RSA 之类的关键字后，我找到了公钥，但没有找到私钥

我再次用谷歌搜索了一部分私钥进行查找

Ohhhhh，他们又使用了一个非常普通的密钥。我想知道他们是否根据“ RSA Encryption & Decryption Example with OpenSSL in C ”进行合规操作……

0x06 等待游戏开始

现在我拥有了这所城堡的钥匙，但仍然没有适用于我这辆汽车的固件更新。我不想冒险破坏我新车的主机，所以我等待更新的到来再开始游戏