Timeline for How are anti viruses so fast?
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 22, 2017 at 14:56 | comment | added | Doktor J | Since a couple of people have asked about scanning executables vs checking a hash on them: To compute the hash on a file, you have to read the entire file; however, proper executable scanning does not need to read the whole file, just key parts. If you have a 100+MB executable, that can mean the difference between reading 2MB of it or reading 100+MB -- multiply that by however many large executables happen to live on a system, and you should be able to see where the performance improvement comes from. | |
| Nov 17, 2017 at 4:33 | comment | added | le3th4x0rbot | @aroth This might be one of those cases where big-O notation hides important constant factors... | |
| Nov 17, 2017 at 4:08 | comment | added | ycomp | so does removing ransomware fall into the AV sphere? or the anti-ransomware software sphere generally? not preventing encrypting, just removing it once detected before it can even try to encrypt | |
| Nov 17, 2017 at 4:06 | comment | added | George Y. | @ycomp There's difference between detecting ransomware binaries (this is what AV engine is doing), and preventing ransomware from encrypting files (this may be an additional component). | |
| Nov 17, 2017 at 4:04 | comment | added | George Y. | @TomášZato you can scan most clean executables without reading the whole file from disk. Obviously you need to read some data. | |
| Nov 17, 2017 at 4:03 | comment | added | ycomp | @GeorgeY. but what happens when the AV vendor has a separate anti-ransomware tool (I use bitdefender av)? do they cripple the free av in regards to ransomware detection then? | |
| Nov 17, 2017 at 4:01 | comment | added | George Y. | @ycomp it is not necessary. All major AV vendors detect adware, spyware and other malware - not just viruses. And separate anti-ransomware is not necessary either. | |
| Nov 17, 2017 at 3:30 | comment | added | ycomp | why is it necessary to have a malware scanner like Malware Bytes? why don't AV vendors just include that in their virus scanning? or do they? And why is a separate anti-ransomware necessary? | |
| Nov 16, 2017 at 21:12 | comment | added | Michael Kay | @aroth Two operations might both be O(n), but one might still be 100 times faster than the other. | |
| Nov 15, 2017 at 14:19 | comment | added | JeopardyTempest | @GeorgeY. So if a user deactivates their AV application for a short period, does the AV determine that all files need to be rescanned (or checked by hash???)... or does it actually leave some minimal form of monitoring active... or does it end up undermining the long-term security leaving most AV to believe files should still be the same when they no longer may be? | |
| Nov 15, 2017 at 11:55 | comment | added | Tomáš Zato | You say that reading the file from HDD would be expensive operation. But how do you scan an executable without reading it? | |
| Nov 15, 2017 at 2:50 | comment | added | George Y. | @PeterA.Schneider there are many possible ways. For example, since most anti-viruses already include the file system driver intercepting file operations, such driver may simply reset the flag in the internal database of already scanned files. | |
| Nov 14, 2017 at 23:15 | comment | added | thomasrutter | @PeterA.Schneider it is true that a file could be modified without changing size and setting modification time back. Virus scanners ought to re-scan files at regular intervals (even if not every time). Not the whole executable would need to be scanned. | |
| Nov 14, 2017 at 23:12 | comment | added | thomasrutter | Another reason hashing the file would not be suitable is that it would be trivially easy to subvert, as most file types, including executables, will tolerate adding random bytes at the end of the file with no change in how the file works. Or at the start of the file, for ZIP/JAR/etc. | |
| Nov 14, 2017 at 8:24 | comment | added | timuzhti | @PeterA.Schneider Aren't write operations monitorable, for lack of a better word? | |
| Nov 14, 2017 at 8:07 | comment | added | Peter - Reinstate Monica | The question remains how you detect that a file on disk has changed since the last scan. It is trivial to reset file modification date, so that is not an indicator; and a sophisticated infection could conceivably leave the file size unchanged. That leaves only a hash as a criteria. | |
| Nov 13, 2017 at 14:30 | comment | added | David Mulder | @aroth Because "for example when scanning executables, only certain parts of it need to be scanned. This minimizes disk reads, and improves performance." | |
| Nov 13, 2017 at 13:48 | comment | added | aroth |
I don't think this answer fully addresses the main question of how the performance is achieved. In particular, "most AV engines should scan a large clean executable file faster than calculating hash on it" seems to merely perpetuate the OP's question. How exactly is it possible to scan a large file faster than computing a hash/checksum from it? Both operations would appear to be O(n).
|
|
| S Nov 13, 2017 at 6:51 | history | suggested | eclipz905 | CC BY-SA 3.0 |
change disclaimer to disclosure
|
| Nov 13, 2017 at 4:13 | review | Suggested edits | |||
| S Nov 13, 2017 at 6:51 | |||||
| Nov 12, 2017 at 13:43 | comment | added | Zanon | I've heard many times about this "hash detection". Thanks for confirming this is non sense. | |
| Nov 12, 2017 at 12:33 | vote | accept | Harry | ||
| Nov 12, 2017 at 8:41 | comment | added | Skaperen | a random number put in the middle of a message in an executable when that file is stored makes each file have a different hash. | |
| Nov 12, 2017 at 3:51 | history | answered | George Y. | CC BY-SA 3.0 |