Finding: NGA_FW_CURRENT.BIN is a compressed Videx microchip firmware image file.
Preliminary Remarks
There is conflicting background information given in the comments about the file alleged to be firmware in the question.
A gzip compressed data file called authorizer.tar.gz located at https://70.60.240.178:8443/CyberAuditWeb/services/nga/download/ under the header "Web Authorizer" from a link called "NGA software" contains a file called NGA_FW_CURRENT.BIN. This file is different from the file called firmware.BIN found at http://s000.tinyupload.com/?file_id=33872947945158763451.
It is this second file, firmware.BIN, that binwalk is run against in the image in the question. The source of firmware.BIN is unknown, since information about a different file, NGA_FW_CURRENT.BIN was given instead.
Diffing these two files shows that they may be related, as they are the same size of 61445 bytes and have similar structure:
Some of this information may prove useful in subsequent analysis. Since NGA_FW_CURRENT.BIN is the file at the location stated to be the source, it is this file that will be analyzed further and not firmware.BIN.
Analysis of NGA_FW_CURRENT.BIN
binwalk does not detect any compression signatures in NGA_FW_CURRENT.BIN:
$ binwalk NGA_FW_CURRENT.BIN
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
Entropy analysis, based on the work done by devttys0 in his article Differentiate Encryption From Compression Using Math, suggests that the file is compressed rather than encrypted.
- Lower chi values (< 300) with higher pi error (> .03%) are indicative of compression.
- Higher chi values (> 300) with lower pi errors (< .03%) are indicative of encryption.
Entropy analysis using ent:
$ ent NGA_FW_CURRENT.BIN
Entropy = 7.997014 bits per byte.
Optimum compression would reduce the size
of this 61445 byte file by 0 percent.
Chi square distribution for 61445 samples is 253.82, and randomly
would exceed this value 50.92 percent of the times.
Arithmetic mean value of data bytes is 127.6737 (127.5 = random).
Monte Carlo value for Pi is 3.126171875 (error 0.49 percent).
Serial correlation coefficient is 0.028565 (totally uncorrelated = 0.0).
A chi square distribution of 253.82 and a pi error value of 0.49 percent is within the range expected for compressed data.
Here is the entropy plot generated by binwalk:
This plot above suggests the following:
- High entropy beginning at offset 0x00 rather than further into the file means that there is no clearly discernible file header structure, which is unusual.
- The entropy line is rough rather than flat, suggesting compression rather than encryption. The rough line is a reflection of the non-uniform structure of the file hinted at by the diff of
firmware.BIN and NGA_FW_CURRENT.BIN. Certain blocks within the file have lower entropy than others.
- The precipitous drop in entropy at offset ~60000 (decimal) is indicative of a block of very low-entropy bytes at the end of the file
Juxtaposition of visualizations of NGA_FW_CURRENT.BIN with the Linux utility ls using binvis.io supports the above suggestions.
________ NGA_FW_CURRENT.BIN _______ ________________ ls _______________
| | | |
v v v v
^ ^ ^ ^ ^
| | | | |
| small area | obvious low entropy
| of low | structures throughout
| entropy | file
| high entropy
No structure throughout file
As we can see, the visualization of the structure of NGA_FW_CURRENT.BIN looks like white noise and has high entropy throughout, whereas ls has clear structures (ELF header, sections) and comparatively low entropy throughout.
Additional evidence indicating compression rather than encryption is the absence of encryption/decryption libraries and routines from the ARM ELF32 binary FWLoader, whose purpose is to load the device firmware during boot (see below).
Is NGA_FW_CURRENT.BIN a firmware image file?
The short answer is yes (probably).
The most direct evidence of this is found in the POSIX shell script S85_check_firmware in the system/rc3.d/ directory.
Here is the source code of S85_check_firmware:
#!/bin/sh
cd /firmware
#Since this script happens very early in the boot process we the opportunity to
# tell the user we are actually still booting as opposed to the keypad showing it's default
# "READY" message.
ngautil -p "CHECKINGFIRMWARE"
#This script checks the videx microchip firmware and reflashes it if necessary
#the FWLoader program must be executable
#and the LBServer.ini file must exist
if [ -x ./FWLoader -a -e ./NGA_FW_CURRENT.BIN ]
then
#increment the number of checks
echo checking >> checks.log
NUM_CHECKS=`grep -c checking checks.log`
#don't do the FW check if we've already checked many times with this FW version. This prevents
#endless an endless cycle of firmware loading and rebooting in case the firmware file is corrupt
if [ $NUM_CHECKS -lt 16 ]
then
echo "Executing firmware check #$NUM_CHECKS"
./FWLoader NGA_FW_CURRENT.BIN
#The above call to FWLoader will only attempt to load the firmware if the version in the chip
#is lesser than in the file. If the chip is already in boot-load mode (because fw loading was interrupted
# previously) it will force loading of the firmware.
#If fw is reloaded succesfully the device will be rebooted
echo "Firmware check complete"
else
echo "Firmware checking skipped (has already been checked $NUM_CHECKS times)"
fi
else
echo "Firmware check skipped (missing FWLoader or NGA_FW_CURRENT.BIN)"
fi
Since FWLoader generally "will only attempt to load the firmware if the version in the chip is lesser than in the file", the file in this case being NGA_FW_CURRENT.BIN, the key to decompressing NGA_FW_CURRENT.BIN must lie somewhere in FWLoader.
When the .rodata section of FWLoader is analyzed, a clue is discovered almost immediately:
Hex dump of section '.rodata':
0x000123cc 01000200 4e474120 4669726d 77617265 ....NGA Firmware
0x000123dc 204c6f61 64657220 7625730a 00000000 Loader v%s.....
0x000123ec 322e3000 55736167 653a205b 2d2d666f 2.0.Usage: [--fo
0x000123fc 7263655d 203c7061 74682074 6f206669 rce] <path to fi
0x0001240c 726d7761 72652066 696c653e 0a000000 rmware file>....
0x0001241c 4e6f7465 3a206669 726d7277 61726520 Note: firmrware
0x0001242c 66696c65 206d7573 74206265 20707265 file must be pre
0x0001243c 70656e64 65642077 69746820 76657273 pended with vers
0x0001244c 696f6e20 62797465 20616e64 20342062 ion byte and 4 b
0x0001245c 79746520 43524320 61732069 74206170 yte CRC as it ap
0x0001246c 70656172 7320696e 204c4254 6573742e pears in LBTest.
0x0001247c 696e690a 00000000 4661696c 65642074 ini.....Failed t
0x0001248c 6f207265 61642063 68697020 6669726d o read chip firm
0x0001249c 77617265 20766572 73696f6e 2e202853 ware version. (S
0x000124ac 7475636b 20696e20 626f6f74 6c6f6164 tuck in bootload
0x000124bc 206d6f64 653f290a 00000000 63526561 mode?).....cRea
< output snipped >
"Note: firmrware[sic] file must be prepended with version byte and 4 byte CRC as it appears in LBTest." (side note: on the download website for the authorizer.tar.gz that all of these files were extracted from, the version number was given as 37.3.3).
That basically gives it away. I'll post an update if/when I isolate the actual decompression code.
