Security Incident Response

If you think you have or know you have a Security Incident please fill in the form and our experienced Onevinn CSIRT team will reach out shortly.
 
The team has long experience in supporting customers in Incident Response and Compromised Recovery.
 
Keep calm and we will be with you shortly!

Johan Schrewelius 02 Mar 2020
3 min

Distribute Drivers at Mach speed

This is a report from the “Onevinn utility research kitchen” where we have spent a few days contemplating and testing driver distribution during OSD. Driver distribution appears to be the talk of the town and new solutions keep popping up at a high rate. Most of these solutions target bandwidth utilization and involves distributing compressed drivers to be expanded on the target machines.

We decided to see if we could contribute to this by somehow improving the concept. The basic idea is of course brilliant and brings huge advantages.

It boiled down to two questions:

  1. If bandwidth is an issue why use the zip-format, it is far from optimal? We have found it has a compression ratio, when dealing with drivers, averaging at about 50 %. Can we do better?
  2. The implementations we have come across all uses the PowerShell cmdlet Expand-Archive to unpack the drivers on the target machine. This cmdlet is horribly slow and only supports zip-archives. Is there a better way?

Both questions are aspects of the same problem and after testing several compression methods we decided to investigate 7-Zips native “7z”-format a bit further. It gave us a compression ratio of just under 70 % which we considered a major improvement compared to zip. The problem is of course that it cannot be expanded with PowerShell, so instead we created a self-extractor (.exe).

A self-extracting archive doesn’t need any third-party binaries, it is itself an exe, and tests showed that it did the job in only about one third of the time required by Expand-Archive. It looked very promising but didn’t work. Even the 64-bit version of 7-Zip produces 32-bit self-extractors. Bummer, hardly no one is using 32-bit boot images these days!

This didn’t look good but suddenly we remembered something; 7-Zip is open source. What if we could recompile it for the correct architecture? This was a game changer, it turned out to be a very easy. The project, which we immediately downloaded, is very well organized and each module can be built separately.

In this case we needed to rebuild and replace one file in the original 7-Zip setup folder, “7z.sfx” to be precise. Once done 7-Zip started to produce 64-bit self-extractors, victory!

But now for the fun part, at least if you want to test this?

First you need to download an archive from the link, it contains two subfolders:

Apply_drivers_at_Mach_speed.zip

The top folder contains the 64-bit self-extractor module mentioned earlier. The other folder holds a custom Task sequence with the steps necessary to run this test.

Next step is to install 7-Zip 19.00 (x64 edition) and replace the “7z.sfx” file with the 64-bit version you just downloaded. You might want to save a copy of the original file?

Import the “Onevinn_Driver_Steps” custom TS from the unzipped archive, the file “Onevinn_Driver_Steps.zip” should not be unzipped, just make sure to keep it in the same folder as the _files folder and import it to CM.

Once imported copy the steps to your own test TS so it resembles this:

There is still some configuration to do, we will get back to that once we have created a driver package for the test.

We are using a HP EliteBook 830 G6 and Windows 10 x64 1909 for this article. For comparison we have already zipped the entire driver folder structure giving us a zip-archive just under 900 MB in size (compressed from 1.98 GB). Now let’s see the result if we instead use “7z” with Ultra compression and create a self-extractor.

If 7-Zip is properly installed you should be able to mark all driver folders, right click and chose 7-Zip “Add to archive”, then use these exact settings do not forget the password:

Make sure all settings are correct and press “Ok”.

The compression will run for a while, when finished you should expect something like this:

So far it should be safe to say that the efforts have been worthwhile…..

Next, move the self-extractor (Driver.exe) to a new folder on your content share and create a standard package without program from it:

Be sure to make a note of the Package ID. And do not forget to distribute it to your Distribution point(s).

Now let’s get back to the TS. We need to create and set two Task sequence variables:

OSDDriverPackageID – The Package ID you just “noted”.

DriverExePassword – The password for the self-extractor (Driver.exe)

Since we expect to run more tests with various computer models, we use a “Set Dynamic Variables” step for the first one:

For the second variable we use a “Set Task Sequence Variable” step, make sure to not display the value:

The rest of the steps requires no configuration but make sure to distribute the new package containing the “StageDrivers.ps1” script, you will find the name and ID here:

Expected behavior:

  1. The two variables are “set”.
  2. The script “StageDrivers.ps1” will read the variables, download and invoke the self-extractor.
  3. All drivers will be inflated to the target drive. (normally c:\Drivers).
  4. The self-extractor is deleted, and password variable reset.
  5. Dism.exe is invoked and pushes the drivers on to the newly applied image.
  6. At the end of the TS the content folder is removed, “Cleanup Driver Staging”. This could have been done by StageDrivers.ps1 but we have a few more ideas for even more optimizations, which will require the drivers to stay on disk a little bit longer. We might get back to that in a follow up post soon.

Logging is limited in this beta edition, but you should be able to find the reason for malfunction in “..\SMSTSLog\Onevinn.StageDrivers.log”.

This solution is of course driven a little bit towards the extreme, but it certainly proves optimization is possible.

Thank you for your attention!