Hacking My Security Alarm! (Texecom Veritas R8)

I was going to do this as a video, but in the end I didn’t think it would work so well, so instead have a wall of text!

So I brought a house, yay! With the house came a security alarm, a relatively decent looking one, full of features, the right kind of things I’d want from it, so far so good. However, I didn’t know anything about it, the access codes, engineering codes, etc.

However I’m not stupid (honestly), I have a decent level of experience with electronics and security alarms, so I wanted to take on maintenance of the unit. So It had been installed “professionally” (we’ll come to that), by an accredited company (who I wont name).

I gave them a ring to see if they would release the codes to me, or how I could get control over the alarm unit, it is mine now after all. So the paraphrased, shortened and niceties removed conversation went something like this:

• Mel: Hi, I just purchased <address> it has an alarm you installed, I’d like control over it to maintain it myself.
• Company: Oh, you can’t do that, you’ll need a maintenance contract.
• Mel: No, I’m capable of doing that myself. I’m competent and have had electrical engineering training/education. It’s all good.
• Company: No, sorry, we wont do that.
• Mel: Can I please just have the engineering code for this alarm panel?
• Company: No! We’d never hand out our engineering code.
• Mel: Ooook, I’ll pursue this via other routes. Bye.

So, their last statement hit me on two levels:

1. The unit is mine, I own it. I’m entitled to do what I want. It’s not connected to a remote alarm center, so no contractual issue, and it’s a self contained non safety system in a residence.
2. “Our engineering code”, having spent enough time in IT security this rang huge bells… this feels to me like you have one code… for all customers.

So the gloves were off. I pulled the alarm to pieces, which I hate doing, you make a lot of noise as you set the tamper detection off until you can short some wires together.

First step is that you can attempt to reset the engineering code by pressing the tamper button in the main panel 3 times in the first 10 seconds the alarm is running… unless the installer has disabled it.

Guess what… they had. It did reset the user code, so I could at least now silence the tamper warning.

So the second thing to do was look at the board for weaknesses.

Processor first, uggh, 64 pin TQFP, not easy to play with, but after moving the assumed version sticker, I could see it was a PIC18F66J11-I/PT. Oooooh PIC’s, I know these, and that one doesn’t have any on board EEPROM for data.

The chip slightly to the right of the MCU is also familiar, 24LC32A, an I2C EEPROM with 4Kb of storage. There are no other storage chips on the board, the codes have to be stored in there.

In order fiddle I was either going to have to solder onto things (uggh), or get a debugging clip. So eBay and two days later.

My initial plan of attack was to use a Logic Sniffer to monitor the I2C commands as the MCU read and wrote data to the EEPROM. However I hit many road blocks due to the short capture time of the Logic Sniffer.

So a new plan was needed, what about just reading the EEPROM. It turns out that the PicKit 2 has the ability to read this kind of EEPROM over I2C. A few minutes later and, et volia.

The dump of the first 16 bytes looked like:

FF FF FF FF FF FF FF FF FF 44 23 71 91 74 F6 FF 27

So the code could be stored in a few ways:

• Binary Coded Decimal (Most Likely)
• Single Values (Unlikely)
• ASCII (Really Unlikely)

So bytes 9-14 (base 0) contained interesting values, and certainly some of the same numbers the user pin had, which was 4321. So the numbers were there, but a bit scrambled. So I changed the user code to 0000.

FF FF FF FF FF FF FF FF FF 04 00 70 91 74 F6 FF 2C

So we can see the high nibble of byte 9 changed, all of byte 10 and the low nibble of byte 11. So we could now see the code was made of:

• Byte 9 - High Nibble
• Byte 10 - Low Nibble
• Byte 10 - High Nibble
• Byte 11 - Low Nibble

So what about the other numbers, we could at least discount the nibbles we had, and anything outside 0-9. So that left us with:

__ __ __ __ __ __ __ __ __ _4 __ 7_ 91 74 _6 __ 2_

So I decided to focus on 91 74, once I had realised that byte 10 was read in opposite order I tried the code 1947. That looks like a year, uh oh… it worked.

I wondered, so I did some research, I looked at their Companies House officers page.

Oh, really? For fucks sake. It’s one of their directors year of birth. If my hacking route had failed, I’d probably have tried that sooner or later.

I have to assume they use the same engineering code everywhere, it’s a piece of information about the company, these people don’t get to call themselves security consultants.

However, I do now have complete control over the alarm. This was oddly fun, and I was happy to win.

So on version 3.22 of the Texecom Veritas R8 panel, the engineer codes are stored at bytes 12-13 with nibbles reversed in BCD. Easily read with an I2C analyser.

I’m not particularly worried about the ease of getting the engineering or user codes out of the device. Perhaps they should have scrambled the code, but it seems pointless. To get this far you have to have physical access to the device and either have set off the alarm or have defeated the anti tampers. At which point you can just get into the box and short the alarm outputs for external sounders to stay off.

I’m happy enough to put this device back into service in my house.

I need to find out how accredited these installers are and log an official complaint, the engineering code should have been a random number unique to my panel. Maybe they shouldn’t have given it me over the phone, but perhaps I could have paid them some money and they could have sent it.

Ahh well, off to put it back into service. Next stop, reverse engineer the protocol between the control board and panels to make an IP interface!