The hash check is the proof, but sometimes you are handed an ISO with no trustworthy reference to compare against. Mounting the image and reading its internal structure gives you the next best thing: a rebuilt ISO almost always leaves fingerprints in its folders and files.
A genuine Windows ISO has a predictable anatomy. Microsoft builds them the same way every time, so anything extra, renamed or misplaced stands out once you know the layout. Mount the ISO - in Windows 10 and 11, double-clicking it mounts it as a virtual DVD drive - and walk the structure below. This check cannot prove a file genuine the way a matching SHA256 does; it can absolutely prove one modified, and it can catch rebuilds that file names alone would never reveal.
Open the mounted ISO. At the root you should see setup.exe and the standard folders - boot, efi, sources, support. Right-click setup.exe, open Properties and the Digital Signatures tab: a genuine file is signed by Microsoft Corporation and the signature validates. Extra passengers are the tell: loose .cmd or .bat files at the root, folders named for activators or cracks, or a readme from a release group all mean hands were inside this image. Genuine retail media carries none of them.
Inside sources sits the operating system itself: install.wim or its compressed sibling install.esd, several gigabytes and the largest file in the ISO. Sanity-check it: a multi-edition Windows 11 image whose install file is far smaller than roughly 4 to 5 GB has had components stripped; one far larger may be carrying additions. Also look for ei.cfg - on current consumer retail media this file is normally absent; its presence (it forces an edition choice) usually means the image was reworked for deployment or rebuilt. Neither sign alone convicts, but each lowers trust and raises the value of a real hash comparison.
Two legitimate deployment features double as rebuild fingerprints. A $OEM$ folder inside sources copies its contents into the installed system and can run scripts at setup - OEMs use it, and so does every 'pre-activated' builder, because it is the perfect place to plant an activator. Likewise an autounattend.xml at the root silently answers setup questions and can execute commands during installation. If you did not build this ISO for an organisation, neither should be there. Their presence does not tell you what the planted code does - it tells you code was planted, which is enough.
Be honest about this method's ceiling: it catches careless and typical rebuilds, which is most of what circulates. A careful rebuild can imitate the standard layout. So read the result correctly - oddities found means reject the file; nothing found means unproven, not genuine, and the SHA256 comparison remains the only proof. In practice the order is: structure check for a fast rejection, hash check for acceptance. A file must pass the second, not merely survive the first.
Every step shown live — checking a real ISO with the verifier tool and with PowerShell.
▶️ Watch Full VideoNot automatically - technicians and organisations add ei.cfg to control edition selection, and some older or volume media include it. On a consumer ISO you downloaded as 'original', though, it is a sign the image was reworked, so verify the hash before trusting it.
In practice the root setup.exe signature plus the ISO hash is the practical route. Inspecting files inside the WIM requires mounting it with DISM, which is a technician-level step - and unnecessary once the whole-file hash matches.
Yes - plug it in and read the same folders on the drive. But you cannot hash-verify a written USB against the ISO hash; verification happens on the ISO file before it is written. For a drive of unknown origin, re-create it from a verified ISO.