Iso Image Scan Failure Rufus

[Virgil Gardiner]

Im trying to install Ubuntu 16.04 from a USB drive. I'm using Rufus to create a bootable stick, but everytime I click start, it starts, and then gives the error ISO image extraction failure. What can I do?

for me the case was that I deleted the rufus_files folder rufus created when it's ran for the very first time. Actually, I keep a different folder for softwares, so i only copied .exe after i did my first iso extraction with rufus and deleted the folder (rufus_files).

I was trying to create the bootable USB from my office laptop and got in to this issue. I have read many solutions and it didn't work out.From one answer they said it might be due to the anti-virus effect and i tried using my personal laptop and it did work out.

In my case, the USB drive was encrypted with BitLocker. I had to remove BitLocker from the drive before it worked. In Windows, just search for BitLocker from the start menu, and see if BitLocker-To-Go is enabled for your drive. Disabling it, then trying Rufus again to write Ubuntu to the drive worked.

I am trying to use Rufus on my Mac running Parallels desktop to create a Windows 11 To Go USB stick. I have properly connected the USB stick, which is formatted as FAT32, and have verified that the checksums for the Microsoft website downloaded Windows 11 ISO image are correct using MD5: 8f76997f66850b0beab0359ab36d167c.

However, when I attempt to use the "Windows to Go" option in Rufus, I receive an ISO image scan failure error. This same error also occurs when attempting to create a Windows 10 To Go USB stick using the same method. The standard Windows Installation works but Windows to Go doesn't.

As I'm running Rufus in a Windows VM and the iso is on the host system, shared with the VM via VMware Shared Folders, I figured that's the issue. I copied the iso into the VM's local virtual disk and Ventoy proceeded wit the scanning.

Turned out to be a problem with the ISO file. I downloaded it on a linux computer and moved to a windows one. That caused a corruption. Directly downloading the ISO on a windows computer solved it (use a linux computer to get the link from Microsoft). -@Julius

Are you experiencing Rufus ISO image extraction failure? If you are, this post is worth reading. It provides you with 4 solutions. Now, explore the content with MiniTool Partition Wizard.

If the ISO file is corrupted, you will experience Rufus ISO image extraction failure. Therefore, it is necessary to check the integrity of the ISO file after you receive the ISO image extraction issue. You can do that by using Windows File Checksum Integrity Verifier (FCIV).

Alternatively, mount the file from your File Explorer and test whether you can view the files within it to check the integrity of the ISO file. If the ISO file is corrupted, reload the ISO file and construct a USB boot again.

On some occasions, formatting the USB drive before using can fix ISO image extraction failure in Rufus. USB formatters like MiniTool Partition Wizard, Disk Management, and Diskpart allow you to format a USB easily. Here, we show you how to format a USB drive by using MiniTool Partition Wizard.

Step 3: In the prompted window, configure format settings and click OK to save changes. For instance, you are able to set partition label, file system, and cluster size based on your demands.

If there are issues with the USB drive, try using a different USB device. Then continue the operation to see if the Rufus ISO image extraction failure disappears. If necessary, update the USB driver via Device Manager.

Once again, the unsigned MinGW build of Rufus (which is built in a fully automated fashion from our public source by GitHub actions here and can also be downloaded here) is being flagged by Malware byte as malware (Malware.Heuristic.1003).

Whereas for previous releases, the false positive seemed to disappear after the file was digitally signed, there is no reason why the unsigned version of the executable should be flagged, especially when it can be formally demonstrated that the binary can only have been produced from the public source at

I appreciate that. But I'd rather not have every unsigned executable I compile get flagged for behaviour that is not present in the source code (unless you guys can actually point to what it is in our source that triggers this false positive).

My understanding is that, if we're going the whitelisting route, I'm going to have to submit new false positive reports every time I recompile a new executable, and this is going to get old very fast...

You already reported it and was solved, Im sure when you compile a new version and report it as FP, Malwarebytes staff will take the needed actions to exclude your executable for longer time (while you no make significant modifications to code)

