文章总结： 本文介绍XProxy安全工具的设计与开发思考，作者分享了使用AI辅助编程（VibeCoding）从零构建该工具的经验。XProxy基于Kotlin开发，核心模块包括Proxy、Fuzzer、Kits、Codec及MCP，支持HTTP/2、WebSocket等协议。文章还总结了AI辅助编程的实践经验，强调模型能力快速进化、任务拆分、需求准确描述等要点。 综合评分： 84 文章分类： 安全工具,AI安全,安全开发,实战经验
XProxy 的设计与思考
原创
medi0cr1ty medi0cr1ty
Medi0cr1ty
2026年9月6日 20:11 浙江
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
Author: @TheKingOfDuck @medi0cr1ty
仓库地址:
https://github.com/XSecurityCN/XProxyhttps://github.com/XSecurityCN/xapp-store
01
写在前面
早在 Burp Suite 1.7 的时代就想过复刻一个开源、免费的版本出来，奈何 Burp 的混淆实在太恶心了，能找到的最老版本 1.2 也有混淆，实在无力实现这个庞大的逆向工程。直到去年 9 月左右，在 Cursor 上第一次感受到 Vibe Coding 的力量，当时正在尝试用模型辅助还原 Burp 的混淆代码，受制于当时的模型能力，几轮尝试下来结论是少量逻辑的片段还原尚可，作为完整的工程项目还原距离还很遥远。即便是今天的sota模型能力再倒回去看，仍是一个大型复杂的工程，token成本不是个人项目能承受的。
既然逆向还原这条走不通，那么是否可能自己造一个呢？转机在去年国庆期间，没出去玩，在群友推荐下买了个中转站的GPT的Pro套餐，9.9一个月，套在opencode里面结合superpower用，写出来的工程质量可以说超过我看过的80%以上专业研发的水平，由此很快搭建了现在XProxy中Proxy和Fuzzer两个模块的骨架。
02
项目介绍
为什么选择 Kotlin，以及 XProxy 和 XServer 的关系
国庆期间开了三个项目，一个是哈曼卡顿 4 的智能化方案 HomePlay，一个是 XProxy，还有一个是 XServer。HomePlay先做的，Android项目，模型默认推荐了Kotlin，Agent边写，人边学，这语言的语法足够简洁，写起来比较像 Python，另一方面它又保留了 JVM 和 Java 生态的能力，很多现成的网络库和工具都可以直接复用。当然还有一个很重要的原因，就是名字好听，所以 XProxy 最后用了 Kotlin。
在以往安服生涯中总结出来的一个重要结论：
扫描能力和本地手工测试应该尽量分开。
本地的 XProxy 更适合做抓包、改包、重放、调试这一类手工测试，而大量扫描、批量请求之类的事情应该交给云端的 XServer 去做。可以降低本地出口被封的概率，减少扫描带来的性能开销。所以未来 XProxy 的插件仓库中也不会允许有大量扫描行为的插件存在的(比如shiro key爆破)
XServer 目前完成度还很低，所以没一并开源，它的主要参考了我之前 rcefuzzer 的一些思路，不过从整体规划上XProxy 和 XServer 最终应该是互补关系，一个本地，一个云端。
XProxy 的几个核心模块
XProxy 非常轻量，核心功能主要就是 Proxy、Fuzzer、Kits 和 Codec，另外原生提供了 MCP。模块之间支持相互联动，比如 Fuzzer 可以使用 Codec，Xapp 可以处理 Proxy 流量，也可以调用 Fuzzer 和 Codec，而 MCP 又可以把这些能力暴露给外面的 Agent。
Proxy
Proxy 是整个项目的基础，目前支持了HTTP、HTTPS、HTTP/2、WebSocket、SSE 等不同类型的流量的 MITM 。
对不同协议的支持整体上是数据模型统一，底层的协议实现保持独立。底层根据协议保留各自的处理逻辑，上层再通过统一的 HTTP Message 进入 History、Target、Fuzzer、Kits 等模块。这样做的好处是上层功能不需要关心当前流量到底来自 H1 还是 H2，但底层又不会因为一个过度设计的抽象层而丢掉协议本身的特性。
Fuzzer
Fuzzer 可以理解为这个模块将 Burp 的 Repeater 和 Intruder 的组合在一起的产物，早期想抄 yakit 中 fuzztag 的作业，这个设计我很喜欢，但是每次相同的爆破动作还是需要配置不同的tag和字典等，所以这里选择了另一个线路，走trubo intruder一样的线路，相同的攻击动作配置一次后保存成模板的script，后续同类任务添加一下占位符就可以开冲。
Fuzzer中“请求编辑”和“请求执行”尽量拆开了。UI 更偏向于维护请求和任务状态，真正负责发送请求的是 Runtime，它根据当前协议和传输方式去选择对应的执行路径。这样一个简单的请求和一批 Payload 的攻击任务，最终都可以抽象成类似的执行过程：输入 Request，交给 Runtime，拿到 Response，再生成 Result。 举一个具体点的例子，如果想复用http2长链接的特性，提高爆破的效率，这个方案能支持。
Kits
Kits 是 XProxy 的插件化的直接体现，插件统一叫做Xapp。通过 Jython 和 Kotlin/Java 环境连接起来，并提供了多种事件触发入口。代理流量经过 XProxy 时，Xapp 可以在对应的生命周期节点参与处理，例如on_proxy_http_message、请求发送前和响应返回后等事件。这样插件只需要关心“什么时候被调用”和“调用以后想做什么”。
比如下面xapp去重后的流量(method + protocol + host + port + path),命中请求方法是GET，响应状态吗是200或者204，请求类型是json或者text的，路径是/api/开头的流量，进入处理逻辑。如果是 Burp 的插件实现，光过滤出目标流量，就需要额外再写几十行代码，加上自己写去重，缓存逻辑等，几百行代码就过去了。
@MatchMethod("GET")@MatchStatus(200, 204)@MatchMimeType("json", "text")@MatchPathRegex(r"^/api/")defon_http_message(ctx): if ctx.response_contains("debug"): ctx.log("api debug marker found: {}".format(ctx.url))
Codec
Codec 则基本就是参考 CyberChef 的思路，把各种数据变换能力独立出来。Base64、URL Encode、Hex、Hash、AES、JWT Payload 等操作可以单独使用，也可以组合成 Recipe，更重要的是这些能力不只存在于一个页面里。Xapp 可以用，Fuzzer 的右键菜单也可以联动使用。
参考proxy部分的第一张图，codec里面配置好的tab是可以和其他模块动态联动的。
MCP
在写一个 ai 相关功能 tab 和提供mcp之间，毫不犹豫的选择了 MCP ，专业的事情交给专业的人干，这里再浪费时间做一个chat入口出来，并不会让体验变得更好，纯浪费时间，这里提供了opencode，codex，claude 三个agent的便捷配置命令。
03
写XProxy这一年，我对VB的一些经验
从最初 9.9 元的 GPT Pro开始，后面 XProxy 基本就没再吃过什么特别好的 Token，基本都是薅社区的免费 Token。这个项目就这么一点点写到了现在，从早期的 Proxy，到后面的 Fuzzer、Kits、Codec，再到 HTTP/2、WebSocket、SSE、MCP，很多东西都是在真正使用的过程中不断补出来的。从 v2026.8.8 之后我一直持续在自己使用，目前也没有再发现什么明显影响我日常使用的 Bug。它当然谈不上和 Burp Suite、Yakit 这种成熟项目比较，但至少已经从“我想试着写一个”变成了“我自己真的会拿来用”。我以为目前的完成度和质量都还算可以，也从一年多写它的身上总结一些 vb 经验分享给大家：
- 模型能力进化很快，glm/deepseek/doubao 可以作为生产力工具在用，乃至于 qwen3.5 27b 低精度的本地模型，放到几年前，都是绝对的生产力工具。不仅是写代码，挖洞也是一样的逻辑，如果你停止思考了，那么什么 sota 的模型都不会让你的代码更像样，也不会让你输出更有意思的漏洞。自己想好了再告诉模型，而不是让模型想好了你来选择。
- 模型内化速度很快，早期还会有各种 loop 插件，superpower 这类 skill，反复强调代码规范等，现在已经完全不需要了。少就是多，学习相关领域的知识，准确向模型说清楚自己的需求才能达成目的。不能上来就让他给你搓一个 burpsuite。 搞不定还用 pua 那种 sx skill。这和让你立刻去挣 1000w，但是又不给任何资源和实现路径有啥区别？
- 清楚自己的能力边界，也要清楚模型的能力边界。能力差的模型 load 太多 skill/mcp 就完全没法用了。将任务做好拆分，比如功能要求和代码规范分成两个任务来做，同时要求会分散模型注意力，占用不必要的上下文。换到人身上来看，你不能要求一个实习生干你自己都无法一次性完成好的项目。
- 模型的知识面是远超任何人类的，很多时候代码不及预期，反复回滚可能并非模型的问题，不妨检查一下是不是自己的需求描述错了，或者验收方式不对。bug多次复现，准确描述后再让模型修改，要避免连续大改项目逻辑。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Medi0cr1ty medi0cr1ty medi0cr1ty《XProxy 的设计与思考》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论