作者：Gcow安全团队-无法

声明：本文所有技术仅限授权渗透测试与安全研究使用，请遵守相关法律法规。

0x00 起因

事情的起因很简单——我在做一次授权渗透测试时，需要让一个C2 Agent成功上线。目标机器上装着360杀毒，手头只有CSC编译器，没有GCC，没有Visual Studio。

我想：能不能让AI来帮我搞定免杀这件事？

但AI毕竟只是个”通才”，它知道VirtualAlloc是什么，也知道XOR加密的原理，但它不清楚实战中哪些手段真正有效、哪些是死路一条。每次遇到问题，它都需要我反复提示和引导。

所以我做了一件事：给AI写了一份专属的免杀知识库——BypassAntiVirus Skill。

从最初的v1.0到现在的v2.4，经历了15个迭代版本，2500+行技术文档，覆盖了从基础到实战的完整免杀知识体系。它不是一篇文章，而是AI的”免杀大脑”。

0x01 它是什么

BypassAntiVirus Skill 是一份结构化的AI技能文件，安装到Trae IDE后，当你跟AI说”帮我免杀”、”帮我生成白加黑”，它会自动调用这份知识库，像一个有着丰富实战经验的红队成员一样帮你完成工作。

十大核心章节：

0x02 AI能做什么

有了这份Skill，AI可以做到：

1. 一键Shellcode处理流水线

你只需要说”对agent.x64.bin进行最优免杀”，AI会自动执行：

SGN编码 → Patch（同义替换+花指令） → XOR加密 → IPv4混淆

每一步都产生完全不同的输出，不需要你手动调用任何脚本。

2. 自动选择最优方案

AI会根据你的环境自动选择加载方案：

• • 有GCC？→ C语言Loader（方案A数据内嵌 / 方案B DLL分离）
• • 只有CSC？→ C# Loader + /platform:x64
• • 只有Python？→ ctypes直接加载
• • 目标有360？→ 方案D：EXE启动器 + Python脚本 + 数据分离

3. 自动排查问题

Shellcode不上线？AI会按照内置的19条问题排查矩阵逐一诊断：

• • 是不是忘了/platform:x64？
• • 是不是ctypes的argtypes没设置导致64位指针截断？
• • 是不是PAGE_EXECUTE_READ权限不够？
• • 是不是从U盘路径运行触发了360启发式检测？

0x03 最精彩的部分：360实战六轮对抗

这是我最想分享的实战记录。v2.4版本中完整记录了与360杀毒（含云查引擎）的六轮攻防对抗，这也是这份Skill最有价值的经验沉淀。

第一轮：C# DLL白加黑 → ❌ 被360静态检测

最直观的方案，Host EXE加载version.dll，DLL里用DllImport声明VirtualAlloc、Marshal.Copy、NtCreateThreadEx。

败因：DllImport声明的API调用链在.NET IL中完全可见，360一扫就知道你在干什么。

第二轮：动态API解析 → ❌ 被360行为检测

改用GetModuleHandle+GetProcAddress+Delegate动态解析API，字符串也拆分了（"Virt"+"ualAll"+"oc"），内存权限也改成两步走（RW→RX）。

败因：360提示”进程创建”行为+”U盘传播途径”（因为我从E盘运行，被识别为可移动磁盘）。

第三轮：WinForm窗口伪装 → ❌ 窗口冻结+行为检测

加了WinForm UI窗口，用EnumWindows回调执行shellcode，伪造了Assembly版本信息。

败因：C2 Agent的shellcode永不返回（维持长连接），EnumWindows回调在UI线程执行导致整个窗口冻结卡死。E盘U盘启发式依然触发。

第四轮：静默执行+系统路径部署 → ❌ 360云查引擎

移除WinForm，shellcode放到后台Thread，写deploy.bat部署到C:\ProgramData。

败因：360云查引擎直接报”高危程序-行为和木马非常相似”。753KB的DLL被云引擎一眼看穿。

第五轮：数据分离（DLL瘦身到7KB） → ❌ 依然被云查

把shellcode数据全部外置到sync.dat，DLL只保留加载逻辑，体积从753KB降到7KB。

败因：7KB的DLL依然被检测。 这一轮让我彻底明白了一个关键事实。

关键发现：.NET IL元数据对杀软完全透明

C# DLL编译后的IL代码，对杀软来说就是”开卷考试”：

