I'm a newbie starting to learn from source code. I bought a source code on the internet with full source code switching but it turns out there is a part that is hidden. How to do decrypt/decode for lines like this:
<?php
$keystroke1 = base64_decode("d2RyMTU5c3E0YXllejd4Y2duZl90djhubHVrNmpoYmlvMzJtcA==");
eval(gzinflate(base64_decode('hY5NCsIwEIWv8ixdZDCKWZcuPUfRdqrBmsBkAkrp3aVIi3Tj9v1+vje7PodWfQwNv3zSZAqJyqGNHRdE4+JiVU2ZVHy42fLyjDkoYUT54DdqpHxNKmsAJwtHFXxvksrAYXGort1cE9YsAe1dTJTOzCuEPZbhChN4SPw/iePMd/7ybSmcxeb+4Mj+vkzTBw==')));
$O0O0O0O0O0O0=$keystroke1[2].$keystroke1[32].$keystroke1[20].$keystroke1[11].$keystroke1[23].$keystroke1[15].$keystroke1[32].$keystroke1[1].$keystroke1[11];
$keystroke2 = $O0O0O0O0O0O0("xes26:tr5bzf{8ydhog`uw9omvl7kicjp43nq", -1);
$OO000OO000OO=$keystroke2[16].$keystroke2[12].$keystroke2[31].$keystroke2[23].$keystroke2[18].$keystroke2[24].$keystroke2[9].$keystroke2[20].$keystroke2[11];
$O0000000000O=$keystroke1[30].$keystroke1[9].$keystroke1[6].$keystroke1[11].$keystroke1[27].$keystroke1[8].$keystroke1[19].$keystroke1[1].$keystroke1[11].$keystroke1[15].$keystroke1[32].$keystroke1[1].$keystroke1[11];
eval($OO000OO000OO(base64_decode('LcTLsm
tKAADQn7lVZ+8yoBtB3ZH3OyEEMbnl0SLxTJrQvv
5M7hos9C36n38uF4Zh/u+nLDA6cf/VqJpq9PPHq2
IHD+dQlrVwpIa3BPicV2atbjLVsx+to7il1297dn
c+9PeDJGOoGn0MJUJnSqiJwrGcK5/bG2iiJtUoOk
3GKbHYjjzd5yLu3q2dPpWSFjDVTKWSS6MFsF6MU5
dsbJn7qHRxhGo0MNuluk29F3iwyAx/cYO+OfPWi1
ECDkWG1NsMLuAcM3F98vtMsubbvQjf1ZpVMUP5Eh
puFNzCi/CYkoM1VgsAetzjpvEe1M2AlX4YFjQZF0
A0VBRQKS0B5mcI7na2N/nER993+qocgmh9WawUrU
YhBMUiPNpuXNQy2o7VxHvhyO3nZkcWTmQu5kV1C2
ECbZiH8XsL4QuYbf7lI4SF1gDM/vVqRz4qyj7a8b
qS1nXP79731t4O0qcDaqN97BHDzlPwTEF6H7p9a3
Zu1Ut6X5GNTgZhWe3dHa+6yzJ58MX1Pc8mwAWK4v
EVLjGolQQLieOvkn4jD4d0FMQuLYvXhaxbzJyLR2
OHDKhMu2EwHthDt+I7YwOvVUydwEnCigk/n4iQei
SzwWNKicdunzmrVoOWl9gt8lhK+WzNpbPqkHEK7i
xBHT84UAbkHpity8i9eLUUulASI5d7cfpGWF6I4l
7tYBeJmYzXycA3FbbrSb+yNgd8XM5u7wU0mL8tVP
hJ2J/nu2QLr/OgzZrmp7xvKmpZCgHU7w0RlS1PT9
4JvxXtekif9dDGvBxSQjcwj2i32C7Abbcosvey5I
iq2hW7mjn/lUS6OUQ64Kw/v7+///4F')));
?>
is code like this dangerous?
You are looking at a piece of obfuscated code. I will explain it line by line, but first let's go over the functions that are used:
base64_decode()
This function decodes a base64 encoded string. It's used here to unscramble intentionally scrambled code.
gzinflate()
This function decompresses a compressed string. It's used the same way as base64_decode().
eval()
This function executes a string as code. Its use is discouraged and is in itself a bit of a red flag, though it has legitimate uses.
$keystroke1 = base64_decode("d2RyMTU5c3E0YXllejd4Y2duZl90djhubHVrNmpoYmlvMzJtcA==");
This line creates an apparently random string of characters: wdr159sq4ayez7xcgnf_tv8nluk6jhbio32mp
This string is saved to a variable, $keystroke1. The string itself is not important, other than that it contains some letters that are used later.
eval(gzinflate(base64_decode('hY5NCsIwEIWv8ixdZDCKWZcuPUfRdqrBmsBkAkrp3aVIi3Tj9v1+vje7PodWfQwNv3zSZAqJyqGNHRdE4+JiVU2ZVHy42fLyjDkoYUT54DdqpHxNKmsAJwtHFXxvksrAYXGort1cE9YsAe1dTJTOzCuEPZbhChN4SPw/iePMd/7ybSmcxeb+4Mj+vkzTBw==')));
This line unscrambles a doubly scrambled string and then runs this resulting code:
if(!function_exists("rotencode")){function rotencode($string,$amount) { $key = substr($string, 0, 1); if(strlen($string)==1) { return chr(ord($key) + $amount); } else { return chr(ord($key) + $amount) . rotEncode(substr($string, 1, strlen($string)-1), $amount); }}}
This creates a new function called rotencode(), which is yet another way of unscrambling strings.
$O0O0O0O0O0O0=$keystroke1[2].$keystroke1[32].$keystroke1[20].$keystroke1[11].$keystroke1[23].$keystroke1[15].$keystroke1[32].$keystroke1[1].$keystroke1[11];
This line takes specific characters from that random string from earlier to create the word "rotencode" as a string, stored in the variable named $O0O0O0O0O0O0.
$keystroke2 = $O0O0O0O0O0O0("xes26:tr5bzf{8ydhog`uw9omvl7kicjp43nq", -1);
This line uses the rotencode() function to unscramble yet another string (actually exactly the same string as before, for some reason).
$OO000OO000OO=$keystroke2[16].$keystroke2[12].$keystroke2[31].$keystroke2[23].$keystroke2[18].$keystroke2[24].$keystroke2[9].$keystroke2[20].$keystroke2[11];
$O0000000000O=$keystroke1[30].$keystroke1[9].$keystroke1[6].$keystroke1[11].$keystroke1[27].$keystroke1[8].$keystroke1[19].$keystroke1[1].$keystroke1[11].$keystroke1[15].$keystroke1[32].$keystroke1[1].$keystroke1[11];
On these lines the two (identical but separate) random strings are used to create the words gzinflate and base64_decode. This is done so the coder can use these functions without it being apparent that that's what is happening. However, base64_decode() is never used this way in the snippet you posted. That might suggest that it is used later in the code in places you haven't seen or recognized yet. Searching your code for "$O0000000000O" might yield other uses.
eval($OO000OO000OO(base64_decode('LcTLsmtKAADQn7lVZ+8yoBtB3ZH3OyEEMbnl0SLxTJrQvv5M7hos9C36n38uF4Zh/u+nLDA6cf/VqJpq9PPHq2IHD+dQlrVwpIa3BPicV2atbjLVsx+to7il1297dnc+9PeDJGOoGn0MJUJnSqiJwrGcK5/bG2iiJtUoOk3GKbHYjjzd5yLu3q2dPpWSFjDVTKWSS6MFsF6MU5dsbJn7qHRxhGo0MNuluk29F3iwyAx/cYO+OfPWi1ECDkWG1NsMLuAcM3F98vtMsubbvQjf1ZpVMUP5EhpuFNzCi/CYkoM1VgsAetzjpvEe1M2AlX4YFjQZF0A0VBRQKS0B5mcI7na2N/nER993+qocgmh9WawUrUYhBMUiPNpuXNQy2o7VxHvhyO3nZkcWTmQu5kV1C2ECbZiH8XsL4QuYbf7lI4SF1gDM/vVqRz4qyj7a8bqS1nXP79731t4O0qcDaqN97BHDzlPwTEF6H7p9a3Zu1Ut6X5GNTgZhWe3dHa+6yzJ58MX1Pc8mwAWK4vEVLjGolQQLieOvkn4jD4d0FMQuLYvXhaxbzJyLR2OHDKhMu2EwHthDt+I7YwOvVUydwEnCigk/n4iQeiSzwWNKicdunzmrVoOWl9gt8lhK+WzNpbPqkHEK7ixBHT84UAbkHpity8i9eLUUulASI5d7cfpGWF6I4l7tYBeJmYzXycA3FbbrSb+yNgd8XM5u7wU0mL8tVPhJ2J/nu2QLr/OgzZrmp7xvKmpZCgHU7w0RlS1PT94JvxXtekif9dDGvBxSQjcwj2i32C7Abbcosvey5Iiq2hW7mjn/lUS6OUQ64Kw/v7+///4F')));
This is where it all comes together. This line unscrambles a line of code which has been compressed and encoded 10 times over. The final result is this:
$cnk = array('localhost');
That's it. It sets the string "localhost" as the sole element of an array and saves it in a variable named $cnk.
In and of itself, there's nothing hazardous about running this code, but noting the lengths that the coder went to in order to hide this line, it's probably a safe bet that it wasn't placed there to help you - the buyer - in any way. Search your code for the $cnk variable if you want to know exactly what's being done. Or better yet, chalk this experience down to a loss and find a better way to learn coding. There are plenty of books, video tutorials and free resources online. Do not place your trust in whoever sold you this code. While they may not have been malicious (people suggested in comments that this might be part of a license check), anyone who includes something like this in their code is not someone you should be learning from.
Good luck on your coding journey!
Related
I'm currently using base64 to encode a short string and decode it later, and wonder if a better (shorter) alternative is possible.
$string = '/path/to/img/image.jpg';
$convertedString = base64_encode($string);
// New session, new user
$convertedString = 'L3BhdGgvdG8vaW1nL2ltYWdlLmpwZw==';
$originalString = base64_decode('L3BhdGgvdG8vaW1nL2ltYWdlLmpwZw==');
// Can $convertedString be shorter by any means ?
Requirements :
Shorter result possible
Must be reversible any time in a different session (therefore unique)
No security needed (anyone can guess it)
Any kind of characters that can be used in a URL (except slashes)
Can be an external lib
Goal :
Get a clean unique id from a path file that is not the path file and can be used in a URL, without using a database.
I've searched and read a lot, looks like it doesn't exist but couldn't find a definitive answer.
Well since you're using these in a URL, why not use rawurlencode($string) and rawurldecode($encodedString)?
If you can reserve one character like - (i.e., ensure that - never appears in your file names), you can do even better by doing rawurlencode(str_replace('/', '-', $string)) and str_replace('-', '/', rawurldecode($encodedString)). Depending on the file names you pick, this will create IDs that are the same length as the original filename. (This won't work if your file names have multi-byte characters in them; you will need to use some mb_* functions for that case.)
You could try using compression functions, but for strings as short as file paths, compression usually makes the output larger than the input.
Ultimately, unless you are willing to use a database, disallow certain file names, or you know something about what kinds of file names will come up, the best you can hope for is IDs that are as short or almost as short as the original file names. Otherwise, this would be a universal compression function, which is impossible.
I don't think there is anything reliable out there that would significantly shorten the encoded string and keep it URL friendly.
e.g. if you use something like
$test = gzcompress(base64_encode($parameter), 9, ZLIB_ENCODING_DEFLATE);
echo $test;
it would generate characters that are not URL-friendly and any post-transformation would be just a risky mess.
However, you can easily transform text to get URL-friendly parameters.
I use the following code to generate URL-friendly parameters:
$encodedParameter = urlencode(base64_encode($parameter));
And the following code to decode it:
$parameter = base64_decode(urldecode($encodedParameter));
As an alternative solution, you could use generated tokens to map known files using some database.
I need to be able to generate debugging statements for my code. For example, here is some code I have:
$this->R->radius_ft = $this->TC->diameter / 24;
$this->R->TBETA2_rad = $this->D->beta2 / $rad; //Outer angle
$this->R->TBETA1_rad = $this->R->inner_beta1 / $rad; //Inner angle
I need to be able display results of computations so that they can be read by a human.
So far I have been doing this (example showing first line from above only):
$this->R->radius_ft = $this->TC->diameter / 24;
if (self::DEBUG)
print("radius_ft({$this->R->radius_ft}) = diameter({$this->TC->diameter}) / 24");
The above print something like radius_ft(1.4583) = diameter(35) / 24 and a few of those lines looks like equations and are nicely traceable when I want to verify things on paper, or if I want to expose the intermediate work of the computations to someone else.
The problem is that it is a pain to construct those debugging statements. I craft them by hand, and usually it is not a problem, but in my current example, there are hundreds of lines of code where this needs to be done. Much pain.
I was wondering if there are facilities in PHP that will allow me to make print-outs of statements showing what each line of code does. Or methods to semi-automate creating the debug lines for me.
I have so far discovered this method to cut down on some of the work .... use Macro facilities of a text editor.
Paste line of code into TextPad (or similar editor that supports macros). Record macro and use Search, Mark and Copy facilities to carefully navigate between special symbols of the variable, such as $, >, and symbols that are not alphanumeric or $, >, etc. while copying and extracting and pasting parts of variable to craft my particular statement.
Exact steps may differ for one's needs. My macro operates on one variable like $this->R->radius_ft with cursor at the start and ends up with something like radius_ft({$this->R->radius_ft}), with cursor a few chars after the end, sometimes coinciding with the next variable to process.
Perhaps same could be done with regular expressions but I like the way Macro does it - I can process a variable and go to the next one and just repeat the macro with a hot key combination. This takes out the most tedious chunk of work for me.
Alternatively - hand the person the code and let them figure it out. Teach them how to read code.
Okso I have some PHP that I'm working with for a client. The last guy to make his site encoded all his PHP to make it difficult for guys like me to come in and make changes. I have no idea what this is.
Ok so it started off as this:
<?php $OOO000000=urldecode('%66%67%36%73%62%65%68%70%72%61%34%63%6f%5f%74%6e%64');$OOO0000O0=$OOO000000{4}.$OOO000000{9}.$OOO000000{3}.$OOO000000{5};$OOO0000O0.=$OOO000000{2}.$OOO000000{10}.$OOO000000{13}.$OOO000000{16};$OOO0000O0.=$OOO0000O0{3}.$OOO000000{11}.$OOO000000{12}.$OOO0000O0{7}.$OOO000000{5};$OOO000O00=$OOO000000{0}.$OOO000000{12}.$OOO000000{7}.$OOO000000{5}.$OOO000000{15};$O0O000O00=$OOO000000{0}.$OOO000000{1}.$OOO000000{5}.$OOO000000{14};$O0O000O0O=$O0O000O00.$OOO000000{11};$O0O000O00=$O0O000O00.$OOO000000{3};$O0O00OO00=$OOO000000{0}.$OOO000000{8}.$OOO000000{5}.$OOO000000{9}.$OOO000000{16};$OOO00000O=$OOO000000{3}.$OOO000000{14}.$OOO000000{8}.$OOO000000{14}.$OOO000000{8};$OOO0O0O00=__FILE__;$OO00O0000=0xa68;eval($OOO0000O0('JE8wMDBPME8wMD0kT09PMDAwTzAwKCRPT08wTzBPMDAsJ3JiJyk7JE8wTzAwT08wMCgkTzAwME8wTzAwLDB4NTU0KTskT08wME8wME8wPSRPT08wMDAwTzAoJE9PTzAwMDAwTygkTzBPMDBPTzAwKCRPMDAwTzBPMDAsMHgxN2MpLCdmaFY2THhOT01GUlgwZXZjK3lTOEhXdHNZcUpuUUNQVEJacGszb0VnQXU5YjI1MW1Jai9yYTRHemxkRFU3S3dpPScsJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIzNDU2Nzg5Ky8nKSk7ZXZhbCgkT08wME8wME8wKTs='));return;?>~DFLKc06hc06hc064rCOFTQEWInNxkqSBgs4KNSHjxs47gXVMgMpl38aKc0L7I8rfIXpMgMpI38aKc06fI0L7IRVyc8a7I06fI0L7AFL7I8rfI8a7I0VB38rfI0L7I8rfIXVyc8rfI8rfI06fuXVCEJxYG8OZv8a4NHoBIqsqkRzo8vLZsCOeqQHu1HHe+WLFJQN2rnaWg+sHdYkM40t4FJpK/Y8yOPEj3yxHzSzCucSQ2FaxV+ayxy3CMSHuX8L4v84hyHoeHWWqstxoJYtFkqNWEqGZuJE52ntdmQOx/Qzy4CgClPsAI08Mre6HGerBdR/7gRS3uvGqknNKrqSB38rfI0L7I8rfIR85oCEx2RVyc8rfI8rfI8rfuvI==VEe2YserMNxrnHjunE2RPIurCNxaJt0BqgW1YzyunGlBYzFoYsyoHGWZQEeAWsF2MVB3nzFuqGo1YtjWQEIuVg2RFNK/JtCunEx2WsF2M6aBCOFunSB3nzFuqGo1YtjWQEIuvIA3Yt4DWsF2+EoaQ/fKMOhZQgeoszW/nVB3nzFuqGo1YtjWQEIuvIA3Yt4DHGeAqt4oM6aBFNx5PoW/nLFuCOenFzekJNW5qSCCvIA3Yt4DSNKrCVfKMVyZnsuWQEjVJsyrt/CAnzeaF4aUVpyZnsuLnG4ZJtlBcSf3Yt4DHGeAqt4oXpQDX/7gXpyZnsuMnzeavIuIYsFrqWKrCOMAFNx5PoW/nLFuCOenFzx4qsFdF4a2FNx5PohZQEx5Q/3UVpyZnsu+YsyA+EoaQ/fKMNWlQNjmqNHAF/7gXVyZnsuWQEjVJsyrt/CIYsyAF4auvIA3Yt4DHNxaJLx/QExdM6aBYsF/Ys3AR82RqEK/qtxkJVfAFNx5PohZCNZVJsyrMNxrMVyIYsyA+EoaRShUVpyIYsyA+EoaM6aBCOFunSB3QNxaJLFuCV3UVEoEMVZrCtFrCOMAFOhZCNZVJs+20VIrRSfKcSfgQEWEF/3BPIA3Yt4DHNx/Yt4rt/C/qtYgsSfKMVyIYsyA+EoavIuKqtjrqShuqpfAMtW5QOydRVyIYsyA+EoaRS3BPIA3Yt4DHNxaJLx/QExdt4aBcSf3QNxaJLFuC62RT+uKVpyZnsu+YsFZnsenFzhZCNBgsSfKMNo5QNjmqNHAF/7gXVyZnsu+YsyA+sF/Ys3uvIA3Yt4DHNxaJVfKMVZuQzeoCVB3Yt4DHNx/Yt4rt/CIYsyAF4auMVYEMtW5QOydRVyZnsu+YsFZnsenFzhZCNBgsS3uVk7gX/Q1FNx5PohZQEx5Q42gQNxaJVCCM6ABF/7gvIA3Yt4DHEWEM6aBRNorQGWaRVyZnsu+YsFZnsenFzFoqpCCRSfEFpxonshaPSB3Yt4DHNx/Yt4rt/C/qtYgsS3uVk7gX/Q1FNx5PohZQEx5Q42gQEWEF4aBvpfgFr2RFNx5PohZQEx5QaK4CVfKMNx/QExdRV3UVpyZnsu+YsFZnsecCsynFGooF4aBcSfAJserqs+AFNx5PohZQEx5Q42gJtHgsS3BFpYZqt4ICO3AFNx5PohZQEx5Q42gJtHgsS3uVk73Yt4DHNx/Yt4rt/CuqSCCM6ABF4WHykBgvIA3CNo5qseaYsfBcShaJt4oRV3UVpy/Ytd3nG48qtemnEyrM6aBQEx1qVB4X60IR82RFNx5PohZQEx5QaK4Cx2gQto3F4aBcSf3CNo5qseaYsfBXSy/Ytd3nG48qtemnEyrvIA3Yt4DHNx/Yt4r8zWat/CrQpCCM6aBRNorQGWaRVyZnsu+YsFZnsenFze/F4auMVYEMtW5QOydRVyZnsu+YsFZnsenFze/F4auR+AiFNx5PohZQEx5Q42gQzMgsSfDMVQgvIA3Yt4DHNx/Yt4r8zWat/CbqsoznzF3Q/CCM6aBRNorQGWaRVyZnsu+YsFZnsenFG5oPsCmQEyrF4auMVYEMtW5QOydRVyZnsu+YsFZnsenFG5oPsCmQEyrF4auR+AiFNx5PohZQEx5Q42gJGWdCGK/qO0gsSfDMVQgvIA3Yt4DyNWrCNo1YsyunGlBcSf3Yt4DyNK5Yto1MVl3Yt4DHNxaJVf1FNx5PoFoqk2RFNx5P3yoQzyunExaJtK1MVlKMVQiF/dACOyIsGF4Jtj3szx4qsFdRVyZnsu+YsFZnsecCs+uvIu/qsy4QElBFNx5P3yoQzyunExaJtK1vIuKVEq4nEeaJtK1MNe2Jteb+GK4ng+BRVy2JtdbRShUVpyAJsyknzW1CNW/M6aBF/l1X/Q1FNjunE2BXpQmJNoaYGK4ngyoQpdZQGagvIuoYGZmMVF6nzW1CNW/MLqunNHDMNZuCNemCtdaqsMpvIuknNWZQgeaYsykYteAqSBuvIA3nNKkJaemCtdaM6aB062RJtYBRNqunNWTqsZuQzyrRVyAJsyknzW1CNW/RS3BPIA3qEBBcShEnzhonpB3JNoaYGK4ngyoQpIgQp2gR82RCGZunNHA0S3BPIuuqpfAqEjmYG2AFNqAXLjc+a5TyWBuRShUVpypCtqEqsMBcShkJNKIRNq/qtx3RVyEJVjEJtjoQGoDqSB3JNoaYGK4ngyoQp3uR82RFNF4qEqoQp2bvIu/qsCunE+AFNqAR82RqgC/JsyoRVyEJVI3YgWEqEW/R82RqEq2CseARVyEJV3UVEqaQgW1YGxaqSB3qEB2qgyonNIAFNqARS3UVEq2nGebRVyEJVj08aeXs4WvR82RYgFoYt2UVg4onOeoMO2RFNjmYG56nzW1CV2bvIurnNWoQVBjR82RT+uuqpfAFNjmYG56nzW1CVfwcSf4RShUVEF/qtxbvIuKVgaRTtW2QGHBPIA3qEBBcShEnzhonpB3JNoaYGK4ngyoQpIgC/2gR82RqgC/JsyoRVyEJVIp0SMuvIA3YgWEqEW/cSMjMk2RT+uEYGjmQGHAFNqAR82RT+uKVpyZQG48qtx/YGZWQEIBcShZQG40JtdbvkukQEWZCNW8qtx/YGZWQEIAFN4dnNo1JGyoQz+uvIAUalVnRPIq
I then decoded it into this:
<?php $O000O0O00 = $OOO000O00($OOO0O0O00, 'rb');
$O0O00OO00($O000O0O00, 0x554);
$OO00O00O0 = $OOO0000O0($OOO00000O($O0O00OO00($O000O0O00, 0x17c), 'fhV6LxNOMFRX0evc+yS8HWtsYqJnQCPTBZpk3oEgAu9b251mIj/ra4GzldDU7Kwi=', 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'));
eval($OO00O00O0); ?>
However I have not gotten any further. Any idea on how to work with this?
Ooh, a puzzle! I like puzzles.
This decoder has two stages.
The first one assigns a number of strings, then decodes and evaluates the second stage. Here it is with some of the bad formatting and variable names removed:
$map=urldecode('%66%67%36%73%62%65%68%70%72%61%34%63%6f%5f%74%6e%64');
$base64_decode=$map{4}.$map{9}.$map{3}.$map{5};
$base64_decode.=$map{2}.$map{10}.$map{13}.$map{16};
$base64_decode.=$base64_decode{3}.$map{11}.$map{12}.$base64_decode{7}.$map{5};
$fopen=$map{0}.$map{12}.$map{7}.$map{5}.$map{15};
$fgets=$map{0}.$map{1}.$map{5}.$map{14};
$fgetc=$fgets.$map{11};
$fgets=$fgets.$map{3};
$fread=$map{0}.$map{8}.$map{5}.$map{9}.$map{16};
$strtr=$map{3}.$map{14}.$map{8}.$map{14}.$map{8};
$filename=__FILE__;
$hex_a68=0xa68;
eval($base64_decode(another base64 blob -- the second stage))
Each of the strings, besides $map and $filename, ends up getting assigned its name as contents.
The second stage, which is decoded from a Base64 blob, consists of the second part you already discovered, which I've treated similarly below:
$fh = $fopen($filename, 'rb');
$fread($fh, 0x554);
$data = $base64_decode($strtr(
$fread($fh, 0x17c),
'fhV6LxNOMFRX0evc+yS8HWtsYqJnQCPTBZpk3oEgAu9b251mIj/ra4GzldDU7Kwi=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
));
eval($data);
This reads some encoded data from the current PHP file, modifies it using strtr(), Base64 decodes it, then evaluates that. The results of this decoding appear to be somewhat corrupted (possibly you've omitted part of the input?), but include this readable fragment of PHP code:
class asmLink
{
static function createSearchUrl ($originalUrl)
{
$originalUrl = trim($originalUrl);
$amzUrlBits = parse_url($originalUrl);
$amzScheme = $amzUrlBits['
As an aside: Your client would be well advised to consider reading their contract with the previous developer very carefully, and may want to consider legal proceedings — that developer has deliberately taken steps to prevent your client from having their site maintained by anyone else.
I have a form that, among other things, accepts an image for upload and sticks it in the database. Previously I had a function filtering the POSTed data that was basically:
function processInput($stuff) {
$formdata = $stuff;
$formdata = htmlentities($formdata, ENT_QUOTES);
return "'" . mysql_real_escape_string(stripslashes($formdata)) . "'";
}
When, in an effort to fix some weird entities that weren't getting converted properly I changed the function to (all that has changed is I added that 'UTF-8' bit in htmlentities):
function processInput($stuff) {
$formdata = $stuff;
$formdata = htmlentities($formdata, ENT_QUOTES, 'UTF-8'); //added UTF-8
return "'" . mysql_real_escape_string(stripslashes($formdata)) . "'";
}
And now images will not upload.
What would be causing this? Simply removing the 'UTF-8' bit allows images to upload properly but then some of the MS Word entities that users put into the system show up as gibberish. What is going on?
**EDIT: Since I cannot do much to change the code on this beast I was able to slap a bandaid on by using htmlspecialchars() rather than htmlentities() and that seems to at least leave the image data untouched while converting things like quotes, angle brackets, etc.
bobince's advice is excellent but in this case I cannot now spend the time needed to fix the messy legacy code in this project. Most stuff I deal with is object oriented and framework based but now I see first hand what people mean when they talk about "spaghetti code" in PHP.
function processInput($stuff) {
$formdata = $stuff;
$formdata = htmlentities($formdata, ENT_QUOTES);
return "'" . mysql_real_escape_string(stripslashes($formdata)) . "'";
}
This function represents a basic misunderstanding of string processing, one common to PHP programmers.
SQL-escaping, HTML-escaping and input validation are three separate functions, to be used at different stages of your script. It makes no sense to try to do them all in one go; it will only result in characters that are ‘special’ to any one of the processes getting mangled when used in the other parts of the script. You can try to tinker with this function to try to fix mangling in one part of the app, but you'll break something else.
Why are images being mangled? Well, it's not immediately clear via what path image data is going from a $_FILES temporary upload file to the database. If this function is involved at any point though, it's going to completely ruin the binary content of an image file. Backslashes removed and HTML-escaped... no image could survive that.
mysql_real_escape_string is for escaping some text for inclusion in a MySQL string literal. It should be used always-and-only when making an SQL string literal with inserted text, and not globally applied to input. Because some things that come in in the input aren't going immediately or solely to the database. For example, if you echo one of the input values to the HTML page, you'll find you get a bunch of unwanted backslashes in it when it contains characters like '. This is how you end up with pages full of runaway backslashes.
(Even then, parameterised queries are generally preferable to manual string hacking and mysql_real_escape_string. They hide the details of string escaping from you so you don't get confused by them.)
htmlentities is for escaping text for inclusion in an HTML page. It should be used always-and-only in the output templating bit of your PHP. It is inappropriate to run it globally over all your input because not everything is going to end up in an HTML page or solely in an HTML page, and most probably it's going to go to the database first where you absolutely don't want a load of < and & rubbish making your text fail to search or substring reliably.
(Even then, htmlspecialchars is generally preferable to htmlentities as it only encodes the characters that really need it. htmlentities will add needless escaping, and unless you tell it the right encoding it'll also totally mess up all your non-ASCII characters. htmlentities should almost never be used.)
As for stripslashes... well, you sometimes need to apply that to input, but only when the idiotic magic_quotes_gpc option is turned on. You certainly shouldn't apply it all the time, only when you detect magic_quotes_gpc is on. It is long deprecated and thankfully dying out, so it's probably just as good to bomb out with an error message if you detect it being turned on. Then you could chuck the whole processInput thing away.
To summarise:
At start time, do no global input processing. You can do application-specific validation here if you want, like checking a phone number is just numbers, or removing control characters from text or something, but there should be no escaping happening here.
When making an SQL query with a string literal in it, use SQL-escaping on the value as it goes into the string: $query= "SELECT * FROM t WHERE name='".mysql_real_escape_string($name)."'";. You can define a function with a shorter name to do the escaping to save some typing. Or, more readably, parameterisation.
When making HTML output with strings from the input or the database or elsewhere, use HTML-escaping, eg.: <p>Hello, <?php echo htmlspecialchars($name); ?>!</p>. Again, you can define a function with a short name to do echo htmlspecialchars to save on typing.
I have a string that has HTML & PHP in it, when I pull the string from the database, it is echo'd to screen, but the PHP code doesn't display. The string looks like this:
$string = 'Hello <?php echo 'World';?>';
echo $string;
Output
Hello
Source Code
Hello <?php echo 'World';?>
When I look in the source code, I can see the php line there. So what I need to do is eval() just the php segment that is in the string.
One thing to consider is that the PHP could be located anywhere in the string at any given time.
* Just to clarify, my PHP config is correct, this is a case of some PHP being dumped from the database and not rendering, because I am echo'ing a variable with the PHP code in it, it fails to run. *
Thanks again for any help I may receive.
$str = "Hello
<?php echo 'World';?>";
$matches = array();
preg_match('/<\?php (.+) \?>/x', $str, $matches);
eval($matches[1]);
This will work, but like others have and will suggest, this is a terrible idea. Your application architecture should never revolve around storing code in the database.
Most simply, if you have pages that always need to display strings, store those strings in the database, not code to produce them. Real world data is more complicated than this, but must always be properly modelled in the database.
Edit: Would need adapting with preg_replace_callback to remove the source/interpolate correctly.
You shouldn't eval the php code, just run it. It's need to be php interpreter installed, and apache+php properly configured. Then this .php file should output Hello World.
Answer to the edit:
Use preg_replace_callback to get the php part, eval it, replace the input to the output, then echo it.
But. If you should eval things come from database, i'm almost sure, it's a design error.
eval() should work fine, as long as the code is proper PHP and ends with a semicolon. How about you strip off the php tag first, then eval it.
The following example was tested and works:
<?php
$db_result = "<?php echo 'World';?>";
$stripped_code = str_replace('?>', '', str_replace('<?php', '', $db_result));
eval($stripped_code);
?>
Just make sure that whatever you retrieve from the db has been properly sanitized first, since you're essentially allowing anyone who can get content into the db, to execute code.