CWE-327: Use of a Broken or Risky Cryptographic Algorithm – CVE-2015-7286

CWE-255: Credentials Management – CVE-2015-7287

CWE-912: Hidden Functionality – CVE-2015-7288

The purpose of this blog post is to act as an intermediate step between the CERT disclosure and my detailed report. This is for people that are interested in some of the detail but don’t want to read a 27-page document.

First, some context.

What are these CSL Dualcom CS2300-R devices? Very simply, they are a small box that sits between an intruder alarm and a monitoring centre, providing a communications link. When an alarm goes off, they send a signal to the monitoring centre for action to be taken. They can send this over a mobile network, normal phone lines, or the Internet.

They protect homes, shops, offices, banks, jewellers, data centres and more. If they don’t work, alarms may not reach the monitoring centre. If their security is poor, thousands of spoofed alarms could be generated. To me, it is clear that the security of these devices must be to a reasonable standard.

I am firmly of the opinion that the security of the CS2300-R devices is very poor. I would not recommend that new CSL Dualcom signalling devices are installed (regardless of model), and I would advise seeking an alternative provider if any were found on a pen-test. This is irrespective of risk profile of the home or business.

If you do use any Dualcom signalling devices, I would be asking CSL to provide evidence that their newer units are secure. This would be a pen-test carried out by an independent third-party, not a test house or CSL.

What are the issues?

The report is long and has a number of issues that are only peripheral to the real problems.

I will be clear and honest at this point – the devices I have tested are labelled CS2300-R. It is not clear to myself or others if these are the same as CS2300 Gradeshift or any other CS2300 units CSL have sold. It is also not clear which firmware versions are available, or what differences between them are.

The devices were tested in the first half of 2014.

CSL have not specifically commented on any of the vulnerabilities. On the 20 November they finally made a statement to CERT.

Here is a summary of what I think is wrong.

1. The encryption is fundamentally flawed and badly implemented

The encryption cipher used by the CSL devices is one step above the simple Caesar Cipher. The Caesar Cipher is known and used by many children to encrypt messages – each character is shifted up or down by a known amount – the “key”. For example, with the key of “4”, we have:

1

2

3

Plain text:THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG

Key:444444444444444444444444444444444444

Cipher text:XLI UYMGO FVSAR JSB NYQTIH SZIV XLI PEDC HSK

CSL’s encryption scheme goes one step further, and uses a different shift as you move along the message. It’s a hybrid between a shift cipher and a polyalphabetic substitution cipher.

The mechanism the algorithm uses is like so:

1

2

3

Plain text:THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG

Key:439837469748612821721892179149127197

Cipher text:XKN YXPGQ KYSET GQF LVTRFL XXFY CII UBBF EXN

The first character is shifted up by 4, the next by 3, then 9, 8, 3 etc. This is simplified, but not by much.

It would be fair to say that this encryption scheme is very similar to a Vigenère cipher, first documented in 1553, even used fairly widely until the early 1900s. However, today, even under perfect use conditions, the Vigenère cipher is considered completely broken. It is only used for teaching cryptanalysis and by children for passing round notes. It is wholly unsuitable to use for electronic communications across an insecure network.

Notice that I said the Vigenère cipher was broken “even under perfect use conditions”. CSL have made some bad choices around the implementation of their algorithm. The cipher has been abused and is no longer in perfect use conditions.

An encryption scheme where the attacker knows the key and the cipher is totally broken – it provides no protection.

And CSL have given away the keys to the kingdom.

The key is the same for every single board. The key cannot be changed. The key is easy to find in the firmware.

An encryption scheme where the attacker knows the key and the cipher is completely and utterly broken.

Beyond that, CSL make a number of elementary mistakes in the protocol design. Even if the key is not known and fixed, it could easily be recovered from observing a very limited number of sent messages. The report details some of these mistakes. They aren’t subtle mistakes- they are glaring errors and omissions.

I cannot stress how bad this encryption is. Whoever developed it doesn’t even have basic knowledge of protocol design, never mind secure protocol design. I would expect this level of work to come from a short coursework from A-level IT students, not a security company.

2. Weak protection from substitution

The CS2300-R boards use two pieces of information to identify themselves. One is the 20-digit ICCID – most people would know this as the number on a SIM card. The other is a 6-digit “chip number”.

Both of these are sent in each message – the same message which we can easily decrypt. This leads to an attacker being able to easily determine the identification information, which could then be used to spoof messages from the device.

Beyond that, installers actually tweet images of the boards with either the ICCID or chip number clearly visible: 1, 2, 3.

This is a very weak form of substitution protection. There are many techniques which can be used to confirm that an embedded device is genuine without using information sent in the open, such as using a message authentication code or digital signature.

3. Unable to perform firmware updates over-the-air

It is both presumptuous and foolhardy to assume that the device you deploy on day one will be free of bugs and security issues.

This is why computers, phones, routers, thermostats, set-top boxes, and even cars, allow for firmware updates over-the-air. Deployed devices can be updated in the field, after bugs and vulnerabilities have been fixed.

It has been considered – for many years – that over-the-air firmware updates are an absolutely vital part of the security of any connected embedded system.

The CS2300-R boards examined have no capability for firmware update without visiting the board with a laptop and programmer. No installers that I questioned own a programmer. The alarm system needs to be put into engineering mode. The board needs to be removed from the alarm enclosure (and, most of the time it is held in with self-adhesive pads, making this awkward). The plastic cover needs to be removed. The programmer needs to be connected, and then the firmware updated. Imagine doing that for 100 boards, all at different sites.

At this point, we need to remember that CSL claim to have over 300,000 deployed boards.

If we imagine that it takes a low estimate of 5 minutes to update each of the 300,000 boards, that is over 1000 man-days of effort to deploy an update. If you use a more realistic time estimate, the amount of effort becomes scary.

This means that any issues found cannot and will not be fixed on deployed boards.

CSL have confirmed that none of their devices support over-the-air firmware updates.

CSL have given away the keys to the kingdom and cannot change the locks.

A software development life-cycle that has a product that cannot be updated fosters a do-not-care attitude. Why should CSL care about vulnerabilities if they cannot fix them? What would be their strategy if there was a serious, remotely exploitable vulnerability was found?

4. I do not believe the CS2300-R boards are standards compliant

One of the standards governing alarm signalling equipment is EN50136. These are a series of lengthy documents that are unfortunately not open access.

