How to Compare Two Different Binary Files
One of our favorite new capabilities in the Centrifuge Spring ‘20 release is Firmware Differencing. This is how to compare two binary files quickly and efficiently for Linux, QNX, and VxWorks. But that’s not all it compares!
You can quickly see entire changes between two firmware versions by comparing the security analysis reports of the product’s old and new firmware. This can dramatically reduce the level of effort required to conduct product security assessments and streamline compliance checks. It can also help you identify changes that you weren’t expecting – either through a harmless mistake or something more malicious.
How to Compare Binary Files and More in Real Life
We blacked out the vendor and product names to protect the (not so) innocent. What we can say is that this firmware is from a popular device widely used on Enterprise and Government networks.
Earlier this year a vulnerability was publicly disclosed, which allowed a remote attacker to get root access to the device and do all kinds of cool bad things.
Let’s look at the patched firmware in Centrifuge.
With the new Compare Reports feature of Centrifuge, we can check the patched firmware results against the previous version that contained the critical vulnerability.
Here is a summary of the differences:
Overview of the Comparison Results – the left column is “previous” and right is “patched”
First let’s see about the fix for the remote exploit.
By clicking into the Code Analysis details we can see the changes. Notice that the
libHTTPService.so library had a buffer overflow, which Centrifuge now detects as fixed in the patched version. This was the public exploit.
Details on Differences in Potential 0-day Buffer Overflows – note the vulnerability was the buffer overflow in
We can’t resist pointing out that Centrifuge identified the vulnerability in the previous version as a potential 0-day! Yet there are still 10 potential buffer overflow vulnerabilities in that executable.
Pretty cool, right?
We can also dig into the file system to see what changed between releases. Again this makes conducting product security assessments much more efficient.
Notice that 15% of the total file system changed between the previous version and the patched version.
Identification of total file system changes with the patched firmware release
We did want to point out one more thing.
The new release patched the public remote exploit. However, some of the core
glibc libraries were regressed from version 2.22 back to 2.18. The result? A number of known vulnerabilities were introduced:
New known vulnerabilities introduced through regression of
Perhaps this regression was intentional to remove a higher severity CVE 2017–16997. But while doing so, the vendor introduced 18 older CVEs! Ouch.
The Centrifuge Platform now makes it easy to compare two different binary files–and more–between firmware images. Teams can quickly and efficiently identify what was fixed and what was broken as a result of the changes.
No more need to rely on open source tools. No more jumping on the command line to run
cmp. With the Centrifuge Platform, the ReFirm Labs team has taken binary differencing (aka binary diffing) and elevated it to a whole new level with entire firmware differencing (aka firmware diffing).
With all of these certification standards and compliance regulations, conducting product cyber-security assessments quickly becomes very complicated and expensive. Here’s how to save time and money.
GHIDRA may be the preferred tool of choice for analyzing RTOS firmware images. We will demonstrate identification of a published vulnerability as a case study.
Backdoored firmware found in the supply chain of video surveillance chips from HiSilicon (a subsidiary of Huawei) allows remote access via Telnet.