在官网上，其实也有对SFD的描述，引用如下：

SFD（车辆诊断保护）是一种基于令牌的访问机制，用于保护 Volkswagen AG 旗下车型对控制单元（设码、适配、参数设置）的写入访问权限。

SFD 的目标：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

为满足法定要求（如 UNECE 规定的网络安全等），SFD 机制应运而生。如需执行控制单元的写入服务或例程，需获取所谓的解锁令牌。在 Volkswagen AG 系统中，令牌的调用基于用户身份，并会与用户相关数据一同记录在案，以便日后追溯车辆上的未授权篡改行为。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

读取服务（例如读取控制单元故障存储器）不受 SFD 保护。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

SFD 的作用方式：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

控制单元的 SFD 解锁由诊断设备在后台自动完成。前提是用户必须在集团零售门户（GRP）中拥有“ODIS”应用程序权限（“机械师”、“服务技师”和“服务顾问”角色已自动包含该权限）。

受 SFD 保护的控制单元可在引导型故障查询（推荐方式）或自诊断模式中手动解锁：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

对控制单元进行写入访问时，诊断设备会识别到该控制单元受 SFD 保护。控制单元将请求解锁令牌。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

如果用户尚未完成认证，需先在 GRP 完成身份验证。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

诊断设备将控制单元 ID 特征及用户数据发送至 Volkswagen AG 制造商系统，发起解锁请求。 󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

Volkswagen AG 的制造商系统检查请求并授权，然后将一个签名激活令牌发送给诊断设备。同时记录访问信息（用户 ID、VIN、控制单元 ID、时间戳等）。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

ODIS 将解锁令牌导入控制单元。控制单元检查解锁令牌，最多允许访问相关诊断对象 90 分钟。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

上面的说完了，大体上已经有相对全面的理解了，我知道还有人对一些深层次的控制策略心存好奇，本文将对SFD2.0 的目标与总体策略、车内（客户端）工作逻辑、服务器端（OEM/厂商）加解密与授权流程、SFD2 的核心功能点、常见实现细节和大家详细分享。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

一、SFD2.0 的目标与总体加密/授权策略（高层）

1. 目标
   • 防止未授权/未审计的诊断操作（coding、adaptation、actuator tests、flash/写操作等）。
   • 确保对 ECU 的软件写入与关键配置变更只能由被授权的实体在受控范围与时间内执行（可追溯）。
   • 满足法规合规（UNECE R155 网络安全、R156 软件更新管理），并支撑 OTA/远程更新的可信链路。
2. 总体策略（策略性要点）
   • 网关/安全模块（SGW/SFD模块）作为策略执行点
     
     ：把对诊断命令的放行/拦截放在车内安全网关或专门的 SFD 模块上。
   • 基于令牌/授权票据（token/permit）
     
     ：诊断工具必须先通过 OEM/授权服务器获取时间/作用域受限的令牌，令牌被绑定到 VIN / ECU 列表 / 操作范围。社区工具与厂商设备也都以 token 流程为核心。
   • 链式信任与签名（chain-of-trust）
     
     ：任何允许闪存/写入的固件包或授权票据都必须由 OEM 私钥签名；车端使用预置的公钥或证书链验证签名。
   • 最小权限与时间限制
     
     ：授权通常限定为有限时间窗口（例如 90 分钟的“unlock”会话）并限定允许的操作范围/受保护模块。社区与售后工具的实践也证实了这一点。

二、SFD2.0：车端（客户端）逻辑 — 典型状态机与校验点

（车端通常以 SGW / SFD 模块+ 各受保护 ECU 协同实现）󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

1. 初始/锁定态
   • 诊断端对受保护模块发起敏感请求（e.g. coding/flash）→ SGW 拦截并返回 “SFD locked / challenge required”。
2. 挑战/请求授权
   • 诊断工具（或车厂诊断 ODIS）发起 SFD unlock 请求（含 VIN、目标模块 ID、请求操作类型、工具证书/身份凭证）。
   • 如果是离线 token 流程（第三方售后工具那类），会发送一个请求字符串/挑战到 OEM 服务器或使用已有 token。
3. 接收授权票据并本地验证
   • 车端（SGW）接收来自诊断工具/服务器的签名票据（signed token），校验签名、时间戳、nonce、目标 VIN/模块是否匹配、票据范围（哪些 ECU、哪些操作）和有效期。
   • 验证通过则将 SGW 状态置为“临时放行”或更新诊断过滤规则（Diagnostic Filter），并记录审计日志（操作者 ID、时间、受影响模块、操作类型）。
