Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Best Of
Re: Performance Regression regarding UNC access
With and without our filter, and below/above our filter (4 cases,
giving us a chance to see if the slowdown is in our driver or not).
So much for SMB3
> we develop a product that uses a minifilter to restrict which files may be
> accessed in which way on which device. We noticed that the performance for
> accessing files on UNC shares regressed over the past Windows versions -
> without our product, but even more so with our product installed.
>
> We measured startup times of Visual Studio Code from a network share:
>
> * Without our product:
>
> ** Windows 7: 8,89s
>
> ** Windows 10 1709: 9,99s
>
> ** Windows 10 1909: 11,32s
>
> ** Windows 10 2004: 16,68s
>
>
> * With our minifilter:
>
> ** Windows 7: 9,51s
>
> ** Windows 10 1709: 28,34s
>
> ** Windows 10 1909: 40,04s
>
> ** Windows 10 2004: 34,65s
>
>
>
> Does anyone have any pointers for me?
>
> * How can I profile the minifilter?
> * Was there any change in Windows that would lead to such a regression? If
> so, is there a known remedy we could implement to decrease the gap between
> performance with and without our driver?
>
Re: InbvDisplayString does not work properly.
NtDisplayString did not work for me; ZwDisplayString yes.
Hmmmm... You do understand that they're the same system service, right?
They only difference between them is one (ZwXXX) explicitly sets previous mode to Kernel Mode, and the other (NtXxxx) leaves the previous mode as is.
When writing drivers, you're not meant to copy/paste. You're meant to read, consider, understand and use the feature you need. In terms of NtXxxx calls, you need to consciously decide which variant you want to use, based on how you code is invoked.
Peter
Re: Com caller process
The server can get the token of the client. That's about as good as it gets.
Re: InbvDisplayString does not work properly.
I was under the impression that InbvDisplayString stopped working as of Windows 8.
Peter
Re: WinDbg Preview vs WinDbg
Is the crash dump from a really new system? Is it user mode or kernel mode?
I just looked on my system and the debugger engine DLLs in WinDbg Preview (somewhere like C:\Program Files\WindowsApps\Microsoft.WinDbg_BLAH_BLAH\amd64) are newer than the ones in the latest WinDbg. You can try replacing the WinDbg DLLs with the WinDbg Preview ones and see if that works.
Re: Shouldn't memory manager bring back paged out memory in PASSIVE_LEVEL IRQL?
we are doing anti cheat companies favors too because without us they are out of job
Sounds of idiots who don't know what's more important and more valuable.
Actually, the OP presents quite an interesting argument. After all, if you stretch your imagination a bit, you can extend this logic not only to the malware writers who can be claimed "to do a favour to the AV companies", but to the burglars as well. Imagine a lawyer claiming that his
client who stands a trial on the burglary charges had actually "tried to do a favour to the security firm, because it would be out of business otherwise". I just wonder what the judge's reaction would be like.......
Anton Bassov
Re: Most stable way of finding executable pages in kernel?
as a aside, it is clear that the level of technical skill demanded to write and effective cheating system is impressively high. Maybe not as high as that needed to use network monitoring software to steal state secrets, but the mark of really good malware is that it does not cause observable effects that cause people to go looking.
but your underlying problem has only two theoretical solutions
- you can run your security protection in a hypervisor underneath the OS
- you can make the end PC a 'dumb terminal' and have all processing done on a physically secured server
or you change the world and reintroduce rings as hardware enforced security boundaries inside the machine.
but the point is that it is an n/p hard problem to find or prevent 'all' cheating software that runs on machines that you do not control
MBond2
Re: Most stable way of finding executable pages in kernel?
You could use NtSystemDebugControl (see LiveDump for a start). Still undocumented but better than walking page tables...
(Note that I admittedly haven't tried this is a couple of years but it appears to still be available in 2004)
Re: Most stable way of finding executable pages in kernel?
How would you do a kernel memory dump without using any third party programs, and obviously from kernel ?
All I've seen on the NT documentation is a function that initialize a crash dump header (KeInitializeCrashDumpHeader).
Re: Most stable way of finding executable pages in kernel?
I've thought of (and written) so many different answers...This is what I've ended up with:
Let Windows worry about this and require your customers to run Win10 with HVCI enabled. Done. It's the only way to know that you don't now (and won't in the future) have any WX pages. As a bonus you also get enforcement of the MS recommended driver block policy.
If your supervisor is convinced that finding executable pages at a particular moment in time will tell you something (I have no idea what), then understand that you don't have access to the locks necessary to walk the page tables safely. Consider periodically creating memory snapshots with something like LiveKD and walking the tables in the resulting crash dump. You at least have a stable image, get to write all code in user mode, and won't crash the machine if you get it wrong.
Lastly, make sure you understand the threat model that you're defending against. I used to think all this stink around anti-cheat was stupid (I loved my Game Genie) but turns out the cheat authors are both very clever AND motivated by significant financial gain. Be careful not to create something incredibly complicated that impacts the reliability and performance of the system for minimal protection against cheating...
Speaking of drivers and cheating: Riot got a lot of shit a couple of years ago for introducing their Vanguard anti-cheat driver. The developers clearly understand the problem space, it loads at boot, is heavily obfuscated with VMProtect (which puts me off from using it), and appears to have taken a significant development effort. Even with all that they're still playing catch up: Riot plans to take action against increase in Valorant cheating.