DisplayLink 8.0 M3 Corporate Installer Problem - Unique Batch Files Generated

[atomicd10]

Hello,

We have several thousand DisplayLink docking stations in our enterprise environment, and while testing we've run into an issue with the 8.0 M2 and 8.0 M3 installers when upgrading from 8.0 M1 on Windows 10 TH2, where a batch file with a unique hash is generated in C:\Windows\Temp\ that is named with a GUID like {70597878-0ACE-41BC-9917-33EE9D36B3BB}.bat and is then executed by either c:\windows\syswow64\msiexec.exe or c:\windows\syswow64\cmd.exe.

The issue is that when these batch files attempt to execute they get blocked by the application whitelisting security software that's installed on all of our endpoints. Ordinarily we would just make a global exception in the security software for something like this, but the problem is that the filename is unique, the file hash is unique, and the file is written and executed in a manner very similar to hundreds of other applications (and malware), so we are unable to create a global rule using our security software to permit these batch files to execute without increasing the attack surface area on our endpoints.

Would it be possible to update the batch file aspect of the DisplayLink installer to do one of the following instead?

1. Generate a static batch file, thereby keeping the batch file's hash value the same in all cases
2. Execute the batch file using a digitally signed DisplayLink process
3. Remove the use of batch files entirely and perform the actions taken in the batch file in the digitally signed DisplayLink installer instead

Any of the above options would mitigate this problem for us by allowing us to create rules in our application whitelisting security software to allow the process to execute without issue. The second or third option would be preferred, but we could make any of the above work.

The batch file itself is not generated in all cases, and is immediately deleted shortly after attempting to execute, making it difficult to catch. However, we have been able to acquire the batch file by suspending the installation procedure when the batch file is executed, and here's the contents of said batch file:

pushd "C:\Program Files\DisplayLink Core Software\8.0.644.0\"

move /Y "USBDriver" "C:\AI_RecycleBin\{54B1F561-31EE-4125-B503-2CCA54204644}\0"

xcopy /E /Y /K /H /I "USBDriver" "C:\AI_RecycleBin\{54B1F561-31EE-4125-B503-2CCA54204644}\0\USBDriver" && del /Q /F /S "USBDriver" && rmdir /Q /S "USBDriver"

popd


del "C:\Windows\TEMP\{70597878-0ACE-41BC-9917-33EE9D36B3BB}.bat" /Q /F

The GUIDs referenced in the batch file above are dynamic, which is why the file's hash value changes each time the batch file is generated. The batch file appears to be removing the old DisplayLink drivers. Are the GUIDs in the batch file randomly generated or are they acquired from somewhere on the local system? If they are acquired from somewhere on the local system, where is this value pulled from? If we know where this value comes from and we are able to acquire it before the DisplayLink installer executes, it should be possible for us to generate the same exact file before the DisplayLink updater is executed, thereby allowing us to essentially "pre-approve" the file with our security software (albeit in a rather round-about manner, by generating the exact same file but using our own trusted process that our security software would then automatically approve).

Any assistance with this would be greatly appreciated.


Thank you!

[AlbanRampon]

Hi Atomic,

I've added a task for an expert in engineering to pick this up as I'm not able to answer.

Kind regards,
Alban

DL Ref 24254

[AlbanRampon]

Hello,

Unfortunately, this is not controlled by our code.
The batch file is created by the Advanced Installer software to remove files/folders under its control.
We have not found any parameters or configuration of the tool allowing us to change that behaviour from Advanced Installer.
Files are created by MSI but run by cmd app (started from msiexec app) - so there is no option to run it by application signed with our certificates.

In the new revisions of Windows 10 (builds >10586), you will not need the MSI and can deploy the .inf to the driver store directly.

Kind regards,
Alban

[atomicd10]

Hi Alban,

Thank you for the follow-up.

