Add ability to detect backdoors

I tried, but it does not seems to detect new files. Would be awesome if it did.

So the trick is it's really hard to tell the difference between 'new files' and actually another module.

So for example, if you think about it, all modules you install into sites/all/modules are 'new files' for the Drupal core project etc.

I'm not 100% sure how to reconcile this really. Does anyone have any smart ideas?

Well, we should at least be able to check if a contrib or core module contains a file that should not be there?

@BarisW see my response above in #3

#4 was a response on #3. We can't easily detect a new module, but when we compare the files of an existing module with the version on drupal.org, we should be able to detect new files? Why would this be hard?

Because you can place a module anywhere, including within another module or project. The easiest to explain example is indeed Drupal care, where say, 'token' module would be viewed as a 'new' file not in Drupal core and would flagged up as such. In general there's not an easy way to reconcile this that I can think of.

Maybe the only way to do this would be to look at all the files for all projects globally, and then look for any files above and beyond that. That might work.
Hacked currently considers projects in isolation, so we'd need something other than the current stuff to build this and search for the new files.

Well, we can just do this as a 'whole site' thing, and then it's done.

I should note that 'Hacked!' is a developer tool and isn't designed for running on production. There are other modules listed on the project page that are designed to protect your code from being changed.

I do agree with @Steven Jones that hacked is not the module for checking new/unwanted file. it is more of module or component specific and inform if there any change.

However, here is an option, if we want to get this option in here:
Write all file hashes in a temporary file/cache and compare them.This would give status of something is different for that module. Here is an example of what I mean:

module foo local:

foo.module -> hash1
foo.info -> hash2
foo.hacked.php -> hash3

local.foo (file or cache_key) - hash1,hash2,hash3 (order by hash)

module foo remote:

foo.module -> hash1
foo.info -> hash2

remote.foo (file or cache_key) - hash1,hash2

By comparing local.foo and remote.foo, we can tell added/removed files.

If I'm not wrong, we already have hackedProject which holds project specific details.
a) Can add another property (i.e. hashCollector)and getter/setter.
b) Can be a separate class (so that we can add an interface and implement one for file, DB, memcache, etc) and inject in hackedProject class.

@vijaycs85 please note this section on the main project page:

There are a number of other 'integrity' modules, such as 'md5check', 'File integrity check' and 'Sentry'. These modules have features to protect a live site from code changes or to only check Drupal core.

I suspect one of those is going to do what you want.

Wich module permit to detect new files ?

I just had the case in misc / farbastic. If I did not inspect my directories one by one, I have not seen a backdoor.

Bumping to major, let's make the whole site scan thing happen.

The most normal thing is to have modules in flat structure in sites/all/modules so that is ok starting poinr I think. Or maybe have a command flag that you can choose to make that assumption.

Also why can't we check what should be in a normal views folder for example and if a views_whatnot_plugin folder is found inside there we could check what should be in that folder too?

If there for some strange reason is modules inside other folder they are most likely still in their module folders. So can't we handle modules per folder?

I would really appreciate this feature.

My take on this is that is should not detect new files. It should detect files that is present on your site that does not exist on Drupal.org (as part of core or part of a full project).

The only exception to this should be directories or files below sites/all/modules/custom. For a first version of this feature, these may be ignored. For a more advanced version, the admin may create a local MD5 "fingerprint" of what should be below sites/all/modules/custom at a time when the site is known to ble clean, and Hacked! should flag anything not matching this fingerprint.

Updated summary.

I am with BarisW (#4 and #6) on this:

Responding to #7:

Because you can place a module anywhere, including within another module or project. The easiest to explain example is indeed Drupal core, where say, 'token' module would be viewed as a 'new' file not in Drupal core and would flagged up as such. In general there's not an easy way to reconcile this that I can think of.

Yes, it is true that you can place a module anywhere, including inside core or another module or project. But Token, it is not a part of core and anyone that puts it below /modules or inside some other contributed project - and not in its own directory below /sites is hacking core or some other project and should be forced to wear a dunce cap until he or she repents.

There are a few special cases like plugin-subdirectories that are intended for custom and third party stuff, but I think that this can be solved by having a way to set up a list of opt-out directories.

I think that this can be reconciled by making Hacked! work well for normal developers doing the right thing™. There is no need to cater for all sorts of special cases.

selinav wrote in #12:

Which module permit to detect new files?

Both of the following will detect new files:

• MD5 Check
• File integrity check

I just completed a total rewrite of File integrity check for Drupal 7. I think it is complete, but I am not creating a full release until I get some user feedback.

Possibly related: #2597361: Add support for new/added/created files