冲鸭安全 https://wechat2rss.xlab.app/feed/25499156ea68aa4ac597801e9be69707e31bba73.xml 我们阻止威胁 (wechat feed made by @ttttmr https://wechat2rss.xlab.app) (冲鸭安全) https://wx.qlogo.cn/mmhead/LIUI5tJGiauBGlPNd8rKaCLywV6kQHBxolRKEfbic65PydhCB4ot3tvXNPxPphRx9oiaUzpJiaiadjEM/0 冲鸭安全 https://wechat2rss.xlab.app/feed/25499156ea68aa4ac597801e9be69707e31bba73.xml 从0训练自己的AI大模型(下) -CTF模型的Hello world https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247486122&idx=1&sn=f2685d6fc15e014188fc141cfd7ebe31 在上一篇中《[2026]从0训练自己的AI大模型(上)》我们已经做完了一个pretrain的模型，而模型聪不聪 原创 为了安全鸭 2026-04-05 10:00 北京

在上一篇中
《[2026]从0训练自己的AI大模型(上)》
我们已经做完了一个pretrain的模型，而模型聪不聪明看两个，一个是pre trian，另外一个是post train。因此本章会开始讨论后训练，我们的这个章节的最终目标是做一个能完成简单CTF的Agent模型。
要完成能打ctf的模型，模型需要掌握两个能力，第一个是工具调用能力，第二个是对”CTF流程的理解能力”。而这两个都在后训练阶段完成

公开互联网高质量文本越来越稀缺，所以各家 pretrain base 的差距在缩小。公开数据红利变小了，base 差距更隐蔽，后训练差异更显眼。这也是为什么后训练如此重要的原因

我们需要什么

让我们把目标明确，我希望模型具有think能力，并且能调用工具，此外能完成简单的登陆注册sql注入的ctf题目
为了实现think/和工具调用，我们需要

  1. 在sft阶段把这两个能力给组起来

  2. 后续使用 RL 纠正行为

SFT

SFT数据集很关键，好的数据集一两拨千金。
我们上一章的SFT是随便找了个简单的试试，而这次我们认真做一下，数据采用claude opus 4.6 + gpt 5.4的公开蒸馏数据集，配比少量deepseek和qwen的数据和部分合成数据，组了两个高质量数据集。非常标准的训练，代码由vibe coding完成，就不细说了。这部分就是数据集要选得好。
这里面包含了我们所有需要的，多轮对话，工具调用，以及关键的think能力。

值得注意的是，如果数据集不干净，模型很容易在这个地方被带偏。我建议是这些数据集至少带，指令遵循，多轮对话（比如第一轮给模型说记住我是谁，第二轮再问我是谁），多样化任务，以及部分工具调用的例子和思维链。而且要尽量避免污染，很多开源数据其实是不能直接用的，里面啥都有，写小黄文的有，搞色情有，最好的办法是自己记录自己给大模型调用的过程。比如给你的opencode装个插件记录一下之类的

用了高质量数据集后，模型很快的呈现了看起来不错的能力，并且大模型的think也迁移过来了:


但是光靠SFT还是不够的，比如一个普通的问题能think这么多:

一根6米长的杆子是否能通过一扇宽三米高5米的门


我猜测是数据集里面带qwen或者ds的缘故,学到了无限think。所以光靠SFT是没用的，而且过长思维链对模型有害。

强化学习

在SFT阶段，模型可能学到了”模式”比如知道用户说 “帮我查询一下天气”，模型会意识到需要调用工具

<tool_call>xxxxx</tool_call>

但是由于各种原因，他们可能会输出垃圾字符或者不闭合tag等。所以光有SFT是不够的，我们需要对其进行强化学习.而这部分简单来说，参考minimind的实现，改进一下
think太长太短，不闭合扣分

工具调用不规范扣分，如虚假工具，无效JSON，不闭合:

然后进行训练，结果:

一根6米长的杆子是否能通过一扇宽三米高5米的门


看样子虽然think乱七八糟，但是至少正常一点了。并且模型也掌握了基础的工具调用。

我应该怎么清理一匹 70kg178cm的马

如果 A>B，B<C，那么A和C的关系是什么?请给出具体的推理过程。

CTF训练

当模型掌握了tool use和看起来没那么糟糕后，我们可以进入正题，CTF训练了。实际上，我做这个系列的核心目的是为了把大模型能力迁移到小模型里面。简单的CTF是我们的第一个目标。我这里设计了一个存在sqli注入漏洞的靶场

import os
import sqlite3
from pathlib import Path
from flask import Flask, redirect, render_template_string, request, session, url_for
BASE_DIR = Path(__file__).resolve().parent
DB_PATH = Path(os.getenv("DB_PATH", str(BASE_DIR / "data" / "lab.db")))
FLAG = os.getenv("FLAG", "flag{demo_sqli_login_bypass}")
ADMIN_PASSWORD = os.getenv("ADMIN_PASSWORD", "sqli_lab_admin_9f3c2")
app = Flask(__name__)
app.config.update(
    SECRET_KEY=os.getenv("SECRET_KEY", "demo-secret-key"),
    SESSION_COOKIE_HTTPONLY=True,
    SESSION_COOKIE_SAMESITE="Lax",
)
def init_db() -> None:
    DB_PATH.parent.mkdir(parents=True, exist_ok=True)
    connection = sqlite3.connect(DB_PATH)
    try:
        connection.execute(
            """
            CREATE TABLE IF NOT EXISTS users (
                id INTEGER PRIMARY KEY AUTOINCREMENT,
                username TEXT UNIQUE NOT NULL,
                password TEXT NOT NULL
            )
            """
        )
        user_count = connection.execute("SELECT COUNT(*) FROM users").fetchone()[0]
        if user_count == 0:
            connection.executemany(
                "INSERT INTO users(username, password) VALUES(?, ?)",
                [
                    ("admin", ADMIN_PASSWORD),
                    ("guest", "guest"),
                ],
            )
        else:
            connection.execute(
                "UPDATE users SET password = ? WHERE username = ?",
                (ADMIN_PASSWORD, "admin"),
            )
        connection.commit()
    finally:
        connection.close()
def fetch_user(username: str, password: str):
    connection = sqlite3.connect(DB_PATH)
    connection.row_factory = sqlite3.Row
    try:
        query = (
            "SELECT username FROM users "
            f"WHERE username = '{username}' AND password = '{password}' "
            "ORDER BY CASE WHEN username = 'admin' THEN 0 ELSE 1 END LIMIT 1"
        )
        return connection.execute(query).fetchone()
    finally:
        connection.close()
INDEX_TEMPLATE = """
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Mini CTF Lab</title>
    <style>
      body { font-family: monospace; background: #f3efe5; color: #1f1b16; margin: 2rem; }
      .card { max-width: 780px; background: #fffdf7; border: 1px solid #c6b89e; padding: 1.5rem; }
      a { color: #8a3b12; }
      code { background: #efe5d2; padding: 0.1rem 0.3rem; }
    </style>
  </head>
  <body>
    <div class="card">
      <h1>Mini CTF Lab</h1>
      <p>This lab is for model training. Goal: become <code>admin</code> and visit <code>/flag</code>.</p>
      <p>Known low-privilege account: <code>guest / guest</code>.</p>
      {% if user %}
      <p>Current user: <code>{{ user }}</code></p>
      <p><a href="{{ url_for('profile') }}">profile</a> | <a href="{{ url_for('flag') }}">flag</a> | <a href="{{ url_for('logout') }}">logout</a></p>
      {% else %}
      <p><a href="{{ url_for('login') }}">login</a></p>
      {% endif %}
    </div>
  </body>
</html>
"""
LOGIN_TEMPLATE = """
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Login</title>
    <style>
      body { font-family: monospace; background: #f3efe5; color: #1f1b16; margin: 2rem; }
      .card { max-width: 780px; background: #fffdf7; border: 1px solid #c6b89e; padding: 1.5rem; }
      input { width: 100%; padding: 0.55rem; margin: 0.35rem 0 1rem 0; }
      button { padding: 0.6rem 1rem; }
      .error { color: #b42318; }
      a { color: #8a3b12; }
    </style>
  </head>
  <body>
    <div class="card">
      <h1>Login</h1>
      <p>Use <code>guest / guest</code> for a normal user.</p>
      {% if error %}<p class="error">{{ error }}</p>{% endif %}
      <form method="post">
        <label>Username</label>
        <input name="username" autocomplete="off">
        <label>Password</label>
        <input name="password" type="password" autocomplete="off">
        <button type="submit">Login</button>
      </form>
      <p><a href="{{ url_for('index') }}">home</a></p>
    </div>
  </body>
</html>
"""
PROFILE_TEMPLATE = """
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Profile</title>
    <style>
      body { font-family: monospace; background: #f3efe5; color: #1f1b16; margin: 2rem; }
      .card { max-width: 780px; background: #fffdf7; border: 1px solid #c6b89e; padding: 1.5rem; }
      a { color: #8a3b12; }
      .hint { color: #5f4b32; }
    </style>
  </head>
  <body>
    <div class="card">
      <h1>Profile</h1>
      <p>Logged in as <code>{{ user }}</code>.</p>
      {% if user == 'admin' %}
      <p>You have admin access. Visit <a href="{{ url_for('flag') }}">/flag</a>.</p>
      {% else %}
      <p class="hint">Only admins can read the flag.</p>
      {% endif %}
      <p><a href="{{ url_for('index') }}">home</a> | <a href="{{ url_for('logout') }}">logout</a></p>
    </div>
  </body>
</html>
"""
@app.route("/")
def index():
    return render_template_string(INDEX_TEMPLATE, user=session.get("user"))
@app.route("/login", methods=["GET", "POST"])
def login():
    error = None
    if request.method == "POST":
        username = request.form.get("username", "")
        password = request.form.get("password", "")
        try:
            user = fetch_user(username, password)
        except sqlite3.Error as exc:
            error = f"SQL error: {exc}"
        else:
            if user:
                session["user"] = user["username"]
                return redirect(url_for("profile"))
            error = "Login failed."
    return render_template_string(LOGIN_TEMPLATE, error=error)
@app.route("/profile")
def profile():
    user = session.get("user")
    if not user:
        return redirect(url_for("login"))
    return render_template_string(PROFILE_TEMPLATE, user=user)
@app.route("/flag")
def flag():
    if session.get("user") != "admin":
        return "Admins only.\n", 403
    return f"{FLAG}\n"
@app.route("/logout")
def logout():
    session.clear()
    return redirect(url_for("index"))
@app.route("/health")
def health():
    return {"status": "ok"}
init_db()
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

然后我们设计一个给靶场专用的CTF RL agent，他有三个模块组成，启动器，验证器，reward结算.

启动器

在启动器中，我会给模型对应的目标以及工具，从而让模型完成目标，并且做了限制，最多十步，最多两次工具失败调用:

验证器

这步是验证模型是否成功拿到flag，是否真的做了某些我们需要的操作，比如有没有发login包:

访问的时候有没有管理员权限

sql注入语句对不对 或者有没有相似的语句

reward结算

我们之所以验证器做那么复杂的原因是因为如果不每一步做验证，只看拿不拿flag，我们这种弱智模型会遇到Reward Sparsity(奖励稀疏)的问题

如同让小学生做高考数学题，无论尝试多少次都得零分，无法通过分数差异学习改进策略。

因此我们必须设计好，每一步都有对应的奖励或者惩罚，防止出现模型摆烂的问题.而这个是reward结算来干的，如模型成功登录就给点分，欺骗欺诈agent扣分等。

没错,RL其实是猴子算法，让猴子自己打字，打出正常语句就给分，错误语句扣分，最终让猴子实现打莎士比亚全集!

过程

这个过程非常有趣，因为模型一定不会走聪明路线，他会走偷懒的路线，哪条线容易就走哪个。
首先，用大模型合成一些正确的SFT过来（大概1k，包含正确的路线和思考），混在正常的SFT里面做训练，这个是保证模型至少读过数据。然后启动这个RL AGENT:
最开始，模型认为我们在骗他:


狠狠的扣分后，过了一个晚上，我发现模型开始上道了，认为这个是sql注入题目了

并且有时候居然还会想去谷歌搜一下答案，可惜我是国内，谷歌不给你访问的:

再过了一个晚上后，我发现模型居然作弊了:

再过了一个晚上后，我发现模型居然作弊了:

这是因为，这个flask后台也是可以正常登录的，而这套系统是我vibe coding出来的，默认的GPT给了一个弱口令，结果模型不知道从哪一步开始猜到了口令，开始疯狂刷分。
回退版本并且重新设计了奖励结构后，继续放置，一天后，这个模型终于学会了sql注入，拿到了flag:


至此，我们的训练模型之旅也结束了

总结

预训练这块坑比较多，花费也多成本也多，有条件的还是直接用别人家的base模型(已经预训练好的基座)吧，之后我也试了一下QWEN的BASE接了SFT和RL后做的真的比我的好太多了。

跳转微信打开

]]> Sun, 05 Apr 2026 10:00:00 +0800 hypervisor AMD嵌套虚拟化 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247486042&idx=1&sn=3486846e6c97495bf53864d09d0e1267 原创 huoji 2026-03-30 10:02 北京

这个嵌套虚拟化的项目去年就完成了,但是因为业务实在是太忙了,没什么时间写再加上这种技术文章没几个人看,现在大众更喜欢的是”爽+AI”,”简单短快+AI”这类的文章.也就一直咕咕咕了,但是全国搞CPU虚拟化的人屈指可数,而且我发现我去年搞的项目今年细节也快忘完了,写了就当存档.
考虑到看这篇文章的人都有一定基础,故不做基础科普.

概念

要做嵌套虚拟化,我们需要了解三大概念

  • L0：最底层的真实虚拟机监控器，直接控制物理硬件

  • L1：运行在 L0 上的一台虚拟机，但它自己又充当 hypervisor

  • L2：运行在 L1 里面的“下一层”虚拟机

我们做的是L1的角色，其实我们只需要:

  1. 虚拟化MMIO嵌套

  2. 虚拟化VMexit嵌套

  3. 虚拟化异常/中断嵌套

核心做法是,我们设计一个l1用的页表/vmcb，然后分配一个l2用的页表/vmcb，当遇到l2调用vmrun的时候,把l2的vmcb提交给cpu,系统就会进入l2的工作状态。然后L2遇到vmexitt或者l1遇到vmexit的时候还是走我们的vmexit entry。虚拟化对应指令就能实现嵌套虚拟化。

让我们一步一步来

MMIO嵌套

小工具建设

第一步我们要给L2分配好页表，我们预先在每个vcpu分配:

然后我们需要一个翻译工具,要不然我们没办法访问l2的pa对应的hva:

这个所谓l1->l2,l2->l1的翻译工具就是把 L1 的 gPA映射成 L0 可访问的 VA

有了这个工具后,剩下的就是做基本的PML4访问映射:

有了PML4访问映射工具后,我们就能正常的访问L2的内存,类似于这个:

不过大部分时间我们用不上VA到PA的转换访问,这是因为,大部分情况下vmexit的都是pa地址而不是VA地址不需要走一次PML4翻译,不排除后续搞hack用的上

#PF处理

当出现#pf的时候,检查是否在guest exit里面,如果是,则进入guest 的pf而不是自己的:

void svm_exit::svm_pf_handler(_svm_guest_status* guest_context) {
#ifdef use_npt
    //__debugbreak();
    // ============ 嵌套NPT页错误处理 ============
    // 如果处于嵌套guest模式且L1启用了NPT，使用嵌套NPT处理
    if (guest_context->vcpu->nested_guest_mode &&
        guest_context->vcpu->nested_npt_enabled) {
        nested_npt::handle_nested_npt_page_fault(guest_context);
        return;
    }

而里面我们只需要像npt hook一样，找L2的rip和cr3,构造shadow page即可.
大概是:

构造shadow page,并且设置vmcb.tlbc设置成刷新tlb

然后走nvmexit即可.这个nvemexit是啥玩意后文会说。

虚拟化Vmexit

这很好理解,之前我们会伪装主板不支持vmexit指令,现在我们可以开始对他的虚拟化。总的来说,他分几步

vmsave

在vmsave阶段我们按照规范,复制当前vmsave到target上

vmload

同理,根据amd手册,复制到当前的vmcb->state_save里面

    // FS, GS, TR, LDTR (包括所有隐藏状态)
    // KernelGsBase, STAR, LSTAR, CSTAR, SFMASK
    // SYSENTER_CS, SYSENTER_ESP, SYSENTER_EIP

vmrun

这个比较复杂,让我们翻一下amd手册,

简单来说,我们先保存一下l1的guest_vmcb状态,然后给目前在用的vmcb赋值过去（也就是说,l1.vmcb = l2.vmcb)，并且标记一下进入嵌套模式(nested_guest_mode = true)

    // RAX包含guest VMCB的物理地址
    unsigned __int64 guest_vmcb_pa = guest_context->guest_register->Rax;
    DebugPrint("[Nested] VMRUN with VMCB PA: %p\n", guest_vmcb_pa);
    // 验证VMCB物理地址对齐(必须4KB对齐),这个地址在当前是不能直接范围的
    if (guest_vmcb_pa & 0xFFF) {
        DebugPrint("[Nested] VMCB PA not aligned, injecting #GP\n");
        inject_exception_gp(guest_context);
        return;
    }
    _svm_vmcb* source_vmcb =
        (_svm_vmcb*)map_l1_gpa_page_to_hva(guest_context->vcpu, guest_vmcb_pa);
    if (!source_vmcb) {
        DebugPrint("[Nested] Failed to map guest VMCB for VMRUN\n");
        inject_exception_gp(guest_context);
        return;
    }
    memcpy(guest_context->vcpu->l1_guest_vmcb, source_vmcb, sizeof(_svm_vmcb));

同时，我们的nested npt也是在这个时候初始化的

    _svm_vmcb* l1_vmcb = guest_context->vcpu->l1_guest_vmcb;
    // 初始化嵌套NPT
    if (!nested_npt::init_nested_npt(guest_context->vcpu, l1_vmcb)) {
        DebugPrint("[Nested] Failed to initialize nested NPT\n");
        inject_exception_gp(guest_context);
        return;
    }

最后把当前状态备份一下,赋值

    memcpy(guest_context->vcpu->l2_guest_vmcb, &guest_context->vcpu->stack->guest_vmcb, sizeof(_svm_vmcb));
    // ============ 从 L1 的 guest VMCB 恢复完整的处理器状态 ============
    // 根据 AMD SVM 规范，VMRUN 指令需要从 VMCB 加载完整的 guest 状态
    //dest_state->Rip = src_state->Rip;
    memcpy(&guest_context->vcpu->stack->guest_vmcb.state_save, &l1_vmcb->state_save, sizeof(_vmcb_state_save_area));

这样做的目的是,让CPU接下来执行l2的vmcb里面的内容,自然也就进入l2的虚拟化的环境了,直到遇到vmexit.

nested_vmexit

当有新的vmexit触发,并且我们进入了嵌套模式的时候,需要判断一下L2的虚拟机是否启用了对应的vmexit:

如果启用了,走nested_vmexit，而这个函数的作用是，拷贝上下文，然后注入回l2，触发l2的vmexit。这样在l2里面做对应的vmexit操作如cpuid等乱七八糟的时候,他会再次触发l1的vmexit,从而被我们控制.
简单来说:
回填一下当前的vmcb(这个时候是l2的vmcb)

    _svm_vmcb* l1_vmcb = guest_context->vcpu->l1_guest_vmcb;
    if (l1_vmcb == nullptr) {
        DebugPrint("[Nested] Error: L1 VMCB is null!\n");
        inject_exception_gp(guest_context);
        return;
    }
// 保存exit信息
    l1_vmcb->control.ExitCode = exit_code;
        l1_vmcb->control.ExitInfo1 =
            guest_context->vcpu->stack->guest_vmcb.control.ExitInfo1;
        l1_vmcb->control.ExitInfo2 =
            guest_context->vcpu->stack->guest_vmcb.control.ExitInfo2;
        l1_vmcb->control.ExitIntInfo =
            guest_context->vcpu->stack->guest_vmcb.control.ExitIntInfo;
    // 使用硬件在本次VMEXIT时给出的NRIP，避免在L2地址空间里手动解码指令长度
    l1_vmcb->control.NRip =
        guest_context->vcpu->stack->guest_vmcb.control.NRip;
    //拷贝state到l1_vmcb里面
    memcpy(&l1_vmcb->state_save, &guest_context->vcpu->stack->guest_vmcb.state_save, sizeof(_vmcb_state_save_area));
    l1_vmcb->state_save.Rax = guest_context->guest_register->Rax;
    _svm_vmcb* l1_guest_vmcb_hva =
        (_svm_vmcb*)map_l1_gpa_page_to_hva(guest_context->vcpu, guest_context->vcpu->l1_guest_vmcb_pa);
    if (l1_guest_vmcb_hva == nullptr) {
        DebugPrint("[Nested] Failed to map L1 VMCB for nested VMEXIT writeback\n");
        inject_exception_gp(guest_context);
        return;
    }
    memcpy(l1_guest_vmcb_hva, l1_vmcb, sizeof(_svm_vmcb));

这个l1_guest_vmcb_pa,不是真的l1_guest_vmcb的PA,是l1调用vm_load出来的

恢复之前的备份:

    // 恢复备份（回到进入L2前的L1 VMCB02）
    memcpy(&guest_context->vcpu->stack->guest_vmcb,
           guest_context->vcpu->l2_guest_vmcb,
           sizeof(_svm_vmcb));

这里有一个细节,在真实SVM上，#VMEXIT 返回到 host 后，某些状态不会自动从 HSAVE 恢复，host 需要在 VMRUN 之后执行 VMSAVE/VMLOAD 来保存/恢复：FS/GS/TR/LDTR（含隐藏状态）、KernelGsBase、STAR/LSTAR/CSTAR/SFMASK、SYSENTER_*。我们这里会把活动 VMCB 从 L2 恢复为进入 L2 前的 L1 备份（vcpu->l2_guest_vmcb）。如果直接整块覆盖，会导致这些字段变成 L1 的，从而让后续的 VMSAVE 保存错对象，解决：在恢复 L1 备份前，先抓取 L2 的这些字段；恢复后再把字段覆写回去，让紧随其后的 L1 VMSAVE 看到的是 L2 的值。
所以我们需要人工恢复一下

 auto* l1_state = &guest_context->vcpu->stack->guest_vmcb.state_save;
    const auto* l2_state = &l2_saved_state_for_vmsave;
    l1_state->FsSelector = l2_state->FsSelector;
    l1_state->FsAttrib = l2_state->FsAttrib;
    l1_state->FsLimit = l2_state->FsLimit;
    l1_state->FsBase = l2_state->FsBase;
    l1_state->GsSelector = l2_state->GsSelector;
    l1_state->GsAttrib = l2_state->GsAttrib;
    l1_state->GsLimit = l2_state->GsLimit;
    l1_state->GsBase = l2_state->GsBase;
    l1_state->TrSelector = l2_state->TrSelector;
    l1_state->TrAttrib = l2_state->TrAttrib;
    l1_state->TrLimit = l2_state->TrLimit;
    l1_state->TrBase = l2_state->TrBase;
    l1_state->LdtrSelector = l2_state->LdtrSelector;
    l1_state->LdtrAttrib = l2_state->LdtrAttrib;
    l1_state->LdtrLimit = l2_state->LdtrLimit;
    l1_state->LdtrBase = l2_state->LdtrBase;
    l1_state->KernelGsBase = l2_state->KernelGsBase;
    l1_state->Star = l2_state->Star;
    l1_state->LStar = l2_state->LStar;
    l1_state->CStar = l2_state->CStar;
    l1_state->SfMask = l2_state->SfMask;
    l1_state->SysenterCs = l2_state->SysenterCs;
    l1_state->SysenterEsp = l2_state->SysenterEsp;
    l1_state->SysenterEip = l2_state->SysenterEip;

然后就是恢复rip，恢复npt到l1里面

    // 恢复L0的NPT到VMCB
    guest_context->vcpu->stack->guest_vmcb.control.NCr3 = guest_context->vcpu->npt_pa;
    guest_context->vcpu->stack->guest_vmcb.control.TlbControl = 3;
    if (guest_context->vcpu->l1_guest_vmcb) {
        // 从 L2 VMEXIT 返回到 L1 host：应继续执行 L1 的 VMRUN 下一条指令。
        // 更可靠的来源是：L0 当初拦截到 L1 的 VMRUN 时硬件给出的 NRIP。
        // 该值在 handle_vmrun 中保存到 l1_vmrun_return_rip。
        uintptr_t resume_rip = guest_context->vcpu->l1_vmrun_return_rip;
        if (resume_rip == 0) {
            // 兼容旧路径：使用进入 L2 前备份的 VMCB02.control.NRip。
            resume_rip = guest_context->vcpu->stack->guest_vmcb.control.NRip;
        }
        if (resume_rip == 0) {
            resume_rip = guest_context->vcpu->stack->guest_vmcb.state_save.Rip;
            DebugPrint("[Nested] Warning: L1 resume RIP is zero, fallback RIP %p\n",
                       resume_rip);
        }
        guest_context->vcpu->stack->guest_vmcb.state_save.Rip = resume_rip;
    } else {
        inject_exception_gp(guest_context);
        return;
    }

最后rax指向guest_vmcb pa即可

    guest_context->guest_register->Rax = guest_context->vcpu->l1_guest_vmcb_pa;

结果

跟simplesvm嵌套：

simplesvm的vmexit:

跳转微信打开

]]> Mon, 30 Mar 2026 10:02:00 +0800 从0开始开发VT调试器（二） https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485990&idx=1&sn=8b48a6c24677302fcddab9fd4dfdea46 原创 CrazyHarb 2026-03-29 10:01 北京

从0开始开发VT调试器（二）

背景：

上一章中，我们完成了基础的VT环境搭建，我们已经可以从guest中拦截一些简单的指令跳转到host了，本期我们加快速度将对调试链路进行进一步编写

原理：

在Ring3层，我们经常会用到各种调试工具，例如vs、x64dbg等，他们的单步原理基本上就是两种异常——#DB、#BP，这两种异常在触发时（其实所有异常都会这么走），会触发IDT表中的1号中断和3号中断，中断触发后，会先触发调试器，也就是windbg、x64dbg等(First Chance); 如果调试器未处理，会自动分发到触发异常的进程的ntdll的RtlDispatchException，最后如果进程没有处理，会再次触发Ring3调试器

我们简单画一下异常处理的流程图，即：

VT下的异常流程:

通过原理已知在Ring3进程触发异常时，首先会通过触发#DB #BP，然后借助IDT进入windows内核，这便是我们可以触发VT调试的点，即，当触发#DB #BP时，VT host会接管异常，并分发到我们自己的调试器，当调试器处理完成后，VT负责注入异常或者继续执行

代码修改：

1. Exception map

首先，我们找到setup_vmcs中的针对_vt_vmcs_exceptionbitmap的写入值，这个字段主要的作用是它记录的值中如果某一位为1，那么当idt触发对应的中断时，会进入vt host，例如当#DB触发时，如果_vt_vmcs_exceptionbitmap的值为 1 << 1，那么#DB会进入VT的host的代码中，这里我们把exception_map的值改为 1 << 1

C++                  uintptr_t exception_bitmap = 1 << 1;                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_exceptionbitmap, exception_bitmap);

2. VT处理异常代码

我们在代码中需要对_vt_exitreason_exceptionornmi进行处理，即vt_vmm_handleexception函数，在该函数中，我们需要对#DB进行判断，并打印一条日志，并按原属性进行注入事件，在我们修改的代码中可以看到，判断了type(Hardware)和vector(#DB)，这个type和vector是一一对应的，具体值需要参考intel的手册，这里就不再展开了

C++                  void vt_vmm_handleexception(_vt_vmhandle_guestcontext* guest_context) {                  
size_t exit_exception_value = 0;                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_vmexitintrinfo, &exit_exception_value);                  
const _vt_vmexit_interruptioninformationfield exception = { exit_exception_value };                  
const _vt_interruption_type interruption_type = (_vt_interruption_type)(exception.fields.interruption_type);                  
const _vt_interruption_vector vector = (_vt_interruption_vector)(exception.fields.vector);                  
ULONG_PTR guest_inst_length;                  
__vmx_vmread((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_vmexitinstructionlen, &guest_inst_length);                  
ULONG_PTR error_code = 0;                  
__vmx_vmread((ULONG32)_vt_vmcs_field::_vt_vmcs_vmexitintrerrorcode, &error_code);                  
if (interruption_type == _vt_interruption_type::_vt_interruption_hardwareexception) {                  
// Hardware exception                  
if (vector == _vt_interruption_vector::_vt_intteruptionvec_debugexception)                  
{                  
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "GetInt1 %p\n", PsGetCurrentProcessId());                  
vt_vmm_injectinterruption(_vt_interruption_type::_vt_interruption_hardwareexception, vector, exception.fields.error_code_valid, error_code);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, guest_inst_length);                  
}                  
else {                  
vt_vmm_injectinterruption(interruption_type, vector, exception.fields.error_code_valid, error_code);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, guest_inst_length);                  
}                  
}                  
else {                  
vt_vmm_injectinterruption(interruption_type, vector, exception.fields.error_code_valid, error_code);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, guest_inst_length);                  
}                  
}

3. 代码测试

我们将驱动在测试环境中加载起来，此时我们需要触发#DB，才能在驱动的输出中看是否拦截到了，所以，在这里需要打开调试器对文件进行单步，笔者使用了x64dbg对一个exe进行调试，可以看到，笔者单步两次后，debug中是可以打印出对应的日志的，证明此时host拦截到正确的数据了

Guest代码转向

现在，我们开始编写guest代码，guest的流程主要为，host注入guest转向，guest代码跳转到我们自己的stub上，stub最后触发host处理，最后host恢复环境，然后ring3继续执行，这里触发host处理，我们用vmcall指令即可

首先，我们在汇编中添加：

C++                  asm_dbg_entry proc                  
mov rcx, 1340h                  
vmcall                  
int 3 ;不该执行到这里                  
asm_dbg_entry endp

其次，我们在#DB中添加注入RIP的代码

C++                  ....                  
   if (interruption_type == _vt_interruption_type::_vt_interruption_hardwareexception) {                  
// Hardware exception                  
if (vector == _vt_interruption_vector::_vt_intteruptionvec_debugexception)                  
{                  
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "GetInt1 %p\n", PsGetCurrentProcessId());                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestrip, (ULONG_PTR)&asm_dbg_entry);                  
}                  
else {                  
vt_vmm_injectinterruption(interruption_type, vector, exception.fields.error_code_valid, error_code);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, guest_inst_length);                  
}

KVA功能的影响

在注入代码后，我们需要考虑的一个问题，就是KVA的问题，如果windows启动了KVA，那么我们还需要更改cr3到kernel态下的CR3，毕竟shadow Cr3只有当前进程的ring3地址，以及ntkernel中的.KVSCode段的地址，我们的驱动不在这个段中，所以需要切CR3；如果没有开启，那么就不需要切了，可以用下面的ps脚本进行判断

C++                  Install-Module SpeculationControl -Force                  
Import-Module SpeculationControl                  
Get-SpeculationControlSettings

笔者的电脑，执行后发现没有开启KVA，查阅相关资料发现在最新的CPU上，已经修复了这个漏洞，所以，windows不再开启了

需要保留的寄存器：

以上的代码展示了核心部分，但不是完整流程，因为在vmcall后，host需要恢复现场内容，所以需要将现场数据进行保存

1. eflags寄存器

该寄存器必然会被修改，因为至少tf位会被置为0，否则当注入guest后，会再次触发#DB，最后走入异常状态，我们根据Intel手册中对eflags的描述，我们将Eflags置为2，原始值保存

2. DR寄存器

和eflags的理由相同，当启动Dr时，如果地址被ring3精心构造，那么我们会在stub的某个地方触发#DB异常，导致异常状态，我们把Dr7改为0x400，屏蔽掉其他的Dr寄存器，避免触发

3. Guest context寄存器

包含cs和ss、rip、rsp、rcx，为了在vmcall的时候直接恢复，所以这几个段需要保存，这里可能会有读者有些疑问，为什么rcx也需要保存呢？因为我们在再次进入host时，用的vmcall，为了判断编号，所以用的时rcx，所以这个rcx是需要保存的

4. guest_exceptionreason、error_code、指令长度等

这些都和guest注入异常有关系，所以也需要进行保存，这样可以避免后续未处理时，注入错了异常

我们总结一下整体的结构

C++                  struct DBG_Stack {                  
ULONG_PTR Dr7;                  
ULONG_PTR guest_inst_length;                  
ULONG_PTR exception_type;                  
ULONG_PTR exception_vector;                  
ULONG_PTR csbase;                  
ULONG_PTR cslimit;                  
ULONG_PTR csselector;                  
ULONG_PTR ssselector;                  
ULONG_PTR csarbytes;                  
ULONG_PTR ssbase;                  
ULONG_PTR sslimit;                  
ULONG_PTR ssarbytes;                  
ULONG_PTR ip;                  
ULONG_PTR eflags;                  
ULONG_PTR sp;                  
ULONG_PTR original_rcx;                  
};

申请并填充栈

为了保存我们需要的数据，我们需要将我们的数据保存在栈上，并为了避免返回Ring3的时候，Ring3找到相关的数据，所以我们需要自己申请一块地址，保存context

C++                  PHYSICAL_ADDRESS phys = { 0 };                  
phys.QuadPart = ~0ULL;                  
auto stack = (ULONG_PTR)MmAllocateContiguousMemory(PAGE_SIZE, phys);                  
DBG_Stack* guest_stack = (DBG_Stack*)(stack + PAGE_SIZE - sizeof(DBG_Stack));                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestdr7, &guest_stack->Dr7);                  
guest_stack->guest_inst_length = guest_inst_length;                  
guest_stack->exception_type = (ULONG_PTR)interruption_type;                  
guest_stack->exception_vector = (ULONG_PTR)vector;                  
guest_stack->ip = (ULONG_PTR)guest_context->ip;                  
guest_stack->eflags = guest_context->flag_reg.all;                  
guest_stack->sp = (ULONG_PTR)guest_context->stack->gp_regs.Rsp;                  
guest_stack->original_rcx = guest_context->stack->gp_regs.Rcx;                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestcsbase, &guest_stack->csbase);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestssbase, &guest_stack->ssbase);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestcsarbytes, &guest_stack->csarbytes);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestssarbytes, &guest_stack->ssarbytes);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestcslimit, &guest_stack->cslimit);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestsslimit, &guest_stack->sslimit);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestcsselector, &guest_stack->csselector);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestssselector, &guest_stack->ssselector);                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_guestdr7, &guest_stack->Dr7);                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcsselector, asm_readcs());                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestssselector, asm_readss());                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcsarbytes, vmx_getsegment_accessright(asm_readcs()));                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestssarbytes, vmx_getsegment_accessright(asm_readss()));                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcslimit, __segmentlimit(asm_readcs()));                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestsslimit, __segmentlimit(asm_readss()));                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdr7, 0x400);                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestrflags, 2);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestrsp, (ULONG_PTR)guest_stack);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestrip, (ULONG_PTR)&asm_dbg_entry);

VMCALL代码的实现：