4. 会话/操作
   • 在票据有效期内，允许对受保护 ECU 进行 flashing/coding/特定适配等操作。所有写操作在 ECU 端也要求签名固件或校验链以保证内容完整性。
   • 操作完成或票据过期后，SGW 自动恢复锁定并写入审计记录。社区报告显示 OEM 工具通常授予 90 分钟的窗口（具体由 OEM 策略决定）。

三、服务器端（OEM / 授权服务）
加解密、授权与审计策略（建议的实现/公开推断）

以下是以工程视角、结合公开资料与逆向/社区信息的典型服务器端流程（OEM 后台 + HSM）。

注：厂商内部细节（确切算法、密钥管理架构）通常不公开，下列为公开资料与合理推断的结合（我在每一步会注明“公开可证/社区证据”或“推断”）。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

服务器端主要职责

• 身份/资质验证（工作站/技师/经销商证书）
• 生成并签发受约束的授权票据（token）
• 为固件发布签名（firmware signing）并发布受信任的 manifest/元数据
• 审计、合规与撤销（revoke）管理
• 密钥托管（HSM）与证书生命周期管理（PKI）

典型授权（unlock token）生成流程（步骤）

1. 请求阶段（Workshop → OEM）
   • 诊断工具/工作站通过 HTTPS与OEM 授权 API通信，提交：VIN、请求的 ECU ID 列表、操作类型（flash/coding）、操作者证书/账号、时间戳与 nonce。
   • 服务器端验证请求方凭证（是否属于授权维修站、是否有当前软件/维修授权、是否针对 recall/campaign/authorized  service）。
     （公开说明：需OEM授权工具如ODIS 或授权第三方，如 Carista/Autel）
2. 策略评估与生成票据
   • OEM 
     
     策略引擎决定是否允许（基于策略、车况、是否在召回名单里或是否需要额外人工审批）。
   • 若允许，生成票据（token）：token 通常包含（VIN、受保护模块清单、允许的操作/权限位、有效期 start/end、唯一 id、nonce、可能还绑定 workshop id / session id）。
   • 服务器使用私钥（保存在 HSM 中）对 token 进行数字签名（或者生成带签名的 JWT / CBOR Web Token / 自定义二进制票据）。（国外论坛工具显示 token 为签名数据结构并严格绑定 VIN/ECU）。
3. 传回诊断工具 / 直接下发车辆
   • 签名后的 token 返回给诊断工具，或由服务器通过安全通道直接推送给车辆（视OEM基础设施）。
   • 诊断工具随后将token 透过 OBD/DoIP/USB 发送给车端 SGW。
4. 审计与回溯
   • 服务器同时记录 audit trail（谁在何时为哪 VIN 签发了哪个 token）。该记录用于合规与事后取证。

固件（软件包）签名与分发（OTA / 手工 flash）

• 固件发布端对固件/manifest 生成签名并附上 hash、版本号与可选的白名单 ECU 信息。
• 车端在接收固件前先验证签名（以及签名者证书是否在信任链上），然后才允许写入。此处通常使用     非对称签名 + 对称加密的组合（签名保证完整性与来源，传输层 AES-GCM 等用于机密性）。（UNECE R156 要求软件更新流程的完整审计与安全性）。

密钥与算法（哪些是“可能使用”的公认做法）

• 私钥保存在 HSM（硬件安全模块）中
  
  （厂商生产环境常见）。——公开业界惯例/社区推断。
• 签名算法：
  
        很多现代车厂倾向 ECC（例如 P-256/secp256r1）或 RSA-2048/3072，具体公开细节少见（社区多以“签名 + 时间戳 + nonce”为共识）。（注意：这是合理推断而非厂商官方公开细节）
• 会话加密：
  
        对称加密（AES-GCM）用于诊断会话数据的机密性与完整性保护（如果需要）。
• 证书管理/撤销：
  
   通过 CRL 或 OCSP/在线验证实现证书撤销/失效判断。

四、SFD2 的核心功能（逐项拆解）

1. 诊断请求访问控制（Diagnostic Access Control）
   • 核心：粒度化地限制哪些诊断服务（UDS 服务）可用于哪些 ECU、哪些操作、在什么时间窗口内。
   • 作用：阻断未经授权的适配/编码/写入指令。
2. 签名与完整性验证（Signed Firmware / Manifest）
   • 核心：固件与重要配置文件必须由 OEM 签名、验证签名后才能被写入 ECU。满足 R156 要求。
3. 会话与令牌管理（Scoped, time-limited tokens）
   • 核心：令牌绑定 VIN/模块/工作站/操作类型，并设置有效期与唯一 ID；车端强制校验。社区证据显示 token 机制与时限窗口（如 90 分钟）。
