Why It Matters#

The first thing a reverse analyst does when they get a binary:

1. Open IDA / Ghidra, inspect the export table, import table, strings
2. If a .pdb with the same name is lying around, load it — variable names, function names, source paths all handed over
3. Run strings to grab plaintext strings from .rdata

If the binary still contains absolute paths from the development machine (e.g. C:\src\targetstring\loader\src\proxy.c), you’ve given away the project name, source structure, and dev machine directory layout for free. A blue-team search by path signature exposes the entire repository.

What Zig’s Strip Actually Removes#

Zig’s .strip = true (or -fstrip) does two things:

• Removes the symbol table (.symtab, .debug_* and other debug sections)
• Prevents PDB / debug info generation

But it does not remove string data from .rdata. This is a critical insight: __FILE__ macro expansions and compiler-generated debug auxiliary strings are “ordinary data” — strip has no way to identify them as something to delete.

I accidentally ran a perfect controlled experiment within the same ReleaseSafe build:

strip=true → no PDB generated; strip not configured → PDB is always generated.

And IDA auto-loads same-directory same-name PDB files — parameter names like dest/src/len are directly exposed, essentially giving away the source code’s “directory”.

Conditional Strip (-Dstrip)#

A blanket strip creates a contradiction:

• Development / AI debugging: need PDB (IDA decompilation quality is night and day with symbols)
• Production release: no PDB (security)

The solution is a build option that defaults based on the optimization mode:

1
const strip_opt = b.option(
2
    bool, "strip",
3
    "strip debug info / suppress PDB (default: false in Debug, true in Release)",
4
) orelse (optimize != .Debug);

Then apply it to all production artifacts:

1
const client_exe = b.addExecutable(.{
2
    .root_module = b.createModule(.{
3
        .strip = strip_opt,
4
        // ...
5
    }),
6
});
7
const client_static_lib = b.addLibrary(.{
8
    .root_module = b.createModule(.{ .strip = strip_opt, /* ... */ }),
9
});
10
const a_dll = b.addLibrary(.{
11
    .root_module = b.createModule(.{ .strip = strip_opt, /* ... */ }),
12
});

Usage:

WARNING

Watch out: “non-primary” artifacts like a.dll are especially easy to miss when configuring strip. I found that the exe and static lib were both configured, but the dynamic lib wasn’t — and it’s precisely the most common IDA analysis target. Double-check every installArtifact.

The Big Gotcha: Source Paths Written into .rdata#

After fixing strip, I thought I was done. A quick rg -a "targetstring" scan:

1
a.dll:  17 hits
2
targetstring-client.exe:  9 hits

strings revealed:

1
Z:\src\targetstring\loader\src\proxy.c
2
Z:\src\targetstring\loader\src\anti_sandbox.c
3
Z:\src\targetstring\loader\src\xtea.h
4
Z:\src\targetstring\zig-pkg\N-V-__8AAJud...\c\dec\decode.c

Accompanied by a bunch of 'DWORD' (aka 'unsigned long'), 'const uint64_t' (aka ...) type strings — these are clang CodeView debug auxiliary strings, stored in .rdata (not the .debug section!). So strip can’t remove them either (.rdata is ordinary data).

1
off=0x617600 rva=0x619000 sec=.rdata :: Z:\...\loader\src\proxy.c

Solution: Post-Install Byte Patching#

Since compile-time can’t handle it, just patch the bytes after the build. Here’s a small script:

1
MARKER = b"Z:\\src\\targetstring"       # Replace with your project's absolute path prefix
2
REPLACEMENT = b"." * len(MARKER)   # Same-length replacement to preserve file structure
3

4
def sanitize(path: str) -> bool:
5
    with open(path, "rb") as f:
6
        data = f.read()
7
    if MARKER not in data:
8
        return False
9
    with open(path, "wb") as f:
10
        f.write(data.replace(MARKER, REPLACEMENT))
11
    return True

Key points:

• Same-length replacement: Z:\src\targetstring (fixed length) replaced with the same number of . characters, preserving file layout
• PDB untouched: debuggers parse source paths from PDB, so PDB keeps the real paths — when scanning binaries with rg, PDB hits don’t count (it’s a symbol file, not distributed with releases)

Integration:

1
// build.zig: manual step (avoids install dependency cycles)
2
{
3
    const strip_cmd = b.addSystemCommand(&.{
4
        "python", "tools/strip_source_paths.py",
5
        b.getInstallPath(.bin, ""),
6
    });
7
    strip_cmd.step.dependOn(b.getInstallStep());
8
    const strip_step = b.step("strip-paths", "sanitize absolute source paths in zig-out/bin");
9
    strip_step.dependOn(&strip_cmd.step);
10
}

1
# CI (.github/workflows/build.yml): runs automatically after every Windows build
2
- name: Sanitize source paths from binaries
3
  if: contains(matrix.target, 'windows')
4
  run: |
5
    python3 tools/strip_source_paths.py zig-out/bin

TIP

Why not make this an automatic build step? Zig has no “post-install” hook — install and any post-processing step create a dependency cycle (install → strip → install). The standard approach is CI integration (same pattern as the existing strip_buildid.py), with a manual zig build strip-paths available locally.

Verification results:

1
$ python scan_paths.py          # Custom scan script
2
a.dll         path-hits=17  → 0
3
targetstring-client.exe  path-hits=9   → 0

Another Gotcha: The .buildid Section#

GitHub Actions build artifacts include a .buildid section that may contain repository/commit info. The project already has tools/strip_buildid.py to remove it in CI:

1
- name: Strip .buildid section
2
  run: |
3
    for exe in zig-out/bin/*.exe; do
4
      python3 tools/strip_buildid.py "$exe" || exit 1
5
    done

When auditing these “metadata sections”, just use objdump -h or pefile to iterate the section list and check for suspicious names.

Pre-Release Checklist#

1
# 1. No PDB shipped with binaries
2
ls zig-out/bin/*.pdb          # Should be empty (Release build)
3

4
# 2. No absolute source paths remaining
5
rg -a "targetstring" zig-out/bin/*.dll zig-out/bin/*.exe   # Should be 0
6

7
# 3. No .buildid section
8
# (Handled automatically by CI)
9

10
# 4. IDA verification: open the binary, confirm no symbols, no paths, functions named sub_XXX

Conclusion#

1. Conditional strip is easy: -Dstrip option + optimize != .Debug, works for both dev and release
2. Strip only removes symbols, not .rdata strings — string-level leakage requires other measures
3. CodeView auxiliary strings (the (aka ...) kind) containing source paths are unaffected by all compile-time flags; -ffile-prefix-map only works for DWARF and __FILE__
4. Post-install byte patching is the most reliable fallback: same-length replacement, PDB preserved, CI-integrated

If you’re building native Windows projects that need to resist reverse engineering, add “no PDB + no paths + no .buildid” to your release checklist.