By default, a CRITICAL_SECTION object is recursive. Can this behaviour be configured like a pthread mutex to enable or disable recursive thread access?
To clarify in response to the comments: I am referring specifically to a Windows CRITICAL_SECTION object, not a Windows mutex.
No, it cannot. Documented APIs do not mention this in any way. Windows critical sections always accept recursive access.
A Critical Section always allows recursion within a thread. So does a Mutex. That is by design and cannot be changed.
A Semaphore, on the other hand, can prevent recursion within a thread. See MSDN documentation for more details.
Related
I recently asked a question about privileges required in Windows to read any user-mode program's memory contents. I learned from documentation linked in some of the comments:
Apparently PROCESS_VM_READ is required but documentation doesn't seem to explain under which conditions such a trait is attributed to a process. Apparently, ACLs are involved:
When you call the OpenProcess function, the system checks the
requested access rights against the DACL in the process's security
descriptor. When you call the GetCurrentProcess function, the system
returns a pseudohandle with the maximum access that the DACL allows to
the caller
But another user asks about "C++: reading memory of another process" and receives an answer linking this github repo:
https://github.com/T-vK/Memory-Hacking-Class
Now I am just learning C++ as a beginner now, so I can look through this code but I can't say I understand it, so I apologize if the answer is obvious.
I'm guessing from what I've learned so far this code only works against processes which allow PROCESS_VM_READ access. But if that's true, I don't understand why every game executable wouldn't just stop cheats by denying that access. There must be something to this picture that I'm missing.
The Windows Antimalware scan Interface (AMSI) contains abstractions which can be used to call the currently active virus scanner in Windows:
https://learn.microsoft.com/en-us/windows/desktop/amsi/antimalware-scan-interface-functions
There are 2 methods related to initialization:
AmsiInitialize
AmsiUninitialize
AmsiInitialize returns "A handle of type HAMSICONTEXT that must be passed to all subsequent calls to the AMSI API.".
After initialization is complete, I can use AmsiScanBuffer to scan a buffer for malware.
My question:
Can I use the same context concurrently from many threads in my application, or do I need to create one per thread from which I'm going to call the methods?
Reading the documentation, for AsmiUnitialize, it tells me that When the app is finished with the AMSI API it must call AmsiUninitialize.. This tells me that the context can be used for many calls, but it doesn't tell me anything about thread safety or concurrency.
Generally, API calls that are not specifically marked as thread-safe are not (this is usually true for any library). The easiest solution is to open an AMSI handle per thread.
(P.S. This only works with Windows Defender so far as I 've tested).
I'd like to get event in kernel on each new process that starts (fork+execve or posix_spawn), and be able to prevent this operations.
The first option would be using Mac framework named mpo_vnode_check_exec by Hooking to this method with function that return 0 when access is granted or check deferred to next hook.. non zero returned value means access is refused right away.
Unfortunately, this framework is unsupported by apple, and I wish to use a stable alternative like kauth fileop scope with KAUTH_FILEOP_EXEC flag.
However, this framework is for detection only and lacks prevention capabilities..
Perhaps there's a way to prevent the process from running when I get relevant kauth callback on process creation, or halt the process from running until I decide whether it should run or not (and enforce the verdict in another thread).
thanks
However, this framework is for detection only and lacks prevention capabilities..
Correct, if you're only focussing on the File scope.
Register with the Vnode scope and your callback returns whether or not access is allowed.
kauth_listen_scope(KAUTH_SCOPE_VNODE, &myCallback, NULL);
Finally, note that this scope is very noisy, as every type of access to every resource is reported.
In the WinHTTP autoproxy API, the WINHTTP_AUTOPROXY_OPTIONS will accept flags for WINHTTP_AUTOPROXY_RUN_INPROCESS and WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY. What's the difference between these two flags and when would you use them?
Figured this out. The out-of-process approach uses the WinInet service, which is deemed more secure. While MSDN doesn't say so explicitly, this is presumably because the in-proc option means the PAC's execution shares the same app context.
Apperantly, GetThreadId is a Vista API. How can I get a thread's id on pre vista systems?
There are a few options:
When you call CreateThread, you get the handle back.
You can call GetCurrentThreadId to get the current thread's ID.
You can use Thread32First/Thread32Next to enumerate threads.
If you can somehow make the thread in question call GetCurrentThreadId and store it somewhere, you could read the result.
If the thread in question enters an alertable wait state frequently, you could send it an APC with QueueUserAPC; the APC handler can then call GetCurrentThreadId and communicate the result back to the caller using whatever method you like.
You can also do this with undocumented NT functions. Using NtQueryInformationThread() on the ThreadBasicInformation class will give you the thread ID in the returned structure. An example can be found in the wine source. However, I'm not sure what versions of windows this is available on - keep in mind these undocumented functions can change at any time, so it's best to test them on the older versions of windows you're interested in, and simply use GetThreadId() where it's available.
Note that these undocumented functions can only be accessed by LoadLibrary() and GetProcAddress() on NTDLL; they have no import library. According to MSDN, declarations for the data structures can be found in Winternl.h, but if not, just define them yourselves based on the ntinternals links above.