Not packed — full MinGW symbol table, debug sections, plaintext strings, 120 benign imports (no process-injection, registry, or service APIs). Decompilation is worthwhile. Let me pull the full string set and check resources first.

The picture is already emerging — a self-updating GitHub installer. Let me check for classic malicious tradecraft strings, then dump the code with Ghidra.

No tradecraft indicators at all — no PowerShell/cmd abuse, no registry run keys, no scheduled tasks, no encoded payloads. Built with llvm-mingw (clang 23.1.5). Now let me decompile it to verify the actual behavior in code.

Only 3 "suspicious" flags — two look like code-quality issues and __write_memory is the standard MinGW relocation helper (patches its own image at load — normal for GCC-built PEs). Let me verify the real logic by reading the key functions.

--play launches bin\hookshot.exe from a chosen folder; launch_installed re-launches the updated versions\<ver>\HookshotBuilder.exe from current.txt. All consistent with a legit updater. Now the core: work()'s download/verify/extract loop and the dangerous primitives (rmtree, tar, file ops).

The installer logic is clear. Now let me verify the security-critical functions: manifest validation (list_name_ok), the recursive delete (rmtree), URL construction, and the download/hash path.

list_name_ok blocks traversal (.. components, leading slashes, restricted charset) and rmtree is a guarded recursive delete used on the app's own folders. Now the network stack and URL construction:

manifest_url shows a hardcoded https://github.com/NotRexed/Hookshot/... default (the char-by-char stores are just the compiler inlining a constant). Let me check the remaining network functions, the hash comparison, and confirm there's no TLS bypass:

All clean: WinHttpSetOption(0x58) is WINHTTP_OPTION_DECOMPRESSION (gzip), not a TLS bypass; downloads are pinned to https://github.com/<repo>/releases/... and rewritten to api.github.com. Let me confirm the SHA-256 check actually gates the install, and verify the tar path:

tar runs from GetSystemDirectoryW() (genuine Windows bsdtar) with quoted fixed args. Now the critical question — is the downloaded data's SHA-256 actually compared before anything is used:

SHA-256 is genuinely enforced: each part's streamed hash is hex-encoded and strcmp-compared to the manifest; on mismatch the .part file is deleted and install aborts. Final sweep — GUI code, remaining helpers, and an entropy check on .data:

.data entropy 0.6 (no encrypted payload), .text 5.8 (normal code). .rsrc is 7.9 — let me confirm it's just an icon, not an embedded payload:

.rsrc is just a 7-icon set (16–256px PNGs), manifest XML and version info — no embedded executables. One last verification of the snprintf flag Ghidra raised (checking the actual call-site arguments):

The snprintf flag is a confirmed false positive: the prologue remaps registers so the call is really snprintf(buf, 0x400, fmt, repo, tag) with both %s args properly passed (R9 = repo, [RSP+0x20] = tag). All triage flags resolved. Writing the final report:

Scan complete: No malware found — this is a legitimate installer/launcher

File: HookshotBuilder.exe — PE32+ x64 GUI, 185,856 bytes SHA-256: 552a24c4c210a87dd3d6494a88a1a707cbedf6e50ddd2604caa5719c5c63a05e Report: malware_report_HookshotBuilder.md

What it is

A self-updating installer/launcher for the open-source project github.com/NotRexed/Hookshot, built with llvm-mingw (clang 23.1.5) with full symbols and debug info — no packing, no obfuscation. Verified behavior from decompiled code:

1. Downloads a release manifest (hookshot-setup.txt) from the hardcoded GitHub repo over HTTPS (WinHTTP)
2. Downloads parts while computing SHA-256 on the fly (BCrypt) and compares against the manifest — on mismatch, the file is deleted and install aborts
3. Extracts with genuine Windows tar.exe (<sysdir>\tar.exe -xf "..." -C "...", quoted/fixed args)
4. Installs to %LOCALAPPDATA%\HookshotBuilder\versions\<ver>\, updates current.txt, relaunches itself; --play launches <dir>\bin\hookshot.exe

Why it's clean (evidence)

• No persistence: advapi32 not even imported — no registry, services, or scheduled tasks
• No injection: no VirtualAllocEx/WriteProcessMemory/CreateRemoteThread/SetWindowsHookEx
• No TLS bypass: the only WinHttpSetOption call is 0x58 = decompression (gzip)
• No shell abuse: zero PowerShell/cmd/certutil/wscript/encoded-blob indicators
• No hidden payloads: binwalk shows only 7 PNG icons + version/manifest XML; .data entropy 0.6
• Downloads pinned to github.com/api.github.com via strict URL prefix validation (api_link_for)
• Path-traversal protected: manifest names validated by list_name_ok() (rejects .., leading slashes, odd charset); rmtree is guarded and only touches its own folders
• All 3 Ghidra triage flags resolved as benign: __write_memory = standard mingw CRT relocation helper; api_asset_url "missing format args" = false positive (ASM shows snprintf(buf,0x400,fmt,repo,tag) with both args); mem_sink = minor OOM-handling quality bug, not malicious

Caveats

• Unsigned — expect generic heuristic AV warnings (reputation, not malice)
• The hash check protects downloads, but the manifest is trusted from the GitHub repo — supply-chain risk is external to this binary, as with any updater`