记录一下我对未来需要实现的一款 RAT 的功能需求 部分功能开发中 主要功能 核心功功能部分，该部分无论如何也必须实现 非交互式Shell命令执行 简易的流量代理(socks) 简易的文件管理(put get delete) 内存加载（pe manual map） 支持内存加载所有常用的系统命令，例如 cmd.exe / net.exe / wmic.exe 等工具，不创建子进程 第三方工具内存加载，需要结合网络文件传输模块，实现文件不落地内存加载，支持 原生二进制(C/Rust) 、运行在运行时(dotnet)、自带运行时(golang)等。 多网络协议支持 利用插件化 或 预编译脚本实现多协议的支持，需要合理抽象出不同通信协议的网络接口。包括但不限于 TCP UDP UDP + TCP header fake (like udp2raw) HTTP / HTTPS TCP over SSL DNS (TXT record) P2P (base udp) 特殊网络协议的恶意利用，直接利用或流量伪装 RDP SSH VNC IM 音视频流量 … 合法服务的滥用 OSS 基于文件下发命令 GitHub API、OneDriver、Azure Function、Dropbox等 自解密 核心 Beacon 加密，执行时动态解密，避免静态特征、字符串特征等。 免编译生成 支持在客户端或网页控制端上根据配置信息进行配置，动态解密预编译的 beacon 后替换上线必须的信息，然后再加密还原，避免每次生成都通过源码编译。 隧道代理 多协议支持的隧道代理，正向，反向，正向反向拼接，串联。 插件化功能模块 除核心功能以外，其他功能插件化加载，共享网络结构体。 加载方式 加载方式需要支持不同使用场景下的不同beacon 最简单就是实现 Loader，将Beacon转成shellcode内存加载，编译为 exe 、dll等，可覆盖钓鱼、攻防等常见场景。 特殊对免杀要求很高的场景需要一对一进行定制，例如在设计时需要考虑功能的模块化，使其模块可自由组装，没有过多的耦合，可跨线程、跨进程通讯。 例如 1.exe 只负责联网与通讯，不执行任何危险操作，2.exe 只负责执行，不联网通讯，两者之间通过多种可能的方式通讯（管道、文件、共享内存、本地socket、消息传递等），避免存在进程链关系。 再比如，支持将模块拆分成，插进开源项目中，保留正常的功能，降低敏感操作的熵值。 桌面感知功能 桌面截图、视频流 剪切板监听 实用功能 代理感知：检测系统代理、浏览器代理、app代理，尝试通过代理出网。 Kill Date 自毁超时删除或拒绝解密：Beacon默认加密，云端下发密钥解密或云端下发完整的beacon，超过特定时间拒绝解密。 BOF 加载器（没用） 内存中 .NET 程序集执行（不建议，高危行为） 令牌窃取/伪造（可用独立程序实现） 进程迁移/注入：需测量测试 UAC 绕过：需大量测试 持久化：开机启动、DLL hijack 启动等。 多服务端支持：支持同时内置多个服务端，每个服务端可选择不同的协议，根据算法在服务端断开后，后续自动选择新服务端。 行为链规避：TODO 设想的其他功能 计划再提供一个 subagent版本，该版本可支持部署在tomcat、k8s等低权限服务上，为主功能Agent 提供网络穿透代理服务。 硬件、内核级持久化：rootkit、BIOS后门、UEFI Bootkit 多人协同 计划三端分离，客户端(Agent)，服务端(Server)，用户端(Client)，大部分功能可通过 webui 去构建，代理部分需思考？或提供独立的 用户桌面端程序（可能会被泄漏？） 基础设施建设 中后期避免使用第三方库减小体积，例如 openssl 、libcurl 等，自己维护依赖库（Agent端）。

前言 本文中总结了我自2023年以来，深度使用大语言模型辅助工作与编码的一些使用经验与技巧。 TL;DR 完善的文档 + 完善的单元测试 + 完善的注释 + 严格的代码审查 + 详细的需求描述，结合少量固定约束提示词，可以实现无负担或少负担的将AI融入编码工作中。 AI编程 迭代到目前，AI编程领域已经出现了Agent、MCP、Codebase RAG等多种增强工具。商业化工具从最初的 TabNine、Github Copilot 到现在的商业化 Cursor、Windsurf、Claude Code，开源 Roo-Code、Continue、Aider等工具。 其中每一个工具我都曾经重度在工作中使用过，基于我过往的使用经验，总结出一些使用技巧。 明确目标 首先需要 明确你的目标 ，以及思考这个目标大模型能否完成？ 模型训练时的数据是有限的，所以首先需要考虑的问题是，你当前需要解决的这个问题，模型的训练数据中有没有可能存在相同或相似的数据？ 什么是擅长的目标？ 例如实现样板的代码、实现通用且常见的算法、解释代码并添加注释、跨语言代码的转换、报错错误信息分析、单元测试生成等。 但是，一但会用到一些小众的库，不常用的API，或是一些比较奇怪的疑难杂症的时候，LLM的会产生幻觉，虚构不存在的库，虚构不存在的API，删除注释代码来尝试解决报错，根据自己的理解创造方法来调用而不是直接调用代码库中已存在的代码块。 那什么是不擅长的目标？ 例如做决策，代码整体的架构设计、创新性的需求实现（网络上没有或很少有类似可参考的实现）、小众语言/小众开发库、包含庞大上下文的代码库分析等等。 你的能力上限决定AI的能力上限，最佳场景是这个功能我自己会写，但是我懒得写，所以我指挥AI帮我完成工作。 如何正确的使用AI 可以把AI根据根据使用场景分成两类，一类是用于从0开始到MVP的一站式服务工具，一类是辅助日常开发迭代的工具。 例如 Bolt、v0 以及“截图转代码”一类的 AI 工具属于前者，Cursor、Cline、Copilot 等等属于后者。 前者的使用逻辑通常会从一个大概的设计或概念开始，使用 AI 快速生成一个完成的基本代码框架，然后快速验证，快速迭代。 而后者通常用于AI代码补全、AI多行修改、基于Agent的重构、生成单元测试和文档，实行结对编程。 AI生成会导致的一些问题 代码库快速膨胀，存在大量过度抽象、过度设计、模块拆分不符等问题，需要人为的进行重构。 AI生成的代码可能会漏掉代码边界的处理部分。 生成代码存在类型错误、类或接口设计不合理。 错误处理 / 异常处理部分很简陋。通常都是直接 catch 所有 Exception。 代码风格差异，无法理解并主动遵循现有代码结构或风格，需要额外的提示或限制。 AI只能看到工程中的一小部分，无法站在全局进行思考与决策。 小白们喜欢吹嘘自己通过 Vibe Coding 实现了xxx项目，上线获取了多少多少的 Star 有经验的开发者使用AI来帮助完成已知步骤，我知道怎么写，但是我希望指导AI快速帮我写完。 而经验不足会导致试图用AI来学习怎么做。 大佬： 快速实现大脑中的原形 让 AI 生成初步实现，然后进行重构 探索已知问题的不同解决方案 自动化各种常规编码任务 小白： ...

在平时的日常测站过程中，经常遇到前端加密相关的对抗，对请求包及响应包进行加密、HASH校验对抗修改，根据加密算法可以分为以下几种： 字符编码：例如base64等。 对称加密：AES、RC4、DES、国密SM4等。 非对称加密：RSA、ECC、国密SM2等。 混合加密：混合多步加密，例如使用AES加密内容 + RSA加密密钥，拼接进SHA1做哈希，AES + base64等。 哈希算法：用于加密解密时的数据校验，例如SHA1/256、MD5、国密SM3等。 对于字符加密，对称加密，部分非对称加密算法： 使用 autoDecode 自带的算法可解。 对于复杂的加密算法，或是不想去逆向算法，不想扣JS补环境： 使用 autoDecode 的接口加解密 配合 JSRPC 提高工作效率。 对于复杂的加密算法，例如需要判断数据包来源时，或是扣出JS函数想直接调用时： 使用Galaxy实现，支持JS 和 Python脚本，可在Hook函数中直接执行JS 函数，也可发起http请求配合JSRPC进行加解密。 扩展插件 autoDecode 最常用的解密插件，通过内置算法与接口加解密配合，基本可以覆盖80%的加解密需求。 数据解密流向： Proxy 历史：浏览器客户端 -> Burp autoDecode栏 显示解密包 -> 发送到服务端 -> 服务端响应加密包 -> 返回 Burp -> Burp autoDecode栏 显示解密包 -> 浏览器返回密文 代理数据全程对数据包无修改，解密过程仅UI中展示。 Repeater 重放：编辑明文包 -> Burp 调用加密 -> 发送到服务端 -> 返回 Burp -> burp autoDecode栏 显示解密包 -> 浏览器 区别是请求时直接是密文，需要在加密时判断当前是否已加密，已加密则避免重复加密，未加密需要自动加密。 部分缺点： ...

注意事项 在Windows中，ASLR_(Address Space Layout Randomization)（内存随机化保护）的存在使得内存地址随机化成为常态。PE文件通过其重定向表(.reloc节)能够适应这种随机化，使得程序在每次启动时都能正确处理地址引用。 shellcode作为一段纯机器码，不存在重定向表。在编写时，不能依赖固定的内存地址，由于ASLR的作用，这些地址在重启后会发生改变，导致shellcode失效。 也就是说，在开启了ASLR的系统上，在Shellcode中不能直接通过名称调用Windows API，也不能通过DLL base + 偏移的方式调用API。如果没有启用 ASLR，Windows 加载器会尝试将 DLL 加载到其 PE 头中 ImageBase 字段指定的地址。并且由于系统 DLL 是共享的，在不同进程中它们会被映射到相同的虚拟地址。 由于Shellcode没有 rdata段，不能使用全局变量，所有的变量只能在函数的内部栈上分配，使用相对寻址而非绝对寻址。 工作可以分为三步： 在内存中查找需要调用的 DLL 文件。 解析 DLL 的导出表。 通过导出表名称对比定位到函数指针。 为了简化第3步，可以先获取两个关键API（GetProcessAddress、LoadLibrary） 第一步：获取 Kernel32.DLL 地址 Shellcode 中通常需要调用操作系统API，为了使该代码可以在不同的机器上运行，避免写死地址时由于地址随机化导致找不到的问题，需要动态定位Windows API地址。 参考：Finding Kernel32 Base and Function Addresses in Shellcode - ired.team 建议动手通过 windbg 跟一遍获取流程，会加深对偏移的理解。 PEB (Process Environment Block) 是 Windows 操作系统中每个进程都有的一个数据结构，每个进程都有一个唯一的PEB。PEB中存储了进程的各种关键信息：进程的基本参数如进程的镜像基址、命令行参数、环境变量等。PEB中还存储了进程加载的模块列表（LoaderData），这个列表记录了所有被加载到进程空间的DLL信息。 同理，TEB (Thread Environment Block) 是保存线程相关的结构体，一个进程只有一个PEB，但可以有多个TEB 对应多个线程，每个TEB都持有一个指向其所属进程PEB的指针，这样线程就能访问进程级的信息。 通过获取PEB结构，遍历其中的模块列表，可以找出所需要的DLL模块。 开始之前，先细化工作： 获取 PEB 结构体的地址 https://en.wikipedia.org/wiki/Win32_Thread_Information_Block ...