CANoe CAPL脚本测试ECU UDS安全访问随机数重复率

1. 项目缘起：一个被忽视的随机数“幽灵”

在汽车电子控制器（ECU）的诊断与刷写测试中，我们常常会用到UDS（Unified Diagnostic Services，统一诊断服务）协议。其中，0x27服务（SecurityAccess，安全访问）是进入ECU保护功能（如刷写、读写关键数据）前的“敲门砖”。这个服务流程的核心，就是经典的“种子-密钥”挑战-应答机制：测试工具（Tester）向ECU请求一个随机数种子（Seed），ECU生成并返回；测试工具基于这个种子，通过预设的算法计算出密钥（Key）并发送给ECU；ECU用同样的算法验证，匹配则授权通过。

听起来很安全，对吧？问题就出在这个“随机数种子”上。在一次针对某车身控制模块（BCM）的自动化诊断测试中，我遇到了一个诡异的现象：脚本连续运行几十次安全访问，成功率极高，但偶尔会失败一两次。查看日志，失败时ECU返回的否定响应码（NRC）是0x35（Invalid Key，无效密钥）。起初怀疑是算法实现有误或时序问题，但反复核对代码和增加延时都无效。

直到我把所有请求的种子和计算的密钥都打印出来对比，才发现了端倪：ECU返回的种子，竟然出现了重复！在几百次请求中，同一个8字节的种子出现了好几次。而我的测试脚本，对于相同的种子，计算出的密钥是固定的。如果ECU内部生成种子的算法不够“随机”，导致短时间内种子重复，而我的脚本又“傻乎乎”地用同一个密钥去应答，那么当ECU期望一个基于新随机数的新密钥时，自然就会验证失败，返回NRC 0x35。

这个“幽灵”就是随机数重复率问题。它暴露的不仅仅是测试脚本的健壮性问题，更深层次地，它可能暗示着ECU软件中随机数生成器（RNG）的实现存在缺陷。在安全访问这类对随机性要求极高的场景下，高重复率的随机数会严重削弱系统的安全性，为潜在的攻击（如重放攻击）打开方便之门。因此，我们需要一个系统的方法，在CANoe环境中，利用CAPL脚本主动、量化地测试ECU返回的随机数质量，评估其重复率。

2. 测试策略设计：如何科学地“抓取”并评估随机性

测试随机数，不是简单收集一些数据看看有没有重复就行。我们需要一个清晰的策略，来定义“测什么”、“怎么测”以及“如何评价”。

2.1 明确测试对象与数据源

我们的核心测试对象是ECU在响应UDS 0x27服务子功能0x01（requestSeed）时，在肯定响应报文数据域中返回的种子（Seed）。种子长度因厂商和ECU而异，常见的是4字节或8字节。测试时，我们需要确保：

1. 环境纯净：在CANoe中建立与ECU的稳定诊断通信（通常通过ISO-TP层处理多帧），排除网络丢包或干扰导致的数据错误。
2. 协议合规：严格按照该ECU的诊断规范发送请求，包括正确的寻址方式（物理/功能）、PCI填充等。
3. 状态稳定：确保每次请求前，ECU的安全状态是一致的（通常是未解锁状态）。对于有安全尝试次数限制的ECU，需在测试后将其复位，避免锁死。

2.2 设计测试流程与评估指标

一个完整的测试流程应该包含数据采集、存储、分析和报告生成。

数据采集流程：

1. 发送 0x27 01 请求。
2. 等待并接收ECU的响应。
3. 如果收到肯定响应（Positive Response，如 0x67 01 [Seed]），则解析并存储种子数据。
4. 如果收到否定响应（NRC），记录错误并分析原因（可能是上次密钥未过期、条件不满足等），根据情况决定是否继续或重置ECU。
5. 循环执行步骤1-4，达到预设的请求次数（例如N=10000次）。
6. 在循环中，可以加入可控的、微小的延时（如10-50ms），以模拟真实操作间隔，避免对ECU造成请求风暴。

核心评估指标：

• 重复次数统计：统计在整个采集过程中，每一个唯一的种子值出现的次数。理想情况下，每个种子应只出现一次。
• 重复率计算：重复率 = (总请求次数 - 唯一种子数量) / 总请求次数 * 100%。这个值越接近0%，说明随机性越好。
• 分布均匀性观察（辅助）：虽然CAPL进行严格的数学分布检验（如卡方检验）较复杂，但我们可以将种子值转换为大整数，观察其在高位和低位的分布是否均匀，或者简单统计种子中每个字节的0/1比特分布，作为直观参考。

