Hi, here I hope to add some new experimental results to complement my previous thread, and revise some wrong conclusions in my previous posts. This time, 4 files will be used in our tests, including: Two files written in C++: EXE.exe and DLL.dll. EXE.exe will call a function in DLL.dll to do some simple computation. Two files written in C#: CallDll.exe and HelloDll.dll. CallDll.exe will call a function in HelloDll.dll to do some simple computation. They are just the files used in my previous tests. I have sent them to many members in wilderssecurity. This time, we start with McAfee Virusscan Enterprise (VSE). Of course, vse is not an anti-exe. But its hips module can help us to make many things clear. This is because, in VSE access protection, we can simply make some hips rules for blocking processes from reading specific files. This is important in our following tests. Test 1: Testing EXE.exe and DLL.dll (both written in C++) with VSE. We make a HIPS rule with VSE to prevent EXE.exe from "executing" DLL.dll. In such case, EXE.exe cannot load Dll.dll. Now make a new HIPS rule in VSE to prevent EXE.exe from "reading" DLL.dll. Now EXE.exe cannot load Dll.dll, either. The third HIPS rule in VSE will prevent EXE.exe from both "reading" and "executing" DLL.dll. Of cource, DLL.dll cannot be loaded. The log of access protection only shows that VSE prevents EXE.exe from "reading" DLL.dll. Test 2: Testing CallDll.exe and HelloDll.dll (both written in C#) with VSE. Making a rule to block CallDll.exe from "executing" HelloDll.dll. [CAUTION!!!] This time, the function in HelloDll.dll is properly executed rather than being blocked. Making a rule to block CallDll.exe from "reading" HelloDll.dll. Now HelloDll.dll is successfully blocked. The two experiments suggest that, C# dlls are different from C++ dlls. But why? These days I am looking for documents on this question on the Internet. I guess now I have found the answer. I guess this may be caused by the special mechanism of C#. When we "compile" a copy of C# code into an EXE or a DLL, that EXE (or DLL) does not contain native machine code that can be directly executed by the CPU. By contrast, it actually contains platform-independent Intermediate Language (IL) code. Then, what will happen when we double click an EXE written in C#? The documents on some websites say that the process will jump from the entrypoint of that EXE to the CorExeMain() function of mscoree.dll. Then CorExeMain() will "execute" the code in the original EXE. The IL code in the original EXE will be complied into native machine code in the granular of object function only when that function is called. This technique is called Just-in-Time (JIT) Compilation. Please note that here "object function" uses the definition in the field of Object-Oriented Programming (OOP). So, what will happen if our executable file calls a function in a C# Dll? I think, the IL code of that function will be read into the memory, compiled into native machine code, and then executed by CPU. I guess this procedure could be completed in the memory. So, it might be difficult for anti-exe programs from blocking a C# Dll. ============================================================================================== I think this explains that why Bouncer with ParentChecking enabled will generate the following log when we double click CallDll.exe: As you can see, Bouncer monitors that CallDll.exe calls many Dlls that may be related to .NET library, but does not monitor that CallDll.exe calls HelloDll.dll. This fact matches our discussion above well. I have conducted a test with the C++ dlls with Bouncer. It could be blocked properly. ============================================================================================== Different from Bouncer, in my tests, SmartObjectBlocker (SOB) could NOT monitor the behaviours of CallDll.exe calling the .NET libraries, after I write the following rule into Block/Dll.DB: Code: [%PARENTFILENAME%: CallDll.exe] Please let me know if I make some mistakes here, thank you. Anyway, when I test SOB with the C++ Dlls instead of C# Dlls, SOB also could successfully block the Dlls. ============================================================================================== To sum up: 1. C# Dlls are different from C++ Dlls. 2. It might be difficult to block C# Dlls for current anti-exe programs. Because the process only needs to read a C# DLL rather than execute it. It is mentioned in some posts that Faronics Anti-Executable could block C# Dlls. Well done! 3. Both Bouncer and SmartObjectBlocker CAN actually block C++ DLLs, as promised by their introduction.