So far, we’ve had a quick look at the hardware, the HEX file firmware, the utility used to program the NVM, and the contents of the NVM. It’s all building up a picture of what the board does and how it does it.

Next I want to power up one of the boards and look at it in operations – what does it actually do when we power it up?

The board just need 9-30V applied to power up. The GPRS module needs an antenna – there is a chance it could be harmed without one. I ordered a cheap GPRS antenna with an MMCX connector on it from eBay for under £5.

Here is one of the boards starting up:

The power-up sequence seems to vary from one board to the next, but for this video, it goes:

• Flashes 88 along with all LEDs (probably a test)
• Flashes firmware version number (2.02)
• Flashes grade (G2)
• Shows “ro” (reset radio module)
• Shows c1/2/3 (lower case c is radio call to ARC, 1 = dialling, 2=handshake, 3=sending data). The two GPRS status LEDs flash.
• Shows A (Comms successful)
• Shows E 21 – error 21 – “PSTN DC line voltage = low or none” – makes sense as I have no phone line connected

Some boards get to c1 and then fail with one of the lower numbered error codes related to the GPRS comms – probably because the SIM has been de-activated.

The next step will be getting the logic analyser onto some of the signals on the board to see exactly what it is doing.

In the last post we read out the contents of an EEPROM for one of the Dualcom GPRS boards. This is in the native Bus Pirate format:

0x00 0x47 0x00 0x25 0x01 0x25 0x00 0x40 0x32 0x52 0x00 0x41 0x00 0x00 0x00
 0x00 0x33 0x32 0x33 0x35 0x39 0x33 0x30 0x30 0x31 0x31 0x32 0x39 0x32 0x36 0x00
 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 0x00 0x33 0x32 0x33 0x35 0x39 0x33 0x30 0x30 0x31 0x31 0x32 0x39 0x30 0x36 0x00

and needs translating into a prm file for the Windows utility to read it.

Python comes to the rescue again:

datafile = open('/Users/andrew/data/BP.txt', 'r')
outfile = open('/Users/andrew/data/BP.prm', 'w')

hexValues = []

# Get all of the values into one big list
for row in datafile:
    values = row.split('0x')
    for value in values:
        if len(value) == 3:
            hexValues.append(value.strip())

# First row is different - handle this
first = True

# We want to flip values around
for i in range(0, len(hexValues)-1, 2):
    if first:
        # The first row is a special case
        outfile.write('H,' + hexValues[i+1] + ',' + hexValues[i] + '\n')
        first = False
    else:
        outfile.write(hexValues[i+1] + '\n')
        outfile.write(hexValues[i] + '\n')

# The fluff at the end of the file copidd from Sample.prm - hope no checksums!
footerfile = open('/Users/andrew/data/footer.txt', 'r')

for row in footerfile:
    outfile.write(row)

outfile .close()

We now have BP.prm. Let’s try opening that in the Windows utility:

Excellent! It works fine. A very old version of the firmware – 1.25!

Then if we whack this through the Python utility that converts it into strings, we get very similar output to before:

In part 4, I looked at the Windows utility that can be used to program the CSL Dualcom GPRS board. It seems to be able to do this one of two ways – over the air, but also by removing the socketed EEPROM chip on the board and putting it into a programmer connected to a PC.

I don’t have one of these programmers unfortunately – it’s called a CS0355 and looks like this:

I’ve asked around to see if anyone has one, but they don’t. It looks like a generic device, but I can’t find out enough to track one down. There is a .hex file in the CS0054 package that looks like it might have PIC code in it, so this might just be a simple PIC microcontroller acting as a EEPROM programmer.

Luckily we don’t need this programmer to read the contents of the EEPROM though – not when we have a Bus Pirate.

The 93C86 is an 16K Microwire Serial EEPROM. Microwire is Microchip’s nâme for their SPI-like protocol used for their ICs. It is very similar to SPI – Chip Select (CS), Clock (CLK), MISO (DO) and MOSI (DI). It doesn’t always work on 8-bit words though, so standard SPI hardware might not work.

This is fine though – the Bus Pirate has a mode called 3WIRE which allows us to bit-bang Microwire.

