劫持 Golang 编译

作者：rook1e@知道创宇404实验室

前段时间学习了 0x7F 师傅的「dll 劫持和应用」，其中提到通过 dll 劫持来劫持编译器实现供应链攻击，不由想到 Go 中的一些机制也可以方便地实现编译劫持，于是做了一些研究和测试。

编译过程

首先我们了解一下 go build 做了什么。

package main

func main() {
    print("i'm testapp!")
}

以这个简单的程序为例，go build -x main.go 编译并输出编译过程（篇幅有限所以没有强制重新编译最基础的依赖）：

上述命令可以将编译过程概括为：

创建临时目录
生成 compile 需要的配置文件，运行 compile 编译出目标文件 ***.a（还有其他编译工具执行类似的操作）
写入 build id
重复 2、3 步编译所有依赖
生成 link 需要的配置文件，运行 link 将上述目标文件连接成可执行文件
写入 build id
将链接好的可执行文件移动到当前目录，删除临时目录

观察这段命令能够发现一些有趣的地方。

每个编译阶段都有单独的工具程序负责，例如 compile、link、asm，这些工具程序可以通过 go tool 获得，其中用于编译的暂且称之为编译工具。

命令中有大段形如 packagefile xxx/xxx=xxx.a 的内容，用于指明代码中依赖和目标文件的对应关系，这些对应关系将写入 importcfg/importcfg.link 作为 compile/link 的配置文件。

另外，还可以发现创建了形如 $WORK/b001 的临时目录。go build 在运行编译工具前会解析出全部的依赖关系，根据依赖关系对每个包创建相应的 action，最终构成 action graph，按序执行即可完成编译，每个 action 对应一个临时目录。例如使用 go build -a -work（-a 表示强制重新编译，-work 表示保留临时目录）编译一个程序：

由图可以看到各个 action 使用的临时目录，如 b062 存放了编译配置文件 importcfg 和编译出的目标文件 _pkg_.a，而最后一个 action 对应的 b001 目录，除了编译的临时文件，还有链接配置 importcfg.link 和链接结果 exe/a.out。

综上，我们可以总结出几个关键信息：

go build 的主要工作：分析依赖，把源代码编译成目标文件，把目标文件链接成可执行文件
目标文件、配置文件存放在临时目录中（b001 是最后一个，也是可执行文件的诞生地），临时目录可以通过 -work 参数保留
调用编译工具实现不同阶段的编译工作
后 action 需要依赖前 action 的结果

可以感受到编译过程是较为“分散”的，这给我们创造了机会：

编译工具是开源的，可以对其修改并替换进 go env GOTOOLDIR 目录
利用 go build -toolexec 机制

这两种方法的思路大致相同，本文尝试了第二种思路。

劫持编译

前段时间研究代码混淆时学习到了 go build 的 -toolexec 机制，这里粘贴一下相关内容：

细心的读者可能会发现一个有趣的问题：拼接的命令中真正的运行对象并不是编译工具，而是 cfg.BuildToolexec。跟进到定义处可知它是由 go build -toolexec 参数设置的，官方释义为：
-toolexec 'cmd args'
a program to use to invoke toolchain programs like vet and asm.
For example, instead of running asm, the go command will run
  'cmd args /path/to/asm <arguments for asm>'.
即用 -toolexec 指定的程序来运行编译工具。这其实可以看作是一个 hook 机制，利用这个参数来指定一个我们的程序，在编译时用这个程序调用编译工具，从而介入编译过程

所以我们的目标是实现一个类似 garble 的工具，暂且称之为 wrapper，在项目的编译脚本或其他存在编译命令的地方插入 -toolexec "/path/to/wrapper"，运行编译命令时 wrapper 要找到一个合适的位置（暂定为 main.main() 的顶部）插入 paylaod。

首先要定位到目标代码文件。

/path/to/wrapper /opt/homebrew/Cellar/go/1.17.2/libexec/pkg/tool/darwin_arm64/compile -o $WORK/b042/_pkg_.a -trimpath "$WORK/b042=>" -shared -p strings -std -complete -buildid ygbMG98G6g0UHH5pai26/ygbMG98G6g0UHH5pai26 -goversion go1.17.2 -importcfg $WORK/b042/importcfg -pack /opt/homebrew/Cellar/go/1.17.2/libexec/src/strings/builder.go /opt/homebrew/Cellar/go/1.17.2/libexec/src/strings/compare.go 
...（省略）