4. 审计与可追溯（Logging / Accountability）
   • 核心：谁在何时对哪辆车做了什么操作必须被记录（用于合规、法务、维修历史追踪）。厂商与第三方工具均强调 audit trail。
5. 策略与黑白名单（Policy Enforcement）
   • 核心：可以基于 VIN、车型、ECU软件版本、地理/法规差异（UNECE 要求）来控制是否允许操作。SFD2 引入与全球法规（UNECE）一致的策略差异化。
6. 支持 OTA 与安全更新（Secure Update Pipeline）
   • 核心：对 OTA 更新流程的端到端签名与验证、以及可回滚/版本管理支持（符合 R156）。

五、已知实践与社区现象（风险、绕过与工具）

• 许多售后/第三方设备厂（Autel、OBDeleven、Carista）已推出“合法授权”或“一次性授权 token”服务，允许 workshop 使用厂商授权流程访问 SFD。
• 国内外一些社区/社群与灰产也有尝试生成离线 token / 模拟授权流程的工具（这类做法存在法律/合规风险）。
• SFD2 
  
  在不同车型/年份的部署不一致：
  部分模块仍使用旧的 Login/legacy security，而关键模块迁移到      SFD/SFD2；这导致研究者在识别哪些 ECU 受保护时需查 ODX/诊断数据库或参考厂商说明。国外有些论坛提供了识别方法（例如 ODX 名称里含 “UNECE” 或查看模块是否报 SFD 锁）。

六、服务器端—典型加解密流程

（按消息序列列出，便于实现/仿真）

• Workshop Tool（W） → OEM Auth Service（S）：HTTPS POST {VIN, requested_ecu_list, requested_ops, workshop_id, cert, timestamp, nonce}

• S 验证 workshop 证书/权限 → S 在 HSM 中生成 token_payload = {VIN, ecus, ops, start, expiry, session_id, nonce}

• S 使用 HSM 私钥对 token_payload 做数字签名：token = Sign_HSM(token_payload)；S 返回 signed_token 给 W。

• VCTool

• W → Vehicle SGW：将 signed_token 通过 DoIP/OBD 发给 SGW（并发起解锁请求）。

• SGW 验证签名：Verify(pub_OEM, signed_token)；验证 VIN/ECU/nonce/timestamps/expiry；若通过，

  更新 diagnostic_filter 允许列表并记录 audit。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

• W 在有效期内对 ECU 执行 flash/coding；ECU 在写入前再次校验固件签名（固件由 OEM Server 事先签名）。

• 操作结束/expiry：SGW 解除放行并上报审计记录到 OEM（可选上报/同步）。

七、合规与工程实施建议

• 若你是授权维修企业，比如4S：使用 OEM 正式授权路径（ODIS/厂商 API）并保留完整审计日志，避免使用非法/未授权 token 服务以免承担合规/法律风险。

• 若你是安全研究者：尽量使用白盒/合作方式获取 OEM 资料或在合法范围下用逆向数据做实验；关注 UNECE R155/R156 的具体要求（日志保存、事件上报、软件更新流程记录）。

• 对抗操作风险：车端应实施短时限 token、绑定 VIN/ECU、nonce 与强签名，服务器端要用 HSM 管理私钥并实现可撤销/黑名单机制。

• 可视化与自动化：建议在 workshop 工具中把 token 生效时间、作用域与审计条目显式展示给技师与车主以提高透明度。

八、哪些是“已确认事实” vs “合理推断/社区证据”

已确认/公开：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

• SFD 是 VW/Audi 的诊断保护机制；

• SFD2 与 UNECE R155/156 有关联（目标是更强的诊断与更新保护）；

• OEM 授权工具（例如 ODIS）能够解锁 SFD；

• 第三方厂商推出授权/token 服务。

社区证据/推断（非 OEM 官方文档）：

• 具体使用哪种签名算法（ECC vs RSA 的版本）

• token 精确结构

• HSM 内部流程细节等

• 这些通常未被 OEM 公开，需要以逆向与国内外论坛工具为参考。

• 对此要保持谨慎。

九、关于SFD1和SFD2.0解锁答疑

1. SFD1.0 vs SFD2.0：

为什么以前能“解锁网关就全车开”？

在 SFD1.0（2020–2022年主流） 时代：

• 网关（例如 J533、J519 等）实现“诊断过滤”（Diagnostic Filter）。
• 一旦通过 OEM 授权（token）解锁网关
  多数下游 ECU 的敏感 UDS 服务都会被网关放行
  例如 Coding、Adaptation、Basic Setting、Parameterization 等。