2.3 工具选型：为什么用CAPL而不是外部工具？

你可能会想，用Python写个脚本发UDS请求并分析不是更强大吗？确实，Python在数据分析方面有天然优势。但在汽车网络测试中，CAPL具有不可替代的集成优势：

1. 环境原生支持：CANoe直接处理底层CAN/LIN/以太网报文，集成ISO-TP、UDS等协议栈，无需额外封装和解包。
2. 实时性与同步：CAPL脚本可以精确控制发送时序，并与总线上的其他报文、系统变量、面板控件实时交互，方便构建复杂的测试场景。
3. 工程集成度高：测试用例、脚本、面板、记录配置可以打包在一个CANoe配置文件中，便于版本管理和团队共享。
4. 快速原型验证：对于ECU测试工程师，在已有的CANoe诊断环境中快速嵌入一个随机数测试模块，CAPL是最直接高效的方案。

当然，对于海量数据（如百万次请求）的后期深度分析，我们可以将CAPL收集的原始数据导出为CSV或文本文件，再用Python/MATLAB进行专业分析。CAPL在这里的角色是可靠的数据采集器。

3. CAPL实战：构建自动化测试脚本

下面，我们将一步步构建一个完整的CAPL测试脚本。这个脚本不仅要求功能完备，还要考虑健壮性、可配置性和可观测性。

3.1 脚本框架与全局变量定义

首先，我们定义脚本所需的全局变量、常量和数据结构。使用msTimer来控制请求间隔，使用数组或关联数组来存储种子并统计重复次数。

