If the file was digitally signed with a valid signature we could whitelist that signature for all builds. 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).

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). 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. Having empty resource sections for example is something that is seen in malware.Īnd 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. 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. 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. The file was generated in a completely transparent fashion by MinGW through GitHub Actions, using a fairly standard build process. 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.Īlso the file has a rcdata resource section but they are all empty. 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. The above is for the UPX decompressed version of above (executable can be found from the artifact at ).

It sure does, along what I can only qualify as all the other 16 idiotic engines who clearly have no clue about what they're analysing and also report a false positive: Endpoint Detection & Response for Serversĭo you know if it still hits if its not upx packed?

Rufus download for chromebook