We’ve captured a trace of:

• The serial comms to the GPRS modem
• The serial comms to the PSTN modem
• The SPI comms to the EEPROM

Now we can take a look at the data in these traces. Let’s start with the communications with the GPRS modem.

The serial comms to the GPRS modem are normal ASCII characters, and it uses the AT command set. The GPRS modem is a Wavecom board – we can download the AT command set documentation.

Stepping through the logic trace and transcribing the commands, we end up with something like this:

The whole CSV file of this trace can be downloaded here.

What can we see going on?

1. The board is reset and some basic settings are sent (don’t echo commands, use DTR to close connection, turn on numeric errors).
2. Setup SMS messaging to store messages on the ME (the GPRS modem, as compared to the SIM). There seems to be room for 100 messages in the modem.
3. Setup three PDP contexts. I think these are essentially GRPS connections. The first two are generic and have no username/password – they might be Vodafone APNs. The third is a csldual.com – likely a private APN. An APN is a gateway between a GRPS connection and an IP network.
4. Setup three Internet accounts. These are credentials used with the PDP contexts. The generic ones have no username or password, but the csldual.com one does – dualcomgprsxx and QO6806xx.
5. The board periodically checks for network registration and signal strength. The signal strength is shown on the 7-seg display when idling. The GPRS modem is connected to the home network with decent signal strength.
6. The board then repeatedly scans the first 15 SMS slots for messages. There are no messages, so we get errors back. This is quite interesting – what is it that gets sent to the board as SMS?
7. The board then tries to connect to a private IP address/port 172.16.6.20:8965 using the csldual.com APN. The first time this is attempted it fails with error code 094, which isn’t listed in the documentation (or on the wider Internet…)
8. The board then tries to connect to the same IP again. This time it succeeds, and some data is sent back and forth. This is a string of ASCII text which looks, from a human perspective, fairly random.

The data looks like follows (sent on left, receive on right):

What things are of note in this trace then?

• The APN and the username and password used are constant across several devices and the Sample.prm I have looked at. It seems curious to require a password but for it not to vary.
• SMS messages are checked for frequently, suggesting something important is received by SMS.
• There is no notion of time/counters/nonce in any of the communications.
• There doesn’t see to be any key exchange
• There doesn’t seem to be any authentication of the APN/server with the GRPS Dualcom board.

This has raised a number of questions:

• What data is used to authenticate a given APN? If the username and password are constant, is the ICCID and other data used?
• Can anyone send SMS to the GPRS modem, or is there some form of blocking performed by the network in the other direction?
• Whilst the notion of time/counters/nonce isn’t essential for strong/good encryption, it does make things easier.
• A common failing of embedded systems that do use encryption is that they don’t change the key. Encryption with a fixed, known key is not really much better than no encryption.
• It’s been possible to spoof a cell site for a few years now using Software Defined Radio. If the APN/server can be spoofed, then the signalling might stop working.

I’m not sure what the next step is:

• Gather more traces and see if any patterns can be spotted in the data going between the board and server.
• Look at EEPROM accesses whilst the GPRS modem is being used.
• Disassemble the firmware and see if we can spot anything interesting.

I’ll see what takes my fancy next time I sit down and look at it.