Found it. The ~1KB you were seeing isn’t a truncated snapin — it’s a 6-byte #!auth error response that the FOG Client wrote to disk and then hashed (which of course doesn’t match the real snapin’s SHA512).
The root cause is on me. A recent security patch on dev-branch added a token check on the snapin download/checkin endpoints, but the deployed FOG Client doesn’t know to send that token — so every legitimate snapin download was getting rejected with #!auth. Closing one hole, opening a different one. Sorry about that.
I’ve reverted the patch on both dev-branch and working-1.6. If you pull the latest and re-run the installer (or just git pull + your usual deploy method), snapins should start working again. Versions to look for:
dev-branch: 1.5.10.1856
working-1.6: 1.6.0-beta.2336
The underlying security issue this was meant to address still needs a real fix, but that requires coordinated changes to both the server and the FOG Client itself, so it’ll be a future release rather than a hotfix.
Let me know if pulling the revert gets your snapins running, and thanks for the detailed report — the “binary garbage” file you described was the clue that cracked it.