C# DLLs are different from C++ DLLs. Bouncer and SOB can actually block C++ DLLs.

Discussion in 'other anti-malware software' started by Online_Sword, Nov 27, 2015.

  1. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    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!
    :thumb:

    3. Both Bouncer and SmartObjectBlocker CAN actually block C++ DLLs, as promised by their introduction.:)
     
    Last edited: Nov 29, 2015
  2. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,629
    Location:
    Toronto, Canada
    Is it possible that C# DLLs are run in user-mode and therefore not even entering kernel-mode and therefore not being picked up by the filtering done by Bouncer and SOB? I really don't know, but that question came to mind after reading your post.

    I am still curious to understand the difference here between C# DLLs and C++ DLLs and curious to see your continued research into this. I am not a developer, so it is far beyond my understanding. We might need someone who is familiar with .NET programming (I assume C# relates to that) and who is also familiar with kernel level programming.

    You could try asking Andreas from SOB who is a master of kernel-mode programming or also Florian from Bouncer, also a master at kernel-mode. But I do not know if either of them have extensive .NET or C# programming knowledge, I just don't know.

    Thank you for your continued research into this and for sharing your findings. It will be interesting to understand more about the difference here between these two types of DLLs.
     
  3. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,060
    Thnx for explaining it @Online_Sword
    That's why Malware Defender logged only .NET dlls being loaded and SRP didn't stop it.
     
  4. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
    Did you try blocking C:\Windows\Microsoft.NET in SRP?
     
  5. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,060
    No, I didn't try blocking whole .NET. I assume that some software that I'm using wouldn't work correctly if I did that.
     
  6. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
    @Minimalist I am not using .dot Net software and created the rule in Windows 10 with no problem. Waiting for Online_Sword to provide the test executable and C-sharp test dll. Thanks for testing it against SRP. :thumb:

    @Online_Sword great find BTW :thumb: :thumb: :thumb:
     
  7. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,060
  8. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    4,950
    Location:
    USA
    Have these .dll's been tested against AppGuard, and Bouncer yet?
     
  9. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    I know nothing about the user-mode and kernel-mode.:p But I think Bouncer and SOB should be able to block both user-mode and kernel-mode drivers. So I think this is not the reason that Bouncer and SOB cannot block C# DLLs.

    In my opinion, C# DLLs are more like Java Bytecodes, which contain codes that cannot be directly recognized by the CPU, than regular DLLs (C++ DLLs). When a function in a C# DLL is called, its intermediate language (IL) code will not be executed directly, because CPU cannot "understand" IL codes. Instead, the IL code will be transformed to native machine code in the run time dynamically with the JIT (just-in-time) technique, and only the native machine code will be executed. So, I think, in fact the C# DLLs are not directly executed. They are only being read into the memory. I guess this is why C# DLLs are not prevented by Bouncer and SOB from "executing" -- because those DLLs are not executed.:)

    I think so.:)

    Yes. I have tested the C# DLLs with AppGuard, Bouncer, EXE Radar Pro, SecureAPlus, and SmartObjectBlocker. None of them can block the C# DLL as long as the C# EXE is whitelisted. Please refer to https://www.wilderssecurity.com/thre...lications-from-executing-unknown-dlls.380122/ for more test results got by other members here.

    Regarding the C++ DLLs, I only test them with Bouncer, SmartObjectBlocker, and Comodo. Bouncer and SmartObjectBlocker can actually block the C++ DLLs.:)

    I have sent you a PM.:)
     
    Last edited: Nov 29, 2015
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    The answer is the difference between static and dynamic .dll loading. Below is an excerpt on the discussion from here: http://stackoverflow.com/questions/3628798/what-is-in-a-dll-and-how-does-it-work

     
    Last edited by a moderator: Nov 29, 2015
  11. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,629
    Location:
    Toronto, Canada
    @Online_Sword Can you please PM me with a link to download your latest test files which includes the C# and C++ binaries? Thank you
     
  12. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    4,950
    Location:
    USA
    Can C# dlls. be executed using rundll32 like C, and C++ dlls? If you were able to extract the .dll from the .exe, and run it with rundll32 then I bet it would be blocked by AppGuard, and Bouncer then. Have you checked a few HIPS to see if they can block the .dll file when ran from the .exe? If the .exe is not allowed to run then the .dll will obviously not be able to execute, but I know that everyone is already aware of that. I know your test is to isolate a product's ability to block C# .dlls. Try running the .dlls using rundll32 if that is possible. I thought all .dlls could be executed using rundll32, but i'm not so sure now after reading a few post on this matter. I will read your link above later tonight when I have more time. Maybe you have already covered my questions.
     
  13. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    4,950
    Location:
    USA
    Bouncer is suppose to block code even if it is only loaded in memory. Bouncer does on my machine anyways. There must be more to it than that. You could also try Execubits memory protection to see if it is able to stop the .dlls from loading. The memory protection is all done in the kernel. If the .dlls appear in a process manager when using Execubits memory protection then make sure they are not zombie processes. Some of my test showed that .dlls were able to load in Process Explorer, but they were empty processes. They tried running, but were not able to. I guess they loaded just long enough to be detected before being shut down. The zombie processes should show 0k memory being used.

    Edited 11/29 @ 7:29 pm

    btw.. Don't try Execubit's memory protection with Eset. They are not compatible on my machines with Windows 7X64. I'm not sure about other OS's. If you try them together then you better use a test machine.
     
    Last edited: Nov 29, 2015
  14. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
    My findings with Software Restriction Policies

    Running it from ACL protected folder allows it to run. Software Restriction Policies do not block the execution either. Again compliments for @Online_Sword :thumb::thumb::thumb:

    Adding a path SRP rule for C:\Windows\Microsoft.NET\Framework blocks the executable to load dot Net dll's (as expected), so HelloDLL.dll does not run either. ;) This rule is only viable when not running software requiring dotNet installed.

    When it the DLL is downloaded from the internet and it is run with this ADS marker the following error is returned:
    Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly :)
     
    Last edited: Nov 30, 2015
  15. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    1,629
    Location:
    Toronto, Canada
    So what we do know so far is that these C# DLLs are not being filtered by SmartObjectBlocker, Bouncer, SRP, AppGuard, and possibly other similar software. As I understand, Faronics AE does seem to filter these. While I don't understand the under-the-hood functionality of this from a programming perspective, what we need here is a way to mitigate against this as @Windows_Security has already suggested some ideas to help mitigate for users that are using SRP.

    Bouncer seems to block the C++ DLL example efficiently using the parent check feature. But the C# DLL does not seem to be filtered.

    For Bouncer, we can follow Kees' initial suggestion from post #4 which is to block the C:\Windows\Microsoft.NET\ folder. Obviously, for some users who rely on .NET, it would not be a good idea to block that directory entirely. But what might be a good idea would be to block access from user-space.
    Code:
    [WHITELIST]
    C:\Users\*\Downloads\TestDLL\CSharp\CallDll.exe
    [PARENTWHITELIST]
    C:\Users\*\Downloads\TestDLL\CSharp\CallDll.exe>*
    [PARENTBLACKLIST]
    C:\Users\*>C:\Windows\Microsoft.NET\Framework\*
    From the example, I have a rule in the [WHITELIST] section that ensures that CallDll.exe is allowed to execute. In the [PARENTWHITELIST] section, I have a rule that allows CallDll.exe to execute and be free to start additional processes literally anywhere on the system (obviously not normally a good idea to do) for testing purposes. And in the [PARENTBLACKLIST] section, we nip everything in the bud. Anything from User directories in not allowed to access anything from the .NET directories.
     
  16. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    I am sorry for the delay in response.

    My test files will load the DLLs dynamically. User is allowed to specify the path and the file name of the DLLs in the run time.
    Thank you for the literature you provided.:)

    I am not sure but I am afraid that we cannot. C# DLLs are much different from the regular DLLs containing native machine codes. The IL codes, just like the JAVA bytecodes, cannot be understood by CPU directly.

    @Windows_Security :

    Thank you for your test on SRP.:thumb:
    But what is ADS marker?

    @WildByDesign :

    Thank you for sharing your Bouncer rules.:thumb:
     
  17. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
  18. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
    EMET 5.5 blocks C# dll's when using ASR, see example by adding mscoreie.dll

    I disabled tray icon, to stop getting mscoreei.dll messages being blocked by EMET

    upload_2016-2-10_22-5-37.png
     
    Last edited: Feb 11, 2016
  19. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,079
    Location:
    Netherlands
    @Online_Sword

    I think it should be possible to block access of mscoreie.dll by parents originating from user space with SOB and Bouncer.
     
Loading...