Making sense of the Drupal Hacked! report

Shakib Mostafa // February 2014

In an earlier post about drupal site audits I introduced the hacked! module, and talked a little bit about how it can be used to identify hacked files in Drupal core and contrib modules. Today we will dive a little deeper into the world of the hacked! module in an effort to make some sense out of the reports this module produces.

First of all, in order to use hacked!, you have to install the module on your site along with a couple of others. Required and helpful modules to be installed are:

The diff module is not required to run hacked!, but without it you won’t be able to see the actual changes that have been made to the hacked files. On the other hand, drush is not needed to run hacked! or diff on the hacked files, but it processes the reports much faster and is needed if you want to create patches for the changed code automatically. I am going to assume that drush is installed and go through the steps of installing, reviewing and utilizing hacked to get your site updated.


Very easy with drush, within your site’s docroot run the following commands:

  • drush dl hacked
  • drush en hacked
  • drush dl diff
  • drush en diff

Overview Hacked! report

Let’s take a look at the drush commands available for hacked. Run the command:

  • drush help

All available drush commands show up. The hacked! section has the following:

All commands in hacked: (hacked)

hacked-details (hd) Show the Hacked! report about a specific project.

hacked-diffOutput a unified diff of the project specified.

hacked-list-projects (hlp)List all projects that can be analysed by Hacked!

hacked-lock-modifiedLock all projects that Hacked! detects are modified, so that drush pm-updatecode will not touch them. (drush-4.x+ only)

This gives us an overview of what we can do with hacked! First, we want to take a look at the list of modules that have been hacked. To do so, on the command line, cd into your docroot and run:

  • drush hlp

The output will be something like:


Administration menuadmin_menu7.x-3.0-rc3Changed10

Custom Breadcrumbscustom_breadcrumbs7.x-2.x-devChanged130

Drupal Coredrupal7.16Changed50



As we can see, in this list of 5 modules, 4 have allegedly been changed (hacked) and the last one (Date) has not been hacked. The next step would be to look at each of these allegedly hacked modules to see what exactly was changed and how to tackle them.

Review line by line changes using diff

Let’s take a look at Admin Menu first. On the command line, cd into docroot and run the command:

  • drush hacked-diff admin_menu

My output was:

diff -uprb a/README.txt b/README.txt

– README.txt 2012-05-17 17:18:12.000000000 -0400

+++ README.txt 2014-02-03 13:45:37.000000000 -0500

@@ -180,7 +180,7 @@ This project has been sponsored by:

   to get you started. Visit for more information.

 * Lullabot

-  Friendly Drupal experts providing professional consulting & education

+  Friendly Drupal members providing professional consulting & education services. Visit for more information.

 * Acquia


Here, the first line of the output tells us which files have been changed, which in this case is the README.txt file. The following lines tell us what was changed. We only need to worry about the lines starting with the + and - symbols. The - symbol means that line was taken out and the + symbol means that line was added. So, looking at this hacked diff report for Admin Menu tells us that the line “Friendly Drupal experts providing professional consulting & education” was replaced by the line “Friendly Drupal members providing professional consulting & education services. Visit for more information.” in the README.txt file. This is actually good news, because this shows that in the admin menu, only the README info file was changed with some comments, which is not a code change or hack and does not have any effect on the site’s behaviour. So we can safely ignore this “hack”, and decide to update the module.


Next up, let’s take a look at drupal core. From anywhere within your docroot, run the command:

  • drush hacked-diff drupal

My output was: 

diff -uprb a/.htaccess b/.htaccess

– .htaccess 2012-10-17 16:45:04.000000000 -0400

+++ .htaccess 2014-02-07 22:47:25.000000000 -0500

@@ -32,6 +32,7 @@ DirectoryIndex index.php index.html inde

   php_value mbstring.http_input             pass

   php_value mbstring.http_output            pass

   php_flag mbstring.encoding_translation    off

+  php_value memory_limit                    1024M


 # Requires mod_expires to be enabled.