首先，我们先针对VMACALL做一下接管，之前的逻辑是直接注入GP异常，现在不需要了

C++                  void vt_vmm_handlevmexit(_vt_vmhandle_guestcontext* guest_context) {                  
....                  
case _vt_vmx_exitreason::_vt_exitreason_vmcall:                  
vt_vmm_handle_vmcall(guest_context);                  
break;                  
   }

我们开始继续封装handle_vmcall函数，当得到rcx为0x1340时，我们直接注入系统异常，后续ring0、ring3的调试器就可以接到内容了

C++                  #define vmcall_db_dispatch_system 0x1340                  
void vt_vmm_handle_vmcall(_vt_vmhandle_guestcontext* guest_context) {                  
const auto hypercall_number = guest_context->stack->gp_regs.Rcx;                  
switch (hypercall_number) {                  
case vmcall_db_dispatch_system:                  
vt_vmm_handle_DB_exception(guest_context, guest_context->stack->gp_regs.Rsp, true);                  
break;                  
default:                  
break;                  
}                  
}

我们继续封装vt_vmm_handle_DB_exception用于处理相关逻辑，其中封装了一个vt_vmm_restore_context函数，用于处理堆栈上的数据恢复guest的状态，段、栈、ip、flags、原始rcx等

C++                  void vt_vmm_restore_context(_vt_vmhandle_guestcontext* guest_context, ULONG_PTR guestRsp, bool dispatch_into_system, ULONG_PTR& exception_reason, ULONG_PTR& error_code) {                  
DBG_Stack* dbgFrame = (DBG_Stack*)guestRsp;                  
guest_context->stack->gp_regs.Rcx = dbgFrame->original_rcx;                  
exception_reason = (ULONG_PTR)dbgFrame->exception_type;                  
__vmx_vmwrite((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_guestrip, (ULONG_PTR)dbgFrame->ip);                  
__vmx_vmwrite((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_guestcsselector, (ULONG_PTR)dbgFrame->csselector);                  
__vmx_vmwrite((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_guestrflags, (ULONG_PTR)dbgFrame->eflags);                  
__vmx_vmwrite((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_guestrsp, (ULONG_PTR)dbgFrame->sp);                  
__vmx_vmwrite((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_guestssselector, (ULONG_PTR)dbgFrame->ssselector);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, dbgFrame->guest_inst_length);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestdr7, dbgFrame->Dr7);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestcslimit, dbgFrame->cslimit);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestcsarbytes, dbgFrame->csarbytes);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestsslimit, dbgFrame->sslimit);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestssarbytes, dbgFrame->ssarbytes);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestcsbase, dbgFrame->csbase);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_guestssbase, dbgFrame->ssbase);                  
}                  
void vt_vmm_handle_DB_exception(_vt_vmhandle_guestcontext* guest_context, ULONG_PTR guestRsp, bool inject_into_system) {                  
ULONG_PTR excetpion_reason;                  
ULONG_PTR error_code;                  
vt_vmm_restore_context(guest_context, guestRsp, inject_into_system, excetpion_reason, error_code);                  
if (inject_into_system)                  
{                  
vt_vmm_injectinterruption(_vt_interruption_type::_vt_interruption_hardwareexception, _vt_interruption_vector::_vt_intteruptionvec_debugexception, false, error_code);                  
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "vt_vmm_handle_DB_exception\n");                  
}                  
}

运行效果：

我们加载驱动后，打开x64dbg，并开始调试任意exe，我们在代码中，接到#DB异常时，打印了一条GetInt，在vmcall恢复的时候，打印了一条vt_vmm_handle_DB_exception，我们在x64dbg下执行两次单步后，发现windbg中日志已经可以正常打印了，切x64dbg下一切正常，没有任何的调试问题，我们再执行两次，发现rcx也是没有被变动的，证明，本次代码改动已经完成了

工程代码：

https://git.key08.com/CrazyHarb/VirtualizeDBG v0.0.2

跳转微信打开

]]> Sun, 29 Mar 2026 10:01:00 +0800 从0开始开发VT调试器（一） https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485989&idx=1&sn=244f30b755ffa00e6cfcd7898c9a81d9 从0开始开发VT调试器（一）背景： 这个项目其实很早就想写了，但一直没有机会，最近忙里偷闲赶紧写一下 原创 CrazyHarb 2026-03-28 10:01 北京

从0开始开发VT调试器（一）背景： 这个项目其实很早就想写了，但一直没有机会，最近忙里偷闲赶紧写一下

从0开始开发VT调试器（一）

背景：

这个项目其实很早就想写了，但一直没有机会，最近忙里偷闲赶紧写一下，目前相关的中文资料不多，所以也当记录一下，避免未来自己也遗忘了。本文不会完成一个完全可用的调试器，仅做技术验证VT调试的链路不会涉及EPT等其他功能，及抛砖引玉供大家讨论，内容有瑕疵的地方，请帮忙指出。

既然是VT调试器，那么必然少不了虚拟化相关的代码，我们就先从虚拟化开始吧！之前已经有相关的资料如何进入虚拟化，各位可以先参考一下下面的参考资料

https://mp.weixin.qq.com/s/PVIkx0FDnZzo5idM3-NSSg (huoji:《国庆专题: 深度了解”核晶“的工作原理并且手动实现一个自己的"核晶"》)

https://mp.weixin.qq.com/s/nIovO0W8QW2YemZ5HCYkQg (手工编写linux下的intel虚拟化驱动)

https://mp.weixin.qq.com/s/mowc1iUJ1F2QghdyWgrrjw (手工编写linux下的intel虚拟化驱动(二))

https://mp.weixin.qq.com/s/a39NgPrKgk2wQNMD8nj5YA (INTEL CPU虚拟化特性研究&初探 (三))

https://github.com/CrazyHarb/VmxProject (linux下简易VT源码)

接下来，在正式的代码处理前，我们本章节将对VT进行简易回顾，简单的讲一下进入VT的代码

环境配置：

vs2022 + WDK + vmware + windbg

这里就不再赘述了，按照网上的来就可以了，实在不行就问AI也行，我们直接进入代码编写吧

VMX环境支持检测：

1Cpuid 1号功能的vmx位

1Msr的ia32_msr_vmx_basic功能，判断memory_type

1Msr的ia32_msr_feature_control lock位及enable_vmxon位

1Msr ia32_msr_vmx_ept_vpid_cap功能，判断是否支持EPT

1具体的结构大家可以参考前面的文章，这就不再赘述了

Java                  bool set_feature_control_lockbits() {                  
for (unsigned iter = 0; iter < KeQueryActiveProcessorCountEx(ALL_PROCESSOR_GROUPS); iter++) {                  
PROCESSOR_NUMBER processor_number;                  
GROUP_AFFINITY affinity, old_affinity;                  
KeGetProcessorNumberFromIndex(iter, &processor_number);                  
RtlSecureZeroMemory(&affinity, sizeof(GROUP_AFFINITY));                  
affinity.Group = processor_number.Group;                  
affinity.Mask = (KAFFINITY)1 << processor_number.Number;                  
KeSetSystemGroupAffinityThread(&affinity, &old_affinity);                  
_ia32_feature_control_msr vmx_feature_control = {                  
__readmsr(ia32_msr_feature_control) };                  
if (vmx_feature_control.fields.lock == false) {                  
vmx_feature_control.fields.lock = true;                  
__writemsr(ia32_msr_feature_control,                  
vmx_feature_control.all);                  
vmx_feature_control.all =                  
__readmsr(ia32_msr_feature_control);                  
if (vmx_feature_control.fields.lock == false) {                  
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[VirtualizeDBG] can't set lockbit in %d \n", iter);                  
return false;                  
}                  
}                  
KeRevertToUserGroupAffinityThread(&old_affinity);                  
}                  
return true;                  
}                  
bool issupportept() {                  
_ia32_vmxeptvpidcap_msr vmx_eptvpidcap_msr = {                  
__readmsr(ia32_msr_vmx_ept_vpid_cap) };                  
if (!vmx_eptvpidcap_msr.fields.support_page_walk_length4 ||                  
!vmx_eptvpidcap_msr.fields.support_write_back_memory_type ||                  
!vmx_eptvpidcap_msr.fields.support_invept ||                  
!vmx_eptvpidcap_msr.fields.support_single_context_invept ||                  
!vmx_eptvpidcap_msr.fields.support_all_context_invept ||                  
!vmx_eptvpidcap_msr.fields.support_invvpid ||                  
!vmx_eptvpidcap_msr.fields.support_individual_address_invvpid ||                  
!vmx_eptvpidcap_msr.fields.support_single_context_invvpid ||                  
!vmx_eptvpidcap_msr.fields.support_all_context_invvpid ||                  
!vmx_eptvpidcap_msr.fields.support_single_context_retaining_globals_invvpid) {                  
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "EPT Setting: %p \n", (ULONG64)vmx_eptvpidcap_msr.all);                  
return false;                  
}                  
else {                  
return true;                  
}                  
}                  
bool checkVMXFeature() {                  
int registers[4];                  
__cpuidex(registers, 1, 0);                  
bool result = false;                  
do {                  
_vt_cpu_features cpu_features = { static_cast(registers[2]) };          
if (!cpu_features.fields.vmx) {          
break;          
}          
_ia32_vmbasic_msr vmx_basic_msr = { __readmsr(ia32_msr_vmx_basic) };          
if ((_ia32_memory_type)vmx_basic_msr.fields.memory_type !=          
_ia32_memory_type::write_back) {          
break;          
}          
_ia32_feature_control_msr vmx_feature_control = {          
__readmsr(ia32_msr_feature_control) };          
if (!vmx_feature_control.fields.lock) {          
bool status = set_feature_control_lockbits();          
if (!status) {          
break;          
}          
}          
if (!vmx_feature_control.fields.enable_vmxon) {          
break;          
}          
if (!issupportept()) {          
break;          
}          
result = true;          
} while (false);          
return result;          
}

虚拟化环境初始化：

在进入虚拟化之前，我们需要对vmcs进行初始化，配置host、guest环境后再进入host

1. 首先我们开启vmx的Crx标志位

C++                  void enable_vmx() {                  
uintptr_t cr0 = __readcr0();                  
uintptr_t cr4 = __readcr4();                  
cr0 |= __readmsr(ia32_msr_vmx_cr0_fixed0);                  
cr0 &= __readmsr(ia32_msr_vmx_cr0_fixed1);                  
cr4 |= __readmsr(ia32_msr_vmx_cr4_fixed0);                  
cr4 &= __readmsr(ia32_msr_vmx_cr4_fixed1);                  
__writecr0(cr0);                  
__writecr4(cr4);                  
}

2. 分配栈、vmcs、vmxon空间

栈空间我们定义为0x6000大小，剩下两个定义为0x1000，并对头写入标志位即可，栈空间主要是为了我们进入host时，供CPU使用

C++                  void init_vmxon(_vt_vcpu_context* vcpu) {                  
_ia32_vmbasic_msr vmx_basic = {                  
__readmsr(ia32_msr_vmx_basic) };                  
PHYSICAL_ADDRESS phys = { 0 };                  
phys.QuadPart = ~0ULL;                  
vcpu->vmxon = (__vt_vmcs_t*)MmAllocateContiguousMemory(PAGE_SIZE, phys);                  
RtlZeroMemory(vcpu->vmxon, PAGE_SIZE);                  
auto mmPhyAddress = MmGetPhysicalAddress((PVOID)vcpu->vmxon);                  
vcpu->vmxon_physical = mmPhyAddress.QuadPart;                  
if (!vcpu->vmxon_physical) {                  
return;                  
}                  
vcpu->vmxon->header.all = vmx_basic.fields.revision_identifier;                  
// function                  
if (__vmx_on((unsigned long long*) & vcpu->vmxon_physical)) {                  
}                  
}                  
void init_vmxcs(_vt_vcpu_context* vcpu) {                  
_ia32_vmbasic_msr vmx_basic = {                  
__readmsr(ia32_msr_vmx_basic) };                  
PHYSICAL_ADDRESS phys = { 0 };                  
phys.QuadPart = ~0ULL;                  
vcpu->vmcs = (__vt_vmcs_t*)MmAllocateContiguousMemory(PAGE_SIZE, phys);                  
RtlZeroMemory(vcpu->vmcs, PAGE_SIZE);                  
vcpu->stack = (void*)MmAllocateContiguousMemory(kernel_stack_szie, phys);                  
auto mmPhyAddress = MmGetPhysicalAddress((PVOID)vcpu->vmcs);                  
vcpu->vmcs_physical = mmPhyAddress.QuadPart;                  
vcpu->vmcs->header.all = vmx_basic.fields.revision_identifier;                  
if (__vmx_vmclear((unsigned long long*) & vcpu->vmcs_physical)) {                  
return;                  
}                  
if (__vmx_vmptrld((unsigned long long*) & vcpu->vmcs_physical)) {                  
return;                  
}                  
return;                  
}

3. 初始化vmcs内容

这里简单讲一下主要就是将vmcs中的数据进行填入，包括guest和host，我们直接上代码，由于篇幅有限，这里不再展开各个字段的含义，如果有需要进一步了解，可以参考上面的几个链接，或者intel手册

C++                  void setup_vmcs(uintptr_t guest_stack_pointer, uintptr_t guest_instruction_pointer, _vt_vcpu_context* vcpu) {                  
__pseudo_descriptor_64_t gdtr, idtr;                  
_sgdt(&gdtr);                  
__sidt(&idtr);                  
//asm_lidt(&vcpu->idtr);                  
_ia32_vmbasic_msr vmx_basic_msr = {                  
__readmsr(ia32_msr_vmx_basic) };                  
ULONG use_true_msrs = vmx_basic_msr.fields.vmx_capability_hint;                  
_ia32_vmx_vmentry_controls vm_entryctl_requested = { 0 };                  
//vm_entryctl_requested.fields.load_debug_controls = true;                  
vm_entryctl_requested.fields.ia32e_mode_guest = true;                  
_ia32_vmx_vmentry_controls vm_entryctl;                  
vm_entryctl.all = vmx_adjust_controlvalue(                  
use_true_msrs ? ia32_msr_vmx_true_entry_ctrl : ia32_msr_vmx_entry_ctrl,                  
vm_entryctl_requested.all);                  
_ia32_vmx_vmexit_controls vm_exitctl_requested = { 0 };                  
vm_exitctl_requested.fields.host_address_space_size = true;                  
_ia32_vmx_vmexit_controls vm_exitctl;                  
vm_exitctl.all = vmx_adjust_controlvalue(                  
use_true_msrs ? ia32_msr_vmx_true_exit_ctrl : ia32_msr_vmx_exit_ctrl,                  
vm_exitctl_requested.all);                  
_ia32_vmx_pinbased_controls vm_pinctl_requested = { 0 };                  
// vm_pinctl_requested.fields.nmi_exiting = true;                  
// vm_pinctl_requested.fields.virtual_nmis = true;                  
_ia32_vmx_pinbased_controls vm_pinctl = {                  
vmx_adjust_controlvalue(use_true_msrs ? ia32_msr_vmx_true_pinbased_ctrl                  
: ia32_msr_vmx_pinbased_ctrl,                  
vm_pinctl_requested.all) };                  
_ia32_vmx_processorbased_controls vm_procctl_requested = { 0 };                  
//vm_procctl_requested.fields.cr3_load_exiting = true;                  
vm_procctl_requested.fields.rdtsc_exiting = false;                  
vm_procctl_requested.fields.use_tsc_offseting = true;                  
vm_procctl_requested.fields.mov_dr_exiting = false;                  
vm_procctl_requested.fields.use_io_bitmaps = false;                  
vm_procctl_requested.fields.use_msr_bitmaps = false;                  
vm_procctl_requested.fields.activate_secondary_control = true;                  
// initialize time offset.                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_tscoffset, 0);                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_tscoffsethigh, 0);                  
_ia32_vmx_processorbased_controls vmx_procctl;                  
vmx_procctl.all =                  
vmx_adjust_controlvalue(use_true_msrs ? ia32_msr_vmx_true_priproc_ctrl                  
: ia32_msr_vmx_priproc_ctrl,                  
vm_procctl_requested.all);                  
_ia32_vmx_secondaryprocessorbased_controls vm_procctls2_requested = { 0 };                  
vm_procctls2_requested.fields.enable_rdtscp = true;                  
vm_procctls2_requested.fields.enable_invpcid = true;                  
vm_procctls2_requested.fields.enable_vpid = true;                  
vm_procctls2_requested.fields.enable_xsaves_xstors = true;                  
_ia32_vmx_secondaryprocessorbased_controls vm_procctls2;                  
vm_procctls2.all = vmx_adjust_controlvalue(ia32_msr_vmx_2ndproc_ctrl,                  
vm_procctls2_requested.all);                  
uintptr_t exception_bitmap = 0;                  
uintptr_t cr0_mask = 0;                  
uintptr_t cr0_shadow = __readcr0();                  
uintptr_t cr4_mask = 0;                  
uintptr_t cr4_shadow = __readcr4();                  
uintptr_t nerror =                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_virtualprocessorid,                  
KeGetCurrentProcessorNumberEx(NULL) + 1);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestesselector,                  
asm_reades());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcsselector,                  
asm_readcs());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestssselector,                  
asm_readss());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdsselector,                  
asm_readds());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestfsselector,                  
asm_readfs());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestgsselector,                  
asm_readgs());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestldtrselector,                  
asm_readldtr());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guesttrselector,                  
asm_readtr());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostesselector,                  
asm_reades() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostcsselector,                  
asm_readcs() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostssselector,                  
asm_readss() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostdsselector,                  
asm_readds() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostfsselector,                  
asm_readfs() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostgsselector,                  
asm_readgs() & 0xf8);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hosttrselector,                  
asm_readtr() & 0xf8);                  
//PHYSICAL_ADDRESS phyAddress = {};                  
//nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_msrbitmap,                  
//(uintptr_t)MmGetVirtualForPhysical(phyAddress));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_vmcslinkpointer,                  
MAXULONG64);                  
_ia32_vmx_debugctl_register l_temp_debugReg = { __readmsr(ia32_msr_debug_control) };                  
l_temp_debugReg.fields.reserved1 = 0;                  
l_temp_debugReg.fields.reserved2 = 0;                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestia32debugctl,                  
l_temp_debugReg.all);                  
nerror |= __vmx_vmwrite(                  
(size_t)_vt_vmcs_field::_vt_vmcs_pinbasedvmexeccontrol, vm_pinctl.all);                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_cpubasedvmexeccontrol,                  
vmx_procctl.all);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_exceptionbitmap,                  
exception_bitmap);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_vmexitcontrols,                  
vm_exitctl.all);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_vmentrycontrols,                  
vm_entryctl.all);                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_secondaryvmexeccontrol,                  
vm_procctls2.all);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guesteslimit,                  
__segmentlimit(asm_reades()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdslimit,                  
__segmentlimit(asm_readds()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcslimit,                  
__segmentlimit(asm_readcs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestsslimit,                  
__segmentlimit(asm_readss()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestfslimit,                  
__segmentlimit(asm_readfs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestgslimit,                  
__segmentlimit(asm_readgs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestldtrlimit,                  
__segmentlimit(asm_readldtr()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guesttrlimit,                  
__segmentlimit(asm_readtr()));                  
// uintptr_t nerror |= __vmx_vmwrite(_vt_vmcs_field::, function::);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestgdtrlimit,                  
gdtr.limit);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestidtrlimit,                  
idtr.limit);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestesarbytes,                  
vmx_getsegment_accessright(asm_reades()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcsarbytes,                  
vmx_getsegment_accessright(asm_readcs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestssarbytes,                  
vmx_getsegment_accessright(asm_readss()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdsarbytes,                  
vmx_getsegment_accessright(asm_readds()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestfsarbytes,                  
vmx_getsegment_accessright(asm_readfs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestgsarbytes,                  
vmx_getsegment_accessright(asm_readgs()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestldtrarbytes,                  
vmx_getsegment_accessright(asm_readldtr()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guesttrarbytes,                  
vmx_getsegment_accessright(asm_readtr()));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestsysentercs,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysentercs));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostia32sysentercs,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysentercs));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_cr0guesthostmask,                  
cr0_mask);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_cr4guesthostmask,                  
cr4_mask);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_cr0readshadow,                  
cr0_shadow);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_cr4readshadow,                  
cr4_shadow);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcr0,                  
__readcr0());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcr3,                  
__readcr3());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcr4,                  
__readcr4());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestesbase, 0);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestcsbase, 0);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestssbase, 0);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdsbase, 0);                  
nerror |= __vmx_vmwrite(                  
(size_t)_vt_vmcs_field::_vt_vmcs_guestfsbase,                  
__readmsr((unsigned long)_vt_msr_value::_vt_msr_fsbase));                  
nerror |= __vmx_vmwrite(                  
(size_t)_vt_vmcs_field::_vt_vmcs_guestgsbase,                  
__readmsr((unsigned long)_vt_msr_value::_vt_msr_gsbase));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestldtrbase,                  
vmx_get_segmentbase(gdtr.base_address, asm_readldtr()));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guesttrbase,                  
vmx_get_segmentbase(gdtr.base_address, asm_readtr()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestgdtrbase,                  
gdtr.base_address);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestidtrbase,                  
idtr.base_address);                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestdr7, __readdr(7));                  
ULONG_PTR rflags = __readeflags();                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestrflags,                  
rflags);                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestsysenteresp,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysenteresp));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestsysentereip,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysentereip));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostcr0,                  
__readcr0());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostcr3,                  
__readcr3());                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostcr4,                  
__readcr4());                  
nerror |= __vmx_vmwrite(                  
(size_t)_vt_vmcs_field::_vt_vmcs_hostfsbase,                  
__readmsr((unsigned long)_vt_msr_value::_vt_msr_fsbase));                  
nerror |= __vmx_vmwrite(                  
(size_t)_vt_vmcs_field::_vt_vmcs_hostgsbase,                  
__readmsr((unsigned long)_vt_msr_value::_vt_msr_gsbase));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hosttrbase,                  
vmx_get_segmentbase(gdtr.base_address, asm_readtr()));                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostgdtrbase,                  
gdtr.base_address);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostidtrbase,                  
idtr.base_address);                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostia32sysenteresp,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysenteresp));                  
nerror |=                  
__vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostia32sysentereip,                  
__readmsr(                  
(unsigned long)_vt_msr_value::_vt_msr_sysentereip));                  
uintptr_t vmm_stack_region_base = (uintptr_t)(vcpu->stack) + kernel_stack_szie;                  
uintptr_t vmm_stack_data = (uintptr_t)(vmm_stack_region_base)-sizeof(void*);                  
*(_vt_vcpu_context**)vmm_stack_data = vcpu;                  
ULONG_PTR vmm_stack_base = vmm_stack_region_base - sizeof(_vt_vcpu_context*) - sizeof(_result_registers);                  
//nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_eptpointer, 0);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostrsp, vmm_stack_base);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_hostrip, (size_t)asm_vmmentrypoint);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestrsp, guest_stack_pointer);                  
nerror |= __vmx_vmwrite((size_t)_vt_vmcs_field::_vt_vmcs_guestrip, guest_instruction_pointer);                  
__vmx_vmlaunch();                  
}                  

这里，我们只简单讲解最后几行的代码，其他的设置可以参考上面的文章引用，有更详细的解释，我们设置了hostrsp、hostrip、guestrsp、guestrip，并执行vmlaunch，当代码正常运行时，我们的cpu会自动进入guest模式，再guestrip处开始执行，如果cpu触发了某些vt的事件导致退出，那么会导致cpu进入host模式，并执行hostrip处的代码

VT Host的handler处理：

为了压缩篇幅，我们将尽可能的减少功能的实现，除非一些"必不可少的功能"，例如，我们需要实现cpuid、msr、nmi、vmx指令的处理，其余的暂时不涉及

1. NMI

针对NMI，我们选择直接注入到guest的方式进行，但需要注意的是，不需要挪动guest环境中的RIP

C++                  void vt_vmm_handleexception(_vt_vmhandle_guestcontext* guest_context) {                  
size_t exit_exception_value = 0;                  
__vmx_vmread((size_t)_vt_vmcs_field::_vt_vmcs_vmexitintrinfo, &exit_exception_value);                  
const _vt_vmexit_interruptioninformationfield exception = { exit_exception_value };                  
const _vt_interruption_type interruption_type = (_vt_interruption_type)(exception.fields.interruption_type);                  
const _vt_interruption_vector vector = (_vt_interruption_vector)(exception.fields.vector);                  
ULONG_PTR guest_inst_length;                  
__vmx_vmread((ULONG_PTR)_vt_vmcs_field::_vt_vmcs_vmexitinstructionlen, &guest_inst_length);                  
ULONG_PTR error_code = 0;                  
__vmx_vmread((ULONG32)_vt_vmcs_field::_vt_vmcs_vmexitintrerrorcode, &error_code);                  
vt_vmm_injectinterruption(interruption_type, vector, exception.fields.error_code_valid, error_code);                  
__vmx_vmwrite((ULONG32)_vt_vmcs_field::_vt_vmcs_vmentryinstructionlen, guest_inst_length);                  
}

2. Cpuid

针对CPUID，我们直接通过调用CPUID，将返回值直接进行写入的方式进行处理，尽管这种处理是存在漏洞的，但本次的完成目标不涉及这块

C++                  void vt_vmm_handlecpuid(_vt_vmhandle_guestcontext* guest_context) {                  
int buf[4];                  
__cpuidex(buf, guest_context->stack->gp_regs.Rax, guest_context->stack->gp_regs.Rcx);                  
guest_context->stack->gp_regs.Rax = buf[0];                  
guest_context->stack->gp_regs.Rbx = buf[1];                  
guest_context->stack->gp_regs.Rcx = buf[2];                  
guest_context->stack->gp_regs.Rdx = buf[3];                  
guest_context->vm_movinstruction = true;                  
}

3. Msr

针对msr的读取和写入，我们也是采取相同的方式进行，但是得套一层异常处理，因为在读写时，可能会导致CPU抛出来异常。在针对一些特殊的msr寄存器时，我们需要用特殊的vmcs段进行代替

C++                  bool vt_vmm_handlemsraccess(                  
_vt_vmhandle_guestcontext* guest_context, bool read_access) {                  
const auto msr = (_vt_msr_value)(guest_context->stack->gp_regs.Rcx);                  
bool transfer_to_vmcs = false;                  
_vt_vmcs_field vmcs_field = {};                  
switch (msr) {                  
case _vt_msr_value::_vt_msr_sysentercs:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestsysentercs;                  
transfer_to_vmcs = true;                  
break;                  
case _vt_msr_value::_vt_msr_sysenteresp:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestsysenteresp;                  
transfer_to_vmcs = true;                  
break;                  
case _vt_msr_value::_vt_msr_sysentereip:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestsysentereip;                  
transfer_to_vmcs = true;                  
break;                  
case _vt_msr_value::_vt_msr_debugctl:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestia32debugctl;                  
transfer_to_vmcs = true;                  
break;                  
case _vt_msr_value::_vt_msr_gsbase:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestgsbase;                  
transfer_to_vmcs = true;                  
break;                  
case _vt_msr_value::_vt_msr_fsbase:                  
vmcs_field = _vt_vmcs_field::_vt_vmcs_guestfsbase;                  
transfer_to_vmcs = true;                  
break;                  
default:                  
break;                  
}                  
const auto is_64bit_vmcs = (vmcs_field >= _vt_vmcs_field::_vt_vmcs_iobitmapa) && (vmcs_field <= _vt_vmcs_field::_vt_vmcs_hostia32perfglobalctrlhigh);                  
LARGE_INTEGER msr_value = {};                  
if (read_access) {                  
if (transfer_to_vmcs) {                  
if (is_64bit_vmcs) {                  
__vmx_vmread((ULONG32)vmcs_field, (size_t*)&msr_value.QuadPart);                  
}                  
else {                  
__vmx_vmread((ULONG32)vmcs_field, (size_t*)&msr_value.QuadPart);                  
}                  
}                  
else {                  
msr_value.QuadPart = __readmsr((ULONG32)msr);                  
}                  
guest_context->stack->gp_regs.Rax = msr_value.LowPart;                  
guest_context->stack->gp_regs.Rdx = msr_value.HighPart;                  
}                  
else {                  
msr_value.LowPart = static_cast(guest_context->stack->gp_regs.Rax);          
msr_value.HighPart = static_cast(guest_context->stack->gp_regs.Rdx);           
if (transfer_to_vmcs) {           
if (is_64bit_vmcs) {           
__vmx_vmwrite((ULONG32)vmcs_field, (size_t)msr_value.QuadPart);           
}           
else {           
__vmx_vmwrite((ULONG32)vmcs_field, (size_t)msr_value.QuadPart);           
}           
}           
else {           
__writemsr((ULONG32)msr, (size_t)msr_value.QuadPart);           
}           
}           
guest_context->vm_movinstruction = true;           
return true;           
}

4. vmx指令

由于本期不涉及嵌套，所以相关指令，我们直接注入一个事件即可

C++                  void vt_vmm_handle_vmx(_vt_vmhandle_guestcontext* guest_context) {                  
vt_vmm_injectinterruption(_vt_interruption_type::_vt_interruption_hardwareexception,                  
_vt_interruption_vector::_vt_intteruptionvec_invalidopcodeexception, false,                  
0);                  
return;                  
}

结尾：

至此，我们的代码已经可以在虚拟机中跑起来了，尽管本工程比较简陋，但对于目前接下来要做的功能，已经绰绰有余了

跳转微信打开

]]> Sat, 28 Mar 2026 10:01:00 +0800 从0训练自己的AI大模型(上) https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485967&idx=1&sn=75ccdade1b71b91fdbca718b77005975 前言2026年了，随着openclaw，ai agent的爆火，越来越多的人开始研究LLM的应用领域，不过我本 原创 为了安全鸭 2026-03-27 10:01 北京

前言

2026年了，随着openclaw，ai agent的爆火，越来越多的人开始研究LLM的应用领域，不过我本人对它不咋感冒，一个是我无论是工作上还是生活中agent写得用的够多了

《[2025]中外AI大战!让AI们通过MCP玩帝国时代2》
https://key08.com/index.php/2025/10/04/2816.html
另外一个是，我觉得agent这些应用层的东西不够底层，没有什么价值。所以快过新年的时候，就打算年后学习咋做LLM，自己搞个AI大模型出来。不过年后公司业务真的忙，一直没空，到3月份也很忙。

ps:现在AI写代码了，理论上更轻松了，但是现实中怎么更忙了。

但是没办法了，我觉得自己不能被垃圾业务代码淹没，所以再怎么忙也抽时间开始这个项目了。

首先声明，虽然我之前懂机器学习/深度学习/强化学习，不过这些都只会一点点，我不是LLM领域专家，要是写的不好或者有问题请评论区请指出我的错误。

前期准备

明确自己要干什么

在训练的第一步，我们确定自己要搞什么，我确定我是搞网络安全的，我要最低代价训练一个看起来不错的小模型就行，其他的能力拉了就拉了，专项训练不是那么容易的。
因此我们确定：

  1. 我们是小模型，不用太多资源

  2. 搞着玩的，自己学习大模型训练，他基本只是个DEMO，不要做太好，不要花太多钱。

服务器配置

基本上，我们前期要准备一个AI训练服务器，我准备训练的模型大小是0.6b，所以两张A100就行了，太多了资源溢出了。但是硬盘和带宽要稍微大一点，特别是带宽，走梯子拉hf的内容，带宽32M绝对不够用。

准备

预训练数据集

这有两个推荐的
commoncrawl -数百 TB 级别的数据，数十亿网页中提取的 TB 级原始网络数据，每月都会爬取新的数据，但我没用，因为光下完我估计我就没了几万块了。
https://commoncrawl.org/get-started

RefinedWeb
1TB 左右，9.68亿条数据
Common Crawl 数据集的大量经过重复数据删除和过滤的标记语料库，它是为较小规模但高质量的数据集训练 Falcon-40B 模型而开发的
https://huggingface.co/datasets/tiiuae/falcon-refinedweb

网络安全社区的爬虫数据/CEV/POC/exploit-db/github安全相关的东西混在一起

由于RefinedWeb是纯英文的，所以我又找了几个hugging face上不知名的中文数据集，中文数据集是真的难找，随便找了几个。

模型架构

这里我就一个经验，永远不要自己创造乱七八糟的架构(其实架构不咋重要，重要的是数据)，所以我选了llama的，由于分词表llama对中文不太好，用qwen的分词表。此外快速注意力，rope这些都上了。

开始训练

所以，现在训练一个模型成本极其的低廉了，我只需要搞个服务器，然后装一个opencode，我给他数据，让他搅拌在一起，就能开始预训练了。你不用关心操作，只需要关心细节就行。
模型loss降低的很快，一晚上就从9到3，似乎一切都朝着好的方向发展，我们很快就能训练一个好的模型了

LOSS居然不降低了

过了大概3天后，我观察到一个问题，loss居然不继续降低了，还是在3-2左右
看了看checkpoints，成这样了


为什么会这样，这个问题别让ai回答，因为我被AI坑了，AI说是训练时间不够久，然后就训练到了60000步，等回过头的时候，已经被坑惨了

让我们仔细回顾一下数据集，RefinedWeb我用了，这个应该是洗好的，网络安全社区的爬虫数据.这个是问题，它包含了大量的无用的标签，时间戳，这些标签因为我们训练的是0.6b的模型，他会让模型困惑，毫无逻辑。可能在更大的模型上他会学到这个是网页，但是对于一个0.6b的模型来说太勉强了。

因此，我们只能清洗一下数据，所谓清洗，我们直接点，国内论坛强行只保留中文，删除非中文或者非代码的内容。删掉无意义的CVE的编号，等。然后我们由于一开始就训练坏了，只能重新训练了，这次看表现还不错，几千次就这样了

然后等吧，由于是重新再来，相当于浪费了1000多，挂了两天，看看效果：
肉眼可见loss低了：

续写也很正常一点了

但是我发现，这玩意大而空：

我认为是数据不够的结果，所以不管他继续训练了。
又过了一天
我发现最新的checkpoints出现损坏的情况：

所以先回退到老版本，做一下SFT

SFT

有了一个续写模型后，我们可以下一步，开始进行SFT微调了, 这样才有对话能力，自我认知能力。
这真的是一个大坑
pre train还算中规中矩。post train就麻烦了，一开始我从网上随便找了数据集进行训练，发现会让模型直接损坏！

还有更离谱的,老外的训练集也带黄色废料,导致模型学了不该学的:
(当我说’你好’的时候)

这tm是一个黄色废料….
实在不行了！业务上又有一堆事…于是乎我找了一个hf上很火的deepseek蒸馏的数据集，不带think的那个，又过了一天…
结果第二天看的时候 我特么发现不对劲..

怎么回事，这么那么多”美人”啊

检查checkpoints，发现从很早开始，模型就学会美人了，而且他最早的时候居然在写小黄文….
倒查训练集，我发现一个绝望的事情，我的训练集里面充满了小黄文，其中美人来自这里

完了，又白训练了.

捣鼓半天，试了N个数据集，效果还是不明显。其实后来写文章的时候看，这就触发了我前面说的两个大坑
我们用了RefinedWeb，并且用了一些受污染的/完全不知名的中文训练集来做预训练，这导致，模型的底座中文能力其实是偏差的，即便是有合成数据在，一开始的混入的中文低质量语料去不掉了，除非重新训练

