Category Archives: Security

We need an antidote to the anti-code

Posted on by

In the last post, I briefly went over the process of reverse engineering the algorithm behind an anti-code generator for an alarm system.

It turned out that the algorithm was very simple indeed. For a given 5-digit numeric quote code, we can derive a 5-digit reset code using a “secret” 8-bit (256 possibilities) version number as a key. This has a lot in common with a keyed hash function or a message authentication code.

There are some pretty serious security implications with this mechanism.

5 digit numeric codes are never going to be strong

Even if I had to enter a pin at random, a 5-digit numeric code only has 100,000 options – I have a 1/100,000 chance of getting it right.

If we made this into a 5-digit hexadecimal code, we would now have a 1/1,048,576 chance – a factor of over 10 times less likely.

Up this to a 6-digit alphanumeric code, and it is now 1/2,176,782,336 – a factor of over 20,000 times less likely we could guess the code.

It doesn’t take many alterations to the limits on codes to make them much more secure.

For this reason it surprises me that alarms are still using 4-digit pins, but most internet forums insist on 8-character passwords with alphanumeric characters and punctuation.

The algorithm isn’t going to stay secret

There is no way to reliably protect a computer application from reverse engineering. If you can run it, at all, it is highly likely the operation can be observed and reversed. Relying on the secrecy of an algorithm or a key hidden within the software is not going to afford any level of security.

Once we know the algorithm, the odds massively improve for an attacker

The algorithm takes a version number from 0-255. For a given quote code, I can try each version number, giving me a list of up to 256 potentially valid reset codes (sometimes, two version numbers will generate the same reset code).

If I enter a code from this list, I now have a 1/256 chance of getting it right. Not great compared to 1/100,000 for a purely random guess.

This is entirely due to the short version number used.

Given a quote/reset code, most of the time we can infer the version

It quickly became apparent that for most quote/reset pairs, there was only a single version number than could produce this pair. I’m awful at probability and decision maths, so I thought running a simulation would be better.

I like running simulations – generally when the number of simulations becomes large enough, the results tend towards the correct value. So I tried the following:

1. Generate a genuine quote/reset pair using a random quote.

2. Use a brute force method to see which version numbers can produce this pair

3. Record if more than one version number can produce this quote/reset pair.

I started doing this exhaustively. This would take a long time though… someone on the Crypto stack exchange answered my question with a neater, random simulation.

Pairs

I ran this test over 20 million times. From this it turns out that 99.75% of quote/reset code pairs will directly tell me the version number. Most of the remaining 0.25% require yield two version numbers. A tiny number (<0.001%) yield more than four version numbers. You are almost certain to know the version number after two quote/reset pairs as a result.

What does this mean in the real world?

The version number is treated as the secret, and I am informed that this secret is often constant across an entire alarm company. All ADT alarms or all Modern Security Systems alarms may use the same version number to generate reset codes.

This means I could get hold of any quote/reset pair, infer the version number, and then use that later to generate my own anti-codes for any ADT alarm. I could get hold of these quote/reset pairs by going to an accomplice’s house with a ADT alarm system, or by eavesdropping on communications.

With that anti-code I could either reset a system presenting a quote code, or impersonate an alarm receiving centre (there are other speech based challenge-response requirements here to prove the caller is genuine, which are easily gamed I would imagine).

Conclusion

A 5-digit reset code using an 8-bit key is never going to be secure.

When computer passwords are 8 characters and 128-bit keys are the norm, this anti-code mechanism seems woefully inadequate.

Reversing an anti-code

Posted on by

A contact in the alarm industry recently asked if I could take a look at a quick reverse engineering job. I’m trying to gain some credibility with these guys, so I naturally accepted the challenge.

Many alarms have the concept of an “anti-code”. Your alarm will go off and you will find it saying something like this on the display:

CALL ARC

QUOTE 12345

The idea is then that you call the alarm receiving centre, quote 12345, they will input this into a PC application, get a reset code back, tell the customer, and then they can use this to reset the alarm. This means that you need to communicate with the alarm receiving centre to reset the alarm.

Alarm manufacturers provide their own applications to generate these codes. This particular manufacturer provides a 16-bit MS-DOS command line executable, which will refuse to run on modern PCs. This is a pain – it’s not easy to run (you need to use a DOS emulator like DOS-BOX) and it doesn’t allow for automation (it would be convenient to call a DLL from a web-based system, for example).

So I was asked if I could work out the algorithm for generating the unlock codes. x86 reverse engineering is not my forté, especially older stuff, but I thought i would have a quick go at it.

Turns out it was easier than expected! I find documenting reverse engineering incredibly difficult in a blog format, so I’ll just cover some of the key points.

Step 1: Observe the program

First things first, let’s get the program up and running. DOS-BOX is perfect for this kind of thing.

The program takes a 5 digit input and produces a 5 digit output. There is also a version number which can be input which varies from 0-255.

I spent a while playing around with the inputs. Sometimes things like this are so basic you can infer the operation (say, if it is XORing with a fixed key, flipping the order of some bits or similar). It didn’t look trivial, but it was plain to see that there were only two inputs – the input code and version. There was no concept of time or a sequence counter.

At this stage, I’m thinking it might be easiest to just create a lookup for every single pin and version. It would only be 2,560,000 entries (10,000 * 256). That’s a bit boring though, and I don’t have any idea how to simulate user input with DOS-BOX.

Step 2: Disassemble the program

To disassemble a program is to take the machine code and transform it into assembly language, which is marginally more readable.

There are some very powerful disassemblers out there these days – the most famous being IDA. The free version is a bit dated and limited, but it allowed me to quickly locate a few things.

An area of code that listens out for Q (quit) and V (version), along with limiting input characters from 0-9. Hex values in the normal ASCII range along with getch() calls are a giveaway.

Keyboard input
Another area of code appears to have two nested loops that go from 0-4. That would really strongly indicate that it is looping through the digits of the code.

Other areas of code add and subtract 0x30 from keyboard values – this is nearly always converting ASCII text numbers to integers (0x30 is 0, 0x31 is 1 etc. so 0x34 – 0x30 = 4)

Loops

A block of data, 256 items long from 0-9. Links in with the maximum value of the “version” above. Might just be an offset for indexing this data?

Data!
IDA’s real power is displaying the structure of the code – this can be a lot more telling than what the code does, especially for initial investigations.

Code structure
It’s still assembly language though, and I’m lazy…

Step 3: Decompile the program

Decompiling is converting machine code into a higher level language like C. It can’t recover things like variable names and data structures, but it does tend to give helpful results.

I used the free decompiler dcc to look at this program. I think because they are both quite old, and because dcc has signatures for the specific compiler used, it actually worked really well.

One procedure stood out – proc2, specifically this area of code:
DCC outputIt’s a bit meaningless at the moment, but it looks like it is two nested while loops, moving through some kind of data structure, summing the results and storing them. This is almost certainly the algorithm to generate the reset code.

Now, again, I could work through this all and find out what all the auto named variables are (i.e. change loc4 to “i” and loc5 to “ptrVector”. Or I could step through the code in a debugger and not have to bother…

Step 4: Run the code in a debugger

A debugger allows you to interrupt execution of code and step through the instructions being carried out. It’s generally of more use when you have the source code, but it is still a helpful tool. DOS-BOX can be run in debug mode and a text file generated containing the sequence of assembly instructions along with the current registers and what is being written and read from them. It’s heavy going, but combined with IDA and the output from DCC, it’s actually quite easy to work out what is going on!

Step 5: Write code to emulate the behaviour

Shortly after, I had an idea how the algorithm worked. Rather than work it through by hand, I knocked up a quick Python program to emulate the behaviour.The first cut didn’t quite work, but a few debug statements and a couple of tweaks later, and I was mirroring the operation of the original program.

Overall, it was only a few hours work, and I’m not really up on x86 at all.

I’m not releasing the algorithm or the software, as it could be perceived as a threat. In the next post, I am going to discuss some of my security concerns around the idea of an anti-code and this specific implementation.

Keep rolling, rolling, rolling

Posted on by

In the last post about technologies used in alarms, I discussed the use of spread spectrum. Another really common keyword seen on marketing material is “rolling code”. What is it, why is it used, and what problems are there with it?

Why?

A wireless alarm system might send a signal from a keyfob to the panel to say “disarm the system”. If the content of this packet does not change in any way from time to time, we could simply record this packet and replay it at a later time.

This is commonly called a replay attack. There are alarm systems available that are vulnerable to this attack – the older Yale Wireless Alarm systems (434MHz ones) and Friedland SL series are examples. There are “Universal cloning remotes” on eBay for less than £5 that will clone any alarm using 434MHz OOK signalling. You can also use an Arduino and cheap receiver to listen out for signals and store them for later replay.

It is desirable to have a means of stopping these replay attacks from happening.

There is nothing in the EN50131-5-3 specification that means a grade 2 alarm needs any protection against these attacks. Most newer alarms do however have some protection.

How?

The attack is possible because the signal doesn’t ever change – it is always “disarm the system”.

To protect against a pure replay attack, we just need to add something that changes each time the signal is sent. How about the time? “disarm the system 21:22:32 26/04/2013”

This works. There is now no way for me to record a packet and use it again later.

But a really malicious attacker could work out how to take a packet recorded earlier, modify the time, and replay it.

This is where rolling code comes into play – instead of appending the time, we add a code to the packet. This code changes each time a packet is sent. The receiver and transmitter have agreed how this code will change – generally using a psuedo-random number generator.

The packet now becomes “disarm the system 204389473692”, the next time it will be “disarm the system 937459384322” and so on.

The sequence of this codes is essentially random to an observer, and the code is long enough that it makes guessing the next one very difficult.

Unlike spread spectrum, this sequence is generally extremely long in small systems.

Keeloq is a proprietary implementation of a rolling code protocol, often used in car keyless entry systems. The rolling code is 32-bit, which essentially means it is impossible for someone to guess the next code.

Keeloq does have weaknesses. The major one is that it is possible to recover the key used to seed the random number generator. Once you have this, it is far easier to guess the next code. It’s still very challenging though.

What issues are there with rolling code?

Again, the devil is in the detail. Rolling code is a sound principal – but it must be implemented correctly.

Predictable codes

The whole thing falls over if someone can guess the sequence of codes you are using. There are a number of ways that this can happen.

If your code is short (say, 8bits), the an attacker has a 1/256 chance of getting the next code correct if he chooses randomly. If your code is long (say, 32 bits), then it is 1/4294967296. Whatever method you are using to guess the codes, you can clearly see that the longer the code, the harder it will be.

A good pseudo-random number generator (PRNG) can be seeded – you give it a key which determines how it will hop. It shouldn’t matter what the algorithm is or if the attacker knows the algorithm, as long as they don’t know the seed, they shouldn’t be able to predict the sequence. Unfortunately, many products either used a fixed seed across all products (this makes protocol design, especially with a one-way radio, much easier) or the algorithm is bad.

How can the algorithm be bad? Say we have a PRNG with this output when seeded with “1”:

7, 3, 4, 1, 3, 6, 1, 3, 2

If I were to seed it with “2”, the output should be completely different:

8, 3, 3, 2, 7, 1, 5, 3, 1

But some systems simply use the seed to skip some of the output i.e. with a seed of “2”:

3, 4, 1, 3, 6, 1, 3, 2, 8

Notice this is just the first sequence shifted along one digit!

If I know the entire sequence, then all I need to do is gather a few packets and I can work out where we are in the sequence. The number of packets I need varies, but with a poor PRNG or short code, it’s not very many!

Worse still, some “rolling code” systems use a code like:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

Whilst this might protect against casual replay attacks, it is not hard for an attacker to guess the next number.

Limitations with one-way radios

If your keyfob can transmit but not receive, there is a small problem. Each time it transmits, the code rolls forward. There is no guarantee that the receiver will hear the transmission.

This means that the transmitter’s code can be further ahead in the sequence than the receiver. This needs to be taken account of – what happens if you are idly pressing the disarm button in your pocket whilst waiting for the bus?

Most systems deal with this by checking for a valid code over a “window” of acceptable values. This could, say, be the next 256 codes. This has an interesting effect on guessing. If I have a 16 bit code, there are 65,536 possibilities. If the window was only 1 long, I would have a 1/65,536 chance of randomly guessing the code. If the window is 256 long, we reduce this by a factor of 256 – to 1/256. That’s a big difference.

Message substitution

A very simple rolling code implementation just appends the pseudo-random code onto the message i.e. “disarm the system 878463098273”

There is no link between the message (“disarm the system”) and the code (“878463098273”).

This means we can change the message and use the same code, providing that the receiver hasn’t received the code.

How could this be done? I’ll give one possible attack.

When you press “arm the system” on the keyfob, it will actually send more than one packet, to ensure that the receiver gets the message. We have something like:

arm the system 736474747363

arm the system 093219457437

arm the system 384838738383

arm the system 732878476655

If I am in the position to jam the receiver, but still receive the genuine packet, I can do the following:

1. Record all 4 packets.

2. Immediately replay the first two to arm the alarm so the user does not see an issue:

arm the system 736474747363

arm the system 093219457437

3. Hold onto the last two packets.

4. Change the messages on the second two packets to:

disarm the system 384838738383

disarm the system 732878476655

And bang, we have disarmed the system.

Replay attacks still work

As long as the packet never reaches the receiver, we can still grab a transmission from a keyfob and use it later. This means someone could press the disarm button on your keyfob whilst you are away from the house (say, when you pass your keys to the checkout assistant to scan your loyalty card), and then replay it later.

Conclusion

Rolling code, again, is a good idea, and if implemented well, can protect against a lot of attacks. Many systems do not implement it well though – the above vulnerabilities can be found in real world alarm systems.

A much more robust solution is to use timestamps in the messages and then use encryption and a message authentication code.

If anyone is interested, Atmel have a really good app note on implementing a secure algorithm with one-way radios.

The ups and downs and ins and outs of spread spectrum

Posted on by

It’s becoming increasingly common to see the terms “spread spectrum“, “frequency hopping” or “FHSS” on the spec speets for wireless alarm systems.

The question is, what does it mean and how does it improve a wireless alarm system?

We might as well start with the wikipedia definition:

Frequency-hopping spread spectrum (FHSS) is a method of transmitting radio signals by rapidly switching a carrier among many frequency channels, using a pseudorandom sequence known to both transmitter and receiver.

A diagram is a clear way of showing this:

Time vs channel

Time vs channel

This is a really basic example with only 5 channels. The channel changes for each time slot, and the hopping pattern is a rather predictable 4, 1, 5, 2 3. Both the transmitter and receiver know this hopping pattern and hop at the same interval.

Practical systems tend to use large numbers of channels (50 upwards) and hop frequently (hundreds of times a second).

This technique is used by Bluetooth and other technologies.

There is another form of spread spectrum called Direct Sequence Spread Spectrum, where the hops are faster than the data rate. This is rarely used in small embedded systems, but is used in WiFi.

What are the advantages of FHSS?

Resistance to jamming and interference

The most obvious advantage is that narrowband interference or jamming (jamming is really just intentional interference) will only cause a problem for one of the channels, so a signal can still make it through.

Jamming, I hope you like jamming too

Jamming, I hope you like jamming too

In the image above, there is interference on channel 2. None of the signal on channel 2 will be received, but all of the other channels are still fine. Even if you continue to use channel 2, 80% of packets will make it through.

Resistance to eavesdropping

At least at a superficial level, you could conceive that an eavesdropper would have to know the hopping pattern to be able to listen it to a FHSS signal. For this reason, some think the FHSS provides added security.

Transmitting with higher power

This is not intrinsic to the technique of FHSS, it is more related to regulatory requirements. A big problem with most ISM band radio systems is contention for channel access. The most common technique to avoid problems (without using spread spectrum) is to limit the duty cycle to 1% or below. This gives other devices a chance to use the channel.

FHSS avoids this issue as you are only using one of a number of channels in a group. Multiple devices can be using the same group of channels and it is unlikely they will want to use the same channel at the same time. Contention is less of an issue for this reason.

This is turn means that more devices can operate in a given area. The area a transmitter operates in is defined by it’s output power – a higher power can transmit further.

The lower chance of contention means that FHSS devices are allowed to transmit with a higher power, and hence tend to have longer range.

What are the problems?

It sounds like FHSS is a great idea. But, as always, the devil is in the detail.

You cannot rely on FHSS to provide protection from eavesdropping

If we take a practical example of one alarm system – this hops over 50 frequencies in the US version (which is the FCC’s minimum number) at a rate of 64 hops per second. This might sound fast, but it really isn’t.

The CC1110 RF SoC has built in support for FHSS. Using a technique whereby you pre-calibrate the frequency synthesiser, a hop time of ~75uS can easily be achieved. You can essentially turn it into a scanner – scanning all 50 frequencies as quickly as you can. This takes 3.75ms, a lot less than the dwell time of 15.625ms (1/64).

I might not be able to receive all of the packet – I’m going to miss at least some of the start of it – but I can receive some.

More to the point, I can record the hopping pattern. The design of most wireless systems means that this will never change.

The CCxxxx chips are used in a lot of alarm systems – from the low-end Friedland SL series to the high-end Texecom Ricochet. When they are used in alarm systems, they tend to be used conservatively – they need to work correctly all of the time. As a reverse engineer and hacker, I can push these chips to their limits and just hope that they work well enough to meet my goals once.

The same system mentioned above is sold in the UK but only hops over 4 frequencies. I don’t think this even meets regulatory requirements (another downside to self-certification), but it provides no protection against eavesdropping or even interference.

Predictable or simple pseudo-random hopping patterns

Both transmitter and receiver need to decide on a hopping pattern ahead of time. There are a number of techniques used to do this – you can store a predefined pattern in memory, or generate one using built in hardware or software.

A cold hard fact of pseudo-random number generation though is that the pattern will repeat at some point. This could be after 127bits or 32767bits or anything really depending on how it is implemented. Small embedded systems tend to use patterns that repeat after short periods though – PN9 (i.e. 511bits) is common.

This means it is entirely feasible to record the hopping pattern. It’s very likely this pattern will be re-used.

Some systems make it possible to look at the firmware and see the code that generates the hopping pattern.

Sequences are the same across all equipment

It’s hard to make every single device “custom”. This isn’t really a manufacturing concern – most devices are programmed at some point with a unique serial number. It’s more a protocol design issue – communicating a secret between devices ahead of time is hard work, especially on a one-way radio system. It’s also hard to work with 10 different transmitters using 10 different hopping patterns.

This means all detectors and all panels across every system made might use the same sequence. It only takes a small amount of effort for an attacker to determine this sequence and reuse it time and time again.

FHSS is complicated by other functionality

One of the advantages of FHSS is resistance to interference. As shown in the diagram above, if channel 2 is interfered with, we will only lose 20% of packets.

This is still a 20% packet loss – if other layers of the protocol aren’t designed to take account of this, it could totally cripple the system.

For this reason, many FHSS systems also employ adaptive frequency agility (AFA). If they detect a problem on a given channel, that channel will be taken out of use.

Adaptive frequency agility

Adaptive frequency agility

How could this be a problem? Well, how long do I take that channel out of use for? What happens if more than 50% of my channels are taken out of use? There needs to be some kind of mechanism to bring the channels back into use at some point.

The design of AFA algorithms is complex, and mistakes are made. It can be possible to game them into a state where they believe that most channels are unusable. A parallel to this is mesh networking routing algorithms  – you can sometimes game the system into believing there are no valid routes with only a few carefully crafted packets.

Conclusion

Whilst FHSS is a useful technique to improve interference and jamming immunity, it should never be relied on for security – that is what encryption and MAC is for.

What’s wrong with the alarm industry today?

Posted on by

Wilco Baan Hofman made a talk last week at the Hack in the Box conference, where he detailed some of his work in reverse engineering the proprietary SIA-HS protocol, which is now becoming more and more common in alarm reporting systems.

As usual, the security industry prefers secrecy over openness, so most of these alarm reporting protocols, and importantly all of their implementations are closed. Time and time again this has been proven to be a sure-fire way of building systems with gaping security holes.

He states 10 assumptions that Alphatronics, the designer of SIA-HS, made. All of these assumptions lead to fatal mistakes being made in the implementation of a secure protocol.

A lot of these assumptions are technical – I can attribute them to ignorance or incompetence.

But not assumption 5. This has to be a conscious, management level decision.

If my product is certified, it is secure

This couldn’t be any more wrong, and points to a worrying, widespread, archaic and persistent attitude problem that many alarm manufacturers have. He backs his statement up with a quote:

“Alphatronics emphasizes that the uncovered vulnerabilities do not influence
the product certification.”

Now, some quotes I have from my correspondence with three alarm manufacturers:

 “The fact remains that this is a Grade 2 security panel and meets all the security requirements for that grade.”

“We consistently strive to ensure that all our products meet the relevant standards and we generate a continual program of product testing and quality control. The product has not been designed to compete with professionally installed commercial products.”

“We have been selling wireless alarms since 1990 and code issues have never been a problem. Potential burglars would need extensive knowledge and equipment to overcome any alarm system.”

All of these are in response to the disclosure of easily exploitable vulnerabilities. The next one is in response to simply discussing vulnerabilities:

“If you have managed to reverse engineer our protocol i would be:

1. Suprised

2. Glad to see you in court”

I honestly find this attitude offensive and I can’t understand it.

Why is it a problem that alarm manufacturers only want to meet the standards and not exceed them?

  • The environment alarms are deployed in is continually changing. What seemed secure 10 years ago may now be stunningly insecure today. Standards take years to draw up, and are normally out of date by the time they are published, and are then used for long periods.
  • A standard cannot and does not cover all known angles of attack. If there is a valid and demonstrable vulnerability but it is not encompassed by the standard, that does not stop it being a vulnerability.
  • Very few alarm systems have any mechanism to update anything but the alarm panel firmware. Most panels don’t allow updates to be carried out automatically or by end users. This massively constrains the ability to patch security holes. The attitude that “it was once certified secure, it is secure now” just causes this practice to continue.
  • Most of the vulnerabilities raised with the manufacturers I would consider a direct result of bad software design and could be fixed with firmware updates. Continuing to sell these systems without altering them is lazy.
  • Electronic and software security systems differ to physical security systems. It would take me 2 hours each and every time to drill the door on a high end safe. However, if I invest a few days in analysing an alarm system and find a vulnerability, I can usually use the vulnerability in seconds time and time again. Importantly, I can package the vulnerability in a way that any idiot can use it.

Maintaining this position directly results in insecure, un-patchable alarm systems being deployed. It doesn’t look like this is going to change.

Why XOR alone is an incredibly bad “encryption” technique

Posted on by
From HITB presentation

From HITB presentation

In Wilco Bann Hoffman’s presentation at HITB, he showed some slides with screenshots from Wireshark, a packet capture utility.

Down at the bottom, you can see a hex representation of the data in the packet on the left. On the right is an ASCII representation of the same hex data. “.” means “Yeah, that hex doesn’t mean anything to me”. When you see this, it means you are looking at something that is likely binary data or encrypted text.

This is a security protocol, so we might assume it is encrypted in some manner. It can be a royal pain to work out how something is encrypted, especially with such a small amount of data. But because the designer of this protocol has made a schoolboy error, anyone with any experience will immediately see how it is encrypted and what they key is. I am not exaggerating here – I saw it in seconds and knew others would to.

Look at the hex data. What do you see? There are an awful lot of 0xB6 values there, aren’t there?

Why would that be?

A really common building block in encryption is to XOR (eXclusive OR) the data with some key material. It’s a clever and fundamental tool used in nearly every single encryption algorithm.

Let’s look at a really quick example:

11010010
10101010 ⊕
--------
01111000

We bitwise XOR the values of the data (0xD2) with the key (0xAA) to get the “encrypted” data (0x78).

To unencrypt, we just do the same thing:

01111000
10101010 ⊕
--------
11010010

Very clever, very clean, and also very easy to do quickly on most processors.

If the key is not constant, this can be an excellent way of encrypting. But if the key (0xAA) stays the same, we have a big problem.

Why? What happens when we encrypt 0x00:

00000000
10101010 ⊕
--------
10101010

The cipher text is the same as the key! Oh no. We’ve just leaked our key.

An awful lot of protocols end up with a lot of 0x00 in them. It’s a common padding value and a common string termination value. We just need to look at the packet in Wireshark, see all of those 0xB6, and we can be pretty certain that XOR is being used with a key of 0xB6.

A very simple python script

A very simple python script

And this is the case. A quick Python script later, and mostly ASCII comes out.

Now we have some plaintext

Now we have some plaintext

Even if 0x00 wasn’t used so frequently, XOR with a fixed key does nothing to increase the entropy of the data. If we used frequency analysis, we would get meaningful results. It’s also pretty easy to bruteforce a single byte key – you can even automate the detection of valid ASCII characters.

Very worrying that this was used over the open internet for security purposes.

Inside a high security electronic combination lock

Posted on by

 

ObliqueView posts an interesting series of images of the inside of a Kaba Mas X-09 electronic combination lock (link to manufacturer page and full set). These locks are expensive, but very highly regarded by many locksmiths. At the same time, many old-school locksmiths seem to distrust anything electronic. This seems to have hindered the security analysis of these locks.

I’ve not seen one of these away from a secure filing cabinet. They are very expensive, so this is a nice little insight into their workings. Some quick notes on what I can observe:

  • The top of the large (ultra?) cap has been blanked out. I can’t imagine what you would need to hide.
  • The pink/orange dots look like UV sensitive ink. This might be for post-intrusion forensics.
  • The board has a conformal coating or lacquer. I’m surprised it isn’t fully potted – it would be better for security.
  • It looks like a simple two-layer PCB.
  • Something odd is going on with the vias. There are a lot of normal small circular vias covered by green solder mask. But a lot are large square, and not covered by solder mask. They might be test points, but that is a lot of them. (edit – I asked on Electronics Stackexchange, without seeding anyone’s mind, what they were – and got test points back. I can only assume because this has to be so reliable, they are into heavy testing)
  • Looks like markings on the chips have been removed. This is token. You can identify nearly all processors and chips without markings.
  • One of U1 looks like a serial EEPROM, from one side being common and the proximity to the larger chips. It looks like the footprint is designed to take two different sized ICs.
  • PCB design is messy, not pleasing to the eye. I can’t work out if this is because it was autorouted, routed by someone inexperienced, or if it is just meant to be confusing to make probing hard.

If anyone has a broken one of these, I’d take it off your hands…

Reverse engineering a wireless burglar alarm, part 8

Posted on by

Last time we worked out that we could drive the CC1150 daughterboard using the Seeeduino Mega Arduino board easily.

The Seeeduino Mega uses a ATmega2560 microcontroller, which has a number of features which will help us do this:

  • Hardware SPI interface – this makes high speed SPI connections almost effortless. No nasty bit-banging here.
  • Pin change interrupts – this means we can quickly and efficiently respond to the clock signal coming into the microcontroller. 6.25kHz isn’t so fast that it precludes the use of a polling technique, but polling is wasteful and limits what we can do with the rest of our time.
  • Lots of memory – we don’t need to care about creating wasteful buffers. The 8KB in the 2560 is far more flexible that 2KB in the 328.

Connecting the hardware is easy – we need to use PB0 (CS), PB1 (CLK), PB2 (MOSI) and PB3 (MISO). These map through to pins 53, 52, 51 and 50. We are going to use the adjacent PL0 port (pin 49) to clock out the data to GDO0. VCC is supplied from the 3.3V supply on the Seeeduino Mega (it is switchable from 3.3 to 5V operation – a valuable addition).

It was at this time I found out that if you connect the CC1150 incorrectly it gets very hot and starts letting out the magic smoke. It also still works after this..

Now, as for the software – I’m not really sure where to begin. It’s quite hard to explain bit-by-bit. I hope it is self-explanatory, to a large extent.

The code is available on github. There isn’t really much fancy going on here – I am using some CC11xx headers from previous projects to help identify the settings registers. All this aims to do is take the 48 bit (6 bytes) of data we have sniffed from a door contact, and replay this signal. It configures the CC1150 exactly as per the sniffed traffic, and then we use a pin change interrupt to clock the data out.

Oooo 2-FSK!

Oooo 2-FSK!

Once all of this is wired up, I can immediately see that my spectrum analyser is showing bursts of 2-FSK. That must mean things are approximately correct. I used to hate working with RF – I could never tell if it was the transmitter, receiver or just idiocy that was preventing things from working. A spectrum analyser gives you reassurance that you are doing at least something right.

So now I need to see if the bell box can learn the door contact from this signal. I connect up the bellbox, press and hold learn, and… nothing. I try the door contact, and it is learnt immediately. I must be doing something wrong.

(when working with alarm sirens, you need to be careful. If you leave the siren connected, they can be loud enough to actually damage your hearing. I never trust the soft setting to turn off the siren for testing, so always disconnect it physically. This then presents another danger – siren drivers can produce large voltages when the siren is open circuit – sometimes hundreds of volts, enough to give you a fair belt.)

The trusty Saleae Logic Analyser comes out again, and I connect it up to my cloned alarm sensor. It’s apparent that the signal isn’t quite right – a few extra bits here and there. A really quick and easy debug method is to use extra IO ports – PL1 and PL2 in this case – to  observe timing and code flow. Serial is just too slow for this kind of stuff – it might help me, but normally it slows down execution enough to cause problems. ATmega chips do have on-chip debug, but it is always more trouble than it is worth – these are very simple microcontrollers!

He's learning, we're learning.

He’s learning, we’re learning.

It turns out it is a simple bug – I’d used an incorrect comparison to signify the end of a packet. The code is fixed, and I try again. This time the panel learns the remote!

So where to from here? I need to start experimenting with the data in the packet, and seeing what the panel will and won’t accept. Next time.