DavidXanatos
patreon
PrivateWin10 development progress
🕑 Added 2019-10-19 15:42:50 +0000 UTCWhy PrivateWin10 development stalled for so long and what’s coming. I know lots of people are waiting on a new Priv10 release, and don’t worry one is in the workings. But since so many months have passed since the last release I feel like some explanation is in order.
First the obvious one TaskExplorer (https://github.com/DavidXanatos/TaskExplorer) this project took a lot of my spare time away from other projects, but for me it had priority.
Now to the more Priv10 related reasons for the long delay; windows firewall is a huge pain to deal with as it’s not intended to be used the way Windows Firewall Control applications are trying to use it. Hence the logging of failed connection attempts is very poorly implemented, in practice it is done through enabling an auditing policy and then capturing event log entries as they are being created. There is an API to do this more strait forward, but it provides even less information’s and no ProcessID. So, to do this as close to properly as possible I had to reimplement the mechanism Priv10 was using and implement a few mechanisms to deal with the lack of information in the log entries. For example, Windows is providing only the path and the PID of the process that caused an event to be logged. But does not log the service name or Container SID of the Modern App if the process runs as such.
Resolving the service name can be done by querying the Service Manager which gives the PID of every service running however as multiple services can share one and the same instance of svchost.exe its not possible to tell at this point which of the hand full of services caused the event.
For more recent windows 10 versions this is not as problematic as here Microsoft chose to mostly use one svchost.exe instance per service hence in many cases the service name can be resolved reliably. Older Windows 10 builds as well as 7 and 8 here are not as nice and there you can have more than dozen services sharing one process. Hence workarounds were in order.
One is a great new feature, the build to come of priv10, in addition to show logged connection attempts will also show a full list of all open sockets per process, including data rates per socket.
This data source can be queried to give information to which service an open socket belongs to, i.e. for allowed sockets we will be able to associate logged events with the service even on older versions of windows. Now this method fails for blocked connections as they are not seen in the list of open sockets and it fails for sockets closed very quickly, that is before they can be enumerated. To solve this issue priv10 will try to match the log entry with existing rules for the list of services that is hosted by the offending svchost.exe instance. This can result in a unique match or not. So, when there is no way to deduce which service it was the event is attributed to an entry svchost.exe without a service tag set. And when showing a notification window, the user will be presented with a drop-down list of services and will have to pick one manually. One can of cause manually make a blanked rule granting svchost.exe full access to the network though.
The other issue are App containers, there is it seems no strait forward documented way to retrieve the Container SID given a ProcessID, there are calls to kernel32.dll that will give you the AppPackage Name by PID but this will only relay to if the executable was installed as a ModernApp it will not tell you if the running process is contained in a AppContainer or is running as a normal win32 application. If the latter is the case Windows Firewall rules set to apply to a specific ModernApp will be ineffective as they strictly speaking apply only to app containers. The proper solution for this issue is to query the processes Access Token and from it one can query the Container SID as which the process is running. I discovered this method only while working on TaskExplorer.
As of today, to my knowledge there is no other Windows Firewall Control tools out there that would properly handle AppContainer’s.
So, as you see it was all a big mess and a more advanced tool for Controlling Windows Firewall must properly resolve this mess such that things displayed in the UI are consistent, the user does not have to handle redundant entries, etc….
Another new feature that I always wanted but before having advanced far enough with TaskExplorer did not know how to do without very invasive approaches like DLL-injection and API-call Hooking, is the proper resolution of remote domain names. What I mean with “proper” is that we want to see the domain name requested by the process for which it than opened a socket, and NOT just a reverse DNS lookup result for the remote IP. As in the age of CDN’s (like CloudFlare, BlazingFast and others) these reverse DNS entries have become mostly useless. By monitoring the windows DNS Cache entries, we can quite reliably detect which remote domain a socket really wanted to connect to and display this information to the user. Resulting in yet another cool feature a per application log of all domain names the application tried to access.
So that’s roughly what is coming in the soon to be released version of PrivateWin10, plus a lot of bugfixes.