Only a small part actually discusses encryption and integrity. Even when they are discussed, it is in loose terms.

CSL have stated, in reference to my report:

As with all our products, this product has been certified as compliant to the required European standard EN-50136

Unfortunately, CSL will not clarify which version of the standards the CS2300-R devices have been tested to.

When symmetric encryption algorithms are used, key length shall be no less than 128 bits. When other algorithms are deployed, they shall provide similar level of cryptographical strength. Any hash functions used shall give a minimum of 256 bits output. Regular automatic key changes shall be used with machine generated randomized keys.

Hash functions and encryption algorithms used shall be publicly available and shall have passed peer review as suitable for this application.

These security measures apply to all data and management functions of the alarm transmission system including remote configuration, software/firmware changes of all alarm transmission equipment.

There are newer versions of the standard, but they are fundamentally the same.

My interpretation of this is as follows:

Cryptography algorithms used should be in the public domain and peer reviewed as suitable for this application.

We are talking DES, AES, RSA, SHA, MD5. Not an algorithm designed in-house by someone with little to no cryptographic knowledge. The cryptography used in the CS2300-R boards examined is unsuitable for use in any system, never mind this specific application.

When the algorithm was sent as a Python script to one cryptographer, they assumed I had sent the wrong file because it was so bad.

The next I sent it to said:

I’ve never thought I’d see the day that someone wrote a variant on XOR encryption that offered less than 8 bits of security, but here we are.

We’re talking nanosecond scale brute force.

Key length should be 128 bits if a symmetric algorithm is used.

A reasonable interpretation of this requirement is that the encryption should provide strength equivalent to AES-128 from brute-force attacks. AES-128 will currently resist brute-force for longer than the universe has existed. This is strong enough.

The CSL algorithm is many orders of magnitude less secure than this. Given the fixed mapping table, a message can be decrypted in the order of nanoseconds.

Regular is obviously open to interpretation. There is a balance to be struck here. You need to change keys often enough that they cannot be brute-forced or uncovered. But key exchange is a risky process – keys can be sniffed and exchanges can fail (resulting in loss of communications).

Regardless, the CS2300-R boards have no facility at all for changing the keys. The key is in the firmware and can never change.

All data and management functions including remote configuration should be protected by the encryption detailed.

The CS2300-R have a documented SMS remote control system, protected by a 6-digit PIN. This is not symmetric encryption, this is not 128-bit, this is not peer-reviewed.

This is a remote control system protected by a short PIN (and it seems that PIN is often the same – 001984 – and installers don’t have the ability to change it).

Data should be protected from accidental or deliberate alteration

The message can easily be altered by accident or by malice. Look at this example:

1

2

3

4

5

Status:89441012345678901237A1234561111111111111117

Encrypted:2i7MZCNhHRdkZpYTX2fiLMIaEbo02SKe5L3EbPYWRkn

Shift:0000000000000000000000000004444444444444440

Altered:2i7MZCNhHRdkZpYTX2fiLMIaEbo46WOi9P7IfT20Von

Decrypted:89441012345678901237A1234565555555555555557

By adding four to a character in the encrypted text, we add four to the decrypted character. This means that the message content has been altered significantly, and very easily. The altered part of the message is the alarm status.

I can see no way that these units are compliant with this standard. CSL, however, say they are certified.

5. I do not believe third-party certification is worthwhile

It’s still not actually clear which units have been tested. The certificate says CS2300, my units say CS2300-R, but CSL say that the units I have looked at have been tested.

After meeting with the test house I have an idea of what happened here.

The test house would not discuss the CS2300 certification specifically, due to client confidentiality. They did discuss the EN50136 standard and testing in general.

Firstly, I was not reassured that the test house has the technical ability to test any cryptographic or electronic security aspects of the standard. Their skills do not lie in this area. At a number of points during the meeting I was surprised about their lack of knowledge around cryptography.

Secondly, there are areas of standards where a manufacturer can self-declare that they are compliant. The test house expected, if another unit was to be tested, the sections on encryption and electronic security would be self-declared by the manufacturer. Note that the test house can still scrutinise evidence around a self-declaration.

Thirdly, there is no way for a third-party to see any detail around the testing without both the manufacturer and test house agreeing to release the data. To everyone else, it’s just a certificate.

From this, I can infer that the CS2300 – and probably other signalling devices, even from other manufacturers – have not actually had the encryption or other electronic security tested by a competent third-party.

I don’t feel that this is made clear enough by either manufacturers or test houses.

6. I do not think the standard is strict enough

I acknowledge that the standard must cover a range of devices, of different costs, protecting different risks, and across the EU. It must be a lot of work drawing up such a standard.

Regardless of this, the section on encryption and substitution protection is so wishy-washy that it would be entirely possible to build a compliant device that had gaping security holes in it.

Encryption, by itself, is not enough to maintain the security of a system. This is widely known in the information security and cryptography world. It’s perfectly possible to chain together sound cryptographic primitives into a useless system. There is nothing in the standard to protect against this.

7. CSL do not have a security culture

There are so many issues with the CS2300-R system it is almost unbelievable.

(It is worth noting that CSL added TLS to their shop and fixed the VPN server after I blogged about them a few weeks ago – why does it take blog posts before trivially simple issues are fixed?)

CSL do not have a vulnerability disclosure policy. It was clear that CSL did not know how to handle a vulnerability report.

CSL have refused to discuss any detail without a non-disclosure agreement in place.

There is no evidence that CSL’s security has undergone any form of scrutiny. Even a rudimentary half-day assessment would have picked up many of the issues with their website.

There is also a degree of spin in their marketing and sales. A number of installers and ARCs questioned believe that the device forms a VPN to CSL’s server. Some also believe that the device uses AES-256. Indeed, their director of IT, Santosh Chandorkar claimed to me that the CS2300-R formed a VPN with their servers. There is no evidence in the firmware to support any of these claims, but there is also no way for a normal user to confirm what is and isn’t happening.

At a meeting, Rob Evans inferred that it would be my fault should these issues be exploited after I released them. He used the example of someone getting hurt on a premises protected by their devices. It obviously would not the fault of the company that developed the system.

IP requires elaborate encryption because it sends data across the open Internet. In my 25 years’ experience I’ve never been aware of a signalling substitution or ‘hack’, and have never seen the need for advanced 128 bit encryption when it comes to traditional security signalling.

