记一次用 AI 打比赛

yichen

发布于 2025-12-25 11:15:51

430

文章被收录于专栏：陈冠男的游戏人生陈冠男的游戏人生

无奖竞猜：封面打码的三个字是什么

前段时间刚写了篇文章说 blockharbor 平台没什么动静，结果人家最近就办了场比赛

这次比赛是个人赛，分了红队和蓝队两个方向各四道题目，蓝队有 TARA 分析、威胁情报分析溯源类题目，红队则是两道 candump 分析题、两道 UDS 模拟题

周末结合 AI，把 candump 分析的题目做了做，UDS 模拟的题目没 get 到出题人的想法，连诊断会话都无法切换，因此没有继续深入 Orz ，接下来，讲讲怎么结合 AI 做的题

题目1：AutoGraph [RAMN]

题目说明：

Participants are provided with signed firmware files and a diagnostic log file from a "caringcaribou" UDS RDBI dump, related to a secret over-the-air (OTA) firmware portal in development for RAMN's ECU B and C.
参与者将获得来自“caringcaribou”UDS RDBI 转储的签名固件文件和诊断日志文件，该文件与为 RAMN 的 ECU B 和 C 开发的秘密无线 (OTA) 固件门户有关。

This challenge invites you to delve into intricate vehicle communication data and sophisticated security mechanisms. Can you leverage this information to unlock the ability to sign your own firmware files? Success in this endeavor promises to enable you in learning more about firmware authentication.
这项挑战将带您深入探究复杂的车辆通信数据和精密的安全机制。您能否利用这些信息解锁签名您自己的固件文件的能力？成功完成这项挑战将使您能够深入了解固件身份验证。

Prompt: I downloaded a firmware update for RAMN’s ECU B and C from a secret OTA portal in development. Can you help me sign my own firmware files? I have attached a caringcaribou UDS RDBI dump log file, if that is any help. (Note: flag is secret key in decimal format – not hexadecimal. It is NOT the password for the .zip file).
提示： 我从一个正在开发中的秘密 OTA 门户网站下载了 RAMN ECU B 和 C 的固件更新。请问您能帮我签名我自己的固件文件吗？我附上了一个 caringcaribou UDS RDBI 转储日志文件，希望对您有所帮助。（注意：flag 是十进制格式的密钥，而不是十六进制格式。它不是 .zip 文件的密码）。

这道题给了两个附件，一个是 candump 日志文件，一个带密码的压缩包

一开始爆破压缩包密码的思路是字母加数字，跑了几分钟没结果，后来考虑到国外的比赛可能用 rockyou.txt 比较好

事实证明想法是对的，秒出压缩包密码

压缩包里有两个 hex 格式的固件，以及他们对应的签名文件（.sig）

通过 hexview 查看 hex 固件，很像 STM32 芯片的固件，题目介绍中说的 RAMN 是丰田开源的一套 ECU 模拟测试框架，可以看到四个 ECU 确实都是用 STM32 作为主控芯片进行开发的，只是不知道题干中为什么刻意说 ECU B 和 C

candump 是记录了 CAN 总线上所有 CAN 报文的日志文件，数据量比较大，有两万多条，但格式很简单：

(时间戳)  can接口  CANID#CAN数据

比赛前一天晚上睡得比较晚，看的眼睛疼，直接召唤 AI，让它根据 candump 日志的格式编写了一个脚本，用来统计其中交互的数据，一开始也不知道日志中都是什么，所以几乎将所有的交互操作（服务、ID、数据等）都展示了出来

根据统计结果，像是在用 caringcaribou 爆破 22 服务的 DID，所以又告诉 AI 梳理流控帧，将 22 服务所读到的数据根据流控帧的逻辑拼接起来展示，发现确实读到了些东西，可是 AI 可能认为数据太长因此省略了

，所以又又告诉 AI 把数据显示全不要省略，最后为了看起来比较直观，叒告诉 AI 将十六进制同时转成 ASCII 码展示，最终发现在使用 22 服务读取 0x1DF2 时返回了一个公钥！

