Process Protection
-
I wonder if something like taking the total number of called dlls after the process starts and whether it increases every 30 seconds or if it does, end the process, can partially prevent dll injection?
To protect an app against
- packet sniffing: Use ssl.
- dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
- stack overflow and DOS attacks: Code nicely and test excessively.
That's as general as I can get. You'd have to share more details and ask more specific questions, if you want more detailed answers.
-
To protect an app against
- packet sniffing: Use ssl.
- dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
- stack overflow and DOS attacks: Code nicely and test excessively.
That's as general as I can get. You'd have to share more details and ask more specific questions, if you want more detailed answers.
@Axel-Spoerl said in Process Protection:
dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
That's just way too simplistic given for example windows shell hooks.
-
@Axel-Spoerl said in Process Protection:
dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
That's just way too simplistic given for example windows shell hooks.
@SamiV123
You're welcome to share better ideas! -
@Axel-Spoerl said in Process Protection:
dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
That's just way too simplistic given for example windows shell hooks.
-
@Axel-Spoerl said in Process Protection:
dll injection: keep intruders off your system and don't dynamically load libraries from untrusted sources
That's just way too simplistic given for example windows shell hooks.
@SamiV123 said in Process Protection:
given for example windows shell hooks.
that goes towards uninvited moderations to your system. In that case the general advice goes: don't run closed source software. Don't use a known-bugridden (virus attracting) operating system.
-
@SamiV123 said in Process Protection:
given for example windows shell hooks.
that goes towards uninvited moderations to your system. In that case the general advice goes: don't run closed source software. Don't use a known-bugridden (virus attracting) operating system.
@TomZ It's not that simple. You guys think in enterprise terms, where the dangers are usually from the outside, but it's not always a problem with buggy OS or software. An app sometimes has to protect itself from its user with full admin access. For example dll injection is a common way to cheat in multiplayer games. Another example is workarounds for DRMed streaming apps or cracking in general.
OP really has to be more specific as to what the use case is.
-
I don't really have any better answers (I think @Axel-Spoerl summed it up pretty well), but I'll add a couple of additional thoughts to consider.
-
What license are you using? Because if you're using Qt under the LGPL, then that license protects the rights of everyone else to modify the Qt DLLs your app is using. That is, if you prevent people from injecting their own code into the Qt DLLs, then you would be in violation of the LGPL license. Of course, if you're using a commercial Qt license, then go for it (and thank you for contributing to Qt's development costs :)
-
Assuming you are using a commercial Qt license, and can prevent, or at least detect, code injection, you still must (as @Axel-Spoerl suggested) use end-to-end encryption. Especially on Windows, because it includes the Windows Filtering Platform (WFP), which allows applications (with admin permissions) to install network shims as kernel-mode drivers, that can see all network traffic in and out of the OS, including your app, with no way for your app to know about it. The functionality is intended for things like virus scanners, but can be used for just about anything (I've used it for transparent email capture for a bespoke product my boss wanted for his own desktop use a decade ago).
-
Assuming you took care of #1 and #2, make sure your app explicitly verifies the peer TLS certificate itself - not just relying on the OS. Person-in-the-middle attacks are even easier than #1 and #2 if someone has access to the OS.
Good luck.
-
-
@TomZ It's not that simple. You guys think in enterprise terms, where the dangers are usually from the outside, but it's not always a problem with buggy OS or software. An app sometimes has to protect itself from its user with full admin access. For example dll injection is a common way to cheat in multiplayer games. Another example is workarounds for DRMed streaming apps or cracking in general.
OP really has to be more specific as to what the use case is.
@Chris-Kawa said in Process Protection:
An app sometimes has to protect itself from its user with full admin access.
The reason I limit myself to scenarios where the threat is unauthorized access to the computer is because the moment an attacker has local access there is nothing you can do. You have per definition lost.
Big security firms that send their employees overseas have the practice that a laptop that comes back is simply destroyed afterwards because it is impossible to find all types of modifications that could possibly be made to turn your device against you. Naturally, those people are ALSO looking at hardware modifications.
The software world is even more adversarial and a static piece of software is not going to be capable of detecting a large class of attacks. TV talks about living software, which is what you'd need. And that obviously is quite far out of our reach.As a result, threat-models on desktop style operating systems stop at people having physical access.
For mobile operating systems we stop at the user rooting the device. -
@Chris-Kawa said in Process Protection:
An app sometimes has to protect itself from its user with full admin access.
The reason I limit myself to scenarios where the threat is unauthorized access to the computer is because the moment an attacker has local access there is nothing you can do. You have per definition lost.
Big security firms that send their employees overseas have the practice that a laptop that comes back is simply destroyed afterwards because it is impossible to find all types of modifications that could possibly be made to turn your device against you. Naturally, those people are ALSO looking at hardware modifications.
The software world is even more adversarial and a static piece of software is not going to be capable of detecting a large class of attacks. TV talks about living software, which is what you'd need. And that obviously is quite far out of our reach.As a result, threat-models on desktop style operating systems stop at people having physical access.
For mobile operating systems we stop at the user rooting the device.@TomZ said in Process Protection:
As a result, threat-models on desktop style operating systems stop at people having physical access.
Well, not really. You're again in that enterprise level of thinking. Highly depends on the sector you're in. If what you're saying was universal the entire gaming industry wouldn't exist and wouldn't be the biggest entertainment medium in the world as it is.
Sure - as soon as someone puts their hands on something they can do whatever they want or are able to do with it. If it happens to be a community of very savvy field experts then you're right - you've lost. But if you're protecting mostly against 12-year olds copying dlls after reading a post on reddit there's actually a lot you can do to protect against 99.999% of them. You'd be surprised what a deterrent it is in some scenarios to simply change a file extension.
So basically yes, but no. You're right but it doesn't always matter. It depends :)
-
@TomZ said in Process Protection:
As a result, threat-models on desktop style operating systems stop at people having physical access.
Well, not really. You're again in that enterprise level of thinking. Highly depends on the sector you're in. If what you're saying was universal the entire gaming industry wouldn't exist and wouldn't be the biggest entertainment medium in the world as it is.
Sure - as soon as someone puts their hands on something they can do whatever they want or are able to do with it. If it happens to be a community of very savvy field experts then you're right - you've lost. But if you're protecting mostly against 12-year olds copying dlls after reading a post on reddit there's actually a lot you can do to protect against 99.999% of them. You'd be surprised what a deterrent it is in some scenarios to simply change a file extension.
So basically yes, but no. You're right but it doesn't always matter. It depends :)
@Chris-Kawa said in Process Protection:
If what you're saying was universal the entire gaming industry wouldn't exist and wouldn't be the biggest entertainment medium in the world as it is.
I'd like to point out that there is no conflict in that world and what I wrote.
See this description; https://www.theverge.com/2021/9/23/22690670/epic-eac-anti-cheat-linux-valve-steam-deck-support-games
EasyAntiCheat is a company that doesn't focus on process protection in the way that OP asked. For starters it requires kernel support.