这是一条 go build -toolexec "/path/to/wrapper" 执行的命令，compile 的目标代码文件路径拼接在最后。提取出文件路径后，根据文件内容判断是否是 main.main() 所在文件，方法有很多，例如直接匹配是否以 package main 开头且存在 func main(){ ，更严谨一点可以解析出 AST，通过下图几个特征来判断：

因为一条编译命令包含的文件都属于一个包，所以只要有一个文件不符合要求就可以放弃后续筛选了。

综上，第一步可以通过如下条件筛选：

调用的工具是 compile
文件是 .go 后缀
AST 中包名是 main，且 Decls 中存在名为 main 的 ast.FuncDecl

定位到了目标代码文件，下一步通过修改 AST 来插入 payload。

根据上一步中的 AST 图，main() 中的每条语句解析成 AST 节点是 ast.Stmt 接口类型，存放于 Body.List 中，所以参照具体 stmt 的格式构造 AST 节点，如：

var cmd = `exec.Command("open", "/System/Applications/Calculator.app").Run()`    
payloadExpr, err := parser.ParseExpr(cmd)
// handle err
payloadExprStmt := &ast.ExprStmt{
  X: payloadExpr,
}

向 main() 的 Body.List 插入 payload 的节点：

// 方式1
ast.Inspect(f, func(n ast.Node) bool {
  switch x := n.(type) {
  case *ast.FuncDecl:
    if x.Name.Name == "main" && x.Recv == nil {
      stmts := make([]ast.Stmt, 0, len(x.Body.List)+1)
      stmts = append(stmts, payloadExprStmt)
      stmts = append(stmts, x.Body.List...)
      x.Body.List = stmts
      return false
    }
  }
  return true
})

// 方式2
pre := func(cursor *astutil.Cursor) bool {
  switch cursor.Node().(type) {
  case *ast.FuncDecl:
    if fd := cursor.Node().(*ast.FuncDecl); fd.Name.Name == "main" && fd.Recv == nil {
      return true
    }
    return false
  case *ast.BlockStmt:
    return true
  case ast.Stmt:
    if _, ok := cursor.Parent().(*ast.BlockStmt); ok {
      cursor.InsertBefore(payloadExprStmt)
    }
  }
  return true
}
post := func(cursor *astutil.Cursor) bool {
  if _, ok := cursor.Parent().(*ast.BlockStmt); ok {
    return false
  }
  return true
}
f = astutil.Apply(f, pre, post).(*ast.File)

最后将修改好的 AST 保存为文件，替换原始编译命令中的文件地址，执行命令。

简简单单，到这里似乎顺利完成，但测试一下会出现报错无法找到 os/exec：

/var/folders/z5/1_qfr0f55x97c63p412hprzw0000gn/T/gobuild_cache_1747406166/main.go:5:2: could not import "os/exec": open : no such file or directory

回想一下前文「编译过程」部分的内容，在编译和链接阶段都需要使用其依赖包在先前编译出的目标文件，并且依赖分析和 action graph 的构建是 go build 在运行编译工具前完成的，无法通过 -toolexec 劫持。所以向 AST 中的 import 节点插入依赖并不会修改已有的依赖关系和 action graph，导致没有 os/exec 的目标文件可用。

既然 action graph 中缺少 os/exec 及其依赖，那我们可以自行完成缺少的 action，即编译出相应的目标文件并添加到 importcfg。

对比 importctg 发现间接依赖比想象中的多，但好在都记录在 importcfg 中，所以我们创建一个新的 go build 编译一段简化的 payload：

package main

import "os/exec"

func main() {
    exec.Command("xxx").Run()
}

添加 -work 参数保留这次编译的临时目录，读取临时目录 b001 中的 importcfg 获得 os/exec 的依赖的目标文件路径，将这些配置项按需追加到原 importcfg。

再次尝试，可以看到 payload 成功插入。

另外，可以看到上述测试都使用了 -a 参数，是由于 go build 存在缓存和增量编译机制，正常 go build 可能因命中缓存而不会调用工具，所以要添加 -a 参数强制编译所有依赖，或者编译前 go clean -cache 清除缓存，或是修改环境变量 GOCACHE 到一个新的目录。

最后，梳理一下上述步骤：

compile 时
1. 定位目标文件
2. 编译一个简化的 payload 得到 importcfg 和其依赖的中间文件
3. 补充 importcfg
4. 在 AST 中插入 payload，保存到临时文件
5. 修改原编译命令中的文件路径，执行编译命令
link 时
1. 定位目标文件
2. 补充 importcfg.link
3. 执行链接命令

总结

本文实践的方案利用了 go build 的 -toolexec 机制让工具介入编译过程，在临时文件中插入 payload。

从实际应用的角度来说还存在很多问题，例如如何隐蔽地在编译脚本中插入 -toolexec 和 -a 参数。在没有合适的伪装手段时，按照本文思路修改并替换编译工具 compile 和 link 或许是更好的选择。

本文相关代码存放在 go-build-hijacking，后续有好的思路会继续补充，欢迎师傅们通过 issue 或邮件交流。

Ref

（完）