wintun/api/api.vcxproj, branch master

api: rewrite based on SwDevice

2021-10-12T18:54:20Z

Signed-off-by: Jason A. Donenfeld

props: unify import .lib of DLLs

2021-08-10T10:01:26Z

This moves downlevelshim.lib and those .lib from any future DLLs in this repo to the matching IntDir. Signed-off-by: Simon Rozman

proj: clean up loose ends

2021-08-01T23:04:35Z

Signed-off-by: Jason A. Donenfeld

api: remove authenticode support

2021-08-01T22:24:10Z

Certificates are no longer valid. Signed-off-by: Jason A. Donenfeld

api: upgrade

2021-07-28T18:25:27Z

Signed-off-by: Simon Rozman

vs: move shared configuration to wintun.props and upgrade

2021-07-28T18:22:18Z

Remember to rename wintun.vcxproj.user file in your local working folder to wintun.props.user manually. Signed-off-by: Simon Rozman

api: build with WDK

2021-07-23T18:20:43Z

Makes builds more reproducable, as we can do our next release using the EWDK, an all-in-one ISO of build tools from Microsoft. Signed-off-by: Jason A. Donenfeld

api: use SuggestedInstanceId instead of NetSetupAnticipatedInstanceId

2021-07-09T15:08:28Z

All was well with NetSetupAnticipatedInstanceId, until a bug crept into recent Windows builds that caused old GUIDs not to be properly removed, resulting in subsequent adapter creations to fail, because NetSetup AnticipatedInstanceId considers it fatal when the target GUID already exists, even if in diminished form. The initial solution was to detect cruft, and then steal a TrustedInstaller token and sleuth around the registry cleaning things up. The horror! Uncomfortable with this, I reopened IDA and had a look around with fresh eyes, three years after the original discovery of NetSetupAnticipated InstanceId. There, I found some interesting behavior in NetSetupSvcDeviceManager::InstallNetworkInterfaces, which amounts to something like: if (IsSet("RetiredNetCfgInstanceId") { if (IsSet("NetSetupAnticipatedInstanceId") DeleteAdapter(GetValue("RetiredNetCfgInstanceId")); else Set("NetSetupAnticipatedInstanceId", GetValue("RetiredNetCfgInstanceId")); Delete("RetiredNetCfgInstanceId"); } CreateAdapter = TRUE; if (IsSet("NetSetupAnticipatedInstanceId")) { Guid = GetValue("NetSetupAnticipatedInstanceId"); if (AdapterAlreadyExists(Guid)) CreateAdapter = FALSE; else SetGuidOfNewAdapter(Guid); Delete("NetSetupAnticipatedInstanceId"); } else if (IsSet("SuggestedInstanceId")) { Guid = GetValue("SuggestedInstanceId"); if (!AdapterAlreadyExists(Guid)) SetGuidOfNewAdapter(Guid); Delete("SuggestedInstanceId"); } Thus, one appealing strategy would be to set both NetSetupAnticipated InstanceId and RetiredInstanceId to the same value, and let the service handle deleting the old one for us before creating the new one. However, the cleanup of the old adapter winds up being quasi- asynchronous, and thus we still wind up in the CreateAdapter = FALSE case. So, the remaining strategy is to simply use SuggestedInstanceId instead. This has the behavior that if there's an adapter already in use, it'll use a new random GUID. The result is that adapter creation won't fail. That's not great, but the docs have always made it clear that "requested" is a best-effort sort of thing. Plus, hopefully the creation of the new adapter will help nudge the bug a bit and cleanup the old cruft. In some ways, transitioning from our old strategy of "cudgel the registry until we get the GUID we want" to "ask politely and accept no for an answer" is a disappointing regression in functionality. But it also means we don't need to keep crazy token stealing code around, or fish around in the registry dangerously. This probably also increases the likelihood that an adapter will be created during edge cases, which means fewer errors for users, which could be a good thing. On the downside, we have the perpetual tensions caused by a system that now "fails open" instead of "fails closed". But so it goes in Windows land. Signed-off-by: Jason A. Donenfeld

api: delay load remaining dlls to work around forwarder gotchas

2020-11-27T13:52:03Z

RtlGenRandom forwards to cryptbase.dll, which is not in KnownDlls. Therefore it's not a good idea to link to advapi32.dll at link time. How many other gotchas of unusual forwarded functions are there? I don't really want to find out. Therefore, delay load everything else. Signed-off-by: Jason A. Donenfeld

api: do not call UpdateDriverForPlugAndPlayDevicesW

2020-11-09T14:14:33Z

This seems to reset a number of device properties, and our update flow seems to update old adapters without needing to call this. Signed-off-by: Jason A. Donenfeld