所以 SFD1.0 时代，网关解锁 ≈ 全车解锁。

2. 为什么 SFD2.0 不再允许“网关解锁 = 全车解锁”？

因为法规要求（UN R155/UN R156），OEM 必须对每个安全关键模块做独立授权。

因此在 SFD2.0 中加入：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

✔每个 ECU 都有单独的授权验证（ECU-internal SFD）

即便网关允许 UDS 服务透传：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

• ECU 
  
  仍会检查自身的 token 或授权会话
• 有些模块使用     本地安全等级（local security level）
• 有些模块会验证     individual ECU signatures
• 有些模块需要     额外 challenge–response（带签名）
• 有些 ECU 甚至要求 在线验证才能写入（软件包/参数化）

这意味着：

SFD2.0 = 网关过滤 + ECU 内置二次防护 + 签名固件管线

3. SFD2.0 的网关“解锁”到底能做什么？

能做：

• 允许诊断设备向下游 ECU 发起受保护服务
• 打开“第一层”安全（像以前      SFD1.0 的流程）

不能做：

• 不能代替 ECU 自己的授权
• 不能伪造写入许可
• 不能绕过 ECU 的签名验证
• 不能写入未签名的参数化数据
• 不能进行 OTA 级别的软件更新

4. SFD2.0 的真正逻辑（非常关键）

SFD2 的 unlock token 是“按模块绑定”的，不是全局的。

token 通常包含字段：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

字段	含义
VIN	仅此车辆有效
ECU list	指定可操作的 ECU（多个，但必须明确列出）
Allowed operations	Coding/Adaptation/Parameterization/Flash
Session validity	一般 30–90 分钟
Nonce + Signature	防伪造、绑定服务器签名

也就是说：

你想操作 7 个模块，就必须请求一个 token，其中列出这 7 个模块。

网关只是验证 token 并放行，但ECU 也会检查 token 中是否包含自己。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

5. 那可不可以“破解网关然后实现全车解锁”？

从安全设计角度：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

不能

原因：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

1. ECU 本地安全检查仍然存在，即使网关放行，它们仍拒绝没有 token 的写入。
2. ECU 
   
   的参数化、flash、编码数据在 SFD2 上必须通过 数字签名验证。
3. 网关不存储 ECU 私钥，也无法伪造 OEM token。
4. 有些关键 ECU（ADAS、动力系统、车身安全）甚至要求 在线授权。

6. 那能否做到“获取一个全车授权 token”？

可以，但必须满足条件：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

1. 使用 OEM 服务（ODIS）
2. 提交授权请求，并明确列出你要访问的全部模块
3. 在服务器批准后获得 token

如果服务器不给你全车权限 -> 就不能通过 SFD2 解锁全部模块。

你手上的第三方工具（如 Autel、OBDeleven、Carista）

它们内部逻辑也是：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

• 向 OEM 授权服务器请求 token
• 但服务器通常只给某几个模块（如编码层级）
• 很难得到“全车辆全模块权限”

7. 最重要的总结（非常关键）

SFD1.0 = 解锁网关-> 全车操作可用

SFD2.0 = 解锁网关只是第一层，ECU 本体仍有自己的 SFD 验证，因此不能实现全车一键解锁

除非：你从 OEM 获得一个包含“所有受保护 ECU”的大 token。
否则：

操作权限是模块级、精确授权，而不是全局开放。

十、车型示例，哪些系统带SFD2.0󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

Audi A6 / A7 C8（2019–2025）使用 SFD2.0 的 ECU 实际列表󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

A6 C8 从 2022~2023年开始逐步由 SFD（V1）升级到 SFD2（V2），重点集中在：

• 网关（CAN 协议的中心）
• 车身稳定系统
• 转向系统
• 驾驶辅助系统的关键 ECU
• 安全相关 ECU
• 高级信息娱乐/远程通信模块

所有允许编程、参数化、匹配的 ECU，只要涉及行车安全、排放、ADAS、网络安全，都会进入 SFD2 覆盖。

10.1 A6 C8 全车最早启用SFD2.0 的“核心 ECU 清单”󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

① 中央网关 & 区域网关（核心） — SFD2 最关键󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

ECU	SFD 类型	说明
A6 C8 主网关 J533 （Diagnostic CAN Gateway / Control Unit “Gateway”）	SFD2	C8 平台最早启用 SFD2 的 ECU，可阻挡全车诊断写入
部分新款采用 Zone Gateway（区域网关）	SFD2	新架构下取代传统网关，必须在线授权

② 车身相关（BCM/后备箱/智能钥匙）

