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:

We then need to download the provided scripts to convert the HEX to binary.

Once we have the scripts, converting is simple

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.

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?

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

Some fault text:

Some diagnostic output?:

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:

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

Reverse engineering a CSL Dualcom GPRS part 2 – online research

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

Dycon D2300

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

Reverse engineering a CSL Dualcom GPRS part 1 – preliminary research

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

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

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.

Hilarious still from CSL Dualcom’s NOC video

CSL Dualcom make their Network Operations Centre widely known.

When they posted a video, I thought I’d check them for sensitive information disclosure, like actual customer ICCIDs and chip numbers.

However, what I found was far funnier. On one of their own promotional videos, they show a close up of an member of staff using some kind of operations/support portal, but they are also logged into Hotmail.


To the left, the partially obscured tab says “o Be Loved?” – a dating site maybe?

Don’t let your staff use personal web email in your Network Operations Centre. This is idiocy.

CSL Dualcom installer shop not protected by TLS

CSL Dualcom operate an installer shop which is used to order Dualcom units. This handles personal information, including a username and password.

The site is not protected by TLS at all. Credentials and any other data will be sent in the plain over the Internet.

This is not acceptable in 2015.

This was reported to CSL in June 2014.


As of 14/11/2015, the site now uses TLS and is configured correctly. Why was this not done before? Why did it take exposing it on a blog to happen?

CSL Dualcom Gemini Cisco VPN endpoint vulnerable to POODLE attack

CSL Dualcom use Cisco VPN software to connect to their management platform, Gemini.

The server that does this is listed as

On inspection with SSLLabs test, there are configuration issues with the TLS on this server, giving it a grade F.

This includes vulnerability to the POODLE attack.

This was fixed a long time ago by Cisco.

Note that, as per the SSLLabs test, this is not the only issue.


As of 14/11/2015, the POODLE vulnerability has been closed. Again, you need to ask why this wasn’t picked up.


Customer database leak on CSL Dualcom’s SIM registration portal

CSL Dualcom sell SIMs for M2M purposes. They need to be registered on their website.

This website is – firstly note how this does not have TLS. This is not excusable in 2015.

On browsing the site, it was noted that the search string was limited to be 3 or more characters using client-side Javascript.

Using the site with Javascript turned off allowed a zero-length search to be submitted. Initially this appeared to cause the request to freeze. However, on waiting ~10 minutes, it became apparent that an empty search had returned every single record from the database – several megabytes of data.

All the companies

Through the UI this just appeared to be company name, town and postcode. However, inspection of the traffic showed that a massive JSON structure had been downloaded, including a company ID, “UniqueCode”, email address and often mobile number.

{“InstallerCompanyID”:”327398f6-431b-4495-8193-96789ecbe2bd”,”CompanyName”:”Minster Alarms”,”ContactName”:”Minster Alarms”,”PostCode”:”YO32 9NQ”,”Town”:”York”,”UniqueCode”:134265,”Accreditation”:”NSI”,”AddressOne”:”Suncliffe House”,”AddressTwo”:”New Lane, Huntington”,”County”:””,”Country”:”UK”,”CountryId”:0,”CurrencyId”:0,”Email”:”“,”Mobile”:“”}

On clicking the company name, a list of users was returned, including personal email addresses, phone numbers and usernames:


These issues were reported to CSL Dualcom on 1st May. The issues were acknowledged on the 3rd May and fixed on the 4th by limiting the fields available.

During the leak, over 5700 companies details were available. It was confirmed that some of these had never registered SIMs, so it is likely the full CSL customer database.

6 months on, the registration site is still using HTTP.


Vulnerability in Risco Lightsys protocol encryption

During a routine pen-test of an alarm receiving centre, a piece of software was found that was used to remotely configure Risco alarms.

This software communicates with alarm panels, sometimes over IP, sometimes over a mobile network. One of these panels is the Lightsys panel, which seems fairly common in the UK.

The encryption used by this protocol is token at best, and not suitable for securing communication across an untrusted network.

The protocol generates a psuedo-random sequence of numbers using a basic function. This is then XORed with the message to encrypt or decrypt.

Each panel has a “seed” that changes the encryption slightly. Because we have a partially known plaintext, you don’t need to know the seed to decrypt messages – it can just be determined. The seed tended to be the same across many panels.

A further proof of concept was developed that can send and receive commands with alarms, leading to a denial-of-service condition. I am not disclosing this as it can cause harm and is not the root cause of the problem.

This was reported to Risco on 7th August. As of yet, they have not indicated if they wish to fix this issue.


  • Don’t roll your own encryption
  • If you have a key, make sure it has enough length to actually improve security

Open Risco support portal including private FTP credentials

During a routine pen-test of an alarm receiving centre, I was googling for default usernames and passwords of Risco software and alarms.

When doing this, I found an abandoned support portal “Riscopedia” which contained a number of valid credentials for FTP sites, along with other private documentation.


Whilst the Technical.Notes account appears to be shut down, there are still paths onto other FTP servers that look like they should be closed.

This was reported to Risco on 30th July via Twitter and email.


Backdoor root account on Visonic Powerlink 2 modules

During a routine pen-test of an alarm receiving centre, a repository of manufacturer firmware was found. This is often quite hard to get hold of, and I welcomed the opportunity to reverse some of these.

The Visonic Powerlink 2 firmware stood out due to it’s large size – this was almost certainly an embedded Linux system.

On unpacking the firmware, it was found that the units had an enabled account with root privileges called root2 with the password visonic. I discovered this by cracking the password file. However, once I had done this, someone pointed out that this was widely documented as early as 2011.

The system runs telnet on port 7523, and a web interface on port 80. Shodan has ~85 of these visible at the moment.

Once you have root access, you can arm and disarm the connected alarm, and capture images from any connected cameras.

In addition to this, for the firmware and single unit I was permitted access to, it was found it was transmitting status messages (armed/disarmed status, serial number) over a plaintext connection to ( We could not find anywhere in the firmware to turn this off.

They would be an ideal pivot or persistance node in a longer term pen-test.