DisplayLink 8.0 M3 Corporate Installer Problem - Unique Batch Files Generated

atomicd10 · 11-09-2016, 12:56 AM

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?

Generate a static batch file, thereby keeping the batch file's hash value the same in all cases
Execute the batch file using a digitally signed DisplayLink process
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!

11-09-2016, 12:56 AM	#1
atomicd10 Junior Member Join Date: Sep 2012 Posts: 16	DisplayLink 8.0 M3 Corporate Installer Problem - Unique Batch Files Generated 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? Generate a static batch file, thereby keeping the batch file's hash value the same in all cases Execute the batch file using a digitally signed DisplayLink process 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!