ECU	SFD 类型
BCM1（车身控制模块前部）– J519	✔ SFD2
BCM2（无钥匙进入/防盗）– J393	✔ SFD2（非常严格）
后备箱控制单元 J605	✔ SFD2

③ 组合仪表 / HUD

ECU	SFD 状态
仪表盘 / Virtual Cockpit（J285）	✔ SFD2
HUD 抬显控制器	✔ SFD2（新款）

④ 车道保持 / ACC / ADAS 系统（最严格）

功能	ECU	SFD
自适应巡航 ACC	J428	✔ SFD2
前雷达/ADAS 主控制器	J1121 / J850	✔ SFD2
驻车辅助控制器	J446	✔ SFD2
360 环视摄像头 J928	✔ SFD2
车道偏离摄像头 J949（KAFAS）	✔ SFD2
夜视系统 J853	✔ SFD2（部分车型）

⑤ 刹车 / 稳定系统

ECU	SFD
ESP/ABS（J104）	✔ SFD2
刹车助力系统 J539	✔ SFD2
电子驻车 J540	✔ SFD2

⑥ 转向系统（完全锁定）

ECU	SFD
电动转向 J500	✔ SFD2
后轮转向（四轮转向） J770	✔ SFD2

⑦ 驻车雷达 + 泊车模块

ECU	SFD
APAS/APA 自动泊车控制单元	✔ SFD2
超声波雷达控制单元 J446	✔ SFD2

⑧ 空调 / 舒适系统

ECU	SFD
空调控制器 J255	✔ 部分机型 SFD2
座椅模块（带记忆）	✔ SFD2（座椅防夹+安全）

⑨ MMI 信息娱乐系统

ECU	SFD
主机 MIB3 / MIB3 High – J794	✔ SFD2（强加密）
音频放大器 J525	✔ SFD2（部分）
Telematics 控制器（紧急呼叫）J949	✔ SFD2

⑩ 动力系统（发动机、变速箱）

动力 ECU 是最新加入 SFD2 的区域：

ECU	SFD
发动机 ECU（Bosch MG1/MD1）	✔ 部分年款 SFD2（2023+）
变速箱控制器（DL382/DL501）	✔ 部分 SFD2

总结下：

动力系统最开始使用 SFD1，2023+ 部分车型逐步升级到 SFD2，大众奥迪在这一块的切换并非是一刀切，而是循序渐进的国产，同一年份，出厂时间不同，可能也在具体范围上有所区别。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

A6 C8 上使用 SFD2 的 ECU 范围约 60–80% 的 ECU 已采用 SFD2󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

但不是所有 ECU 都必须，比如：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

电动尾门模块（旧硬件）有概率仍是 SFD1 或无保护󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

简单的照明模块仍可能没有 SFD󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

HVAC 风扇 MCU 多为无 SFD󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

今后的总体趋势是：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

所有与安全、网络安全、ADAS、车身防盗、驾驶控制相关的 ECU 全部必须通过 SFD2 解锁才能执行“写入类操作”。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

---

下面引用来自官网的手动解除操作说明，仅供参考。

备用解决方案：󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

在特殊情况下，如果诊断设备未连接维修站网络，还可通过自诊断模式进行离线 SFD 解锁。此时必须手动从控制单元读取解锁数据，借助这些数据在 Volkswagen AG 制造商系统中生成解锁令牌。同样也要手动（例如通过 U 盘）将该令牌再次复制到诊断设备上。具体操作指南参见下文“自诊断中的手动解锁”部分。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

该流程较为繁琐，并非维修站常规操作场景。如需使用此 SFD 备用方案，请联系您的进口商。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

来自官网说明中自诊断中的手动解锁操作󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

在自诊断模式下，可以在“访问权限”中手动解锁 SFD。

现在，在新打开的窗口中选择 SFD 解锁应用场景。

推荐在线解锁，因为它主要特点是快速且无需额外操作！󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

如上文所述，在线解锁时所有权限都会全自动验证。您无需进行其他设置。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

解锁已激活。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

即使 SFD 解锁有时间限制，我们仍建议在完成工作后，当不再需要 SFD 解锁时，将控制单元重新锁定。

为此，请在访问权限窗口中点击“锁定控制单元”按钮，并再次确认您的选择。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

控制单元已锁定。󠄐󠄹󠅀󠄪󠄢󠄡󠄦󠄞󠄧󠄣󠄞󠄢󠄡󠄦󠄞󠄤󠄨󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄦󠄤󠄨󠄧󠄦󠄢󠄠󠄢󠄬󠅒󠅢󠄟󠄮󠇖󠅸󠆁󠇗󠅸󠆡󠇘󠆭󠆖󠇖󠆄󠆩󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

【完】