Downloading apps encoded

[Wolfie]

Not sure how feasible or possible this would be, so I'll toss it out there and so it can at least be thought on.

Now, I can understand many people liking the idea of downloading and running source files on their sites. But what if someone wants to permit access to their ACP and/or FTP but want to make sure that the access isn't misused to download any of the source files?

Here's my thought on it. Provide an option for the client to download an encoded version, but with a twist. Provide a way to get a unique 'key' that would be part of the encoded files (perhaps encoded within one of the primary core files) that would perform a simple check and if it's not running in the correct environment, then it fails to run. Could be made to check the domain name (just the domain.tld part even), so that it should work on a subdomain if the client moves their community to another URL on the same domain. But if someone manages to get hold of the files and install it on someotherdomain.com, then it won't work.

I know it might sound like a bizarre request or whatever, but I'm sure there are some who would make use of the option to make sure that if someone betrays their trust, then they won't get much use from it.

Another benefit is it could help reduce the chances of the files being infected, at least without it being easy to detect. If a hacker uses a tool to edit a file to add code, it would either fail to add the code (can't find the right area to add it) or would cause the file to fail to load, which might sound like a drastic measure but in a way would prevent the code from running since it would effectively shut the site down, but that in turn would raise a major red flag immediately. In a way would be like a virus alert.

Now, not saying to force clients to accept encoded files. Just the option to download an encoded version that is set to run only on their site.

_{(Waits for an IM from someone jumping his case over this idea...)}

[skizzerz]

It is a good idea, but I don't see this working 100% in practice. I am going to speak from the perspective of ionCube encoding, as I own an ionCube license but not a Zend Guard license, so I better know what ionCube's capabilities are.

The first part of your suggestion, downloading an encoded version that is locked to a specific domain, is completely doable and not too difficult to implement. In ionCube, I could simply encode the product and use the option that says "require a license file to run," and then in the download process I would generate a license file with the download which authorizes the downloaded product to run on that specific domain.

The second part, preventing arbitrary code execution when giving someone write access to your filesystem, would be a nightmare if not downright impossible to implement. You might be able to set up your php.ini (hopefully you aren't giving the untrusted user write access to php config, either system-wide or per-dir) to have an auto_prepend_file that checks for encoded status and bails out if the file being run is not encoded (ionCube provides functions to check if a given file is encoded, but I don't know if/how this works from an auto_prepend_file standpoint), but this requires system access high enough to modify php configuration. If you cannot accomplish that, there is nothing stopping the user from simply replacing a file with an unencoded version from a pirate release with some additional malicious code hooked in, as an encoded file will happy include and execute any unencoded file (the reverse -- an unencoded file including and executing an encoded file -- can be prevented by encoding the files with an "include key", which is essentially a password in order to successfully include/require the particular encoded file).

So what I think this amounts to is that it prevents someone you give filesystem access to from stealing your code and using it on their own site, but in this event they'll probably just grab a pirated release anyway. You can configure your system's PHP to only run encoded files, which would assist in stopping hackers from executing arbitrary code (at least until they just uploaded encoded malware), but you would likely be better served following common security practices anyway: don't allow the web user to write to directories where PHP scripts can be executed, only give filesystem access to users that you trust will not upload anything malicious, set up a virus scanner or checksum watching program (such as tripwire) and execute it regularly via cron to detect malware or unauthorized file changes.

[Wolfie]

It is a good idea, but I don't see this working 100% in practice. I am going to speak from the perspective of ionCube encoding, as I own an ionCube license but not a Zend Guard license, so I better know what ionCube's capabilities are.

Just so this is mentioned now, if someone can't run ionCube or Zend files, then obviously they just use the source files. I know you weren't hinting at that being an issue but thought I would mention it.

The first part of your suggestion, downloading an encoded version that is locked to a specific domain, is completely doable and not too difficult to implement. In ionCube, I could simply encode the product and use the option that says "require a license file to run," and then in the download process I would generate a license file with the download which authorizes the downloaded product to run on that specific domain.

I know, and that was what I had in mind with this idea.

The second part, preventing arbitrary code execution when giving someone write access to your filesystem, would be a nightmare if not downright impossible to implement.

I'm not talking about preventing code from executing, but more of the fact that if a tool is being used to insert code within a certain point, it either wouldn't find the code (because it's encoded and not plain text) or it would still insert the code, thus breaking the encoded file, which in turn will cause it to throw an error. More of letting it fail naturally vs designing it to fail.