I am currently trying to reverse-engineer a firmware file to learn the topic but I am a little bit stuck.

I tried to use binwalk to get more information about the file but this did not produce anything useful. Below is the output of running binwalk with the -I argument which shows results marked as invalid: enter image description here

Almost no useful information was discovered by using strings and hexdump to analyze the file. It seems that the file is encrypted or packed. Does anyone have any ideas that will help me continue investigating this? Maybe recommendations for some good tools to use?

  • I would start by using bffxtractor.py on those BFF volume entries. – tmp Jan 31 '17 at 19:16
  • Can you provide the file you are attempting to investigate and more details regarding the steps you have taken so far? – julian Jan 31 '17 at 19:33
  • Hi :) thanks for your answers :) I tested with bffxtractor.py and nothing. I have this "Unrecognized magic bytes! Quitting." I am checking with radare2 maybe I will find something interesting :) the file link – wawouille Feb 1 '17 at 8:49
  • @wawouille Help us help you by providing as much information about the file as you can. How do you know that this file is indeed a firmware image? Where did you get it from? What was the original file name? Can you explain why it is so small ( 61K )? Do you know what device this is for? The more information you provide, the more likely it is someone will be able to provide meaningful assistance. – julian Feb 2 '17 at 5:00
  • @SYS_V Yes, indeed. I found the "firmware" on this Web Site "" > inside the "NGA software" file. I do not know if it is really a firmware but they call it like that inside the file... I made researches and I found that it is maybe for a Cyberlock hub (embedded ARM device) but I am not really sure... I wanted to learn how to reverse engineer this :) I will buy the Cyberlock solution to play with. – wawouille Feb 2 '17 at 8:02

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 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: diff part 1

diff part 2

diff part 3

diff part 4

diff part 5

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.


binwalk does not detect any compression signatures in NGA_FW_CURRENT.BIN:



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:

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: entropy plot

This plot above suggests the following:

  1. 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.
  2. 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.
  3. 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

file structure visualization file entropy visualization ls structure ls entropy

        ^         ^          ^                ^                  ^
        |         |          |                |                  |
        |     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:


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.

#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 ]

        #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 ]
                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"
                echo "Firmware checking skipped (has already been checked $NUM_CHECKS times)"
        echo "Firmware check skipped (missing FWLoader or NGA_FW_CURRENT.BIN)"

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.