diff -uprb a/modules/user/user.module b/modules/user/user.module

– modules/user/user.module 2012-10-17 16:45:04.000000000 -0400

+++ modules/user/user.module 2014-02-03 13:45:36.000000000 -0500

@@ -610,8 +610,7 @@ function user_save($account, $edit = arr


     return $account;

-  }

-  catch (Exception $e) {

+  } catch (Exception $e) {


     watchdog_exception(‘user’, $e);

     throw $e;

Only in /Library/WebServer/Documents/project/docroot/sites/all: libraries

Only in /Library/WebServer/Documents/project/docroot/sites/all/modules: account_reminder


Again, see that these are non-issues. There are a few diffs mentioned here:

1. diff -uprb a/.htaccess b/.htaccess

This is very common since htaccess is often changed by developers. Changes to htaccess are not considered to be hacks. We just need to remember to save a copy of the htaccess prior to running updates, so that those changes can be applied back after core update.

2. diff -uprb a/modules/user/user.module b/modules/user/user.module

This is an issue with white space and new lines, actual code hasn’t changed. The piece of code “} catch (Exception $e) {” used to be in two lines and now is in one. This is a fairly common false positive on hacked. Often there will be reports of hacked files which are just spacing issues and these can be completely ignored for updates.

3. Only in /Library/WebServer/Documents/project/docroot/sites/all: libraries

These are obvious, drupal core does not have anything in sites/all, so things like sites/all/libraries, sites/all/modules etc will show up here and can be ignored.

After seeing all of these, we can safely decide to update Drupal core since these were not actual hacks. We just need to remember to save and reapply the htaccess changes.

Hacked! False Positives

As we saw earlier, spacing issues can trick the Hacked module into giving false positives. Another area where we end up with a lot of false positives are actually modules that are in their dev version. For example, on our list, the Custom Breadcrumbs module is a dev version: 7.x-2.x-dev. Dev versions are a nightly snapshot of the development branch of the module on a given day. If the module’s developers make more changes the following day and check them in, the version of the module does not change. Therefore, your modules that are on dev versions are being compared to the code of the latest release of those development branches and can often and almost always give out false positives. We can ignore dev version hacks, but if you just want to be sure, you can download the module’s code from the exact date that’s on your module’s info file and do a manual diff with your code to see if anything has changed.

Actual hacks

Lastly, let’s take a look at a module that has actually been hacked. Running drush hacked-diff on mailchimp gave the following output:

diff -uprb a/modules/mailchimp_lists/mailchimp_lists.module b/modules/mailchimp_lists/mailchimp_lists.module

– modules/mailchimp_lists/mailchimp_lists.module 2013-07-24 19:44:54.000000000 -0400

+++ modules/mailchimp_lists/mailchimp_lists.module 2014-02-03 13:45:37.000000000 -0500

@@ -686,7 +686,7 @@ function mailchimp_lists_execute_change(


       case ‘update’:

-        $ret = mailchimp_update_user($list, $mail, $mergevars, TRUE, $mcapi);

+        $ret = mailchimp_update_user($list, $mail, $mergevars, FALSE, $mcapi);


There is clearly a hack here, the value of an argument has been changed from FALSE to TRUE. This is a fairly small hack but there may be other instances where they are larger and harder to deal with. With real hacks, there are a number of things that can be done. One option is to not update the module at all, in which case, after the other modules have been updated, we could run the hacked-lock-modified command so that these are locked from future drush updatecode updates. The other option is to use this hacked-diff to create a patch and update the module and apply the patch. For more severe cases, where the actual contributed module is no longer being maintained, it could even make sense to move it to the custom modules folder and treat it like a custom module.

To summarize, Hacked! and Diff combined give us an awesome tool that will help us identify real issues within the sites that are new to us. After going through the process of identifying hacks, we can safely update the modules and then take care (or decide not to update) the modules that have been identified as hacked.

Filed under: