Npcap fails in AdminOnly mode even when approving the NpcapHelper elevation prompt

[conioh]

Describe the bug

When running as a non-admin user, with Npcap configured to AdminOnly=1, despite allowing the elevation prompt for NpcapHelper.exe, the client library fails to access the Npcap driver.

To Reproduce

Steps to reproduce the behavior:

1. Install Npcap 1.8.0 with AdminOnly=1 (I used the GUI to select that)
2. Install Wireshark 4.4.1
3. Log on to Windows as a standard user, not as an administrator with a split token!
4. Run Wireshark
5. Approve NpcapHelper.exe elevation request
6. Note you don't see your real network adapters, but rather only the same adapter as you would, had you not allowed the NpcapHelper.exe elevation prompt (ETW, random packet generator, etc.)

Alternatively: 4. Run & 'C:\Program Files\Wireshark\dumpcap.exe' -D (PowerShell syntax) 6. Note only loopback adapter is listed and all the other adapters are missing

Alternatively: 2. Download and extract 86Box v4.2.1 [build 6130] [f6948478a] [x86_64, old dynarec] 4. Run 86Box 6. Go to Tools > Settings... menu and pick the Network pane and there under Mode select PCap 7. Note that under Interface are listed only None and the loopback adapter

Expected behavior

I expect that if the helper broker process that's supposed to provide non-admins access to Npcap is allowed to run as admin it would perform its task of providing its parent process with access to Npcap.

Screenshots

Unnecessary.

Diagnostic information

• Windows 11 Version 23H2, OS Build 22631 something something

Cause

NpcapHelper erroneously assumes that it will have access to the pipe it creates to communicate with its clients. That is not necessarily true. NpcapHelper sets on pipe a secrutiy descriptor with a single ACE that allows access to the user under which the client is running. If the client is not the running as same user (different SID) as NpcapHelper, NpcapHelper itself won't have access to the pipe.

The first call to CreateNamedPipeA will succeed and the client will be able to connect, but NpcapHelper will immediately try to reopen (not create) the pipe to support subsequent calls, and the second call to CreateNamedPipeA will fail.

Npcap should not make that assumption and add itself to the DACL too.