So yes, this is probably a major concern for a product that actually cares about their user's performance.

How much wasted money could they save each year by changing this setting? You need to speak their language. If you can legitimately show that it costs 15k per year to have that checkbox on, they will act.

The only sandbox I apply to this "realtime scanning" is to disable it wholesale. Instead of this waste of a Moore cycle Microsoft should add a few more patch days.

https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

> The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers and cryptors, full system emulators and interpreters for various architectures and languages, and so on. All of this code is accessible to remote attackers.

> NScript is the component of mpengine that evaluates any filesystem or network activity that looks like JavaScript. To be clear, this is an unsandboxed and highly privileged JavaScript interpreter that is used to evaluate untrusted code, by default on all modern Windows systems. This is as surprising as it sounds.

[1] https://www.drivereasy.com/knowledge/antimalware-service-exe...

That means many written files (which won't be read for a long time) can be scanned hours later.

Others can be checked for matching a "known good" hash whitelist which can be downloaded from the net. That should cover all kinds of files which are parts of software distributions etc.

That leaves very few files which really need real time scanning.

Seems to me that the "system police", as it were, needs access to the system it is policing.

I agree with your sentiment that sandboxing will require more complex interactions between sandboxes for antimalware suites to act on pre-existing threats (and minimizing the required privileges for the 'SYSTEM'-level process that must act on those threats.)

[1]: https://www.engadget.com/2016/06/29/google-symantec-antiviru... [2]: https://www.engadget.com/2016/01/13/trend-micro-security-pas...

This doesn't make sense to me. It may have been easier to accomplish within the author's skillset, but it seems to me that the more beneficial approach would be to modify Tavis’ code to report the correct version of Windows.

Originally the author didn't hook and let Defender call the native version check APIs, which (correctly) reported Windows 10. Apparently there was extra initialization code in that case that failed to run in a sandbox. The fix was to reproduce the hooking code, in Rust, to report XP as the underlying Windows version.

[1] https://github.com/taviso/loadlibrary/blob/master/peloader/w...

- Tavis' original code ran on Linux, where there's no correct version of Windows

- it actually worked with the old code; it's only broken when msmpeng sees the new Windows version

- the old code is not in use at all (the whole thing was ported to rust), which didn't have a good DLL interception library

So it would seem the suggestion to modify the old code wouldn't help.

Just tangential, but [are we sure], we added enough obnoxious UI-Dialog so that the usual user will [Allow everything ?] once shelled to oblivion with [Can you Confirm] boxes? After all, real secure Security, is when you shirk the responsibilty as fast as possible by getting a User to act dumb or get some overworked [Administrator started]?

I think the one other useful sandboxing-related tool for Windows comes from Project 0, and they are for assessing the security of a product that uses one: https://github.com/google/sandbox-attacksurface-analysis-too...

as well as thoughts about Rust on Windows.

Running Windows Defender in a sandbox will mitigate its own vulnerabilities, but also make it easy for viruses to hide from it.

If the sandboxed process is compromised, all you can do is read a file that you already had access to (because it's your exploit), and lie about the scan result. That is not terribly exciting.

As the parent process doesn't do very much other than setup handles and read simple results from the sandboxed process, it is significantly harder to compromise.

This is the same model that browsers use. Your browser needs access to all your files to manage Downloads and so on, but all the dangerous stuff happens in the sandboxed renderer process. It is not "easier to hide from it", because the process that intercepts i/o still runs at the same privilege.

If the sourecode for Windows Defender was mostly open source, with only critical portions linked in, then it would be possible to improve the portions that integrate the libraries into the system without moving each process used by it into some sort of wrapper.

There is not even a need for the sourcecode to be "free", merely that it is able to be viewed and alterations contributed back to be available to anyone who has paid for Windows.