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 <Jason@zx2c4.com>
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 <Jason@zx2c4.com>
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 <Jason@zx2c4.com>
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 <Jason@zx2c4.com>
The additional build steps performed are now attached to the build
process using BeforeTargets/AfterTargets.
Signed-off-by: Simon Rozman <simon@rozman.si>
This requires us to make some insane conversions between INF date,
JavaScript time, and finally Windows file time. The point is to mimic
SystemTimeToFileTime, which is what SpInf.dll's pSetupStringToDriverDate
does on the YYYY-MM-DD from the INF.
The result is that we no longer have to parse an ancient text format in
C at runtime.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It would be better to do this only if either nci.def or nci.h are newer
than nci.lib, but who knows if msbuild is expressive enough for this.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is an appalling hack. We need the lib tool to generate a coff lib
with the "undecorate" parameter. And apparently the only way to do this
with the MSVC tools is by making a stub object, and then rewriting the
symbols using the def file. See Q131313 for Microsoft-sanctioned
details.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
When Windows 7-8.1 support is sunset, there will be no more EV driver
deployment at all.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
When we install the Wintun driver to the store, we get exact oem<nn>.inf
filename of the driver in the store we just installed. Since the
installation should be only temporarily, we should uninstall only the
driver we installed.
This also eliminates the need for iterating driver store speeding up
things.
The code we removed was inherited from the installer.dll, where it made
perfect sense to remove all installed Wintun drivers in the update
process.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
This adds the ARM driver to the list of Wintun drivers we compile for
future deployment. Since we're not in position to test it in the real
world, any feedback is greatly appreciated.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
Rather than every client reinvent the art of using the Wintun and its
ring buffers, we offer helper structs and functions to unify and
simplify Wintun usage.
Signed-off-by: Simon Rozman <simon@rozman.si>
The SDK header for deployment containing datatype and function
declarations for use by C/C++ clients.
As we shall not distribute MSVC wintun.lib files, making clients need to
use GetProcAddress(), this file contains function type declarations
rather then __declspec(dllimport) function declarations.
Signed-off-by: Simon Rozman <simon@rozman.si>
SetupAPI fails to create a device in WoW64 processes. x86 (and arm)
wintun.dll pack the amd64 and arm64 wintun.dll now, and use rundll32 to
create a native process to do the job where required.
Signed-off-by: Simon Rozman <simon@rozman.si>
This should allow wintun.dll to simplify referencing same configuration
but different platform wintun.dll for WoW64 support.
Signed-off-by: Simon Rozman <simon@rozman.si>
Gather adapter management in adapter.h/.c (formerly devmgmt.h/.c) and
unify HwID tests.
Use "Namespace" namespace in all functions from namespace.h/.c.
Fix char strings in LOG_...
Signed-off-by: Simon Rozman <simon@rozman.si>
Some functions of SetupAPI only work when invoked from a native process.
Registry and filesystem reflection makes them fail on WoW64. For WoW64
processes, a minimum set of rundll32 functions are provided.
Signed-off-by: Simon Rozman <simon@rozman.si>
Mind that this also fixes the order of adapter detection checks. A fast
test to eliminate non-Wintun adapters from iteration to speed things up
rendered the method incapable of detecting a non-Wintun adapter with the
name we are looking for.
ERROR_OBJECT_NOT_FOUND was replaced with ERROR_FILE_NOT_FOUND.
Signed-off-by: Simon Rozman <simon@rozman.si>
