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
Inactive Support Threads
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
Software
Security Apps
Other security for Windows, Mac, Linux
NoVirusThanks OSArmor
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 700794"><p>Well MS own Windows so they can do whatever but they probably just use a callback but have it invoked before others. Anyway as for suspension, the main thread of a newly starting up process (which will be the only thread at the start) will be in a suspended state by the Windows Loader before initialisation has completed.</p><p></p><p>Therefore, while you are waiting to respond to an alert from a product holding up a callback routine for PsSetCreateProcessNotifyRoutineEx, the main thread of the process starting up will automatically be in a suspended state. You can't suspend a process, you can only suspend the threads of a process; this narrows down to the suspension state for the process itself, which is the container for the inner workings of the process. This is why NtSuspendProcess -> PsSuspendProcess -> KeSuspendProcess -> KeSuspendThread -> KiSuspendThread. Because the threads execute the code</p><p></p><p>The Windows Loader will invoke NtResumeThread within the context of the process responsible for the starting up of another process once its ready to do so, however bits and bobs like kernel-mode callbacks which need to be invoked will indeed be before this point arrives. So it is normal for a process which you need consent provided to start-up is in a "suspended" state, because this is automatic and just how it works. Until the process has actually started up and the main thread has been resumed by the Windows Loader, it'll maintain like this.</p><p></p><p>However, it's a different story if someone is allowing the execution of a new process, and then afterwards manually suspending it themselves. That indeed would be a potential vulnerability, and I thought this is what you were saying before. But I misunderstood? As for the automatic "suspended" state, attempting to resume it if it was by the Windows Loader would be a stupid idea because initialisation would not be complete and would likely end up in the starting up process crashing</p><p></p><p>All processes being started up are started in a suspended state by the Windows Loader, and the "process" is resumed after all initialisation, so that is when the main thread is resumed</p><p></p><p>I don't think there's anything to worry about here. ReHIPS and OSArmor are great and the devs both know what they are doing. If a vulnerability is found and exploited and then discovered or by a researcher, both software teams will fix it up. and the potential abuse for either of them for a zero-day is very small</p><p></p><p>You can try monitoring various APIs for the Windows Loader and then tracking the call stack, then when the smart screen notification appears, use the call stack/logs to see how far the progress was for NTDLL calls invoked from the process trying to start-up the other process which is being intercepted by SmartScreen to get an idea of where about SS will intercept from KM</p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 700794"] Well MS own Windows so they can do whatever but they probably just use a callback but have it invoked before others. Anyway as for suspension, the main thread of a newly starting up process (which will be the only thread at the start) will be in a suspended state by the Windows Loader before initialisation has completed. Therefore, while you are waiting to respond to an alert from a product holding up a callback routine for PsSetCreateProcessNotifyRoutineEx, the main thread of the process starting up will automatically be in a suspended state. You can't suspend a process, you can only suspend the threads of a process; this narrows down to the suspension state for the process itself, which is the container for the inner workings of the process. This is why NtSuspendProcess -> PsSuspendProcess -> KeSuspendProcess -> KeSuspendThread -> KiSuspendThread. Because the threads execute the code The Windows Loader will invoke NtResumeThread within the context of the process responsible for the starting up of another process once its ready to do so, however bits and bobs like kernel-mode callbacks which need to be invoked will indeed be before this point arrives. So it is normal for a process which you need consent provided to start-up is in a "suspended" state, because this is automatic and just how it works. Until the process has actually started up and the main thread has been resumed by the Windows Loader, it'll maintain like this. However, it's a different story if someone is allowing the execution of a new process, and then afterwards manually suspending it themselves. That indeed would be a potential vulnerability, and I thought this is what you were saying before. But I misunderstood? As for the automatic "suspended" state, attempting to resume it if it was by the Windows Loader would be a stupid idea because initialisation would not be complete and would likely end up in the starting up process crashing All processes being started up are started in a suspended state by the Windows Loader, and the "process" is resumed after all initialisation, so that is when the main thread is resumed I don't think there's anything to worry about here. ReHIPS and OSArmor are great and the devs both know what they are doing. If a vulnerability is found and exploited and then discovered or by a researcher, both software teams will fix it up. and the potential abuse for either of them for a zero-day is very small You can try monitoring various APIs for the Windows Loader and then tracking the call stack, then when the smart screen notification appears, use the call stack/logs to see how far the progress was for NTDLL calls invoked from the process trying to start-up the other process which is being intercepted by SmartScreen to get an idea of where about SS will intercept from KM [/QUOTE]
Insert quotes…
Verification
Post reply
Top
