4 ms·

I think it's probably because the system doesn't see it as "copying", it sees it as "writing arbitrary data that just-so-happens-to-be identical to existing dat

I think it's probably because the system doesn't see it as "copying", it sees it as "writing arbitrary data that just-so-happens-to-be identical to existing data in another open file". It'd be tricky to figure out (and verify in a secure manner) that data is in fact being copied.

saghm 5y ago
I mean, if you're literally using the Windows utility for copying files (either by clicking copy/paste in Explorer or using whatever the DOS equivalent of "cp" is), it seem like it shouldn't be that tricky for them to make it work at least for the built-in AV, which is what the parent comment was talking about.
- dataflow 5y ago
  I think that depends on whether you want to trust already-executing programs or not. If you trust them, then sure, it's pretty straightforward: you just tell the AV what to scan vs. not. If you don't, then it's not: you have to either offload the copying to kernel-mode, or delegate it to a secured user-mode process, because otherwise a malicious program could just modify the buffer you're copying from. The former makes sense from a performance standpoint but the latter also makes sense from a security standpoint.
- makeitdouble 5y ago
  An issue is the original files are not guaranteed to be trusted. If for instance your were copying files from a flash drive or a network permission, it would seem natural to rescan every file that is copied to a local disk. From there the more the "outside"/"inside" line gets blurry (e.g. what if it was synced from Dropbox ? or data got injected by an arbitrary program etc.), the more it becomes justified to just scan every file moving anywhere. If the goal is indeed to scan files in the first place.
buraktamturk 5y ago
If I remember correctly the CreateFileEx win32 api takes a flag and template file handle to copy when creating a new file. Maybe the copy operations can use this api and expect AV software to ignore the operation. (I have no idea about the performance of such approach) Or maybe a syscall (preferably at filesystem level) that can be introduced for bulk copying purposes and AVs can ignore such calls.
- bmm6o 5y ago
  The template parameter is related to attributes, not contents. AV would still have to scan the data that is written to the file. -- [in, optional] hTemplateFile A valid handle to a template file with the GENERIC_READ access right. The template file supplies file attributes and extended attributes for the file that is being created.
cesarb 5y ago
> It'd be tricky to figure out [...] that data is in fact being copied. For other operating systems, sure, but the Win32 API has a function literally called CopyFile (and its variants CopyFileEx and CopyFileTransacted).

saghm 5y ago

I mean, if you're literally using the Windows utility for copying files (either by clicking copy/paste in Explorer or using whatever the DOS equivalent of "cp" is), it seem like it shouldn't be that tricky for them to make it work at least for the built-in AV, which is what the parent comment was talking about.

dataflow 5y ago
I think that depends on whether you want to trust already-executing programs or not. If you trust them, then sure, it's pretty straightforward: you just tell the AV what to scan vs. not. If you don't, then it's not: you have to either offload the copying to kernel-mode, or delegate it to a secured user-mode process, because otherwise a malicious program could just modify the buffer you're copying from. The former makes sense from a performance standpoint but the latter also makes sense from a security standpoint.
makeitdouble 5y ago
An issue is the original files are not guaranteed to be trusted. If for instance your were copying files from a flash drive or a network permission, it would seem natural to rescan every file that is copied to a local disk. From there the more the "outside"/"inside" line gets blurry (e.g. what if it was synced from Dropbox ? or data got injected by an arbitrary program etc.), the more it becomes justified to just scan every file moving anywhere. If the goal is indeed to scan files in the first place.

buraktamturk 5y ago

If I remember correctly the CreateFileEx win32 api takes a flag and template file handle to copy when creating a new file. Maybe the copy operations can use this api and expect AV software to ignore the operation. (I have no idea about the performance of such approach) Or maybe a syscall (preferably at filesystem level) that can be introduced for bulk copying purposes and AVs can ignore such calls.

bmm6o 5y ago
The template parameter is related to attributes, not contents. AV would still have to scan the data that is written to the file. -- [in, optional] hTemplateFile A valid handle to a template file with the GENERIC_READ access right. The template file supplies file attributes and extended attributes for the file that is being created.

cesarb 5y ago

> It'd be tricky to figure out [...] that data is in fact being copied. For other operating systems, sure, but the Win32 API has a function literally called CopyFile (and its variants CopyFileEx and CopyFileTransacted).