What's really inside this Go CLI? A dependency inventory from the binary

A compiled Go program carries a list of every module it was built from, with versions. REA can read that list without running the program. We pointed it at the official GitHub CLI (gh) 2.102.0 and got the Go version, the main module, 164 dependency modules and the build settings in one session. One of the model's labels for the result was wrong, and we explain which below.

Target

• Program: GitHub CLI, MIT license, https://github.com/cli/cli/releases
• Release: v2.102.0, file gh_2.102.0_macOS_arm64.zip
• Archive SHA-256: da922c20d1792e5b2cbf375593d7a658acf034c12c84e007e71c76ef959c337e (this matches the digest GitHub shows for the release asset)
• bin/gh SHA-256: 8a4258433c81106343144857750316241759d06dcf16265cf3c4864a8f2f2ad6 (Mach-O 64-bit arm64, 39,834,784 bytes)

The target is open-source software, and we only read the file. We never executed it.

Requirements

• Node.js 22.19 or newer within 22, 24.11 or newer within 24, or 26 and newer (Node 25 is not supported). free-pi needs 22.19 or newer, and REA's loader accepts only those ranges.
• A GitHub account, free-pi 0.4.5 or newer, and curl and unzip to fetch the target. No API key, no card, no Go installation.
• The tool also reads Go binaries in ELF (Linux) and PE (Windows) format. This post uses macOS arm64.

Commands

curl -L -o gh.zip https://github.com/cli/cli/releases/download/v2.102.0/gh_2.102.0_macOS_arm64.zip
shasum -a 256 gh.zip      # compare with the archive digest above
unzip gh.zip
mv gh_2.102.0_macOS_arm64 gh-2.102.0

npx free-pi-cli

Then inside free-pi (setup details are in Use REA (Reverse Engineer Anything) free: no API key, no card):

/reverse-engineer-anything
/mcp

Wait until /mcp shows rea as connected, then send one prompt:

Use REA to inspect ./gh-2.102.0/bin/gh. List the Go toolchain version, the main module,
the top-level dependencies with versions, and the build settings. Cite the tool output
for each fact.

Sped up 8x. The recording starts when we type the command; the session took about a minute and 45 seconds.

The evidence

The model called REA's inspect_go_binary tool. The tool reads the Go build information embedded in the file: no disassembler, no execution, no network. The result is saved as an evidence record with the file's SHA-256 and the byte range where the data was found. The model reported:

evidence  ev_da4787e6b56e88d41529a1e21e35a2598b9eaa13438bb1eb8268f8810a231eb4
sha256    8a4258433c81106343144857750316241759d06dcf16265cf3c4864a8f2f2ad6
build-info at file offset 37,224,448 (inline encoding)
"go_version": "go1.27.1"

Main module:

path   github.com/cli/cli/v2/cmd/gh
mod    github.com/cli/cli/v2   v2.102.0

Dependencies: the tool returned 164 entries, and none had a replacement. A few of them, copied from the model's list:

github.com/cli/go-gh/v2            v2.16.1
github.com/spf13/cobra             v1.10.2
github.com/charmbracelet/glamour   v0.10.0
github.com/sigstore/sigstore-go    v1.3.0
github.com/theupdateframework/go-tuf/v2   v2.4.2
google.golang.org/grpc             v1.83.2
golang.org/x/crypto                v0.57.0

Build settings (as the model listed them; the tool reported complete: true and no unparsed lines):

-buildmode   exe
-compiler    gc
-ldflags     -s -w -X github.com/cli/cli/v2/internal/build.Version=2.102.0
             -X github.com/cli/cli/v2/internal/build.Date=2026-09-30
CGO_ENABLED  1
CGO_CFLAGS / CGO_CPPFLAGS / CGO_CXXFLAGS / CGO_LDFLAGS   (all empty)
GOARCH       arm64
GOOS         darwin
GOARM64      v8.0
vcs          git
vcs.revision fc4b137cdef0a6bd28fd461b7cf9c84a5812a8cd
vcs.time     2026-09-30T02:18:02Z
vcs.modified false

What we learned

• The release was built with Go 1.27.1 from a clean git checkout (vcs.modified=false) at commit fc4b137c…. The -ldflags show the symbols were stripped (-s -w) and the version and date were set at link time. These values agree with each other and with the file name.
• Even with stripped symbols, the module list is intact. Anyone with the binary can see which libraries it contains. That is useful for checking a vendor's software against a vulnerability list, and it is why you should assume your own Go binaries reveal their dependencies.
• The list includes a TUI stack (Charm libraries), cobra for commands, a group of sigstore and TUF libraries, gRPC and OpenAPI packages. We did not verify what each library is used for; that needs the source or a disassembler.

What went wrong

• The model blurred direct and indirect dependencies. It headed the list "Top-level dependencies". Go's embedded build information is a flat list of every module linked into the program, and it does not mark which ones are direct. The model said this itself in its reasoning, but its closing caveat then claimed the output "distinguishes direct dependencies from their transitive closure", which is wrong. The accurate statement is "164 dependency modules". To separate direct from indirect you need the project's go.mod. We asked for "top-level" dependencies in the prompt, which invited the mistake.
• The output was too large for one reply. REA's result was about 16,000 tokens (the CLI reported "original token count: 15896"), so free-pi truncated it and saved the full text to a temporary file. The model then ran several jq commands on that file. Three of them failed (jq: error ... Cannot iterate over null and similar) because the model guessed the wrong field names; later ones found the settings and dependencies under normalized_result.build_info.module. That is why one tool call turned into a longer session.
• We did not independently recount the 164 modules with another tool such as go version -m.

What it cost

/usage before and after this session:

14,153 / 15,000 credits left today
14,008 / 15,000 credits left today

That is 145 credits. (We read the first number just before starting the recording, so it is not in the GIF.) The footer at the end showed about 45k fresh input tokens and 8.6k output tokens; most of the input was served from the prompt cache.

Use REA responsibly

Use REA only for lawful, authorized analysis: your own apps, open-source software, CTFs, and security research.

Tool output goes to the model provider, and free-pi stores traces of sessions. Do not analyse files you are not allowed to share.

free-pi is in early testing; features and limits may change.

We build free-pi, and an AI model produced the analysis shown above.

---

Series: Use REA (Reverse Engineer Anything) free: no API key, no card and What does your app store? Reading an app's SQLite database.