No need for 128 bit encryption, Simon. Only the standard.

Conclusion

The seven issues to take away from this are:

CSL have developed incredibly bad encryption, on a par with techniques state-of-the-art in the time before computers.

CSL have not protected against substitution very well

CSL can’t fix issues when they are found because they can’t update the firmware

There seems to be a big gap between the observed behaviour of the CS2300-R boards and the standards

It’s likely that the test house didn’t actually test the encryption or electronic security

Even if a device adheres to the standard, it could still be full of holes

CSL either lack the skill or drive to develop secure systems, making mistake after mistake

What do I think should happen as a result of this?

All signalling devices should be pen-tested by a competent third-party

A cut-down report should be available to users of the devices, detailing what was tested and the results of the testing

The standards, and the standards testing, needs to include pen-testing rather than compliance testing

The physical security market needs to catch up with the last 10 years of information security

Rebuttals

CSL have made some statements about this.

This only impacts a limited number of units

CSL have stated:

Of the product type mentioned in his report there are only around 600 units in the field

If it is only a subset of units labelled CS2300-R, how does a user work out which ones are impacted?

The other 299,400 devices may not be the same unit, but how do they differ? Has a competent third-party tested the encryption and electronic security?

We have done an internal review

CSL have stated:

Our internal review of the report concluded there is no threat to these systems

Ask yourself this: if someone has deployed a system with this many issues in it, why should you trust their judgement as to the security of the system now? Are they competent to judge? There is no evidence that they are.

They have been third-party tested

CSL have stated, specifically in reference to my report:

As with all our products, this product has been certified as compliant to the required European standard EN-50136

This worries me. This says that the very device I have examined – the one full of security problems – got past EN-50136 testing. If this device can pass, practically anything can pass.

But I am fairly sure that the standards testing essentially allows the manufacturer to complete the exercise on paper alone.

The devices are old

The product tested was a 6 year old GPRS/IP Dualpath signalling
unit.

Firstly, there are at least 600 of these still in service.

Secondly, when the research was carried out, the boards were 4.5 years old.

Thirdly, does that mean that a 6 year old product is obsolete? Does that mean they don’t support it any more?

The threat model isn’t the one we are designed for

This testing was conducted in a lab environment that isn’t
representative of the threat model the product is designed to be implemented in
line with. The Dualpath signalling unit is designed to be used as part of a
physically secured environment with threat actors that would not be targeting
the device but the assets of the device End User.

This seems to have been a sticking point with some of the more backwards members of the security industry as well.

The reverse engineering work was done in a lab. As with nearly all vulnerability research, there needs to be a large initial investment in time and effort. Once vulnerabilities have been found, they can be exploited outside of the lab environment.

If the threat actors aren’t targeting the device, why bother with dual path?

Again, it doesn’t look like the devices comply with the standards. This is what counts.

They aren’t remotely exploitable

No vulnerabilities were identified that could be exploited remotely via
either the PSTN connectivity or GPRS connection which significantly reduces the
impact of the vulnerabilities identified.

I disagree with this. CSL and a number of their supporters do not seem to want to accept that GPRS data can no longer be classed as secure.

This still leaves the gaping holes on the IP side. When I met CSL at IFSEC 2014, they strongly implied that the number of IP units they sold was negligible. There seem to be more than a few getting installed though.

The price point is too low

The price point for the DualCom unit is £200 / $350. CSL DualCom also
have devices in their portfolio that are tamper resistant or tamper evident to
enable customers to defend against more advanced or better funded threat
actors. Customers are then able to spend on defence in line with the value of
their assets.

I’m not sure why the price is relevant. Are CSL saying it’s too cheap to be properly secure?

I can’t find any of these tamper resistant or tamper evident devices for sale – it would be interesting to see what they are.

Very few of the issues raised involve physically tampering with the device. They are generally installed in a protected area.

These aren’t problems, but we are releasing a product that fixes the issues

If customers are concerned about the impact of these vulnerabilities CSL are
releasing a new product in May which addresses all of the areas highlighted.

So on one hand, these vulnerabilities aren’t issues, but they are issues enough that you’ve developed a new product to fix them? Righty ho.

Firmware updates are vulnerable, but not normal communications

CSL products are not remotely patchable as we believe over the air updates
could be susceptible to compromise by the very threat actors we are defending
against.

What?

Just a few paragraphs ago, you say that you are not protecting against the kind of threat actor that can carry out attacks as in the report. But you are protecting against a threat actor that can intercept firmware updates?

Why allow critical settings to be changed over SMS if this is an issue?

What-if rebuttals

These are things that haven’t been directly stated by CSL or others, but I suspect that people will raise them

These issues are not being exploited

During discussions with CSL, they seemed very focused on what has happened in the past. I had no evidence of attacks being carried out against their system, and neither did they. Therefore, in their eyes, the vulnerabilities were not an issue.

We don’t mind issues being brought to us privately

He works for a competitor

Firstly, I don’t. I have spoken to competitors to find out how they work.

Secondly, this would not detract from the glaring holes in the system.

He is blackmailing people in the security industry

I have released vulnerabilities in Visonic and Risco products. Shortly, there will be a vulnerability in the RSI Videofied systems. None of these people have been asked for payment and have been given 45+ days to respond to issues. This is a fair way of disclosing issues.

I do paid work with others in the security industry. Again, at no point has payment been requested to keep issues quiet.

I have never asked CSL for payment. At several points they have asked to work with me, which I have turned down as I don’t think their security problems are going to be resolved given their culture.

The encryption and electronic security are adequate

It’s hard to explain (to someone outside of infosec) just how bad the encryption is. It is orders of magnitude less strong than encryption used by Netscape Navigator in 2001.

The problems found have been widely known for 20+ years, and many are easy to protect against. Importantly, it appears that their competitors – at least WebWayOne and BT Redcare – aren’t making the same mistakes.

The GPRS network is secure

This was true 15 years ago. It is now possible – cheaply and easily – to spoof a cell site and then intercept GPRS communications. You cannot rely on the security of the GRPS network alone.

Further to this, exactly the same protocol is used over the Internet.

But above all, the standards don’t differentiate between GPRS and the Internet – they are both packet switched networks and must be secured similarly.

Two intetesting subs that are called frequently to move working memory onto stack and back again

