Does it matter which platform a file is scanned on for malware?

Question

Different operating systems use different file types and file systems. Does it make a difference to a virus scan which system it is being run on and what type of malware it's looking for? I ask because the way the files are archived may be different, for example Android's apk is in an archive so would a program like Windows Defender (running on Windows) know how to examine the contents?

In simple cases an AV wouldn't have a problem, for example an AV running on OS X and malware arriving as an .exe would raise a red flag but what about an infected RPM on Windows; Windows doesn't even know how to handle RPMs so would there be a point in scanning such files in hopes of not transferring it on to a Linux machine?

EDIT: I've seen some AVs with the option to scan inside archives, so this implies the AV would have to know how to correctly open the archive? Can viruses hide inside archives the AV doesn't know how to handle? If a archive is password protect (i.e. encrypted) than is there anything to AV can do?

Answer 1

Your question potentially applies to many different situations so it is difficult to answer it definitively. Ideally, you should make your question more specific.

As a general rule, file scan signatures target whatever the deployed package is. So, it does not matter whether it is an RPM or EXE or what. Whatever form the malware is deployed in, will be targeted for the scan.

Answer 2

In short no, it does not matter for most cases, including unencrypted archives. Malware detectors snipe for signatures, which are basically chunks of data. Unless the platform malforms the somehow data, you should be ok.

That being said, theoretically, you may run into trouble with endianness if the AV doesn't interpret the data correctly. But in most cases the AV (or it's pre-processors) is platform-aware and does endianness translation if neccessary.

Still, your question is quite wide and could use a little more specification.

Answer 3

Does it make a difference to a virus scan which system it is being run on and what type of malware it's looking for?

Not unless you include exotics. The problem boils down to if a product supports engines effectively scanning the target from the perspective of the intended environment.

All malware we scan for exhibits some structure compatible with a target environment. Compatible doesn't mean good or bad; it just means that for any scanner, accessor, etc, that object has an obtainable feature other than existing as an opaque object with no discernible purpose (which is, incidentally, what a properly-encrypted container strives to be).

Then, because it has features in some environment, you can detect those features, and the decision really relies on whether or not a protection product is going to worry about it.

Would Windows Defender know how...?

Yes, now or with effort. See above.

...would there be a point in scanning such files...

Yes. Detecting Malware Across Operating Systems

...this implies the AV would have to know...

Yes, most certainly consisting of custom, sandboxed or hardened extractors.

...hide...?

Yes. That's the game.

...Encryption; can anything be done?

Sure, but often not, for reasons around Time Complexity

But I really want a yes!

Okay. We've been assuming the host has complete, unchallenged, universal control. To get your "yes", the anomaly candidate (by virtue of its properties, like existing) has to cause the host to lose control of the scan. Good luck.

Answer 4

I agree with the others that this question is super broad, however I can offer the following:

1. Some AV engines short-cut their scans and will only scan those that it sees as "executable" (or have just been renamed to be executable) for that platform. In this instance unless it's a known executable file extension it will probably be missed.

2. APKs are just ZIP files, some anti-virus products ignore what the file extension claims it is, will detect APKs for what they are (ZIP files of a special file path layout) and will be able to read ZIP files anyway. Avira calls this "Smart extensions" (https://www.avira.com/en/support-for-home-knowledgebase-detail/kbid/179)

3. It depends very much on the virus signatures of the AV engine, if Windows Defender doesn't have any other signatures other than for files affecting the Windows platform then scanning files from other platforms would be pointless. I believe Clam-AV can detect (specifically as in has signatures for) some Windows viruses.

4. You specifically mentioned Windows Defender :

   Windows Defender in Windows 8 resembles Microsoft Security Essentials and uses the same virus definitions.

   https://en.wikipedia.org/wiki/Windows_Defender

   but beyond that I couldn't find out if they make their own definitions or sub-license someone else's to know whether these are Windows only signatures.

5. A good site to learn about AV effectiveness is av-comparatives.org, they list all of the different AV products and how many viruses they caught.

6. If an archive is password protected then it can't be scanned, if it's an archive you are opening then you will have the password.. however I suppose malware could embed a password protected archive, but then the malware packer itself should get detected.

7. AV tends to rely more on heuristics now anyway due to the limitations of signatures. The heuristic analysis would be platform specific. So there are clear advantages to using AV for the designed platform.

8. Most AV products offer the ability to report previously unseen files for them to analyse when they are executed, I doubt many APKs therefore would have made it up to Avira's cloud based lookup.

9. While it's true Windows doesn't have native support for RPM files, that doesn't mean an anti-virus vendor (or any other program) couldn't program support for them. Check with your AV vendor to see what file types they support. The ZIP program 7-ZIP for instance has RPM unpacking support so don't assume because Windows doesn't natively know a file type that a program cannot provide some support for it.