Is Rufus Available For Android

[Elwanda Menhennett]

Onceagain, 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.

I think that's coz a malware does exists by the name of rufus. Its around 300MB. I downloaded it once by mistake while trying to download the real Rufus and got my system infected. Had to wipe my drive and do a clean OS install.

If AntiVirus solutions were based, even remotely, on malware sharing the same name as a legitimate application, or even including the legitimate binary as part of their payload (which can also happen, in order to trick end users into thinking that they are running the application after malicious content has been installed), to declare legitimate executables as malware, they'd be doing a pretty poor job, as any malicious actor could create something like a malicious `word.exe`, that would result in the official Microsoft Word being flagged as malicious.

Thankfully, I am not aware of a single AntiVirus solution that can be tricked that easily, precisely because that's the basic of what one would expect security solutions not to be able to be fooled with.

Humans on the other hand will be tricked into thinking that, because malicious software shares the same name as legitimate one, they are the same thing, and not look any further as to whether they got it from the official website or whether its uses a digital signature that is valid and that bears the expected name.

Also, considering that Rufus should be famous to be a very small executable (it's currently a 1.3 MB download), if you are downloading a 300 MB executable, you should be asking yourself some questions...

3a8082e126