I realize that this might be a bit of a stretch, but would it be possible to replace the Advanced Installer batch file behavior entirely? To clarify, a potential example could be the DisplayLink install MSI could extract a digitally signed executable file to a temp directory and then have the MSI write a RunOnce registry key in Windows so that the aforementioned temp file would execute the next time Windows booted. For less complexity an -installCleanup (or similar) argument that triggered the same procedure that the batch file performs could potentially be added to one of the existing DisplayLink executable files that could be called and used instead of a temp file.

If something like the above isn't feasible, would it be possible to add an argument to the DisplayLink MSI installer to "pre-extract" the batch file before the DisplayLink installer even runs? If not, would extracting the batch file as the very first step of the MSI installation process be an option?

It would be great if we could update our endpoints to Win10 AU, but unfortunately the ~7500 endpoints that we have DisplayLink installed on need to remain on Win10 TH2 for at least a year due to significant vendor compatibility issues with Win10 AU, infrastructure constraints in our environment, testing, deployment, etc.

I realize that this request might sound a little out of left field, but it turns out that these batch files get blocked intermittently by application whitelisting software on average 12.5% of the time (including prior 8.0 releases of DisplayLink) in our environment, and is likely the case for other enterprises that use DisplayLink and similar security software.


Thank you for all of the assistance you've given us! I genuinely appreciate it; even if there isn't a solution available for our current issue it's good to know that it likely is not an issue with newer Win10 versions.


- Andy

[AlbanRampon]

Hi Andy,

I need a bit of time to digest this... and understand it!
The batch file behaviour is from AI itself, not something we specifically ask it to do: it cleans up after itself.

Which version of the driver are you using? The Setup.exe or the MSIs?
There is also an .INF version for pre-installation available, but there is a co-installer embedded (and required) for TH2.

That's probably the type of question we should get an answer from by Advanced Installer. I'm writing to ask...

Kind regards,
Alban

[AlbanRampon]

Hello Andy,

I've received a reply from AI.
They understand what is taking place and this is a security feature.
They confirm the user (DisplayLink) has no control over how these are created.
The only way not to have these random batch created is not to use anything to do with file, folder, registry removal or preserve operations (backup/restore). This would basically mean not having an installer and do everything by hand.

Have you been able to assess the MSI or INF based install?

Kind regards,
Alban

[atomicd10]

Hi Alban,

We've been using the corporate MSI installer to install and update DisplayLink on our endpoints, and unless I'm mistaken the INF pre-install won't work in our environment for upgrading DisplayLink on computers that already have DisplayLink installed (we're running Win10 TH2, build 10586.713); so unfortunately we have not made any progress.

To clarify, we haven't had any issues installing DisplayLink for the first time on endpoints as far as I'm aware; the installation issues we've encountered now and historically have typically been during upgrades.

Did AI happen to clarify if the GUIDs (e.g: "{54B1F561-31EE-4125-B503-2CCA54204644}" like in the sample batch file example above) are generated randomly or acquired from the system somewhere? If we are able to acquire the GUID that's used inside of the batch file before the batch file is executed we may be able to work around the issue.

Thank you for all of your help!

- Andy

[AlbanRampon]

Hi Andy,

You could force a clean-up and then install from zero but that's not really nice from the user point of view.

They did say it was random and not predictable on purpose: so nothing else injects or tampers with it as you don't know the file name.
We have a product GUID you can see once you've ran the MSI install, but that's nothing to do with the installer.

Is it an issue you had before or is it new with 8.0?
We have changed 8.0 installer to do side-by-side installation. On 7.9 and below, the installer was pulling the rug at the installation which meant if IT was pushing an update remotely, the end user would just get blank screen until next reboot without knowing why... On 8.0, we leave the rug and swap at the following reboot so the end user can keep using the machine.

It is difficult to advise the manual steps to do this instead of using the installer as on TH2 what the installer has to do is platform dependent.

Let's try another angle... What makes you to wish to update to 8.0 M3 from 8.0 M1?

Kind regards,
Alban