We have an Intel HEX file of the Dualcom firmware download from the CSL Dualcom website. HEX is a common format for distributing firmware. It has two big advantages. Firstly, there are checksums in the file. A single bit flipped in a firmware file can prevent it from working. Checksums prevent against this. Secondly, the file can specify addresses. This can make a small firmware far more compact, as you don’t need to explicitly define empty blocks of memory.
It isn’t, however, very helpful for analysis. We need to convert it into a pure binary form to start using other tools.
To do this, there is a Python package called IntelHex. Install this using:
pip install IntelHex
We then need to download the provided scripts to convert the HEX to binary.
Once we have the scripts, converting is simple
python hex2bin.py Dualcom_v353.hex Dualcom_v353.bin
We now have a binary file ~80k in size. This easily fits into the 128KB flash in the 78K0R processor.
Let’s take a quick look at this file using some readily available tools.
First up – strings. This is available in OS X and pretty much every Linux install. It looks for ASCII strings in binary files.
strings Dualcom_v353.bin
It defaults to show strings that are 4 and longer. It can be useful to take this down to 3 or even 2, but for a first look, the default is good.
Here is the output of that command.
What can we see of interest?
A copyright notice, version, and possibly a build date?
(C) 2004-2011 Dycon Ltd. 0353 Dualcom GPRS> Jan 16 2013 15:59:07
Loads of AT commands, presumably for the GPRS modem and PSTN modem:
AT*E2IPC AT^SISC AT+WIPCLOSE=2,1 #GPRS? +WIPBR? AT#SKTCT= AT^SISS=
Some fault text:
Invalid Code Invalid Command SMS Fault Command Failed
Some diagnostic output?:
: GPRS : LAN : PSTN : GSM : Signal : Ber : Line : Radio : LanF : Flt : Err : Chns : Bat : Temp : Poll : Pty
Dycon come up:
HELLO Dycon
There’s even a few bits that look like they could be passwords:
ahakaj aqajak ealajak53 aqajak
strings also allows us to see the address of the strings:
strings -t x Dualcomv353.bin
This shows the hex address of the string before the string. We can see that the obviously human readable strings start at 0x1000 and run to 0x1fd4. This is consistent with storing a string table in flash memory.
Another good check to do is to look at the entropy of the file. Strings have very low entropy (<0.3). Code, for a processor like the 78K0R, averages 0.75 entropy. Random data has an entropy of 1. Compressed data should be very close to random data. As should good key material. So if we see areas of the binary that have high entropy, it is worth investigating.
Binwalk, the binary firmware investigation tool, has built-in functionality to graph entropy in a file. After installing binwalk, simply run:
binwalk -E Dualcomv353.bin
Binwalk entropy graph
Unfortunately, all this shows us is that there is an area of low entropy (the strings) followed by middling entropy – this is likely just code. If there is key material in there, it is short or not random – both of which are bad for security.