The board supports several GPRS modems – the Wavecom GR64 on the boards I have, but also Cinterion and Telit. The AT command set between the modems is completely different, so there are often several sections of code for common functionality like “Activate PDP context”. I’ve only looked at the Wavecom parts.

Having all this has given me enough to tie observed behaviour (just from using the Dualcom board, and the logic traces) back to specific areas of the code. Seeing the strings on the UART and searching for the address where that string is stored in flash/EEPROM is very useful.

I’m fairly sure the code is compiled C from IAR Embedded Workbench – the multiply, divide and startup are identical. If I compile code from Renesas Cubesuite, it looks very different.

There is still a lot of code that looks like assembly though – some of the memory operations, calling convention, and string searching look very odd to be compiled C.

One thing that caught my eye during the serial trace was that the board repeatedly checks for SMS messages. This suggests it is waiting for something to arrive, possibly commands

Digging around a bit, in the manual for the Dualcom GSM (not the GPRS), it mentions SMS remote control – sending commands to the CSL Dualcom:

SMS Remote commands

This is interesting. A 6 digit PIN and some limited commands. It wouldn’t be the first time that PINs are defaulted to a certain value or derived from open information like the ICCID or number. It also wouldn’t be the first time that there are undocumented or hidden commands for a device, or even a backdoor.

We’re going to need to have a dig about in the code to see how these commands are dealt with. A good starting point would be to find where the string AT+CMGR (read text messages) is used, and follow on from there.

AT+CMGR is stored in the flash at 0x1BE6 (0x1000-0x2000 is almost exclusively strings and lookup tables). If we search for this address, we find the following chunk:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

// State 0x86

// Request text messages

0c657afc8f5 MOVW AX,!0F5C8H// This is used as a time out

0c65a7c80XORA,#80H

0c65c440180CMPW AX,#8001H

0c65fdc07 BC$0C668H

0c661d46a CMP00FFE6AH

0c66361f8SKNZ

0c665ee3902 BR$!0C8A1H

0c668e1 ONEBA

0c669fc64d700 CALL sub_Serial_ResetBuffers

0c66d32b61eMOVW BC,#1EB6H // AT+CMGR=

0c670e1 ONEBA

0c671fcd1e100 CALL sub_Serial_WriteString_e1d1

0c6758f49f7MOVA,!0F749H

0c67872MOVC,A

0c679f3 CLRBB

0c67ae1 ONEBA

0c67bfc04e200 CALL sub_Serial_WriteHexAsDec_e204

0c67ff46b CLRB0FFE6BH

0c681f46a CLRB0FFE6AH

0c683cf41f704 MOV!0F741H,#4H

0c687530dMOVB,#0DH //CR

0c689e1 ONEBA

0c68afcb2e100 CALL sub_Serial_WriteChar_e1b3

0c68e30a302MOVW AX,#2A3H

0c691bfc8f5 MOVW!0F5C8H,AX// set timeout to 675

0c694cf4af704 MOV!0F74AH,#4H // State 4 next

0c698ee0602 BR$!0C8A1H

This is a massive state machine. The “state” is stored in 0xF74A, checked at the beginning of the sub and then a branch performed to the current state.. State 0x86 sends “AT+CMGR=1” to UART1. It then sets the next state to 0x4.

Each one of the states sets a counter in 0xFF5C8 which is decremented in the timer interrupt. If this is hit, the state machine seems to be reset in most cases.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

// State 0x4

// State after requesting text messages

0c69bafc8f5 MOVW AX,!0F5C8H// timeout

0c69e7c80XORA,#80H

0c6a0440180CMPW AX,#8001H

0c6a3dc42 BC$0C6E7H

0c6a58f19f7MOVA,!0F719H

0c6a84c02CMPA,#2H

0c6aa61d8SKNC

0c6aceef201 BR$!0C8A1H

0c6af32c01eMOVW BC,#1EC0H // "REC "

0c6b2e1 ONEBA

0c6b3fcd3de00 CALL sub_Serial_FindInRX_ded3

0c6b7d1 CMP0A

0c6b8dd0d BZ$0C6C7H

0c6ba30a302MOVW AX,#2A3H

0c6bdbfc8f5 MOVW!0F5C8H,AX

0c6c0cf4af718 MOV!0F74AH,#18H // State 0x18 next

0c6c4eeda01 BR$!0C8A1H

0c6c732c61eMOVW BC,#1EC6H // "STO "

0c6cae1 ONEBA

0c6cbfcd3de00 CALL sub_Serial_FindInRX_ded3

0c6cfd1 CMP0A

0c6d0dd07 BZ$0C6D9H

0c6d2cf4af717 MOV!0F74AH,#17H // State 0x17 next

0c6d6eec801 BR$!0C8A1H

0c6d93152410aBT0FFE41H.5H,$0C6E7H

0c6ddafdef5 MOVW AX,!0F5DEH

0c6e07c80XORA,#80H

0c6e2440180CMPW AX,#8001H

0c6e5dc0b BC$0C6F2H

0c6e7cf49f70f MOV!0F749H,#0FH

0c6ebcf4af796 MOV!0F74AH,#96H // State 0x96 next

0c6efeeaf01 BR$!0C8A1H

State 0x4 searches the receive buffer on UART1 for the characters “REC” or “STO”. “REC” is what we would see if there was a text message to read, and if this is found we move to stat 0x18. This calls 0xC301 and the flow continues from there. It might be better to describe this as a process rather than show ASM.

In addition to finding the most frequently called functions, we should go through the memory map and identify importants parts of it.

One part of this that is very important to how the device operates is the vector table, right at the bottom of the flash.

The vector table contains addresses that are called when certain interrupts are triggered. For these microcontrollers, this is structured like this:

So we take a look right at the beginning of the disassembly:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

0000000NOP

0000101ADDW AX,AX

0000282INCC

000032084SUBW SP,#84H

000052086SUBW SP,#86H

000072088SUBW SP,#88H

00009208aSUBW SP,#8AH

0000b208cSUBW SP,#8CH

0000d208eSUBW SP,#8EH

0000f2090SUBW SP,#90H

000112092SUBW SP,#92H

000132001SUBW SP,#1H

00015247d23SUBW AX,#237DH

00018292494MOVA,9424H[C]

0001b2096SUBW SP,#96H

0001d203aSUBW SP,#3AH

0001f21?

00020be20 MOVW PM0,AX

000223c21SUBCA,#21H

0002492DECC

