* Working with a mounted flash drive
If a flash drive smaller than 80 GB is mounted, there will be a false positive.
* wiring of small devices
USB Devices rarely have a capacity of more than 80 GB. A false positive occurs.
* fix ;
* Revert "fix ;"
This reverts commit bf68dc2758.
* fix deleted }
* Disable optimization to avoid crash in GetProcAddress
* Adding the SEH misuse anti-disassembly technique
* Fix messed-up stack after execution of VectoredHandler in TrapFlag.cpp
* Fix messed-up stack after executing the SEH misuse anti-disassembly technique
* Fix VectoredHandler for x64 architectures
Co-authored-by: Fulvio Di Girolamo <fulviodigirolamo@tutanota.com>
Co-authored-by: Fulvio Di Girolamo <fulviodig96@gmail.com>
The memory walk check was broken because it assumed that memory regions would be executable. It also started at the wrong address - AllocationBase is the start of the allocator region, whereas BaseAddress is the actual start of the region. This has now been fixed.
This commit also adds a new check, which scans for memory structures that the .NET runtime creates to track loaded modules. This should catch injected modules even if they're dynamically loaded from memory.
The previous method of checking if the process was launched by Explorer was very prone to false positives, since it would return a detection if you have Explorer process isolation enabled (i.e. one process per explorer window).
The new method finds the parent process ID and checks the main module path to see if it's an explorer.exe process. The full path is checked so as to avoid the trick of just renaming the parent process to explorer.exe somewhere else in the filesystem.
If the parent process filename or explorer path cannot be fetched for some reason, the check falls back to the old method. It also handles the situation where GetExplorerPIDbyShellWindow fails and returns zero.
Previously we were using BOOL for the hidden thread flag, but that's typedef int which is 4 bytes. This query call expects a 1-byte bool instead, so the NtQueryInformationThread call would always fail with a length mismatch. Due to the logic in the function, this resulted in silently returning no detection.
One important detail of note is that because bool is a single byte local variable, it is free to be allocated anywhere and isn't necessarily aligned. This commit introduces an AlignedBool struct that uses the alignas keyword to get around this issue.
Three new checks are added in this commit:
The first check detects if a length mismatch status is returned for legitimate calls, which might happen if someone writes a buggy hook that incorrectly assumes a BOOL is passed rather than a bool.
The second check detects if a length mismatch status is not returned when a BOOL is passed, which is likely to happen if someone writes a buggy hook that doesn't check the input length properly.
The third check detects if misaligned ThreadInformation pointers are properly rejected. This is not something a hook is likely to properly check for, so it's a good way to catch them out.
This resolves#230.
dependabot[bot]