• • 方法名、参数类型、委托声明——明文
• • API调用链——明文
• • 字符串常量——明文（即使你运行时拼接，IL里的委托类型声明暴露了一切）

无论你怎么混淆——动态API、字符串拆分、数据外置、体积压缩——360云查引擎的.NET IL分析都能直接读取所有敏感模式。

结论：C# .NET DLL在360面前是死路。必须脱离.NET生态。

第六轮：彻底弃用C# DLL → ✅ 成功上线

最终方案架构：

CloudSyncHelper.exe (5KB纯启动器)    → 搜索pythonw.exe    → 执行 config.dat (Python脚本，.dat扩展名伪装)        → 读取 sync.dat (加密shellcode)        → XOR解密        → ctypes加载执行

为什么能过360：

1. 1. EXE只有5KB，仅调用Process.Start，零敏感代码，任何杀软都找不到恶意行为
2. 2. Python脚本用.dat扩展名，360不会主动扫描Python脚本内容
3. 3. pythonw.exe是微软签名进程，启动它不会触发告警
4. 4. shellcode加密存储在二进制文件中，随机填充+自定义格式，无可识别特征
5. 5. 彻底避开了.NET IL元数据透明性——因为整个执行链根本没有.NET DLL

0x04 踩过的坑（血泪经验）

这些经验都沉淀在Skill的问题排查和关键经验章节中，AI下次遇到同样的问题会直接避开：

🔴 CSC编译不加/platform:x64

CSC默认AnyCPU，.NET的AnyCPU EXE在Windows上以32位模式运行。32位进程执行x64 shellcode——直接崩溃，无报错、无输出、无进程。这个问题让我排查了三轮才定位。

🔴 Python ctypes 64位指针截断

ctypes默认将函数返回值视为c_int（32位）。在64位系统上，VirtualAlloc返回的高于0xFFFFFFFF的地址会被截断。你的shellcode写到了一个错误的地址，然后执行——崩溃。

修复：必须显式设置VirtualAlloc.restype = c_void_p和argtypes。

🔴 EnumWindows回调不能执行shellcode

C2 Agent的shellcode维持长连接，永不返回。如果在EnumWindows的回调函数（UI线程）中执行，整个窗口会冻结卡死。必须用后台Thread。

🔴 RW→RX两步内存权限切换不可靠

理论上先PAGE_READWRITE写入再VirtualProtect切PAGE_EXECUTE_READ更隐蔽。但实战中部分shellcode在权限切换后行为异常。直接PAGE_EXECUTE_READWRITE(0x40)一步到位更可靠。

0x05 Skill的演进之路

v1.0  → 基础知识框架（从70+篇文章萃取）v1.1-1.7 → 逐章深度学习（工具/代码/白名单/多语言）v1.8  → AI免杀套件集成（流水线+Loader模板）v1.9  → ck-loader单文件架构学习（360核晶bypass）v2.0  → XOR分离加载实战v2.1  → 多态加密+Process Hollowing二次封装v2.2  → 重构AI免杀套件（IPv4+反沙箱+DLL分离）v2.3  → C#/CSC实战经验（/platform:x64血泪教训）v2.4  → 360六轮对抗完整记录（.NET IL透明性根因+Python方案）

每个版本都是一次实战后的经验沉淀。AI不会遗忘，下次遇到类似场景，它会直接跳过所有已知的坑，选择最优路径。

0x06 一些思考

AI免杀的本质不是让AI替你写代码，而是让AI拥有你的实战经验。

裸的AI知道免杀的概念，但它不知道：

• • 360云查引擎会分析.NET IL元数据
• • ctypes不设argtypes在64位系统上会截断指针
• • EnumWindows回调里不能放永不返回的shellcode
• • 从U盘路径运行会触发启发式检测

这些经验，只有亲自踩过坑才知道。而Skill文件的价值，就是把这些血泪经验结构化地喂给AI，让它在未来的每一次任务中都能直接调用。

同一技术栈内的优化有天花板，跨技术栈切换才能突破根本性检测机制。 这是六轮360对抗给我最深的教训——与其在C# DLL上反复优化，不如直接跳到Python ctypes。

0x07 最后

这份Skill还在持续迭代中。每次实战中遇到的新问题、新绕过方式、新的杀软检测机制，都会被记录并更新到知识库中。

AI的记忆是无限的，但需要你来告诉它什么值得记住。

如果你也在做AI辅助安全研究，欢迎交流。