00025225921SUBW AX,!2159H

00028ba22 MOVW[DE+22H],AX

0002a9820MOV[SP+20H],A

0002c00NOP

0002d209aSUBW SP,#9AH

0002f209cSUBW SP,#9CH

00031209eSUBW SP,#9EH

0003320a0SUBW SP,#0A0H

0003520a2SUBW SP,#0A2H

0003720a4SUBW SP,#0A4H

0003920a6SUBW SP,#0A6H

0003b205eSUBW SP,#5EH

0003d23SUBW AX,BC

0003ed7 RET

0003f226023SUBW AX,!2360H

00042a820 MOVW AX,[SP+20H]

00044aa20 MOVW AX,[DE+20H]

00046ac20 MOVW AX,[HL+20H]

00048ae20 MOVW AX,PM0

0004ab020b2 DEC!0B220H

0004d20b4SUBW SP,#0B4H

0004f20b6SUBW SP,#0B6H

0005120b8SUBW SP,#0B8H

0005320baSUBW SP,#0BAH

0005520ffSUBW SP,#0FFH

The disassembler has tried to disassemble when it shouldn’t – a common issue. Though, to be honest, it should know that this area is a vector table.

So if we re-organise the hex file into something a bit more readable, we get this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

0000-&gt;0100*RESET

0004-&gt;2082

0006-&gt;2086

0008-&gt;2088

000A-&gt;208A

000C-&gt;208C

000E-&gt;208E

0010-&gt;2090

0012-&gt;2092

0014-&gt;2401*INTST3

0016-&gt;237D*INTSR3

0018-&gt;2429*INTSRE3

001A-&gt;2094

001C-&gt;2096

001E-&gt;213A*INST0

0020-&gt;20BE*INTSR0

0022-&gt;213C*INTSRE0

0024-&gt;2292*INTST1

0026-&gt;2159*INTSR1

0028-&gt;22BA*INTSRE1

002A-&gt;2098

002C-&gt;2000*INTTM00

002E-&gt;209A

0030-&gt;209C

0032-&gt;209E

0034-&gt;20A0

0036-&gt;20A2

0038-&gt;20A4

003A-&gt;20A6

003C-&gt;235E*INTST2

003E-&gt;22D7*INTSR2

0040-&gt;2360*INTSRE2

0042-&gt;20A8

0044-&gt;20AA

0046-&gt;20AC

0048-&gt;20AE

004A-&gt;20B0

004C-&gt;20B2

004E-&gt;20B4

0050-&gt;20B6

0052-&gt;20B8

0054-&gt;20BA

Notice how a lot of the addresses are just incrementing- 20AA, 20AC, 20AE. This is just a massive block of RETI instructions – i.e. the interrupt handler just returns immediately – it is not implemented.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

0209261fcRETI

0209461fcRETI

0209661fcRETI

0209861fcRETI

0209a61fcRETI

0209c61fcRETI

0209e61fcRETI

020a061fcRETI

020a261fcRETI

020a461fcRETI

020a661fcRETI

020a861fcRETI

020aa61fcRETI

020ac61fcRETI

020ae61fcRETI

020b061fcRETI

020b261fcRETI

All of the vectors that are marked with an asterisk and with a name are implemented or used by the board. There are some important handlers here – mainly the serial IO.

Reset jumps to 0x100. I’ll save looking at that for another time – mostly the reset vector will be setting up buffers, memory, pointers, some checks.

You can also see we have groups of interrupt handlers for INTST* (transmit finished), INTSR* (receive finished), INTSRE* (receive error). These are for the the UARTs 0-3 respectively. Their implementation is very similar – let’s look at UART1 which is used for the GPRS modem.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

// INTST1

02292c1 PUSH AX

02293c3 PUSH BC

02294c7 PUSH HL

02295fbb6e0 MOVW HL,!0E0B6H

02298afb4e0 MOVW AX,!0E0B4H

0229b47CMPW AX,HL

0229cdd17 BZ$22B5H

0229edbb4e0 MOVW BC,!0E0B4H

022a149b8e4MOVA,0E4B8H[BC]// Get data from E4B8 using offset from E0B4

022a49e44MOV SIO10,A// Move to serial data TX register

022a6a2b4e0 INCW!0E0B4H// Increment the offset

022a9afb4e0 MOVW AX,!0E0B4H

022ac440a04CMPW AX,#40AH // Is the offset greater than 1034? If so reset to 0

022afdc04 BC$22B5H

022b1f6 CLRW AX

022b2bfb4e0 MOVW!0E0B4H,AX

022b5c6 POP HL

022b6c2 POP BC

022b7c0 POP AX

022b861fcRETI

Again – I’m not really currently interested in precise detail, just an idea of what is happening. This handler takes a byte from a buffer at 0xE4B8 and writes it into the transmit register. That buffer will appear elsewhere in the code and hint to us when something is being sent out of UART1.

We can then go through all of the other UART/serial functions and identify potential transmit/receive buffers.

Interestingly, INTST0 and INTST2 are just RETI instructions. Why do these not require a transmit empty interrupt handler? Is it handled in software elsewhere?

The next handler that stands out from the others is INTTM00. This is the timer interrupt for timer 0 which will fire when the timer hits a certain value.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

// INTTM00

02000c1 PUSH AX

02001c3 PUSH BC

02002c7 PUSH HL

02003aefc MOVW AX,0FFFFCH

02005c1 PUSH AX

02006a0b3f6 INC!0F6B3H

020098fb3f6MOVA,!0F6B3H

0200c5c03ANDA,#3H

0200e4c03CMPA,#3H

02010df38 BNZ$204AH

02012a0b4f6 INC!0F6B4H

02015fcfc2801 CALL!!128FCH

02019fc932601 CALL!!12693H

0201dfcf22701 CALL!!127F2H

02021f45c CLRB0FFE5CH

02023fc132a01 CALL!!12A13H// 7SEG display

02027fcaa3201 CALL!!132AAH// Buttons

0202b8fb4f6MOVA,!0F6B4H

0202e5c03ANDA,#3H

02030dd08 BZ$203AH

0203291DECA

02033dd0b BZ$2040H

0203591DECA

02036dd0e BZ$2046H

02038ef10 BR$204AH

0203afccbff00 CALL!!0FFCBH// Analog

0203eef0a BR$204AH

02040fcd13101 CALL!!131D1H

02044ef04 BR$204AH

