Blast From The Past

For kicks I downloaded Milestone Xprotect GO this morning.

My handiwork is still in there!

In the Milestone/Milestone Surveillance folder, you’ll find a file called “mask.exe”. Don’t try executing the file, just copy the file and rename the extension to .jpeg. So you get

mask.exe -> mask.jpeg

Then open the file in your favorite JPEG viewer, and behold, a wonderful image i made in 3DSMax about 10 years ago.

Mask.exe

This was used for demo-mode purposes. If you had not entered a valid license code, we’d embed this frame into the video (a costly process). To ensure that you didn’t just replace the demo image with a 1×1 pixel image, we validated a hash of the file content.

Fun times.

Advertisements

Hacked Sites

LinkedIn’s user database was leaked online a while ago, now usernames and passwords are for sale in the dark net. LinkedIn were not the first, nor the last to have their user database stolen, and published online.

Companies go to great lengths to protect their databases from outside intrusion; but what about the disgruntled employee? Your best friend had root access to the system, but when things went sour, he had already made a copy of the database (just in case), and so when he was finally let go, he decided to post the database snapshot online.

In the terrible old days, the database would contain the username and password in plaintext, so you’d see something like this:

User      | Pass
----------+------- 
Morten    | 123456

Then someone thought to encrypt the passwords, but the disgruntled employee has access to the key and the algo used, so he could just post that information online as well. A tell-tale sign of such a (horrific) implementation is that the system sends your password to your email address if you forget it, instead of the usual reset password email that you get today.

These days we do salted hashes to make it hard to determine the passwords if the database is compromised. The basic idea is that you no longer store the password, but instead store the result of a hash function. When the user provide their password, the system combines the password with another value and computes the resulting hash value. This value is then compared to the value stored in the database, if they match the user gets access. Since the user database contains the RESULT of a computation, there is “no way” to deduce the original password from the hash value stored in the database.

Here is a very simple example:

Say we only allow 4 digits as our password, and our hash is simply to add the numbers together (this is a TERRIBLE hashing function!), but this will serve as an example.

So the user has a pin of 1234, and for this user we have made a salt value of 3333.

So the user enters 1234, we then append the salt, so we get 12343333, then hash that value (1+2+3+4+3+3+3+3 = 22), so we store 22 in the database.

User      | Salt | Hash
----------+------+----- 
Morten    | 3333 | 22

Now, say someone tries to use my account, and attempted to gain access. He then enters 1111 as the PIN. The system then computes the hash (1+1+1+1+3+3+3+3 = 16). The hash computed (16) is then compared to the value in the database (22), since they don’t match, the user is denied access.

The observant reader will have realized that if I know the salt it will be simple to find a combination of PIN that will give us the desired result (22). 4321 would work and grant us access, so even if I don’t have exactly the same PIN we will get access just the same.

This is primarily because the hash function is so terrible; so you do not use idiotic hash functions, but pick some that are generally accepted as being “good”, for example MD5 is widely used. So when you use good hash functions, the likelihood of 2 PINS given the same hash is very small. This means that you have to try a lot of combinations to find a combination where function ( guess, known_salt ) == hash. But computers are happy to try a lot of combinations, and the number of combinations can be greatly reduced by using “rainbow tables”. These are tables of known, often used passwords, usually retrieved from other hacks, and while this doesn’t give us all the passwords, it usually breaks enough accounts for whatever purpose is needed. We might also want to target just one account in the DB, and try a much wider range of passwords.

Someone might argue that since I don’t have the hashing algo used I will be unable to set up my little script to run through the rainbow table, but this could have been leaked as well. Even if it wasn’t there might be known accounts in the database, where I will be able to try different hashes with a known username, password and salt.

If you are in the “same password everywhere” camp, then you are SOL. Even if the blog comes clean and discloses that they have been compromised, it is too late. Changing the password on the blog does not remove the password in the leaked database.

Breadboards and LEDs

I had forgotten the smell of an electronics store. I am not talking about Best Buy, or Radioshack, but one where you can get LEDs, resistors, wires and breadboards, where the guy behind the counter tells you that a 220 ohm resistor is suitable for the LED.

The computers I am playing with these days are very low cost (down to $5), but they have digital IOs readily available, and I must say that I am amazed the kinds of things that are available. RFID readers, 433MHz transceivers, PIR detectors, touch screens, cameras etc. And did I mention that you can play Minecraft on these things?

So today I got myself a breadboard, some LEDs and resistors, and set up my little script so that when motion is detected by a camera, the LED turns on for 5 seconds. It feels almost magical to see the little LED light up when I move in front of the cameras. Strange how this little addition somehow makes it all seem more “real”.

Most of the code for this little NVR is javascript; there is a little bit of c++ in there too, but I think I can move that to javascript in a day or so. The caveat is that this is H.264 only, but I can live with that for now.

I’m a Luddite

Google and Amazon would like to place a sort of Peeping Tom on your house. You’ll pay for it, and in return it will turn your light on (when WiFi works), play music and order crap you don’t need when you yell at it. But most likely, it will hear when you tell your wife that your sphincter has been giving you grief lately, and the next thing you know, every page will pop ads for Preparation H (now it just pops ads for skin cleansers!?!?!).

I hardly go to the movies any more, and if I do, I sure as shit wouldn’t trust the Google Peeper to book the tix for me (there are several screens, not all are good, and in Denmark we have numbered seating and so there’s a lot of things that can go wrong).

The general direction seems to be to allow you to be completely passive except for the occasional yelling at your golem, but then – the next thing Google shows is a watch with a fitness tracker. So, you get this device that listens to everything you say, and does trivial things for you, and then you put on this other device that tracks where you are, and tries to motivate you to burn off those excess calories, that you’ve accumulated from sitting on your ass all day.

Some of the tech is designed to let you connect with friends and family, but the demo then shows an automated response to a picture of a bowl spaghetti (they say it can tell the type of pasta being served, which is probably a lie). I’m sure that the system, in time, will know that you are cooking linguini and autonomously send a picture of some linguini to you wife, who’s phone will then create an automated reply “yummy”.. awesome… I feel connected already.

 

Server Side Motion Detection Redux

Good grief.

A friend of mine dropped off a HikVision camera a while ago, and I had added it to my DIY NVR. Setting up the motion detection was a breeze, and so I was optimistic when I added a second camera. An older Axis Canon camera.

This camera wanted to use Java, which was problematic. In fact, neither of my 3 browsers would allow running Java – regardless of how many “I am aware of the risks, just let me do my thing” boxes I checked.

In the end, I had to ask a friend, and surprisingly I had to use IE and add the camera to the list of “compatible” sites.

So suddenly, the motivation to do server side motion detection is clear to me – it is not about using the resources optimally (most people probably realize this already, and I’ve heard that Pelco is not recommending this as well), but it’s just such a massive pain in the ass to do it.

Maybe ONVIF will make a protocol for setting up motion detection (but since there is no notion of “motion detection”, and no fixed node to poll for such an event, I am not holding my breath). I’ll just recommend using a camera with a sensible configuration interface.