Patch windows app udp safely

安全地改造 Windows App UDP 副本

目标

在不触碰原版 /Applications/Windows App.app 的前提下，审计每台 Mac 上实际安装的版本，为当前用户创建暂存副本，重新定位并验证 UDP 门控，按架构做最小字节修改，仅重签顶层 App，然后验证和交付。用户另行授权时，可在独立暂存副本上把 Metal 显示目标从 28 调到 60；Windows 端只把 Microsoft 对受支持 Windows Server 文档化的值作为依据，Windows 10/11 视为实验。

“低风险”只表示缩小写入范围和提供可恢复路径，不表示零风险。开始前必须完整阅读 risk-and-disclaimers.md，并把与本次任务相关的警告告诉用户。

不可违反的安全边界

• 不使用 sudo，不以 root 运行，不要求 App Management 权限。
• 不写入 /Applications，不原地修改原版，不替换或删除原版。
• 不直接运行本仓库的 auto-patch.sh 或 revert.sh；只把上游项目当研究资料。
• 不使用 codesign --deep，不重签嵌套的 XPC、Quick Look、Framework 或 Helper。
• 不关闭 SIP、Gatekeeper、防火墙或其他系统保护；不全局改变安全设置。
• 不自动删除 com.apple.quarantine。若确有启动问题，先分析来源和影响，再单独征得同意。
• 不修改 CFBundleIdentifier。相同 bundle ID 会产生 LaunchServices、偏好设置和数据容器碰撞，因此不得同时运行原版和副本。
• 不使用已知版本的硬编码文件偏移。每个新二进制、每个架构都要重新定位并验证完整指令。
• 不把 UDP 补丁自动扩大为 60 FPS 补丁；两者分别授权、暂存、验证和恢复。
• 不把 preferredFramesPerSecond=60 描述成服务端必然产生 60 个不同帧，也不把社区推测的注册表值用于 120 FPS。
• 不把“找到第二个 IsWvdConnection 调用”当作充分证据；它最多是定位线索。
• 不迁移、导出或打印 Keychain 密码。数据库检查只输出架构、完整性状态和记录数量。
• 不自动改 Windows 注册表、组策略、防火墙或重启服务；这些属于独立的高权限任务。
• 任一身份、字节、控制流、签名、磁盘空间或运行状态检查不明确时停止，不猜测。

按需加载参考资料

• 任何实际操作前：完整阅读 risk-and-disclaimers.md。
• 定位、写入或签名前：完整阅读 patch-protocol.md。
• 用户要求提高流畅度或 60/120 FPS 时：完整阅读 frame-rate-60.md。
• 用户要复制连接时：完整阅读 data-migration.md。
• 无法启动、没有 UDP、更新或想清理时：阅读 troubleshooting.md。
• 需要解释依据或发布文档时：使用 sources.md 中的原始资料和固定提交。

工作流

1. 明确授权范围

先把用户请求拆成相互独立的阶段：

1. Mac 只读审计；
2. 创建、修改并签名 UDP 副本；
3. 可选迁移连接数据库；
4. 可选只读审计 28 到 60 呈现目标；
5. 可选创建、修改并签名独立的 60 呈现目标副本；
6. 可选只读检查 Windows 主机值；
7. 可选设置或精确恢复 Windows HKLM 值；
8. 可选重启 Windows。

用户明确要求“完成 UDP 改造”通常只覆盖 1–2，不自动覆盖数据迁移、FPS、Windows 写入或重启。Mac FPS 授权不包含 Windows 操作；Windows Check 授权也不包含 Set60、Restore 或重启。执行每个新增写操作前，说明目标路径、将改变什么和恢复方法。若设备受企业管理，要求用户先取得组织管理员授权。

2. 只读盘点

优先运行随附审计脚本；它拒绝 root、不会写文件，也不会输出连接详情：

bash "<本技能目录>/scripts/audit_windows_app.sh" \
  --source "/Applications/Windows App.app"

若已有副本：

bash "<本技能目录>/scripts/audit_windows_app.sh" \
  --source "/Applications/Windows App.app" \
  --copy "$HOME/Applications/Windows App UDP.app"

逐项确认：

