So a user of mine brought up an interesting security vuln that stems from ExeOutput I believe. ExeOuput has a dir called “Data” in which it places the index file. I wasnt aware of this, but if the user puts their OWN file in the Data dir with the same name as the original index file, it will use their file rather than the one in the compiled EXE, the result is that they can then do something like this:
<?php
$myfile = fopen("C:\TEST6\Data\util.php", "r") or die("Unable to open file!");
echo fread($myfile,filesize("C:\TEST6\Data\util.php"));
fclose($myfile);
exit;
?>
Being able to run code is the problem. From here, they could print the contents of every file, whether they should be able to see it or not. And since the PHP files are not encrypted at this point, no amount of encrypting would do any good.
I have to assume that this is a well known vuln considering it’s simplicity and that there is a workaround for this maybe? How can I protect against something like this, or is it simply not possible.
Yes, it is known and that’s not a real security problem: it is explained in our documentation at several places. Here for instance:
https://www.exeoutput.com/help/accessingfiles#accessing-source-files-from-php
If you want to avoid this problem, you can activate “Use an absolute path for the virtual “Data” subfolder” option.
You also have the option to encrypt important PHP source files, though you have to tell ExeOutput which files you want to encrypt. See https://www.exeoutput.com/help/php-protection#encode-marked-php-files-with-internal-protection-system
Finally, to prevent your index.php file from being replaced by another one, if you don’t want to use an absolute “Data” folder, you can activate this property for your index.php file:
Thanks for the quick reply. The “Unpack the file(s) to virtual memory at startup” option seems to fix this vulnerability issue. Should I be using this for all files I dont want the user to overwrite? If so, a better explanation of what this option does in the UI would have been cool to have. In parenthesis put something like (prohibits user from overwriting this file locally) or something like that. Because I thought “Exclude the selected files” option was the one that allowed overwriting and that clearly isnt the case here. I thought all files were prohibited from overwriting by default since that is the purpose of the exe to begin with and that would be why an “exclude” option would exist, to allow the user to overwrite certain files (such as images, etc).
Sure, we’ll add the details you suggestedt in the UI (and in the help file). Help has to be helpful 
…
Updated title to Resolved.