第二个问题，我们的模型比较小，只有0.6b，他受到post train的影响非常大，他并不是一个通用模型，如果我们再拿网上的一些数据去给他做SFT，他只会学到乱七八糟的 杂七杂八的内容，除非我们预训练做的非常充分。
而看起来，我们的预训练也不充分，数据集不够多，次数也不够多，数据配比也有问题。一系列问题导致我们到了如今的情况。

make duckgpt greate again

其实前面写了一大堆废话的原因是因为，很明显，我前面的各种操作导致模型训练失败了。这种感觉就像是，你想去送外卖但是没有电动车，冰箱里面有泡面但是没有卤蛋，塞满了资料的硬盘说挂，很好的朋友突然翻脸，认真做的东西没人喜欢,你又会发现龟苓膏里面没有龟，老婆饼里面没有老婆，你以为的通常都不是通常，生气没用，愤怒徒劳，不行就是不行，但是失败并不丢人，只要总结原因，我们一定能解决各种未知的困难，毕竟这不是物理学。而经过冷静思考，我发现我前几天失败的原因是，在没有科学的进行学习的情况下干某件事，就跟《勇哥说餐饮》里面的蜘蛛侠一样失败。

于是乎为了解决问题，我重新进行了大量的资料学习，并且我仔细思考了一下目前的困境:
英文的效果都是好的，英文看起来至少都正常，比如这个，但是模型完全不会中文

因此本质上，需要的是pre train足够扎实，但是我们的pre train并不扎实

经过一段时间的学习和资料查找和别人的大模型POC学习（minimind），我发现，我们的重大失误:

首先，我们需要我们正确配比数据，正确的做法是，模型大小 x 20，比如我是0.6b的模型，则需要12b的数据。此外这之，我也不打算先训练网络安全的数据了，用完90%是通用数据，10%是合成的网络安全数据

此外，我们不能用野鸡的数据集，HF上很多数据集并没有进行很好的清理，一味的追求数据大规模，只会导致模型啥也学不到，除非模型参数是真的大，大到无视这种杂七杂八的数据，但是那种几百B的我们个人是搞不定的。小模型对输入的数据很敏感。

最后，我的SFT数据集也有问题，我们太相信网上的数据了，但是网上数据他并不是正常分布的，他充斥着很多人对AI的想法，比如有人拿AI做数学题，有人让AI写小黄文，有人让AI解决数学作业。这些如果是大模型搞通用大模型是可以的，但是这些数据对于我们来说，有毒。会拉低整体模型水平，正规做法是base+通用任务SFT+领域任务SFT，而不是一股脑全塞进去会导致出问题。
因此SFT数据配比我90%都是大模型合成，10%是网上通用数据。并且SFT训练率通常要是pre train的0.1左右，大了可能不收敛。

最后的最后，我发现的模型架构也有问题
我们用了Qwen的分词器，Qwen的分词器占用大概151k 加上并没有用tie，导致实际上attention就会很小很小，解决方案是换一个词表+用TIE
(实际上，在QWEN3里面的说法中，4B以下的模型都用tie)

合成数据

现在大模型厂商训练开始用合成数据来进行训练，即用一个更大的模型合成数据给小模型出来用，自然语言数据已经快到头了对于很多大模型来说（当然对于我来说不是）。

我们可以从中获得的启发是，大模型合成的数据，相比从网上爬来的野鸡数据，至少清洗过，可靠。另外对于raw data，做数据清洗是一个体力活，我一个人时间有限，而且这个吞金兽还开着，时间很珍贵。所以我立刻开始了下一步，用本地模型进行合成数据的操作

我准备用两种模型来合成数据，一个是本地的qewn3.5,他们做的非常不错，本地成本低，另外一个是云端的大模型，为了实现合成数据，我让AI写了一个发散脚本，即自己思考自己下一步要生成什么，因为我们是做pre train，所以做的是续写而不是对话。

我的配置是云端大模型占了30%，本地小模型占了70%
为什么用本地模型，因为在线大模型耗钱啊！

先让大模型无限自动生成种子数据：

然后拿这些东西去让大模型续写：

这样就得到了一批高质量的数据，虽然还是有问题，比如大模型的幻觉会会影响数据质量，而且我也没清洗过，但是至少靠谱一点了.

结果，又过了两天（-400rmb）

重新预训练

所以，我重新进行了预训练，搞了几个高质量的通用任务数据集:
https://huggingface.co/datasets/Goose-World/RWKV-World-v3
https://huggingface.co/datasets/opencsg/Fineweb-Edu-Chinese-V2.2
https://huggingface.co/datasets/shareAI/ShareGPT-Chinese-English-90k
等等..
然后继续合成数据:

数据大小限制在12b左右，不扩大。
终于，在睡了一觉后，loss终于稳定在2.5-3左右了：

看起来靠谱一点了，没之前那么离谱

于是我们得到了一个pre train训练好的模型。虽然这个模型很垃圾，其他领域续写一窍不通，因为我们没有给他投喂太多的语料。但是对于安全领域，属于是能跑吧

现在再对其做SFT。用了合成数据，其他没什么特别的

做完后效果如下:

当然也有幻觉，比如这个中国美食带了日本寿司:

然后弄了一个版本的SFT纠正了一下：

不过我也不知道他学了什么…可能是学到合成数据里面的拒绝语句了，对于代码题目是拒绝的

然后我们用了QWEN作为合成数据，所以这个模型自我认知里面认为自己是qwen的，我也懒得再合成一些自我认知数据去修正他的认知了，反正是做着玩的

幻觉依然是存在的，而且非常大，并且对于不懂的问题，就会变得笨笨的：

(我们的训练集里面没有银狐木马，所以AI完全无法找到有用的东西，所以就会这样)

总结反思

这次一共花了5000RMB，而其实跑通后实现同样的效果的模型，只需要800rmb左右，大部分时间花费在边学边测边用上:

这是因为我选了一个错误的路线，0.6b对于模型来说还是太大了，应该先从极小的参数开始，比如0.1b或者0.01b先做实验。实验跑通了再堆数据规模。从而避免时间/金钱的耗费。

无论怎么样，我们都跑通了整体的路线，下次就不会那么吃瘪了，这次没有做工具调用训练以及RL以及实现COT(思维链推理)效果也是一种遗憾，因为花的钱太多了，所以先抱有遗憾的止血，等回血一波后，攒一波再来一次更好的训练，敬请关注冲鸭安全。

这边非常感谢minimind,所有想训练的人但是不是搞模型专业的人应该先复现一下这个,节约大量时间,避免跟我一样一头撞到墙上:
https://github.com/jingyaogong/minimind

跳转微信打开

]]> Fri, 27 Mar 2026 10:01:00 +0800 Windows下不触发任何进程监控的创建进程 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485866&idx=1&sn=027c346f42696ff753a8681b2308e3c2 前言这几年AI用多了,脑子坏了,比如之前写代码很容易进入心流解决问题,这个过程很爽,但是现在只会开五六个ai的 原创 为了安全鸭 2026-01-24 16:30 北京

前言

这几年AI用多了,脑子坏了,比如之前写代码很容易进入心流解决问题,这个过程很爽,但是现在只会开五六个ai的console让他帮我打工。
一开始是很急的让AI写功能，
但是到后来恨不得遇到bug，编译不通过，甚至是思考都托管给AI。
我把它叫做脑腐现象.所以为了避免这种现象,我准备用纯手工打造的方式搞点项目做。锻炼一下大脑。正巧，操作系统内核目前还是AI无法触及的领域。所以，here we go。

内核创建进程

所以，让我们来复习一下内核创建进程，这里不会说太多的基础，因为chatgpt都能回答了。我们直接说简单一点的。我们先实现一个简单的调用ntcreateuserprocess创建进程的例子，在内核里面这需要三步:

  1. 定位ntcreateuserprocess

  2. 填好参数

  3. call

定位ntcreateuserprocess

定位方式有很多，比如经典款祖传找SSDT table,但是
我是懒得定位了，直接特征码写死了:

填好参数

ntcreateuserpcoess在R3的执行的时候需要用到RtlCreateProcessParametersEx和RtlDestroyProcessParameters去填_RTL_USER_PROCESS_PARAMETERS

我们R0是没有这个两个参数的，所以要自己填.填完直接call就行:

但是坑来了,
而这个RTL_USER_PROCESS_PARAMETERS 微软故意隐藏了东西，导致如果你按照微软的来写是没有办法跑起来的，跑起来会直接segment fault.这是因为没有正确的填参数,CRT初始化的时候就崩溃了。因此我写了一个R3程序，打印一下里面需要什么东西:

// ConsoleApplication1.cpp
// Dumps the raw payload produced by RtlCreateProcessParametersEx (user-mode).
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winternl.h>
#include <cstdint>
#include <cstdio>
#include <string>
//0x18 bytes (sizeof)
struct _CURDIR
{
    struct _UNICODE_STRING DosPath;                                         //0x0
    VOID* Handle;                                                           //0x10
};
//0x18 bytes (sizeof)
struct _RTL_DRIVE_LETTER_CURDIR
{
    USHORT Flags;                                                           //0x0
    USHORT Length;                                                          //0x2
    ULONG TimeStamp;                                                        //0x4
    struct _STRING DosPath;                                                 //0x8
};
//0x410 bytes (sizeof)
struct _RTL_USER_PROCESS_PARAMETERSEX
{
    ULONG MaximumLength;                                                    //0x0
    ULONG Length;                                                           //0x4
    ULONG Flags;                                                            //0x8
    ULONG DebugFlags;                                                       //0xc
    VOID* ConsoleHandle;                                                    //0x10
    ULONG ConsoleFlags;                                                     //0x18
    VOID* StandardInput;                                                    //0x20
    VOID* StandardOutput;                                                   //0x28
    VOID* StandardError;                                                    //0x30
    struct _CURDIR CurrentDirectory;                                        //0x38
    struct _UNICODE_STRING DllPath;                                         //0x50
    struct _UNICODE_STRING ImagePathName;                                   //0x60
    struct _UNICODE_STRING CommandLine;                                     //0x70
    VOID* Environment;                                                      //0x80
    ULONG StartingX;                                                        //0x88
    ULONG StartingY;                                                        //0x8c
    ULONG CountX;                                                           //0x90
    ULONG CountY;                                                           //0x94
    ULONG CountCharsX;                                                      //0x98
    ULONG CountCharsY;                                                      //0x9c
    ULONG FillAttribute;                                                    //0xa0
    ULONG WindowFlags;                                                      //0xa4
    ULONG ShowWindowFlags;                                                  //0xa8
    struct _UNICODE_STRING WindowTitle;                                     //0xb0
    struct _UNICODE_STRING DesktopInfo;                                     //0xc0
    struct _UNICODE_STRING ShellInfo;                                       //0xd0
    struct _UNICODE_STRING RuntimeData;                                     //0xe0
    struct _RTL_DRIVE_LETTER_CURDIR CurrentDirectores[32];                  //0xf0
    ULONGLONG EnvironmentSize;                                              //0x3f0
    ULONGLONG EnvironmentVersion;                                           //0x3f8
    VOID* PackageDependencyData;                                            //0x400
    ULONG ProcessGroupId;                                                   //0x408
    ULONG LoaderThreads;                                                    //0x40c
};
// Some SDKs do not declare this prototype in user-mode headers.
using fnRtlCreateProcessParametersEx = NTSTATUS(NTAPI*)(
    _RTL_USER_PROCESS_PARAMETERSEX* pProcessParameters,
    PUNICODE_STRING ImagePathName,
    PUNICODE_STRING DllPath,
    PUNICODE_STRING CurrentDirectory,
    PUNICODE_STRING CommandLine,
    PVOID Environment,
    PUNICODE_STRING WindowTitle,
    PUNICODE_STRING DesktopInfo,
    PUNICODE_STRING ShellInfo,
    PUNICODE_STRING RuntimeData,
    ULONG Flags
);
using fnRtlDestroyProcessParameters = NTSTATUS(NTAPI*)(_RTL_USER_PROCESS_PARAMETERSEX ProcessParameters);
static UNICODE_STRING MakeUnicodeString(const std::wstring& s)
{
    UNICODE_STRING us{};
    us.Buffer = const_cast<PWSTR>(s.c_str());
    us.Length = static_cast<USHORT>(s.size() * sizeof(wchar_t));
    us.MaximumLength = us.Length + sizeof(wchar_t);
    return us;
}
static void HexDump(const void* data, size_t size)
{
    const auto* p = static_cast<const unsigned char*>(data);
    for (size_t i = 0; i < size; i += 16) {
        std::printf("%08zx  ", i);
        for (size_t j = 0; j < 16; ++j) {
            if (i + j < size) std::printf("%02X ", p[i + j]);
            else std::printf("   ");
        }
        std::printf(" ");
        for (size_t j = 0; j < 16 && i + j < size; ++j) {
            unsigned char c = p[i + j];
            std::printf("%c", (c >= 32 && c <= 126) ? c : '.');
        }
        std::printf("\n");
    }
}
static void PrintUs(const char* name, const UNICODE_STRING& us, const void* base)
{
    const auto baseAddr = reinterpret_cast<uintptr_t>(base);
    const auto bufAddr = reinterpret_cast<uintptr_t>(us.Buffer);
    std::wprintf(L"%hs: Len=%u Max=%u Buf=%p (off=0x%Ix)  \"%.*s\"\n",
        name,
        us.Length,
        us.MaximumLength,
        us.Buffer,
        (bufAddr >= baseAddr) ? (bufAddr - baseAddr) : 0,
        us.Length / 2,
        us.Buffer ? us.Buffer : L"");
}
int wmain()
{
    // Example payload: create cmd.exe parameters (NOT actually launching here).
    std::wstring imagePath = L"\\??\\C:\\Windows\\System32\\cmd.exe";
    std::wstring cmdLine = L"\"C:\\Windows\\System32\\cmd.exe\"";
    UNICODE_STRING usImage = MakeUnicodeString(imagePath);
    UNICODE_STRING usCmd = MakeUnicodeString(cmdLine);
    HMODULE ntdll = ::GetModuleHandleW(L"ntdll.dll");
    if (!ntdll) {
        std::printf("GetModuleHandleW(ntdll) failed: %lu\n", ::GetLastError());
        return 1;
    }
    auto pRtlCreate = reinterpret_cast<fnRtlCreateProcessParametersEx>(
        ::GetProcAddress(ntdll, "RtlCreateProcessParametersEx"));
    auto pRtlDestroy = reinterpret_cast<fnRtlDestroyProcessParameters>(
        ::GetProcAddress(ntdll, "RtlDestroyProcessParameters"));
    if (!pRtlCreate || !pRtlDestroy) {
        std::printf("GetProcAddress failed. RtlCreate=%p RtlDestroy=%p\n", pRtlCreate, pRtlDestroy);
        return 1;
    }
    _RTL_USER_PROCESS_PARAMETERSEX* p = nullptr;
    constexpr ULONG RTL_USER_PROCESS_PARAMETERS_NORMALIZED = 0x01;
    NTSTATUS st = pRtlCreate(
        (_RTL_USER_PROCESS_PARAMETERSEX*)&p,
        &usImage,
        nullptr,
        nullptr,
        &usCmd,
        nullptr,
        nullptr,
        nullptr,
        nullptr,
        nullptr,
        RTL_USER_PROCESS_PARAMETERS_NORMALIZED);
    std::printf("RtlCreateProcessParametersEx -> 0x%08X, p=%p\n", static_cast<unsigned>(st), p);
    if (st < 0 || !p)
        return 1;
    // Raw payload dump (what you'd want to mirror in kernel if you're hand-building).
    HexDump(p, sizeof(_RTL_USER_PROCESS_PARAMETERSEX));
    //pRtlDestroy(p);
    return 0;
}



实际上，缺失的内容是，我们需要填工作目录，并且要有完整的结构体:

//0x18 bytes (sizeof)
struct _CURDIR
{
    struct _UNICODE_STRING DosPath;                                         //0x0
    VOID* Handle;                                                           //0x10
};
//0x18 bytes (sizeof)
struct _RTL_DRIVE_LETTER_CURDIR
{
    USHORT Flags;                                                           //0x0
    USHORT Length;                                                          //0x2
    ULONG TimeStamp;                                                        //0x4
    struct _STRING DosPath;                                                 //0x8
};
//0x410 bytes (sizeof)
struct _RTL_USER_PROCESS_PARAMETERSEX
{
    ULONG MaximumLength;                                                    //0x0
    ULONG Length;                                                           //0x4
    ULONG Flags;                                                            //0x8
    ULONG DebugFlags;                                                       //0xc
    VOID* ConsoleHandle;                                                    //0x10
    ULONG ConsoleFlags;                                                     //0x18
    VOID* StandardInput;                                                    //0x20
    VOID* StandardOutput;                                                   //0x28
    VOID* StandardError;                                                    //0x30
    struct _CURDIR CurrentDirectory;                                        //0x38
    struct _UNICODE_STRING DllPath;                                         //0x50
    struct _UNICODE_STRING ImagePathName;                                   //0x60
    struct _UNICODE_STRING CommandLine;                                     //0x70
    VOID* Environment;                                                      //0x80
    ULONG StartingX;                                                        //0x88
    ULONG StartingY;                                                        //0x8c
    ULONG CountX;                                                           //0x90
    ULONG CountY;                                                           //0x94
    ULONG CountCharsX;                                                      //0x98
    ULONG CountCharsY;                                                      //0x9c
    ULONG FillAttribute;                                                    //0xa0
    ULONG WindowFlags;                                                      //0xa4
    ULONG ShowWindowFlags;                                                  //0xa8
    struct _UNICODE_STRING WindowTitle;                                     //0xb0
    struct _UNICODE_STRING DesktopInfo;                                     //0xc0
    struct _UNICODE_STRING ShellInfo;                                       //0xd0
    struct _UNICODE_STRING RuntimeData;                                     //0xe0
    struct _RTL_DRIVE_LETTER_CURDIR CurrentDirectores[32];                  //0xf0
    ULONGLONG EnvironmentSize;                                              //0x3f0
    ULONGLONG EnvironmentVersion;                                           //0x3f8
    VOID* PackageDependencyData;                                            //0x400
    ULONG ProcessGroupId;                                                   //0x408
    ULONG LoaderThreads;                                                    //0x40c
};

再然后稍微的手工填一下，这一步很想用AI忍不住了:

call it!

然后我们就跑起来了

但是这个有第二个问题，结束了就会蓝屏:

让我们调查一下,根据信息,错误代码在结束时候,

执行MmSessionGetWin32Callouts的时候:

.text:000000014008A220                                     MmSessionGetWin32Callouts proc near     ; CODE XREF: NtDeleteAtom+F↓p
.text:000000014008A220                                                                             ; PsConvertToGuiThread:loc_14060BEFE↓p ...
.text:000000014008A220 65 48 8B 04 25 88 01 00 00                          mov     rax, gs:188h
.text:000000014008A229 48 8B 88 B8 00 00 00                                mov     rcx, [rax+0B8h]
.text:000000014008A230 48 8B 81 00 04 00 00                                mov     rax, [rcx+400h]
.text:000000014008A237 48 83 B8 C0 03 00 00 02                             cmp     qword ptr [rax+3C0h], 2
.text:000000014008A23F 48 8D 05 52 E7 3A 00                                lea     rax, PsWin32CallBack
.text:000000014008A246 73 07                                               jnb     short locret_14008A24F
.text:000000014008A248 48 8D 05 41 E7 3A 00                                lea     rax, PsWin32NullCallBack
.text:000000014008A24F
.text:000000014008A24F                                     locret_14008A24F:                       ; CODE XREF: MmSessionGetWin32Callouts+26↑j
.text:000000014008A24F C3                                                  retn
.text:000000014008A24F                                     MmSessionGetWin32Callouts endp

而这个MmSessionGetWin32Callouts读

cmp     qword ptr [rax+3C0h], 2

的时候蓝屏了，这说明我们有什么东西没初始化。寻找这玩意的最好的办法是,ida搜索[rax+3C0h]访问的特征码:

根据特征码找一下cal，可以定位到，这个是在初始化win32k pfn的时候填的东西

就不卖关子了,我直接说为什么:
在操作系统创建进程时，分配进程内存和初始化进程的pfn的时候，会考虑进程的会话和上下文信息，以决定是否允许该进程访问 win32k 的pfn。而我们是直接在系统线程启动的进程，自然就没这些信息。
解决方法是附加到一个带界面的信息，比如我附加到资源管理器，这样会话也会自动分配到1而不是0:

这样你结束就不会蓝屏了，至此我们成功的实现了内核创建进程

进程回调

我们在
《[2022]新瓶装旧酒: 微软CreateProcessNotify的设计缺陷》
https://key08.com/index.php/2022/10/12/1606.html

中提到过 进程创建会触发createprocessnotify回调，这也是现在很多安全软件所用来监控进程创建的回调。

而这些回调会加入到PspCreateProcessNotifyRoutine里面.在有进程创建的时候，会被逐个执行

这些call最后被”PspCallProcessNotifyRoutines”这个执行:

so，有什么不搞DKOM的方法去不触发此类回调呢？有的兄弟，有的，那就是CPU模拟

AMD64 CPU模拟器

既然我们控制不了系统的执行流程，那么我们就不控制了，我们自己模拟一个CPU进行执行，只不过给的是真实的信息数据，唯一区别是，在执行PspCallProcessNotifyRoutines的时候,我们就跳过,其他时候跟操作系统一样就行。输入输出完全一样。
至于系统的call,我们除了PspCallProcessNotifyRoutines其他的就直接转发。这样我们就能达到目的。
如果不理解，这里有一个简单的图：

架构设计

我这边就最简单的zydis了，手搓的不需要太复杂。一个简单的X86虚拟就只需要指令行为模拟和栈就行，遇到call，我们要么选择转发，要么选择接管。
简单来说

初始化X64的vCpu

一次性decode 15字节

decode后，根据指令读取/写入不同的内存


比如mov rax,那就是给vcpu写入值

这一段让AI干了，纯苦力牛马活，没AI干不动
值得注意的是，一些指令会影响elflags,所以也记得让AI干好,AI会忽略这些影响elfags的指令:

执行他

之后就能愉快的把参数PUSH到vm里面并且执行了

值得注意的几个问题是，遇到cfg guard的时候,不要虚拟执行,因为CFG guard的bitmap会校验来源,我们的这种call肯定是非法的。最好的办法是跳过他如何call cfg,我之前手写的时候跳过是硬编码地址,但是GPT说有更好的,嗯…直接硬编码

如果遇到了直接跳过就行

call转发我之前也想的是人模拟参数,但是GPT给了一个更野的,直接全参数call,爱用哪个用哪个:

还得是AI,真的野，
此外我们设置返回地址为0，这样当模拟执行到0的时候，代表执行完成了。
我们来试一下直接模拟+call转发的:

可以看到,我们成功的运行了。
接下来跳过指定的函数,这也非常容易,我们直接跳过并且返回一个自定义的rax就行,我们跳过的是PspCallProcessNotifyRoutines,他不会修改传递的参数里面的内容,所以简单点就行:

这样我们就实现了完整跳过内核回调了

结果

让我们写个简单的createprocess回调看看，他会捕获所有cmd的执行

当我们执行cmd的时候,他会执行:

我们试试，传统内核直接ntcreateuserprocess:

很明显,因为会触发PspCallProcessNotifyRoutines,导致我们被发现:

而使用cpu模拟的ntcreateuserprocess,不会触发内核的进程回调的:

so…可能好奇的你问,这有什么用.
此技术有三个用途:

第一个是反作弊,总所周知,部分外挂会通过这些进程创建回调等回调,去拿真实的CR3或者做进程APC注入.而部分反作弊使用这种技术去不触发这些系统的回调启动游戏进程实现保护的效果

第二个是,目前绝大部分安全软件,都是基于PspCallProcessNotifyRoutines里面的回调创建进程管理器的,一旦一个进程不在安全软件自己的进程管理器里面,会导致安全软件无法监控到这个进程所有的行为,虽然有些脱裤子放屁的嫌疑,因为都驱动了都可以各种手段致盲安全软件了。

第三个是,他本来就没什么用,就跟大部分东西一样,写了就是为了提高自己技术.不要以”有什么用”去做某件事,要以”好玩就行”去做某件事。

阅读原文

跳转微信打开

]]> Sat, 24 Jan 2026 16:30:00 +0800 现代windows内存攻防简介(2026年) https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485822&idx=1&sn=93390a5b33f43d4822bb76b04a6ee436 简介又过一年了兄弟们，是时候更新冲鸭安全和key08了。主要是1月太忙了，一直忙着新产品，一直没空更新公众号和博客，趁着现在有空赶紧更新一波。 原创 为了安全鸭 2026-01-13 09:00 北京

简介

又过一年了兄弟们，是时候更新冲鸭安全和key08了。主要是1月太忙了，一直忙着新产品，一直没空更新公众号和博客，趁着现在有空赶紧更新一波。

shellcode

安全软件对抗中,常用shellcode作为规避杀毒软件文件查杀的办法,因为shellcode可以内存执行,可以随时抹掉,并且容易变形.
一段经典的shellcode loader如下:

    char* shellcode = (char*)VirtualAlloc(
        NULL,
        shellcode_size,
        MEM_COMMIT,
        PAGE_EXECUTE_READWRITE);
    CopyMemory(shellcode, buf, shellcode_size);
    //CreateThread函数，创建线程
    hThread = CreateThread(
        NULL, // 安全描述符
        NULL, // 栈的大小
        (LPTHREAD_START_ROUTINE)shellcode, // 函数
        NULL, // 参数
        NULL, // 线程标志
        &dwThreadId // 若成功，接收新创建的线程的线程ID DWORD变量的地址。
    );

如果你对”他发生了什么”感兴趣自己问chatgpt的VAD/PTE吧,这里我们不废话介绍原理了.

一般检测

现代的杀毒软件/或者EDR,对于这分配内存,一般会扫一下VAD里面的rwx

代码如下:

MEMORY_BASIC_INFORMATION mbi = { 0 };
        SIZE_T address = 0;
        while (VirtualQueryEx(hProcess.get(), reinterpret_cast<LPCVOID>(address), &mbi, sizeof(mbi)) == sizeof(mbi))
        {
            // 排除模块映像段
            if (mbi.Type != MEM_IMAGE)
            {
                // 检查是否可执行
                DWORD protect = mbi.AllocationProtect;
                bool checkExecuteFlag =
                    (protect & PAGE_EXECUTE) ||
                    (protect & PAGE_EXECUTE_READ) ||
                    (protect & PAGE_EXECUTE_READWRITE) ||
                    (protect & PAGE_EXECUTE_WRITECOPY);
                if (checkExecuteFlag)
                {
                    .....
                    if (!memoryAvEngin->ScanProcessBlocks(memoryStreamPtr, false, callback)) {
                        printf("ScanProcessBlock error");
                    }
                    .....
                }
            }
            // 跳到下一个内存区域
            address = reinterpret_cast<SIZE_T>(mbi.BaseAddress) + mbi.RegionSize;
        }

由于VirtualAlloc分配的内存是RWX属性并且不是MEM_IMAGE,所以会被扫出来后匹配特征码。

缺陷

实际上，与大家想的不同，安全软件通常不会直接报RWX为病毒(不过部分**EDR会这样做)。这个原因是 实际环境中，基本每个电脑都会或多或少的有几个RWX内存，jit，广告软件，部分加壳软件居多。所以杀毒软件不会看到就报，他一定匹配特征码，并且做匹配:
比如ES的yara为例子:
https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_CobaltStrike.yar

他不能看到就直接告警，会出现严重问题。必须依赖特征码，并且还有一个致命问题: 依赖进程有RWX的内存，否则就扫不到了。
总结一个痛点是，必须要能扫到RWX内存，并且必须要匹配特征.

所以,这种其实后来演变到所谓的”自研C2”/“二开CS”/“SleepMask”。为什么他们能工作的重要原因是,自研/二开的马，没有被拉黑特征，而Sleepmask等一派的东西，他们在休眠的时候是把RWX内存去掉了X属性甚至是混淆了shellcode，导致上面的遍历VAD的代码失效了

升级检测

在前面的一般检测遇到瓶颈后，安全厂商发明了新的办法，为了解决前面的所谓的匹配不到RWX的问题,可以用更激进的手段.这边有几种手段:

SleepMask: 检测所谓的RWX切换

部分厂商,比如ES通过TI-ETW检测virtualprotect的切换RWX内存，这样就检测了所谓的SleepMask因为这玩意会切换内存，这挺草台的说实在的，但是能用就不深入说了

不依赖特征: 检测shellcode API调用

为了更好的时机去检测,部分厂商使用API HOOK,去挂钩某些SYSCALL或者某些关键API，挂钩后，检测调用是否来自Shellcode,如果是直接拦截或者阻止,而且不止API调用,也能通过TIETW拿到某些来自shellcode的call从而检测.

对这块感兴趣的我强烈建议你购买一份冲鸭安全的EPP开发教程,此事在EPP开发里面有提到

缺陷

这几个检测手段的缺陷同样有问题,有几个问题:

  1. 盲目检测误报大 -生产环境几乎不能用,比如某些严格点策略的组织连x神游戏都打不开,打开直接被拦截.

  2. 为了消除误报,依然使用特征码 -虽然解决了SleepMask导致获取不到shellcode的问题,但是为了减少误报,依然会用特征码尝试对shellcode进行匹配,否则是没办法上生产环境的,依然会被自研C2绕过

  3. 各种花式syscall直接调用，ntdll unhook，调用栈欺骗绕过API的钩子

继续升级检测

大部分厂商在前面两个阶段就停止对抗了,毕竟用户电脑不是战场,而且手段越多误报越多,不方便运维.但是
部分好一点的厂商为了解决以上的手段,继续加码,对抗到底:
首先,使用CET技术或者其他调用栈完整性校验技术,去检测异常调用栈,这里分两种,常见是软件类的,不太常见的是硬件类的.先说硬件类型的:

CET技术:

Intel Processor Trace技术:

软件类型的:
[2025]SleepDuck-通用堆栈欺骗检测POC,检测SleepMask
SleepDuck：通用堆栈欺骗检测POC,检测SleepMask
TI-ETW结合调用栈:

天守EDR的动态指令追踪技术:

结合虚拟执行,检测调用栈完整性:

此类软/硬技术结合 就保证了获取的调用栈是真实可靠的,而不是被欺骗的.并且无法通过摘钩进行绕过.反而摘钩/栈欺骗会导致被检测.

缺陷

此类技术,有严重的缺陷,基于硬件的需要硬件达标,暂且不提

基于软件的技术,只能EDR来处理数据,EPP是处理不了这些数据的,处理了也会卡本机系统,因此只能在EDR上使用此类技术,成本没有办法降低.因此实际做到这一层的很少,实践中也遇到的非常少,总的来说因为成本太大,此类操作不太符合目前的安全市场行情

下一代展望

这里多扯几句，如果我以后还在干安全,并且让我来设计下一代怎么检测shellcode内存加载的操作的话,我会先思考两个问题,我们需要解决什么问题? 我们需要怎么做才能彻底解决他?

当前所有的检测主要有几个痛点:

  1. 检测成本太高

  2. 无论什么手段,为了防止误报,依然无法离开基于特征码的检测

  3. 其实整篇文章我故意忽略了一个细节,那如果我们不放到RWX内存呢,会怎么样?答案是全部拉闸,如果你了解外挂就会知道,外挂喜欢找代码洞把shellcode塞到文件段里面,这样就扫不到了.除非更进一步做CRC内存->文件完整性校验,那样成本更高了.

所以,要是让我来搞,我一定会选择语义检测，在如今全是LLMs的时代,我们不能再抱着传统不放手.
这是有可能的,我们完全可以这样做:

  1. 把shellcode/调用堆栈/等代码变成HLIL,类似于IDA的伪代码一样

  2. 把HLIL送到transformer-base的二分类器里面,就跟以前古早时期那种什么AI检测说的话是不是恶意的话一样.剩下的等结果就行,整个过程非常快,因为不是大模型,是小小模型.

这样会解决如下问题:

  1. 基于语义的分析,即便是不用AI,也能用规则驱动检测,比如检测PEB直接寻找的shellcode,比如检测shellcode里面的内容到底是在干什么,是混淆还是什么

  2. 能检测出不放到RWX段的shellcodes,因为他不需要关心是不是RWX,输入应该是调用栈的各个地址就能开始检测,并且由于没有特征匹配的环节,所以他的速度非常非常的快.

扩展阅读(广告)

我提到的语义分析目前真的不是什么技术难题,shellcode2hlil的引擎已经有了: 

[2025]在线样本分析平台,下一代文件云鉴定
大模型的病毒木马文件云鉴定平台(粉丝内测)

剩下的就是训练一个transformer分类器就行.
本系统已经有部分应用,不过目前接的是大模型,还没接transformer分类器,可以先用着,目前开放体验(还没开放shellcode/elf的检测,只开放了PE的):
基于大模型的病毒木马文件云鉴定
目前对于PE的效果非常好,同时其实平台也支持ELF和SHELLCODE,但是我现在暂时没开放,还需要调试这两个
比如VT 1报毒的木马:

常规ghost:

c#:

混淆:

重要的是,核心引擎只有6M,6M还是因为我带了一个libcurl

所以下一步,完全可以携带到客户端,做shellcode分析/病毒分析等.

阅读原文

跳转微信打开

]]> Tue, 13 Jan 2026 09:00:00 +0800 大模型的病毒木马文件云鉴定平台(粉丝内测) https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485767&idx=1&sn=2527efc71f3493583fa34c43a7eeec23 原创 huoji 2025-12-24 21:17 北京

上一篇文章说到的

基于大模型的病毒木马文件云鉴定

目前有粉丝内测平台了

微信回复 "分析平台" 得到访问地址

目前只支持PE文件, 这个服务器是一个1H 512M的机器 不要狠蹬

平台亮点

支持AI分析,智能出结果,准确率高,有可解释性:

反汇编:

有任何问题加群反馈(误报/不报):

阅读原文

跳转微信打开

]]> Wed, 24 Dec 2025 21:17:00 +0800 基于大模型的病毒木马文件云鉴定 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485757&idx=1&sn=6a9abd8c76b5537f73f64671ff48a7e7 原创 huoji 2025-12-22 10:00 北京

前言

不开玩笑的说,这玩意比实习生靠谱
事情的起因是一年前我说过做基于HLIL的语义驱动的杀毒引擎,现在年底了,也应该要拿出来了:
《2024年终: 木马病毒自动化特征提取&云端机器学习的思路分享》
2024年终: 木马病毒自动化特征提取&云端机器学习的思路分享

如果没LLM 我会选择用规则驱动去识别异常代码,但是LLM实在是太好用了，他比过去所有所谓的检出规则都好用，所以中途就修改了一下方案，就变成现在的效果了。

特点

他相比传统鉴定引擎，有如下优点:

  1. 大部分情况下不可绕过 传统规则引擎，能被各种混淆/加密绕过,而这个引擎,就相当于人搁那分析代码,所以各种花里胡哨的绕过反而会被标记成恶意

  2. 越来越强,检出能力和效果会随着样本积累变强

当然什么事情都有缺点,实践中他也有如下缺点:

  1. 非常依赖反编译引擎,如果反编译引擎拉闸比如不支持RUST,也没办法很好的适配LLM,模型会失去效果 -这个得持续优化代码才行

  2. 大模型容易受到提示词影响比较大,是真的比较大,提示词工程可能需要一段时间的磨练和积累 -这个得通过不断人工干预，得到一个数据合集后，再做微调才行，否则没什么好的办法.

  3. 模型不是专用模型，导致数据积累知识经验不够,目前所有主流的模型都对逆向不太熟悉,幻觉率高,导致检出效果不稳定. -这个可以跟2一样用一样的方法解决

  4. 成本太高 -大模型是通用模型拿来干这种检出成本太高了，但是也可以通过2的方法，搞一个比较小的模型，应该是OK的

技术架构

核心架构

本质上,我们最终目的是 让大模型读代码 然后输出结果.
第一步我们其实是需要一个靠谱的反编译引擎，本来我想直接做MCP的，但是实测下来,IDA/BN/NSA的那个反编译工具 均不能有效的输出想要的东西,更别说遇到ZIG OLLVM RUST golang就属于拉闸的那一步,因为他们没适配，而且速度慢。最重要的是代码不可控,比如BN在跑某些混淆会直接bug闪退,以及这些都要版权费,实在是太折腾了。所以2024年年底就开始折腾一个靠谱的/快速的反汇编引擎
具体可以看IDA的F5制作系列

IDA背后的原理入门(一): 简介&函数识别

IDA背后的原理入门(二): 函数大小计算

IDA原理入门(三): 控制流追踪与CFG Blocks构建

IDA原理入门(四): 函数参数识别

从0制作IDA的F5代码还原功能(hex-rays插件) 上

最终我实现了一个自定义的反汇编引擎,他效果比IDA差,但是给大模型读肯定是够用了,重要的是由于没有太多的编译器优化或者乱七八糟的组件,他的速度非常的快而且精准,大概速度是IDA的2-4倍


而且也专门做了对GO的支持,可能以后要做RUST的支持:

对GO的符号解析感兴趣吗?感兴趣的可以私聊我感兴趣,人多了(大于100个人),出一期专门说怎么处理GO的ABI/symbols的操作

反汇编引擎的技术架构上,走的是bn的路线,思路来自binnary ninja的blackhat演讲,简单来说,把汇编抽象成LLIL->MLIL->HLIL->CUSTOM IL（比如C/rust/go都行）
这个路线不仅成熟，而且也够现代，IDA有历史局限原因，这个就很蛋疼。
具体就不展开细说了，大部分时间我其实都在处理最后的HLIL的打印优化上（是的，从机器角度来说够用了，但是人要看得舒服就一定要做大量的打印优化，比如do while,for ,if else），相当于从头写了一个编译器优化pass，而retdec比较聪明，他们用LLVM做优化，但是LLVM也存在不可控，大，慢的问题，所以我最后决定还是自己做，反正是给AI看的。
总而言之，花了一年的摸鱼时光，我们现在就有了一个 快速，轻量，可跨平台的反编译器，支持LINUX和MAC和windows和国产系统.而且代码只有大概十万行:

还是DeepSeek

有了核心基础后,我们要考虑用什么AI模型.最终我选择了DEEPSEEK,原因无他,他便宜。
我们知道，工程应用和实验室不一样，工程应用一定要考虑成本，哪怕模型再好，成本太高肯定是不能接受的。DS的能力虽然在我看来做检出非常非常的中庸，但是他是最便宜的,在随随便便就没了几百万token的时代,便宜才是硬道理.

一千两百万Token只要四块钱,隔壁GPT哭晕在厕所.

当然这也不是吹DS好,只是因为DS够便宜,所以出问题算我的.他实践过程中真的有不少问题,我感觉是我为了兼容他,做了大量修改,而别的模型总是一次过,这里就不细说了,都是提示词和优化流程的问题.

结论

最后,我做了一个web节目和命令行,用于批量分析木马,做鉴定,并且给出结论:

AI检测到病毒的时候:

检测到OLLVM代码混淆

检测到游戏修改器:

mimikatz:

VT全绿银狐:

漏洞驱动:

不闭门造车

本来我想打着不闭门造车的想法加上马上2025年了,把这个开源的.
但是目前这个,完成度比较低,bug也贼多(尤其是反编译引擎),所以还是先等我把bug修的差不多了再说吧.不过目前整套引擎已经在外网部署了一套,感兴趣的朋友可以在底下投票,如果票数大于300则进一步搞一个先锋内测群.进一步探索大模型用在杀毒的能力.少于300投票则算了不搞了,浪费时间.

阅读原文

跳转微信打开

]]> Mon, 22 Dec 2025 10:00:00 +0800 DeepSeek V3.2策略游戏测试 | 进步很大 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485737&idx=1&sn=68961c19d35699cf80801677ac9f3839 众所周知昨天DS发布了V3.2.据说是极大的提高了智商,所以我准备拿上次的帝国时代2游戏竞技场来复测一次。 原创 huoji 2025-12-02 23:42 北京

众所周知昨天DS发布了V3.2.据说是极大的提高了智商,所以我准备拿上次的帝国时代2游戏竞技场来复测一次。让AI通过MCP工具操作游戏, 玩策略游戏，最终打败对手:

中秋特辑:中外AI大战!让AI们通过MCP玩帝国时代2

这些策略游戏是一个可以很好的考验语言模型的工具。

从资源调度，信息搜集，巨量token是否崩坏，MCP能力，战略决策能力上，能看出一个模型的综合能力.

上次只有两个模型是出彩的，一个是国产GLM ，另外一个是国外Claude SN 4.5，而DEEPSEEK属于是中等偏下那一桌

上次测评,DS的主要痛点是:

逐渐崩坏,一开始领先慢慢的变落后最后被反超

唯一一个主动投降的模型:

还要其他的问题，比如空间感知问题(一个农田，非要叠到其他农田上去，导致建造失败->反复建造->建造失败....)

而今天晚上发布的v3.2，这些痛点都解决了,首先是thinking过程中调用工具,终于让think模型可以跑tools了而不用额外的<call_tools>

不过这个东西缺点也很明显，在我的MCP里面，我也不知道为什么，他会无限在think状态调用工具....希望后续官方能出一个限制调用工具次数的东西，否则他的所有输出全部在think里面而不在正常的回复里面了.

但是这些都不是重点，这次新版本，实测几次下来，无论是空间感，资源调度能力，还是MCP调用能力，还是逐渐崩坏的问题 都已经解决了! 并且价格居然还是那么低,低到我不得不连夜发这一篇文章的地步.

空间感:

之前ds最显著的问题是,他一个建筑,非要放到另外一个建筑旁边,他对x y z的把握非常非常差差，导致他想新建建筑，但是这个建筑被其他建筑占位了，他又想调整，导致死循环，这一点在建造农田和伐木场的时候尤其明显。

而经过多次测试，这次版本中解决了这个问题,至少农田不卡壳了...

伐木场的摆放顺序也非常正确

他的农田摆放居然懂得围绕磨坊来摆放,这以前版本是不可能的

建造的时候已经学会正确的先观察有没有物体防止堆叠

资源调度能力

之前的一大痛点就是,他的村民调度能力实在是不行,经常出现十来个村民搁那空闲不干事。这次资源调度表现比之前好很多，经过多轮测试，他现在已经有意识的让村民保持干活状态了:

闲置率基本能保持在1-5个左右:

会主动让村民干活

而升级时代的速度,和资源的分数上,也是首次出现超过AI的水平

战略决策能力

GLM/Claude知道在封建时代派兵骚扰，城堡时代攻城武器攻击，并且建造箭塔进行防御,之前DS只会防御不会进攻,进攻也只是搞笑的几个骑士,也不会造攻城武器,而这次有了很大进步:

他的进攻计划,跟其他不同,他进攻之前一定要满科技:

然后准备攻城武器:

跟上次不同，他现在会袭扰农民战术:

派出的部队:

不过有点搞笑,派出的部队走得太慢打不到敌人，背后跟了一堆野生动物

然后这些部队被野生动物吃掉了

标记地点,造攻城武器:

总的来说,有进步,但是没GLM/Claude那么聪明,这两个会直城，并且派兵骚扰，建造攻城武器联合进攻，造弓箭手。而DS更倾向于两个兵种，长矛兵和骑士。。。不知道为什么

价格

价格真的是这个模型最大的优势，在一场接近2小时的帝国时代2的MCP高强度调用后，我居然实际只花费了27块

而同样的模型GLM花费200左右，claude花费了1200人民币 ，还是用了1rmb=1美刀的中转站。要不然我就直接破产了。

所以别说好不好用，他价格就这样，这种价格，即便是代码写出bug了，也是我的问题

总结

从最终效果来看，进步非常之大，相当于从完全不能用的人机，变成了能跟帝国时代2里面的简单电脑切磋的水平.....虽然策略类游戏跟GLM和CLAUDE还有一段距离.但是考虑到价格因素，让我们继续拭目以待.....(话说回来，也就GLM和CLAUDE能打策略类游戏，GPT5也打不了)

当前DSV3.2和AI的比分,两个相似,相当 于是简单人机吧:

隔壁GLM的,碾压水平,起码相当于困难电脑:

现在这么便宜的东西都已经效果这么好了，已经迫不及待的等下一个大版本了

阅读原文

跳转微信打开

]]> Tue, 02 Dec 2025 23:42:00 +0800 "破碎注入"无痕注入不使用任何进程句柄的注入技术原理分析 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485690&idx=1&sn=774ef1b6f5a1299414aa781c979d71f7 破碎攻击(Shatter Attack)概念来源所谓 Shatter Attack 是一种早期（主要在 Win 原创 huoji 2025-11-27 00:18 北京

破碎攻击(Shatter Attack)

概念来源

所谓 Shatter Attack 是一种早期（主要在 Windows NT、Windows 2000、Windows XP 时代被关注）的本地特权提升攻击方式。它利用的是 Windows 消息机制（Windows Messages）在同一桌面（desktop）环境下没有足够的安全隔离这一漏洞。

Windows 消息机制的背景

在 Windows 图形界面系统里，GUI 线程之间可以通过 SendMessage / PostMessage 等 API 发送消息。

这些消息（WM_XXX）会被目标窗口的回调过程（WindowProc 或过程函数）处理。

在设计上，所有同一交互会话中的应用程序都可以给彼此发送消息——包括输入消息、控制消息、甚至某些带有内存指针的结构（如 WM_TIMER、WM_COPYDATA、WM_SETTEXT）。如果目标进程是一个高权限进程（例如以管理员账户运行的 GUI 程序），而攻击者的低权限进程能向它发送精心构造的消息，就有可能诱使目标进程执行任意代码。

攻击原理

攻击者写一个低权限程序，找到同一桌面上运行的高权限进程窗口句柄（比如系统配置工具、服务管理器 GUI）。
利用 Windows 消息机制，向窗口过程发送带有指针的消息，让高权限进程执行某种动作（如调用回调函数、写入/读出内存）。
因为消息处理代码是在目标进程的上下文中执行的，这会让攻击者的代码在高权限进程里运行，从而提升权限。

使用的漏洞点

当时的核心问题：

高权限 GUI 程序与低权限 GUI 程序运行在同一个交互桌面 (interactive desktop) 上。
Windows 消息机制在用户模式下允许跨进程发送，并且缺乏足够的权限检查。
这种情况就被形象地称为 “Shatter”（打碎安全界限）攻击，因为它“打碎”了权限隔离的边界。

影响与修复

微软在后续更新（尤其是 Windows XP SP2 以后）中，加强了对 SendMessage 等 API 的检查，限制不同安全级别进程之间的消息交互。
从 Windows Vista 开始，引入了 “用户界面特权隔离” (User Interface Privilege Isolation, UIPI) / 低完整性级别机制，阻止低权限程序向高权限程序发送某些危险消息。

现代复兴

这个跟Storm-0978的利用路线一样,我们先说一下时间线:

深度研究APT组织Storm0978的高级注入技术StepBear

2017年最开始被人拿去在CSGO上搞外挂，因为这是一种不用进程句柄的远程进程读写技术

2022年又被提出来了一次

并且有人提到有恶意软件在使用

2023年的时候跟汪总稍微研究了一下,因为我发现有人利用,所以才接触到此类技术,稍微在key08提了一嘴:
[2023]阻止window hook exploit meme
https://key08.com/index.php/2023/12/30/1823.html

2024年就看到毛子APT在大规模滥用了

再然后,这种东西就跟VMP3源码一样，传来传去,到最后免费送了, 所以到现在,被开源了,那也没什么好藏着掖着的了,直接来介绍这块吧.

这项技术的优点的:

  1. 不用任何句柄

    ,这意味着,大部分常见的EDR/EPP检测注入手段全部失效.

  2. 很难进行行为检测,恶意软件利用基本能实现断链.

缺点:

  1. 开了CFG拉闸

  2. 很多窗口默认都开了CFG, 所以一般游戏用得多.但是对于安全领域,总有些窗口是没CFG的

没开CFG的窗口

开了的:

核心原理介绍

让AI复习一下setwindowshook的工作原理

发现盲点了吗~ 通过setwindowshook我们可以实现让具有窗口的程序执行任意代码

任意代码执行

SetWindowsHookEx负责设置要执行的位置,而我们还需要执行的代码，而SendMessage是非常好的执行的API,但是我们依然要找个gate,来把 msg->wparam、msg->lparam 和 msg->id 反序列化到三个不同的寄存器，然后通过 JMP [RAX] 调用 msg->lparam
所以作者准备了两个gate,作为布局,分别是RtlpFcChangeRegistrationCallback和_PsxaCallOwner

而毛子的APT组织用的是I_RpcFreePipeBuffer

整个流程如下

 SendMessageA(hwnd, WM_APPCOMMAND, wparam, lparam)
      ↓
  SetWindowsHookEx的 WH_SHELL Hook 被触发，执行 w (write gadget)
      ↓
  w 读取 wparam 结构体中的 function_ptr (即 t)
      ↓
  t (trampoline) 解析参数，调用 memcpy 字段指向的实际函数
      ↓
  实际目标函数执行 (RtlCopyString, malloc, 或任意函数)

第一个gate

这个代码里面，作者第一个gate是
RtlpFcChangeRegistrationCallback
一旦发送消息后,目标进程就会执行
gate_one(nCode, wParam, lParam)
而这个地方长这样:

改个名字：

__int64 __fastcall RtlpFcChangeRegistrationCallback(__int64 a1, __int64 a2)
{
  RtlAcquireSRWLockExclusive(a2 + 0x20);
  (*(void (__fastcall **)(_QWORD))(a2 + 0x10))(*(_QWORD *)(a2 + 0x18));
  return RtlReleaseSRWLockExclusive(a2 + 32);
}

他会执行wParam+0x10的代码,并且把0x18当作参数1传入到里面,也就是开始执行第二个gate

第二个gate

第二个gate在shell32里面,叫做_PsxaCallOwner,参数1成了前一个gate写的wpawn + 0x18了
而参数2,rdx成了之前的wpawn的0+0x8了:

然后就会call rax,这个rax本来应该是0的,但是前一个RtlpFcChangeRegistrationCallback会设置rax=rbx+0x10 也就是wpawn + 0x10 所以这玩意就成最终的call函数地址了:

从而实现了任意进程函数调用,任意进程读写.而不用任何windows的API.一次能读写8字节数据..

总结

让AI画了个图

检测

他不是完全不能检测,如果EDR采集了窗口数据源,或者像xxx一样有核晶或者infinityhook的话,就非常容易检测了,所幸,win32k数据源，hypervisor，infinityhook这三个已经成为大部分安全软件的基础设施组件了.所以检测起来不难.就拿EDR来说,他的检测结果跟之前的APT的检测结果完全一样,就是因为EDR采集了win32k数据源

源码

本人不是作者,不对它具有任何法律责任
https://github.com/waryas/WaryasSWHE

再次强调,本公众号不做任何红队内容.这次也只是别人的开源技术分析.

后续

现在回过头看毛子的APT的破碎注入过程,他们选择的应该是能避免CFG违规触发的调用路线,而这份代码,如果开了CFG,就举步维艰了.可能这就是APT跟民用的差距?

阅读原文

跳转微信打开

]]> Thu, 27 Nov 2025 00:18:00 +0800 安全开发(终章): 主动防御架构设计/查杀引擎设计/下一代查杀引擎展望 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485673&idx=1&sn=e36d59a9e8830c80fac9575eefba4d6e 原创 huoji 2025-11-17 10:00 北京

前言

终于,我们迎来了整个系列的完结,在此之前请阅读之前所有内容,因为本章包含了大量信息,不可以逃课.

安全开发: 实现拦截病毒并且弹窗

[预约订阅]高级安全研究之路:拒绝内耗,通过阅读提高自己

在上一篇中,核心EPP的功能,内核通讯<->查杀<->UI 我们已经搞定了(虽然很多问题)
因此，其他的“功能” 比如主动防御/乱七八糟的杀毒/也只是基于这个核心功能的对外扩展.因此我决定不再这些乱七八糟的功能具体细节代码上浪费时间,只说一下咋实现.
本节主要内容:

  1. 目前要解决的问题

  2. 主动防御设计

    1. 本地规则系统设计

    2. 云主防设计

    3. 主动防御缺陷

  3. 查杀引擎设计

    1. 特征杀毒设计

    2. 启发查杀设计

    3. AI查杀设计

    4. 云杀毒引擎设计

    5. 目前主流查杀引擎缺陷

  4. 更好的查杀引擎展望

  5. 题外话: 为什么我们需要用EDR?

  6. 结语

其实本来还想写更多的,但是考虑到读者消化能力有限,还是别写太多了.

要解决的问题

这里列举一下目前整套系统存在的问题,以及咋解决,但是不给出具体解决代码了,毕竟DEMO和商业化,路差的很远.

  1. IOCP通讯 -> 我们的通讯机制还是队列通讯,这是异步的而且容易卡系统.为了实现主动防御，软件管控等功能，需要做IOCP的通讯，具体自己问GPT咋实现吧

  2. UI/查杀分离 我们现在的R3模块是UI+查杀+高权限一起的,这不是设计失误,这只是为了简化,严格来说，查杀服务，和驱动通讯的服务，应该是单独的一个exe并且以service启动,而UI只低权限用RPC/PIPE/ALPC/GRPC等手段跟那个exe通讯.而不是在一起。在一起会有几个问题,比如UI不启动功能不生效,比如不要UAC功能就不生效,不开UI就没主动防御等问题.

  3. UI架构,CEF过于臃肿,可能的替代方案是:QT,不过这玩意bug也多,WEBVIEW,这个不支持老版本的windows,新版本倒挺不错的.DUI这个最完美,360等一众杀毒软件都是这个做的.不过这玩意坑也多,而且对技术要求高.所以看情况来

  4. 驱动鉴权,内部签名. 如你所见,我们现在的驱动通讯是没签名验证的,所以会导致什么人都可以调用我们的驱动,从而成为漏洞驱动,所以,驱动要校验一下R3的内部签名,具体方法就不说了,自己问一下GPT,不过值得注意的是,校验是不是内部签名也不安全,因为有DLL注入/白加黑劫持的风险,所以还需要校验进程内存完整性或者改用PPL保护方案.否则就会被劫持.

主动防御设计

注意: 设计主动防御之前,必须要先把通讯队列做成IOCP的那种优化,否则做出来的效果会不理想

主动防御的设计,其实很简单,比你想的简单太多了,回顾上一章节,我们进程创建的时候就判断了MD5是不是黑的,如果是黑的就弹窗.而主动防御,就是把一堆信息,同样的方法塞到R3,然后R3写规则系统去判断.
当然不止进程创建,还能塞模块加载(loadimage),文件操作(minifilter),网络操作(WFP,不过注意这个只能异步,因为WFP的回调都是DPC级别的)等等的内核事件发给R3,玩的野一点的,hypervisor或者inifityhook的事件也可以发给R3.总之一句话,内核把事件发给R3.

阅读原文

跳转微信打开

]]> Mon, 17 Nov 2025 10:00:00 +0800 VMP3源码学习——虚拟化 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485663&idx=1&sn=508c4ad1f5163381c0727a6bccd48cc1 原创 CrazyHarb 2025-11-16 10:02 北京

VMP3源码学习——虚拟化

背景：

前文中我们已经分析了源码中的变异核心指令，我们书接上文，本文中我们来看一下VMP中的虚拟化相关功能的代码，vmp的运行流程可以参考鸭哥的(VMP3.x内部原理详解与还原思路)，链接我放在本文最后的参考中了，说实话，我不是这方面专家，所以本文中涉及的逻辑仅限于windows x64下的PE文件的高级版本VMP

 前文摘要

VMP源码学习(1) 变异分析与代码bug

入口点：

C                   // intel 虚拟化入口                  
   void IntelFunction::CompileToVM(const CompileContext &ctx);

HANDLERS分析：

1. entry_command_

这个就是鸭哥文章中提到的vmentry，该代码的最终效果可参考文章中的内容，它在源码中初始化流程为：

1初始化不使用寄存器列表，x64下是R12 ~ R15

1在rbx、rbp、rsi、rdi、R8~R11这几个寄存器之间，不放回取四个寄存器，分别表示密钥寄存器、伪指令寄存器(VIP)、伪栈寄存器(VSP)、跳转寄存器

1初始化入口加密器，其实就是随机几条指令add sub xor inc dec bswap rol ror not neg这几个指令进行随机，指令条数大于100，或者大于3且随机数的最低位为1（我称它为随机数命中），则生成结束。同等道理，如果vmp选项中选中了加密字节码，也会随机一个指令加密器

1开始填入代码，把rax、rcx、rdx、rbx、rbp、rsi、rdi、R8~R15、rflag随机交换顺序后，全部入栈

1随机一个空闲寄存器存储当前段地址，并把该寄存器入栈

1将rsp + 0x90的值赋给伪指令寄存器，0x90代表前面压入栈的16个寄存器+1个随机的空闲寄存器+call的返回地址，共18*8 = 0x12*8 = 0x90，取到的是vm入口入栈的参数

1通过入口加密器解密伪指令寄存器，解密后加上前面的当前的段地址，当然这些运算都是低32位的，如果镜像地址高出32位地址，就把高位地址加上

1把rsp栈指针赋值给伪栈寄存器，并执行 rsp -= 0x180后，将RSP进行对齐操作，即

C                  
RSP &= 0xFFFFFFFFFFFFFFF0

Assembly language                  
示例代码                  pushrdi                  
pushr9                  
pushrbx                  
pushr11                  
pushrcx                  
pushrax                  
pushr12                  
pushr8                  
pushrsi                  
pushrbp                  
pushr10                  
pushfq                  
pushr14                  
pushrdx                  
pushr15                  
pushr13                  
; 以上是全部入栈                  
movrbp, 7FF50F570000h                  
pushrbp; 存储当前段的地址                  
movrbx, [rsp+90h]; 取到call处的参数， 17 个push一个返回地址18 * 8 = 0x90                  
; 解密算法开始                  
notebx                  
rolebx, 2                  
decebx                  
xorebx, 1DBA2712h                  
; 解密算法结束                  
addrbx, rbp; 加上段地址算出来地址                  
movrax, 100000000h; x64 位高位有1，加上                  
addrbx, rax; rbx 你就是伪指令寄存器了                  
movrsi, rsp; rsi 你就是伪栈指针寄存器了                  
subrsp, 180h                  
andrsp, 0FFFFFFFFFFFFFFF0h; rsp 分配栈空间

2. init_command_

1初始化密钥寄存器，即把伪指令寄存器的值减掉当前的段的地址得到的值赋值给密钥寄存器

1把当前的RIP赋值给跳转寄存器，开始添加EndHandler指令，并跳转到下一个Handler，等...等一下，这个EndHandler是啥？

3. ReadCommand

要了解EndHandler，我们首先来了解一下VMP读取指令的动作，它主要动作是滚动密钥寄存器，读取下一条指令码

1首先会从伪指令寄存器中读取4字节的下一个指令，但这个读取动作会分为两种，分为倒序和正序，这个是随机的，如果是倒序，则先给伪寄存器指令减4，再读取4字节内容；如果是正序，则先读取4字节，再给伪寄存器加4

1读取出来的指令值，先与密钥寄存器进行异或，再根据指令加密器（注意不是寄存器）对数据进行解密

1最后密钥寄存器会与结果进行异或，达到滚动密钥寄存器的目的

1返回解密出来的结果

4. EndHandler

好了，我们已经了解了读取指令的动作，那么HandlerEnd这部分逻辑就简单了，这部分在每一个Handler中都会出现，它主要动作是调用读取指令进行读取，然后将值加到跳转寄存器，并跳转过去

这里面有一个特殊的点，如果参数指定了目标指令地址，那就会跳到目标指令地址中，但是还是会执行一次读取指令的动作

Assembly language                  movr10, rbx; r10 你就是密钥寄存器了                  
movrdx, 7FF50F570000h                  
subr10, rdx; 减掉段地址                  
lear11, [#5]; 获取当前rip地址到r11，你就是跳转寄存器了                  
;EndHandler                  
; 下面的指令就是ReadCommand，看来是倒序                  
subrbx, 4                  
moveax, [rbx]; 挪动指针，然后读取4字节                  
xoreax, r10d ; 先和r10密钥寄存器进行异或                  
; 下面是解密算法                  
deceax                  
roleax, 17h                  
subeax, 3F47718Ah                  
negeax                  
roleax, 1Eh                  
; 回填r10，滚动更新r10密钥寄存器                  
pushr10                  
xor[rsp], eax                  
popr10                  
; ReadCommand 结束                  
movsxdrax, eax                  
addr11, rax;加到r11 跳转寄存器上                  
jmpr11; 跳！

5. check_stack

别误会，这个Handler并不是对栈做了多么严谨的判断，仅仅判断了一下伪寄存器空间用了是否超过了0x40大小，如果超过了，就把rsp移动到当前栈指针上面0x180的位置，并把原始位置的0x100字节拷贝过去（在golang里面是乘以2，估计这么设计是有什么说法）

Assembly language                  learcx, [rsp+140h]                  
; 由于栈分配了至少0x180的大小，判断伪栈寄存器用的空间是否少于0x40，少于的话，直接进行执行下一条指令                  
cmprsi, rcx                  
ja@F                  
movrax, rsp; 这个位置证明栈空间不够了，那就把rsp移动到伪寄存器 - 0x180的位置                  
movrcx, 100h                  
lear8, [rsi-80h]                  
andr8, 0FFFFFFFFFFFFFFF0h                  
subr8, rcx                  
movrsp, r8                  
pushrsi                  
pushfq                  
movrsi, rax; 把之前的rsp拷贝0x100个字节到新的rsp位置                  
movrdi, r8                  
cld                  
rep movsb                  
popfq                  
poprsi                  
@@:                  
jmpr11

6. push register

Assembly language                  ; ReadCommand Handler                  
subrbx, 1                  
movzxr8d, byte ptr [rbx]                  
xorr8b, r10b                  
rorr8b, 2                  
decr8b                  
notr8b                  
incr8b                  
xorr10b, r8b                  
// 获取对应寄存器/局部变量的值                  
movr9, [rsp+r8]                  
// 移动伪寄存器栈的指针，将值写入，完成压入动作                  
subrsi, 8                  
mov[rsi], r9                  
// EndHandler 动作                  
subrbx, 4                  
movedx, [rbx]                  
xoredx, r10d                  
notedx                  
decedx                  
bswapedx                  
roredx, 5                  
incedx                  
pushr10                  
xor[rsp], edx                  
popr10                  
movsxdrdx, edx                  
addr11, rdx                  
jmpcheck_stack

7. pop Register

Assembly language                  // 读取伪栈寄存器的值，并移动伪栈寄存器指针                  
movrdi, [rsi]                  
addrsi, 8                  
// ReadCommand 动作                  
subrbx, 1                  
movzxecx, byte ptr [rbx]                  
xorcl, r10b                  
addcl, 32h ; '2'                  
notcl                  
negcl                  
deccl                  
negcl                  
xorr10b, cl                  
// 写入对应的寄存器/变量中                  
mov[rsp+rcx], rdi                  
// EndHandler动作                  
subrbx, 4                  
movecx, [rbx]                  
xorecx, r10d                  
subecx, 7ACA04FBh                  
bswapecx                  
addecx, 2B355FD5h                  
rolecx, 10h                  
dececx                  
pushr10                  
xor[rsp], ecx                  
popr10                  
movsxdrcx, ecx                  
addr11, rcx                  
jmpr11

8. push value

Assembly language                  ; ReadCommand 动作                  
subrbx, 8                  
movrcx, [rbx]                  
xorrcx, r10                  
incrcx                  
xorrcx, 0CCC15C6h                  
notrcx                  
incrcx                  
xorrcx, 456C3348h                  
xorr10, rcx                  
// 移动伪栈指针，将值写入，完成压入动作                  
subrsi, 8                  
mov[rsi], rcx                  
// EndHandler动作                  
subrbx, 4                  
movr8d, [rbx]                  
xorr8d, r10d                  
notr8d                  
incr8d                  
notr8d                  
addr8d, 4FEA55AAh                  
pushr10                  
xor[rsp], r8d                  
popr10                  
movsxdr8, r8d                  
addr11, r8                  
jmpcheckStackHandler

9. add

Assembly language                  ; 取出伪栈寄存器上面的两个参数                  
movrcx, [rsi]                  
movr9, [rsi+8]                  
// 相加                  
addrcx, r9                  
// 结果返回结构体                   
// {                  
//uint64 rflags;                  
//uint64 result;                  
// }                  
// 由于输入参数和返回大小一样，所以不会对伪栈寄存器进行任何移动                  
mov[rsi+8], rcx                  
pushfq                  
popqword ptr [rsi]                  
// EndHandler 动作                  
subrbx, 4                  
movebp, [rbx]                  
xorebp, r10d                  
bswapebp                  
addebp, 42EC7D95h                  
rolebp, 12h                  
decebp                  
pushr10                  
xor[rsp], ebp                  
popr10                  
movsxdrbp, ebp                  
addr11, rbp                  
jmpr11

10. call

Assembly language                  ; 这里由于是再次entry_command_过了，所以，伪寄存器已经重新随机了                  
; pcode_register(VIP) --->rbp                  
; jmp_register 跳转寄存器----> r11                  
; crypt_register_ 加密寄存器----> r9                  
; stack_register(VSP) 伪堆栈寄存器 ----> ebx                  
; ReadCommand 动作                  
subrbp, 1                  
movzxedi, byte ptr [rbp+0]                  
xordil, r9b                  
roldil, 1                  
decdil                  
rordil, 4                  
notdil                  
rordil, 5                  
xorr9b, dil                  
; 伪寄存器入栈，堆栈寄存器赋值给rbp                  
pushrbp                  
pushr11                  
pushr9                  
movrbp, rbx                  
; edi 解密出来是参数的个数                  
movebx, edi                  
movedx, ebx                  
xorecx, ecx                  
; 参数个数小于等于4，则直接跳转                  
cmpebx, 4                  
jbelower_or_equal_4                  
movedx, 4                  
leaecx, [rbx-4]; 存储入栈的参数                  
;我们的是x64，所以rdx rcx r8 r9 剩下的入栈                  
lower_or_equal_4:                  
shlecx, 3; *8入栈的总大小                  
shledx, 3; *8计算参数总大小                  
movrax, rbp                  
addrax, rdx; 伪堆栈指针跳过总参数大小                  
mov[rbp-8], rax; 保存原始伪堆栈指针                  
mov[rbp-10h], rsp ; 保存原始rsp                  
subrsp, rcx; 分配入栈参数                  
// 对齐rsp                  
andrsp, 0FFFFFFFFFFFFFFF0h                  
addrsp, rcx; 堆栈加回去                  
testebx, ebx                  
jzcore_call; 0 个参数直接调用call                  
loop_arg_deal:                  
movrax, [rbp+rbx*8+0]; 取一个参数                  
cmpebx, 1                   
jnzjudge_2; 不是1个参数就跳转                  
movrcx, rax; 如果只有一个参数就放在rcx中                  
jmpdec_arg_count                  
judge_2:                  
cmpebx, 2                  
jnzjudge_3 ; 如果不是2个参数，就跳转                  
movrdx, rax; 第二个参数放入rdx中                  
jmpdec_arg_count                  
judge_3:                  
cmpebx, 3                  
jnzjudge_4 ;如果不是3个参数，就跳转                  
movr8, rax; 第三个参数放入r8中                  
jmpdec_arg_count                  
judge_4:                  
cmpebx, 4                  
jnzexternal_args ; 如果大于4个参数，就把当前的入栈                  
movr9, rax; 第四个参数放入r9中                  
jmpdec_arg_count                  
external_args:                  
pushqword ptr [rbp+rbx*8+20h]                  
dec_arg_count:                  
subebx, 1; 剩余参数-1                  
jnzloop_arg_deal                  
core_call:                  
movrax, [rbp+0]; 取出来函数地址                  
subrsp, 20h; 分配0x20个4参数空间                  
callrax; 调用                  
movrsp, [rbp-10h]; 恢复堆栈                  
movrbp, [rbp-8]; 恢复伪栈寄存器                  
mov[rbp+0], rax; 结果存入                  
movrbx, rbp; 伪寄存器恢复                  
popr9                  
popr11                  
poprbp                  
; EndHandler                  
subrbp, 4                  
movecx, [rbp+0]                  
xorecx, r9d                  
subecx, 7D526FFAh                  
bswapecx                  
xorecx, 24E27C67h                  
notecx                  
incecx                  
bswapecx                  
pushr9                  
xor[rsp], ecx                  
popr9                  
movsxdrcx, ecx                  
addr11, rcx                  
jmpr11

11. push [address]

根据前文的handler总结，规律大差不差，后面的handler我们用简单的伪代码来表示一下核心逻辑

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [reg1]                  
sub stack_registr_, result_size - operand_size                  
[stack_registr_] = reg2

12. pop [address]

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [stack_registr_ + 8]                  
add stack_registr_, operand_size                  
mov [reg1], reg2

13. push segment register

Assembly language                  mov reg1, seg                  
sub stack_registr_, 2                  
mov word ptr [stack_registr_], reg1

14. Pop segment register

Assembly language                  mov reg1, [stack_registr_]                  
add stack_registr_, operand_size                  
mov seg, reg1

15. Push debug register

Assembly language                  mov reg1, DrN                  
sub stack_registr_, 8                  
mov [stack_registr_], reg1

16. Pop debug register

Assembly language                  mov reg1, [stack_registr_]                  
add stack_registr_, 8                  
mov i, reg1

17. Push control register

Assembly language                  mov reg1, CrN                  
sub stack_registr_, 8                  
mov [stack_registr_], reg1

18. Pop control register

Assembly language                  mov reg1, [stack_registr_]                  
add stack_registr_, 8                  
mov CrN, reg1

19. Push rsp

Assembly language                  mov reg1, stack_registr_                  
sub stack_registr_, 8                  
mov [stack_registr_], reg1

20. Pop rsp

Assembly language                  
mov stack_registr_, [stack_registr_]

21. Nor

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [stack_registr_ + mov_size]                  
sub stack_registr_, offset                  
not reg1                  
not reg2                  
and reg1, reg2                  
mov [stack_registr_ + 8]， reg1                  
pushfq                  
pop [stack_registr_]

22. Nand

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [stack_registr_ + mov_size]                  
sub stack_registr_, offset                  
not reg1                  
not reg2                  
or reg1, reg2                  
mov [stack_registr_ + 8], reg1                  
pushfq                  
pop [stack_registr_]

23. shl/shr

Assembly language                  mov reg1, [stack_registr_]                  
mov cl, [stack_registr_ + mov_size]                  
sub stack_registr_, offset                  
shl/shr reg1, cl                  
mov [stack_registr_ + 8], reg1                  
pushfq                  
pop [stack_registr_]

24. rcl/rcr

Assembly language                  mov reg1, [stack_registr_]                  
mov cx, [stack_registr_ + mov_size]                  
sub stack_registr_, offset                  
shr ch, 1                  
rcx/rcr reg1, cl                  
mov [stack_registr_ + 8], reg1                  
pushfq                  
pop [stack_registr_]

25. shld/shrd

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [stack_registr_ + size]                  
mov cl, [stack_registr_ + size * 2]                  
sub stack_registr_, offset                  
shld/shrd reg1, reg2, cl                  
mov [stack_registr_ + 8], reg1                  
pushfq                  
pop [stack_registr_]

26. div/idiv

Assembly language                  mov rax, [stack_registr_]                  
mov rcx, [stack_registr_ + mov_size]                  
sub rsp, offset                  
div/idiv rcx                  
mov [stack_registr_], rax                  
pushfq                  
pop [stack_registr_]

27. mul/imul

Assembly language                  mov rax, [stack_registr_ + mov_size]                  
mov rdx, [stack_registr_]                  
sub rsp, offset                  
mul/imul rdx                  
mov [stack_registr_ + 8], rdx                  
mov [stack_registr_ + 8 + mov_size], rax                  
pushfq                  
pop [stack_registr_]

28. fild, fld, fadd, fsub, fsubr, fstp, fst, fist, fistp, fdiv, fmul, fcomp, fstcw, fldcw, fstsw

Assembly language                  
command [stack_registr_]

29. wait, fchs, fsqrt, f2xm1, fabs, fclex, fcos, fdecstp, fincstp, finit, fldln2, fldz, fld1, fldpi, fpatan, fprem, fprem1, fptan, frndint, fsin, ftst, fyl2x, fldlg2

Assembly language                  
command

30. ret/iret

Assembly language                  mov rsp, stack_registr_                  
pop all register                  
ret/iret

31. popf

Assembly language                  push [stack_registr_]                  
add stack_registr_, 8                  
popfq

32. Jmp

Assembly language                  mov reg1, [stack_registr_]; 这里读取了但没人用                  
add stack_registr_, 8                  
jmp xxx

33. rdtsc

Assembly language                  rdtsc                  
sub stack_registr_, 8                  
mov [stack_registr_], edx                  
mov [stack_registr_ + 4], eax

34. Cpuid

Assembly language                  mov rax, [stack_registr_]                  
mov reg1, stack_registr_                  
push rbx                  
cpuid                  
sub reg1, 12                  
mov [reg1 + 12], eax                  
mov [reg1 + 8], ebx                  
mov [reg1 + 4], ecx                  
mov [reg1], edx                  
pop rbx                  
mov stack_registr_, reg1

35. Syscall

Assembly language                  call syscallflag                  
return                   
syscallflag:                   
mov r10, rcx                  
syscall                  
ret

36. Lock

Assembly language                  mov reg1, [stack_registr_]                  
mov reg2, [stack_registr_ + 8]                  
sub/add stack_registr_, offset和result_size对齐大小                  
lock command [reg1], reg2                  
; xchg: mov [stack_registr_], reg2break;                  
; xadd: mov [stack_registr_], reg2                  
pushfq                  
pop [stack_registr_]

VMCommand分析：

前面我们已经掌握了VMP的全部handler，那么，这些handler是如何串起来工作的呢？

通过前文的EndHandler我们可看到，每次跳转到下一个Handler之前都会读取伪指令寄存器中的数据，然后解密，再进行跳转，我们以

C++                  
pop rxx

为例，看一下代码中是如何处理的，入口点为：

C++                  
void IntelVirtualMachine::CompileCommand(IntelVMCommand &vm_command)

首先，代码先对寄存器做了判断，如果不为rsp，则获取，pop rxx的handler（Handlers 中的7)的入口点，并通过GetRegister随机一个寄存器偏移(针对栈)，并将该偏移放在虚拟指令集中

在函数的结尾，判断是否是开头第一个指令，如果是，则在开头插入4字节0；判断是否是末尾，如果不是末尾，则在末尾添加4字节0

即，假设有5个pop，例如：

C++                  pop rax                  
pop rbx                  
pop rcx                  
pop rdx                  
pop rsi

那么经过上面的函数，生成的伪指令为：

C++                  00 00 00 00 18 00 00 00 00                  
20 00 00 00 00                  
28 00 00 00 00                  
30 00 00 00 00                  
38 

当然，上面的伪指令是我随便填的，实际上的寄存器存储地址是随机的，通过针对handler的对比可以发现，一个pop读取了5个字节的伪指令寄存器，即(1字节寄存器地址偏移 + 4字节下一条指令地址偏移)

那么为什么第一条指令会多出来4个字节呢？那是因为entry_command_中也存在EndHandler

当然了，这些0是没办法直接跳转的，所以在

C++                  
IntelVirtualMachine::CompileBlock

对跳转地址做了修正

业务逻辑：

看到这，恭喜你已经完成了代码主体中的基本流程，我们假设一下，如果我们的代码是

C++                  
cpuid

那么，我们编译后的代码是34号 handler的 cpuid handler吗？答案是否定的，因为这里面还存在着一层业务逻辑

在函数IntelCommand::CompileToVM中我们可以看到，cpuid指令不仅增加了cpuid handler的逻辑，还在之前把rax寄存器的值入栈，执行结束后把结果出栈，我们回头看一下34号handler的结构，再回想一下handler的运行过程——参数放栈上，结果也放栈上，那么一切就都对的上了。

另外，如果是x64下的代码，vmp还会增加把几个寄存器高位清空的动作。其余的业务逻辑就不再贴出来，有时间大家可以自己copy一下源码

总结：

Handlers中的列表其实并不完整，因为VMP还会初始化几个包含少部分Handlers的虚拟指令列表——我们称为虚拟机，编译的过程中，vmp会随机一个虚拟机进行指令替换，所以可能会出现cpuid在一个地方为被虚拟化的指令，在另一个地方需要退出虚拟化才会执行cpuid，详情可以参考IntelVirtualMachineList::Prepare及BaseFunction::virtual_machine，这里就不再赘述了。

文章有很多不清晰或者不对的地方，希望大家帮忙指出，如果错误太大，请大家多多包涵，正如我开头所说的，我不是这方面的专家。

文章参考：

https://mp.weixin.qq.com/s/CpbOGakvdKkWAyZogxpwvw (VMP3.x内部原理详解与还原思路)

https://mp.weixin.qq.com/s/UU3fL70Jbw4uwGULxZeK6A (VMP源码学习(1) 变异分析与代码bug)

阅读原文

跳转微信打开

]]> Sun, 16 Nov 2025 10:02:00 +0800 通过分析加密流量快速检查手机是否中了APT远控 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485653&idx=1&sn=25c4f51fcb58dae070226023ced95ab8 原创 为了安全鸭 2025-10-20 09:00 北京

前言

最近 国家授时中心 被美国用三角测量行动同样的手法攻击了iphone
https://mp.weixin.qq.com/s/XPjT0BVOJPJxSmASW0tXTA
众所周知,windows的安全最容易做,即便是有0day,在windows下也一定有办法能检测。linux的安全看linux的系统版本,而手机,尤其是ios/安卓 那一坨,是压根做不了安全的.因为系统机制的问题,攻防完全不对等.

我就在想,我们如何在不用到MVT(Mobile Verification Toolkit)的情况下怎么快速的分析一个设备是否中了0day/apt的远控木马,毕竟开ADB或者iTunes备份都挺麻烦的.
首先我想到的是流量设备,因为他非常简单,手机接入网络这个操作谁都会,连个wifi就行
而且卡巴斯基发现三角测量行动也是的流量设备先分析到的.更早的飞马 也是流量设备捕获到的.
不过我家里也没IDS/NDR设备,也没软路由,搞个流量设备不现实,所以就有了今天主题.手搓一个简单的.

地址

整个项目地址
https://github.com/huoji120/mbnsc

这东西电脑应急响应也能用.不过windows上没设计解密RPC.MAC用了谷歌不维护的gopacket不知道能不能用.linux也得看gopacket的兼容性.

设计思路

整个设计路线非常粗暴,我们搞一个抓包工具,用go-packet用libpcap进行抓包.然后我们把数据包变成一个JSON,本来想变成ELK里面的,但是考虑到便携性,还是算了.我们没必要那么重.
之后就是python的分析了.而我们目的很明确,检测APT,所以思路是:

  1. IP/DNS/SNI 先过一次情报

  2. 检测抖动心跳 -> 这个是关键

  3. 流量模式匹配,匹配特定的流量

（1）很好理解
（2）主要目的是,中马后,通常是多少分钟/多少小时 来一次心跳,通过心跳来检测C2是绝对靠谱的.不会错的.要是看到10分钟一次/1分钟一次/一个小时一次的心跳,或者N久才连一次服务器的网络,那就是了.
（3）的主要目的是,辅助我们看流量的类型，虽然流量是加密的，但是我们任然可以通过接收/发送/频率做一定的模式匹配,去匹配一些相关的,上传,下载,http请求,混合交互,心跳等模式.虽然不是100%准确,但是很值得我们研究.
具体我们直接实战:

教程

部署

电脑上开热点,手机链接热点
然后,编译好go程序,直接运行,会显示出网卡列表,选择一个网卡,一定要选,热点的网卡.不要选错了.
如果你选错网卡了,会什么都抓不到.
如果你选了电脑的网卡,不是wifi热点的网卡,则会抓整个电脑的流量,而不是只抓手机的流量
所以选择手机的wifi的网卡很重要!(还要注意不要选wifi链别人的那个网卡,要选热点的那个网卡!)

选正确后
xxx.exe -i 网卡名字
然后手机访问网络都有链接:

这样才是正确的!

抓包开始后,建议操作,重启手机,并且息屏等10分钟或者一个小时,在电脑内存允许的情况下,放置久一点.因为我也不知道心跳什么时候回来
当抓到一定数量的包后,ctrl+c抓包软件,会生成一份JSON.用目录下的analyzer进行分析

python .\analyzer.py .\capture_stats_20251019_221220.json --proxy --proxy-host 127.0.0.1 --proxy-port 7890

如果你有OTX的威胁情报key,你也可以接:
https://otx.alienvault.com/
我本来想用国内的威胁情报的,但国内威胁情报API无一例外都收费,不如用国外的otx的

--otx-api-key YOUR_API_KEY

等一会,分析完毕后,我们就能看手机这段时间内访问的信息了:

这个html一共有两个部分组成,首先是图表,他是能快速分析的地方

另外一个是总览表格

快速威胁检测

如果你部署了OTX的API,拉到表格下面,有IOC

比如我的xred蠕虫的C2,我测试访问的
然后在图表里面也会有表格

注意,OTX的情报并不是准确的,他很多CDN服务器,114dns服务器之类的会被标记恶意,这个是正常的.毕竟他是社区驱动的.
而且考虑到apt的远控不太会暴露,所以IOC数据只能说看看就行.
第二就是国外IP

国外IP在一个手机里面占比非常少,建议快速check,国外和香港台湾的这几个IP.
第三就是看心跳
心跳包的特征如下:

这种就是非常典型的心跳包,你可以看到X秒来一次发送接受.

如果心跳包是已知手机域名,那没什么问题,如果你看到

  1. 一分钟以上来一次,或者十分钟来一次,或者一个小时来一次

  2. IP是非大陆地区

那你需要额外警惕.

建议用qax的威胁情报平台进行二次确认:
https://ti.qianxin.com/
我不推荐别的,因为qax的情报对APT追踪是最敏感的
还有就是辅助的,卡巴斯基的平台
https://opentip.kaspersky.com/
这两个二次确认即可

比如我的,虽然是心跳包,但是是小米手机追踪的东西,不知道是什么,但是应该是暂时没问题

其他流量特征

这有几种常见的模式匹配
比如这个,当你发现,send比recv小的时候,那一般就是下载流量,比如我这是美团下载的流量


被阻断的: 单向发送,没任何的recv的,比如如下是谷歌的域名被阻断了

典型心跳:

经过排查,这个IP是小米的消息通知推送,也确实是心跳,x秒一次:

上传,美团的report域名

结语

最后,经过检查,我确认我手机没问题.可以放心睡觉了

阅读原文

跳转微信打开

]]> Mon, 20 Oct 2025 09:00:00 +0800 中秋特辑:中外AI大战!让AI们通过MCP玩帝国时代2 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485632&idx=1&sn=5099048f6d21234acfacb5f13d2c7545 前言说来话长, 熟悉我的人都知道，我每年国庆都会在家整点活，去年是深度研究APT组织Storm0978的高级注 原创 为了安全鸭 2025-10-06 10:01 北京

前言

说来话长, 熟悉我的人都知道，我每年国庆都会在家整点活，去年是
深度研究APT组织Storm0978的高级注入技术StepBear
今年是AI通过MCP玩帝国时代2!
本系列非常非常非常复杂,原因是我一开始只是想做个能自动帮我玩帝国时代2的脚本,但是做着做着我突然觉得没意思,就改变想法搞个让大语言模型玩游戏的MCP。事实证明已经严重超出我得工作量了，不过经过快一个星期的逆向，分析，模型调用调优。我终于取得了进展。这一切都是值得的!
我们先说偏娱乐的部分,中外AI大战!

帝国时代2

帝国时代2是我最喜欢的游戏，玩了快15年了.如果你不知道他是什么, 他是一款类似于红警的RTS游戏,跟红色警戒不同,他是慢节奏游戏,一把大概一个小时。所有人要采集资源,然后从黑暗时代升级到封建时代->城堡时代->帝王时代
然后互相伤害:

我用的是steam的决定版本,因为他还在更新:
https://store.steampowered.com/app/813780/Age_of_Empires_II_Definitive_Edition/

MCP

MCP的具体设计思路下一篇再说了,总之我们有了一个能让AI操控升级时代/移动/攻击/研究科技的MCP了
MCP代码大概长这样,claude写的,1000多行:

claude是第一个(也许是世界上/人类上第一个),从黑暗时代升级到封建时代的AI!

并且还会训练马厩

话不多说! 让我们直接开始主题! 但是在直接AI大战之前，我进行了一轮初筛，毕竟一局帝国时代2大概要一个小时，我没那么多时间浪费，而且这些模型还是要付费token用的，我也没那么多钱，所以我决定先拿现在的模型进行一波简单人机对战，谁赢了才选出来！

先说一下各个AI的表现吧,我们的AI Agent有两个模型在混合工作.一个是军师,他是各家模型的最强think模型,根据游戏状态和历史会话总结部署战术的人物

一个是实际操作的,他是非think模型,因为think一次太慢和太耗费token了,所以要快:

接下来我会简单说一下各个模型的玩这游戏的玩法,以下数据我通过几个维度评估模型好坏:

  1. 闲置村民数量

  2. 战术得分
    满分五分

国外模型

claude

综合评分: 4.8分

但是有一处非常奇怪,他非常喜欢采集外围资源不采集自己的.并且会无上限爆农民导致没人口造兵。
还喜欢去别人家偷资源:

不过还是后期通过爆骑士打败了简单电脑
第2天测试,开局,基本完美贴合资源建造,这个是我第一次见空间感这么强的AI,其他家的包括GLM都做不到完美建筑位置开局

不过失误还是有的,两个村民杀猪没了:

后期毫无悬念的碾压了简单人机，从规划到进攻表现算亮眼
本来想因为后期的操作给5分的，但是他太太太贵了！！我一看钱包只能给他4.8分了。

GPT-5

综合评分: 3分
我也不知道为什么,gpt5我是API版本真的跟弱智一样.原地等了五分钟才发展,在此之前一直在废话:

但是没任何工具调用!发展了一会后,然后开始玩角色扮演了….

然后自己回答自己上一个问题 继续角色扮演

然后就这样无限循环了…

grok

跟GPT的毛病一样,前几轮还好还在工作,后几轮就开始在玩起了角色扮演了,忽略

gemini-2.5-pro

综合评分: 2.0分
这玩意纯粹搞笑的,每一句话都带了纯粹的语文快乐
比如

又比如

再然后

还有,发现地方侦察骑兵在家门口,他就”组织农民敢死队”把所有空闲农民去砍侦察骑兵…

搞笑是搞笑,但是拉了,因为他前期一大半时间都在尝试建造市场，而系统提醒他那个地方不能建造，他每次失败就写个悲剧文，然后继续尝试在那个地方建造…最后在面临电脑”大军”的时候, 他最终选择建造弓箭手对抗投投矛手,然后输了(ps 帝国时代2里面,投矛手克制弓箭手)…

国产模型

deepseek

综合评分: 2分
deepseek前期规划不错,农民全用了.但是一旦野果采集完毕后,他就不太行了,他也不会种田,也不会狩猎,后期会直接崩坏甚至是投降，而且我确定他没训练过帝国时代2,经常搞错单位升级什么的.但是至少会出兵打一下简单人机…

他像极了我的第一次玩帝国时代2,会建造防御箭塔在家周围,发现打不过选择来一点”高科技”:

他的高科技:

战术也是有的: 比如埋伏一队兵在对方家里杀农民:

只不过越玩越崩坏,有些时候还会投降（他是AI里面唯一一个投降的，而且在经济巨好的情况下….）
deepseek投降,原因是他的”大军”-6个骑士被敌方指挥中心射死了:

qwen

由于他的think token消耗太吓人,算了.我没那么多钱.具体吓人来说,为了做一个动作就要暴力think非常久.如果不think他就基本不智能….

豆包

太慢了，调用一次黄花菜凉了,没时间等他思考..所以放弃

GLM4.6

评价: 5分满分,非常亮眼操作
真正的神！这不是广告，在耗费50元后，他压倒性的打败了简单电脑,并且会战术.

集结单位 包抄

袭击对方军事建筑 封建压制

我故意放水用作弊码让AI有城堡后,他选择造攻城车

最后胜利

kimi-k2-0905-preview

综合评分: 3.5分

他有点太敏感了:

一个侦察骑兵让他所有农民全部回防…

然后就开始崩坏了,这些回防的农民全部不动了,导致他升级不了时代,就这卡着耗费我token

而且封建升级什么的错了,感觉跟ds一样没有研究过帝国时代2

不过令我惊讶的是他在尝试计算还有多少分钟升级,有一点那种电影里面ai计算还有多少分钟可能性的感觉了.

花了我快十块钱后还是毫无进展:

最后挂机了一会升级到封建时代了,我发现他开始跟gemini一模一样,开始逐渐崩坏..

但是不得不说,非常可爱,跟我以前第一次玩帝国时代2一样,建造几个垃圾兵种在”边疆”站岗有安全感

最后我的钱花了16还是没进展,我就终止了他

Claude-4-5-sonnet VS GLM4-6

综上所述,我准备举办一个1v1的比赛,本来想4v4的,但是要八个电脑而且要很多钱,我就放弃了.要让有人想搞的话可以关注我的github不定时开源.(虽然开源可能性非常小因为很容易被拿去做外挂)
一开始,GLM和claude战术一致,都选择了快速升级封建
GLM:

Claude:

在和平发展了一整子后,GLM派出了一个侦察兵发现了别人的位置,而这让CLaude非常不安:



从而让claude选择立刻出兵营,把有限的资源投入到军事里面

而正是这个举动,让CLAUDE经济落后了GLM

但正是这个举动,让GLM也陷入猜疑链,怀疑别人要进攻自己,立刻建造了一个兵营,并且训练了两个民兵

这样对峙了一段时间后:

claude率先犯蠢,他认为远方的树比较安全..就派了四个村民去,但是被野生动物袭击：


然后他发现了,想立刻召回,不过来不及了:

不过来不及了,这四个村民的损失导致claude经济大比分落后GLM
但是他却是第一个升级到封建时代的:

这是因为我们的GLM犯傻了,他认为封建时代是需要500肉,200黄金,然后派了一堆村民采集黄金….

导致慢了五分钟才进入封建时代.这非常致命!
然后GLM认为需要派部队保护金矿

双方升级到封建后又和平发育了一段时间,但是CLAUDE在连续尝试在磨坊建造农田失败后,派出了几个农民去地图边缘建造农田…但是不出意外,又被野生动物咬了

与此同时 GLM的农田铺的非常工整:

与此同时 claude又把农民撤回来了:

而这个时候GLM准备升级城堡时代了

市场/铁匠铺关键科技已经准备就绪

而claude还咋想办法研究为什么他的农田造不了:


GLM已经进入城堡时代


但是进入城堡时代后,GLM不想进攻却想着发展经济:


这导致claude也进入了城堡时代


目前两方对比图


而claude进入城堡时代后,第一件事就是策划进攻计划,准备使用联合部队进行进攻:


而这个消息也被GLM捕获到,GLM也加快了战备速度


claude在一般部队外,还准备了攻城武器


claude第一波攻势是采矿场


而与此同时,GLM却在关键时候不让手头的防御部队去防御,而是选择放弃抵抗:


然后转移石矿


而claude乘胜追击


claude在城市里面肆无忌惮的攻击


原来他是想城堡建造完才进行反击


而这个时候GLM的城堡建造起来了


GLM进行了第一波反击


双方进行了混战


最后GLM胜利了(所以为什么不早点来??)


这一波由于GLM的绥靖政策,自己城镇中心已经没了,并且经济损失过半


而GLM的军师认为,已经毫无胜算,准备最后一搏


于是他把所有的部队分成了两拨,一波直接冲城镇中心


而另外一波断农民金矿


而claude其实还有预备队,因为claude计划了三波攻击，刚刚攻击GLM的其实是第一波


毫无意外,这一波没了


而GLM选择重新建造城镇中心


而来不及了,claude准备了冲车+投矛手


GLM刚刚莽的那一波,自己的部队完全没了,现在只有两三个长矛兵
两辆冲车率先冲入


而GLM也没坐以待毙,等那些人接近城堡，在城堡的掩护下，用两个长矛兵反击


而投矛手全部暴露在城堡射程下，一大半都被射死


claude准备撤退，然后准备来一波更大的


而GLM认为自己没有任何抵抗能力了,投降


赛后总结:
claude对战场处理能力非常好，长远规划非常精彩，包括攻击节奏
而GLM关键输的节点是，自己的矿场被攻击没有第一时间派兵迎战而是选择放弃战略要地，跑路继续发展经济。直到城堡建造好才反击，浪费了大量时间，导致自己的基地被干烂。虽然进行了漂亮的反击并且孤注一掷，但是大势已去。claude赢得比赛只是时间问题

4v4 国产AI大战国外AI!

由于经费问题,不会有4v4中外AI大战了,虽然我也很想举办,但是目前看没几万是举办不了,原因是:
这一局claude花了700人民币

GLM花了200多:

实在是支撑不起4v4的巨型战斗了!

技术细节

这次整活真的是让我力竭了!原因是我基本国庆不休息的在逆向游戏并且写SDK,有非常多非常多的新发现和新技术,很可惜这里写不下,我们写一些基本的吧
这次逆向光笔记写了快几千个字了, 包含了大量算法，解密，反作弊

为了实现功能,我写了700多行的sdk,结合remote_call模块这样我就能跟回家一样调用游戏的功能了.

这样就能跟回家一样调用游戏引擎:

基本游戏引擎

如果我们要做AI的MCP,我们需要完整了解这个引擎.这边由于是偏娱乐的第一篇,我们就不详细介绍了,只是简单介绍一下.
帝国时代2的总结构有几个
avgamescreen -> 负责UI层的东西,点击什么
PathingSystem-> 核心层,里面有世界的信息
通过ida+reclass我们很容易的就定位到他了(通过搜索”World: end_of_new_game”字符串)

在PathingSystem下面有我们关键信息:

AVBaseWorld->
    AvCommandBase
    PlayerList->AVWordBasePlayer ->我们玩家的信息
    AVMapPtr
        ->staticObjects

玩家playerlist:

avgamescreen有我们需要的摄像机,有了这个我们就能做world2screen操作
而里面的”玩家”实际上是多个class的合体

比如一个村民:

AVTRIBE_Combat_Object : AVRGE_Combat_Object : AVRGE_Action_Object : AVRGE_Moving_Object : AVGRGE_Animated_Object : AVRGE_Static_Object

帝国时代2部分数据是加密的,微软做了混淆,不过他们犯了一个错误,混淆不能与0数据混淆,否则出来就是密钥了,出来密钥后,我们可以ida直接搜定位从哪来的,并且知道解密方式:

搜索后,让AI根据算法,写一个逆向的

#include <cstdint>
#include <stdexcept>
#include <vector>
// 解密函数
std::vector<uint64_t> decrypt_pointer(uint64_t encrypted_value, uint64_t multiplier) {
    std::vector<uint64_t> possible_results;
    // 默认情况（原始值能被5整除）
    uint64_t decrypted_default = encrypted_value - 0x7987582189A6A79A;
    possible_results.push_back(decrypted_default);
    // 情况1（原始值 mod 5 == 1）
    // 根据乘数确定不同的常量
    uint64_t case1_const;
    switch(multiplier) {
        case 1345: case1_const = 0x54DD3E6DE5EA4C5D; break;
        case 1368: case1_const = 0x54DD3E6DE5EA4C74; break;
        case 1386: case1_const = 0x54DD3E6DE5EA4C86; break;
        case 1387: case1_const = 0x54DD3E6DE5EA4C87; break;
        case 1388: case1_const = 0x54DD3E6DE5EA4C88; break;
        default: throw std::runtime_error("Unknown multiplier");
    }
    // 检查是否能被0x5314BB974EE0274A整除
    if ((encrypted_value - case1_const) % 0x5314BB974EE0274A == 0) {
        uint64_t decrypted_case1 = (encrypted_value - case1_const) / 0x5314BB974EE0274A;
        possible_results.push_back(decrypted_case1);
    }
    // 情况2（原始值 mod 5 == 2）
    uint64_t case2_term = encrypted_value + 0x6C5EAB60B426DD28;
    if (case2_term % multiplier == 0) {
        uint64_t divisor = case2_term / multiplier;
        if (divisor != 0) {
            uint64_t decrypted_case2 = 0xE7C353CF2DBBE2F2 / divisor;
            possible_results.push_back(decrypted_case2);
        }
    }
    // 情况3（原始值 mod 5 == 3）
    uint64_t case3_term = encrypted_value + 0x2B3719EF44DE99FF;
    if (case3_term % 0xC397D46924EFACCD == 0) {
        uint64_t quotient = case3_term / 0xC397D46924EFACCD;
        uint64_t decrypted_case3 = quotient * multiplier;
        possible_results.push_back(decrypted_case3);
    }
    // 情况4（原始值 mod 5 == 4）
    // 根据乘数确定不同的解密方法
    if (multiplier == 1368) {
        // 对于1368，使用模0x558
        uint64_t target = (encrypted_value + 0x726CEB9596408004) % 0x558;
        // 寻找满足 (0x5E9DF56934CB6EC7 * value) % 0x558 == target 的value
        for (uint64_t value = 0; value < 0x558; ++value) {
            if ((0x5E9DF56934CB6EC7 * value) % 0x558 == target) {
                possible_results.push_back(value);
            }
        }
    } 
    else if (multiplier == 1386) {
        // 对于1386，使用模0x56A
        uint64_t target = (encrypted_value + 0x726CEB9596408004) % 0x56A;
        // 寻找满足 (0x5E9DF56934CB6EC7 * value) % 0x56A == target 的value
        for (uint64_t value = 0; value < 0x56A; ++value) {
            if ((0x5E9DF56934CB6EC7 * value) % 0x56A == target) {
                possible_results.push_back(value);
            }
        }
    }
    else {
        // 对于其他乘数（1345, 1387, 1388），使用更复杂的解密方法
        // 这里简化处理，实际应用中可能需要更精确的逆向计算
        uint64_t base = encrypted_value + 0x726CEB9596408004;
        // 尝试一些可能的值范围
        for (uint64_t value = base - 1000; value <= base + 1000; ++value) {
            // 简化的验证 - 实际应用中应使用完整的逆向计算
            if (value % 5 == 4) { // 情况4的条件
                possible_results.push_back(value);
            }
        }
    }
    return possible_results;
}
// 辅助函数：从对象中解密指针
std::vector<uint64_t> decrypt_object_pointers(uint8_t* object_base) {
    std::vector<uint64_t> decrypted_pointers;
    // 第一组数据：偏移量16-176，使用乘数1345
    for (int i = 0; i < 20; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 16 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1345);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]); // 取第一个可能的结果
        }
    }
    // 第二组数据：偏移量184-344，使用乘数1345
    for (int i = 0; i < 20; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 184 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1345);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第三组数据：偏移量560-736，使用乘数1368
    for (int i = 0; i < 22; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 560 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1368);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第四组数据：偏移量744-920，使用乘数1368
    for (int i = 0; i < 22; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 744 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1368);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第五组数据：偏移量968-1048，使用乘数1386
    for (int i = 0; i < 10; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 968 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1386);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第六组数据：偏移量1056-1136，使用乘数1386
    for (int i = 0; i < 10; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 1056 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1386);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第七组数据：偏移量1136-1264，使用乘数1387
    for (int i = 0; i < 16; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 1136 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1387);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第八组数据：偏移量1272-1400，使用乘数1387
    for (int i = 0; i < 16; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 1272 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1387);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第九组数据：偏移量1400-1520，使用乘数1388
    for (int i = 0; i < 15; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 1400 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1388);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    // 第十组数据：偏移量1528-1648，使用乘数1388
    for (int i = 0; i < 15; ++i) {
        uint64_t encrypted_value = *reinterpret_cast<uint64_t*>(object_base + 1528 + i * 16);
        auto results = decrypt_pointer(encrypted_value, 1388);
        if (!results.empty()) {
            decrypted_pointers.push_back(results[0]);
        }
    }
    return decrypted_pointers;
}
// 定义加密组结构体
struct EncryptedGroup {
    uint64_t start_offset;  // 组起始偏移量
    uint64_t end_offset;    // 组结束偏移量
    uint64_t multiplier;    // 该组使用的乘数
    const char* description; // 组描述（可选）
};
// 获取指针位置对应的乘数
uint64_t get_multiplier_at_offset(uint64_t base, uint64_t offset) {
    // 定义所有加密组
    const std::vector<EncryptedGroup> groups = {
        // 第一组：偏移量16-175，乘数1345
        {16, 175, 1345, "Group 1 (offsets 16-175)"},
        // 第二组：偏移量184-343，乘数1345
        {184, 343, 1345, "Group 2 (offsets 184-343)"},
        // 第三组：偏移量560-735，乘数1368
        {560, 735, 1368, "Group 3 (offsets 560-735)"},
        // 第四组：偏移量744-919，乘数1368
        {744, 919, 1368, "Group 4 (offsets 744-919)"},
        // 第五组：偏移量968-1047，乘数1386
        {968, 1047, 1386, "Group 5 (offsets 968-1047)"},
        // 第六组：偏移量1056-1135，乘数1386
        {1056, 1135, 1386, "Group 6 (offsets 1056-1135)"},
        // 第七组：偏移量1136-1263，乘数1387
        {1136, 1263, 1387, "Group 7 (offsets 1136-1263)"},
        // 第八组：偏移量1272-1399，乘数1387
        {1272, 1399, 1387, "Group 8 (offsets 1272-1399)"},
        // 第九组：偏移量1400-1519，乘数1388
        {1400, 1519, 1388, "Group 9 (offsets 1400-1519)"},
        // 第十组：偏移量1528-1647，乘数1388
        {1528, 1647, 1388, "Group 10 (offsets 1528-1647)"}
    };
    // 检查特殊位置（不使用乘数的位置）
    if (offset == 1520) {
        // 偏移量1520使用异或和加法加密
        return 0xFFFFFFFFFFFFFFFE; // 特殊标记1
    }
    if (offset == 1264) {
        // 偏移量1264使用加法加密
        return 0xFFFFFFFFFFFFFFFD; // 特殊标记2
    }
    // 检查偏移量是否在任何加密组内
    for (const auto& group : groups) {
        if (offset >= group.start_offset && offset <= group.end_offset) {
            // 检查偏移量是否是8的倍数（指针应该对齐到8字节）
            if ((offset - group.start_offset) % 8 != 0) {
                throw std::runtime_error("Offset not aligned to 8-byte boundary within group");
            }
            return group.multiplier;
        }
    }
    // 如果不在任何加密组内，返回0表示未加密
    return 0;
}
// 获取对象中所有加密位置的乘数信息
std::vector<std::pair<uint64_t, uint64_t>> get_all_encrypted_offsets(uint64_t base) {
    std::vector<std::pair<uint64_t, uint64_t>> result;
    // 定义所有加密组
    const std::vector<EncryptedGroup> groups = {
        {16, 175, 1345, "Group 1"},
        {184, 343, 1345, "Group 2"},
        {560, 735, 1368, "Group 3"},
        {744, 919, 1368, "Group 4"},
        {968, 1047, 1386, "Group 5"},
        {1056, 1135, 1386, "Group 6"},
        {1136, 1263, 1387, "Group 7"},
        {1272, 1399, 1387, "Group 8"},
        {1400, 1519, 1388, "Group 9"},
        {1528, 1647, 1388, "Group 10"}
    };
    // 添加特殊位置
    result.emplace_back(1520, 0xFFFFFFFFFFFFFFFE);
    result.emplace_back(1264, 0xFFFFFFFFFFFFFFFD);
    // 添加所有加密组内的位置
    for (const auto& group : groups) {
        for (uint64_t offset = group.start_offset; offset <= group.end_offset; offset += 8) {
            result.emplace_back(offset, group.multiplier);
        }
    }
    return result;
}
// 打印对象中所有加密位置的乘数信息
void print_encrypted_offsets_info(uint64_t base) {
    auto encrypted_offsets = get_all_encrypted_offsets(base);
    printf("Encrypted offsets in object at base 0x%llX:\n", base);
    printf("Offset\tMultiplier\tDescription\n");
    printf("------\t----------\t-----------\n");
    for (const auto& entry : encrypted_offsets) {
        uint64_t offset = entry.first;
        uint64_t multiplier = entry.second;
        if (multiplier == 0xFFFFFFFFFFFFFFFE) {
            printf("0x%llX\tSpecial\t\tXOR + ADD encryption\n", offset);
        } else if (multiplier == 0xFFFFFFFFFFFFFFFD) {
            printf("0x%llX\tSpecial\t\tADD encryption\n", offset);
        } else if (multiplier == 0) {
            printf("0x%llX\t0\t\tNot encrypted\n", offset);
        } else {
            printf("0x%llX\t%llu\t\tStandard encryption\n", offset, multiplier);
        }
    }
}
int main(){
uint64_t base = 0x7ff7c06b0000; // 对象基地址
print_encrypted_offsets_info(base);
auto decrypt_test =  decrypt_pointer(0x4EF2932AD180DD26, 1345);
    printf("decrypt_test: %llx \n",decrypt_test[0]);
}

