Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
General Security Discussions
Protecting processes from injection via SetWindowsHookEx() ?
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 730521"><p>Firstly, your method will be surpassed extraordinarily easily. GetWindowThreadProcessId (USER32) relies internally on NtUserQueryWindow (WIN32U). While nothing is full-proof in this world, surpassing this implementation would be completely effortless; simply call NtUserQueryWindow.</p><p></p><p>Even if you were to patch NtUserQueryWindow, you still have a problem with people using direct NT system calls or removing your patches. Protecting against behavior like this will likely end up causing more harm than good, especially in terms of performance.</p><p></p><p>Secondly, you will need to be performing Remote Code Execution (RCE) into every single running process for your idea to be effective against all processes. This really is not a good idea from a realistic stand-point, it would be better if your aim was for unknown processes.</p><p></p><p>Developers are constantly becoming frustrated with people who are using the excuse of "security development" while breaking their software with buggy and inefficient memory patches - you need to be really careful with why and how you use memory patching and consider how it will affect the targets.</p><p></p><p>If you went ahead with the idea regardless, it won't stop global window hooks (which do not care about a specific process as a target).</p><p></p><p>At this point, I'd be considering how important it is for you to protect against window hooks (if no "closer-to-home" and less-undocumented techniques are applicable) and what you could do to minimize the damage an attacker could do, should the GUI process ever become compromised by an attack like the one you're trying to prevent.</p><p></p><p>I admit that your situation is a bit of a dead end because taking unreliable and undocumented routes can catch up with you and drag you back down.</p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 730521"] Firstly, your method will be surpassed extraordinarily easily. GetWindowThreadProcessId (USER32) relies internally on NtUserQueryWindow (WIN32U). While nothing is full-proof in this world, surpassing this implementation would be completely effortless; simply call NtUserQueryWindow. Even if you were to patch NtUserQueryWindow, you still have a problem with people using direct NT system calls or removing your patches. Protecting against behavior like this will likely end up causing more harm than good, especially in terms of performance. Secondly, you will need to be performing Remote Code Execution (RCE) into every single running process for your idea to be effective against all processes. This really is not a good idea from a realistic stand-point, it would be better if your aim was for unknown processes. Developers are constantly becoming frustrated with people who are using the excuse of "security development" while breaking their software with buggy and inefficient memory patches - you need to be really careful with why and how you use memory patching and consider how it will affect the targets. If you went ahead with the idea regardless, it won't stop global window hooks (which do not care about a specific process as a target). At this point, I'd be considering how important it is for you to protect against window hooks (if no "closer-to-home" and less-undocumented techniques are applicable) and what you could do to minimize the damage an attacker could do, should the GUI process ever become compromised by an attack like the one you're trying to prevent. I admit that your situation is a bit of a dead end because taking unreliable and undocumented routes can catch up with you and drag you back down. [/QUOTE]
Insert quotes…
Verification
Post reply
Top