• 来源路径由用户确认；存在多个候选 App 时不擅自选择。
• CFBundleIdentifier 是 com.microsoft.rdc.macos。
• 原版签名的 Team Identifier 是 Microsoft 的 UBF8T346G9；否则停止并要求用户核实来源。
• 记录版本、build、架构、主二进制 SHA-256、签名状态、MAS receipt 和 quarantine 状态。
• 原版主二进制仍包含 EnableUdpSideTransport，且目标分支尚未被 NOP。
• Windows App 的所有进程都已退出；检查原版和副本的明确路径，而不是只按显示名称判断。
• 用户目录至少有原 App 大小两倍的空闲空间，足够容纳暂存副本和失败恢复材料。

codesign --verify --deep --strict 可能因证书信任链或原版某个嵌套组件失败。记录原版基线，不把一次失败自动解释成篡改，也绝不通过重签原版来“修复”。

3. 创建暂存副本

把最终目标放在当前用户的 ~/Applications，并在同一文件系统创建唯一暂存目录。最终目标已存在时停止，让用户选择新名字或先明确处理旧副本。不要覆盖。

SOURCE_APP="/Applications/Windows App.app"
FINAL_APP="$HOME/Applications/Windows App UDP.app"
mkdir -p "$HOME/Applications"
STAGE_ROOT="$(mktemp -d "$HOME/Applications/.windows-app-udp-stage.XXXXXX")"
STAGE_APP="$STAGE_ROOT/Windows App UDP.app"
ditto "$SOURCE_APP" "$STAGE_APP"

在写入任何字节前验证原版和暂存副本的主二进制 SHA-256 完全相同，版本、bundle ID、架构也相同。记录嵌套代码签名/文件摘要基线。若复制或校验失败，停止并保留诊断信息；只有确认暂存路径、所有者和前缀后才清理它。

不要重命名内部可执行文件，不要改 Info.plist，不要改 bundle ID。仅改变外层 .app 文件名即可让 Finder 中两个 App 易于区分。

4. 重新发现并证明补丁点

严格按照 patch-protocol.md 对每个实际存在的架构执行以下逻辑：

1. 从不变字符串 EnableUdpSideTransport 反向找到“写入”属性包的函数；排除只读取该键的函数。
2. 找到用户偏好检查和 WVD 身份检查形成的短路控制流。
3. 只选择 WVD 身份检查之后、跳过整个属性写入块的分支；保留用户偏好分支。
4. 验证 fall-through 不只写 EnableUdpSideTransport，还会启用同组的 ICE、鼠标光标和 Core Input DVC 属性；在风险说明中披露这一点。
5. 验证 arm64 是完整的 4 字节 cbz w0, target，或 x86_64 是完整的 2/6 字节 je target；验证跳转目标、前后上下文和实际文件字节完全一致。
6. 从该副本本身的 fat slice offset 和 __TEXT vmaddr 计算文件偏移，不复用任何旧版本数字。
7. 为每个架构生成补丁清单：版本、build、源哈希、架构、虚拟地址、文件偏移、原字节、NOP 字节、指令上下文和验证人。

任一架构无法满足全部证据时，不做“能跑的那一半”。停止并建议使用 Ghidra/Hopper/IDA/Binary Ninja 手工复核，或等待已审计的新版本支持。

5. 只修改暂存副本

先逐字节读取并比较预期原字节，再用 dd ... conv=notrunc 写入完整指令长度，立即读回。arm64 使用一个 4 字节 NOP 1f2003d5；x86_64 对整个 je 指令使用同长度的 90。不要修改分支以外的任何字节。

如果任一写入、读回或反汇编验证失败：

• 不继续签名；
• 不尝试在同一副本上“补救”；
• 保留补丁清单和错误；
• 丢弃暂存副本后，从原版重新复制。

6. 仅签顶层 App

在所有架构验证为预期 NOP 后执行：

codesign --force --sign - "$STAGE_APP"
codesign --verify --verbose=2 "$STAGE_APP"

不要加 --deep。重新检查所有嵌套代码的摘要或 CDHash 与复制前基线一致。顶层签名预期变成 ad-hoc，Team Identifier 可能为空，原公证和开发者身份信任不再适用于修改副本，主 App entitlements 或 hardened-runtime 选项也可能丢失；这不是无害的格式变化，必须向用户明确披露。

再次验证：

• 两个架构的目标位置均为 NOP；
• 除清单中的补丁字节和顶层签名相关文件外，没有意外变化；
• 原版主二进制 SHA-256、签名和文件时间未因操作而改变；
• 嵌套组件没有被重签；
• 最终目标路径仍不存在。

验证全部通过后，才在同一文件系统把暂存 App 移到最终路径。不要删除用户已有数据。清理空的暂存根目录前重新验证其规范化路径位于 ~/Applications/.windows-app-udp-stage.* 且由当前用户拥有。

