Reverse engineering a CSL Dualcom GPRS part 8 – logic analyser

Last time we powered up a board to see what it did just by observing the normal IO with our eyes.

This time we are going to look at what happens in more detail with this particular board using a logic analyser.

First things first, we’ll take the EEPROM out, pop it into our Bus Pirate EEPROM reader, pass the data through our converter, and then open the resulting .prm file in the CS2364 Windows utility.

This indicates that this board only has GPRS and PSTN paths enabled – no LAN.

Comms paths

There isn’t much else of note.

Running the .prm file through the strings utility we wrote provides very similar output to before – the same IP addresses and possibly the same password.

We now need to work out exactly what we want to connect to the logic analyser. The Dualcom has convenient test points grouped in threes and labelled GSM, PSTN, LAN and 485. It’s highly likely that these are serial connections – GND, TX, RX. A quick check of data sheets and use of the continuity tester confirms this.

Let’s solder some pin headers onto GSM serial, PSTN serial and also the socketed EEPROM. Pin headers make connecting and reconnecting the logic analyser very quick and easy compared to using test hooks.

We already know what is on the EEPROM, but we don’t know when and how the data is accessed – using a logic analyser will allow us to see this. This could be compared to static analysis (reading out the EEPROM entirely) and dynamic analysis (seeing how the EEPROM is accessed).

Often test points on hardware end up full of solder due to the manufacturing process. It’s awkward to remove this solder, so I just tend to tack pin headers on at a slight angle. To hold these, I use White Tack – a bit like Blu-Tak but holds out at soldering temperatures. Much easier than using helping hands or pliers.

DSCF0454

DSCF0456

Yep – the joints look dry. Lead-free solder + leaded solder seems to result in joints looking like this.

Once this is done, we connect up the logic analyser – the Saleae Logic. This is a USB logic analyser, and probably my most used reverse engineering tool. It is only 8-channel, but this is frequently more than adequate.

Saleae Logic

The connections end up as follows:

  • 1 (Black) GPRS RX
  • 2 (Brown) GPRS TX
  • 3 (Red) PSTN RX
  • 4 (Orange) PSTN TX
  • 5 (Yellow) DO EEPROM
  • 6 (Green) DI EEPROM
  • 7 (Blue) CLK EEPROM
  • 8 (Purple) CS EEPROM
  • GND (Grey) GND

I don’t have enough channels to monitor CS for the soldered on EEPROM. We’ll have to look at that another day.

Yes – GND is grey and channel 1 is black on the Saleae Logic. This has caught more than a few people out!

After a few trial runs, I find out that I can use the following settings for analysing the data:

  • GPRS RX/TX – 9600baud serial
  • PSTN RX/TX – 2400baud serial
  • EEPROM – SPI, CS active high, 30bits transferred

So now we have a good logic trace. At an overview level, you can see that everything is accessed at one point or another.

Logic trace

If we zoom in we can see EEPROM data transfers (this is a read – 0b110 is the command):

EEPROM

And a GPRS modem response:

GPRS

And the modem as well:

PSTN

You can download the settings/data for this trace here. This can be opened in the freely downloadable Saleae Logic program.

The next step is to decode some of this data further and see what is going on.

 

Reverse engineering a CSL Dualcom GPRS part 7 – board startup

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.

 

 

Reverse engineering a CSL Dualcom GPRS part 6 – interpreting EEPROM

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:

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

Python comes to the rescue again:

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

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:
Screen Shot 2014-03-31 at 15.40.11

User email enumeration vulnerability on CSL Dualcom’s password recovery site

CSL Dualcom allow users to reset their password on http://passwordrecovery.csldual.com/  (yes, no HTTPS, again).

The password reset functionality allows an attacker to enumerate valid usernames. Genuine usernames have a different response to invalid usernames.

The forgotten username functionality also allows an attacker to check for valid email addresses.

Leaking valid usernames and email addresses like this is an incredibly bad idea. An attacker can send crafted emails directly users to reset their passwords on a server under his control, for example.

Reverse engineering a CSL Dualcom GPRS part 5 – reading the EEPROM

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:
CS0355 NVM programmer

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

Connected to Bus Pirate

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

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:

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?
BP readout

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

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

with the start of the Sample.prm file:

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.

Reverse engineering a CSL Dualcom GPRS part 4 – programming utility

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:

CS2364

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

2014-03-29 23_06_20-CS2364 Programmer for DualCom GPRS 5.01 2014-03-29 23_05_48-CS2364 Programmer for DualCom GPRS 5.01 2014-03-29 23_05_34-CS2364 Programmer for DualCom GPRS 5.01

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.
2014-03-29 23_19_26-Process Monitor - C__Users_Andrew_AppData_Local_Temp_HBCD_ProcMon.pml

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

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

2014-03-29 23_24_17-Registry Editor

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?

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:

2014-03-29 23_42_03-CS2364 DualCom GPRS Programmer

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:

2014-03-29 23_45_24-CS2364 Programmer for DualCom GPRS Factory 5.01

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:

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:

2014-03-30 00_16_04-CS2364 Programmer for DualCom GPRS Factory 5.01

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

2014-03-30 00_18_00-C__Users_Public_Documents_CSL_CS2364 GPRS DualCom_Sample.prm - Notepad++

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:

The output of this can be downloaded here.

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

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:

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

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.

Why have I removed all the CSL Dualcom posts?

Update: the full report into the issues I found with the CS2300-R boards has been published.

Update: The posts are being republished November 2015.

As part of my reverse engineering of the CSL Dualcom alarm signalling boards, I have uncovered some issues that I would classify as vulnerabilities. I have recently informed CSL Dualcom about one the issues, alongside tweeting some rather unexpected findings about the encryption used.

In response to this, CSL Dualcom have requested that I remove the blog posts and tweets until I meet with them. I have decided, out of courtesy, to hide the posts for now. This is not an admission of any wrong doing, censorship of my posts, or response to legal threats.

As always, my approach to vulnerability disclosure is to follow the model of responsible disclosure. As this is an embedded system with a very large deployment, it would only be reasonable to have an extended period for the vendor to respond.