检测混淆PHP函数调用的正则表达式：挑战与策略

本文深入探讨了使用正则表达式检测混淆php函数调调用的复杂性，特别是那些通过字符串拼接（如`gzinflate(base64_decode(`）进行片段化的函数。文章阐述了简单正则表达式的局限性，提出了处理常见拼接模式的策略，并强调了为实现稳健检测而采用高级技术或外部工具的必要性。

PHP字符串混淆的挑战

在安全分析和恶意代码检测中，识别PHP代码中被混淆的函数调用是一个常见但复杂的任务。攻击者经常使用字符串拼接技术来隐藏恶意函数（如eval、gzinflate、base64_decode等），以规避静态分析工具和简单的正则表达式匹配。

例如，一个原本清晰的函数调用：

eval("gzinflate(base64_decode(\$data));");

可能被混淆成以下形式：

eval("\$x=gzin"."flate(base"."64_de"."code(\$data));");

在这种情况下，简单的正则表达式如gzinflate\(base64_decode\(将无法匹配，因为函数名被拆分成多个部分，并通过点号(.)运算符进行拼接。这种碎片化方式使得传统的模式匹配变得极其困难。

立即学习“PHP免费学习笔记（深入）”；

理解PHP字符串拼接机制

PHP提供了多种字符串拼接方式，其中最常见的是使用点号（.）运算符。此外，字符串还可以通过数组implode()函数、变量插值等方式动态构建。理解这些机制对于设计有效的检测策略至关重要。

例如，以下PHP代码片段展示了如何通过implode()函数将字符串片段组合起来，这正是攻击者常用来混淆代码的方式：

<?php
$array = ["\$x=gzin", "flate(base", "64_de", "code(\$data))"];
$str = implode($array);

// $str 现在包含: $x=gzinflate(base64_decode($data))
eval($str); // 最终执行混淆前的代码
?>

这个例子虽然不是直接的正则表达式解决方案，但它揭示了混淆的本质：在代码执行前，碎片化的字符串会被重构成完整的函数名。这意味着，静态分析工具需要能够识别这些碎片以及它们之间的潜在连接方式。

针对碎片化字符串的正则表达式策略

面对字符串混淆，纯粹的正则表达式方法面临挑战。在寻求“更好的解决方案”时，我们需要在匹配的特异性（避免误报）和覆盖率（避免漏报）之间取得平衡。

策略一：匹配已知片段与灵活连接符

对于目标函数名（如gzinflate和base64_decode），我们可以识别其常见的碎片化模式，并设计一个能够容忍这些碎片之间存在连接符的正则表达式。一个灵活的连接符模式可以匹配点号（.）运算符，以及可能存在的引号（"）和空白字符（\s）。

NoCode

美团推出的零代码应用生成平台

180

查看详情

我们可以定义一个通用连接符模式来匹配.、"."、" . "等形式： (?:"?\s*\.\s*"?)

• "?: 匹配可选的双引号。
• \s*: 匹配可选的空白字符。
• \.: 匹配字面意义的点号（PHP的拼接运算符）。
• \s*: 匹配可选的空白字符。
• "?: 匹配可选的双引号。
• (?:...): 非捕获组，用于将模式组合在一起。

现在，我们可以用这个连接符来构建匹配gzinflate和base64_decode的正则表达式：

1. 匹配 gzinflate： 如果gzinflate可能被分成gzin和flate，则模式为： gzin(?:"?\s*\.\s*"?)flate

2. 匹配 base64_decode： 如果base64_decode可能被分成base、64_de和code，则模式为： base(?:"?\s*\.\s*"?)64_de(?:"?\s*\.\s*"?)code

3. 组合完整函数调用： 将这两个部分组合起来，匹配gzinflate(base64_decode(： (gzin(?:"?\s*\.\s*"?)flate)\((base(?:"?\s*\.\s*"?)64_de(?:"?\s*\.\s*"?)code)\(

示例代码：

注意事项： 这种策略的局限性在于，它仍然依赖于对碎片化模式的预知。如果攻击者使用不同的碎片化方式（例如，将gzinflate拆分成g、z、i、n、f、l、a、t、e九个部分），则上述模式将失效。

策略二：字符级可选连接符（权衡与取舍）

虽然提问者希望避免“在每个字母后都匹配"."”，但在某些极端情况下，为了最大化覆盖率，可能需要采用更细粒度的匹配方式。例如，匹配gzinflate可以写成：

g(?:"?\s*\.\s*"?)z(?:"?\s*\.\s*"?)i(?:"?\s*\.\s*"?)n(?:"?\s*\.\s*"?)f(?:"?\s*\.\s*"?)l(?:"?\s*\.\s*"?)a(?:"?\s*\.\s*"?)t(?:"?\s*\.\s*"?)e

这种模式理论上可以匹配任意字符级的碎片化，但它的缺点显而易见：

• 复杂性高： 正则表达式冗长且难以维护。
• 性能开销大： 更多的可选匹配会增加正则表达式引擎的负担。
• 误报风险： 过于宽松的模式可能匹配到不相关的代码。

因此，这种方法通常被视为最后的手段，且需要仔细评估其带来的负面影响。

纯正则表达式的局限性

尽管正则表达式在模式匹配方面功能强大，但在面对高级PHP混淆时，它有其固有的局限性：

1. 动态字符串构建： 正则表达式无法执行PHP代码。如果函数名是通过复杂的逻辑（如循环、条件语句、数学运算）动态构建的，正则表达式将无法预判最终的字符串值。
2. 变量混淆： 函数名可能被存储在变量中，例如$func = 'gzinflate'; $func($data);。正则表达式很难追踪变量的赋值和使用。
3. 控制流混淆： 恶意代码的执行路径可能被混淆，使得静态分析难以确定哪些代码会被实际执行。

超越正则表达式：高级检测技术

为了更有效地检测混淆的PHP代码，通常需要结合使用更高级的分析技术：

1. Yara规则： Yara是一种用于识别恶意软件家族的模式匹配工具。虽然Yara规则本身也使用字符串和正则表达式，但它允许通过逻辑运算符（and、or）组合多个规则和字符串，从而实现更复杂的检测逻辑。例如，可以创建多个规则来分别匹配gzinflate和base64_decode的碎片，然后用逻辑and将它们组合起来，并结合proximity（接近度）检查，确保这些碎片在代码中彼此靠近。

   rule php_obfuscation_gzinflate_base64 {
     strings:
       $s_gzin = "gzin" nocase
       $s_flate = "flate" nocase
       $s_base = "base" nocase
       $s_64_de = "64_de" nocase
       $s_code = "code" nocase
       $re_gzinflate = /gzin(?:"?\s*\.\s*"?)flate/ nocase
       $re_base64_decode = /base(?:"?\s*\.\s*"?)64_de(?:"?\s*\.\s*"?)code/ nocase
   
     condition:
       // 尝试匹配完整的正则表达式
       ($re_gzinflate and $re_base64_decode) or
       // 或者，匹配所有碎片，并确保它们在一定范围内出现
       (all of ($s_gzin, $s_flate, $s_base, $s_64_de, $s_code) and
        // 检查碎片之间的相对位置，例如，所有碎片都在文件的前500字节内
        #s_gzin < 500 and #s_flate < 500 and #s_base < 500 and #s_64_de < 500 and #s_code < 500 and
        // 更复杂的接近度检查可能需要外部脚本或更精细的Yara规则
        // 例如，确保s_flate在s_

   登录后复制

以上就是检测混淆PHP函数调用的正则表达式：挑战与策略的详细内容，更多请关注php中文网其它相关文章！