Advice Request Did you have false positive issues when using Windows Defender?

[Andy Ful]

Thanks to you for having read it

The term "computer dependent" is very broad and can mean many things, so it depends on what you want to say with it.
If with computer dependent you mean that in a PC runnning Windows 10 under Intel's x86 architecture, one particular native image is different from another present on a Windows 7 PC with the same processor architecture, in this case we would not agree.
However, if what you want to say is that a native image depends on the processor (x86, x64, ARM...) and not on the OS, then we would agree.

Neither of the above. If I correctly understand, you want to stress the strict dependence of the native DLL code on the processor architecture. But, this does not mean that the binary content of the native DLL cannot change after changing some shared components or computer settings. That is how I interpret the info from the Microsoft documentation: "Similarly, changes to a shared component or changes to computer settings might require many native images to be updated."
.
If the file is flagged by AV as malicious, then the file fingerprint / hash is added to the blacklist. The hash / fingerprint is calculated just from the binary file content.
The AV AI can easily flag the file as malicious when all the below conditions are fulfilled:

• it is involved in infection chain,
• it is unsigned,
• it is not on AV whitelist,
• it is not common on clean machines.

The last point can happen if the DLL binary content depends also on some computer-specific factors (computer settings, shared components, etc.), so accidentally, some native DLLs may not be common on clean machines.
.
Regards.

 

[maka]

Hi Andy,

It's a pity we do not agree. I do not hve much time, so I'll try to be concise.

Native code = machine code = processor dependant. You can read more here: What is native code? - Definition from WhatIs.com

.NET assembly = .NET dll = precompiled code (MSIL) + meta information (metadata) -managed by CLR, compiled to machine code (on runtime) by JIT- = STATIC code (only change if you modify the source code).

MSIL is similar to Java's bytecode.
You can write an assembly in many languages: C#, F#, VB .NET, C++/CLI...

Native image = .NET assembly compiled to machine code. More info here: Basics of Ngen.exe (Native Image Generator) in .Net

Similarly, changes to a shared component or changes to computer settings might require many native images to be updated.

From Microsoft documentation: Ngen.exe (Native Image Generator)
"The following changes to a computer's settings and environment cause native images to become invalid:" (invalid = updated = recompiled)

• "The version of the .NET Framework". Explained with the Hard_Configurator analogy => .NET 4 != .NET 4.5 != NET 4.6, so a <.NET 4 assembly> != <.NET 4.5 assembly>
• "The version of the operating system, if the change is from the Windows 9x family to the Windows NT family". Oviously we are speaking about NT family.
• "The exact identity of the assembly" = AssemblyCultureAttribute (language and dialect, calendar, day format...), AssemblyFlagsAttribute (JIT compiler options), AssemblyVersionAttribute (asembly version ej: 2.0.1).
• "Security factors" = security properties (embed in the source code) used by JIT.

As you can see the variables that make sanse are the last two, but if you change any of these (you have to make changes in the source code), the assembly will not be the same. The final native image will not be the same.


Maybe I'm wrong but In my opinion none of us know how the WD IA engine works internally, so we are speculating. I think that none of your 4 points are wrong but IA is a complicated thing that use complex mathematical algorithms.
The IA engine of WD is developed by people and they are no perfect, so the can make mistakes and software can have bugs. Also I think that the AI engine take hundreds of parameters to classify files. For example:

• PE sections, number of PE sections, invalid / unknown sections...
• Entropy.
• Presence of packers.
• File / Rgistry manipulation.
• Network connections.
• Function calls.
• Strings.
• ... and much more

Also as you can see, not only native images are detected as viruses, but also VBox files, AutoHotKey (similar to Autoit)... so the problem are not native images.

Finally, I'm sorry to tell you that this will be the last reply to this thread, since I do not know to what extent this conversation can be productive.

I hope this is the beginning of a good friendship.
Regards.

 

[Andy Ful]

Hi @maka
I think that it is not that we do not agree. In fact, I agree with everything you posted. Simply, my posts were concentrated on native image DLL (ni.DLL) as an array of bytes on the disk, and your posts were concentrated on ni.DLL as a piece of optimized machine code.
Our points of view are not contradictory. As you noticed in your previous post, changing some computer settings and environment can cause the ni.DLL to be recompiled. I simply take another step by saying that this also changes the binary content of ni.DLL as an array of bytes on the disk.
I called the above 'computer dependent', but you can call it 'partially dependent on computer settings and environment', etc.
I think that I could be wrong if any ni.DLL was always present on many clean machines.
I conclude that sometimes the ni.DLL can happen to be uncommon on the clean machines and this can be taken by AV AI as the potentially malicious factor.
Regards.

 

[valvaris]

No FP issues here.

Using:

Windows Defender with Windows 10 Build 1803 (current Patch)
Adguard Desktop (current Patch)
GlassWire Elite (was on Steamsale over 70% savings)
Windows Firewall (Block all inbound with rules for some basic apps.)

 

[illumination]

I have not ever had FP issues with Defender, but then again, i do not drown my system in applications either, so there is much less a chance of coming across one.