shmu26

Level 76
Content Creator
Trusted
Verified
Someone called me a few days ago, about their dead internet connection, and it turned out that WD had detected a "trojan", and after they performed recommended actions, the internet connection came back. But there was no reason to believe their system was actually infected, other than that. In other words, Defender was not the solution, it was the problem.

Some of Defender's advanced protections, when they falsely block a file, will completely delete it from the hard disk, rather than putting it in quarantine. That's annoying. This has happened to me several times.

It's too bad WD zaps legitimate Windows files, because the main reason we use WD is our belief that it plays well with Windows. Apparently, that belief is just another FP.
 

shmu26

Level 76
Content Creator
Trusted
Verified
i hate AVs...
I have basically lost patience with them, too. If your system is locked down, the AV is pretty much redundant, anyway.
The only case I can think of where they might help is if you got hit by update poisioning, like with the CCleaner fiasco. But these events are so rare, you will probably hear about them in the news at the same time your AV does.
 

Aerdian

Level 3
Verified
One time, a piece of legitimate software I use (I don't remember now what it was) wasn't working right. It would open, turn black, then crash. I then realized that Windows Defender was closing it because it thought it was legitimate. And whatever the software was, it's decently popular.
 

Andy Ful

Level 40
Content Creator
Trusted
Verified
One of the members on Reddit forum noticed that his application was suddenly detected as malware by Defender and next by Kaspersky too. I suspect that some new malware had similar behavior to the blocked files. When AV AI created the heuristic fingerprint it accidentally covered some legal files.
.
The interesting fact is blocking Windows DLL:
C:\Windows\assembly\NativeImages_v4.0.30319_64\Microsoft.C26a36d2b#\daf01e12fa59ed340363c44b7deff15e\Microsoft.CertificateServices.PKIClient.Cmdlets.ni.dll
I suspect that everyone on Windows 1803 (and maybe on other Windows versions) can have this DLL , but many had no issues at all. This can be related to the fact that this DLL is a native image, so it is created on each computer and is computer dependent and not signed. It is impossible to include such DLLs in the signature base (as whitelisted) until they are recognized as the false positives.
.
I think that similar problems can arise in the future in relation to the growing importance of AV AI.
 

RoboMan

Level 27
Content Creator
Verified
I have had specific FP's lately, and when it suggests me recommended actions, it gets bugged. I choose "skip" or "ignore" and WD doesn't seem to care, it just stays there waiting for action. And when I close it, I get messages about "Items have been detected, select an action".

Yeah I have selected an action for godsake, disable WD! :p
 

maka

Level 1
I've had issues with packer detectors, some dissasemblers/debuggers, etc, but in my opinion this is the "normal" behavior.

These FP are very strange. I imagine that is due to some asemblies such as "Microsoft.CertificateServices.PKIClient.Cmdlets.ni.dll" contain cryptographic functions, and the IA is not able to classify them correctly.

In reference to "Native Images":
Native images are .NET assemblies compiled with Ngen to native code (used as a cache system to improve startup time - JIT not need to compile it when they're necesaries -), something similar (but not the same) to when a compiler generate an executable from c++ code, for example.
Native images are processor dependent, not system/computer dependent, so in PCs with the same processors, the code (native images) will be the same.
 

Andy Ful

Level 40
Content Creator
Trusted
Verified
...
In reference to "Native Images":
Native images are .NET assemblies compiled with Ngen to native code (used as a cache system to improve startup time - JIT not need to compile it when they're necesaries -), something similar (but not the same) to when a compiler generate an executable from c++ code, for example.
Native images are processor dependent, not system/computer dependent, so in PCs with the same processors, the code (native images) will be the same.
I think that the final DLL code depends also on the .NET Framework version. Furthermore, the native image usage is more complicated, for example:
"A single assembly may need multiple native images for use in different applications or different scenarios. For example, the configuration information in two applications might result in different binding decisions for the same dependent assembly."
or
"Similarly, changes to a shared component or changes to computer settings might require many native images to be updated."
Native Image Generator (Ngen.exe)
 

shmu26

Level 76
Content Creator
Trusted
Verified
I think that the final DLL code depends also on the .NET Framework version. Furthermore, the native image usage is more complicated, for example:
"A single assembly may need multiple native images for use in different applications or different scenarios. For example, the configuration information in two applications might result in different binding decisions for the same dependent assembly."
or
"Similarly, changes to a shared component or changes to computer settings might require many native images to be updated."
Native Image Generator (Ngen.exe)
This stuff sounds almost as random as quantum particles!
 

maka

Level 1
I think that the final DLL code depends also on the .NET Framework version.
Yes ofcourse, but it's the same as when you release a new version of Hard_Configurator (good tool, by the way). For example, v3 will be different than v4 but all v4 executables will have the same code (with the difference that autoit not compile to machine code - native code -).

"A single assembly may need multiple native images for use in different applications or different scenarios."
Yes, it may seem complicated, but it is because of the way in which things are explained in the MS documentation. In a simple way this is:
If you write an app in .NET which need to connect to a web server, you need to use "System.Net.dll", "System.Net.Http.dll" assembly and probably also "System.Web.dll". These 3 assemblies will refer to anothers (for example, "System.Web.dll" reference to/use "System.dll" and "mscorlib.dll"), so your app need multiple assemblies. The same applies to native images.

For example, the configuration information in two applications might result in different binding decisions for the same dependent assembly.
This means that if you write a software, depending on the "target framework" ( .NET v4, v4.5) for example, it will use the corresponding assembly versions.

"Similarly, changes to a shared component or changes to computer settings might require many native images to be updated."
Native Image Generator (Ngen.exe)
Yes, native imges may be updated (recompiled) if you made changes in your software / system configuration, but the code generated will be the same (if the target framework is the same).



In short, as I said in the previous post, the machine code generated from a certain source code, only depends on the processor. For equal processors, the resulting code (native images in this case) will be the same.

I hope I have explained clearly. Regards
 
Last edited:

Andy Ful

Level 40
Content Creator
Trusted
Verified
Yes ofcourse, but it's the same as when you release a new version of Hard_Configurator (good tool, by the way). For example, v3 will be different than v4 but all v4 executables will have the same code (with the difference that autoit not compile to machine code - native code -).


Yes, it may seem complicated, but it is because of the way in which things are explained in the MS documentation. In a simple way this is:
If you write an app in .NET which need to connect to a web server, you need to use "System.Net.dll", "System.Net.Http.dll" assembly and probably also "System.Web.dll". These 3 assemblies will refer to anothers (for example, "System.Web.dll" reference to/use "System.dll" and "mscorlib.dll"), so your app need multiple assemblies. The same applies to native images.


This means that if you write a software, depending on the "target framework" ( .NET v4, v4.5) for example, it will use the corresponding assembly versions.


Yes, native imges may be updated (recompiled) if you made changes in your software / system configuration, but the code generated will be the same (if the target framework is the same).



In short, as I said in the previous post, the machine code generated from a certain source code, only depends on the processor. For equal processors, the resulting code (native images in this case) will be the same.

I hope I have explained clearly. Regards
Thanks for your interesting reply. I would like to be sure if we equally understand the phrase "native DLL is computer dependent". I understand this as the binary difference when you compare those DLLs byte by byte.
 
Last edited:

maka

Level 1
Thanks for your interesting reply. I would like to be sure if we equally understand the phrase "native DLL is computer dependent". I understand this as the binary difference when you compare those DLLs byte by byte.
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.
 
Last edited:
  • Like
Reactions: Andy Ful