[Feature]: 全局热热加载

Related Problem / 相关问题

好的，已删除该段描述。以下是更新后的完整 Issue：

一、背景与现状

1.1 热加载的三种类型与作用域差异

Yakit 中热加载分为三种，其作用域完全不同：

当前已知限制：

• 只有全局热加载可以在 MITM 和 WebFuzzer 同时生效。
• MITM 热加载虽然能实现劫持请求和响应的目的，但它不能像全局热加载那样跨模块复用。
• 这意味着用户在 MITM 中编写的加解密逻辑，无法直接复用到 WebFuzzer 的爆破、模糊测试等场景中。

1.2 当前数据流与函数覆盖情况

目前，全局热加载提供了部分请求方向的加解密函数，覆盖了流程1和流程2：

当前问题汇总：

1. 全局热加载仅覆盖了请求方向（流程1 + 流程2），响应方向（流程3 + 流程4）的函数完全缺失，导致 MITM 界面无法呈现明文响应。
2. 即便 MITM 热加载能实现劫持，但其加解密逻辑无法复用到 WebFuzzer 等模块，用户需在不同模块重复维护相同的加解密代码。

二、功能需求

需求1：补充响应方向的加解密热加载函数

建议新增以下两个全局热加载函数，以实现跨模块复用，注释中直接将函数名嵌入数据流向链路：

（1）hijackHTTPResponse —— 响应解密

// 数据流向: 服务端 → hijackHTTPResponse → Yakit MITM → 客户端
// 职责: 对服务端返回的加密响应进行解密，使 MITM 界面呈现明文
// 作用域: 全局热加载（MITM + WebFuzzer 共用）
function hijackHTTPResponse(response) {
    // 用户自定义解密逻辑
    return decryptedResponse;
}

（2）afterResponse —— 响应加密

// 数据流向: 服务端 → Yakit MITM → afterResponse → 客户端
// 职责: 将 MITM 修改后的明文响应加密后传回客户端
// 作用域: 全局热加载（MITM + WebFuzzer 共用）
function afterResponse(response) {
    // 用户自定义加密逻辑
    return encryptedResponse;
}

补充：现有请求方向函数注释格式（供官方对齐参考）

// 数据流向: 客户端 → hijackHTTPRequest → Yakit MITM → 服务端
// 职责: 对客户端发来的加密请求进行解密，使 MITM 界面呈现明文
// 作用域: 全局热加载（MITM + WebFuzzer 共用）
function hijackHTTPRequest(request) {
    // 用户自定义解密逻辑
    return decryptedRequest;
}

// 数据流向: 客户端 → Yakit MITM → beforeRequest → 服务端
// 职责: 将 MITM 修改后的明文请求加密后发往服务端
// 作用域: 全局热加载（MITM + WebFuzzer 共用）
function beforeRequest(request) {
    // 用户自定义加密逻辑
    return encryptedRequest;
}

期望效果：

• 四个流程覆盖后，Yakit MITM 交互界面看到的请求和响应均为明文，便于测试人员分析和修改。
• 新函数作为全局热加载，加解密逻辑可在 MITM 和 WebFuzzer 间复用。

需求2：解决外部扫描工具复用 Yakit 加密逻辑时的性能问题

问题描述：

在使用 sqlmap 等扫描工具进行自动化测试时，sqlmap 需要复用 Yakit 中已编写的 beforeRequest 加密逻辑，将扫描 payload 加密后发往服务端。如果直接将 sqlmap 的代理指向 Yakit MITM：

• sqlmap 会产生大量请求（少则数千，多则数十万），所有流量都会被 Yakit MITM 写入本地数据库，导致数据库文件急剧膨胀。
• MITM 交互界面需要渲染海量流量记录，界面响应缓慢甚至无响应。
• 扫描流量与人工测试流量混在一起，干扰正常的人工渗透测试分析。

当前平替方案：

为了规避上述问题，目前的变通做法是：

• 在 Yakit 上下游各挂一个 mitmproxy 代理：
  • 上游代理（客户端侧）：实现请求解密 + 响应加密（流程1 + 流程4）
  • 下游代理（服务端侧）：实现请求加密 + 响应解密（流程2 + 流程3）
• Yakit MITM 置于两个代理之间，仅处理纯明文流量，用于人工分析和调试。
• sqlmap 等扫描工具直接指向下游代理，复用下游代理中的加密逻辑发往服务端，流量完全绕过 Yakit MITM，避免涌入数据库。

问题：这套方案下，Yakit 中编写的 beforeRequest 等全局热加载加解密逻辑完全无法被 sqlmap 等外部工具复用，用户需在 mitmproxy 中重新实现一套相同的加密脚本，维护两套代码。

期望改进：

希望 Yakit 能提供一种复用现有全局热加载加解密逻辑的机制，使 sqlmap 等外部工具能直接复用 Yakit 的 beforeRequest 加密逻辑，将 payload 加密后发往服务端，同时外部工具的流量不经过 Yakit 的 MITM 交互界面和数据库存储，避免性能问题。

简单来说：希望 Yakit 的 beforeRequest 等加密能力可以独立于 MITM 交互界面存在，作为一个可被外部工具调用的服务化组件，实现一次编写加密逻辑，Yakit MITM 和外部扫描工具共用。

三、期望的最终效果

1. 热加载函数完整覆盖四个流程，MITM 界面全链路呈现明文。
2. 新增响应方向的函数为全局热加载，实现加解密逻辑在 MITM 和 WebFuzzer 间的跨模块复用。
3. 统一所有热加载函数的注释格式：一行数据流向（函数名嵌入链路中），一行职责，一行作用域。
4. 提供独立的加解密服务机制，使 sqlmap 等外部工具能复用 Yakit 的加密逻辑，同时避免对 MITM 数据库造成性能压力。

Desired Solution / 期望的解决方案

同上

Alternatives Considered / 考虑过的替代方案

No response

Priority / 优先级

High (Urgent) / 高（迫切需要）

Additional Context / 补充信息

No response