WSL Kali换源、binwalk固件解包与outguess隐写实战

在 Windows 上把 Kali 跑进 WSL再用它做固件解包和 JPEG 隐写分析这套组合我用了挺长时间说实话比开虚拟机省事太多——不用切桌面、文件系统互通、VS Code 一点就能连进去写脚本。但新手最容易卡住的地方往往不是工具本身而是第一步源没换apt update慢到怀疑网线换源换错了文件改了半天没生效好不容易装上 binwalk一到提取环节全是报错想装 outguessapt install直接告诉你找不到包。这篇就把这几件事从头到尾捋一遍——WSL 下的 Kali 换源、binwalk 的安装与实战解包、outguess 的编译与隐写提取每一步都说清楚为什么这么做、这么做的坑在哪。适合刚接触 WSL 和 Kali 的同学也适合已经装了但一直没配顺的老哥对照排查。1. 整体环境搭建思路与方案取舍1.1 为什么用 WSL 跑 Kali 而不是开虚拟机先把这件事说明白不然后面一堆操作你会觉得我图什么。虚拟机方案VMware、VirtualBox跑 Kali 的优势是完整、隔离、能跑图形界面、能做网络实验。但代价也明显硬盘要划出几十 G内存至少分 4G开机要等一分钟宿主机和虚拟机之间传文件要么装增强工具要么走共享目录。如果只是跑一条命令、解一个固件、提取一段隐写数据为这点活儿开一整套虚拟机性价比太低了。WSL 的逻辑完全不一样。它不是模拟硬件而是在 Windows 内核上做了一层系统调用翻译让 Linux 的可执行文件直接跑在 Windows 上WSL1或者跑在一个轻量级虚拟化环境里WSL2。带来的直接好处是启动快基本是秒开wsl敲下去就进去了文件互通Windows 的盘挂在/mnt/c、/mnt/dLinux 的文件在资源管理器里输入\\wsl$就能看到剪贴板共用Linux 里选中复制Windows 里直接粘VS Code 直连装个 Remote - WSL 扩展直接在 WSL 文件系统里开项目终端、调试、Git 全在 Linux 侧跑编辑器界面还是 Windows 的这个体验确实接近原生。那我为什么选 Kali 而不是 Ubuntu因为 Kali 预装了一大批信息安全方向的工具链metasploit、nmap、wireshark、john 这些开箱就有省得一个个装。而且 Kali 是滚动发行版工具版本比较新。binwalk、outguess 这类工具在 Kali 的软件源里覆盖度也比 Ubuntu 好一些。注意WSL 上跑 Kali 只适合命令行场景。Kali 的图形桌面在 WSL 下虽然能用 WSLg 跑起来但体验一般真要做图形化实验还是虚拟机或者独立系统更合适。这篇文章讨论的全部是命令行范畴。1.2 WSL 环境的前置检查与版本升级动手之前先确认三件事能省掉后面很多莫名其妙的错误。第一确认 WSL 本体版本。打开 PowerShellwsl --version如果提示wsl: 无法识别的选项或者类似你的 WSL 版本过旧的提示说明你用的是 Windows 自带的旧版组件需要先升级wsl --update升级完之后再wsl --version应该能看到 WSL 版本号2.x 开头、内核版本、WSLg 版本这些信息。这一步别跳过老版本 WSL 在网络栈和文件系统上有不少已知问题后面apt卡住、DNS 解析失败十有八九跟它有关。第二确认要装的发行版。列出可安装的清单wsl --list --online找到kali-linux那一行然后wsl --install -d kali-linux这个命令会自动下载、注册发行版并提示你创建 UNIX 用户名和密码。注意这里的密码是 sudo 密码输入时不显示是正常的别以为键盘坏了。第三装完之后验证一下版本wsl --list --verboseSTATE是 RunningVERSION是 2就对了。如果是 1用wsl --set-version kali-linux 2转过来。WSL2 用的是真正的 Linux 内核binwalk 里那些依赖内核特性的操作比如挂载 loop 设备、处理特殊文件系统镜像在 WSL2 下成功率明显更高所以强烈建议用 2。1.3 换源这件事到底解决什么问题很多人对换源的理解停留在下载速度快一点其实不止。Kali 默认源指向的是海外的主仓库在国内环境下有两个典型症状一是apt update拉索引的时候慢几十兆的 Packages 文件要跑很久二是apt install下载 deb 包时经常中途断流尤其是 binwalk 那种带一大堆依赖的包装到一半失败然后用apt --fix-broken install反复补救非常折磨。换成国内镜像源之后索引拉取基本能在十几秒内完成包下载速度能跑满带宽。这中间的原理是镜像站会定期同步上游仓库你访问的是国内的 CDN 节点省掉了跨国链路的不确定性。这里有个很多人不知道的点镜像站不是实时的。国内镜像通常每几小时同步一次上游。如果你要装的包刚好是上游刚更新、镜像还没同步的版本可能会遇到索引里有但文件不存在的 404。遇到这种情况隔几小时再试或者临时切回官方源装完再切回来。提示换源只影响apt这条线。pip、conda、npm这些各有各的配置后面第 2.4 节会单独说。2. Kali 换源的核心操作与细节拆解2.1 先搞清楚你的 Kali 用的是哪种源文件格式这是最容易翻车的一步。很多人照着几年前的教程改/etc/apt/sources.list改完apt update发现还是走原来的源一脸茫然。原因在于 Kali 从 2024 年之后的版本开始逐步把软件源配置迁移到了 deb822 格式文件位置在/etc/apt/sources.list.d/kali.sources而老的/etc/apt/sources.list里可能只剩一行注释甚至完全为空。你改了一个空文件当然没效果。所以第一步永远是先看现状ls -l /etc/apt/sources.list /etc/apt/sources.list.d/ cat /etc/os-release | head -n 5/etc/os-release的输出里会显示PRETTY_NAMEKali GNU/Linux Rolling之类确认你的系统代号。Kali 是滚动发行版代号固定就是kali-rolling不像 Ubuntu 有 jammy、noble 这种版本代号。这一点也容易搞错——有人把 Ubuntu 的换源配置直接复制到 Kali 上那必然是不通的。看清楚/etc/apt/sources.list.d/下面有没有kali.sources文件。有就改它没有才去改sources.list。2.2 两种格式的源配置写法传统 one-line 格式写在/etc/apt/sources.listdeb https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware这行的结构是deb表示二进制包仓库中间是镜像地址然后是套件名kali-rolling最后是组件列表。main是官方自由软件contrib是依赖非自由组件的自由软件non-free和non-free-firmware是非自由软件与固件。少写组件会导致部分包搜不到所以通常四个都带上。deb822 格式写在/etc/apt/sources.list.d/kali.sourcesTypes: deb URIs: https://mirrors.tuna.tsinghua.edu.cn/kali Suites: kali-rolling Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg这个格式看着啰嗦但信息更明确而且Signed-By字段直接指定了验签用的密钥环路径避免了老格式下密钥找不到的一类问题。如果你系统里已经是这个文件直接覆盖内容就行别再去动sources.list。我常用的几个国内镜像地址列出来方便你挑镜像站地址特点清华大学 TUNAhttps://mirrors.tuna.tsinghua.edu.cn/kali同步频率高覆盖面全中科大 USTChttps://mirrors.ustc.edu.cn/kali稳定性好历史久阿里云https://mirrors.aliyun.com/kaliCDN 节点多南方访问快南京大学https://mirrors.nju.edu.cn/kali教育网内速度快不确定哪个快就分别curl -o /dev/null -s -w %{time_total}\n 地址/dists/kali-rolling/Release测一下响应时间哪个快用哪个。这一步花两分钟能省后面几个小时的等待。2.3 备份、写入与生效验证改配置之前必须备份这是我踩过坑之后的肌肉记忆。改错了至少能退回去sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date %F) sudo cp /etc/apt/sources.list.d/kali.sources /etc/apt/sources.list.d/kali.sources.bak.$(date %F) 2/dev/null带日期后缀是为了多次修改时不互相覆盖。别小看这个习惯我有一次手滑把kali-rolling写成了kali-rolling多一个空格apt update直接报错说找不到套件排查了半小时才发现是尾随空格。写入用tee比vim更稳尤其在 WSL 里粘贴长文本时vim的自动缩进偶尔会把配置搞乱sudo tee /etc/apt/sources.list.d/kali.sources /dev/null EOF Types: deb URIs: https://mirrors.tuna.tsinghua.edu.cn/kali Suites: kali-rolling Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg EOF这里的EOF加单引号很重要它表示不做变量展开。如果不加引号配置里如果有$符号会被 shell 吃掉。虽然这个配置里没有但养成习惯没坏处。写完之后刷新索引sudo apt update正常的话你会看到Get:1 https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling InRelease速度应该是几 MB/s 起步。如果还是显示http.kali.org说明你改的文件不是系统实际读取的那个回去看 2.1 节重新确认。索引刷新成功后升级一次sudo apt full-upgrade -y为什么用full-upgrade而不是upgrade因为 Kali 是滚动发行版包之间依赖关系变动频繁upgrade遇到需要卸载旧包才能满足依赖的情况会直接跳过导致系统长期处于半新半旧的状态。full-upgrade允许为了满足依赖而增删包更适合滚动发行版。2.4 pip、conda、npm 的换源配置Kali 里跑 Python 脚本是家常便饭binwalk 的很多辅助脚本、CTF 里的一堆工具都依赖 pip。如果 pip 没换源装个包能等到花儿都谢了。pip 换源推荐用配置文件方式一次配置长期生效mkdir -p ~/.config/pip cat ~/.config/pip/pip.conf EOF [global] index-url https://pypi.tuna.tsinghua.edu.cn/simple extra-index-url https://mirrors.aliyun.com/pypi/simple/ trusted-host pypi.tuna.tsinghua.edu.cn mirrors.aliyun.com timeout 60 EOFextra-index-url是备用源主源上没有的包会自动去备用源找这个配置能显著减少Package not found的情况。不用-i参数是因为临时参数每次都得敲而且有些工具内部调用 pip 时带不上你的参数。如果装了 conda比如 Miniconda配置在~/.condarcchannels: - defaults default_channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r custom_channels: conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud show_channel_urls: trueshow_channel_urls: true建议打开装包的时候能看到具体从哪个镜像拉的出问题好定位。npm 换源一行搞定npm config set registry https://registry.npmmirror.com验证配置有没有生效pip config list npm config get registry实操心得pip 换源之后偶尔会遇到 SSL 证书校验失败报SSLError: certificate verify failed。这种情况多半是 WSL 系统时间漂移导致的。WSL2 休眠唤醒后虚拟机时钟有时会和宿主机差出几分钟HTTPS 握手时证书会判定为未生效或已过期。解决办法是先同步时间再重试后面第 5 章会详细说。3. binwalk 的安装选择与固件解包实战3.1 apt 装还是源码装两条路线怎么选binwalk 有两个大版本线选错了会走不少弯路这里先把区别说清楚。Python 版2.x 系列也就是过去十来年大家最熟悉的那个版本。它的工作方式是靠一个庞大的 magic 签名库扫文件头识别出里面嵌套了什么格式然后调用外部工具去提取。优点是签名库成熟、对老式固件支持好、网上教程全是基于它的。缺点是它自己不会提取必须依赖一堆外部程序sasquatch、7z、cabextract 等等少装一个就报Extractor Exception。Rust 版3.x 系列是重写版本。核心扫描引擎换了速度提升明显而且提取能力内置了一部分对外部工具的依赖大幅减少。缺点是发布还比较新签名库不如 2.x 全一些冷门格式可能识别不出来而且参数和输出格式跟老教程对不上。我的建议是两个都装互不冲突。名字分别可以用binwalk和binwalk3区分或者按需切换 PATH。日常扫固件用 2.x 打底遇到 2.x 卡住的大文件用 3.x 提速。先装 Python 版sudo apt update sudo apt install -y binwalkKali 源里的 binwalk 包已经带了一部分依赖但提取工具链还得自己补sudo apt install -y \ python3-pip python3-setuptools git \ p7zip-full cabextract unzip tar gzip bzip2 xz-utils zstd \ mtd-utils squashfs-tools sleuthkit lzop lz4 \ file binutils cpio这一串看着长但每一个都对应一类提取场景squashfs-tools处理路由固件最常见的 squashfs 根文件系统p7zip-full处理各种 zip/7z 封装cabextract处理微软的 cab 格式mtd-utils处理嵌入式 flash 镜像sleuthkit处理磁盘镜像。装的时候会下载几十兆换过源之后应该很快。sasquatch要单独说一下。它是 squashfs 的魔改版本专门用来处理那些被厂商改过压缩算法或者加了非标准头的 squashfs 镜像标准unsquashfs遇到这类镜像会直接失败。Kali 源里不一定有如果没有可以自己编译sudo apt install -y build-essential zlib1g-dev liblzma-dev liblzo2-dev libzstd-dev git clone https://github.com/devttys0/sasquatch.git cd sasquatch ./build.sh编译过程中如果报LZMA相关的错误把patches/patch.sh里对应那行注释掉再试。这个工具的补丁脚本对新版内核头文件有点兼容问题属于正常现象。再装 Rust 版sudo apt install -y build-essential curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y source $HOME/.cargo/env cargo install binwalkcargo install会从源码编译视机器性能大概几分钟到十几分钟。装完在~/.cargo/bin/binwalk。如果你不想装 Rust 工具链也可以去 release 页面下预编译的二进制解压后丢到/usr/local/bin就行更省事。不过要注意版本迭代快写这篇文章的时候最新稳定版和半年前的参数已经有差异了具体以binwalk --help为准。3.2 扫描阶段的常用参数与输出解读工具装好了先拿个固件试试手。假设你有个firmware.bin。最基础的扫描binwalk firmware.bin输出是一个表四列DECIMAL十进制偏移、HEXADECIMAL十六进制偏移、DESCRIPTION识别出的格式。看这个表有个技巧关注偏移量是不是连续递增。如果第一个条目是0x0 - 0x400000区间的某个文件系统第二个条目紧接着从0x400000开始说明这是一个完整的分区布局如果偏移跳得很乱可能是加密固件或者是有校验头。只看特定类型用-y过滤binwalk -y squashfs -y jffs2 -y cramfs firmware.bin只看 CPU 架构相关的段用-Abinwalk -A firmware.bin这个参数会扫描可执行代码特征不同架构的指令编码模式输出里面哪些段是 MIPS、哪些是 ARM、哪些是 x86。这个信息在做漏洞分析的时候特别有用——知道哪些段是可执行的才知道该往哪儿看。粗粒度扫描大文件时可以用-B跳过熵值低的区域比如全 0 的填充区速度能快好几倍binwalk -B firmware.bin3.3 提取阶段的参数组合与详解扫描只是看提取才是干活。核心参数是-ebinwalk -e firmware.bin它会自动把识别到的每个文件系统/压缩包解出来放在_firmware.bin.extracted/目录下子目录按十六进制偏移命名。三个我几乎每次都会加的参数binwalk -e -M -d 3 -C /tmp/fw_out firmware.bin-M递归扫描。提取出来的东西再扫一遍因为固件里经常是squashfs 里套 cpiocpio 里套 gzip这种多层嵌套。不加这个参数你只拿到最外层。-d 3限制递归深度为 3 层。不加的话默认递归 8 层遇到自相似的文件结构会无限往下套生成一堆垃圾目录把你的磁盘塞满。3 层覆盖绝大多数真实固件。-C /tmp/fw_out指定输出目录到/tmp。为什么不在当前目录跑因为 WSL 的 Linux 文件系统/home和 Windows 挂载盘/mnt/c在性能上差很多。在/mnt/c下做大量小文件读写速度能慢十倍以上。所以解包这类会产生成百上千个小文件的操作一定放在 Linux 文件系统里做。还有一个参数--run-asroot要慎用。有些固件里的文件带特殊权限位普通用户解不出来加上这个能解决。但它是让你以 root 身份执行解包工具链而解包工具链是直接处理不可信数据的从安全角度这是有风险的。真要加建议在容器或者专门的测试环境里做别在日常用的 WSL 里开。如果某次提取失败了先用-v打开详细日志看看到底卡在哪binwalk -e -v firmware.bin 21 | tail -n 50日志里通常会明确告诉你缺哪个工具比如sasquatch not found或者unsquashfs: unsupported compression。前者装工具就行后者说明是魔改压缩算法得用 sasquatch 换掉标准 unsquashfsbinwalk -e --preserve-symlinks -D squashfs:sasquatch -d %e %f firmware.bin-D是自定义提取规则格式是类型:命令%e是输出目录占位符%f是输入文件占位符。这个参数很灵活厂商用了奇葩格式的时候自己写条规则比等 binwalk 更新签名库快得多。注意事项解包出来的根文件系统里经常有指向/dev、/proc的符号链接如果不在隔离环境里某些脚本可能会顺着链接影响到宿主机。养成习惯——解包目录只读查看不要在解包出来的目录里直接执行任何脚本。要分析二进制用file、readelf、strings这些静态工具看。4. outguess 编译安装与 JPEG 隐写操作4.1 为什么 apt 源里经常找不到 outguessapt install outguess报Unable to locate package是常态。原因有两个。一是 outguess 的上游项目维护已经不太活跃了最后一个正式版本是 0.2 时代的 0.2.2 和后来的 0.4Debian 系因为维护成本问题在某个时间点把它从主仓库移到了非官方源Kali 作为下游自然也就跟着没了。二是 outguess 依赖比较老的 libjpeg 接口新版 libjpeg-turbo 的 ABI 变化导致老包编译不过维护者不愿意为一个小众工具长期打补丁。所以实际做法就是源码编译。好在它依赖极少编译本身不难。先确认有没有apt search outguess apt-cache policy outguess真没有就开始编译。装依赖sudo apt install -y build-essential autoconf automake libtool pkg-config libjpeg-devlibjpeg-dev是关键outguess 整