02046fc063301 CALL!!13306H

0204afc742e01 CALL!!12E74H

0204efc84ff00 CALL!!0FF84H

0205272MOVC,A

0205381INCA

02054dd24 BZ$207AH

0205662MOVA,C

0205770MOVX,A

02058f1 CLRBA

0205901ADDW AX,AX

0205a04b8f5ADDW AX,#0F5B8H

0205d16MOVW HL,AX

0205ef6 CLRW AX

0205fb1 DECW AX

02060bb MOVW[HL],AX

0206162MOVA,C

02062d1 CMP0A

02063dd11 BZ$2076H

020652c11SUBA,#11H

02067dd05 BZ$206EH

0206991DECA

0206add06 BZ$2072H

0206cef0c BR$207AH

0206ee46a ONEB0FFE6AH

02070ef08 BR$207AH

02072e46b ONEB0FFE6BH

02074ef04 BR$207AH

02076fcf7fc00 CALL!!0FCF7H

0207ac0 POP AX

0207bbefc MOVW0FFFFCH,AX

0207dc6 POP HL

0207ec2 POP BC

0207fc0 POP AX

This looks like it is fired periodically. A number of counters are used so that portions of the subroutine are only run now and then.

There are a lot of calls, and if we look to them we can clearly identify function:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

// Suspect from IO this is output to 7 seg

12a13d45d CMP00FFE5DH

12a15f1 CLRBA

12a1661f8SKNZ

12a18e1 ONEBA

12a199d5dMOV0FFE5DH,A

12a1bd45d CMP00FFE5DH

12a1ddd24 BZ$12A43H

12a1f8f46f6MOVA,!0F646H

12a22d448 CMP00FFE48H

12a24dd0a BZ$12A30H

12a2636b4f6MOVW HL,#0F6B4H

12a2931d50eBF[HL].5H,$12A3AH

12a2c51ffMOVA,#0FFH

12a2eef0a BR$12A3AH

12a30d446 CMP00FFE46H

12a32dd06 BZ$12A3AH

12a3436b4f6MOVW HL,#0F6B4H

12a3731f3f2BT[HL].7H,$12A2CH

12a3a712305CLR1 P5.2H// These are the common cathodes

12a3d713205SET1 P5.3H

12a409d06MOV P6,A// P6 is the 7SEG

12a42d7 RET

12a438f47f6MOVA,!0F647H

12a46d449 CMP00FFE49H

12a48dd0a BZ$12A54H

12a4a36b4f6MOVW HL,#0F6B4H

12a4d31d50eBF[HL].5H,$12A5EH

12a5051ffMOVA,#0FFH

12a52ef0a BR$12A5EH

12a54d447 CMP00FFE47H

12a56dd06 BZ$12A5EH

12a5836b4f6MOVW HL,#0F6B4H

12a5b31f3f2BT[HL].7H,$12A50H

12a5e712205SET1 P5.2H// common cathodes flip

12a61713305CLR1 P5.3H

12a649d06MOV P6,A

12a66d7 RET

From the IO, we can see this is likely to be updating the 7 segment LED displays.

The method used – of setting one common cathode, then the segments for that half, then the other common cathode, then the segments for that half – means that this needs to be called relatively frequently otherwise flicker will be detected by the eye.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

// Button detection and debounce?

132aa31220217BT P2.2H,$132C5H// Button A

132ae4029e0ffCMP!0E029H,#0FFH

132b2dd24 BZ$132D8H

132b4a029e0 INC!0E029H

132b74029e007CMP!0E029H,#7H

132bbdf1b BNZ$132D8H

132bdcf29e0ff MOV!0E029H,#0FFH

132c1e445 ONEB0FFE45H

132c3ef13 BR$132D8H

132c5d529e0 CMP0!0E029H

132c8dd0e BZ$132D8H

132cab029e0 DEC!0E029H

132cd4029e0f8CMP!0E029H,#0F8H

132d1df05 BNZ$132D8H

132d3f529e0 CLRB!0E029H

132d6f445 CLRB0FFE45H

132d831320216BT P2.3H,$132F2H// Button B

132dc402ae0ffCMP!0E02AH,#0FFH

132e0dd23 BZ$13305H

132e2a02ae0 INC!0E02AH

132e5402ae007CMP!0E02AH,#7H

132e9df1a BNZ$13305H

132ebcf2ae0ff MOV!0E02AH,#0FFH

132efe444 ONEB0FFE44H

132f1d7 RET

132f2d52ae0 CMP0!0E02AH

132f5dd0e BZ$13305H

132f7b02ae0 DEC!0E02AH

132fa402ae0f8CMP!0E02AH,#0F8H

132fedf05 BNZ$13305H

13300f52ae0 CLRB!0E02AH

13303f444 CLRB0FFE44H

13305d7 RET

Again, from the IO, we can see that the buttons are being polled. There’s also some counters changing – probably some debounce.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

// Analog something or other

0ffcbf1 CLRBA

0ffcc71042aMOV1 CY,0FFE2AH.0H

0ffcf7189MOV1A.0H,CY

0ffd170MOVX,A

0ffd2f1 CLRBA

0ffd3710ce3MOV1 CY,ADIF

0ffd661dcROLCA,1

0ffd86158ANDA,X

0ffdadd23 BZ$0FFFFH

0ffdc710be3CLR1 ADIF

0ffdf4031ff07CMP!ADS,#7H

0ffe38d1fMOVA,ADCRH

0ffe5df0b BNZ$0FFF2H

0ffe79f0af6MOV!0F60AH,A

0ffea717b30CLR1 ADCS

0ffedce3106 MOV ADS,#6H

0fff0ef09 BR$0FFFBH

0fff29f0bf6MOV!0F60BH,A

0fff5717b30CLR1 ADCS

0fff8ce3107 MOV ADS,#7H

0fffb00NOP

0fffc717a30SET1 ADCS

0ffffd7 RET

This does something with one of the ADC inputs. I’ve not seen anything of interest that uses analog yet, so I’ll not look into this more currently. It could be the input voltage (the boare can alarm on this) or PSTN line voltage.

There aren’t many other clearly idenfiable subroutines, but these few clearly identifiable ones give me confidence that this interrupt handler is most handling periodic IO.

