Reverse engineering a CSL Dualcom GPRS part 3 – what’s in the HEX?

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

Loads of AT commands, presumably for the GPRS modem and PSTN modem:


Some fault text:

Invalid Code
Invalid Command
SMS Fault
Command Failed

Some diagnostic output?:

 : LAN 
 : PSTN 
 : GSM 
 : Signal 
 : Ber 
 : Line 
 : Radio 
 : LanF 
 : Flt 
 : Err 
 : Chns 
 : Bat 
 : Temp 
 : Poll 
 : Pty

Dycon come up:


There’s even a few bits that look like they could be passwords:


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

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.

Leave a Reply

Your email will not be published. Name and Email fields are required.

This site uses Akismet to reduce spam. Learn how your comment data is processed.