variables { // 用户可配置参数 const dword gTotalRequests = 10000; // 总请求次数 const long gRequestIntervalMs = 20; // 请求间隔(ms) const byte gSeedLength = 8; // 期望的种子长度（字节），根据实际ECU调整 // 测试控制与状态 dword gCurrentRequestCount = 0; int gTestRunning = 0; // 0:停止, 1:运行中 msTimer gRequestTimer; // 用于控制发送间隔的定时器 // 诊断报文标识符 (示例，需根据实际DBC或LDF配置修改) // 假设Tester发送到ECU的请求ID是0x7E0，ECU回复的ID是0x7E8 const dword cDiagReqId = 0x7E0; const dword cDiagResId = 0x7E8; // 数据结构：用于存储种子和出现次数 // 由于CAPL的关联数组不支持byte数组作为key，我们需要将种子转换为字符串或长整数来作为唯一标识。 char gSeedMap[10000][50]; // 假设最多存储10000个唯一种子，每个用16进制字符串表示，最长50字符 dword gSeedCount[10000]; // 对应种子的出现次数 dword gUniqueSeedCounter = 0; // 当前唯一种子的数量 // 日志与报告 char gLogFileName[64] = "SeedRandomnessTest_"; dword gFileHandle = 0; }

注意：使用固定大小的数组（gSeedMap）存在上限。对于极端情况（唯一种子数超过数组大小），脚本会出错。更稳健的做法是使用CAPL的TestModule或TestUnit特性中的动态容器，或者直接先将每次收到的种子原始数据写入文件，后期再分析。这里为了演示清晰，采用数组方案。

3.2 核心函数：发送请求与处理响应

这是脚本的心脏。SendSeedRequest函数负责组帧并发送UDS请求。我们使用DiagSendRequest函数，它是CAPL为诊断测试提供的高级API，能自动处理多帧传输。

// 发送安全访问种子请求 void SendSeedRequest() { byte requestData[2]; requestData[0] = 0x27; // 服务ID: SecurityAccess requestData[1] = 0x01; // 子功能: requestSeed // 使用诊断API发送请求，目标为默认的诊断请求对象（需在CANoe Diagnostic/Transport Layer配置中设置好） diagSendRequest(requestData); // 或者使用底层报文发送（不推荐，需要自己处理ISO-TP）： // byte msg[8] = {0x02, 0x27, 0x01, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA}; // 示例单帧 // output(cDiagReqId, msg); } // 诊断响应处理函数 // 这个函数名需要与在CANoe Diagnostic Configuration中配置的诊断响应事件名一致，例如 on diagResponse <ECU>. on diagResponse SecurityAccess::requestSeed { byte responseData[64]; dword dataSize; byte seed[8]; char seedStr[17] = ""; // 8字节种子，16进制字符串表示，需要16+1个字符 int i; dword foundIndex = 0xFFFFFFFF; // 获取响应数据 diagGetLastResponseData(responseData, dataSize); // 检查是否为肯定响应 (0x67 + 子功能 + Seed) if (dataSize >= 2 && responseData[0] == 0x67 && responseData[1] == 0x01) { // 提取种子数据 for (i = 0; i < gSeedLength && (i+2) < dataSize; i++) { seed[i] = responseData[i+2]; } // 将种子转换为16进制字符串，作为唯一标识 for (i = 0; i < gSeedLength; i++) { snprintf(seedStr, elcount(seedStr), "%s%02X", seedStr, seed[i]); } // 在现有数组中查找该种子是否已存在 for (i = 0; i < gUniqueSeedCounter; i++) { if (strncmp(gSeedMap[i], seedStr, gSeedLength*2) == 0) { foundIndex = i; break; } } // 根据查找结果进行记录 if (foundIndex != 0xFFFFFFFF) { // 种子重复，计数加1 gSeedCount[foundIndex]++; writeLogEx(gFileHandle, "INFO: Repeated Seed Found! Seed: %s, Count: %d", seedStr, gSeedCount[foundIndex]); } else { // 新的唯一种子，存入数组 if (gUniqueSeedCounter < elcount(gSeedMap)) { strncpy(gSeedMap[gUniqueSeedCounter], seedStr, elcount(gSeedMap[gUniqueSeedCounter])); gSeedCount[gUniqueSeedCounter] = 1; gUniqueSeedCounter++; writeLogEx(gFileHandle, "INFO: New Unique Seed. Seed: %s", seedStr); } else { writeLogEx(gFileHandle, "ERROR: Seed Map is FULL! Cannot store more unique seeds."); gTestRunning = 0; // 停止测试 cancelTimer(gRequestTimer); } } // 记录原始数据到文件（可选，用于深度分析） char rawDataLine[128]; snprintf(rawDataLine, elcount(rawDataLine), "Req#%d, Seed:%s", gCurrentRequestCount, seedStr); filePutString(gFileHandle, 0, rawDataLine); } else { // 处理否定响应或其他异常 writeLogEx(gFileHandle, "WARNING: Non-positive response or data size error. DataSize: %d", dataSize); // 可以进一步解析NRC，例如 responseData[2] } // 更新请求计数，并决定是否发送下一次请求 gCurrentRequestCount++; if (gTestRunning && gCurrentRequestCount < gTotalRequests) { setTimer(gRequestTimer, gRequestIntervalMs); } else { // 测试完成或停止 gTestRunning = 0; cancelTimer(gRequestTimer); GenerateTestReport(); } }

3.3 测试控制与报告生成

我们需要提供开始、停止测试的接口，并在测试结束后生成一份简单的报告。

// 定时器回调函数，用于触发下一次请求 on timer gRequestTimer { if (gTestRunning) { SendSeedRequest(); } } // 开始测试函数 (可通过CAPL面板按钮调用) void StartSeedRandomnessTest() { char fullLogName[128]; datetime now; // 初始化状态 gCurrentRequestCount = 0; gUniqueSeedCounter = 0; memset(gSeedMap, 0, sizeof(gSeedMap)); memset(gSeedCount, 0, sizeof(gSeedCount)); // 创建日志文件，以时间戳命名 now = getLocalTime(); snprintf(fullLogName, elcount(fullLogName), "%s%04d%02d%02d_%02d%02d%02d.csv", gLogFileName, now.year, now.month, now.day, now.hour, now.minute, now.second); gFileHandle = openFileWrite(fullLogName, 0); // 0表示文本模式 if(gFileHandle == 0) { write("ERROR: Failed to create log file!"); return; } // 写入CSV表头 filePutString(gFileHandle, 0, "RequestNumber,SeedHex,IsUnique"); writeLogEx(gFileHandle, "INFO: Seed Randomness Test Started. Total Requests: %d, Interval: %d ms", gTotalRequests, gRequestIntervalMs); gTestRunning = 1; // 发送第一次请求，后续请求由响应处理函数中的定时器触发 SendSeedRequest(); } // 停止测试函数 void StopTest() { if (gTestRunning) { gTestRunning = 0; cancelTimer(gRequestTimer); writeLogEx(gFileHandle, "INFO: Test Stopped by user. Processed %d requests.", gCurrentRequestCount); GenerateTestReport(); } } // 生成并输出测试报告 void GenerateTestReport() { dword i; dword totalRepeats = 0; float repeatRate = 0.0; // 计算总重复次数 for (i = 0; i < gUniqueSeedCounter; i++) { if (gSeedCount[i] > 1) { totalRepeats += (gSeedCount[i] - 1); // 一个种子出现N次，则重复次数为N-1 } } // 计算重复率 if (gCurrentRequestCount > 0) { repeatRate = (float)totalRepeats / (float)gCurrentRequestCount * 100.0; } // 输出报告到Write窗口和日志文件 write("\n========== Seed Randomness Test Report =========="); write("Total Requests Sent: %d", gCurrentRequestCount); write("Total Unique Seeds Collected: %d", gUniqueSeedCounter); write("Total Seed Repetitions: %d", totalRepeats); write("Seed Repetition Rate: %.4f%%", repeatRate); write("\n--- Details of Repeated Seeds (Count > 1) ---"); for (i = 0; i < gUniqueSeedCounter; i++) { if (gSeedCount[i] > 1) { write(" Seed: %s, Occurrences: %d", gSeedMap[i], gSeedCount[i]); } } write("===============================================\n"); // 将报告也写入日志文件 writeLogEx(gFileHandle, "\n========== FINAL REPORT =========="); writeLogEx(gFileHandle, "Total Requests Sent: %d", gCurrentRequestCount); writeLogEx(gFileHandle, "Total Unique Seeds Collected: %d", gUniqueSeedCounter); writeLogEx(gFileHandle, "Total Seed Repetitions: %d", totalRepeats); writeLogEx(gFileHandle, "Seed Repetition Rate: %.4f%%", repeatRate); writeLogEx(gFileHandle, "================================="); // 关闭文件 if(gFileHandle != 0) { closeFile(gFileHandle); gFileHandle = 0; } }

3.4 创建测试面板与集成

为了让测试更便捷，我们可以在CANoe中创建一个简单的面板，放置按钮和显示控件。

1. 在CANoe中插入一个Panel。
2. 添加两个Button控件：
   • btnStartTest：文本为“开始测试”，关联on preStart测量StartSeedRandomnessTest()函数。
   • btnStopTest：文本为“停止测试”，关联on preStart测量StopTest()函数。
3. 添加几个Display或Write控件，用于显示测试状态、当前请求计数、唯一种子数等。这些显示内容可以通过在CAPL脚本中更新系统变量，再在面板控件中绑定这些系统变量来实现。

通过面板，我们可以一键启动和停止测试，并实时观察关键指标。

4. 结果分析与问题深潜：当重复率不为零时

运行脚本，收集了10000个种子后，我们得到了报告。理想情况是重复率为0%。但现实中，我们可能会遇到以下几种情况：

4.1 情况一：极低重复率（如 < 0.1%）

如果重复率极低，比如万分之一，这通常可以接受。这可能是由于：

• 真随机数生成器（TRNG）的固有特性：基于硬件熵源（如电路噪声），理论上可能产生重复，但概率极低。
• 伪随机数生成器（PRNG）的周期足够长：如果ECU使用一个状态空间很大的PRNG（如32位线性同余发生器），在有限的采样次数内，重复概率也很低。

评估建议：可以增加测试次数到10万甚至百万次，观察重复率增长曲线。如果重复率随测试次数线性缓慢增长，符合大空间随机抽样的数学期望，则通常认为随机性良好。

4.2 情况二：周期性或规律性重复

这是更值得警惕的信号。例如，你发现每256次或65536次请求后，种子序列开始循环。这强烈暗示ECU使用的PRNG种子（状态）初始化有问题。

• 根因推测：ECU在每次上电或进入安全访问状态时，可能使用了一个固定值或变化很小的值（如系统时钟的低位字节）来初始化PRNG的状态。导致PRNG的序列周期很短。
• CAPL排查技巧：在脚本中记录每次收到种子时的相对时间戳（timeNow()）。分析重复种子出现的时间间隔是否有规律。如果每次ECU复位后，种子序列都从头开始，那基本可以确定是初始化问题。

4.3 情况三：高重复率或短周期重复

例如，在几千次请求内，就出现了几十次重复，甚至有几个种子频繁出现。这属于严重缺陷。

• 可能原因：
  1. 错误的RNG实现：ECU可能错误地使用了非加密安全的随机函数（如C标准库的rand()），且未正确播种。
  2. 熵源不足：在ECU启动初期，硬件熵源尚未收集到足够的随机性，导致生成的随机数质量差。
  3. 种子缓存机制：ECU可能错误地缓存了最近生成的几个种子，以应对快速重试，但缓存刷新逻辑有bug。
• 安全影响评估：这种情况下，攻击者可以通过有限次数的尝试，收集到所有可能出现的种子，并预先计算好对应的密钥，从而极大降低破解安全访问的难度。

4.4 情况四：测试脚本自身引入的“假重复”

在排查ECU问题前，必须先排除测试脚本和环境的问题：

1. 诊断会话未切换：确保每次发送0x27 01请求前，ECU都处于默认会话（0x01）或正确的非默认会话（如编程会话0x02）。如果ECU停留在扩展会话，可能认为安全访问已在进行中，从而返回固定的错误种子或保持旧状态。
2. 安全访问状态未复位：成功通过一次安全访问（发送密钥）后，ECU会进入解锁状态。在这个状态下再次请求种子，ECU的行为是未定义的（可能返回固定值、NRC或新种子）。我们的测试必须在未解锁状态下进行。因此，脚本需要在每次循环后，发送一个0x27 02（无效密钥）或通过0x10服务切换诊断会话来显式地使安全访问失败/复位。
3. 请求间隔过短：ECU的RNG可能需要时间“冷却”或收集新的熵。如果请求间隔太短（如1ms），可能超过了ECU内部RNG的生成速度，导致它返回缓存值或错误值。尝试将gRequestIntervalMs增加到100ms或更长，观察重复率是否下降。
4. 报文记录与解析错误：确认CANoe的Trace窗口记录的响应报文数据与脚本解析的数据一致。检查DBC/LDF中诊断报文的长度定义是否正确，避免因解析错位导致误判种子重复。

5. 从测试到改进：给开发者的反馈与建议

当我们通过CAPL测试确认了随机数重复率问题后，如何将问题清晰地反馈给ECU软件开发者，并推动解决呢？

1. 提供无可辩驳的数据包：不要只说“随机数会重复”。提供完整的测试报告，包括：

• 测试环境：CANoe版本、硬件接口、ECU软件版本、诊断配置。
• 测试参数：总请求次数、请求间隔、种子长度。
• 原始数据：将记录的CSV文件作为附件。里面包含每次请求的序号、种子值。
• 统计结果：重复率、重复种子的具体值和出现次数。
• 重现步骤：清晰的、可复现的测试步骤描述。

2. 定位问题环节的建议：在报告中，可以基于测试现象，给出可能的问题环节分析，帮助开发者快速定位：

• 如果重复是周期性的：提示检查PRNG的初始化种子和状态更新算法。
• 如果重复是固定几个值：提示检查是否有“安全访问失败后的默认返回值”或RNG模块的硬件故障/驱动错误。
• 如果重复只在连续快速请求时出现：提示检查RNG的熵源采集速率或是否有软件节流/缓存机制。

3. 建议的解决方案参考：

• 初始化优化：建议使用更可靠的熵源进行PRNG播种，如结合硬件唯一ID、上电时间、ADC采样噪声等。
• 算法升级：建议使用汽车行业或信息安全领域认可的加密安全随机数生成器（CSPRNG），如基于AES-CTR DRBG或HMAC-DRBG算法的实现。
• 状态管理：确保安全访问状态机清晰，在未成功验证前，每次请求种子都应触发一次新的RNG调用。

4. 将测试用例自动化集成：将本次编写的CAPL脚本进行封装，可以转化为CANoe Test Module中的一个测试用例。这样，在每次ECU软件迭代的持续集成（CI）测试中，都可以自动执行随机数质量测试，监控重复率指标，防止问题回归。

在我实际的项目经验中，正是通过这样一套CAPL测试脚本，我们不仅复现了现场偶发的安全访问失败问题，更向供应商提供了确凿的证据，最终推动其修复了ECU内部一个在特定看门狗复位路径下未能正确重置PRNG状态的缺陷。这个案例让我深刻体会到，一个好的测试不仅是发现bug，更是穿透现象，定位到设计层级的根本原因，而这离不开精心设计的测试方案和扎实的数据支撑。