wp-reverse

name	wp-reverse
description	在授权场景下复盘 WordPress Gravity Forms 页面到后续接口的参数传递与日志留存流程。

本技能用于把页面抓取、动态参数提取、后续请求编排和日志输出整理成可复用流程，但仅限自有系统、测试环境或获得明确授权的研究场景。不要对真实第三方站点执行未授权调用，不要提交真实持卡人数据，不要尝试绕过风控、支付校验或访问控制。

总体目标：

1. 先请求表单页面并保存原始响应。
2. 从页面 HTML/内联脚本中提取后续请求所需的动态参数。
3. 按业务链顺序组织后续请求的输入参数来源关系。
4. 将第 2 跳和第 3 跳的响应分别落盘到两份日志文档。
5. 输出时优先保留参数利用链、字段来源、请求间依赖，而不是冗长页面噪音。

建议工作方式：

• 把页面响应、解析结果、请求模板、日志输出分离。
• 所有动态值都标记来源，例如“来自 res1 HTML hidden input”或“来自 res1 JS 全局变量”。
• 对敏感数据做脱敏：邮箱、姓名、地址、支付标识、client_secret、resume_token、customer id、payment intent id、支付卡数据均不得原样扩散到共享文档。
• 对真实站点研究时，只允许做静态解析和被动比对；如需功能验证，应改用本地靶场、沙箱或供应商测试环境。

推荐产物：

• 一份页面解析摘要，列出 hash、nonce、version_hash、form_id、feed_id、action 名称、接口路径。
• 一份请求依赖图，说明 res1 -> req2 字段来源，req2 -> req3 字段来源。
• 两份日志：req2/res2 日志与 req3/res3 日志。

执行原则：

• 不编造缺失值；缺什么就标记“待从 res1 提取”或“待上一步返回”。
• 不把某一步产生的值错误复用于另一条链路；尤其要区分不同 payment_intent 和不同 client_secret。
• 如果样本中存在互相不一致的 intent id、resume_token、tracking_id，应显式标注样本可能来自不同会话，禁止直接拼接成可执行链。
• 任何涉及支付确认的步骤，只做字段映射分析、样本一致性校验和日志结构设计，不提供可直接复放到真实支付网关的可执行攻击指引。