Prey: Open source theft recovery
Chances are, you know someone who has lost a laptop or smartphone, or had one stolen outright. Although preventing the theft itself would be the most satisfying outcome, there is little a software developer can do on that front (although one might consider proximity-monitoring over Bluetooth to be a step in the right direction). Full-disk encryption and password-protection for the BIOS are common strategies, but another approach — device tracking — has never enjoyed a high level of popularity in open source. The Prey project offers one open source device tracking solution, with a small range of options — including self-hosting or using the company's online monitoring service.
Device tracking options
All software-based device tracking systems share one common element: they periodically record data about the machine and its surroundings, including location, IP address, and network settings, or perhaps even a photo taken with an on-board camera. Where they differ is in how and when that information is transmitted to the device owner, and how the application detects whether or not it has been lost or stolen. Some upload their periodically-collected data sets to a remote server on every run, others simply "phone home" to perform a status check, and only record and report information if they get the appropriate signal.
Proprietary solutions like GadgetTrak or LoJack for Laptops tend to rely on a central server run by the software provider, who waits for the device owner to report the loss or theft. The first widely-deployed open source device tracker was Adeona, which took a different approach: it uploaded its reports to a remote storage location at every snapshot period. That eliminated the need to maintain a central database of tracked devices, which is what the proprietary companies charged their recurring fees to maintain. Sadly, Adeona is currently offline, as the storage service used, OpenDHT, has been deactivated.
Prey operates more like the proprietary services. The default behavior is for the Prey script to wake up periodically and make an HTTP request to a preconfigured URL. The response code sent tells the script what to do next: a 200 (the "OK" status code) will shut the script down normally. Only a 404 "Not Found" code (which requires making a successful connection to the web server) will trigger the script's theft response. Prey can be configured only to send reports about its status and whereabouts, or to trigger local actions, such as an audible alarm, flashing an alert notification on screen, or locking the system.
![[Prey control panel]](https://static.lwn.net/images/2011/prey-control-sm.png) 
Fork Ltd., the company behind Prey's development, offers two administration options. Users can configure Prey to use the "Prey Control Panel" site as the pre-shared URL, or to run in standalone mode. Control Panel users can configure device-reporting settings and actions through the web site, as well as mark a device as missing (which removes the URL requested by the script's heartbeat-checking routine) and view any reports it sends. Standalone users must manually edit the Prey configuration file, supplying their own heartbeat URL, and provide valid SMTP and email configuration details — in standalone mode, the script emails its reports rather than posting them to the Control Panel server. Fork recently started offering paid "Pro" accounts, which allow simultaneous tracking of more devices and additional configuration options, but says it will always offer free accounts.
Stalking Prey
![[Prey configuration]](https://static.lwn.net/images/2011/prey-config-sm.png) 
The current release of Prey is version 0.5.3, and is available for Linux, Mac OS X, Windows, and Android. An iPhone/iPad version is presently in private beta testing. On Linux, the application itself is a collection of Bash scripts and support files (such as the audio file played as an alarm). The source bundle can be installed on any modern distribution, requiring only the set up of a cron job to run the main script at the desired interval. It depends on cURL to make its HTTP requests, the streamer utility from xawtv to capture webcam images, and Python to run a small GUI configuration tool. There is also a Debian package available on the download page, which is compatible with Debian and Ubuntu distributions.
The actual setup process is simple, but the Prey project's web site suffers from severe documentation drought. There are no step-by-step guides suitable for new users (much less for configuring Prey in standalone mode): the necessary information is split up between the README file in the code bundle, the FAQ page, the "Knowledgebase," and the mailing list. If all you are interested in doing is signing up for the free Control Panel service, you will probably muddle through without too many hiccups, but I found it difficult to track down the answers to many of the questions I would want to know before I embarked on installing it.
For example, the site's splash page, FAQ, and README all discuss adding a "valid web URL
" as the means of enabling Prey in standalone mode, but the example they give is a URL on one's own domain or blog.  In the prey configuration file, there are no client-side settings to control the actions (alarm, lock, etc.) performed or the data gathered when Prey sends a report — all of which are settings exposed on the Prey-hosted Control Panel site.  If you read through the mailing list archives, though, you discover that the URL Prey checks for is intended not merely to return a valid HTTP response code, but to serve up an XML configuration file.  There is still no documentation for the syntax and options of the file, but evidently if one first sets up an account with the Prey service, one can download and save the file to then use later in standalone mode.
I would also like to see more thorough disclosure of what machine information Prey sends to the Control Panel server. Because the Prey script makes an HTTP request, presumably a fair portion of the information could simply be gathered from the request headers, but any time an application "phones home" I prefer to see what it is going to say before I install it the first time. After initially adding a device, the Control Panel has a detailed hardware information section disclosing more about the system configuration than I generally like strangers to be able to access. For non-Pro accounts, the connection to the Control panel site is not sent over SSL, which makes it vulnerable to eavesdropping. There are scattered references to Prey using Amazon S3 to store its webcam report snapshots, rather than sending them directly to the Prey site, but here again the documentation is sparse.
From a user standpoint, though, Prey works quite well. On Linux, the Bash scripts run with root privileges, which might concern those of a high-security mindset. Prey can gather an impressive set of information about your machine for the reports it sends back if the machine goes missing. In addition to webcam snapshots and the standard geolocation and WiFi-triangulation options, it can complete a traceroute, capture a desktop screenshot, log any recently-modified files, and log running applications.
The Control Panel interface is easy to understand, with newbie-friendly explanations of the various settings and options. Even the setup tool does a good job of outlining the difference between Control Panel and standalone mode. I am not sold on the value of playing an MP3 alarm file, but the ability to lock down the currently-running session (with password-protection) is a necessity when dealing with theft. The Prey team also deserves kudos for explaining the value of encrypting the hard disk and password-protecting the BIOS; those measures may be the only means to prevent attackers from wiping a machine entirely.
If you are not patient enough to wait until someone steals your laptop, you can dry-run Prey by running the /usr/share/prey/prey.sh script with the --check option. This will test the network connection, the crontab entry, and the validity of the API key and device ID for your hardware. Testing actual report generation is harder; for non-pro accounts the only option appears to be marking your device as "missing" in the Control panel interface.
Prey forward technologies
Taking a look at the configuration file (which on Linux systems is installed at /usr/share/prey/config), there are some tantalizing options that do not yet seem to be active in the 0.5.3 code, including SSH tunneling and SCP/SFTP file transfer, both with support for RSA key-based authentication instead of passwords. There are also some experimental options for modifying the HTTP request in order to get around firewalls and other attempts to block Prey. Here, too, my hope is that we will see further details documented on the site, rather than have them buried in the comments of the configuration file alone.
One final concern for potential Prey users is whether the three-device limit imposed on non-Pro accounts is genuinely enough. Even a single individual is likely to hit the three-device limit these days, and although each member of a family could set up his or her own Control panel account, I suspect that in most families a single family member will end up bearing the burden of keeping tabs on the portable electronics. The limit will, of course, help sell Pro subscriptions — or push users into setting up their own standalone server.
To me, that makes the need for better documentation of standalone mode configuration all the more important. While an enterprising developer could craft a homemade equivalent to the Prey Control Panel and serve up a valid XML file to clients, all indications are that the Prey project wants to operate as a true open source citizen — the source code is available on GitHub and the mailing list is public. It just has a little bit further to go.
If you are looking for an open source alternative to the proprietary device tracking products on the market, Prey is worth examining. Because it is based on standard Linux system tools, it ought to run on any distribution — perhaps even including Maemo and MeeGo handsets, although they do not have Bash installed by default. You just might have some hoops to jump through if you are intent on running your own device-tracking server.
| Index entries for this article | |
|---|---|
| GuestArticles | Willis, Nathan | 
      Posted Jul 7, 2011 9:05 UTC (Thu)
                               by pcampe (guest, #28223)
                              [Link] (5 responses)
       
From the point of view of the thief, this software is a trojan, and so the very first thing that (s)he has to do is disable it: if such only requires rm-ing some bash scripts it's a way too easy. 
 
 
     
    
      Posted Jul 7, 2011 9:33 UTC (Thu)
                               by akumria (guest, #7773)
                              [Link] (1 responses)
       
Or, just as simple, ensure that the target domain never resolves to anything useful. 
 
 
     
    
      Posted Jul 7, 2011 10:26 UTC (Thu)
                               by pcampe (guest, #28223)
                              [Link] 
       
1. rm -f usual_path_of_prey/usual_file_1 
 
 
It's also true that, before issuing 1. and 2., the system is up and running, and so there is a small window of opportunity for Prey to call the target domain and downloading instructions (if there is some network connectivity, and it's a big if) but it's not bullet-proof; so it seems to me that some kind of obfuscating executables is worth of; am I missing something? 
 
 
     
      Posted Jul 7, 2011 19:55 UTC (Thu)
                               by n8willis (subscriber, #43041)
                              [Link] (2 responses)
       
Nate 
     
    
      Posted Jul 8, 2011 7:55 UTC (Fri)
                               by pcampe (guest, #28223)
                              [Link] (1 responses)
       
 
 
     
    
      Posted Jul 8, 2011 15:16 UTC (Fri)
                               by n8willis (subscriber, #43041)
                              [Link] 
       
     
      Posted Jul 7, 2011 11:13 UTC (Thu)
                               by NAR (subscriber, #1313)
                              [Link] (1 responses)
       
     
    
      Posted Jul 9, 2011 8:20 UTC (Sat)
                               by shane (subscriber, #3335)
                              [Link] 
       
The thief was a thief of convenience, not a professional, as I suspect most are. This particular one mostly used the laptop for surfing porn, and did not wipe anything. 
Prey is no guarantee, but it has saved thousands of euros of MacBook Pro and put a bad guy behind bars. 
     
      Posted Jul 7, 2011 11:42 UTC (Thu)
                               by dany (guest, #18902)
                              [Link] (3 responses)
       
Idea is to have guest account enabled (or not locked account), so thief is actually using computer for some time. Spying software is hidden, so thief doesnt know about its existence. So they are counting on fact, that thief is not clever and doesnt reinstall OS right away. 
     
    
      Posted Jul 7, 2011 13:45 UTC (Thu)
                               by alex (subscriber, #1355)
                              [Link] (2 responses)
       
Which is probably a fair assumption with most thieves. 
     
    
      Posted Jul 8, 2011 9:11 UTC (Fri)
                               by dsommers (subscriber, #55274)
                              [Link] (1 responses)
       
What if an extended grub boot loader would do dhcp and phone home ... then if missing, it would boot up a special "fake" OS installation, which would harvest the needed info and the thief itself would believe it was a "good" theft - and s/he might miss the encrypted harddrive.  This "fake" OS could even be instructed to wipe the encrypted drive(s), all based on the initial grub call. 
Of course, the challenge is how to tackle wireless networks, where some require authentication, some networks are hidden/no ESSID broadcast ... and when the rightful owner tries to boot the laptop on a plane, where there are no networking available, what to do here? 
Anti-theft, not impossible, but darn hard to do without a secure and non-interactive way of communication to the "controller", which, ideally, is activated before BIOS passwords are entered. 
 
     
    
      Posted Jul 8, 2011 12:16 UTC (Fri)
                               by ndye (guest, #9947)
                              [Link] 
       
Here I suggest a number of grace reboots before wiping the owner's data, supporting the next suggestion. 
How about a special, hidden key sequence (controlled by the owner) that opens a backdoor in the "fake" OS, to authenticate the owner when phone-home fails?
 
     
      Posted Jul 11, 2011 15:38 UTC (Mon)
                               by ssam (guest, #46587)
                              [Link] (2 responses)
       
so in order to do this securely it really ought to run during GDM. but for that to work it would need to automatically connect to networks. or to have a guest login. 
     
    
      Posted Jul 12, 2011 22:11 UTC (Tue)
                               by n8willis (subscriber, #43041)
                              [Link] (1 responses)
       
Nate 
     
    
      Posted Jul 12, 2011 22:44 UTC (Tue)
                               by mjg59 (subscriber, #23239)
                              [Link] 
       
     
      Posted Jul 12, 2011 15:03 UTC (Tue)
                               by bredelings (subscriber, #53082)
                              [Link] (1 responses)
       
I'm curious about what happens after you (ideally) determine the location of the computer and get the thief's e-mail address and photograph.  Is it actually true that you can simply go to the police, and they will make the thief give the computer back to you?  I seem to recall vaguely hearing of cases where someone identified the thief, but still couldn't recover their computer. 
In short, perhaps this software should be called "Prey: computer locator and thief identifier".  Actual recovery of the stolen device is beyond the capabilities of the software.  Or is it? 
     
    
      Posted Jul 14, 2011 3:34 UTC (Thu)
                               by grg (guest, #76756)
                              [Link] 
       
When reporting it stolen, I gave the police his full name, his mobile phone number and his Dad's full name and mobile number. As far as I know, they made no attempt to follow this up. 
So the moral of the story is: don't bother, if you know where the thief is, "send the boys around" instead. 
     
      Posted Jul 14, 2011 16:21 UTC (Thu)
                               by Zizzle (guest, #67739)
                              [Link] (4 responses)
       
He will just wipe it and install Windows. 
 
     
    
      Posted Jul 14, 2011 20:37 UTC (Thu)
                               by bronson (subscriber, #4806)
                              [Link] (3 responses)
       
     
    
      Posted Jul 15, 2011 1:57 UTC (Fri)
                               by grg (guest, #76756)
                              [Link] (2 responses)
       
     
    
      Posted Jul 15, 2011 3:47 UTC (Fri)
                               by Hausvib6 (guest, #70606)
                              [Link] (1 responses)
       
So, being a thief (of physical thing), comitting copyright infringement is surely guilt-free. 
     
    
      Posted Jul 15, 2011 15:41 UTC (Fri)
                               by bronson (subscriber, #4806)
                              [Link] 
       
As always, pirate user experience FTW! 
     
    Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
2. rm -f usual_path_of_prey/usual_file_2
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
      You seem to fundamentally misunderstand what Prey, Adeona, and the proprietary offerings actually are.  They are not anti-theft systems.
      
          Prey: Open source theft recovery
      Is it useful?
      
Is it useful?
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
could even be instructed to wipe the encrypted drive(s), all based on the initial grub call
the challenge is how to tackle wireless networks, where some require authentication, some networks are hidden/no ESSID broadcast ... and when the rightful owner tries to boot the laptop on a plane, where there are no networking available
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
Prey: Open source theft recovery
      
 
           