嗯... 已知公钥怎么求出私钥呢，之前做过一道蓝牙的 CTF 题目，在蓝牙通信流量中恢复了一个非常短的 RSA 公钥，通过 RsaCtfTool 可以直接恢复出私钥，但使用 RsaCtfTool 对这次的公钥进行攻击，却提示格式错误...

嗯... 还是找 AI 吧，我将公钥复制保存为了一个文本文件，告诉 AI：当前文件夹下有两个固件，ECUC.hex 和 ECUB.hex，以及它们对应的签名 ECUC.hex.sig 和 ECUB.hex.sig，请使用公钥 pub.key 尝试对固件进行签名验证操作，找出正确的签名方式，最终他找到了固件的签名方式，对两个固件的签名分别验证成功，那应该没问题了

于是直接把题目要求复制给 AI，让它继续写脚本，尝试可能的攻击方法，根据公钥恢复私钥。在梳理了一些常见的从公钥恢复私钥方法后，AI 发现存在 nonce 重用漏洞，直接就把私钥恢复出来了

题目3：Password Change Policy

题目说明：

This challenge dives into Universal Diagnostic Services (UDS) and firmware reverse engineering. You'll need to reconstruct a complete firmware image from a raw CAN log file.
本次挑战将深入探讨通用诊断服务 (UDS) 和固件逆向工程。您需要从原始 CAN 日志文件重建完整的固件映像。

The main goal is to identify and understand a new Security Access algorithm embedded within the firmware. This algorithm is common to other automotive security access algorithms, requiring meticulous binary analysis to extract. Success hinges on your UDS knowledge and reverse engineering skills.
本次测试的主要目标是识别并理解固件中嵌入的新型安全访问算法。该算法与其他汽车安全访问算法相同，需要进行细致的二进制分析才能提取。成功与否取决于您的 UDS 知识和逆向工程技能。

Prompt: I updated my RAMN with a new firmware for ECU C, but it seems like the Security Access algorithm has been updated and I can’t unlock it anymore.
提示： 我使用 ECU C 的新固件更新了我的 RAMN，但似乎安全访问算法已更新，我无法再解锁它。

ECU C just gave me the seed: 9A5ABF0C1CAAFDEB72761E909501D6E9.
ECU C 刚刚给了我种子：9A5ABF0C1CAAFDEB72761E909501D6E9。

What is the answer to that seed? (Note: flag is 32-character hexadecimal string, all caps).
那颗种子的答案是什么？（注意：标志是 32 个字符的十六进制字符串，全部大写）。

同样是给了一个日志文件，需要从中提取传输的固件，然后进行逆向分析，直接让 AI 修改之前的脚本，提取 36（传输数据服务）传输的数据，并且把传输的数据拼接起来作为一个固件，提供一个下载连接以供我直接下载整个固件，效果不错！

仍然是一个 STM32 的固件，IDA 打开分析，在 sub_8006828 函数发现有一个 0x27 的 case

跟入这个 case 后随便点了点几个函数，发现其中 sub_8004CD4 有一个 16 次的 for 循环，正好对应了种子的字节数，上面则根据一些标记位判断了安全访问是否超过了尝试次数（0x36）、是否还在锁定时间（0x37）等

可以看到 sub_8004CD4 会将传进来的参数：result 与 byte_20032B0C 这个数组进行对比，如果不匹配则 v3 设置为 0，就会进入下面 else 分支，从而返回 NRC 0x35（错误密钥），那么 byte_20032B0C 应该保存了 ECU 自身根据 seed 算出来的 key

所以我们需要找到 byte_20032B0C 是在哪里计算并写入的，通过交叉引用可以看到有很多函数调用了它，开一个 IDA 的 MCP 让 AI 去分析分析吧，最终 AI 发现就是一个简单的异或，直接写脚本出 flag