Basic "Can't get it to work" issue.

[ghost]

Please use this template when reporting bugs, problems, issues, etc.

Server: GoDaddy
phpMussel version used: latest
PHP version installed: 7.1.0
Operating system used: Linux

---

Issue:
First, a future thanks for the great virus scanner. I am amazed by how thorough the programme is vis-a-vis so many others. It seems like it would be really great to use.

The issue is that I can't get it to work at all. I have literally followed the instructions step by step. For clarification, they were as follows:

1. Download package.
2. Upload package and unpack the compressed folder.
3. Move to the desired destination, which is one child down from the main directory. (publichtml/phpfiles/phpMussle).
4. Rename the ini file to be just config.ini.
5. Change config settings to disable clean up.
6. Hook it to the necessary upload script pages, putting the following at the top of the pages:
   <?php require 'pathhome/public_html/phpfiles/phpMussel/loader.php'; ?>
   (pathhome has been change to correct name).
7. Then I added test code of the following:
   echo $phpMussel['Scan']('pathhome/public_html/phpfiles/phpMussel/_testfiles/ascii_standard_testfile.txt', true, true);

After such, it's all blank. The path to loader is correct because I've tried echoing code, and also printing the array and it prints a gigantic array of your data. But the above echo is blank. Just returns nothing. There is no information online. Stackoverflow has nothing yet, but the programme is a couple years old. Makes me think this issue is so small no one could have had it. Please let me know what I've done wrong. Thank you.

[Maikuolan]

Hi,

Any error_log files generated, or anything mentioned in your server's error logs at all corresponding to the approximate time and files concerned?

[ghost]

Hi @Maikuolan, there were no error logs made at all. Do you know if it's unable to work on a godaddy server? Many function are unable to work on godaddy servers.

[ghost]

The entire loader.php function correctly, nothing dies. That is, I've tried adding an echo to the bottom of the file, and it's echoed perfectly. I download every single file, I used the option at the top right of github to download the package, so no files was missing. I haven't yet gone through them to remove the .md and .txt files, so all still are there.

[DanielRuf]

I guess the error is suppressed by some @ in the code or by your server in general.

[Maikuolan]

Replicated the steps (i.e., a fresh install) on my test server, and works as expected, so at least, no recent breaking changes made to the codebase itself AFAICT.

Not aware specifically of any compatibility issues with GoDaddy, though it's possible there could be problems due to specific php.ini values or similar, depending on however they've set up the account.

