iso2god-rs v1.8.1 Says ‘1.8.0’ — Your Download Is Not Wrong
If you downloaded iso2god-rs v1.8.1 and the program answers iso2god 1.8.0 when you run it with --version, nothing is wrong with your download. The v1.8.1 release binary genuinely reports itself as 1.8.0 — the version string inside the program was not bumped for that release. We know this because we downloaded the official release, ran the binary ourselves, and checked what it printed.
This short page explains the quirk, why it happens with small open-source releases, and — more usefully — how to prove which release you actually have, using the file’s SHA-256 hash rather than its version string.
What we verified, and how
On 2026-10-23 we downloaded iso2god-rs v1.8.1 (published 2025-08-10) directly from the project’s GitHub Releases, hashed the files, compared those hashes against the digests GitHub itself records for the release assets, and then executed the Linux binary. Its --help worked normally, and its --version output was:
iso2god 1.8.0Context that makes this unsurprising: v1.8.0 and v1.8.1 were published on the same day, minutes apart. A small follow-up release that fixes something outside the version string — a packaging detail, a build correction — is exactly the kind of release where the embedded version number gets left behind. That is an explanation of the likely mechanics, offered as such; the verified fact is simply that the genuine v1.8.1 binary prints 1.8.0.
Why the version string is the wrong thing to trust
A version string is just text the program was told to print. It can lag the release it ships in (as here), and on a file downloaded from an untrusted mirror it proves nothing at all, because anyone can rename a file or rebuild a program to print anything. The reliable identity check for a release binary is its cryptographic hash: if your file’s SHA-256 matches the digest recorded for the official release asset, you have the official file, bit for bit — whatever its version string says.
The five verified v1.8.1 hashes
These are the SHA-256 digests for all five iso2god-rs v1.8.1 release assets. The Linux x86_64 and Windows x86_64 files are ones we downloaded and hashed locally, with our results matching GitHub’s recorded digests exactly; the remaining three are the digests GitHub records for those assets.
| Platform | Asset | Size (bytes) | SHA-256 |
|---|---|---|---|
| Linux x86_64 | iso2god-x86_64-linux | 1,317,368 | 4cee1da8dff34659246a4e26bfafd56d023b1ff6b07b3f652b9302b1d2b089a1 |
| Windows x86_64 | iso2god-x86_64-windows.exe | 1,129,984 | 1459fcf8ff5a89e039b02c68c06b006b7a036f3b1ca237c2d7e03d61bd211d47 |
| Linux ARM64 | iso2god-aarch64-linux | 1,247,616 | e32c812a803da0a3ff65cd405a42a463b05e09a8589e06a956db57d99eba852b |
| macOS x86_64 | iso2god-x86_64-macos | 1,085,848 | a06eb89ed0915bacc230cf6069e81e4116879fb2ccd7ab2b692fef6c1b34095c |
| macOS ARM64 | iso2god-aarch64-macos | 1,048,976 | fac0e506a668a1616270082caf18ddd7e7cfda96aac23a20d8161e65bf3d911b |
How to check your copy
- Find the file you downloaded and note which platform asset it should be from the table above.
- On Linux or macOS, open a terminal in that folder and run
sha256sum <filename>(Linux) orshasum -a 256 <filename>(macOS). On Windows, runGet-FileHash <filename> -Algorithm SHA256in PowerShell, orcertutil -hashfile <filename> SHA256. - Compare the result character by character with the matching row in the table, and check the file size too.
- If both match, you have the genuine v1.8.1 release — even though
--versionsays 1.8.0. If they do not match, delete the file and download again from the GitHub link on our download page, then check once more.
The same verify-before-you-trust routine applies to every tool on this site, and it is the heart of our guide to antivirus flags on homebrew tools: a matching hash from the real release page is worth more than any badge, label or version string a download portal prints next to a file.
What to do with this knowledge elsewhere
- Do not “fix” the mismatch by hunting for another download that prints 1.8.1 — you would be trading a verified official file for an unverifiable one.
- Do not report the quirk as a bug in your download or assume your conversion results are suspect. The converter’s behaviour is the release’s behaviour; only the printed string lags.
- If a tutorial (ours included) ever tells you to reject a download purely because of what
--versionprints, prefer the hash check. Where our own guides mention the version, they mean the release — v1.8.1 — as labelled on the project’s Releases page.
For actually using the tool once you have verified it — syntax, --dry-run, trimming, thread counts and worked examples — go to our full iso2god-rs guide.
Frequently asked questions
Why does iso2god-rs v1.8.1 print “iso2god 1.8.0”?
Because the version string embedded in the binary was not bumped for the v1.8.1 release, which followed v1.8.0 on the same day. We confirmed it by running the official v1.8.1 binary ourselves: --version prints 1.8.0.
How can I be sure I really have v1.8.1?
Hash your file and compare it with the table on this page. A SHA-256 match with the official release asset’s digest — together with the correct file size — confirms your copy bit for bit, regardless of the printed version string.
Should I download a different copy that says 1.8.1?
No. A file that prints 1.8.1 but does not match the verified hashes would be less trustworthy, not more. Keep the hash-verified official file from the GitHub link on our download page.
Does the wrong version string affect conversions?
No. It is a label, not a functional difference. Your conversions are performed by the v1.8.1 release code. More troubleshooting topics are collected on the Troubleshooting hub.
Why two releases can share one day
Small open-source projects release differently from commercial software. There is no marketing calendar and no certification gauntlet; when a maintainer finds a problem in a release they published that morning — a wrong asset attached, a build flag missing, a packaging mistake — the fastest responsible move is a new point release the same day, which is what the v1.8.0-then-v1.8.1 sequence on 2025-08-10 looks like. In that kind of rapid follow-up, the code that prints the version is simply one more file that has to be edited, and it is the easiest one to forget precisely because it changes nothing about how the tool behaves. Commercial teams catch this with release checklists and automated version stamping; a volunteer project catches it when a user notices — which, in effect, is what pages like this one are for.
Version numbers across the Iso2God family, so this stops being confusing
Part of the confusion around this quirk is that “Iso2God” version numbers come from several different projects. The original Team 360h program ended at v1.3.6. The Windows GUI fork continued the numbering on its own line, reaching v1.6.0 — numbers that look like sequels to the original but are a separate project’s releases. Iso2god-rs is a different codebase again, with its own numbering, currently at release v1.8.1. None of these numbers are comparable across projects, and a higher number in one line says nothing about another. Judged within its own line, your rs binary is exactly what its hash says it is: the v1.8.1 release, wearing a 1.8.0 name tag. When you read any guide on this site, version references follow the release labels on each project’s own Releases page, for exactly this reason.
Keep the habit this page teaches and version confusion loses its power generally: for any tool in this scene, the release page plus a hash check identifies your file, and the string a program prints about itself is only ever a clue.