Scrambled names for classes are not case-sensitive

[sedimentation-fault]

Consider the following three PHP files:

a.php:

<?php

 include_once("b.php");
 include_once(CLASS_XXX);

 echo 'hello world'.'<br>';

 $thisColorSchemeLineItemSimpleSearchInfo = new colorSchemeLineItemSimpleSearchInfo();

?>

b.php:

<?php

  define("CLASS_XXX",'class_xxx.php');

?>

class_xxx.php:

<?php
        class colorSchemeLineItemSimpleSearchInfo extends lineItem
        {
                var $colorScheme;
    }
?>

Putting them all inside a common directory test-yakpro-po and obfuscating with:

yakpro-po test-yakpro-po -o test-yakpro-po-obf

results in three obfuscated files. The yakpro-po.cnf used contains 'CLASS' in its $conf->t_ignore_constantsprefix array, so that the constant CLASS_XXX is not obfuscated and thus the inclusion of _classxxx.php should work. So far, so good.

The obfuscated files look like this:

a.php:

<?php
/*   __________________________________________________
    |  Obfuscated by YAK Pro - Php Obfuscator  2.0.12  |
    |              on 2020-07-01 22:15:04              |
    |    GitHub: https://github.com/pk-fr/yakpro-po    |
    |__________________________________________________|
*/

include_once "\142\56\x70\150\x70";
include_once CLASS_XXX;
echo "\150\145\x6c\154\157\x20\x77\x6f\162\x6c\x64" . "\74\142\x72\76";
$LJMmF = new npWpq();

b.php:

<?php
/*   __________________________________________________
    |  Obfuscated by YAK Pro - Php Obfuscator  2.0.12  |
    |              on 2020-07-01 22:15:04              |
    |    GitHub: https://github.com/pk-fr/yakpro-po    |
    |__________________________________________________|
*/

define("\103\x4c\101\x53\x53\x5f\x58\130\x58", "\x63\x6c\141\x73\x73\x5f\x78\x78\x78\56\160\x68\x70");

class_xxx.php:

<?php
/*   __________________________________________________
    |  Obfuscated by YAK Pro - Php Obfuscator  2.0.12  |
    |              on 2020-07-01 22:15:04              |
    |    GitHub: https://github.com/pk-fr/yakpro-po    |
    |__________________________________________________|
*/

class nPWpQ extends AQejL
{
    var $JVlii;
}

You can see that, although

class nPWpQ

in _classxxx.php and

$LJMmF = new npWpq();

in a.php seem to use 'the same' obfuscated string, the strings are NOT the same - they differ in case! I don't know where the rest of the world uses PHP (Windows?), but on my Linux system

nPWpQ != npWpq

and this has been so pretty much all the time...

This is a clear bug.

Looking inside the _yakpro-po/context/function_orclass file that can be found inside the obfuscated directory, I see that both names are 'stored' under the same, all-low-case key npwpq:

a:5:{i:0;s:3:"1.1";i:1;a:2:{s:35:"colorschemelineitemsimplesearchinfo";s:5:"npwpq";s:8:"lineitem";s:5:"aqejl";}i:2;a:2:{s:5:"npwpq";s:35:"colorschemelineitemsimplesearchinfo";s:5:"aqejl";s:8:"lineitem";}i:3;i:5;i:4;i:0;}

It looks as if the obfuscator does not pay attention to case and subsumes all instances of 'npwpq', in capital or small letters and in all possible combinations, under the same small-letter key npwpq.

I did not find any setting that allows case-sensitive obfuscations.

This bug is very important and should be rectified with high priority, if I may suggest. It renders class name obfuscation useless, at least on Linux.

[pk-fr]

This is not a bug! refer to php documentation!

• case-sensitive: variable names, constant name, array keys, class properties, labels
• case-insensitive: function names, class names, class method names, namespaces, keywords and constructs, classes, interfaces, traits

yakrpo-po takes it into account and randomizes cases for case-insensitive objects for better obfuscation!

[sedimentation-fault]

After some searching, I realized that class names in PHP are case-insensitive, so it should not matter how ones writes them, in any combination of small/capital letters. :astonished:

Thus, you may disregard this 'bug' - it is none.

The reason why I get

Uncaught Error: Class 'BQYtu' not found

in my real project on a line like

$gZwln = new BQYtu();

is thus NOT the fact that the class is defined as

class bQyTu extends Ga6T3

but it must be something else...

[sedimentation-fault]

...and just now I saw you comment @pk-fr , where you already said it. I'm sorry, I'm overworked...