Checking whether error suppression has been enabled definitely sounds like the logical next step to take, I think. If there's some error occurring, and we can't see what it is, it will be difficult to fix, so not suppressing errors would be ideal in this case (assuming that they're being suppressed currently).

[Maikuolan]

Worth noting: You'll need to install and activate any needed signature files as well, for phpMussel to work optimally. That said though, so you still be seeing something from phpMussel, regardless of whether any signature files are installed.

For example, on the fresh install on my test server just now (without the signatures), I see this currently:

Wed, 11 Jul 2018 13:49:09 +0800 Started.
> Checking '/phpMussel/_testfiles/ascii_standard_testfile.txt' (FN: 112049b9; FD: 7b9bfed5):
-> No problems found.
Wed, 11 Jul 2018 13:49:09 +0800 Finished.

[ghost]

Damn it. I was going through the code for hours last night. Errors aren't supressed, they come up whenever they occur. In regards to php.ini, could you think of any specific options that need to be changed?

I also noticed that the check you did above, @Maikuolan , in the previous comments took less than a second to complete. I thought it would take longer, that is super quick. I really would like this plugin/programme to work.

[Maikuolan]

in the previous comments took less than a second to complete. I thought it would take longer, that is super quick.

Take in mind, the example in the above comment is scanning without any signature files. It might take a little longer when all signature files are properly installed, depending on what's being scanned. ;-)

Still, we aim for fast execution when possible, so it should be reasonably fast regardless.

As an example, scanning all test files together in the same scan operation, with all signature files installed and activated, configuration giving preference for maximum scanning (e.g., nothing blacklisted, most options enabled, etc):

Wed, 11 Jul 2018 14:34:56 +0800 Started.
> Checking '/phpMussel/_testfiles/ascii_standard_testfile.txt' (FN: ce76ae7a; FD: 7b9bfed5):
-> Detected phpMussel-Testfile.ASCII.Standard!
> Checking '/phpMussel/_testfiles/coex_testfile.rtf' (FN: b0e404dc; FD: c44e0020):
-> Detected phpMussel-Testfile.CoEx!
> Checking '/phpMussel/_testfiles/exe_standard_testfile.exe' (FN: bc2b0816; FD: 0133b2e1):
-> Detected phpMussel-Testfile.EXE.Standard!
> Checking '/phpMussel/_testfiles/general_standard_testfile.txt' (FN: e0a8291b; FD: e1d00044):
-> Detected phpMussel-Testfile.General.Standard!
> Checking '/phpMussel/_testfiles/graphics_standard_testfile.gif' (FN: fa02d6a4; FD: 31dcb0b4):
-> Detected phpMussel-Testfile.Graphics.Standard!
> Checking '/phpMussel/_testfiles/html_standard_testfile.html' (FN: 20df694f; FD: 48e4ea2b):
-> Detected phpMussel-Testfile.HTML.Standard!
> Checking '/phpMussel/_testfiles/md5_testfile.txt' (FN: 26568969; FD: 4e8f9f87):
-> Detected phpMussel-Testfile.MD5!
> Checking '/phpMussel/_testfiles/ole_testfile.ole' (FN: 1d191026; FD: 0de5ef7a):
-> No problems found.
-> Reading 'ole_testfile.ole' (PHAR):
-> Checking '/phpMussel/_testfiles/ole_testfile.ole>/phpMussel/_testfiles/ole_testfile.ole/ole_testfile.txt' (FN: 4974ab10; FD: b6da61cd):
--> Detected phpMussel-Testfile.OLE.Standard!
> Checking '/phpMussel/_testfiles/pdf_standard_testfile.pdf' (FN: 6d1c7c10; FD: 8c05e37f):
-> Detected phpMussel-Testfile.PDF.Standard!
> Checking '/phpMussel/_testfiles/pe_sectional_testfile.exe' (FN: 51114ec6; FD: f93ee86b):
-> Detected phpMussel-Testfile.PE.Sectional!
> Checking '/phpMussel/_testfiles/swf_standard_testfile.swf' (FN: 1c2de39d; FD: e0cfb75b):
-> Detected phpMussel-Testfile.SWF.Standard!
Wed, 11 Jul 2018 14:35:03 +0800 Finished.

..takes about ~6, ~7 seconds on my test server (which is still pretty fast IMO, especially for something written entirely in PHP, but still somewhat slower than a traditional desktop scanner).

[Maikuolan]

Could be output being suppressed somehow, maybe..? Anything generated in /phpMussel/vault/cache/ after scanning? That location is where phpMussel stores most of its cache data (to speed up repeated scan operations and such), and we would generally expect that some .tmp files get generated into that directory when a scan operation completes. Whether anything is being generated there, could give us a clue as to whether anything is actually being scanned at all (and that we're just not seeing any output being generated for some reason), or whether the package is literally not working at all for some reason (i.e., nothing to output).

[ghost]

@Maikuolan well, in the cache there are two files.

1. a .htaccess (to be honest, don't know how that got there). Its conent is:

<Files *>
	Order Allow,Deny
	Deny from All
</Files>
Order Allow,Deny
Deny from All

2. There's also a file called index.dat (also don't know how that got in there).

[Maikuolan]

Cheers.

The .htaccess file is included in the package itself (just intended to prevent any unauthorised direct access to the directory in question; should be a few more of the same in phpMussel's other directories too).

The index.dat is usually automatically generated alongside any .tmp files generated (basically maps out for phpMussel which cache files contain what data). A little weird for one to be generated and not the other, but doesn't tell us much in itself, I think.

That there aren't any .tmp files in there though, would suggest that nothing has been scanned (so, whatever the cause of the problem, it's probably not just output being suppressed, I think).

Just to explore all possibilities: What's the current permissions/CHMOD set for the phpMussel vault directory?

[ghost]

I see i see.
Well, phpMussel folder is 775, it was originally 755, but in the instructions is said; "if you're having trouble, to try 775", so I tried that. The vault folder is on 755.

[Maikuolan]

Try saving this to a new PHP file, uploading to your server, and running it;

<?php echo ini_get('disable_functions') ?: 'Nothing disabled.';

What appears on the page?

[ghost]

A real shame, I thought maybe we were on to something! It came up saying 'Nothing Disabled'.

[ghost]

I tried doing the bit where you log in via the front end. I then trialled scanning 3 files, they all worked perfectly and the file called "scan_log.txt" was edited with each scan. Still, just not working when on a php page.

Maybe this doesn't work how I think it should.
I'm using the script inline on a page. For example, a regular php page that is used as page that a user views - not a hidden page that is used merely for ajax calls.
I'm also expecting that the data appear when I use the function "echo".

It's not overridden, thus echoing to a file in the vault, is it?

I don't want to sound like an arse, because I really really appreciate your effort in the programme and respect it, but there isn't much information regarding functions and actions other than that one liner. I notice that you need to specifically turn of the auto clean. The description of such makes it seem as if the scan happens on its own just whenever a file is uploaded.

How do all those great functions I see in the upload.php get triggered? Do they just automatically override when you use the move_uploaded_file() function or similar?

[Maikuolan]

I don't want to sound like an arse, because I really really appreciate your effort in the programme and respect it, but there isn't much information regarding functions and actions other than that one liner.

No problem. Not coming off as an arse at all, IMO. :-)

The fact that it seems to not be working as expected, is a bit baffling to me at the moment too, but we should be able to get to the bottom of it one way or another.

I notice that you need to specifically turn of the auto clean. The description of such makes it seem as if the scan happens on its own just whenever a file is uploaded.

How do all those great functions I see in the upload.php get triggered? Do they just automatically override when you use the move_uploaded_file() function or similar?

phpMussel doesn't override any default PHP functions at all. So, the "scan" function/closure (i.e., the $phpMussel['Scan'](...) bit), basically encapsulates everything foreseeably needed to scan something. It, along with all related functions/closures, are stored in functions.php.

In sticking with the coding standards promoted by PSR as best I can (specifically, the part about how files should either declare things, or cause things to happen, but not both), the functions.php file declares all the main functionality of phpMussel (minus anything specific to the front-end, which is kept in a separate file, frontend_functions.php), but it doesn't itself actually trigger any of the functionality that it declares. Conversely, the upload.php file doesn't itself declare any functionality, but is responsible for triggering the functionality already declared by functions.php, specifically, in calling the "scan" function/closure to scan an uploaded file, whenever phpMussel detects that the end-user is trying to upload something (which it detects, by way of checking whether $_FILES is populated).

In upload.php near ~L217-L228, you'll see this:

                /** Execute the scan! */
                try {
                    $r = $phpMussel['Scan'](
                        $phpMussel['upload']['FilesData']['FileSet']['tmp_name'][$phpMussel['upload']['FilesData']['FileSet']['i']],
                        true,
                        true,
                        0,
                        $phpMussel['upload']['FilesData']['FileSet']['name'][$phpMussel['upload']['FilesData']['FileSet']['i']]
                    );
                } catch (\Exception $e) {
                    die($e->getMessage());
                }

(The $phpMussel['upload']['FilesData']['FileSet'] array, ultimately, comes from $_FILES. phpMussel just rearranges the contents of $_FILES a little before scanning, to make it easier to iterate through it all, but does so in separate array, because messing around global arrays in a pre-wrapper-type package such as phpMussel, could cause unexpected problems for anything that executes afterwards, so just creating its own copy to mess around with instead is a safer alternative).

In the above snippet, you'll notice that the main bulk of what "upload scanning" is doing, is iterating through $_FILES, and then calling phpMussel's main scan function/closure for each iterated item. There are some other things which the file is responsible for too, like handling the upload honeypot (assuming this is enabled, and should be disabled by default anyhow, and likely not needed by ~99% of users), generating the "Upload Denied" page (the page we should see when something is detected in an upload and the upload consequently gets blocked), and ensuring that the hash cache gets updated (which should normally happen anyway when calling the main scan function/closure, but there's some optimisation going on in the background too for file uploads to speed up some of these peripheral things, which is why it does it in upload.php too; this shouldn't affect what you're doing though).

In functions.php near ~L4588-L4634, you'll see this:

/**
 * The main scan closure, responsible for initialising scans in most
 * circumstances. Should generally be called whenever phpMussel is
 * required by external scripts, apps, CMS, etc.
 *
 * Please refer to Section 3A of the README documentation, "HOW TO USE (FOR WEB
 * SERVERS)", for more information.
 *
 * @param string|array $f Indicates which file, files, directory, or
 *      directories to scan (can be a string, an array, or a multidimensional
 *      array).
 * @param bool $n A boolean, indicating the format for the scan results to be
 *      returned as. False instructs the function to return the results as an
 *      integer; True instructs the function to return the results as human
 *      readable text. Optional; Defaults to false.
 * @param bool $zz A boolean, indicating to the function whether or not arrayed
 *      results should be imploded prior to being returned to the calling
 *      function. False instructs the function to return the arrayed results as
 *      verbatim; True instructs the function to return the arrayed results as
 *      an imploded string. Optional; Defaults to false.
 * @param int $dpt Represents the current depth of recursion from which the
 *      function has been called. This information is used for determining how
 *      far to indent any entries generated for logging (you should never
 *      manually set this parameter yourself).
 * @param string $ofn For the file upload scanning that phpMussel normally
 *      performs by default, this parameter represents the "original filename"
 *      of the file being scanned (the original filename, in this context,
 *      referring to the name supplied by the upload client, as opposed to the
 *      temporary filename assigned by the server or anything else).
 * @return bool|int|string|array The scan results, returned as an array when
 *      the $f parameter is an array and when $n and/or $zz is/are false, and
 *      otherwise returned as per described by the README documentation. The
 *      function may also die the script and return nothing, if something goes
 *      wrong, such as if the function is triggered in the absense of the
 *      required $phpMussel['memCache'] variable being set, and may also return
 *      false, in the absense of the required $phpMussel['HashCache']['Data']
 *      variable being set.
 */
$phpMussel['Scan'] = function ($f = '', $n = false, $zz = false, $dpt = 0, $ofn = '') use (&$phpMussel) {

CLI mode doesn't need the encapsulation provided by "scan", and skips ahead to using phpMussel's internal "recursor" function/closure instead, but otherwise, normally everything should just use "scan".

(Sorry for the some of the weird keyword and variable names, BTW. I'll get around to sorting those out at some point in the future, but as changing them wouldn't affect functionality at all, wouldn't bring in any new features and such, and is basically considered an aesthetic issue, it's something on the back-burner at the moment).

On note about the cleanup directive: Normally, when phpMussel finishes executing (and when cleanup is true), phpMussel will completely remove itself (including all its functions) from memory. The reason for this, is to play nice with older, inferior servers, which mightn't have the necessary RAM available to be able to readily support having both the entirety of phpMussel sitting in memory, as well as the entirety of whatever would normally execute afterwards, and so, for them, in many cases, it may be ideal to immediately remove anything from memory, as soon as its no longer required, in order to maximise the amount of RAM available to the server. When cleanup is false though, phpMussel will remain in memory, and the user will need to remove it from memory themselves at that point if they want it to be removed at some point after when it finishes executing, and before PHP itself finishes executing for the request instance (after which, PHP itself should take of this anyway).

If logging is enabled, then scan results should be logged to a file within the vault, but this shouldn't affect the output generated by scan at all (i.e., you should still be seeing some output regardless of whether logging is enabled or disabled).

[ghost]

That was a great explanation. Completely sums my questions up. No I see how confusing this can be, because there are very minimal, if not only 1, functions that can be used. So it's really not as if I'm missing or doing something wrong. Have you not to date had many poeple say that haven't been able to install it and have it work correctly?

Are there any other trouble shooting at all that you can think of for me to do to try and figure out the issue? My times limit is merely my next app update, and in my list of items, this scanning function was first so I'm good to do whatever to see if we can get it working.

[Maikuolan]

Have you not to date had many poeple say that haven't been able to install it and have it work correctly?

I've had people say that before, but it usually turned out to be them doing something wrong, problems on the server (like crucial PHP functions disabled and such), or misunderstanding something, or a wrongly configured package (like with cleanup, for example), or things like that.. but I can't see anything like that in this case (at least, nothing that stands out, and assuming we haven't just missed something somewhere). From the information you've supplied, you seem to be doing all the right things, which makes it all very odd.

Do you, by any chance, have a separate hosting space available elsewhere (i.e., with a different hosting provider), per chance? If not, maybe a friend that could set up temporary subdirectory and FTP account for you on theirs for a day or two to test this out? Bit of a long shot, but I'm wondering, if you were to try to replicate the exact steps taken thus far with the installation which isn't working, at a separate location elsewhere, whether there would be any differences (either working properly, or if not working, providing some more details, via error logs, or some server messages which we aren't seeing currently). At the very least, whether we'd see different results between the two different locations, while taking the exact same steps, could identify whether the ultimate cause of the problem cause of the problem is (1) something wrong with the package itself (e.g., a bug, typo in the codebase somewhere, etc), (2) something wrong with the specific installation (e.g., a misstep, something configured wrongly, or installed incorrectly somehow), or (3) something wrong with GoDaddy (i.e., if the results are different, despite taking the same steps, that would imply that the ultimate cause lies with GoDaddy somewhere, whether it be a problem with the way they've configured PHP, a problem with the way the hosting account is configured, or something like that; conversely, if the results are exactly the same in both cases, then the ultimate cause of the problem couldn't be something specific to GoDaddy, and must lie either with us or the codebase somewhere).

[ghost]

That sounds good. I've got a couple of sites all with GoDaddy. They've only let me down a couple of things, so I've stayed. Give me an hour and I'll try installing it on another site.

[ghost]

Jeeeeeeeesus. It worked perfectly on the other domain. I then decided to delete phpmussel from the original site and then reinstall it.

It works! Got no idea, clearly it was all my fault and I must have done something incorrectly the time. Quick question, is there a line of code I can use to trigger a clean up?

Also, in your experience, do you know which file types are the least likely to have viruses? Or if there are file types, such as a spreadsheet document that can't have viruses?

I'll be using your virus scanner in an upload function that accepts .txt, .pdf, .xml/s, .csv, and .doc/x. Any advice?

[Maikuolan]

It works! Got no idea, clearly it was all my fault and I must have done something incorrectly the time.

No worries; As long as it works now, that's the main thing. ^.^

is there a line of code I can use to trigger a clean up?

Yep. :-)

The $phpMussel variable contains the entirety of the phpMussel's working data, functions, variables, etc, so simply destroying/unsetting it should be sufficient:

unset($phpMussel);

Or if doing so from somewhere outside the global scope (e.g., within some class, function, etc):

unset($GLOBALS['phpMussel']);

The only thing that this would miss, is any plugins that might optionally be installed (in case they work with closures or classes outside of phpMussel's global variable). The default cleanup routine in phpMussel accounts for this though by iterating through it all and using variable-variables to destroy anything registered by any installed plugins:

        /** Destroy unrequired plugin closures. */
        if (isset($phpMussel['MusselPlugins']['closures'])) {
            foreach ($phpMussel['MusselPlugins']['closures'] as $x) {
                if (isset($$x) && is_object($$x)) {
                    unset($$x);
                }
            }
        }

        /** Unset our working data so that we can exit cleanly. */
        unset($x, $phpMussel);

(But if you're not using any optional plugins, and if your own cleanup is happening within the global scope, just that first unset($phpMussel); line should be sufficient).

Also, in your experience, do you know which file types are the least likely to have viruses? Or if there are file types, such as a spreadsheet document that can't have viruses?

Technically speaking, any type of file can contain (or be infected by) a virus. However, viruses can't necessarily be executed from any type of file. For example: I could easily take the raw data belonging to a virus which normally exists inside a PE (portable executable) file (e.g., EXEs, DLLs, etc) and dump it into a plain-text file (TXT), and it would still continue to exist all the same, but in most cases, as it would be existing outside its intended infection vector, it would (usually) be effectively neutered, and unable to cause any real harm. In that sense, there's not a single type of file on the planet that we could ever guarantee as being 100% virus-free, but some types of files are nonetheless more/less dangerous than others, due to being inherently unable (under normal circumstances) to actually execute/run malicious code. So the main question then, is which types of files can actually cause things to execute, or run.

TXT files are generally pretty safe in that sense. They're intended for plain-text, and nothing else, and (assuming the end-user isn't using some insane program for reading plain-text files which does things that such a program shouldn't normally do) don't execute anything (i.e., programs intended for reading text-files, tend to just show the content of the file, allow basic editing, search-and-replace, etc, and don't actually execute anything based on file content). Because of this, TXT files aren't generally considered as viable infection vectors.

PDFs and DOC(/X) files can contain macros though, which makes them tempting infection vectors for virus and malware creators. Disabling macros in your document reader should generally make them a bit safer of course, but they remain a tempting infection vector nonetheless.

XML files are in a similar situation to TXT files. Though I've seen a few nasties before that could execute in specific contexts (like when XML files might be intended for specific programs that might execute commands based on the contents of an XML file), but it's generally pretty rare. CSV files are generally pretty safe, too (although a spreadsheet file containing a malicious macro could theoretically be renamed as a CSV file to trick users into thinking its a CSV file, and if that user's default program for opening CSVs and opening spreadsheets is the same, potentially risk being infected, so I wouldn't call them 100% safe in that sense.. but again, not a particularly big risk, and definitely mitigable if said default program disables macros in the first place, as many do nowadays by default anyhow).

Anything directly executable, or self-executable, like EXE files, are naturally going to be your main worry. If you don't allow them to be uploaded to your server in the first place though, then it's much less of a worry (you could just blacklist that filetype, ensure that the chameleon_from_exe and corrupted_exe directives are enabled, and they shouldn't then be able to be uploaded at all). If you do allow them at all though, then that's going to always be your main focus, in terms of risk factor.

As always, regardless of filetype, it's good to ensure that the chameleon_from_php directive is enabled. Given that phpMussel is intended to protect against malicious uploads to websites, and given that it's possible to embed malicious PHP code in just about anything (though the comment headers of image files tends to be a favourite for many PHP malware authors), protecting against non-PHP files containing PHP code is always a good idea (which is what that directive controls). An attacker could theoretically hijack and take over your entire server, if files are uploaded to a location where there might be some chance of PHP code being executable, and if they're able to upload something containing malicious PHP code.

Java files, Flash files, etc, are some other potential infection vectors (though there are plenty that exist, of course).

[Maikuolan]

A quick note regarding archives containing potentially infected files: In terms of risk, one's about the same as any other. However, the chance of phpMussel detecting something malicious in an archive may depend on the type of archive, due to that phpMussel doesn't yet support all of the more common archive formats.

See: Wish list: Archive support.

So, if you allow archives to be uploaded, in order to really be sure about them, and if relying primarily on phpMussel, it may, in some cases, be worth considering blacklisting the formats which aren't yet supported (due to phpMussel being unable to see inside them and scan their contents yet). Though, this would be a concern primarily for end-users being infected, as opposed to the server or website itself (seeing as the chameleon attack detections and such should still be able to detect any embedded malicious PHP code and such that could potentially execute).

General rule of thumb, also: If a particular type of file isn't something you actually expect or normally anticipate being uploaded to your website, it may be prudent to block it regardless (due to that if you see such files being uploaded by a user at some point in the future, it might or mightn't be infected, but the fact of it being unanticipated or unexpected would in itself be reason to question the file to some extent, and blocking may thus be a good idea just in case).