Using Hacked! module to compare Drupal site code to standard code
One of the first things we do when supporting a site or reviewing it for security is look for modifications to the code.
We use the Hacked module to achieve this because it works quickly and automates a lot of the work in what is a normally very tedious process.
Here's some basic usage:
Step 0. Remove any .git or CVS or .svn or...directories from your site
The Hacked module currently gets somewhat confused if there are both CVS directories and a .info file that has newer information. Now that the git migration is over I can see this potentially happening with .git directories and just to be sure you're working with a clean slate you should remove .svn directories. These metadata directories make manual diffing comparing a site's version of a module to a freshly downloaded tarball a little harder.
So, you should make sure you're working with a temporary throw-away version of of the site code and then run a command something like this from the root of the site (i.e. where index.php lives):
find ./ -name ".svn" -type d -exec rm -rf {} \;<br> find ./ -name ".git" -type d -exec rm -rf {} \;<br> find ./ -name "CVS" -type d -exec rm -rf {} \;
That will recursively find directories you no longer want and remove them. Remember, only do this from inside the Drupal root on a copy of the site where you are OK losing information.
Step 1. Review the results of the hacked report
I prefer to run the command via the command line rather than the user interface. This requires the excellent Drush module.
The command to view the list of modified files is:
drush hlp
That will create some output like:
Title Name Version Status Changed Deleted <br>Drupal drupal Drupal 6.19 Unchecked 0 0<br>Administration menu admin_menu 6.x-3.0-alpha4 Changed 1 0<br>Apache Solr Search apachesolr 6.x-1.2 Changed 28 0<br>Better Exposed Filters better_exposed_filters 6.x-1.0 Changed 6 0<br>Better Formats better_formats 6.x-1.2 Changed 4 0<br>Checkbox Validate checkbox_validate 6.x-2.1 Changed 3 0<br>Chaos tool suite ctools 6.x-1.7 Changed 1 0<br>Deployment deploy 6.x-1.x-dev Changed 17 0
Step 2. Get precise details with "hacked diff"
Step 3. Compare the module using a tarball or git
If you're still not sure what's going on you can potentially compare the module on the site to a module from drupal.org. Look in the module's .info file for information like:
; Information added by drupal.org packaging script on 2010-07-02<br>version = "6.x-1.1"<br>core = "6.x"<br>project = "ife"<br>datestamp = "1278062408"
If it's a stable release (i.e. the version doesn't end in a .dev) then you can just download it. Use the "View all releases" link from the module page to find older versions if the module has been updated from the version you are working with.
I like to download the fresh modules into a directory in my sites/all/modules/ folder called "fresh_copy".
If it's a dev release you can you use that datestamp value to figure out when it's from. First you will need to make a local copy of the git repository. Here are the commands I used for Mollom module:
cd sites/all/modules/fresh_copy/<br> git clone --branch 6.x-1.x http://git.drupal.org/project/mollom.git
From there you will now checkout the version of the code from a specific date. You can change the datestamp value to a normal date using the date command. Then use that in a git command to get a copy of the code from that date:
cd mollom
date -d @1288656895
Mon Nov 1 18:14:55 MDT 2010
git checkout git rev-list -n 1 --before="2010-11-01 18:14" 6.x-1.x
Now that you've got the files locally, I like to compare them with the diff command:
diff -rupw ife ../ife/
The -rupw options will make it run recursively on the directories, showing the output in a standard Drupal unidiff format, and ignore whitespace changes that might have been introduced by certain text editors even though they don't really change the file.
If you're lucky, the output will be something like this:
Now you have to read through the changes and see if they are real or not and you can see a little about what you might need to do about those changes.
As you can see from the later steps in this article there is a lot of manual busy-work to do a proper analysis comparing local modules to those on drupal.org. Thankfully the Hacked! module makes the initial job a good bit faster.
Tags: moduleDrupal Planet