First we remove the 8-pin EEPROM from the CSL Dualcom GRPS, then put it into a breadboard. We connect it up as follows to the Bus Pirate:

• Pin 1 CS -> CS
• Pin 2 CLK -> CLK
• Pin 3 DI -> MOSI
• Pin 4 DO -> MISO
• Pin 5 VSS -> GND
• Pin 6 ORG -> Pin 8 VCC (This choses either 2048x8bit or 1024x16bit operation – this is arbitrary, I went for 16bit)
• Pin 7 PE -> can be left floating
• Pin 8 VCC -> 5V

Connected to Bus Pirate

Now we fire up our terminal and connect to the Bus Pirate.

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
x. exit(without change)

(1)>7
Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz

(1)>4
CS:
 1. CS
 2. /CS *default

(2)>1
Select output type:
 1. Open drain (H=Hi-Z, L=GND)
 2. Normal (H=3.3V, L=GND)

(1)>2
Ready
3WIRE>W
POWER SUPPLIES ON

First we change to 3WIRE using m, then option 7.

We then chose 400KHz, the fastest bit-banged 3WIRE can go.

CS is active high – contrary to many SPI devices. Chose 1.

Although the chip is a 5V device, 3.3V is detected as logic high by the specs, so we can stick with normal outputs.

Finally, capital W turns the 5V power supply on. The chip is now powered.

The next step is to read the data out. The chip has a convenient bulk read mode. Instead of having to do command + address + read, command + address + read, command + address + read etc. you can just do command + address + read + read + read – the chip will automatically increment the address.

Doing this with the Bus Pirate is easy:

[0b110;3 0x000;10 r:0x800;8]

Let’s break this down.

[ means assert CS to select the chip.

0b110;3 means send 110 in 3bits. If you just do 0b110, you send 8bits i.e. 00000110, which is not what we want.

0x000;10 means send 0000000000 as the address (i.e. the first address). This is 10bits when ORG is high (1024x16bit organisation).

r:0x800;8 means read 8bit values 0x800 (2048) times. For some reason I couldn’t get r:0x400;16 to work.

What do we get out of this?

There’s all of the data, from the EEPROM.

If we compare the start of the data read out from the EEPROM:

0x00 0x47 0x00 0x25

with the start of the Sample.prm file:

H,47,00
25
00

It looks like we have the same data, just ordered a little differently.

I can also spot some ASCII phone numbers and IPs in there.

It does look a lot like the prm file is just a representation of the EEPROM.

NOTE – slashes are getting messed with by WordPress, I am sure you’ll be able to work it out.

We’ve had a quick look at the HEX file, but what about the programming utility we have downloaded? This is to program the NVM (Non-Volatile Memory), which is a socketed EEPROM on the board. This is a quite common mechanism for storing and modifying settings in security equipment.

CS0054_setup.msi is a Windows installer that installs a series of applications in C:Program Files (x86)CSL. There are the following applications:

• CS0054 Universal Programmer
• CS1054 Programmer for Dualcom Plus
• CS2054 Programmer for Dualcom GSM
• CS2364 Programmer for Dualcom GRPS

Let’s start with CS2364 – the programmer for the DualCom GPRS. The others are older communicators that we don’t have. We might come back to the other utilities later.

When you start this program up, you are presented with a fairly blank screen:

And there a number of dialogs accessible, allowing us to set some obvious and not so obvious options:

The top most dialog required setting the option “System” in the options dialog. There are also a lot of greyed out options. How do we get them enabled?

The program looks like it is pretty old – VB, probably no notion of Internet connectivity. The settings are likely to be stored in a file or the registry.

Let’s use Process Monitor to… monitor the process. This is a Microsoft utility that shows file and registry activities for running programs. It can often hint at where a program is looking for settings and license keys.

You filter the output down to show the process and actions you want to see, or you will be overwhelmed by other application’s data.

We can see that the program accesses the following registry key:

HKCU\Software\VB and VBA Program Settings\CSL\CS2364 GPRS DualCom\Options\System

and reads a value of “True” from REG_SZ key:

If I turn off “System” in the options dialog, I see this value get set to “False”. This is good – the settings are stored very simply in the registry. So where else is the program looking?

HKCU\Software\VB and VBA Program Settings\CSL\CS2364 GPRS DualCom\Options\Factory
HKCU\Software\VB and VBA Program Settings\CSL\CS2364 GPRS DualCom\Options\Numbers
HKCU\Software\VB and VBA Program Settings\CSL\CS2364 GPRS DualCom\Options\Jamming
HKCU\Software\VB and VBA Program Settings\CSL\CS2364 GPRS DualCom\Options\Mon&Outputs

I can’t see any options in the front-end for these. Let’s create values and set them to “True”, one by one, and see what happens.

Factory

When we startup now, we get an error dialog:

There isn’t a file present called ServerList.dat – so it must be missing rather than malformed. .dat files are very often binary, so it can be hard to work out what should be in them. Disassembly is often the way forwards, but it’s not of importance at the moment.

Once in the program, we now have some additional options. Under View, we now have LAN:

Under NVM we now have Program (which just complains about the programmer not being present, as we have no programmer). It’s odd that without this setting, we can Read and Compare the EEPROM, but not

We also have a new option in the System dialog which says “NVM Config Requires Update”. I can’t see any other differences in the UI.

Numbers, Jamming, Mon&Outputs

I can’t see any difference with these set to True, or when I try various combinations of True/False.

So we seem to have the program in some kind of factory mode. All of the values are blank or 0 though. However, if we go to File, Open, we find Sample.prm. Open this file, and now the dialogs show numbers and settings. This must be an example for programming the EEPROM. Still a lot of

Opening the Sample.prm file in a text-editor, I can see that it is a text file, with the following format:

H,47,00
25
00
00
00
2F
00

00
00
00
00
00
00

If we look to the board, the socketed EEPROM is a 93C86 – which is a 2048x8bit EEPROM. It’s quite likely that this file represents the contents of that EEPROM with some overhead – maybe the Site Details are stored in the file but not the EEPROM.

I can see in the program that the SIM ICCID is as follows:

This is a long, unique number. We should be able to find this in the Sample.prm file:

There it is – stored as a number in 304-313.

Whilst looking at the file, I noticed a lot of values in the range 30-39. These are ASCII for 0-9 i.e. these could be numbers and text represented in ASCII instead of raw number as with the ICCID.

A quick python program to convert the ASCII range values into strings:

datafile = open('f:\data\Sample.prm','r')

combstr = ''

for row in datafile:
    # Just rows with a two character entry
    if len(row) == 3:
        # Ignore > 127 which are not simple ASCII
        if int(row,16) < 128:
            # Put a space for 0 to show breaks
            if (int(row,16) == 0):
                combstr = combstr + ' '
            else:
                combstr = combstr + chr(int(row,16))

outfile = open('f:\data\Sample.prm_string.txt', 'w')
outfile.write(combstr)
outfile.close()

The output of this can be downloaded here.

And now we can see that there are quite a few strings in the Sample.prm:

01895460023 // Phone number - as a string as likely it is sent via AT commands

172.168.10.10:9000 // IP address and port

apn6.com // Details including username and pass for an APN?
csldual.comv
dualcomgprs19
QO680677

Also, interestingly, the filename “Sample.prm” is stored in the file itself towards the end. This is probably the overhead that makes the prm file bigger than 2048 lines.

When exiting the program, it stores a new file – last.prm – which includes any changes you have made. There is no Save. Interestingly, when running this through the Python script above – I see the following:

CS2364:X220:Andrew

So that’s my hostname and login name for the machine stored in the overhead at the end. Interesting!

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.

My first step with all products is a detailed, online search for documentation, firmware, images, and so on. Although in isolation it is rare for these to provide anything really juicy, it all builds up a picture that can help us find a hole. Sometimes silly things like source code end up on open sites.

The CSL website itself has a number of useful documents and utilities.

The manual is fairly standard. It tells us a little about the displays and error codes. It also mentions being able to read and write settings from the NVM using software called CS0054.

Interestingly, there is also a firmware available on the site – “Dualcom v353.hex”. This looks like it is a normal Intel HEX file used to update firmware on an embedded system. Later we can examine this file or even disassemble it to see what the system is doing.

There is also a downloadable package of utilities called CS0054_setup.msi. This looks to contain 4 distinct utilities used to program different CSL communicators.

Looking further into the site, on the installer shop, we can find a number of high resolution images of the board (1, 2, 3, 4).

There are also high resolution images of the programmer used to update firmware (1, 2, 3, 4). This is a Renesas Minicube2, the debug/programming device for use with the 78K0R processor. This is promising – it likely means the HEX file is not obfuscated or encrypted, and normal Renesas tools can be used to update the board.

Having a further look about on Google, it appears that the CSL Dualcom boards have a lot in common  communicators made by another company called Dycon – specifically the Dycon D2300. I can’t see any information on the Dycon site that I haven’t already seen on the CSL Dualcom site. Question is, who actually makes the boards? What is the relationship between the two companies?

Dycon D2300

Google site search and basic directory exploration on the CSL Dualcom site hasn’t yielded anything further.

After showing my wireless alarm reverse engineering work to a few installers, ARC operators and manufacturers, it became clear that many were interested in looking at signalling devices rather than alarms themselves.

A signalling device is the piece of equipment that communicates with an Alarm Receiving Centre (ARC) to signal status such as “I’m all good” or “I’m in alarm”. They are essential on any serious alarm system and are used on everything from high-end domestic installs to banks and security deposit centres.

It’s clear that a security hole in a signalling device could have huge repercusions.

There are many signalling devices available – BT Redcare, WebWayOne, CSL Dualcom to name a few. CSL Dualcom has a large portion of the market, and I happened across a pile of 15 used Dualcom GPRS units. This makes them a good place to start.

This series is going to be a bit different to others. I’ve always finished or mostly finished by research before publishing before. This time, I’m going to publish work as I do it. It might be more rambling and verbose, but hopefully it will give people a better idea of the amount and range of work involved.

What is a CSL Dualcom GPRS?

From promotional material:

DualCom GPRS G2, from CSL DualCom Limited, is an intruder alarm signalling device that uses both the Vodafone network and your telephone path to transmit intruder and personal attack signals at high speed. Once the alarm is confirmed as genuine, police are notified. Utlising two signalling paths ensures that DualCom dual-signalling will always have a back-up path in the event of an accidental or deliberate fault on either path.

Essentially, it’s a small box which receives signals from the alarm system, and communicates with the ARC over both a GPRS (mobile phone data) connection and either a telephone line or IP connection.

I’m not seeing phrases like “encryption” and “military grade”. This is a good thing really.

I’ve really not had much experience with GPRS so this should be interesting.

What’s in a Dualcom GPRS?

It’s a small, plastic box partially enclosing a PCB. There are screw terminals, two buttons, two 7-segment LED displays, and a socketed 8-pin EEPROM.

Dualcom GPRS detail

I haven’t seen a UI so simple for a very long time.

“NVM” means Non Volatile Memory i.e an EEPROM. These are still quite common on security equipment. You pull the EEPROM, program it in an external device, put it back in.

There’s also terminals on the side for connecting to the PSTN (telephone line), and a SIM card socket. Nothing out of the ordinary.

Let’s pop the cover off:

Annotated diagram of Dualcom GPRS

Some more detail:

• The main processor is an NEC 78K0R/KF3, specifically a μPD78F1154. This is a 16bit processor with 128KB of flash, 8KB of RAM, ADCs, DACs, a load of IO, 4 UARTS, timers etc.
• In addition to the socketed EEPROM , there is an additional SMD EEPROM.
• A fairly large section of the board is for the PSTN modem.
• The GPRS modem is a Wavecom GR64 module, which is connected via a 60pin interface.

What to look at next?

Next we need to see what information is available on the Internet about this device.

I’ve been posting code and paths regently use the <pre></pre> tags to preserve formatting. WordPress, however has other ideas, and removes the and changes the <> into escaped codes (&gt; &lt;), which display incorrectly inside <pre></pre>.

You can workaround this by editing outside WordPress, pasting in, and saving – it works fine the first time. This is really awkward though.

It seems installing this plugin:

http://wordpress.org/plugins/preserve-code-formatting/

Solves the problem by making sure everything inside <pre> is not messed with.

c:\text\

if A < C: