cybergibbons

For Technistore, on average you need just one quote/reset code pair to derive the seed code. About 0.25% of code pairs lead to two valid seeds, and less than 0.01% generate more than that. So after a single reset, you have the seed for your panel, and it seems quite likely the seed for all alarms on the same ARC (correct me if wrong, there are quite a lot of references to the seed not varying on a per-customer basis). Like I say, the key length is so short that you can normally recover it with a single quote/reset code pair. No need to spy on the installer. So what if it isn't genuine? The point is that this mechanism is touted as secure ("a military strength data encryption algorithm") and it isn't. There isn't a need for it to be insecure, this is just bad code. Reverse engineering for the purposes of writing your own code for interoperability is specifically protected in law in the EU.

There's money in reverse engineering, trust me.

Which one is it then?

You'd still need a lot of skill from anything I had posted to be able to defeat the anti-codes. On one hand I am being told that these issues I'm pointing out aren't real vulnerabilities, on the other hand I'm being told that they shouldn't be published?

Changed to reset, sorry.

I've just updated the blog with my findings from the reverse engineering of Technistore, if anyone is interested.

The key would need to be longer than the pin for it to be difficult. With it being so short, it's really not hard.

Thanks, I guess?

So I guess I need to start ripping UDL software apart now?

Technistore and one other. Not wanting to name as I can't openly source it.

It's a hard one to make better though. If you are limited to 0-9 on 5 digits, it can only be so secure, but a seed at least as long as the reset code would make it better.

It's easy to bypass that check with a debugger, and then it just seems to be a 0-255 code.

That's interesting. With no seed, the only protection is keeping the executable secret. Technistore allow you to download it from their site, oddly.

This is the thing - it is virtually impossible to secure an executable such that you can't get the algorithm out. The security has to be in the key (the secret). If the key is only 8 bits, then guessing it isn't going to be hard. Have their been many changes in anti-codes recently? Do new panels have new decoders? Which standard or body is it that dictates how anti-codes are used?

Another question about impressions of security. I'm looking at anti-codes at the moment, which seem common on monitored systems. Typically this takes a 5 digit quote code along with a secret seed, and generates a 5 digit reset code (along these lines, anyway). It turns out for the few decoders I have now looked at, the secret seed can be determined from a one or two pairs of quote/reset codes. If this seed was constant across an entire installer or manufacturer, this could present a risk. What are your thoughts on this?

It doesn't take me much longer to get from West London to the NEC than getting to Excel, such is the public transport.