PrivateWin10 development progress

Why 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.