Taking the Hacked! Module for a Spin

At CommonPlaces we regularly take over projects that have stalled for one reason or another under our CPR (CommonPlaces Rescue) program. Our initial assessment of a site always includes checking the server error logs, watchdog logs, checking which versions of modules are running and if they need to be updated, and so on.

It’s not uncommon that a new client will tell us that Drupal core or contributed modules on their site have been hacked by the previous developer. This puts us in a tough position because 99.9% of the time the code that was hacked now has a new release which includes functional and/or security updates, but updating the module will lose the hacks, which may or may not have been documented in the form a readme file and patches, and may or may not even be needed any more. With tens of thousands of lines of code running on your average Drupal site, how does one go about locating hacks so they can be removed and re-implemented using approved methods without losing the functionality that the hacks provided?

One great way to find hacks is by using the Hacked! module. At its core it’s a diff tool. The project page describes how it works. “This module scans the currently installed Drupal, contributed modules and themes, re-downloads them and determines if they have been changed.” Let’s get into some more of the details and see it in action.

To get started I downloaded and installed Hacked and the Diff module to my sandbox. The Hacked module maintainers suggest adding Diff, to add line-by-line visual diff functionality to Hacked. Also worth mentioning is that this should never be done on a live site. Only use this tool locally or in a sandbox.

So now that I’ve got the necessary modules installed and running, let’s see what they can do. If I head over to /admin/reports/hacked Hacked will kick off the batch process that downloads and checks each module and theme.

For the purposes of demonstration I fiddled with a couple of core files. You can see that Hacked has flagged Drupal core in red, indicating it’s been hacked (changed), and also shows the count of the files changed; in my case it was two.

If I click on “View details of changes” I can see which files were changed. With the Diff module installed I also get a link on each file name that was flagged, which takes me to the diff page for that file.

If you’re a commandline junkie and you’re using Drush you might be interested in the Drush support for Hacked. I won’t go into each Drush command in detail here, but here is an example report provided by the Drush integration which is great for including a report in an email or text document to a client.

There are additional commands as well, which let you drill down into each module or package and get even more detailed information. Also worth mentioning is the drush hacked-diff command which runs a commandline diff that you could theoretically use to create a patch file.

All this is certainly a big help, but it’s worth noting that while awesome and useful, the module isn’t infallible and false positives can occur. All in all when using this module, you’ll just need to take the results with a grain of salt so to speak, and understand a few minor limitations.

For example, one file I modified was the .gitignore file that now ships with Drupal 7. This file is intended to be modified to suit your own needs and it’s one of only a handful of files that should be modified. Unfortunately, after I modified this file the Hacked module flagged Drupal as being hacked, which is not the case.

Additionally, in the past I have run the report on sites using development versions of a module and those dev versions almost always get flagged. Why? Because development versions are a nightly snapshot of the state the development branch of the module (or theme) on a particular day. If the module maintainer makes more changes the following day and checks those in to the development branch, the version of the module does not change (nor should it). It remains the 7.x-1.x-dev version (or some similar name) and today’s code in 7.x-1.x-dev will likely differ from next month’s version of 7.x-1.x-dev. In other words 7.x-1.x-dev downloaded yesterday is not (usually) equal to 7.x-1.x-dev downloaded today. Luckily this issue only appears for dev versions. Stable releases are always the same from day to day for consistency and to make it easy to give support and debug issues.

Even with these minor limitations, the module is very well done and provides a straightforward and quick method for identifying hacks in Drupal. If you’ve taken over a site, it’s definitely worthwhile to add running a Hacked report to your existing site review procedures.