It was solved for one executable. It wasn't solved for the 2 previous builds [1], [2], and I just don't have the scope as a software developer to go around every AV vendor out there that suddenly decides to flag my software, which is why I asked for something better than whitelisting...

This is an auto learning heuristic. It will usually learn within 24 hours of first scan wether its a fp or not and self correct. Do you know if it still hits if its not upx packed? Also the file has a rcdata resource section but they are all empty. that may be triggering the heuristic.

THIS is why I just don't have the time to go around every AV vendor out there and report a false positive, because, from the inconsistencies I can formally demonstrate, they are much more interested in crying wolf than anything else.

While I understand that you can of course only vouch for the MB engine (who, at least, is consistent there), if one is doing a proper job, then a decompressed UPX exe should produce the same results as a compressed...

So, if this is what you are going for, I am going to posit that I should not be the one who has to modify their build process so as not to trigger AV detection. Instead, it should be the exact opposite, with AV vendors being smart enough not to be tripped by an empty resource section when there's nothing malicious actually going on there...

The way the heuristic works is it looks for file anomalies. Having empty resource sections for example is something that is seen in malware. Also its 24 hours from first scan of the file. If the file was digitally signed with a valid signature we could whitelist that signature for all builds. Basically something in your build process is something similar to malware files we have seen.

And now you have seen it in non-malware, therefore, I will argue that you should stop using that rule to qualify an executable as potential malware or, better, refine your rule so that your previous malware sample that had this property still gets flagged (through the use of other characteristics), but innocuous applications that also have this property don't.

I hope you can appreciate that if we go that route, then there's not much that's going to be left for legitimate application developers not to have their executable flagged as malware eventually, if all it takes is a property, that does not qualify as malware per se, to trigger a false positive. That's pretty much the same issue as what we have with the inordinate amount of engines that continue to see the use of UPX compression as an indicator of potential malicious behaviour (instead of just reporting on the uncompressed version of the file). Again, I will reiterate that this is in part why it is exhausting for developers to try to engage with AV vendors, because there's no denying that there's often a strong preference there to prefer "wider nets" over "accuracy of results" (and yes, I do understand where this comes from, since accuracy of results is hard, but when 16 engines are jumping into the same bandwagon and are misclassifying a specific type of build from the exact same source, and not another, I can't help but think that there is definitely a problem that should be fixed there).

I've happened to have to switch signatures (including CN) in the past, so that last thing I want, if that happens again, is for a dozen AV engines to suddenly declare my application as malware just because I switched signatures.

This also means that we'd be creating two classes of digital signatures: ones that have been whitelisted by major AV vendors and ones that have not, which of course makes trying to steal the credentials for the former quite a juicy prospect, and would have the consequence of painting a nice "Hey, you should try to hack those guys" target on some developers' backs, when such information becomes public...

Besides, it is again my opinion that the presence of a signature (or UPX compression, or an empty resource for that matter) should really have no play when it comes to classifying something as malware, and I am therefore hoping that MalwareBytes can do a bit better than that to solve this specific issue...

Ok so my only option was to whitelist it for the specific engine detecting it. This has been done and should be forward looking for version changes. Its not as effective as whitelisting by signature but should work unless you drastically change things. This will be out next update.

The latest MinGW builds of Rufus (which is uploaded to VirusTotal straight from GitHub Actions) are still regularly flagged with Malware.Heuristic.1003, despite the fact that not much of the code has changed.

So, once again, I will have to reiterate my call for the MalwareBytes staff to do a bit better than report of whole class of binaries as potentially malicious, on account of a rule that should no longer, on its own, be used for such classification when you now have valid counter examples of legitimate executables that also match said rule.

The system did autolearn this executable and its not detected on client machines. Note on new executable after first scan of an unknown it cant take up too 24 hours to autolearn. We are still addressing the issue with virustotal reporting incorrectly because they have trouble reaching our cloud. I added another whitelist definition but not sure if that will help any.

3a8082e126