Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
This is the patch I'm using on 7.x-2.0-beta5, it adds support for files that have been added to project, but ignores *.patch files, so needed to add regex support to hacked_file_scan_directory() as well.
I tested the patch in #4 against the current dev, and I have a few comments/questions...
When I run the Hacked report or view a result, it throws this error message:
Notice: Constant HACKED_STATUS_DELETED already defined in include_once() (line 18 of /home/ruffsack/public_html/sites/all/modules/hacked/hacked.module).
When you view a result, it shows "Created" files as "Deleted" in the column on the right.
It did find a test.php file that I added to the Webform module directory, so that is working quite nicely.
It also reported several "files created" for benign files that are part of contrib modules. For example, it told me that the Ubercart contrib folder contained "9 files created". I compared the Ubercart installation files to a fresh download of the module, and it appears that Ubercart adds files to its installation folder, perhaps when you activate certain features. For example, I have a file called shipping/uc_ups/uc_ups.css that doesn't exist in a fresh download of UC. It is simply CSS code to style the UPS options at checkout. Not sure how that could be handled/ignored. Perhaps there simply needs to be some due diligence by the webmaster to take note of which modules contain those kinds of files.
Another example is the Entity API module. Hacked reports this file, which is benign: "views/error_log" (no extension on the file)
It reports that Drupal core has "9502 files created", so it is counting the fils/ dir, the contrib modules, etc. Again, not sure of a way to avoid that, but it makes it difficult or even impossible to find backdoors in Drupal core.
1+2. Yea I just looked at the patch again myself, seems like it wasn't formed correctly, should be a pretty easy fix.
3. Yea for me this was really the main use-case, to aid with detection of custom tweaks to contrib modules.
4. Not sure what to do about these sort of things either, perhaps suggest the offending modules don't do it, haven't run into this issue yet myself though.
5. I think this is the main big task that'll need to be tackled for this feature, but for me it's not so important because I don't hack core and run a web server config that blocks access to a lot of stuff, and regular core updates take care of the rest of my concerns, it also makes it incredibly slow to run a scan on large sites, so on my version I've just disabled core scanning for new files, someone else can take the reins on this one.
I've been rolling out the patched version on several sites, and have been encountering this error while running the Hacked report on quite a few of them:
An AJAX HTTP request terminated abnormally. Debugging information follows. Path: /batch?id=35&op=do StatusText: error ResponseText: ReadyState: 0
Is this a memory issue on the server? Or something else?
It could provide an useful option : the possibility to ignore the public file directory cause if you have a lot of media, the system will detect a lot of changes.
Comments
Comment #2
mustanggb commentedThis is the patch I'm using on 7.x-2.0-beta5, it adds support for files that have been added to project, but ignores *.patch files, so needed to add regex support to hacked_file_scan_directory() as well.
Comment #3
mustanggb commentedWhoops, spotted a typo in default $nomask parameter.
EDIT: Sorry about the unnecessary chmod's.
Comment #4
mustanggb commentedAn untested reroll against dev.
Comment #5
hockey2112 commentedI tested the patch in #4 against the current dev, and I have a few comments/questions...
Another example is the Entity API module. Hacked reports this file, which is benign: "views/error_log" (no extension on the file)
Thanks!
Comment #6
mustanggb commented1+2. Yea I just looked at the patch again myself, seems like it wasn't formed correctly, should be a pretty easy fix.
3. Yea for me this was really the main use-case, to aid with detection of custom tweaks to contrib modules.
4. Not sure what to do about these sort of things either, perhaps suggest the offending modules don't do it, haven't run into this issue yet myself though.
5. I think this is the main big task that'll need to be tackled for this feature, but for me it's not so important because I don't hack core and run a web server config that blocks access to a lot of stuff, and regular core updates take care of the rest of my concerns, it also makes it incredibly slow to run a scan on large sites, so on my version I've just disabled core scanning for new files, someone else can take the reins on this one.
Comment #7
hockey2112 commentedHow would I disable scanning of core files. You are right that regular updates will eliminate any new files in the core folder structure...
Comment #8
mustanggb commentedI'll do a new patch tomorrow if I remember, also setting write permissions correctly helps eliminate backdoor injections.
Comment #9
hockey2112 commentedSounds good, thanks!
Comment #10
mustanggb commentedUntested dev roll with #5-1+2 & #7.
Comment #11
hockey2112 commentedHad a moment to try the new patch today. 1 and 2 are resolved.
RE: #5, it shows Drupal core in red with "Changed!" and says "0 files changed, 0 files deleted".
Thanks!
Comment #12
hockey2112 commentedI've been rolling out the patched version on several sites, and have been encountering this error while running the Hacked report on quite a few of them:
Is this a memory issue on the server? Or something else?
Comment #13
zmove commentedEssential patch that works well.
It could provide an useful option : the possibility to ignore the public file directory cause if you have a lot of media, the system will detect a lot of changes.
Comment #14
zmove commentedI put it as reviewer too quickly, it seems that with this patch, drupal consider every contributed module as added files. It should ignore it.
Comment #15
mustanggb commentedLatest code re-rolled against dev, haven't looking into any of the feedback, however it does now distinguish between hacked and patched code.
Comment #16
generalredneckAdd this task for D8 #3046936: Add support for new/added/created files D8
Comment #17
mustanggb commentedComment #18
mustanggb commentedComment #19
mustanggb commentedComment #20
mustanggb commentedComment #21
gngn commentedI am using #19 with 7.x-2.0-beta8 and can confirm that it finds added files.
Comment #22
ivnishAutomatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.