A couple of years ago I announced in a forum that I had been able to bypass the regular user interface on Visonic's Powerlink module for their Powermax +/Pro alarms. I didn't want to give out the details publicly for security reasons. However, I receive requests about this almost weekly, and I've also learned that there are many valid reasons for bypassing the regular interface (such as to reset the user account) and that Visonic is less than helpful in order to help out in such cases. So I feel now that having the backdoor key is a requirement for users to be able to use their rather expensive powerlinks. Besides, I'd like to see more people hacking with their powerlinks and explore further.
I want to stress a security concern whether or not you use the backdoor. Never expose Powerlink to an insecure wlan (such as wep or no encryption at all), as an intruder then easily could disarm the alarm from the street outside your home. The default root password cannot easily be changed.
There are two ways of logging into Powerlink. Either by ftp, which will take you straight to the root filesystem, or by telnetting to port 7523 for a regular Unix login session. The root password depends on the software version. For version 2.1.1 the password is vispl211. For version 3.1.* (only verified for 3.1.7) the password is vispl31x. An alternative way that works for several versions is to log in as "root2" using the password visonic.
The passwords were no big secret, really. It turns out that the way cameras communicate with Powerlink is to upload pictures through ftp using the root acount. Ftp is totally unencrypted, so the password can easily be found by sniffing packets on the lan using a program like wireshark. /etc/password revealed the root2 user and the password was very weak and trivial to obtain. If none of the mentioned passwords work, I suggest to use the network sniffing method to find it. Having Powerlink and your PC on an old network hub will do the trick. Or try to guess the password. There seems to be a pattern...
One of the other things that the network sniffing revealed was that Powerlink communicates with one of Visonic's servers in Israel (212.179.58.186 = myhome.visonic.com), passing on information such as changes in the alarm's status. This alone is a reason good enough why any user should know the backdoor to be able to disable this "feature". Even worse, the communication is via unencrypted http meaning that not only do you tell Visonic whether you're at home or not, but anyone with access to the network between you and Visonic can (theoretically) spy on you. Some information can actually be deduced from the URL's which probably means that if you live in an EU/EEA country, your ISP is required to store all this information up to two years due to the infamous Data Retention Directive, so that your government can have a record of when you leave your house and when you get home, and when you go to bed and get up if you regularly arm to the "home" mode. Stasi would drool if they had been shown the technology.
An example of the kind of information going out of your Powerlink is a POST /scripts/notify.php request with the following data:
<?xml version='1 0'?> <notify> <pmax_account>001234</pmax_account> <index>39</index> <serial>0208018292</serial> <time>87765</time> <priority>2</priority> <event id='81' type='Arm Home'/> <profile id='3' type='Open / Close'/> <device id='3' type='User'/> <location id='1' type='Admin'/> <zone id='-1'/> <userlist> </userlist> </notify> |
I don't know why this kind of information is sent to Visonic. Perhaps it's needed for optional services such as e-mail notifications. But I find it absolutely unacceptable, if not criminal, that this is done without the user's knowledge and consent, and I find it questionable even if the user knew and agreed. I strongly suggest that all users turn this stuff off. That will also block Visonic from upgrading your system remotely (or brick it for that matter). This is how you do it:
The server is now set to 127.0.0.1 (localhost) and no data will leave your Powerlink, which will simply ignore the requests to itself.
We've now seen that there is a commandline tool for manipulating Powerlink. It can be used to check the status, to arm, disarm, etc. Some features are not available in all Powerlink versions, though. I wrote a Perl script to make the commands available on a PC and to interpret the reply. You can download it here. You may need to change the first lines of the script to suit your needs and setup.
If the script complains about missing files, run cpan and install the missing packages. Search the internet if you're unsure about this.
The syntax is powermax.pl <command>. The most useful commands are:
So to arm Powermax, run powermax.pl 1 2 away regular on your PC.
Powerlink runs Linux on an ARM processor. This makes it easy to program. The main limitation, however, is that the root filesystem is readonly. The filesystem is cramfs, which by design and for better compression is readonly. Luckily, the /var directory is a separate filesystem which is writeable making it possible to store data and programs permanently. Unfortunately, everything related to the boot process is on the root filesystem, so there seems to be no way of making new programs run automatically after a reboot.
I noticed that Powermax has a logfile /tmp/log/wc_log. This is a circular buffer which includes all communication between Powermax and Powerlink (at least in version 2.1.1, but this has changed somewhat in version 3.1.7), including information about sensor activity. So I wrote a program that keeps track of the sensor activity. This makes it possible to keep a detailed log, and I also found it useful for switching on lights in a room using X10 if someone enters it. The program has two parts: a Perl program to run on your PC which will create a log file, and a precompiled binary which the Perl program will upload to Powerlink and run there. The binary does the buffer reading on your Powerlink. The program is by no means complete. It has to interpret the communication between Powerlink and Powermax, which requires some reverse engineering, and I've only done this partly. The source code of the binary is available here. The binary was created with gcc for ARM. If you want to compile for ARM yourself, you can either set up a cross-compiler, or you can compile natively on an ARM machine. I have a few Linksys NSLU2 running Debian (little endian) which can be used for making binaries for Powerlink.
Now things get interesting. Since Powerlink has a widely used ARM processor, can we simply copy the entire filesystem from Powerlink, put it on some other hardware and run the software and that way solve the problem with the readonly root filesystem? The answer is yes! This is exactly what I've done. I created a directory on a Linksys NSLU2, copied the entire Powerlink filesystem to that directory, chroot'ed to that directory and ran the boot scripts. I had made an RS232 to RJ45 cable to connect the NSLU2 to Powermax and made sure that the cable could be accessed through the device file that Powerlink expects (/dev/ttyS1, if I remember correctly). And it worked!
I never used the NSLU2 as a Powerlink replacement. I only did this to the point that I had verified that it works, and I didn't make notes. So for those who'd like to replicate this, I can only offer the information that it works. I believe it should work on other ARM based Linux boxes as well, such as SheevaPlug or GuruPlug. Unfortunately I have no notes of the pinout for the cable and I don't have the cable at home anymore.
If you see this as a way to get a pirate Powerlink and to save money (there are several ARM based Linux boxes available for less than $100), I can't help you. I will not send you the Powerlink filesystem. It contains copyrighted programs. So you need your own Powerlink if you wish to replace the hardware.
So the root filesystem is readonly, but it doesn't mean that it can't be changed. It just means that you need to reflash the Powerlink in order to change it. Let's have a look at it:
# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00040000 "Blob" mtd1: 00100000 00040000 "Kernel_A" mtd2: 00c80000 00040000 "Cramfs_A" mtd3: 00400000 00040000 "Jffs2" mtd4: 00100000 00040000 "Kernel_B" mtd5: 00c80000 00040000 "Cramfs_B"
/dev/mtdblock0 contains the bootloader. /dev/mtdblock3 contains the /var filesystem, and /dev/mtdblock[12] and /dev/mtdblock[45] are alternate versions of the firmware, most likely selectable in the bootloader. The dual boot setup is probably there for safe upgrading.
It's possible to reflash by writing to /dev/mtdblock*, but you have to be absolutely sure of what you're doing if you do this. I will not touch my flash unless I have access to the bootloader.
The bootloader remains elusive. I've not found a way to access it. The bootloader is GPL'd code and Visonic has changed it. They're required to publish the code as well as their changes, which could reveal whether it's possible to reach the bootloader via ethernet, but they've not responded to my requests for the code. Others have also requested the code, but heard nothing back or got a rude reply. So it seems that Visonic is pretty determined in violating the license.
I hope that the above information will be sufficient for other hackers to get started, and perhaps pick up the trail where I left it. If you go further or otherwise do something interesting with your Powerlink, please send me an e-mail. I've only scratched the surface of the possibilities. I've received many questions whether it's possible to use other cameras than Visonic's expensive and extremely low quality cameras. I haven't tried. It should work. Either the camera needs to be programmed to behave like a Visonic camera (directly or through a PC), or Powerlink can be changed (might require changes to the root filesystem). Someone just needs to try it out.
This is a feature that the Powerlink doesn't allow as it "takes over the cams". Before I found your article I already tried to intercept the "camera enrollment sequence" with whireshark but I never could seem to find the enrollment traffic.
I was looking for the password that is set on the cams by the Powerlink.
With your article's help I was able to figure out that the application that runs on the Powerlink that controls the Cams is called /misc/wc-pxa255/binaries/cmm. As there is no config or xml data on the cams I just opened the CMM binary file in ultraedit and found that all the Camera Enrollment strings are readable. Starting at (ultraedit file position) Position: 73ec0H, 47816, C0 the camera definitions start. For all the cameras that the Powerlink support the enrollment settings are hardcoded into the CMM app.
This is how I found out that for my 1 visonic cam the uid/pwd = camadmin / viscam and for my 3 Vivotek cams it is uid/pwd root/viscam. Having this access I can use my cams connected to the Powerlink and in addition use them with my Netcam Watcher software (http://www.netcam-watcher.com/index.php).
I was able to boost the resolution from 320×240 (standard Powerlink resolution) to 640×480. Altough the webinterface of the Powerlink still resizes them to 320×240 the detail is much better. Having the experience I have now the webinterface must be easy to edit (haven't tried it yet, but will do soon).
The JPEG compression can also be altered to get better image quality but I found out the compression cannot be absolute minimum as the files become too large and the Powerlink cannot handle that large datastream.