Introduction#
The Dimensional Card supports third-party developers to develop plugins to enrich website functionality, and can set plugin fees to generate revenue. The main restriction of plugins is that if the plugin is not purchased, it cannot be installed from the store. Even if the plugin is obtained by some means and manually installed, it cannot be enabled. If the developer's own plugin is not listed, it cannot be used.
Analysis#
The initialization of the plugin can be seen in /kernel/kernel.php. The plugins are scanned first, and then the initialization function is called.
// Plugin library
if (\Kernel\Util\Context::get(\Kernel\Consts\Base::STORE_STATUS) && \Kernel\Util\Context::get(\Kernel\Consts\Base::IS_INSTALL)) {
require("Plugin.php");
// Plugin initialization
\Kernel\Util\Plugin::scan();
Initialize();
// Plugin initialization
hook(\App\Consts\Hook::KERNEL_INIT);
}
The key lies in this Plugin.php file.
After opening the file, it is found that the file is encrypted, so one approach is to decrypt the file and modify the related detection code.
Pitfalls#
This file uses Z5 encryption. It is a PHP encryption scheme introduced by the Z-Blog application center and the only encryption scheme supported by the Z-Blog application center.
Decryption is quite difficult.
After various processing, the code becomes human-readable, and it is found that this is a virtual machine written in PHP. The real code is converted into virtual machine code and then executed in the virtual machine. To obtain the original code, reverse engineering of the virtual machine is required, which is very difficult.
Approach#
After being troubled by the decrypted code for several days, a flash of inspiration came during a nap today. Why not try to refactor the plugin system?
At first, this idea seemed unrealistic because refactoring the plugin system requires a lot of work. So let's start by analyzing the original plugin system.
After analysis, it was found that the plugin system mainly relies on the hook mechanism to implement plugin functionality through registering and triggering hook functions.
In /kernel/Util/Plugin.php, I found the complete functions for registering hooks and triggering hooks, and they are not encrypted, which made me excited.
At first, I tried to delete the Initialize(); function and found that illegal plugins can be enabled normally, but cannot be triggered by hooks.
Continuing to analyze the hook function
public static function hook(int $point, mixed &...$args)
{
if (Context::get(\Kernel\Consts\Base::STORE_STATUS) && \Kernel\Util\Context::get(\Kernel\Consts\Base::IS_INSTALL)) {
$list = _Point($point);
foreach ($list as $item) {
$instance = _Instance($item);
$ref = new \ReflectionClass($instance);
$reflectionProperties = $ref->getProperties();
foreach ($reflectionProperties as $property) {
$reflectionProperty = new \ReflectionProperty($instance, $property->getName());
$reflectionPropertiesAttributes = $reflectionProperty->getAttributes();
foreach ($reflectionPropertiesAttributes as $reflectionAttribute) {
$ins = $reflectionAttribute->newInstance();
if ($ins instanceof \Kernel\Annotation\Inject) {
di($instance);
}
}
}
$result = call_user_func_array([$instance, $item['method']], $args);
if ($result) {
return $result;
}
}
}
}
Suddenly, it was found that the function _Point($point) for obtaining hook functions by key value is defined in the previous encrypted file. By directly using var_dump to obtain the return value, and then modifying it according to the format, it is possible to bypass it.
Crack#
Modify the hook function in /kernel/Util/Plugin.php as shown below to enable illegal plugins.
public static function hook(int $point, mixed &...$args)
{
if (Context::get(\Kernel\Consts\Base::STORE_STATUS) && \Kernel\Util\Context::get(\Kernel\Consts\Base::IS_INSTALL)) {
//$list = _Point($point);
$list = Plugin::$container['hook'][$point];
//var_dump($list,$point);
foreach ($list as $item) {
$instance = _Instance($item);
$ref = new \ReflectionClass($instance);
$reflectionProperties = $ref->getProperties();
foreach ($reflectionProperties as $property) {
$reflectionProperty = new \ReflectionProperty($instance, $property->getName());
$reflectionPropertiesAttributes = $reflectionProperty->getAttributes();
foreach ($reflectionPropertiesAttributes as $reflectionAttribute) {
$ins = $reflectionAttribute->newInstance();
if ($ins instanceof \Kernel\Annotation\Inject) {
di($instance);
}
}
}
$result = call_user_func_array([$instance, $item['method']], $args);
if ($result) {
return $result;
}
}
}
}
It is also recommended to delete the /kernel/Plugin.php file and remove the following lines in /kernel/kernel.php
if (\Kernel\Util\Context::get(\Kernel\Consts\Base::STORE_STATUS) && \Kernel\Util\Context::get(\Kernel\Consts\Base::IS_INSTALL)) {
//require("Plugin.php");//Delete this line
// Plugin initialization
\Kernel\Util\Plugin::scan();
//Initialize();Delete this line
// Plugin initialization
hook(\App\Consts\Hook::KERNEL_INIT);
}
Others#
It is recommended not to use the Dimensional Card as there are quite a few vulnerabilities. I have several undisclosed vulnerabilities in my hands. Smart people will definitely discover these vulnerabilities in the future, so for the sake of card security, please stop using the Dimensional Card.
If you firmly believe that the Dimensional Card has no vulnerabilities, don't argue with me, just continue to use it
As for whether there are other mechanisms to prevent plugin theft, I am not sure, but testing here has been successful, and plugins still need to be borrowed from others.