Another WordPress plugin to help you secure your blog. This time the plugin „File Hash Trace“ will help you generate a report of file hashes for all of the files on your site and check it against the actual file hashes.
This way you can detect any file changes.

  • Introduction
  • Function
  • Generate hash report
  • Check actual hashes against a hash report
  • History
  • TODOs
  • Known Bugs
  • Feature Requests
  • Compatibility
  • Installation
  • Usage
  • Donate
  • Download
  • Introduction

    It was several months ago, when my WordPress installation was hacked through an exploit in version 2.6. The hacker (shurely automatically) modified several of the php-files redirecting traffic from my site to another.
    Since I don’t check my php files for injected code, it took several time to recognize it.
    As a result me and some friends, who had the same problem, got a little bit paranoid about recent vulnerabilities in WordPress.
    My first idea was to create a plugin, that could generate hashes for all files and store it in the database, making it realy easy to trace file modifications. But storing hashes in the database is not really safe, since a hacker could delete or update the hashes. So my friend Toni suggested to me to make the hashes downloadable to the local computer and check against that hashes on demand.
    Now the first version of my plugin File Hash Trace (FHT) is finished and works.


    FHT offers two actions:

  • create a report of file hashes from the actual state of your files (generate hash report)
  • compare a previously generated hash report against the actual state of your files (check actual hashes against a hash report)

  • A hash report is a collection of filenames and the associated file hashes, as well as some meta information on the configuration that was used to generate the hashes.

    Following picture shows the main manage page fo the plugin:

    Generate hash report

    With this function you can configure which file extensions to include or exclude as well as which folders to exclude. When having lots of mp3 files or images in your blog generation of the report can take quite long and also produce high cpu load.
    You can define a list of file extensions that will be excluded (or included) in your report as well as folders not to recurse. The used hash-algorithm also can be selected. The available hash-algorithms depend on your php-installation. I suggest to use the wide spread SHA1 algorithm, that is a little bit safer than the more common and faster MD5.
    Also your absolute path for your wordpress installation is shown. (You can’t modify this, since FHT will start hashing files at the root of your wordpress installation.)
    The following picture shows the configuration page:

    As a result all files accepted by the configured filtering options are included in a hash report, which then is displayed in a text-area, from where it can be copy-pasted on the local computer.

    As you can see, the report is just a simple file containing some meta-information and all files with hashes.

    Check actual hashes against a hash report

    When you’ve saved a hash report localy, you can check the stored report against the actual file hashes at any time.
    Selecting the function an empty text-area as in the image below is displayed.

    After copy-pasting your previously generated hash report into this text-area, you can start the comparison:

    On the resulting page any file-modifications are shown as well as the files included in the previous hash report (removed/missing files) and the ones not included in the previous report (new files).

    Also the full actual hash report is displayed:


    Version: 0.1 – initial


    Known Bugs

  • The checksum comparison in the „Check actual hashes against a hash report“ function doesn’t work and always reports they are equal.
  • The parsing of hash reports is not safe. Manually trashing the report or entering some non-report values into the plugin can lead to ugly php-exceptions.
  • Feature Requests

  • Trace and display information, if parsing of a hash report fails, or if the parsed hash report’s checksum is not equal to the checksum within the report
  • When generating a report: an option: Display in textarea or download to client
  • Advanced inclusion/exclusion of files and folders via custom regular expressions (only for advanced regex-geeks)
  • Option to upload a report via fileupload as alternative to pasting it into a textarea
  • Compatibility

    Tested with WordPress 2.7. Should work on all 2.x versions. PHP 5 is recommended.


    Just upload to your wp-content/plugins folder or any subfolder and activate in plugins menue.


    Go to your manage console and find the entry „File Hash Trace“.


    If you like this plugin and it helps so much, that you would like to donate (no matter how much), please do it here.


    [drain file 1 show]

    Tags:, ,

    4 Responses to “File-Hash-Trace” »»

    1. Comment by Toni | 23:57 10.02.09|X

      You are so the man! :)

      Habs gerade mal getestst. Funktioniert 1a und mit excludes viel schneller als gedacht. Geil wäre natürlich noch eine diff view von den modifizierten dateien – vielleicht gibts dafür schon fertige php komponenten?

      Ausserdem dauert das cut&paste der checksums recht lang (mein Browser friert für 2-3 sec ein) – vielleicht sollte man das über einen fileupload lösen?

      Sind deine plugins eigentlich im wordpress listing erfasst? Wenn nicht sollten die dahin – die sind super! Weiter so!


    2. Comment by Secco | 21:00 11.02.09|X

      Hi Toni,

      Geil wäre natürlich noch eine diff view von den modifizierten dateien – vielleicht gibts dafür schon fertige php komponenten?

      Daran hatte ich auch schon gedacht. Aber das problem ist weniger die Implementierung eines Difs (was ich bereits gefunden habe) als vielmehr die Daten, die gedift werden sollen.
      Der Report enthält nur Datei URI und Hashes. Daraus kann man nur schließen, dass sich eine Datei geändert hat, aber nicht was.
      Die einzige Möglichkeit für einen Dif wäre es alle Daten zum Erstellungszeitpunkt des Reports zu speichern (ob in einem Verzeichnis, in der DB oder lokal als download).

      Ausserdem dauert das cut&paste der checksums recht lang (mein Browser friert für 2-3 sec ein) – vielleicht sollte man das über einen fileupload lösen?

      Ja, ist schon geplant. Ich schreib gleich auch mal eine Feature-Request und Known Bugs Liste dazu.

      Sind deine plugins eigentlich im wordpress listing erfasst?

      Die Populären schon, also RandomFlickrFav, Amazon Book Picture und MP3 Tag. FHT noch nicht, kommt aber bald, wenn ich wieder Lust/Zeit habe mich mit dem SVN von WordPress rum zu schlagen.
      Übrigens total blöd, dass man nicht ohne das SVN Plugins auf WordPress managen kann.
      Daher gibt es die aktuelle Version und Infos immer zuerst auf meinem Blog 😉

    3. Comment by Ralf | 10:43 12.02.09|X

      Hi Leute,

      lese gerade den Artikel, sieht wirklich gut aus!

      Auf einem root-Server würde ich jedoch noch ein paar Schritte weitergehen und Tripwire einsetzen, um auch gleich die Systemkonfiguration mitzuprüfen.



    4. Comment by Secco | 13:14 13.02.09|X

      Hi Ralf,
      hab schon mal was von den verschiedenen Intrusion Detection Systemen gehört, und das Plugin ist ihnen nachempfunden, zumindest das was ich von Toni darüber gehört habe.
      Auf meinem Blog kann ich solche Hash-Tracer (wie auch dieses Plugin) nicht unbedingt einsetzen, da ich ständig meinen WP-Code modifiziere :)
      Ich habs hauptsächlich für Toni und die anderen Blogs, die ich nur verwalte, geschrieben.
      Hoffe mal, dass es bei der Gemeinde gut ankommt.

    Leave a Reply »»

    Note: All comments are manually approved to avoid spam. So if your comment doesn't appear immediately, that's ok. Have patience, it can take some days until I have the time to approve my comments.