Posts

前言 本文中总结了我自2023年以来，深度使用大语言模型辅助工作与编码的一些使用经验与技巧。 TL;DR 完善的文档 + 完善的单元测试 + 完善的注释 + 严格的代码审查 + 详细的需求描述，结合少量固定约束提示词，可以实现无负担或少负担的将AI融入编码工作中。 AI编程 迭代到目前，AI编程领域已经出现了Agent、MCP、Codebase RAG等多种增强工具。商业化工具从最初的 TabNine、Github Copilot 到现在的商业化 Cursor、Windsurf、Claude Code，开源 Roo-Code、Continue、Aider等工具。 其中每一个工具我都曾经重度在工作中使用过，基于我过往的使用经验，总结出一些使用技巧。 明确目标 首先需要 明确你的目标 ，以及思考这个目标大模型能否完成？ 模型训练时的数据是有限的，所以首先需要考虑的问题是，你当前需要解决的这个问题，模型的训练数据中有没有可能存在相同或相似的数据？ 例如你使用的技术栈是很主流的Java + spring boot，前端 TypeScript + Next.js，存在大量的训练数据，那AI生成效果可以达到满意。 但凡是会用到小众的库或小众语言，LLM就开始胡言乱语、伪造不存在的API、伪造不存在的语法，如果自身没有鉴别能力，很容易被误导。这种就是大模型的 幻觉问题 。 你的能力上限决定AI的能力上限，最佳场景是这个功能我自己会写，但是我懒得写，所以我指挥AI帮我完成工作。 Complete / Ask / Agent AI辅助编程主要可以分为两大类 代码补全 (auto complete) 问答/结对编程 (chat / agent) 通常对话模型需要经过预训练、指令微调（Instruction Tuning）、强化学习等训练步骤，才能够正常理解对话形式的上下文。而代码补全通常是基于未经过指令微调的基础模型，主要用于文本的补全。 对我而言，日常并不依赖AI代码补全。因为补全需要一定实时性，对速度要求高，且基础模型通常不会太大（猜测不超过14B），无法包含足够的上下文信息，幻觉问题非常严重，补全错误率高，容易打断思路。 当然AI补全也不是完全无用，在特定场景下，例如需求明确的简单CRDD，流水线代码、文档注释、日志输出等，AI补全效果可以满足简单需求。 Agent 是对传统AI编程能力的一次大增强，利用Agent工作流可以使 LLM 将一个大任务拆分成多个小任务，逐步完成，而避免单次任务过于繁重导致结果不理想的问题，那 Agent 模式就一定好用吗？ 我们都知道，Agent每次请求都需要带上过去的上下文信息，请求次数越多，Token数量成指数级放大。这会带来两个问题： TOKEN 数量大以后，大模型容易遗漏关键信息、注意力涣散，导致幻觉增加，代码错误率高。 多轮任务堆叠后，出现上下文稀释，状态同步困难、debug难度高。 钱包爆炸。 MCP （Multi-Component Pipeline）本质上是为LLM提供一套工具箱(toolbox), 使传统文本生成模型拥有了和“现实”的交互能力，实现例如访问网页、命令执行、连接数据库等功能。 在没有 Agent 和 MCP 之前，AI结对编程需要你手动将需要交互的文件加入到Chat对话中，交互后，LLM通常会返回diff结构(Ask Mode)；或是先返回部分设计思路与代码片段，再由专用的diff模型生成diff(Architect mode)。整个交互逻辑需要依赖用户的能力，LLM更像是一个听话的“实习生”，根据用户提示解决问题，无法自动修复问题。 ...

在平时的日常测站过程中，经常遇到前端加密相关的对抗，对请求包及响应包进行加密、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栏 显示解密包 -> 浏览器 区别是请求时直接是密文，需要在加密时判断当前是否已加密，已加密则避免重复加密，未加密需要自动加密。 部分缺点： ...

22年部门内部做的一次 Sysmon进程保护的研究分享，主要是基于 minifilter过滤和进程断链，实现对Sysmon进程、驱动、服务、文件等状态的隐藏。 这套解决方案还有很多问题，例如内核断链需要先想办法BypassPG (patch guard)，每个版本Windows bypass 的兼容性问题等等。 我手上还有一套研究出来更稳定的方案，无需 bypass PG也能实现断链，可能泛滥被恶意利用所以没办法发出来。 另外还有一个基于VT的进程隐藏 + 进程保护的 Demo，看后续有没有机会整理出来。 pdf: Sysmon驱动保护：深度剖析进程隐藏的实现原理

注意事项 在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 ...