I have a .Net application, in which a C++ DLL is embedded as a resource into the application.

When the .Net application is running, I will extract the C++ DLL to a temporary folder, and after that, my .Net code will immediately load the C++ DLL into the memory and use it by calling a function on the C++ via interop.

My concern is that with scheme like this, is it possible for an attacker to somehow (still) hijack the C++ DLL and replace it with his own compromised version? Or is it possible to hijack a C++ DLL after it has been loaded into the memory space?

If yes, how?

  • 1
    What is the attack scenario you want to defend against? If an attacker may inject code into your application at runtime, he can do pretty much whatever he wants, including forcing your application to read the DLL from another location instead of the temporary directory. Or he can modify the DLL in-memory after it's loaded, too. – Johann Aydinbas Jun 19 '19 at 7:57
  • I want to ensure that my C++ dll is always the genuine copy, and not replaced by hacker – Graviton Jun 19 '19 at 8:33
  • If an attacker may inject code into your application at runtime-- how is it possible, given that my .Net application has anti-debugging feature – Graviton Jun 19 '19 at 8:41
  • 1
    Anti debugging features will not prevent a determined reverse engineer from debugging your application. An interesting article about breaking even sophisticated techniques: oklabs.net/skype-reverse-engineering-the-long-journey. – bart1e Jun 19 '19 at 8:56
  • If your software is going to run in an uncontrolled environment (i.e. client PC somewhere) your solution is good enough I'd say. There is simply no way of guaranteeing anything more, that's the nature of computers. You are trying to achieve what multiple industries (AV, DRM, anti-cheat) have been unsuccessful at. An attacker would possibly have access to system-level code (via kernel drivers) while your application is user mode. You cannot win that battle. – Johann Aydinbas Jun 20 '19 at 15:43

It is possible for an attacker to replace the file on the disk by beating the race condition. When you write the file to disk, there is a delay until when the function you called which loads the DLL actually reads it from disk. An attacker can reverse your application and find out where you place the DLL, then in a no-sleep thread (maybe even multi-threaded) application can constantly spam to see if there is a new DLL placed, if there is, quickly replace it.

Another way to prevent you from reading it instead of just writing over it as fast as possible would be to get an operation lock on the file preventing you from reading it until the oplock handle is closed.

Second, if an attacker is at the same privilege level as your process, he can easily tamper with your process. You do not need to attach as a debugger or "debug" to inject code into your process. All an attacker needs to do is OpenProcess your process, WriteProcessMemory his shellcode, and then CreateRemoteThread the shellcode.

This is only one way of injecting code, there are SEVERAL more and you can't ever be 100% protected. Returning to your question whether or not an attacker can hijack your DLL, they most certainly can. They can overwrite portions of your DLL to hook or do another operation.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.