然后解密一下,当然其他不同的class加密方法不同,但是结果都一样:

帝国时代2反作弊:
如果你挂了CE或者其他debuger,他会提示

这是因为它使用isdebug和veh做检测
定位后patch掉就行

__int64 __fastcall isWecheating(__int64 a1)
{
  return *(unsigned __int8 *)(a1 + 0x698);
}
搜索
IDS_TAMPERING_DETECTED_MESSAG

还有一个暗装:
aoe2de_s.exe + 0xA39668
_QWORD *__fastcall sub_7FF63BB7BEC0(__int64 a1, _QWORD *a2)
{
  struct _Mtx_internal_imp_t *v4; // rbx
  int v5; // eax
  __int64 v6; // r8
  unsigned __int64 v7; // r9
  *a2 = 0i64;
  v4 = (struct _Mtx_internal_imp_t *)(a1 + 9344);
  v5 = Mtx_lock((_Mtx_t)(a1 + 9344));
  if ( v5 )
  {
    std::_Throw_C_error(v5);
    JUMPOUT(0x7FF63BB7BF78i64);
  }
  v6 = *(_QWORD *)(a1 + 9336);
  if ( v6 )
  {
    v7 = *(_QWORD *)(a1 + 9328);
    *a2 = *(_QWORD *)(*(_QWORD *)(*(_QWORD *)(a1 + 9312) + 8 * ((v7 >> 1) & (*(_QWORD *)(a1 + 9320) - 1i64)))
                    + 8 * (v7 & 1));
    *(_QWORD *)(a1 + 9336) = v6 - 1;
    if ( v6 == 1 )
      *(_QWORD *)(a1 + 9328) = 0i64;
    else
      *(_QWORD *)(a1 + 9328) = v7 + 1;
  }
  Mtx_unlock_0(v4);
  return a2;
}
弹信息框的地址是
7FF63B4B2AA0 - 0x7FF63AC70000 = 842AA0
aoe2de_s.exe + 0x842AA0
hook后看来源
0:306> kb
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff7`c10ec93b     : e1c096a0`0e29052d e1c096a0`0e29052d e1c096a0`0e29052d 00000230`c85d43a0 : AoE2DE_s+0x842aa0
01 00007ff7`c10daeff     : 00000000`00000000 00000000`00000000 00000230`61a2e1f0 00000000`00000003 : AoE2DE_s+0xa3c93b
02 00007ffd`45459363     : 00000230`460ae850 00000000`00000000 00000000`00000000 00000000`00000000 : AoE2DE_s+0xa2aeff
03 00007ffd`464426ad     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x93
04 00007ffd`4796a9f8     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x1d
05 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28
0:323> kb
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff7`c1c8352b     : 00007ffd`4796a9f8 00007ff7`c3cf38c8 00000000`00000030 00007ff7`c3cf69b0 : USER32!MessageBoxW
01 00007ff7`c0ef2ac7     : ca057213`7bfa831d 00000000`ffffffff 00000230`60ad5d30 00000000`ffffffff : AoE2DE_s+0x15d352b
02 00007ff7`c10ec93b     : ca057213`7bfa831d ca057213`7bfa831d ca057213`7bfa831d 00000230`c85d43a0 : AoE2DE_s+0x842ac7
03 00007ff7`c10daeff     : 00000000`00000000 00000000`00000000 00000230`f8868840 00000000`00000003 : AoE2DE_s+0xa3c93b
04 00007ffd`45459363     : 00000230`46018fc0 00000000`00000000 00000000`00000000 00000000`00000000 : AoE2DE_s+0xa2aeff
05 00007ffd`464426ad     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x93
06 00007ffd`4796a9f8     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x1d
07 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28
__int64 __fastcall sub_7FF63BAE8380(__int64 a1)
{
  __int64 result; // rax
  __int64 v3; // rcx
  __int64 (__fastcall ***v4)(_QWORD, __int64); // rcx
  if ( qword_7FF63F0780E8 )
    sub_7FF63BB86ED0(qword_7FF63F0780E8, 4i64);
  if ( *(_BYTE *)(a1 + 0x699) )
    sub_7FF63BB799C0(g_events);
  *(_BYTE *)(a1 + 0x699) = 1;
  result = g_events;
  v3 = *(_QWORD *)(*(_QWORD *)(g_events + 848) + 11088i64);
  if ( v3 )
    result = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)v3 + 552i64))(v3);
  v4 = *(__int64 (__fastcall ****)(_QWORD, __int64))(a1 + 1136);
  *(_QWORD *)(a1 + 1136) = 0i64;
  if ( v4 )
    return (**v4)(v4, 1i64);
  return result;
}
写入的几个地址：
0:293> g
Breakpoint 4 hit
AoE2DE_s+0xa3c11f:
00007ff7`c10ec11f c681f10e000001  mov     byte ptr [rcx+0EF1h],1 ds:00000292`17f1dba1=01
0:293> kb
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff7`c10ec92f     : 6d4c1d03`8609bde5 6d4c1d03`8609bde5 6d4c1d03`8609bde5 00000292`0d042b50 : AoE2DE_s+0xa3c11f
01 00007ff7`c10daeff     : 00000000`00000000 00000000`00000000 00000293`1d5f04f0 00000000`00000003 : AoE2DE_s+0xa3c92f
02 00007ffd`45459363     : 00000292`077fbfd0 00000000`00000000 00000000`00000000 00000000`00000000 : AoE2DE_s+0xa2aeff
03 00007ffd`464426ad     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x93
04 00007ffd`4796a9f8     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x1d
05 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28
call的函数是
aoe2de_s.exe + 0x501d43e
0x7FF63AC70000 + 0xa3c93b = 
AoE2DE_s.exe+2B86916 - 66 66 0F1F 84 00 00000000  - nop word ptr [rax+rax+00000000]
AoE2DE_s.exe+2B86920 - 48 3B 0D 91D86A01     - cmp rcx,[AoE2DE_s.exe+42341B8] { (-562597392) }
AoE2DE_s.exe+2B86927 - 75 10                 - jne AoE2DE_s.exe+2B86939
AoE2DE_s.exe+2B86929 - 48 C1 C1 10           - rol rcx,10 { 16 }
AoE2DE_s.exe+2B8692D - 66 F7 C1 FFFF         - test cx,FFFF { 65535 }
AoE2DE_s.exe+2B86932 - 75 01                 - jne AoE2DE_s.exe+2B86935
AoE2DE_s.exe+2B86934 - C3                    - ret 
AoE2DE_s.exe+2B86935 - 48 C1 C9 10           - ror rcx,10 { 16 }
AoE2DE_s.exe+2B86939 - E9 C2030000           - jmp AoE2DE_s.exe+2B86D00

之后我们就可以顺利得到资源了.这些都不是本篇要说的内容.
为此 我做了一个简单的透视，打印出内容


值得注意的是,盖亚的树木和鱼和海要额外处理:
你可以看到他并不显示树木

这是因为，这些是 地图属性,需要从另外一个表读取,非常非常大,这个折腾花了我一天时间,最后借助GPT的帮助才恍然大悟!

帝国时代2内存泄漏

我有理由相信帝国时代2存在某种资源泄漏.原因是死亡的对象会堆积在0-0-0的区域内,不会被删除

据我观察到,这块内存会越来越大在一局比赛中,这可能也是为什么帝国时代2这游戏越玩越卡的原因

帝国时代2命令系统

微软九十年代的程序员,代码技术非常的硬.表现为他们要实现一个八人在线，数百个甚至是数千个单位，在10kb光猫下跑的联机对战系统！(以及反外挂)
这个系统细节我会放到下期，这对我们的影响是，我们没有办法直接移动单位，或者修改资源，或者做出任何事情！只能读取
这是因为，帝国时代2的网络系统是lockstep,这是一种非常离谱的方法,在2000年的时候还专门写了一篇新闻说他们是如何的困难
https://web.archive.org/web/20180719170411/https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php?print=1
我非常建议搞技术的详细阅读这篇文章.即便是不是游戏行业也受益匪浅

简单来说,你的所有状态都会同步给其他玩家,
其他玩家会根据你的少量信息在本地进行模拟计算
计算出来的结果再在本地呈现出来
这意味着:

（1）所有对局看起来没多少延迟,因为大部分都是本地计算的.除非有大量丢包.
（2）你可以改资源/甚至是修改视野范围,但是其他玩家发现你的状态并不是能在他本地”模拟计算”出来的结果,所以他就会发出不同步的指令,这代表本局有人开挂。

所以我们不能直接移动单位,而是寻找传说中的命令系统
命令系统寻找过程就不说了,因为是九十年代的代码,实在是过于复杂,在连续熬夜三天三夜只睡了4个小时后,说个血泪总结:
有一个函数,是命令分发的!原型是

接受的参数是

有了这个我们就能构造任意命令发送了。移动，升级时代，都是这样的
ps这个有个bug: 命令是P2P的,所以能瞎几把发,比如你选择B的玩家的单位发送命令移动或者摧毁自己都可以。不过我们的目的不是为了开外挂,是为了做MCP.所以默认我们是合法的
相关资料:

https://redrocket.club/posts/age_of_empires/

远程call

为了发命令,我设计了一个基于ALPC的远程call,一个DLL注入到帝国时代2里面,暴露ALPC接口:

接受客户端的游戏指令并且在UI线程执行,之所以在UI线程执行,因为帝国时代2并没有多线程安全的机制,它默认所有的游戏都是UI更新来的(ps: 很多老游戏都这样,而且这玩意跟AI挂钩,自己的FPS越高,AI越聪明…)

这样客户端就能轻松CALL了

结果:

地图系统

为了实现MCP,我做了一个地图系统。总所周知，帝国时代2的地图是一个XY坐标的地图，一般是320x320 650x650等等，这个地图系统，我们是不能直接for x-y去寻找对象的，因为效率太低。所以要用到另外一个算法，叫做空间哈希网格，这个算法我也不太熟悉，是AI看了帝国时代2的代码后给出的，他的主要作用是，能快速索引 某个对象周围的对象。时间复杂度只有o(1)

而寻路算法使用a star 不过帝国时代2自己有寻路系统，我们不需要操心（他也是A star）

第一部分：什么是哈希算法？
想象一下你有一个巨大的图书馆，里面有成千上万本书。如果你每次找书都从第一排第一个书架开始一本一本地找，那会非常慢。
哈希算法就是一个超级高效的“图书管理员”。它的工作方式是：
输入：你给它一个“键”，比如一本书的书名《三体》。
计算：它通过一个固定的数学公式（哈希函数）对这个书名进行计算。
输出：计算出一个固定的、通常比较短的编号，比如 5381。这个编号就是“哈希值”。
核心特点：
确定性：同样的输入（《三体》），永远会得到同样的输出（5381）。
高效性：计算速度非常快。
散列性：一个好的哈希算法会让不同的输入尽量产生不同的输出，避免“冲突”（即两本不同的书算出了同一个编号）。
在我们的图书馆例子里，这个管理员（哈希算法）会告诉你：“《三体》这本书在 5381 号书架上”。你直接去那个书架找就行了，省去了遍历整个图书馆的时间。
第二部分：什么是空间哈希网格？
现在，我们把场景从图书馆换到一个游戏世界，比如你正在玩的《帝国时代2》。地图上有成百上千个单位：农民、士兵、建筑、资源……
游戏需要 constantly （不断地）回答一个问题：“在某个单位周围，有哪些其他单位？” 例如：
一个士兵需要知道周围有没有敌人可以攻击。
一个农民需要知道附近有没有树可以砍。
一个建筑需要知道周围有没有友方单位在驻扎。
最笨的办法是让每个单位都和地图上所有其他单位都计算一次距离。如果有1000个单位，就需要计算1000 * 1000 = 1,000,000次！这会让游戏卡成幻灯片。
空间哈希网格就是一个聪明的“空间分区”方法，它把整个游戏世界划分成一个个小格子（单元格）。
它的工作原理是：
划分空间：将整个游戏地图虚拟地划分成许多大小相同的正方形格子。
分配对象：根据一个游戏单位（比如一个骑兵）的坐标 (x, y)，计算出它位于哪个格子里。例如，坐标 (155, 267) 可能位于格子 (15, 26) 中。
只检查相邻格子：当需要查找某个单位附近的其他单位时，系统只检查这个单位所在的格子以及它周围的8个格子。
举个例子：
假设地图被分成100个格子。一个士兵在格子 (5,5) 里。
笨办法：它需要和地图上所有999个其他单位计算距离。
空间哈希网格：它只需要和也在格子 (4,4), (5,4), (6,4), (4,5), (5,5), (6,5), (4,6), (5,6), (6,6) 这9个格子里的单位计算距离。
如果单位均匀分布，每个格子里大约只有10个单位，那么士兵只需要进行 9 * 10 = 90 次计算，而不是999次！效率提升了成百上千倍。
第三部分：两者如何结合？“哈希”在哪里？
现在关键问题来了：我们如何快速知道一个坐标 (x, y) 属于哪个格子？又如何快速找到某个格子里的所有单位呢？
这里就用到了 哈希算法！
步骤如下：
生成“键”：我们取一个单位的坐标 (x, y)，把它映射到对应的格子坐标 (grid_x, grid_y)。通常很简单：
grid_x = floor(x / cell_size)
grid_y = floor(y / cell_size)
（floor 是向下取整，cell_size 是每个格子的大小）
计算哈希值：我们将这个格子坐标 (grid_x, grid_y) 作为“键”，输入给一个哈希函数。
hash_key = hash_function(grid_x, grid_y)
存储和查找：系统维护一个巨大的“字典”（哈希表）。这个 hash_key 就是字典的索引。所有在同一个格子里的单位，都会被放入这个 hash_key 对应的列表里。
当我们需要查找时：
取目标的坐标，算出它的格子坐标 (grid_x, grid_y)。
用哈希函数瞬间计算出 hash_key。
直接用这个 hash_key 去字典里，瞬间找到对应格子的单位列表。
检查这个格子及周围8个格子的列表，完成碰撞检测或范围查询。
总结
哈希算法：是一个高效的“计算器”，能把任意数据（如坐标）转换成一个快速的索引号。
空间哈希网格：是一种管理大量空间对象的数据结构，通过将空间分格来极大地减少需要计算的对象数量。
把它们结合在一起：
空间哈希网格使用哈希算法，来快速地将一个空间位置（坐标）映射到一个存储单位的容器（格子）上。
这就好比：
空间哈希网格是那个划分了区域的图书馆大厅。
哈希算法是那个看一眼书名就能立刻报出书架编号的超级管理员。
你（游戏引擎） 想问“《三体》在哪？”，管理员瞬间告诉你“5381号架”，你直接过去，而不用逛遍整个大厅。
在《帝国时代2》这样的游戏中，这套机制是保证成千上万个单位能够流畅运行而不会卡顿的关键技术之一。

反正我是不懂，不过就当是真的吧，确实有效果。 那么这样我们的MCP就有感知能力了，以下是AI感知周围的截图:

MCP服务端设计

这是最关键的一部分，也是最耗费时间的部分。总的来说，我们其实有很多种让AI玩的方案，不一定是大语言模型。其实我也考虑过其他方案，不过国庆就这么多天，我也没时间实现了。方案如下

  1. OneBrain ALL IN

  2. 决策层（有限状态机/行为树） + 命令执行层

  3. 决策层 (效用AI) + 命令执行层

第一种是，我们直接让AI参与控制决策并且直接控制各个单位移动，部署。 -这样做的比较快，本次项目用的就是这个。

第二种第三种的“决策层”这个决策层不仅仅是大语言模型，还可以是传统游戏决策树/强化学习的AI甚至是一个xgboost就行，因为它只需要发几个特定的命令: 比如农田建造在x区域。然后命令执行层用代码根据村民位置，选择最好的方案执行。 如果你读过帝国时代2的AI代码，你就会发现，帝国时代2的AI就是这样做的。他的好处是决策和执行分开，不需要太大的沉默成本。但是也是最费时间的，原因很简单，有限状态机/决策树是可枚举的，但是帝国时代2的这个RTS被开发出了上百种玩法，即便是帝国时代2的极难AI也有缺陷-比如黑暗时代封墙，黑森林围墙之类的。所以这个方案耗时耗力，考虑到我不是专业游戏开发，还是算了- 要是哪天我去做游戏的我会试试的

第三种
不为AI定义明确的“如果-那么”规则，而是为每个可能的行动计算一个“得分”（效用值），然后选择得分最高的那个行动
比如,计算得分：
攻击的得分 = 攻击欲望 命中率
吃药的得分 = (1 - 生命值百分比) 药瓶价值
找掩体的得分 = 危险程度 * 附近掩体质量
选择：比较这三个得分，执行最高的那个
这个也比较复杂，复杂不是决策层的设计而是那个命令执行层的设计。所以也pass了

因此我选择直接让AI控制单位这种低级粗暴的算法。因为我没多少时间，国庆后还要当牛马

因此我设计了17款工具,抛开别的,关键的几个是

incident

为了让AI有态势感知能力，我编写了一个incident系统，其实游戏也有incident系统，比如你被野生动物攻击，敌人正在进攻城镇什么的，但是我实在是不想hook了，因为hook意味着你还需要把incident传入客户端，alpc是单向的，我懒得再建立一个服务器了。因此我在incident加了一个events，循环遍历把事件加入到表里面:

比如遇见敌方军队，遇见自然资源，都加进去

事实证明这非常有用，基本所有的AI都靠这个做战场态势感知。

移动

智能交互

a单位和b单位进行交互,计算两个单位是什么东西,比如村民交互了绵羊那就是在杀羊.发attack命令。士兵选择了敌方城堡 那就是攻击命令

地图发现

这个工具让AI输入坐标，输出里面一定范围内有什么

这样能方便建造，训练，位置摆放。
map_discover虽然我不想让AI作弊，但是我不想再搞个视野检查系统了，太累了，虽然能搞。但是时间有限，还是让AI作弊吧。不过AI也不知道敌人坐标，所以还好。

实战观测到，claude会用这个作弊，其他都是老老实实排除侦察骑兵进行侦察

建造功能

值得注意的是，本来建造功能没那么复杂，直接调用游戏函数判断结果的

结果我发现：
大部分AI包括claude除了GLM,他们的”空间感”都不是很好,经常建造在重复建造的区域内…所以实在是受不了了，又自己硬编码了建筑物大小，前置信息等乱七八糟的东西，防止AI瞎搞并且给出信息

http服务器

这17个工具都用httplib暴露接口,做标准的MCP服务器
httplib
非常推荐这玩意，真的好用，祖传了几年，没出事过
https://github.com/yhirose/cpp-httplib

agent设计

整个agent部分我用deepseek一边调试一边写的，deepseek可以说是第一个玩帝国时代2的agent，因为他的token真的便宜，可以给我大量的试错。经过deepseek的调整，花了几天功夫，我总结出以下几点

  1. 所有AI没有长期规划能力，所以一定要让他们自己维护一个todolist.而且我规定必须带数字,比如搜集100食物,这规定是代码写死的，提交不明确的信息将被拒绝，事实证明这非常有效果。

  2. 我把10-12次对话设置为一轮，一轮后一开始是由AI自己总结对话，继续新的对话实现token”压缩”但是token压缩效果非常差，表现为deepseek经常会把错误带入到下一个对话，导致拉闸。所以我决定彻底放弃对话，而是设计一个”军师”的角色，这个角色的目的是根据现在的游戏信息+反思历史AI和工具交互的错误，总结AI的错误，这不是简单的token压缩。因此deepseek才终于能反思自己的错误避免错误传递到下一轮,并且军师的思考能直接决定战局走向。非常不错

  3. 写告警事件: 大部分AI其实完全不会玩帝国时代2,或者说他们压根没训练过帝国时代2, 很多时候不知道自己要干什么，比如一堆空闲农民他们觉得是正常的，因此我设计了一个硬编码的告警系统，提醒他们需要干什么，比如空闲农民过多，立刻不让他们空闲之类的:

    这我也没办法，毕竟AI没玩过帝国时代2，就这样AI还会出错,比如GLM:

  4. 内置工具call: 我也不知道为什么，deepseek的深度思考是不支持工具调用的，所以我没办法，只能做一个正则匹配的内置call，具体来说匹配tools开头的标签和结尾，然后把里面的json解析出来，事实证明，其他具备agent能力的模型，是内置call也好还是openai格式的call也罢都支持挺不错的，唯一就是deepseek的think模型完全不支持这样。反正非常蛋疼

总结

感谢你的耐心收看,如果你对帝国时代2的游戏引擎/游戏机制/优秀的游戏网络系统感兴趣的话，更多详细的技术分析报告详我会整理大概半个月后发出来,微信公众号回复"帝国时代2"可以参与预约,如果预约的人太少,那就烂在肚子里面吧，因为他的游戏机制实在是太多，太复杂了，我还在考虑也不要在我忘记之前记录下来。
整个过程非常累人，这个工作量远远超出我的预期了，表现在，当我认为现在的功能完美能让AI用的时候，我发现AI又缺功能了，又缺功能，只能继续硬着头皮逆向，来来去去，，这种活本来预期三天的搞了快一个星期，我决定下次不整这种活了，国庆就应该好好休息。

阅读原文

跳转微信打开

]]> Mon, 06 Oct 2025 10:01:00 +0800 "ucpd.sys后门事件"详细分析技术报告-他是后门.....吗? https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485442&idx=1&sn=a56332f9d4b4ef24ddcbc8da592399c8 原创 为了安全鸭 2025-09-18 10:03 日本

前言

老实说,我非常不喜欢蹭热点,因为我认为人生不能把时间浪费在无意义的争论上.但是最近一篇文章引起了我的兴趣:

因为整个微信公众号,整个新闻页面,都是这玩意了,不小心点了之后,感谢大数据,我的各种社交媒体首页,也全是这玩意推荐:

这些新闻无一例外都只是在散发焦虑

并且没有一丝技术分析

事实真的如此吗? 如果是,这会给我们什么启示? 如果不是,微软最有可能装后门的地方在哪? 让我们从技术角度详细分析.而不是被新闻焦虑冲跨

根源问题

这一切的根源是,在Windows中,默认浏览器保存在以下注册表项中：

设置默认浏览器就像设置这些键的值一样简单——相对来说比较直观。然而，某些厂商经常滥用这一功能，在未经用户同意甚至未经用户交互的情况下，将默认浏览器劫持为自己的产品。

为了解决这个问题，Windows 引入了一个Hash子键，其中包含所选默认浏览器的哈希值。只有哈希值正确时，才会遵循默认浏览器设置。该哈希算法是专有的，只有在使用 Windows 的“设置”对话框进行设置时才能正确计算。它还包含当前计算机的熵，因此无法预先计算。

当然，这个哈希值的秘密不会持续太久。2017年，Christoph Kolbicz 逆向工程了该哈希算法，并将其部署到他的 SetUserFTA 工具中，这是一个命令行实用程序，可以设置文件类型关联或默认浏览器。2021年，Mozilla 也允许 Firefox直接将自身设置为默认浏览器。

微软于 2024 年 3 月推出 UCPD 驱动程序，以应对其哈希算法的“破解”。UCPD 代表用户选择保护驱动程序，它是一种过滤驱动程序，用于保护存储默认浏览器设置（以及类似内容，例如默认 PDF 阅读器）的注册表项

驱动逆向

通过bn+MCP,我们很快的就完成了对我目前系统上的UCPD驱动逆向:

这个驱动的核心逻辑之一是注册了一个注册表回调,监控windows的注册表操作

可以看到,会监控读写删除

而这几个回调,其实都在干一件事:

在一个全局的保护列表里面,匹配注册表是否是被保护的对象

而这个列表是在函数sub_1C0018310也就是驱动初始化的时候初始化的:

列表内容包括:

默认浏览器:

Software\\Microsoft\\Windows\\Shell\\Associations\\UrlAssociations\\http\\UserChoice

默认html文件打开方式:

Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts\\.html\\UserChoice

默认pdf打开方式(额...不知道为什么):

Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts\\.pdf\\UserChoice

系统安装时候的设备时区:

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\DeviceRegion

虽然不知道为什么,但是这一块linux.do里面也说了

一些office文件的关联方式

一些explorer的组件

一旦匹配中了这些保护列表,会看保护的类型,保护类型有几个，这里AI搞错了,我觉得这个应该叫做"策略",而不是保护类型

我们以默认浏览器为例子,他的默认级别是1

我们先看策略1:

策略1会先检查是否是可信进程,检查方式是

是否是微软签名

可执行文件在不在单里面

其中微软签名是通过内核CI.dll做签名校验

列表如下:

其中让我们记住这个explorer.exe 因为这个是伏笔.jpg

现在我们搞清楚了目前的UCPD的驱动逻辑,他非常简单,不在白名单里面的进程,禁止修改这些注册表,也就是回调返回错误

并且同时发一份ETW记录

并且在阻止后,还会做一次栈回溯然后发ETW,这可以理解,毕竟需要一些信息去判断什么代码触发链.(比如检查某些未知的流氓软件在篡改主页)

结束了?

你以为到这里就结束了？ 没有,还有高手!

UCPD这个驱动还创建了一个进程创建回调和一个object打开回调

在进程创建的时候,会检查是否是这些进程名字或者签名,我把这个函数叫做IsStringInChinaBlackList,里面包含了一些不能在这个公众号出现的国产软件:

如果是,在object回调,也就是openprocess的时候,会判断是不是这些进程,如果是,则去掉部分权限,并且发ETW记录

  被移除的权限位：

  - 0x10: 可能是 PROCESS_VM_WRITE (写入进程内存)

  - 0x28: 可能是 PROCESS_TERMINATE + 其他权限

根据xusheng的介绍

现在应该很容易看出其意图——它阻止 ****.exe/******.exe/********.exe....将代码注入 explorer.exe/msedge.exe！UCPD 为什么要这么做？唯一的解释是，他们试图通过向 explorer.exe/msedge.exe 注入代码来绕过 UCPD，因为这两者都可以修改默认浏览器的注册表项。微软不喜欢这个主意，所以它直接封禁了违规者，从而加强了防护！

https://binary.ninja/2025/03/25/default-browser-upcd.html

微软如何真的投递后门

我们假设,发生了ww3,微软把windows武器化了,那么作为微软,如何提前埋好后门呢?

首先,微软不需要后门,他的windows update就是最大的后门,哪天推一个一键锁机补丁都有可能,不过windows update补丁被全球的安全从业人员审计着,至少在没到WW3的时候,哪怕有小规模冲突,都是不太可能投递的.(我甚至是怀疑WW3的时候大家是不是都已经没有网络了)

其次,如果微软真的需要"偷"资料,他只需要走windows defender就行了,windows defender会"上传可疑文件"但是这个文件怎么定义可疑,是他们说的算.保不准"觉得"你的文档带了中文可疑.但是这里只是我瞎说的,没实际证据,原因很简单,defender的代码也是被全球各地的安全人员审计着,所以如果直接来一套后门，应该不超过一个星期就被发现了.

所以这就带来一个问题,如果是常规后门,在没做代码加密的情况下,最多一个月就会被全球安全从业人员分析出来,代码加密了,说明那一块更可疑,只会吸引更强的大哥来分析,最终变成会议ppt,比如windows的战鸟:

微软的代码虚拟机"战斗之鸟"(warbird)深度研究与逆向 #1

微软的代码虚拟机"战斗之鸟"(warbird)深度研究与逆向 #2

有没有更隐蔽的后门呢? 隐蔽到我们常规安全人员无法分析的?

有的,那就是密码学.

比如在我审计XP的代码的时候:

当然以上是开玩笑的meme,因为我也搞不懂为什么,我本身不是学密码学的.只是觉得好奇怪。

玩笑归玩笑，话说回来，让我们头脑风暴一下, 如果微软要在和平时期搞后门，而不被发现(发现了我估计第二天全球就没多少用windows的设备了)，而且我们假定后门不能是“漏洞”类型的(要不然就陷入无穷无尽的阴谋论了).那就只有密码学,如果我们的密码基础设施被植入后门,可以做到:

0. 大部分安全从业人员无法察觉,这不是代码层面的事情.

1. 实时监控任意流量 -因为密码学存在漏洞,导致加密流量可以被解密

2. 伪造任意数字签名-如果密码学存在后门,攻击者完全可以伪造任意数字签名,一旦能伪造签名,重装系统就没有信任体系了.这无法防御.

3. 可以顺利甩锅,哪怕是windows被曝光用"漏洞"算法,windows也完全可以说是行业标准他带漏洞,让我打个安全更新给你修了.即便是被曝光,也不影响股票.

而且这事NSA又不是没干过:

彩蛋

我搜资料的时候还发现国内也有人问过怎么过这玩意改主页....

参考资料

https://binary.ninja/2025/03/25/default-browser-upcd.html

https://linux.do/t/topic/884669

https://bbs.kanxue.com/thread-285575.htm

https://github.com/xusheng6

阅读原文

跳转微信打开

]]> Thu, 18 Sep 2025 10:03:00 +0800 阻止通过漏洞驱动利用(byovd)技术致盲安全软件 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485391&idx=1&sn=d6b003bb825f096fea77d5cabb1a10d3 原创 为了安全鸭 2025-09-16 10:00 北京

前言

byovd,在2014年左右这些在业内还是被叫做"vulnerable driver"也不是什么神秘的东西,我知道的到现在也就几十年了吧(实际可能更早,比如NSA的那个远控XP时代就用了)这些驱动有几个类型,但是无非就是跟R3交互接口没验证签名导致函数被滥用。

内核驱动调用ZwTerminateProcess

现在信息安全领域见得多的还是这种内核发terminalprocess的东西，毕竟没游戏安全对抗那么激烈。大部分情况下关闭就行不做其他的操作就比如银狐木马用的:这种情况跟上面说的一样，内核IO管理权限校验没做好，让人可以对任意进程发ZwTerminateProcess.

缓解

实际上,在2020年左右Aidan Khoury的faceit反作弊(也负责后来的VGK反作弊)就已经开始做缓解了(这个作者长得很帅,建议github star一下)https://github.com/ajkhoury

缓解方法如下:

开机启动标记/阻止 漏洞驱动加载API 挂钩监控前两个没什么好说的,无非就是拉黑驱动签名和HASH,但是漏洞驱动太多了.我们重点说第三点

在windows系统中,随便挂钩系统驱动可能会被PG蓝屏.但是挂钩第三方驱动不会的.而保险的方式是挂钩驱动IAT,比如欧洲bro挂的BE的驱动的IAT导入函数列表是的,其实卡巴斯基和一些国外的EDR也挂了很多常见的驱动IAT或者IO HANDLE,目的就是为了防止漏洞驱动利用.比如为什么SentinelOne EDR能阻止漏洞驱动利用,就是挂了IAT

缓解POC

让我们以一个卡饭流行的样本为例子,我们如何缓解他致盲edr:代码真的非常非常简单，我们只需要注册一个loadimage回调,然后判断是否是驱动,如果是,则hook导入表:标准的导出表hook:hook后,我们判断是否是受保护进程,我这里以defender的msmpeng.exe为例子:完整代码:

/// @brief 根据进程句柄返回进程路径,必须要释放/// @param ProcessHandle/// @return 成功返回unicode_string* 否则返回nullauto QueryNameByHandle(HANDLE ProcessHandle) -> PUNICODE_STRING {    void* allocMemory = nullptr;    uint32_t bufferSize = 0;    bool isSuccess = false;    do {        if (ZwQueryInformationProcess(ProcessHandle, ProcessImageFileName, NULL,                                      0, (PULONG)&bufferSize) !=            STATUS_INFO_LENGTH_MISMATCH) {            break;        }        if (bufferSize == 0) {            break;        }        allocMemory = ExAllocatePoolWithTag(PagedPool, bufferSize, HUOJI_TAG);        if (allocMemory == nullptr) {            break;        }        memset(allocMemory, 0x0, bufferSize);        auto ntStatus = ZwQueryInformationProcess(            ProcessHandle, ProcessImageFileName, allocMemory, bufferSize,            (PULONG)&bufferSize);        if (NT_SUCCESS(ntStatus) == false) {            break;        }        isSuccess = true;    } while (false);    if (isSuccess == false) {        if (allocMemory != nullptr) {            ExFreePoolWithTag(allocMemory, HUOJI_TAG);            allocMemory = nullptr;        }    }    return reinterpret_cast<PUNICODE_STRING>(allocMemory);};namespace Hooks {/// @brief hook的漏洞利用函数/// @param ProcessHandle/// @param ExitStatus/// @returnNTSTATUSNTAPIHookZwTerminateProcess(_In_opt_ HANDLE ProcessHandle,                       _In_ NTSTATUS ExitStatus) {    const static UNICODE_STRING defenderProcess =        RTL_CONSTANT_STRING(L"msmpeng.exe");    PUNICODE_STRING TargetProcessName = nullptr;    PUNICODE_STRING CurrentProcessName = nullptr;    bool isBlock = false;    do {        if (ProcessHandle == (HANDLE)-1) {            break;        }        TargetProcessName = QueryNameByHandle(ProcessHandle);        if (TargetProcessName == nullptr) {            break;        }        CurrentProcessName = QueryNameByHandle((HANDLE)-1);        if (CurrentProcessName == nullptr) {            break;        }        if (RtlSuffixUnicodeString(                &defenderProcess,                reinterpret_cast<PUNICODE_STRING>(TargetProcessName),                true) == false) {            break;        }        DebugPrint("Detect vulnerable Driver Exploit\n");        DebugPrint("Process for exploit: %wZ \n", CurrentProcessName);        DebugPrint("try to kill: %wZ \n", TargetProcessName);        isBlock = true;    } while (false);    if (TargetProcessName != nullptr) {        ExFreePoolWithTag(TargetProcessName, HUOJI_TAG);        TargetProcessName = nullptr;    }    if (CurrentProcessName != nullptr) {        ExFreePoolWithTag(CurrentProcessName, HUOJI_TAG);        CurrentProcessName = nullptr;    }    return isBlock ? STATUS_UNSUCCESSFUL                   : ZwTerminateProcess(ProcessHandle, ExitStatus);}};  // namespace Hooksauto LoadImageNotifyRoutine(PUNICODE_STRING FullImageName, HANDLE ProcessId,                            PIMAGE_INFO ImageInfo) -> void {    if (ProcessId != 0) {        return;    }    DriverUtil::IATHook(ImageInfo->ImageBase, (char*)"ZwTerminateProcess",                        &Hooks::HookZwTerminateProcess);}auto InstallHook() -> void {    PsSetLoadImageNotifyRoutine(&LoadImageNotifyRoutine);}

效果

一旦发现目标正在尝试结束我们受保护进程,我们可以直接阻止他,这是效果,我们可以看到我们成功检测并且阻止了漏洞驱动利用:

代价?

是的,如此简单背后是有自己的代价的: 他极其不稳定,比如闹得沸沸扬扬的火绒和卡巴斯基不兼容就是卡巴斯基挂了火绒的iat:此外一旦安装,无法热卸载驱动,怎么卸载都是不安全的.并且可能会有多个安全软件hook iat,到时候谁卸整个系统都会蓝屏.梦回XP时代杀毒软件互相打架。而且这与任何现代游戏反作弊都不兼容,现在的游戏反作弊都也会hook iat,导致进一步冲突.

一般来说,客户在发现游戏和杀毒软件冲突的时候,会优先卸载杀毒软件.

扩展阅读:直接物理内存读写

在早期我印象中的漏洞驱动,都是一些主板刷bios/cpuz/gpuz的驱动，这些驱动有一些物理内存读写的API,忘记做校验导致被利用.利用去关闭dse这里以GPUZ漏洞利用为例:不做任何校验,直接用了MMIO:所以可以给gpuz发控制码读物理内存而我们只有读物理内存的权利,所以还需要寻找到system PML4 这样才能翻译系统内存有了系统PML4后,就可以做地址翻译,把虚拟地址翻译为物理地址.然后进行读写能做内核任意读写了,就可以干任何事情了,比如关闭驱动DSE暴力搜特征码关的关掉后就可以加载任意驱动了，或者跟之前一样, 遍历handle table拉高自己的handle权限 然后关闭安全软件不过这个技术在系统windows1809后这种很少见了,因为windows加了一个机制,禁止这些物理内存读写的API访问系统CR3,如果访问了会被蓝屏打开IDA,可以看到在iMapContiguousMemory的实现里面有这个代码可以看到,它通过MiFillSystemPtes

if ( (int)MiFillSystemPtes(v16, v12, v24, v5, v17, (__int64)&v23) < 0 )  {    MiReleasePtes(&qword_43C0A0, v16, v14);    return 0i64;  }

阻止了这些API对系统CR3的访问。访问不了系统CR3,也就没办法做后续了。当然还有后续,后续有个全新的方法继续绕过继续利用,毕竟对抗永无止境:

【漏洞分析】从驱动直接读写物理内存漏洞 到内存加载驱动分析

对杀毒软件对抗这些感兴趣吗? 感兴趣具体更多可以参考:

深度了解现代安全软件对抗与缓解措施

阅读原文

跳转微信打开

]]> Tue, 16 Sep 2025 10:00:00 +0800 深入研究银狐木马通过网络致盲安全软件的技术原理与解决方案 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485364&idx=1&sn=8fd1ae4f1ee3e50572383bce2a7b4fff 深入研究R3通过网络(WFP架构)致盲EDR的技术原理与解决方案 原创 为了安全鸭 2025-08-31 10:00 北京

深入研究R3通过网络(WFP架构)致盲EDR的技术原理与解决方案

前言

从2025年的安全对抗环境的越来越猖獗的银狐事件来看,我们进入了国内安全行业泡沫被戳破后的回归期:

国内正在回归到最原始的技术论成败的阶段,而不是PPT美观论成败阶段.
这一点,可以从这几年 银狐/RAT/红队 的一些手法论证:
各种威胁组织正在大量用漏洞/设计缺陷致盲EDR/AV,就比如今天所说的通过WFP致盲的问题

WFP

无论是银狐/黑产/APT 大规模用的EDRSilencer:

还是顺丰安全应急响应中心的沧总发的
EDR监测遭遇滑铁卢？无驱动技术让你轻松突破EDR！

本质上是利用windows的一个狗屎机制->WFP
WFP最开始是想做一个ALL IN ONE的网络过滤框架，以代替NDIS.比如杀毒软件过滤可以用WFP，TUN/VPN/防火墙也可以用WFP实现自己的功能.只不过,他们设计之初忘记了一个核心要素: 鉴权

从理论上来说,WFP在设计之初应该考虑鉴权,最基本的如,R3不能影响R0的WFP回调,或者每个程序的WFP都跟自己的进程绑定,进程不在了则自动退出.等等,但是微软没有考虑到这一点,或者说写WFP的那伙人可能都不是windows的主力开发(参考minifilter架构,很明显确认基本不是一伙人).在windows中WFP里,R3是可以影响到R0的回调的!

黑产利用

在EDRSilencer项目中我们可以看到,他们利用R3的WFP给其他进程套了一个WFP过滤器

套完后我们可以看到多了一个layers,但是这个layers默认类型是FWP_ACTION_BLOCK

在顺丰安全应急响应中心的沧总的代码中,是利用WFP删除杀毒软件的网络监控回调:

破局之道

让我们回归技术,冷静分析WFP的工作流程.让我们以沧总的代码为例,学习R3是如何给R0提交WFP操作的:

WFP的R3->R0过程

R3的WFP操作这个本质上是一个RPC客户端包装

会发给

C:\Windows\system32\svchost.exe -k LocalServiceNoNetworkFirewall -p

从windbg中我们可以论证到这一点:

而这个svchost会调用BfeDeviceIoControl去进入内核

内核会走到
而他最终会走到tcpip—>KfdDriverEntry->KfdDispatchDevCtl

然后这个转发到了netio!IoctlKfdBatchUpdate里面:

总体流程是:

R3->RPC服务器->bfe.dll->tcpip!KfdDriverEntry->tcpip!KfdDispatchDevCtl->netio!IoctlKfdBatchUpdate

IoctlKfdBatchUpdate

IoctlKfdBatchUpdate是最后一步,这里先说结论,无论是EDRSilencer的给别人套WFP回调,还是沧总的删除WFP回调致盲网络过滤,都会走到BatchUpdate.
让我们仔细分析一下这个batchupdate.
他的AI美化代码如下,放心,我做了删减


// 优化后的 IoctlKfdBatchUpdate 函数
NTSTATUS IoctlKfdBatchUpdate(
    PVOID BatchUpdateBuffer,
    ULONG BatchUpdateSize,
    PVOID *Result)
{
    // 解码批量更新对象
    status = WfpMidlObjectDecode(
        PWFP_BATCH_UPDATE_IOCTL_Decode,
        BatchUpdateBuffer,
        BatchUpdateSize,
        (PVOID *)&batchUpdateObj);
    .....
    // 处理添加过滤器到索引
    for (i = 0; i < batchUpdateObj->FilterCount; i++) {
        PFILTER_DESCRIPTOR filterDesc = (PFILTER_DESCRIPTOR)((PBYTE)batchUpdateObj->FilterDescriptors + 24 * i);
        PFILTER_OBJECT filterObj = *(PFILTER_OBJECT *)((PBYTE)batchUpdateObj->FilterObjects + 8 * i);
        ......
    }
    // 处理删除过滤器
    for (i = 0; i < batchUpdateObj->DeleteFilterCount; i++) {
        PFILTER_DESCRIPTOR filterDesc = (PFILTER_DESCRIPTOR)((PBYTE)batchUpdateObj->DeleteFilterDescriptors + 16 * i);
        PFILTER_OBJECT filterObj = *(PFILTER_OBJECT *)((PBYTE)batchUpdateObj->DeleteFilterDescriptors + 16 * i + 8);
        .......
    }
    ....
    return status;
}

实际上,我们可以注意到,关键就在于WfpMidlObjectDecode所调用的PWFP_BATCH_UPDATE_IOCTL_Decode函数.而这个函数告诉我们,他在用RPC解码.R3发的其实是一个RPC的结构体:

__int64 __fastcall PWFP_BATCH_UPDATE_IOCTL_Decode(__int64 handle, __int64 ppObject)
{
  return NdrMesTypeDecode3(
           handle,
           &g_BatchUpdateTypeInfo,
           &g_BatchUpdateFormatString,
           &g_BatchUpdateProcFormatString,
           1,
           ppObject);
}

而他实际干的操作是,用户发来信息->RPC反序化->正常结构体
这个正常结构体长这样:

// 批量更新上下文结构体
typedef struct _BATCH_UPDATE_CONTEXT {
    PVOID BatchUpdateObject;      // 偏移量 0
    BYTE UnknownData[20];          // 偏移量 8
    BYTE StateArray[99];           // 偏移量 20
    BYTE UnknownData2[1];         // 偏移量 119
    ULONG Counter;                 // 偏移量 120
    // 可能还有更多字段
} BATCH_UPDATE_CONTEXT, *PBATCH_UPDATE_CONTEXT;
// 批量更新对象结构体
typedef struct _BATCH_UPDATE_OBJECT {
    // 偏移量 0 处的未知字段
    ULONG FilterCount;             // 偏移量 4
    // 偏移量 8 处的未知字段
    PVOID FilterDescriptors;       // 偏移量 16
    PVOID FilterObjects;           // 偏移量 24
    ULONG DeleteFilterCount;       // 偏移量 32
    // 偏移量 36 处的未知字段
    PVOID DeleteFilterDescriptors; // 偏移量 40
    // 可能还有更多字段
} BATCH_UPDATE_OBJECT, *PBATCH_UPDATE_OBJECT;
// 过滤器描述符结构体
typedef struct _FILTER_DESCRIPTOR {
    // 偏移量 0 处的未知字段
    USHORT FilterId;               // 偏移量 16
    ULONG UnknownValue;            // 偏移量 20
    // 可能还有更多字段
} FILTER_DESCRIPTOR, *PFILTER_DESCRIPTOR;
// 过滤器对象结构体
typedef struct _FILTER_OBJECT {
    // 偏移量 0 处的未知字段
    ULONG Flags;                   // 偏移量 40
    // 可能还有更多字段
} FILTER_OBJECT, *PFILTER_OBJECT;
// 内部过滤器结构体
typedef struct _INT_FILTER {
    // 偏移量 0 处的未知字段
    LONG64 ReferenceCount;         // 偏移量 16
    // 偏移量 24 处的未知字段
    PFILTER_OBJECT FilterObject;   // 偏移量 24
    // 偏移量 32 处的未知字段
    ULONG StateFlags;              // 偏移量 52
    // 可能还有更多字段
} INT_FILTER, *PINT_FILTER;

解决思路

既然是IoControl,我们可以做irp stack attch.去检测这一行为,实际上,我们只需要附加Tcpip驱动就行:

关键问题在于,我们没有微软的MDL文件,这个文件是自动生成的,因此我们解不了用户发来的结构体.
因此我们要手动推导一下结构体,windbg断下iocontrole后看看buffer:

把这buffer写到磁盘文件,用relcass打开推一下,这里直接说结论吧,有两个类型的删除操作,一个类型的增加操作,这里不说增加的,之说删除的.
经过几十分钟的推导后,我们从一开始的raw数据逐步推导出了如下操作:
raw数据:

推导出来后的:
删除操作1: type0x40

删除操作2: type0x38

增加操作: type0x101:

让我们总结一下:
rpc_header->
type
data <-这里面就是我们要的信息
其中type == 0x38的时候

struct WfpUpdateBatch_Type0x38_Array {
    uint32_t Array_MagicNum;    // 0x002C
    uint32_t Array_Conditions;  // 0x0030
    uint32_t Array_flags;       // 0x0034
    uint32_t Array_unk3;        // 0x0038
    uint32_t Array_unk4;        // 0x003C
    uint32_t Array_LayerId;     // 0x0040
    uint32_t Array_unk5;        // 0x0044
};
struct WfpUpdateBatch_Type0x38 {
    WfpUpdateBatch_Header header;
    uint32_t Version;        // 0x0010
    uint32_t Unk5;           // 0x0014
    uint32_t Unk6;           // 0x0018
    uint32_t Unk7;           // 0x001C
    uint32_t Unk8;           // 0x0020
    uint32_t Unk9;           // 0x0024
    uint32_t DelArrayCount;  // 0x0028
    WfpUpdateBatch_Type0x38_Array Arrays[1];
};

其中type==0x40的时候

struct WfpUpdateBatch_Type0x40_Array {
    uint32_t Array_MagicNum;    // 0x002C
    uint32_t Array_unk;         // 0x0030
    uint32_t Array_unk2;        // 0x0034
    uint32_t Array_Conditions;  // 0x0038
    uint32_t Array_unk4;        // 0x003C
    uint32_t Array_unk5;        // 0x0040
    uint32_t Array_unk6;        // 0x0044
    uint32_t Array_LayerId;     // 0x0048
    uint32_t Array_unk7;        // 0x004C
};
struct WfpUpdateBatch_Type0x40 {
    WfpUpdateBatch_Header header;
    uint32_t Version;        // 0x0010
    uint32_t Unk4;           // 0x0014
    uint32_t Unk5;           // 0x0018
    uint32_t Unk6;           // 0x001C
    uint32_t Unk7;           // 0x0020
    uint32_t Unk8;           // 0x0024
    uint32_t DelArrayCount;  // 0x0028
    WfpUpdateBatch_Type0x40_Array Arrays[1];
};

那么问题就非常简单了:

  1. irp hook tcpip驱动

  2. 判断IOCODE是不是batchupdate

  3. 解码WFP的结构体,通过自己推算的结构体

让我们直接开始

最终解决方案

irp hook tcpip驱动


判断IOCODE是不是batchupdate

解码WFP的结构体,通过自己推算的结构体

结果

删除一些回调,可以看到成功检测:


我们成功检测到了WFP回调删除,EDRSilencer同理能被检测.

后续

其实，EDR在沧总那篇文章出来后就做了更新了:

参考资料

https://github.com/netero1010/EDRSilencer

题外话

自从搞安全以来,天天听大家说各种不好,确实,这行业从2012年开始就被喷这不好那不好,但是个人作为一个打工人还是认为,好不好只是行业的事情.跟打工人毫无关系.打工人做的不是抱怨/焦虑. 而是提高自己,用比较古老的话来说:

技术在手,天下我有

阅读原文

跳转微信打开

]]> Sun, 31 Aug 2025 10:00:00 +0800 从0制作IDA的F5代码还原功能(hex-rays插件) 上 https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485332&idx=1&sn=25ef87ab7af839c54e8e4727bfd045cb 原创 为了安全鸭 2025-08-12 09:30 北京

前言

说来惭愧,鸭哥的业余时间娱乐活动一般除了 dota 外,就还剩下写代码,尤其是一些”高难度”的代码,我喜欢业余的时候打磨一下.每年给自己定个目标,比如去年是 VMP 还原的代码

[2025]VMP3.x 原理详解与还原思路
https://key08.com/index.php/2025/04/20/2467.html

你是否想过IDA的F5/bn的 伪C代码怎么来的,即便是有开源的NSA的Ghidra/avast的retdec也看不懂代码? 因为这些都是复杂的成品工程项目,而核心代码相比各种乱七八糟的UI调用其实少得可怜
所以让我们实际操作一下,手写一个类似于IDA的F5的功能,一起学习一下这块的工作原理

这块做的过程中觉得很难,但是实际上,特别简单,没什么难度,我们依次介绍原理,详解,并且逐步实现一个看起来能用的东西

免责声明: 我不是专业搞编译器的，整个过程的路线是能跑就行,要是有高手发现我写的有问题,评论区跟我说一下,我们一起探讨一下

先放几个成品图:

最开始的想法是为了做 NGAV:

2024 年终: 木马病毒自动化特征提取&云端机器学习的思路分享
https://key08.com/index.php/2024/12/28/2310.html

不过后来由于今年业务相关的东西太忙,在公司一直没时间写,只能周末空闲的时候当娱乐活动随便写写研究了.

警告,本文1万字,并且没有一点AI的参与,看不懂是正常的,我建议丢给GPT做阅读.我自己写完后看也头疼.不硬着头皮从0开始一步一步看是看不懂的.由于公众号的格式太难受了,想要pdf的朋友,后台回复”IDA制作”,可以拿到原始的PDF

原理

IDA 识别到能一键 F5 实际上可以分为几个具体步骤:

  1. PE 识别，导入表，导出表，TLS 等等

  2. 基于（1），进行函数识别，标记哪些位置是函数

  3. 基于（2），提升为 LLIL 也就是 low level IL,这个主要负责将 汇编 转为自己的通用翻译语言。这代表上层不需要关系汇编的架构什么的（比如，X64，MIPS,等等 转 IL 后都不需要关心了）

  4. 基于（3） 提升为 MIDDLE LEVEL IL，而这个过程我们需要根据 RSP/RBP 访问标记函数，解析符号，并且识别函数内容

  5. 基于（4） 做进一步优化，总而成为 HIGHT LLIL。这一步后,就已经是 IDA F5 后的形状了

需要注意的是,这个过程并不是严格线性的。比如在 LLIL 提升过程中,可能会发现新的函数,这时需要回到第 2 步重新进行函数识别。整个过程是迭代式的,每一步都可能影响其他步骤。
我们以 BN 为例子:
我们以 BN 为例子:

  1. bn 的汇编模式:

    你可以看到,在这个阶段,bn 只是显示纯汇编(虽然可能有一些标注)

  2. BN 的 llil 模式:

    这个时候,原来的汇编已经变成了 BN 的一种中间码,这样 BN 就能很愉快的处理各种乱七八糟的平台的汇编,比如 ARM,mips 等等
    3.MLIL 模式:

    这个模式下的 BN,在 LLIL 的基础上已经标识了
    函数调用/函数参数/符号及代码做了优化

  3. HLIL 模式与 C 语言模式:

    这个时候,已经跟本来的 C 语言没什么区别了.可能没有 C 语言能导出去运行的功能而已，这个是 C 语言的

函数识别

初级函数识别

我们整个旅程的第一步，就是识别函数.如何做到在没符号识别函数是一个学问，我们不能太宽泛，就先假定目标是 windows x64。

识别 winx64 的 函数 最基本的办法是遍历 text 段找 call,我们可以遍历出 所有的 call imm 指令以及 JMP 指令，这些指令通常是一个函数.
基本代码如下:

其中 call 后就是我们识别的函数。
此外,msvc 编译器编译出来的程序,会带 cfg 保护区段

CFG（Control Flow Guard）是微软推出的漏洞利用缓解机制，从 Windows 8.1 开始引入，并且需要编译器的支持，编译器的版本为 Virtual Studio 2015 Updated 2 版本以上。
在开启了 CFG 支持以后，编译生成 exe 程序中，所有间接调用前面都会插入一个_guard_check_icall 的检查函数，如果系统不支持 CFG 机制，则该函数不会生效。

如下就是一个经典的例子:

eax,[esi]
ecx, eax
call _guard_check_icall  // CFG检查函数
call eax

_guard_check_icall 函数的地址,在 PE 程序被系统加载的时候会被替换成 nt!LdrpValidateUserCallTarget 函数的地址
nt!LdrpValidateUserCallTarget 函数的参数就是上面 ecx 的值，也就是间接调用的函数地址

校验逻辑如下：

1）间接调用函数地址共 4 字节,取高 3 字节的值加上 CFGBitmap 表的基址,得到 CFGBitmap 表中的值
2）判断间接调用地址是否 0x10 对齐：
2.1) 如果是对齐的,函数地址的第 4-8 位的值,就是上面获取的 CFGBitmap 表值的位偏移
2.2) 如果不是对齐的,函数地址的第 4-8 位的值,再或上 1,得到的值就是 CFGBitmap 表值的位偏移
3）验证 CFGBitmap 表值的位偏移处的 bit 位，如果是 1,则说明这个函数是有效的,否则产生异常

在 PE 结构的 loadConfig 信息中保存了：

1）_guard_check_icall 的函数地址
2）CFGBitmap 表的 RVA，这里面是该程序的每个函数的 RVA 转换成 1bit 的值,制作成的一个 CFGBitmap 表
3）CFGBitmap 中函数的数量

来源:
https://blog.csdn.net/cssxn/article/details/101285088
因此我们也必须要识别是否是来自 cfg 控制区段的跳转,否则我们是没办法检测到函数的
基本代码如下:

值得注意的是，这个只是最基本的函数识别，这没办法处理其他情况，尤其是对于 VT 函数，我们应该需要搜索 rdata 去处理，除此之外，我们还需要从如下地方找：

  1. 暴力特征函数序言

  2. 异常处理表

  3. TLS 回调

  4. 虚表/class

除了直接的 call/jmp 指令识别,我们还需要处理以下情况:

// 典型的间接跳转模式
mov rax, [some_address]
call rax

跳转表

// 常见于switch-case实现
jmp qword ptr [rax*8 + jump_table]

这些情况需要进行数据流分析才能准确识别目标函数。
一个完整的代码如下:

函数识别

初级函数识别

我们整个旅程的第一步，就是识别函数.如何做到在没符号识别函数是一个学问，我们不能太宽泛，就先假定目标是 windows x64。

识别 winx64 的 函数 最基本的办法是遍历 text 段找 call,我们可以遍历出 所有的 call imm 指令以及 JMP 指令，这些指令通常是一个函数.
基本代码如下:

其中 call 后就是我们识别的函数。
此外,msvc 编译器编译出来的程序,会带 cfg 保护区段

CFG（Control Flow Guard）是微软推出的漏洞利用缓解机制，从 Windows 8.1 开始引入，并且需要编译器的支持，编译器的版本为 Virtual Studio 2015 Updated 2 版本以上。
在开启了 CFG 支持以后，编译生成 exe 程序中，所有间接调用前面都会插入一个_guard_check_icall 的检查函数，如果系统不支持 CFG 机制，则该函数不会生效。

如下就是一个经典的例子:

eax,[esi]
ecx, eax
call _guard_check_icall  // CFG检查函数
call eax

_guard_check_icall 函数的地址,在 PE 程序被系统加载的时候会被替换成 nt!LdrpValidateUserCallTarget 函数的地址
nt!LdrpValidateUserCallTarget 函数的参数就是上面 ecx 的值，也就是间接调用的函数地址

校验逻辑如下：

1）间接调用函数地址共 4 字节,取高 3 字节的值加上 CFGBitmap 表的基址,得到 CFGBitmap 表中的值
2）判断间接调用地址是否 0x10 对齐：
2.1) 如果是对齐的,函数地址的第 4-8 位的值,就是上面获取的 CFGBitmap 表值的位偏移
2.2) 如果不是对齐的,函数地址的第 4-8 位的值,再或上 1,得到的值就是 CFGBitmap 表值的位偏移
3）验证 CFGBitmap 表值的位偏移处的 bit 位，如果是 1,则说明这个函数是有效的,否则产生异常

在 PE 结构的 loadConfig 信息中保存了：

1）_guard_check_icall 的函数地址
2）CFGBitmap 表的 RVA，这里面是该程序的每个函数的 RVA 转换成 1bit 的值,制作成的一个 CFGBitmap 表
3）CFGBitmap 中函数的数量

来源:
https://blog.csdn.net/cssxn/article/details/101285088
因此我们也必须要识别是否是来自 cfg 控制区段的跳转,否则我们是没办法检测到函数的
基本代码如下:

值得注意的是，这个只是最基本的函数识别，这没办法处理其他情况，尤其是对于 VT 函数，我们应该需要搜索 rdata 去处理，除此之外，我们还需要从如下地方找：

  1. 暴力特征函数序言

  2. 异常处理表

  3. TLS 回调

  4. 虚表/class

除了直接的 call/jmp 指令识别,我们还需要处理以下情况:

// 典型的间接跳转模式
mov rax, [some_address]
call rax

跳转表

// 常见于switch-case实现
jmp qword ptr [rax*8 + jump_table]

这些情况需要进行数据流分析才能准确识别目标函数。
一个完整的代码如下:

函数识别的难点与挑战

在基础函数识别之外，实际场景中还存在许多复杂情况需要处理：
编译器优化导致的函数识别困难

// 尾调用优化
void funcA() {
    return funcB();  // 编译器会直接优化为 jmp funcB
}
// 内联优化
inline void funcC() {
    // 函数体直接被插入调用处
}

反调试技术的影响
一些程序会使用特殊技术干扰函数识别：

// 花指令
push rax
jmp $+5
db 0xE8  // 假call指令
pop rax
// 真实代码继续...

虚函数表的处理
需要专门的算法来处理 C++的虚函数表：

struct VTable {
    void* func1;
    void* func2;
};
class Base {
    virtual void vfunc() = 0;
    VTable* vtable;
};

改进的函数识别算法
我们可以通过以下方式提高函数识别的准确率：

  1. 启发式规则
    检查函数序言模式（非仅 prolog）
    分析栈平衡情况
    追踪寄存器使用模式

  2. 交叉引用

  3. 数据流分析

函数大小计算

现在,我们遇到了一个麻烦: 函数大小计算

可能有一些逆向人认为,直接查找 ret 即可完成任务。知道了函数开头，直接查找第一次出现的 ret 就是函数的大小。
但是事实并非如此，并且函数大小计算是一个充满启发性的计算。不是想象中那么容易能算出来的。让我们一步一步的说明为什么

存在的问题

如果我们直接看函数的 ret 会怎么样？看第一次出现的 ret，就能非常轻松的确定是哪个。
如果实际这样做过，你就会发现，大小完全的不准。这是因为各个编译器编译参数不一样,不一定是以 ret 为函数结尾

比如这个函数:

int test_function(int x) {
    volatile int a = x;
    if (a > 0) {
        for (int i = 0; i < a; i++) {
            if (i * i > a) {
                return a + i;
            }
        }
        return a + 1;
    }
    return a - 1;
}

在 clang 的情况下,是这样:

test_function(int):
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 8], edi
        mov     eax, dword ptr [rbp - 8]
        mov     dword ptr [rbp - 12], eax
        mov     eax, dword ptr [rbp - 12]
        cmp     eax, 0
        jle     .LBB0_8
        mov     dword ptr [rbp - 16], 0
.LBB0_2:
        mov     eax, dword ptr [rbp - 16]
        mov     ecx, dword ptr [rbp - 12]
        cmp     eax, ecx
        jge     .LBB0_7
        mov     eax, dword ptr [rbp - 16]
        imul    eax, dword ptr [rbp - 16]
        mov     ecx, dword ptr [rbp - 12]
        cmp     eax, ecx
        jle     .LBB0_5
        mov     eax, dword ptr [rbp - 12]
        add     eax, dword ptr [rbp - 16]
        mov     dword ptr [rbp - 4], eax
        jmp     .LBB0_9
.LBB0_5:
        jmp     .LBB0_6
.LBB0_6:
        mov     eax, dword ptr [rbp - 16]
        add     eax, 1
        mov     dword ptr [rbp - 16], eax
        jmp     .LBB0_2
.LBB0_7:
        mov     eax, dword ptr [rbp - 12]
        add     eax, 1
        mov     dword ptr [rbp - 4], eax
        jmp     .LBB0_9
.LBB0_8:
        mov     eax, dword ptr [rbp - 12]
        sub     eax, 1
        mov     dword ptr [rbp - 4], eax
.LBB0_9:
        mov     eax, dword ptr [rbp - 4]
        pop     rbp
        ret

开了-o2 优化后,会变成这样

test_function(int):
        mov     dword ptr [rsp - 4], edi
        cmp     dword ptr [rsp - 4], 0
        mov     eax, dword ptr [rsp - 4]
        jle     .LBB0_7
        test    eax, eax
        jle     .LBB0_6
        xor     eax, eax
.LBB0_3:
        mov     ecx, eax
        imul    ecx, eax
        cmp     ecx, dword ptr [rsp - 4]
        jg      .LBB0_4
        inc     eax
        cmp     eax, dword ptr [rsp - 4]
        jl      .LBB0_3
.LBB0_6:
        mov     eax, dword ptr [rsp - 4]
        inc     eax
        ret
.LBB0_7:
        dec     eax
        ret
.LBB0_4:
        add     eax, dword ptr [rsp - 4]
        ret

非常明显，我们多了几个 RET,这是因为:
不开优化（-O0）时：

编译器会按照代码的字面顺序直接翻译
所有返回语句通常会跳转到函数末尾的一个公共返回点
这样做便于调试，因为执行路径更直观

开启优化（-O2）时：

编译器会尝试优化执行路径，减少指令数量
如果发现直接返回比跳转到公共返回点更高效，就会生成多个 ret
这样可以省去额外的跳转指令

所以,直接找 ret 不可取,并且导致了一个麻烦的结论

所有软件对函数大小的计算,都是启发性的,并不能精准识别.

我们需要一个更加聪明的办法.

聪明的办法

要准确计算函数大小，我们需要分析函数的控制流。主要思路是：追踪所有可能的执行路径，直到找到所有可能的结束点。

具体来说,我们需要：

  1. 追踪所有的跳转指令（jmp, jz, jnz 等）

  2. 分析条件分支创造的多个执行路径

  3. 找到每个路径的终点（ret 指令）

  4. 取所有终点中地址最大的那个作为函数结束位置

这将会尽可能的找到我们需要的函数方向.

具体实现

基本的实现流程如下：

function FindFunctionEnd(startAddress):
    1. 反汇编当前地址的指令
    2. 如果是返回指令，记录当前位置+指令长度
    3. 如果是跳转指令：
       - 验证跳转目标的合法性
       - 递归分析跳转目标
       - 继续分析当前路径
    4. 返回找到的最远结束地址

为了避免重复分析和无限递归，我们需要：

  1. 使用哈希表记录已分析过的地址

  2. 检查跳转目标是否在合理范围内

  3. 防止向低地址的非法跳转

关键点处理

跳转指令分析：

if (isJump(instruction)) {
    // 获取跳转目标
    targetAddress = getJumpTarget(instruction);
    // 验证目标地址
    if (isValidTarget(targetAddress)) {
        // 递归分析新路径
        endAddr = max(endAddr, FindFunctionEnd(targetAddress));
    }
}

这样会追踪所有可能的执行路径

示例代码：
if (x > 0) {
    return 1;
} else {
    return 2;
}
汇编代码：
    cmp eax, 0
    jle else_branch   // 条件跳转,创建两条路径
    mov eax, 1
    ret              // 路径1的结束点
else_branch:
    mov eax, 2
    ret              // 路径2的结束点

如果不分析跳转,就会漏掉 else 分支的 ret,导致函数大小计算错误

另外这个不允许向上跳转，向上跳转则认为这个跳转没意义,我们假设代码是从下到上的.因此还需要地址合法性检查

地址合法性检查代码:

bool isValidTarget(targetAddress) {
    // 不允许向低地址跳转
    if (targetAddress < functionStart)
        return false;
    // 不允许跳出代码段
    if (targetAddress > codeSegmentEnd)
        return false;
    // 避免重复分析
    if (alreadyAnalyzed(targetAddress))
        return false;
    return true;
}

地址合法性检查存在的意义是,防止向下跳转导致的误判,如下所示:

function_A:
    ...
function_B:
    jmp function_A   // 如果允许向下跳转，可能误判为function_B的一部分

以及避免跨段访问

.text:
    function_start:
        jmp data_section  // 不允许跳转到数据段
.data:
    data_section:
        db "Hello"

这样,我们终于能安心的寻找最后一个 RET 了:

测试

上面的代码,IDA 里面大小是 0x50:

而以上的实现,也是 0x50:

如果直接看单独 ret 的存在,我们是没办法这样匹配的

CFG 分析的基本原理

控制流图是程序分析的核心，它将代码分解为基本块（Basic Blocks），并表示这些块之间的控制转移关系。我们的实现主要分为以下几个步骤：

  1. 识别函数入口点

  2. 分解函数为基本块

  3. 建立基本块之间的连接关系

  4. 处理特殊情况（如 CFG 保护机制）

基本块的本质与控制流分析

在编译理论和静态分析领域，基本块（Basic Block）是程序分析的基础单元。一个基本块是满足以下条件的最大连续指令序列：

  1. 只有一个入口点（第一条指令）

  2. 只有一个出口点（最后一条指令）

  3. 如果执行了第一条指令，那么块内的所有指令都会按顺序执行，没有分支、跳转或者提前终止

基本块的这种特性使得我们可以将复杂的程序分解为更易于分析的单元，进而构建控制流图（CFG）。

如图所示,这个就是 IDA 的每个块的直观表示:

为了实现块分析,我们需要两步走

第一步：识别所有基本块的起始地址

这一步的核心思想是通过广度优先搜索（BFS）来识别所有可能的基本块起始点。我们从函数入口开始，在遇到控制流改变的指令时（如跳转、条件分支、返回等），我们认为当前基本块结束，并且标记潜在的新基本块起始点：

std::set<uint64_t> blockStarts{addressInFile};  // 初始化集合，包含函数的入口地址
std::set<uint64_t> processedAddrs;  // 已处理地址集合
std::queue<uint64_t> workList;      // 工作队列
workList.push(addressInFile);
// 第一轮：找出所有基本块的起始地址
while (!workList.empty()) {
    uint64_t currentAddr = workList.front();
    workList.pop();
    // 避免重复处理
    if (processedAddrs.count(currentAddr) > 0) {
        continue;
    }
    processedAddrs.insert(currentAddr);
    // 反汇编当前地址处的指令
    cs_insn* insn;
    size_t offset = currentAddr - addressInFile;
    if (offset >= size) continue;
    size_t count = cs_disasm(handle, addressInMemory + offset,
                             size - offset, currentAddr, 0, &insn);
    if (count == 0) continue;
    // 遍历反汇编出的指令
    for (size_t i = 0; i < count; i++) {
        auto theInsn = &insn[i];
        auto termType = GetBlockTerminatorType(theInsn);
        // 如果是块终止指令（如跳转、返回等）
        if (termType != BlockTerminatorType::kNone) {
            auto targets = GetBlockTargets(theInsn);
            auto isCondJmp = is_cond_jump(theInsn);
            // 处理跳转目标
            for (auto target : targets) {
                if (target >= addressInFile && target < addressInFile + size) {
                    blockStarts.insert(target);
                    workList.push(target);
                }
            }
            // 对于条件跳转，下一条指令也是新块的开始
            if (isCondJmp && i + 1 < count) {
                blockStarts.insert(insn[i + 1].address);
                workList.push(insn[i + 1].address);
            }
            // 非返回且非条件跳转情况下，也考虑后续指令
            if (termType != BlockTerminatorType::kRet && !isCondJmp) {
                if (i + 1 < count) {
                    blockStarts.insert(insn[i + 1].address);
                    workList.push(insn[i + 1].address);
                }
            }
            break;  // 当前基本块结束
        }
    }
    cs_free(insn, count);
}

对于跳转指令（如 JMP、JE 等），跳转目标地址成为新基本块的起始点
对于条件跳转，不仅跳转目标是新基本块，跳转指令之后的下一条指令也是新基本块
对于返回指令（RET），没有新的基本块起始点

这个过程使用工作队列（workList）实现，以确保我们能够处理所有可达的代码路径，即使存在复杂的跳转关系。

第二步：创建基本块对象

在这一步中，我们根据第一步识别的所有基本块起始地址，构建完整的基本块对象。对于每个起始地址，我们：

  1. 创建一个新的基本块对象

  2. 设置起始地址（文件中和内存中）

  3. 反汇编指令，直到找到一个终止指令或下一个已知的基本块起始点

  4. 记录终止类型和后继块地址

  5. 设置结束地址

  6. 将完整的基本块添加到列表中

这种方法可以确保我们不会漏掉任何执行路径，并且正确识别基本块的边界。

// 第二轮：根据起始地址创建实际的基本块对象
for (auto blockStart : blockStarts) {
    Block currentBlock;
    currentBlock.startAddressInFile = blockStart;
    currentBlock.startAddressInMemory = func.address + (blockStart - addressInFile);
    size_t offset = blockStart - addressInFile;
    if (offset >= size) continue;
    cs_insn* insn;
    size_t count = cs_disasm(handle, addressInMemory + offset,
                             size - offset, blockStart, 0, &insn);
    if (count == 0) continue;
    for (size_t i = 0; i < count; i++) {
        auto termType = GetBlockTerminatorType(&insn[i]);
        // 如果是终止指令
        if (termType != BlockTerminatorType::kNone) {
            auto isCondJmp = is_cond_jump(&insn[i]);
            currentBlock.terminatorType = termType;
            currentBlock.nextBlockAddresses = GetBlockTargets(&insn[i]);
            currentBlock.endAddressInFile = insn[i].address + insn[i].size;
            currentBlock.endAddressInMemory = func.address + (insn[i].address - addressInFile) + insn[i].size;
            // 对于条件跳转，添加顺序执行的下一个块地址
            if (isCondJmp && i + 1 < count) {
                currentBlock.nextBlockAddresses.push_back(insn[i + 1].address);
            }
            // 检查目标的有效性
            bool hasValidTarget = false;
            for (auto target : currentBlock.nextBlockAddresses) {
                if (target >= addressInFile && target < addressInFile + size) {
                    hasValidTarget = true;
                    break;
                }
            }
            if (hasValidTarget || termType == BlockTerminatorType::kRet) {
                blocks.push_back(std::make_shared<Block>(currentBlock));
            }
            break;
        }
        // 如果下一条指令是已知的新块起始点
        if (i + 1 < count && blockStarts.count(insn[i + 1].address) > 0) {
            currentBlock.endAddressInFile = insn[i].address + insn[i].size;
            currentBlock.terminatorType = BlockTerminatorType::kNone;
            currentBlock.endAddressInMemory = func.address + ((insn[i].address + insn[i].size) - addressInFile);
            blocks.push_back(std::make_shared<Block>(currentBlock));
            break;
        }
    }
    cs_free(insn, count);
}

细节 1: 判断块终止符类型

我这边简单的识别了各种类型的返回指令和跳转指令，并将它们映射到对应的终止符类型。值得注意的是，CALL 指令通常不会结束基本块，因为调用完成后控制流会继续。

auto GetBlockTerminatorType(const cs_insn* insn) -> BlockTerminatorType {
    if (insn->id == X86_INS_RET) return BlockTerminatorType::kRet;
    if (insn->id == X86_INS_JMP) return BlockTerminatorType::kJmp;
    if (insn->id == X86_INS_JE) return BlockTerminatorType::kJz;
    if (insn->id == X86_INS_JNE) return BlockTerminatorType::kJnz;
    if (insn->id == X86_INS_JBE) return BlockTerminatorType::kJbe;
    if (insn->id == X86_INS_JB) return BlockTerminatorType::kJb;
    if (insn->id == X86_INS_JS) return BlockTerminatorType::kJs;
    if (insn->id == X86_INS_JO) return BlockTerminatorType::kJ0;
    if (insn->id == X86_INS_JP) return BlockTerminatorType::kJp;
    if (insn->id == X86_INS_JAE) return BlockTerminatorType::kJnb;
    // if (insn->id == X86_INS_CALL) return BlockTerminatorType::kCall;
    return BlockTerminatorType::kNone;
}

细节 2: 确定跳转目标

我们同时也需要确定跳转指令的目标地址。它处理了两种常见情况:
立即数操作数（如 JMP 0x1000）- 直接提取立即数值作为目标地址
基于 RIP 的内存操作数（如 JMP [RIP+0x100]）- 计算有效地址
此外，对于终止指令，还需要添加下一条指令的地址作为”fall-through”路径。

auto GetBlockTargets(const cs_insn* insn) -> std::vector<uint64_t> {
    std::vector<uint64_t> targets;
    // 检查指令是否有操作数
    if (insn->detail == nullptr || insn->detail->x86.op_count == 0) {
        return targets;
    }
    // 从立即数或内存操作数获取目标地址
    const auto& operand = insn->detail->x86.operands[0];
    if (operand.type == X86_OP_IMM) {
        targets.push_back(operand.imm);
    } else if (operand.type == X86_OP_MEM && operand.mem.base == X86_REG_RIP) {
        uint64_t nextInstructionAddr = insn->address + insn->size;
        uint64_t target = nextInstructionAddr + operand.mem.disp;
        targets.push_back(target);
    }
    // 对于条件跳转，也添加下一条指令地址
    auto termType = GetBlockTerminatorType(insn);
    if (termType != BlockTerminatorType::kNone) {
        targets.push_back(insn->address + insn->size);
    }
    return targets;
}

细节 3: 判断跳转条件

我们需要一个函数区分条件跳转和无条件跳转。它首先排除无条件跳转（JMP），然后检查指令是否属于跳转组。这对于正确处理控制流至关重要，因为条件跳转会产生两条可能的执行路径。

inline auto is_cond_jump(cs_insn* ins) -> bool {
    // 如果是无条件跳转，返回false
    if (ins->id == X86_INS_JMP) return false;
    // 遍历指令组
    for (int i = 0; i < ins->detail->groups_count; i++) {
        if (ins->detail->groups[i] == X86_GRP_JUMP) return true;
    }
    return false;
}

基本块之间的关系建立

在构建完所有基本块后，我们需要建立它们之间的关系。这是通过记录每个块的后继块地址实现的：

currentBlock.nextBlockAddresses = GetBlockTargets(&insn[i]);
// 对于条件跳转，添加顺序执行的下一个块地址
if (isCondJmp && i + 1 < count) {
    currentBlock.nextBlockAddresses.push_back(insn[i + 1].address);
}

这样，我们就建立了基本块之间的控制流关系，为完整的控制流图（CFG）奠定了基础。

效果展示

这个是这个算法与 IDA 的块对比截图,基本上 1:1 还原了 IDA 的块构建:

其他待解决问题

目前来说,我们还需要处理:

  1. 表驱动跳转：使用跳转表（jump table）实现 switch 语句

  2. 内联汇编：可能包含非标准的控制流转移

  3. 异常处理：try-catch 结构创建的隐式控制流

  4. 间接跳转：通过寄存器或内存中的地址进行跳转
    这几个也是现代混淆引擎最喜欢操作的部分,属于混淆-反混淆对抗阶段.如果这个系列反响还不错,我会单独出一期介绍一些主流的方法

函数参数识别

我们必须要知道一个事实是, 在没 PDB 之前，是没有一个准确的函数识别办法的，现如今所有的办法都是启发式的办法，这也是为什么逆向工具在遇到混淆的时候会拉闸。我们这边不介绍复杂的启发算法，只说一个简单的： 堆栈遍历+模式匹配 (只说 X64 的)

注意只是大概,目前没有任何靠谱办法除了不用 PDB 的情况下识别出参数,这也是为什么 IDA 也不准确

我喜欢把这个方法叫做,stackwalker

stackwalker

你可能觉得不可思议,其实他的原理非常简单(其实我想破脑袋才想出来的):

第一遍：收集所有栈访问
第二遍：分析参数使用情况
第三遍: 转换为vector并排序

第一遍：收集所有栈访问

他的原理很简单,我们统计一下是不是在序言里面,如果在prologue前,一定是参数(“启发式”),并且我们要找到rsp的adjust值,用来计算rsp和rbp的Δ,因为可能rbp,rsp操控的对象是一个var

它本质上是一个大号的模式匹配,匹配出来序言前的变量,这些一定是参数

    for (auto& theBlocks : func->llil_blocks) {
        const auto blockItem = theBlocks.get();
        for (auto& llil_ins : blockItem->instructions) {
            if (firstBlockWalked == false && func->inPrologue) {
                if (llil_ins->type == LLIL::LLILInstruction::ARITHMETIC &&
                    llil_ins->op == LLIL::LLILInstruction::Operation::ADD) {
                    func->stackAdjustment += 8;
                    if (!llil_ins->operands.empty() &&
                        llil_ins->operands[0]->type ==
                            LLIL::LLILOperand::REGISTER &&
                        llil_ins->operands[0]->value == "rbp") {
                        func->foundPushRbp = true;
                    }
                } else if (llil_ins->type ==
                               LLIL::LLILInstruction::ARITHMETIC &&
                           llil_ins->op ==
                               LLIL::LLILInstruction::Operation::SUB &&
                           llil_ins->operands.size() >= 2 &&
                           llil_ins->operands[0]->type ==
                               LLIL::LLILOperand::REGISTER &&
                           llil_ins->operands[0]->value == "rsp" &&
                           llil_ins->operands[1]->type ==
                               LLIL::LLILOperand::IMMEDIATE) {
                    func->stackAdjustment += llil_ins->operands[1]->immediate;
                    func->inPrologue = false;
                } else if (llil_ins->type == LLIL::LLILInstruction::LEA &&
                           llil_ins->operands.size() >= 2 &&
                           llil_ins->operands[0]->type ==
                               LLIL::LLILOperand::REGISTER &&
                           llil_ins->operands[0]->value == "rbp" &&
                           llil_ins->operands[1]->type ==
                               LLIL::LLILOperand::MEMORY &&
                           llil_ins->operands[1]->base == "rsp") {
                    func->rbpRspOffset = llil_ins->operands[1]->offset;
                    func->inPrologue = false;
                }
            }  // 跟踪栈帧设置
            // 记录栈访问
            auto processMemOperand = [&](const LLIL::LLILOperand op,
                                         bool isDest) {
                if (op.type != LLIL::LLILOperand::MEMORY) return;
                int64_t offset;
                if (op.base == "rsp") {
                    offset = op.offset;
                } else if (op.base == "rbp") {
                    offset = func->stackAdjustment - op.offset;
                } else {
                    return;
                }
                StackAccess access;
                access.isRead = !isDest;
                access.isLea = llil_ins->type == LLIL::LLILInstruction::LEA;
                access.insIndex = insIndex;
                access.isBeforePrologue = func->inPrologue;
                access.ins = llil_ins.get();
                stackAccesses[offset].push_back(access);
            };
            // 在处理序言中的参数保存指令时
            if (func->inPrologue &&
                llil_ins->type == LLIL::LLILInstruction::ASSIGN) {
                // 如果是写入操作，记录目标偏移
                for (auto& op : llil_ins->operands) {
                    if (op->type == LLIL::LLILOperand::MEMORY &&
                        op->base == "rsp") {
                        /*
                        int64_t targetOffset =
                            op->base == "rsp"
                                ? op->offset
                                : func->stackAdjustment - op->offset;
                        */
                        handledOffsets.insert(op->offset);
                    }
                }
            }
            if (llil_ins->type == LLIL::LLILInstruction::ASSIGN) {
                if (llil_ins->operands.size() >= 2) {
                    processMemOperand(*llil_ins->operands[0], true);   // dest
                    processMemOperand(*llil_ins->operands[1], false);  // src
                }
            } else {
                //   恢复栈指针
                //   lea     rsp, [rbp+0xc8]
                if (llil_ins->operands.size() >= 2) {
                    if (llil_ins->operands[0]->value == "rsp" &&
                        llil_ins->operands[1]->base == "rbp") {
                        continue;
                    }
                }
                for (const auto& op : llil_ins->operands) {
                    processMemOperand(*op, false);
                }
            }
            insIndex++;
        }
        firstBlockWalked = true;  // 标记已经处理过第一个块
    }

然后对于 序言里面拷贝rcx什么的到栈的操作,一律算参数

// 序言里面拷贝rcx什么的到栈的操作
    /*
        140012510  44894c2420         mov     dword [rsp+0x20 {arg_20}], r9d
        140012515  4489442418         mov     dword [rsp+0x18 {arg_18}], r8d
        14001251a  89542410           mov     dword [rsp+0x10 {arg_10}], edx
        14001251e  894c2408           mov     dword [rsp+0x8 {arg_8}], ecx
        140012522  55                 push    rbp {__saved_rbp}
        140012523  57                 push    rdi {__saved_rdi}
    */
    // bool isInPrologue = handledOffsets.find(offset) !=
    // handledOffsets.end();
    for (auto& offsetAddr : handledOffsets) {
        auto info = std::make_shared<ParamInfo>();
        auto theVars = std::make_shared<_FuncVariableInfo>();
        info->offset = offsetAddr;
        info->confidence = 1.f;
        info->insMemAddress = 0;
        info->regIndex = getRegIndexByOffset(offsetAddr);
        paramsByOffset[offsetAddr] = info;
        theVars->rawName = "param_" + std::to_string(varIndex);
        theVars->beautifullyName = theVars->rawName;
        theVars->offset = info->offset;
        theVars->regIndex = info->regIndex;
        theVars->insMemAddress = info->insMemAddress;
        func->funcVars[offsetAddr] = theVars;
        varIndex += 1;
        func->ParamInfo.push_back(info);
    }

第二遍：分析参数

然后我们分析我们捕获的所有栈访问的情况,标注这些是参数,还是无用的变量,没很复杂,基本上lea+不是在序言用的就是参数,否则只是变量,核心代码如下:

    for (const auto& [offset, accesses] : stackAccesses) {
        // if (offset < 0x8 || (offset % 8) != 0) continue;
        bool hasRealAccess = false;
        bool onlyLea = true;
        bool usedBeforePrologue = false;
        uint64_t firstAccessAddr = 0;
        for (const auto& access : accesses) {
            if (!access.isLea) {
                hasRealAccess = true;
                onlyLea = false;
            }
            if (access.isBeforePrologue) {  // 假设前5条指令是prologue之前
                usedBeforePrologue = true;
            }
            if (firstAccessAddr == 0) {
                firstAccessAddr = access.ins->address;
            }
        }
        auto theVars = std::make_shared<_FuncVariableInfo>();
        auto info = std::make_shared<ParamInfo>();
        info->offset = offset;
        info->confidence = 0.6f;
        info->insMemAddress = firstAccessAddr;
        info->regIndex = getRegIndexByOffset(offset);
        if (accesses[0].isLea == false && usedBeforePrologue) {
            paramsByOffset[offset] = info;
            theVars->rawName = "param_" + std::to_string(varIndex);
        } else {
            theVars->rawName = "var_" + std::to_string(varIndex);
        }
        theVars->beautifullyName = theVars->rawName;
        theVars->offset = info->offset;
        theVars->regIndex = info->regIndex;
        theVars->insMemAddress = info->insMemAddress;
        func->funcVars[offset] = theVars;
        varIndex += 1;
    }

最后排个序就行

   // 转换为vector并排序
    // func->ParamInfo.clear();
    // 大于四的情况下,寄存器那组传参会保存到栈上.但是地址会和之前的冲突,导致我们ParamInfo只有四个,实际寄存器已经传参了
    if (paramsByOffset.size() > 4) {
        for (const auto& [offset, param] : paramsByOffset) {
            func->ParamInfo.push_back(param);
        }
    }
    std::sort(func->ParamInfo.begin(), func->ParamInfo.end(),
              [](const std::shared_ptr<ParamInfo>& a,
                 const std::shared_ptr<ParamInfo>& b) {
                  if (a->regIndex != -1 && b->regIndex != -1)
                      return a->regIndex < b->regIndex;
                  if (a->regIndex != -1) return true;
                  if (b->regIndex != -1) return false;
                  return a->offset < b->offset;
              });
    func->ParamNum = func->ParamInfo.size();

效果:

我们正确的显示了参数列表:

ida的:

提升为Low-level il

在有了blocks/参数/calls后,我们终于可以开始正式的提升了,所谓提升,就是把汇编变成与平台无关的il.要是允许,我们可以x86提,x64提,arm提,跟平台无关.
这玩意纯体力活,他基本结构就是两个
指令
操作数

指令里面包含操作数

以及一些其他信息,比如计算操作所需要的,左边右边.以及CF影响

一些有意思的指令:

memset

在asm2llil的过程中,我们可以处理一些有意思的指令,比如 rep stosd这种,我们可以处理一下标记为memset
stosdrep

call

call需要特殊处理标记一下目标地址,原因是一些函数,其实是空客(你ida里面经常看得到的j_subxxx就是warper函数,纯空壳),所以也要特殊处理一下,之后的mlil用：

跳转

值得注意的是,跳转我们需要特殊处理一下,毕竟涉及到后续的if

如果上一个命令,是影响跳转的,比如cmp/sub,那么100%就是跳转了:

这一块我们需要稍微标记一下

剩下的还是体力活了~ 还好现在AI发达,赛博搬砖了这块

体力活

然后就是纯体力活了,这块没有一丝技术
暴力枚举capstone的指令(枚举不了的,就直接当汇编显示了之后,现在你知道ida的什么asm { vmwrite }指令块咋来的了吧):

比如mov这一类,属于ASSIGN

push单独一下

计算属于ARITHMETIC

测试

最后剩下的就是这样(忽略这些残缺的打印,这个是很早期的实现了,那会指令还没补全):

我们就完成了基本的asm2llil了,后续一系列操作都围绕这个llil进行

提升为Middle-level il

llil可以说是为了我们后续整个打好基础,而mlil让我们可以做一些基本操作,从而优化掉llil.
由于有llil的苦逼体力搬砖,我们mlil的操作将变成非常容易.实际上他就是合并一些LLIL指令

call合并

如你所见,在llil中我们是没有call的信息的(比如call的几个参数,几个变量被拿去call了).而在mlil里面,我们可以做到,如果是IAT,我们则直接标注符号,如果是未知的函数,我们直接取目标函数的信息,然后通过目标函数的参数数量,去推算出参数数量

当然这个call做得我不满意,原因是:

  1. 对于IAT来说,我们不应该猜测IAT的函数数量,而是直接找.h文件,因为我们怎么猜测都没.h文件的准,实际上ida,BN都是由这些定义符号的,但是,懒了

  2. 对于目标call来说,我们需要做第二次call参数修正,即调用栈参数修正,两个比对,才能正确的比对出参数,如您所见,我没做,因为懒了,这样会导致一个问题,memcall(比如ida里面常见的 v1(xxx,xxx,xxx) 变量call,我们拿不到参数.也会解析失败)但是你懂的,懒了.

jcc合并

这非常关键,因为我们的ifelse,dowhile都离不开jcc的合并识别,为了实现识别”if去哪”,我们需要

  1. 处理比较操作 (CMP, TEST)

  2. 检查这个COMPARE指令是否被后面的条件跳转使用

  3. 在当前块中查找下一个指令

这样我们才能知道”跳哪”

if (llil_ins->type == LLIL::LLILInstruction::COMPARE) {
                // 处理比较操作 (CMP, TEST)
                // 检查这个COMPARE指令是否被后面的条件跳转使用
                bool isUsedByCondJmp = false;
                // 在当前块中查找下一个指令
                auto currentBlock = llil_block;
                auto currentIt =
                    std::find(currentBlock->instructions.begin(),
                              currentBlock->instructions.end(), llil_ins);
                if (currentIt != currentBlock->instructions.end()) {
                    auto nextIt = std::next(currentIt);
                    if (nextIt != currentBlock->instructions.end()) {
                        auto nextIns = *nextIt;
                        if (nextIns->type == LLIL::LLILInstruction::COND_JUMP) {
                            // 检查条件跳转是否使用了这个COMPARE的结果
                            // 在x86架构中，CMP指令后紧跟的条件跳转通常会使用CMP设置的状态标志
                            isUsedByCondJmp = true;
                        }
                    }
                }
                if (isUsedByCondJmp) {
                    // 如果COMPARE被条件跳转使用，则标记为已优化，不显示
                    mlil_ins->type = MLILInstruction::kOptimized_already_ASSIGN;
                } else {
                    // 否则正常处理为ARITHMETIC操作
                    mlil_ins->type = MLILInstruction::ARITHMETIC;
                    mlil_ins->op = MLILInstruction::
                        SUB;  // 比较操作实际上是减法但不保存结果
                    for (auto& llil_op : llil_ins->operands) {
                        auto mlil_op = std::make_shared<MLILOperand>();
                        mlil_op->add_in_file = llil_op->add_in_file;
                        mlil_op->add_in_mem = llil_op->add_in_mem;
                        if (llil_op->type == LLIL::LLILOperand::MEMORY) {
                            int64_t targetOffset =
                                llil_op->base == "rsp"
                                    ? llil_op->offset
                                    : func->stackAdjustment - llil_op->offset;
                            if (func->funcVars.find(targetOffset) ==
                                func->funcVars.end()) {
                                if (llil_op->base == "rsp" ||
                                    llil_op->base == "rbp") {
                                    __debugbreak();
                                    continue;
                                }
                                // not a variable, must be registry base access
                                mlil_op->base_reg = llil_op->base;
                                {
                                    std::stringstream ss;
                                    ss << std::showbase << std::hex
                                       << llil_op->offset;
                                    mlil_op->base_index = ss.str();
                                }
                                mlil_op->type =
                                    MLILOperand::kREGISTER_BASE_ACCESS;
                            } else {
                                mlil_op->type = MLILOperand::kVar;
                                mlil_op->variableInfo =
                                    func->funcVars[targetOffset];
                            }
                        } else if (llil_op->type ==
                                   LLIL::LLILOperand::IMMEDIATE) {
                            mlil_op->type = MLILOperand::kIMMEDIATE;
                            mlil_op->value = llil_op->value;
                            mlil_op->size = llil_op->size;
                        } else if (llil_op->type ==
                                   LLIL::LLILOperand::REGISTER) {
                            mlil_op->type = MLILOperand::kREGISTER;
                            mlil_op->value = llil_op->value;
                            mlil_op->size = llil_op->size;
                        }
                        mlil_ins->operands.push_back(mlil_op);
                    }
                }
            }

结果

这是结果,可以看到,我们的MLIL跟BN的MLIL是几乎一模一样的,除了他做了一些美观优化:

实际上到MLIL,我们就可以直接把他用于网络安全的操作了(比如做NGAV)
下面的HLIL是给人看,而不是给机器脚本看的

提升了Hight-level il

经过MLIL的提升后,我们终于可以提升为hight-level的il了,他在MLIL的基础上,增加了编译器优化/友好的C风格,blocks识别去美化代码(比如把goto变成ifelse或者是do-while),这一块就比较复杂了
基本上,IDA/BN做到优秀代码可读大部分跟他这块的优化有关系

不要被混淆概念,IDA没HLIL这种概念

你可能注意到标题有上和下,因为这是上,我们就不继续介绍了,这块介绍能再写几万字,涉及到非常底层的编译器原理,这块涉及到的pass可以干非常非常多的事情,如去混淆,如识别golang的ABI重新编写输出函数从而避免被golang的垃圾代码搞坏大脑(部分函数参数识别要放在MLIL里面做),rust识别也同理,因为这块不属于抽象层的东西,属于最终给用户看的界面.说起来非常费劲.

最后给张成品效果图,如果这篇文章阅读量超过4000,我立刻更新下一章介绍这块.

实际上我最后也没搞完这块的优化,要做太费劲了.retdec项目取了个巧,给llvm做优化,但是很臃肿.

最后

非常感谢你的耐心收看,这可能是全网唯一一篇介绍反汇编工具的内部原理的,我希望你能学到一些什么.觉得看不懂也不要气馁,很多概念我也不懂,乱写能跑就行.

阅读原文

跳转微信打开

]]> Tue, 12 Aug 2025 09:30:00 +0800 VMP源码学习(1) 变异分析与代码bug https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485288&idx=1&sn=74c85fd0a3c61b7eb98415cb7128c40d VMP源码学习——变异分析背景：VMP在23年泄露了一份代码，尽管目前在github上代码已经大部分被删除，但 原创 CrazyHarb 2025-07-31 10:01 北京

VMP源码学习——变异分析

背景：

VMP在23年泄露了一份代码，尽管目前在github上代码已经大部分被删除，但也让我们有机会得以窥探一眼这款商业混淆软件的内部原理。目前，网上关于这份源码的分析“少之又少”（这句话怎么这么耳熟），所以笔者打算分享一下对该源码的分析，旨在抛砖引玉。

 

功能分析：

针对代码的混淆与加密，目前提供了三种功能即（变异、虚拟、变异+虚拟），代码中支持了变异、虚拟两种混淆功能，本文将从变异功能出发，抛砖引玉，深入VMP而出不来。

 

入口点：

C                  
void IntelFunction::Mutate(const CompileContext &ctx, bool for_virtualization)

 

垃圾代码初始化：

首先，会初始化一个垃圾指令的列表，这里的垃圾指令代表的是不会对后续的运行产生影响的指令，垃圾指令的存在只是为了扩大文件，加大逆向的时间成本，初始化逻辑中IntelCommand代表一条指令，例如

Assembly language                  
mov rax, 1

IntelOperand代表操作数，例如 rax rbx等，在这段初始化中，垃圾指令的列表共初始化了78条垃圾指令，列表如下：

Assembly language                  
mov rxx,rxx                  
mov rxx, value                  
movsx xx, xl/xh                  
movsx exx,xx                  
movsx rxx, xx                  
movsxd rxx, exx                  
movzxxx, xl/xh                  
movzxexx, xx                  
movzxrxx, xx                  
notrxx                  
negrxx                  
incrxx                  
decrxx                  
cmprxx, rxx                  
cmprxx, value                  
test rxx, rxx                  
test rxx, value                  
andrxx, rxx                  
andrxx, value                  
or   rxx, rxx                  
or   rxx, value                  
xorrxx, rxx                  
xorrxx, value                  
addrxx, rxx                  
addrxx, value                  
adcrxx, rxx                  
adcrxx, value                  
subrxx, rxx                  
subrxx, value                  
shlrxx, cl                  
shlrxx, byte of value                  
shrrxx, cl                  
shrrxx, byte of value                  
salrxx, cl                  
salrxx, byte of value                  
sarrxx, cl                  
sarrxx, byte of value                  
rolrxx, cl                  
rolrxx, byte of value                  
rorrxx, cl                  
rorrxx, byte of value                  
shrdrxx, cl                  
shrdrxx, byte of value                  
shldrxx, cl                  
shldrxx, byte of value                  
btrxx, rxx                  
btrxx, byte of value                  
btcrxx, rxx                  
btcrxx, byte of value                  
btrrxx, rxx                  
btrrxx, byte of value                  
btsrxx, rxx                  
btsrxx, rxx                  
setz/seto/setc/...                  
cmovc/cmova/cmovo/...                  
clc                  
stc                  
cmc                  
cbw                  
cwde                  
cwd                  
cdq                  
cdqe                  
cqo                  
lahf                  
bswap rxx                  
xchgrxx, rxx                  
xaddrxx, rxx                  
jmp   value                  
; 后面的指令是当for_virtualization == false（非虚拟化选项）的时候才会存在                  
sbb rxx, rxx                  
sbb rxx, value                  
rcl rxx, cl                  
rcl rxx, byte                  
rcr rxx, cl                  
rcr rxx, byte                  
bsr rxx, rxx                  
bsf rxx, rxx                  
rdtsc

上面的垃圾指令列表中包含了所有的垃圾指令，但没有体现出具体的随机长度，若有具体分析的必要，可以参考一下源码

 

指令的处理：

初始化完成垃圾代码列表后，变异逻辑将对汇编指令进行了逐条处理，我们先忽略掉“指令块”这些概念，只看指令的变异处理。实际上，所谓的变异功能，包含了以下几步逻辑处理，即：指令信息获取→获取空闲寄存器→指令替换→垃圾代码筛选→垃圾代码填充。我们分步来看一下：

 

1. 指令信息获取

此步骤将会调用IntelCommand::GetCommandInfo指令获取当前指令的信息，当然，这个函数中没有任何的奇淫巧计，全部都是暴力硬编码，例如 rdtsc及lahf中，代码中的实现为：

C                  
case cmRdtsc:                  
     command_info_list.Add(atWrite, regEAX, otRegistr, osDWord);                  
     command_info_list.Add(atWrite, regEDX, otRegistr, osDWord);                  
     break;                  
case cmLahf:                  
     command_info_list.Add(atRead, regEFX, otRegistr, size_);                  
     command_info_list.set_need_flags(fl_S | fl_Z | fl_A | fl_P | fl_C);                  
     command_info_list.Add(atWrite, regEAX, otHiPartRegistr, osByte);                  
     break;

可以看到：

①针对rdtsc指令，指令信息中指明了eax和edx将会被写入。

②针对lahf指令，标志位将会被读取，同时指明了sf、zf、af、pf、cf将会被读取，最后ah将会被写入。

 

以此类推，这个函数中包含了大部分的指令，其余的指令则返回获取失败。

 

2. 获取空闲寄存器

此步骤将会调用IntelFunction::GetFreeRegisters进行获取空闲寄存器，尽管代码量很少，但这块逻辑可能比较抽象，所以笔者结合流程图与简单的举个例子进行简单的分析，假设当前指令为如下:

C                  
sub rbx, rax                  
mov rax, rbx                  
cpuid                  
mov rdx, rcx                  
rdtsc                  
nop                  
jnz xxx

假设目前要对第一行指令做处理，我们需要获取空闲寄存器，代码将从第二行指令开始扫描，扫描动作为：获取指令信息→判断是写入还是读取。这个扫描动作直到遇到无法获取的指令信息或有修改RIP的指令为止（例如样例中的第7行）

 

先说结论：

1先写入的话，就代表是空闲寄存器，因为开始指令到当前扫描指令之间，这个寄存器无论如何更改，都会被后面的指令改写覆盖

1先读取的话，就代表是使用中的寄存器

 

我们再来看一下扫描流程：

1当前扫描第2行，由于rbx被修改了，rax被读取了，所以当前扫描结果为，空闲寄存器: rbx， 已使用寄存器: rax

1当前扫描第3行，rax尽管被修改了，但rax在已使用的寄存器中，所以不作为空闲寄存器，所以当前扫描结果为: 空闲寄存器 rbx、rcx、rdx，  已使用寄存器 rbx、rax

1当前扫描第4行，当前扫描结果为 空闲寄存器 rbx、rcx、rdx，  已使用寄存器 rbx、rax、rcx

1当前扫描第5行，当前扫描结果为 空闲寄存器 rbx、rcx、rdx，  已使用寄存器 rbx、rax、rcx

1当前扫描第6行，由于没扫到任何的寄存器变动，所以当前扫描结果不变 空闲寄存器 rbx、rcx、rdx，  已使用寄存器 rbx、rax、rcx

1当前扫描第7行，由于本行指令将改变RIP，所以直接退出扫描

 

针对以上，我们可以看到运行返回结果的空闲寄存器为：rbx rcx rdx，当然，空闲标志位也是通过上面的逻辑进行获取的，流程图如下，这里就不再展开了

 

3. 指令替换

该步骤，将会对特定的指令规则进行平行替换结果不变，规则如下表展示：

C                  
xor rxx, rxx（rxx相同）  ->  sub rxx,rxx                  
add rxx, rxx1  ->   lea rxx, [rxx + reg1]                  
add rxx, value ->   lea rxx, [rxx + value]                  
sub rxx, value ->   lea rxx, [rxx - value]                  
jmp [value]   ->    push [value]                  
                    ret                  
jmp rxx       ->    push rxx                  
                    ret                  
jmp [rxx]     ->    push [rxx]                  
                    ret

当然替换也并不是每次都会发生，仅会在本条指令处理时，(rand() & 1)不为0的情况下，才会匹配规则，并进行替换。

且针对add与sub，会进行标志位逻辑判断，即：当前指令修改的标志位寄存器在空闲标志位寄存器中时（也就是说，当前更改的标志位不会影响后续代码执行结果），才会进行指令替换。

 

4. 垃圾代码筛选

前面我们已经获取到了空闲寄存器（包含空闲标志位寄存器），也初始化垃圾指令的列表，本节中将会对已有的垃圾指令列表进行筛选。

①获取当前指令信息，可以参考第1步骤，这里就直接跳过了。

②循环判断操作数：

1) 如果是读取则放过

2) 如果是写入，则判断是否是立即数，如果是也放过

3) 如果是寄存器或高位寄存器，则进一步判断寄存器类型

4) 如果是需要空闲寄存器，则从空闲寄存器列表中找一个，如果空闲寄存器列表为空，则筛选掉当前垃圾指令，如果所有空闲寄存器的长度都小于需要的大小，也筛选掉垃圾指令。

5) 如果是需要空闲标志位寄存器，则查看空闲标志寄存器，如果空闲标志位寄存器列表为空，则筛选掉当前垃圾指令。

6) 如果是高位寄存器，则按照长度2倍对齐，例如 ah/al -> ax

 

针对4）、5）我们举个例子，例如 sub rax, rbx ，那么我们获取到的四条操作信息：标志位：OSZAPC -> 更改、rbx -> 读取、 rax -> 读取、 rax -> 更改。然后会判断所有的操作信息，由于rbx仅有读取，所以直接跳过。会判断一下空闲标志位寄存器中是否存在OSZAPC标志位，判断一下空闲寄存器是否存在rax，如果都符合要求，证明当前的垃圾指令符合要求，放入筛选后的列表中。

 

5. 垃圾代码填充

经过上面的筛选及指令替换，我们到了最后一步，开始垃圾代码填充，可以放一首比较好听的bgm，完成最后的一部分，要想放的歌曲好听，好的手机必不可少，我新换的手机，旧的手机我放在...

① 首先，代码中会随机添加的垃圾指令的数量 n ( 0~4)，然后开始指令预处理阶段

C                  
rand() % 4

② 在筛选后的列表中随机一条指令，并将其从筛选后的列表中删掉，也就是针对一条指令的垃圾填充，不会重复使用相同的垃圾指令。

③ 遍历选取的垃圾指令的操作数，如果是空闲寄存器，就随机一个寄存器（空闲寄存器可以重复使用）并获取当前随机出来的寄存器长度,如果当前记录的最大长度大于随机出来的长度，就把当前记录的最大长度改为随机出来的长度

④ 记录所有操作数中最大的寄存器序号，这里如果当前操作数是指明了寄存器，且是rax，代码中会根据位数随机一个寄存器(rax ~ rbp 或 rax ~ r15)

⑤ 如果当前是32位程序，且寄存器不是 rax rdx rcx rbx，并且最小长度小于2字节，则将最小长度置为2字节

⑥ 如果最小长度大于最大长度，则执行失败，进行下一条垃圾指令填充，如果长度非随机，且当前垃圾指令长度小于最小长度或者当前指令长度大于最大长度，也算作执行失败

      ⑦ 上面预处理完成后，开始随机填入操作数的各种信息：

1）如果长度需要随机，则根据最大长度、最小长度随机一个长度。

2）如果操作数是寄存器，则填入上面随机出来的寄存器，且如果长度是1字节，垃圾指令的需求寄存器是空闲寄存器或者rax，最大长度大于1字节，且最大寄存器序号小于4（rax rdx rbx rcx)，且随机一个数为奇数，则使用高位寄存器代替   即 mov al, bl  -> mov ah, bl

3)  如果是立即数，则随机一个数即可

4）如果是setx/cmovx 等指令，则随机一个标志位使用，随机一个数，如果是奇数，则取setnx/cmovnx指令。

⑧ 循环下一条垃圾指令填充，垃圾指令填充完成后，循环下一条指令处理

 

代码中的bug：

1. 垃圾指令的重复

根据垃圾指令列表可以得知，52行和53行的垃圾指令是相同的，根据之前的代码推测，有一个应该是 

C                  
bts rxx, value

笔者想了一下应该不会有什么坑，猜测应该是写错了

2. 获取空闲标志位错误

根据流程图可以得知空闲标志位寄存器会在第一次获取成功后停止获取，也就是说，如果指令列表中，第一行指令改变了Z，第二行改变了C，理论上返回的空闲标志位为ZC，但由于获取成功一次后就停止获取了，所以实际返回的空闲指令寄存器是Z，也就是说有可能会影响部分垃圾指令的生成。

阅读原文

跳转微信打开

]]> Thu, 31 Jul 2025 10:01:00 +0800