7. 首次启动和功能验证

只按明确路径启动副本：

open -na "$HOME/Applications/Windows App UDP.app"

验证实际进程路径属于副本，并确认原版没有同时运行。若副本首次启动后看不到旧连接，这是预期的沙盒身份变化，不表示数据丢失。用户要求迁移时再按 data-migration.md 做一次性 SQLite 快照迁移。

检查用户偏好 ClientSettings.EnableAvdUdpSideTransport；仅在用户授权时写入当前用户 defaults 域。该偏好仍是功能开关，不应通过补丁绕过。

运行时使用 Windows App 的 Connection Information 查看 UDP (Private)。不要为了验证而默认调用 sudo tcpdump。如果没有 UDP，先按 troubleshooting.md 区分客户端偏好、补丁、Windows 主机、组策略、防火墙和网络路径。

8. 可选的 60 FPS 阶段

只有用户单独授权时，才完整阅读并执行 frame-rate-60.md。保留已经验证、可运行的完整 UDP-only App，从它创建唯一 stage，并默认交付成另一个不存在的最终路径；不要直接改或替换 UDP-only App。相同 bundle ID 的副本不得同时运行。

对每个架构重新证明实际连接视图传给 setPreferredFramesPerSecond: 的参数确为 28，完整指令、调用上下文和文件偏移均满足 frame-rate-60.md。任一歧义都停止。写入本身只有两个立即数字节，但只能在精确哈希匹配、完整指令匹配且可丢弃的 stage App 中执行；签名前用全文件比较证明恰好只有这两个位置变化。

这一改动只提高客户端 Metal 视图的目标调度频率，不证明 Windows 捕获、编码、网络、解码和呈现链路都达到 60 个不同帧。Windows 检查保持只读且不要求提升；用户另行授权管理员写入时，才按 frame-rate-60.md 记录实际原状态，并为该状态生成两个可直接审阅的短脚本：一个只设置 DWORD 15，另一个只恢复已记录的 DWORD 或删除原先不存在的 value。Windows 10/11 不受该 KB 保证，也不自动重启 Windows。

完成后只重签顶层 App，逐架构反汇编验证 60，确认 UDP 补丁仍在，并对顶层及嵌套签名做与修改前相同的基线比较。验证稳定前保留完整回滚副本。

9. 交付与恢复

交付说明至少包含：

• 原版与副本的绝对路径；
• 原版/副本版本、架构和主二进制哈希；
• 每个架构的原字节和新字节；
• UDP 与 60 FPS 是否分别执行，以及 60 FPS 是否只属于客户端显示请求；
• 签名身份变化以及嵌套代码是否保持不变；
• 数据是否迁移、Keychain 密码是否需要重新输入；
• 所有改过的用户偏好或 Windows 主机设置；若没有，明确写“未修改”；
• Windows 原值记录、设置/恢复短脚本的路径，以及是否实际执行和复核；
• App Store 更新只维护原版；升级后应从更新后的干净原版重新审计并重建副本；
• 恢复方法是退出副本并停止使用/移走副本。删除副本数据目录必须另行确认和备份，不能自动执行。

已验证的 11.3.7 样例只能用于对照

2026-07-20 在一份 Microsoft Windows App 11.3.7 (3040) universal binary 上，原版主二进制 SHA-256 为 ef283a5cd3532a21e8fcca5e003dc55b9fc77b3afeae2796c53b3e21ddef6c07。该样例中 arm64 原指令字节为 e00c0034、x86_64 为 0f84c5010000，分别替换成 4 字节 ARM NOP 和 6 个 x86 NOP。

这些数值只能帮助检查分析是否合理，绝不能作为另一个下载、build 或未来版本的写入依据。即使版本号相同，也先核对完整源哈希并重新计算偏移。

同一台机器后来在已验证的 UDP 副本上单独完成了 28 到 60 的 Metal 常量修改；对应哈希、完整指令和偏移只记录在 frame-rate-60.md 的受限样例中。不得把 UDP 样例与 FPS 样例的哈希或阶段混用。

引用

引用清单、访问日期和各来源用途见 sources.md。本技能主要参考 winapp-udp-unlock 项目 及本次审计所对应的固定提交 0865ba2，并结合 Apple 的代码签名/沙盒文档、Microsoft 的 RDP 传输策略文档和 SQLite Online Backup API 文档制定防护流程。