Introduction to Binary Diffing – Part 1

14 March 2022

Introduction

Do you want to figure out what that software update that has been driving you up the wall actually did? Did you just start reverse engineering a malware sample again from scratch because you got an updated sample? Have you heard of a new vulnerability that would make a great addition to your red team toolbox? Or have you identified a statically-linked library and want a way to get some symbols for it? Well, perhaps binary diffing is just what you need!

This blog series is an introduction to diffing Windows patches and how this technique can be used.

In the first part we introduce Windows Update, the different patch releases, as well as an overview of the file format used in Windows patches.
In the second part (available March 16th) we will introduce binary diffing and examine two of the tools that can be used.
In part three (available March 18th) we will go hands-on and diff a Windows patch.

Windows patches

For most, Windows patches are synonymous with Patch Tuesday, that time of the month where your computer haunts you until you give in and just reboot. But Patch Tuesday wasn’t always a thing, as it was only formalized in 2003. Before that, patches were released as they were ready.

The first iteration of Windows Update was launched with the roll-out of Windows 98. At the time, it was a web app using ActiveX and also offered optional updates including themes, games and device drivers. Shortly after releasing Windows 98, Microsoft realized that some kind of notification for critical updates was a good idea and they subsequently released the Critical Update Notification Utility. This was a background task that checked for updates marked as critical. However, it was not capable of actually downloading or installing these updates.

It wasn’t until Windows ME that Automatic Updates replaced the Critical Update Notification Utility, but unlike its predecessor, Automatic Updates could both download and install updates directly. In Windows XP, the Automatic Updates client was updated to use the now-included Background Intelligent Transfer Service, which transferred files in the background without user interaction. In XP, the tool was able to throttle its own bandwidth requirements based on user activity, and also included the now infamous ‘Restart Required’ nag that would reappear every 10 minutes until the user gave in and rebooted.

In Windows Vista and Server 2008, both the Windows Update web app and Automatic Updates were replaced with the Windows Update Agent. With this change, all file transfers would be handled in the background without user interaction, and the tool’s network usage would also be throttled based on user activity. With Windows 10, the option to selectively choose updates was removed, and patches began to be delivered in a peer-to-peer fashion. In addition, Windows 10 saw the introduction of Cumulative Updates which would bundle multiple patches together. This change reduced the number of updates to individually download, as well as reduced the total number of reboots required. ^[1] These monthly releases are sometimes also known as Quality Updates, in contrast to the larger Feature Updates that are released once or twice a year. ^[2]

Patch releases

Patches from Microsoft are on a schedule and the releases are as follows: ^[3]

‘B’ release or ‘Patch Tuesday’ occurs on the second Tuesday of each month. This is the primary and most important update of the month, and is the only release that includes new security fixes.
‘C’ releases occur the third week of the month and only contain non-security related updates. ‘C’ releases are intended to provide visibility and testing of the planned non-security fixes slated for the following month’s Patch Tuesday release.
‘Out-of-band’ releases are reserved for situations where there is a need for either an immediate fix for a security vulnerability, or to solve an issue impacting a large number of devices.

As patches are released, Microsoft’s Security Update Guide ^[4] is updated accordingly. This includes information such as:

Product – which describes the product family impacted by the vulnerability.
Severity – which explains the level of risk associated with the vulnerability.
Knowledge base – which links to the knowledge base, providing information on what was fixed, if there are any known issues, and if so, provides suitable workarounds.
CVE – which provides detailed information on the vulnerability, the CVSS score (Common Vulnerability Scoring System) and the metrics that went into calculating that score.

Severity is a rating to help Microsoft customers understand the risk of not updating their systems as follows: ^[5]

Rating	Description
Critical	A vulnerability whose exploitation could allow code execution *without* user interaction. These scenarios include self-propagating malware (e.g. network worms), or unavoidable common use scenarios where code execution occurs without warnings or prompts. This could mean browsing to a web page or opening an email. Microsoft recommends that customers apply Critical updates immediately.
Important	A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources. This includes common use scenarios where the client is compromised *with* warnings or prompts regardless of the prompt’s provenance, quality, or usability. Sequences of user actions that do not generate prompts or warnings are also covered. Microsoft recommends that customers apply Important updates at the earliest opportunity.
Moderate	Impact of the vulnerability is mitigated to a significant degree by factors such as authentication requirements or applicability only to non-default configurations. Microsoft recommends that customers consider applying the security update.
Low	Impact of the vulnerability is comprehensively mitigated by the characteristics of the affected component. Microsoft recommends that customers evaluate whether to apply the security update to the affected systems.

For further notifications on when security-related updates are available, users can sign up for Microsoft’s email notifications. ^[6] For these emails, there is a choice between a basic version and a more in-depth technical version, although both versions are written for IT professionals.

Government entities also have the option of signing up to the Government Security Program (GSP), which offers additional information: ^[7]

5-day advance notice of vulnerabilities with release notes and the affected software tables.
24-hour advance notification of public vulnerability announcements.

The GSP also includes online source access, IP addresses of known malicious devices and URLs, as well as direct access to Microsoft’s engineers and security experts.

How does Orange Cyberdefense notify customers?

Orange Cyberdefense provides customer updates using a service called World Watch. This service not only contains actionable expert advice, but it is also how Orange Cyberdefense communicates with customers during a high priority event. A recent example of a high priority event is Log4j, where significant information went out to customers using this service. ^[8]

Patch format and installation

With this background information in mind, let’s start diving into the more technical aspects. We will begin by looking at the MSU (Microsoft Standalone Update) which is illustrated in the image below:

As we can see the MSU is essentially just the outer layer which will contain multiple cab files. These contain metadata as well as the delta patches, which is what we’re interested in. But let’s first explain some key terms:

Base Version (V0) – This is a major software release such as 19043.1
Forward Delta – This is a delta to bring the base version to a specific version
Reverse Delta – This is a delta to bring a specific version back to the base version.
Null Delta – This is the actual file but in a patch format; applied to an empty file you will have the version of the patched binary.

In our case, the base version is 19043.1. If we then download a patch for a file (V0), and want to patch it to N, we can simply:

V0 + ΔN = VN

However, if the file is version N and we want to patch to version P, we need to use the following set of transformations:

VN + ΔN→0 = V0

V0 + Δ0→P = VP

So Windows Quality Update packages will contain forward differentials from the baseline (ΔBASE → P) as well as reverse differentials back to the base version (ΔP → BASE) for each file that has changed since the base version. But what happens in scenarios when new files are introduced? That’s where null deltas can be used, whereby new files are packaged in a delta file format.

When installing an update, a simplified version of the process looks like this:

Identify all files that are required to install the update.
Hydrate each of necessary files. (Note that ‘hydration’ is a term used by Microsoft to describe the transformation of update files when applying a delta.) This process is done by taking the current version (V_N) of the file, applying a reverse differential (V_N—>RTM) of the file back to Quality Update RTM/base version, and then applying a forward differential (V_RTM—>R) from Feature Update RTM/base version to the target version. Also, use null differential hydration to hydrate null compressed files.
Stage the hydrated files (full file), forward differentials (under ‘f’ folder) and reverse differentials (under ‘r’ folder) or null compressed files (under ‘n’ folder) in the component store (%windir%\WinSxS folder).
Resolve any dependencies and install components.
Clean up older state (V_N-1); the previous state V_N is retained for uninstallation and restoration or repair. ^[9]

In this first part of our series, we have provided a preliminary introduction covering when Windows patches are released, how update installations happen, and how the update files are constructed. In the next part we will continue with an introduction to binary diffing.

References