This program structure of calling time-sensitive IO using a timer interrupt is fairly common in embedded systems. It means that IO is serviced regularly, allowing more time consuming (or non deterministic time) processing to happen outside of the interrupt in the main code. It means there are a lot of buffers and global variables to pass data back and forth that we can look at and play with.

From a security perspective, it can also produce problems. If we can stall something in the timer interrupt – by buffer overflow, bad input or so on – it can be possile to lock up a device. I’d hope that the board used a watchdog timer to recover from this though.

A few posts ago, we managed to disassemble the firmware from the CSL Dualcom site.

The entire listing is available here as a zip. There is a lot of blank space in the file which needs to be trimmed down, but for reference this file will be left as-is.

I have also put the code on github. It’s not ideal as you can’t use the web interface to show the code/diffs, but it is a good way of recording history as mistakes will be made.

The process of turning diassembly into something useful isn’t easy. I find the most useful things are to find very commonly called subroutines first, and work out what they do. If they aren’t obvious, skip them.

The raw listing doesn’t show us the frequency with which subroutines are called. Python, to the rescue again. We trim out the fluff from the file. 0x1000-0x2000 is the string table, which the disassmebler doesn’t know about and tries to turn into code. The processor has a mirrored address structure so everything in the range 0x00000. Everything above 0x1FFFF isn’t the code – it’s special function registers and a mirror area.

First thing to be aware of is that disassembly is not an exact science. Sometimes you will see an address CALLed but you can’t find it. This probably means that the disassembly is misaligned in that area – look a couple of adresses above and below. This is not the case here.

We can see immediately above 0xE1B2 there is a POP and RETB, the end of a subroutine.

To work out what a sub does, it helps to know what parameters are passed to it and how. If we look through for all the CALLs to 0xE1B2, we get an idea of what is going on:

1

2

3

03d31530dMOVB,#0DH

03d33e1 ONEBA

03d34fcb2e100 CALL!!0E1B2H

B is always set to a value over quite a wide range. It’s probably a number or a ASCII character.

A is set to either 0, 1, 2 or 3. This is likely some kind of option or enumeration.

Going back to the subroutine, we can see how this could work:

1

2

3

4

5

6

7

8

9

10

11

12

13

0e1b24c01CMPA,#1H

0e1b4df05 BNZ$0E1BBH

0e1b663MOVA,B

0e1b7ec01e100 BR!!0E101H// If A = 1, branch to 0xE101

0e1bb4c02CMPA,#2H

0e1bddf05 BNZ$0E1C4H

0e1bf63MOVA,B

0e1c0ec47e100 BR!!0E147H// If A = 2, branch to 0xE147

0e1c44c03CMPA,#3H

0e1c663MOVA,B

0e1c761f8SKNZ

0e1c9ec6ce100 BR!!0E16CH// If A = 3, branch to 0xE16C

0e1cdecdfe000 BR!!0E0DFH// If A = 0, branch to 0xE0DF

So we are branching to other addresses based on the parameter in A.

There’s one thing to note about this function. There is no immediate RET instruction there. These have to be dealt with in the code that is branched to.

Let’s look at 0xE101.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

0e10177MOVH,A

0e1028efaMOVA,PSW

0e1049803MOV[SP+3H],A

0e10667MOVA,H

0e107717bfaDI

0e10ac3 PUSH BC

0e10bdbb6e0 MOVW BC,!0E0B6H

0e10e48b8e4MOV0E4B8H[BC],A

0e111a2b6e0 INCW!0E0B6H

0e114afb6e0 MOVW AX,!0E0B6H

0e117440a04CMPW AX,#40AH

0e11adc04 BC$0E120H

0e11cf6 CLRW AX

0e11dbfb6e0 MOVW!0E0B6H,AX

0e1208f0401MOVA,!SSR02L

0e12331631eBTA.6H,$0E144H

0e126362201MOVW HL,#122H

0e12971a2SET1[HL].2H

0e12b71b2SET1[HL].3H

0e12ddbb4e0 MOVW BC,!0E0B4H

0e13049b8e4MOVA,0E4B8H[BC]

0e1339e44MOV SIO10,A

0e135a2b4e0 INCW!0E0B4H

0e138afb4e0 MOVW AX,!0E0B4H

0e13b440a04CMPW AX,#40AH

0e13edc04 BC$0E144H

0e140f6 CLRW AX

0e141bfb4e0 MOVW!0E0B4H,AX

0e144c2 POP BC

0e14561ecRETB

It’s pretty long and complex. But there is one really key piece of info in there – the special function register SSR02L. Looking to the 78K0R data sheet, this is “Serial status register 02”. It’s pretty likely this function concerns serial. It has a return at the end as well.

If we look 0xE16C, this has reference to SSR12L. Another serial port.

It’s quite likely that this function concerns either reading or writing to the various serial ports on the board. I’ve not looked at it in enough depth to know exactly what it is doing, so we’ll do the following:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

// B has char

// A has 0,1,2,3 - probably different serial ports

// Return is in the branches

:sub_Serial_UnknownA_e1b3

0e1b24c01CMPA,#1H

0e1b4df05 BNZ$0E1BBH

0e1b663MOVA,B

0e1b7ec01e100 BR!!0E101H// A = 1

0e1bb4c02CMPA,#2H

0e1bddf05 BNZ$0E1C4H

0e1bf63MOVA,B

0e1c0ec47e100 BR!!0E147H// A = 2

0e1c44c03CMPA,#3H

0e1c663MOVA,B

0e1c761f8SKNZ

0e1c9ec6ce100 BR!!0E16CH// A = 3

0e1cdecdfe000 BR!!0E0DFH// A = 0

What have I done here?

Called the sub :sub_Serial_UnknownA_e1b3. The : denotes that this is the actual sub. It is something to do with serial – the first unknown sub to do with serial. I have put the address on the end just to keep track of where it is.

Search and replace on !!0E1B2H with this new name. “sub_Serial_UnknownA_e1b3” now shows instead of the raw address – when I see it called I know it is something to do with serial.

Put some brief notes above the sub so I know what it is doing.

Indented branches so function is a little clearer

I’m now going to do similar for the other high-frequency subs. Again, I am building up a broad picture, not going into extreme depth at this stage.

The ICCID is written on the outside of the Dualcom GPRS, stored in the EEPROM, read in from the GRPS modem, and read in from EEPROM immediately before a long, random looking, string is sent to a remote server. It seems quite important.

The Dualcom board also frequently checks for received SMS.

