On PHP “Encryptions”

Alright, so I’ve gotten (relatively) a lot of attention for my post(s) (mainly this one) about “decrypting” PHP scripts that are engulfed in various combinations of gzinflate();, str_rot13();, and base64_decode();.

This post is mostly an attempt to enlighten those that come upon it to what these functions are and do, and probably more importantly, how to undo their secretive evil.

base64_decode

The most common function (I’ve seen) used would be base64_code(). From the documentation on php.net of this function:

Encodes the given data with base64.
This encoding is designed to make binary data survive transport through transport layers that are not 8-bit clean, such as mail bodies.
Base64-encoded data takes about 33% more space than the original data.

Here’s an example of the base64_encode(); and what the encoded string looks like (if the string ends in ‘==’ odds are it’s base64_encoded).

echo base64_encode('This is an encoded string');
// VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==

# The reverse of this function is pretty much the same:

echo base64_decode('VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==');
// This is an encoded string

str_rot13

Sometimes you’ll see people use str_rot13(); at some point during their process. This really just “shifts every letter by 13 places in the alphabet while leaving non-alpha characters untouched”. So … using str_rot13() on the string that’s already had it used on it, produces the original string.

$a = 'this is a string';
$b = str_rot13($a);
$c = str_rot13($b);

echo $b; // guvf vf n fgevat
echo $c; // this is a string

gzinflate

Now a lot of times, they like to go a step further and use gzdeflate(); because base64_encode(); produces a lot more code than the original, so it will shrink the size of the original code inside before sent to base64_encode(). gzdeflate() uses the DEFLATE data format to make the encoded string quite a bit smaller.

$a = 'this is a long, long, long, string that just seems to keep on going forever and ever and ever ...';
$b = gzdeflate($a);
$c = gzinflate($b);

echo $b;
// lots of unreadable characters
// 67 characters

echo $c;
// this is a long, long, long, string that just seems to keep on going forever and ever and ever ...
// 97 characters

Methodology

The first thing I do when I see some obscenely long, obfuscated code somewhere is look how they convert their encoded string to actual php code. This most simplistic one you’ll find would probably look something like this:

$str = 'PctOCoMwEEDRtYHcbhDBbYZ3vVU30zgxgZgJ46RdlN692bTwSg/+vJZDrBlj6V80CsHGMe9j8k7g+CgpOkfa4NTqPQQS6q/W+JqdU87wVSj7cmtB8Lamu1DCf9hAVatxQ6nUro815AL/Jpyarbcv';
eval(gzinflate(str_rot13(base64_decode($str))));

To retrieve the original code out of this you just have to change the eval() to echo() instead. But since the string might have some tags in it, I usually use htmlentities() as well.

$str = 'PctOCoMwEEDRtYHcbhDBbYZ3vVU30zgxgZgJ46RdlN692bTwSg/+vJZDrBlj6V80CsHGMe9j8k7g+CgpOkfa4NTqPQQS6q/W+JqdU87wVSj7cmtB8Lamu1DCf9hAVatxQ6nUro815AL/Jpyarbcv';

//eval(gzinflate(str_rot13(base64_decode($str))));
echo(htmlentities(gzinflate(str_rot13(base64_decode($str)))));
// <?php $a="we're doing some complicated stuff here"; function blarg($v) { /* do stuff here */ return $v; } echo blarg($a); ?>

Assuming the encoding hasn’t been iterated over and over again, it should be pretty easy to view the code inside by taking apart how they undo it themselves. Sometimes it’s a bit more in depth and complicated than others, but the end result is just a hair bit of observation

PS.

eval is one letter away from evil