It might be worth taking a look at the SIM to see what is on it.

From previous projects, I have an Omnikey Cardman 5321 card reader. This reads both RFID cards and smart cards. We can put the SIM card in a carrier and read it with this device.

SimSpy II is a free utility which can read most data from SIM cards inclouding ICCID, IMSI, Kc (which can be used to decrypt communications), SMS messages and more.

Unfortunately, nothing too interesting comes up. The card never seems to have stored any SMS. There’s no numbers in the phone book. We might end up coming back to this at some point.

We’ve now got the code disassembled. The disassembler has no concept of what is connected to the microcontroller though, so we need to work out which ports/pins/peripherals are used by which parts of the board. What is P11.1? What about P7? These are all I/O, but meaningless without looking at the physisal board.

The best way of doing this is using a continuity tester and buzzing the board out. It’s not worth exhaustively mapping out the PCB at this stage – just the interesting bits. There might even be some mistakes.

When doing this, I find two tools are essential:

A meter with a quick continuity beep. Some have a lag. I’ve not got time for that. I use my Amprobe AM-140-A for this – it’s very quick, if a bit scratchy sounding.

Pop one end on the peripheral and just brush the other along the sides of the microcontroller. Not too hard or you risk dragging metal between the pins. It makes it very quick to find where things are going.

Watch out for transistors and resistors in the way though e.g. the inputs from the alarm are likely transistor buffered, and some of the peripherals might have resistors to divide voltage.

I find reverse engineering is about building up a broad picture instead of working in-depth on any one aspect of the system. Dip into one bit, check what you are seeing is reliable and makes sense, dip into another area to get more detail, repeat.

We’ve done this with the logic trace – seen the long string sent, looked at the EEPROM access, checked what this in the .prm file, and seen that it is the ICCID. Now I would like to look at the firmware on the device.

CSL Dualcom have v353 hex file available for download on their site. The board I am looking at uses v202. That’s a big difference.
I can see a few paths here:

Get a v202 (or anything nearer to v202 than v353) hex file downloaded. A quick Google doesn’t help here.

Upgrade the board I have to v353. This would require the EEPROM to be updated, possibly other changes. I don’t want to break this board.

Recover the v202 firmware from the board I have. There is a programming header – it could be possible to get the code off. But it may not be possible.

Live with the difference and hope that there is enough consistency between the two to be helpful.

I’m going to run with 4. It’s the lowest effort, and I think it will work. The EEPROM structure between some of the different board seems identical – this is backed up by there only being a single Windows programming tool for the board, regardless of firmware version. In my experience, smaller embedded system firmware is quite consistent as new functionality is added, even if the toolchain changes (this really doesn’t hold true when you move up to anything bigger running Linux).

What can we do with the firmware? Well, we need to disassemble it. What does that actually mean? It means changing the raw machine code back into human-readable assembly language i.e. F7 becomes CLRW BC (clear register BC). This probably doesn’t meet everyone’s idea of human readable, but it is a lot better than machine code.

Some microcontrollers (like the ATmega series) have easy to understand and even read machine code. 90% of instructions are a fixed length (16bits). The number of instructions are limited and there are only limited addressing modes. With some practice you can make sense of machine code in text editor.

The 78K0R is not like this.

All of the enclosed red cells are MOV instructions. That’s a lot of them. There are 4 of these maps, with a total of 1024 cells. ~950 of them are populated.

There are several addressing modes and the instruction length varies from 8bits to 32bits. This makes the machine code incredibly hard to read.

We need an automated disassembler. Google isn’t much help here – these microcontrollers aren’t as popular as x86, ARM, AVR, or PIC .

There are two toolchains widely available for these processors. Renesas Cubesuite and IAR Embedded Workbench. There is a chance that one of these has either a disassembler or a simulator that allows a hex file to be loaded.

After a lot of messing around, it appears that Renesas Cubesuite can load the hex, disassemble it, and also simulate it.

Last post, we looked at the comms between the board and the GPRS modem. There was a long, interesting, string send to a remote server:

1

LjS1WQjg8FHqR1a4P4DVsjO8eUITXY6ifHPlaFhkZ2SJ

When we look out to the rest of the logic trace, we can see that the EEPROM is accessed exactly as this begins:

From this view, it might look like the EEPROM access is too late for it to be used to generate that long string. However, in microcontroller terms, there is ~0.3ms between the end of the EEPROM access and the start of the first character on serial (I suspect the ‘1’ is a start character). I’ve not checked the crystal speed, but it’s between 2MHz and 20MHz. Even at 2MHz, that’s 600 instructions – plenty of time to act on the EEPROM data.

We now need to zoom in on the EEPROM data and see what is happening:

The trace is maybe a little confusing here. The green bordered binary is the DI line – the microcontroller to the memory. The yellow bordered binary is the DO line – the memory to the microcontroller. The Saleae Logic software has no decoder to deal with Microwire, so we need to use the SPI decoder set with a bit-width to deal with both the receive and transmit sides.

According to the data sheet for the EEPROM, this should be 29 clock cycles. For whatever reason there is an additional clock cycle here though – the very short transition in the middle of the trace. So we set the SPI decoder to 30bits.

The first 3bits of the green bordered binary are 0b110 – a read command. The next 10bits are the address – 0b00 1001 1000 – i.e. 0x098. After this point, we can ignore the green bordered binary.

The last 16bits of the yellow bordered binary are the value from memory – 0x4489.

We should be able to find this in the .prm file. 0x098 is 152. The prm file has a byte per row, and 2 bytes on the first row, so we should need to go to row 304 of the file – and there we go – 89, 44. Perfect.

If we continue going through the trace, we read the following addresses:

1

2

3

4

5

6

7

8

9

10

0x098

0x098

0x099

0x099

0x09A

0x09A

0x09B

0x09B

0x09C

0x09C

Strangely each of the addresses is read twice. Why? Not sure at this time.

What data do we get back?

1

89441000300637117619

This is the ICCID – the unique ID assigned to the SIM card in the GPRS modem.

The board is reset and some basic settings are sent (don’t echo commands, use DTR to close connection, turn on numeric errors).

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.

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.

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.

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.

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?

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

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

DC4

HS87

r (immediately after response above)

LjS1WQjg8FHqR1a4P4DVsjO8eUITXY6ifHPlaFhkZ2SJ

EE1404,0122,3343,’6’

‘3’

OK

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.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.