WSL 里跑 Kali第一件绕不过去的事就是换源。我见过太多人包括几年前的我自己装完kali-linux这个发行版兴冲冲敲下apt update然后盯着0% [Connecting to http.kali.org]发呆十分钟最后气得直接关窗口。等你后面想装binwalk拆固件、装outguess提隐写数据的时候会发现每一个工具的安装都卡在这同一道坎上——源不通后面全白搭。这篇东西不打算讲复制这三行粘贴进去这种一锤子买卖。我想把整个链路讲清楚WSL 的网络栈和 Kali 的滚动更新机制各有什么脾气换源到底动的是哪个文件新版 Kali 这里有个很容易踩的坑binwalk 的 v2 和 v3 命令为什么长得不一样以及 outguess 这种东西为什么要自己编译还有为什么你用 binwalk 扫半天都扫不出 outguess 藏的那点东西。适合刚在 Windows 上装好 WSL 和 Kali、准备做固件分析或 CTF 类隐写题的人也适合用了一段时间但一直没搞明白为什么换完源还是报错的人。1. WSL 里的 Kali 为什么一上来就必须换源1.1 Kali rolling 的更新节奏决定了默认源很难受Kali 只有一个主分支叫kali-rolling它不是像 Ubuntu 那种半年发一版的模式而是持续滚动更新。这意味着你apt update拿到的索引文件变化非常频繁官方源http.kali.org又是一个全球负载均衡的入口国内访问基本靠运气。更关键的是Kali 的软件包数量比 Ubuntu 少但更新频率高得多一次apt full-upgrade下来可能拉几百个包不用国内镜像基本没法用。这里要区分两件事apt update只是拉索引几百 KB 到几 MBapt upgrade才是真正下包。很多人失败在第 2 步却误以为是源写错了其实只是带宽。我的经验是换国内镜像之后索引更新时间从几分钟压到几秒包下载速度差一个数量级。1.2 WSL 的网络不是Windows 的网络这是很多玄学问题的根源WSL2 跑的是一台轻量虚拟机默认走 NAT 网络。这带来两个后果第一DNS 解析走的是 Windows 的 DNS 配置转发如果 Windows 侧改过 DNS 或者用了某些网络环境WSL 里的/etc/resolv.conf可能会指向一个不通的地址第二虚拟机的时钟偶尔会漂移尤其是 Windows 睡眠唤醒之后。时钟漂移这件事必须单独讲因为它伪装得特别好。报错长这样E: Release file for http://mirrors.xxx/kali/dists/kali-rolling/InRelease is not valid yet (invalid for another 3h 12min 5s). Updates for this repository will not be applied.看到not valid yet而不是404或签名错误八成不是源的问题是系统时间比真实时间慢了。解决方法按优先级先wsl --shutdown在 PowerShell 里执行再重新进WSL 重启时会跟主机同步时间如果还不行用sudo date -s 2026-01-15 10:30:00手动拨过来装ntp之后sudo ntpd -qg也可以。我第一次遇到这个报错的时候傻乎乎换了好几个镜像最后才发现是时间的事儿。1.3 换源之前先认清你要改的到底是不是 sources.list这是新版 Kali 最容易踩的坑。Kali 在 2024 年前后开始切到 Debian 的 deb822 格式包源配置的默认位置变成了/etc/apt/sources.list.d/kali.sources而/etc/apt/sources.list里只剩下一堆注释掉的说明文字。很多网上的老教程还在教你往sources.list里追加三行deb http://... kali-rolling main contrib non-free你照着做了然后发现要么新写的源和kali.sources里的官方源同时生效apt update出 warning说是同一个 target 被配置了多次要么更糟重复配置导致包版本混乱apt full-upgrade拉了一半失败。所以动手之前先看清楚ls -l /etc/apt/sources.list.d/ cat /etc/apt/sources.list看到kali.sources就以它为唯一入口把sources.list里的有效行全部注释掉。这不是洁癖是避免两个源打架这种很难排查的问题。下面第 3 节我会给出两种格式的完整写法。2. 从零把 Kali 请进 WSL2安装环节的几个关键决定2.1 版本选择、内核与 wsl --install 实际做了什么Windows 10 2004 以上和 Windows 11 都支持一条命令装好wsl --list --online wsl --install -d kali-linux wsl --set-default-version 2第一条列出所有可装发行版第二条装 Kali第三条把默认版本锁死成 WSL2。这一步建议一定确认是 2 而不是 1因为 WSL1 是系统调用翻译层很多依赖内核特性的工具尤其是涉及网络抓包、文件系统操作、需要 systemd 的在 WSL1 下会以各种莫名其妙的方式失败。wsl --install慢是老问题了它要去微软的服务器拉发行版镜像时间不固定。如果实在拉不动有个替代路径先在启用或关闭 Windows 功能里手动勾选适用于 Linux 的 Windows 子系统和虚拟机平台重启然后去拿离线的发行版包通过wsl --import导入wsl --import kali-linux D:\wsl\kali D:\download\kali-rootfs.tar --version 2--import这个操作后面还有别的用处——比如你想给做好的环境留个备份wsl --export kali-linux D:\wsl\kali-backup.tar一行就够了。我做固件分析之前习惯先 export 一份因为往系统里装各种编译依赖之后环境很容易被搞脏。2.2 首次启动之后必须处理的三件事第一次进 Kali会让你设置 UNIX 用户名和密码默认建出来的普通用户不是 root。装完之后我一般按这个顺序处理第一确认能提权sudo -i能进 root 就行后续所有装包操作我倾向用sudo前缀而不是直接切 root避免权限混乱。第二开 systemd。新版 WSL 已经支持 systemd但需要显式开启# /etc/wsl.conf [boot] systemdtrue [automount] options metadata,umask22,fmask11 [network] generateResolvConf true改完必须wsl --shutdown才生效。开 systemd 的意义在于你后面用apt install postgresql、docker这类带服务的东西时systemctl start才能用否则只能靠service xxx start而且有些包的后置脚本会因为找不到 systemd 直接报错。顺便说一句metadata这个挂载选项决定了/mnt/c下面的文件能不能保存 Linux 权限位做取证相关工作时经常需要早点加上省事。第三确认磁盘位置。默认wsl --install装出来的发行版在C:\Users\你的用户名\AppData\Local\Packages\...下面如果你 C 盘比较紧张或者要处理几十 GB 的固件包尽早用 export/import 的方式挪到 D 盘。2.3 两个配置文件的分工别搞混.wslconfig和/etc/wsl.conf是完全不同的东西我见过有人把内存限制写到/etc/wsl.conf里然后奇怪为什么不生效。文件位置作用范围典型用途.wslconfigWindows 侧C:\Users\用户名\所有 WSL 发行版限制内存、CPU 核数、交换分区wsl.conf发行版内/etc/单个发行版开 systemd、挂载选项、DNS 行为内存这件事值得强调。WSL2 默认最多能吃到主机 50% 的内存跑 binwalk 递归提取大固件的时候很容易把内存吃满然后整个 Windows 开始卡。我会在.wslconfig里写死上限[wsl2] memory8GB processors4 swap4GB3. 换源实操从备份到 apt update 跑通的完整链路3.1 备份、查看、再动手任何改配置文件的操作先备份是肌肉记忆sudo cp /etc/apt/sources.list.d/kali.sources /etc/apt/sources.list.d/kali.sources.bak sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak然后确认你现在用的是哪套格式grep -v ^# /etc/apt/sources.list ls /etc/apt/sources.list.d/如果sources.list里没有有效行全是注释就说明你在用 deb822 格式去改kali.sources。3.2 国内镜像怎么选几个常用镜像的实际差别镜像地址特点我的使用感受清华 TUNAhttps://mirrors.tuna.tsinghua.edu.cn/kali同步频率高文档全综合最稳出问题最少中科大 USTChttps://mirrors.ustc.edu.cn/kali教育网内速度快校园网环境首选阿里云https://mirrors.aliyun.com/kali公网覆盖面广家里宽带表现好华为云https://mirrors.huaweicloud.com/kali部分地区延迟低备用官方http://http.kali.org/kali最新但慢只在验证镜像问题时用选的时候注意一点Kali rolling 更新频繁镜像同步有延迟某些小镜像可能落后半天到一天。如果apt update报某个包404先别怀疑自己的配置换成 TUNA 大概率就好了。3.3 deb822 格式和传统单行格式的两种写法deb822 格式推荐改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传统单行格式写进sources.list前提是把kali.sources里的源注释掉deb https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware两种格式里Signed-By那一行千万别漏。Kali 从某个版本开始把 GPG 校验的 keyring 从trusted.gpg.d挪到了/usr/share/keyrings/kali-archive-keyring.gpg如果你照抄了很老的教程、只写了一行deb很容易遇到W: GPG error: ... The following signatures couldnt be verified because the public key is not available遇到这个先检查 keyring 文件在不在在的话就是 deb822 里缺Signed-By或者传统格式里缺[signed-by...]这一节deb [signed-by/usr/share/keyrings/kali-archive-keyring.gpg] https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware3.4 换完之后的验证流程和三类高频报错改完执行sudo apt update sudo apt full-upgrade -y注意 Kali 是滚动发行版日常更新应该用full-upgrade而不是upgrade因为 rolling 分支里包依赖关系变化频繁upgrade遇到需要卸载旧包来满足依赖的情况会直接放弃升级留着半新半旧的环境后面装工具时依赖地狱会更严重。报错排查按这个顺序走报错关键词真实原因处理方式not valid yet系统时钟漂移wsl --shutdown重启或手动date -sCould not resolveDNS 不通检查/etc/resolv.conf必要时换成8.8.8.8之类的公共 DNS404 Not Found镜像同步滞后换 TUNA或等几小时Configured multiple times新旧配置重复注释掉kali.sources或sources.list其中一份GPG errorkeyring 路径或写法问题补Signed-By还有一类特别隐蔽的apt update一切正常但装某个包时报Unable to locate package。这通常不是源的问题是apt的索引没刷新干净sudo apt clean sudo apt update一次即可。4. 顺手把 pip、conda、npm 的源一起收拾了4.1 为什么装完 binwalk 还得管这些binwalk的 v2 是 Python 写的pip装依赖时如果还走默认的 PyPI在国内一样是龟速。更别说做固件分析经常要顺手跑个 Python 脚本解析文件头、做熵值统计环境里迟早会用到 pip。而 conda 和 npm 是很多人在 WSL 里同时装着的一次配好以后省心。4.2 三个配置各自写在哪pip 全局配置pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip config set global.trusted-host pypi.tuna.tsinghua.edu.cn注意 Kali 新版对系统级 pip 安装有限制PEP 668直接pip install会报externally-managed-environment。绕开的正确姿势是用虚拟环境或者pipx而不是加--break-system-packages。pipx是我装binwalk这类命令行工具的首选它给每个工具独立建虚拟环境不会污染系统 Pythonsudo apt install -y pipx pipx ensurepath pipx install binwalkconda 的源写在~/.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: truenpm 一行搞定npm config set registry https://registry.npmmirror.com npm config get registry # 验证4.3 换源的代价什么时候你会想换回去镜像站不是实时的。PyPI 的 TUNA 镜像同步延迟通常在几分钟内问题不大但 conda 的镜像有时候会落后版本出现某个包在官方源有、镜像里是旧版的情况。我的做法是日常装常规包用镜像遇到版本对不上时临时加-i https://pypi.org/simple单次覆盖而不是把全局配置改回去。同理pip config unset global.index-url可以在需要时清掉配置。5. binwalk 的安装分岔路v2 和 v3 命令根本不是一回事5.1 v2apt 装最省事但要补齐外部解包器Kali 仓库里自带binwalk包装起来一步到位sudo apt install -y binwalk但装完你会发现识别功能正常-e提取却经常半途而废。原因是 binwalk 本身不做解包它只做三件事扫描文件里符合特征的偏移、给你算熵值、然后调用外部工具7z、unsquashfs、tar、gzip等去解。缺哪个外部工具对应格式就提不出来。所以我会一次性把常用解包器装全sudo apt install -y p7zip-full squashfs-tools mtd-utils gzip bzip2 tar cpio lzop zstd xz-utilsjffs2 镜像要用mtd-utils里的jefferson这个需要单独 pip 装非标准 squashfs 要用sasquatch得自己编译。这两个在嵌入式固件里出现频率很高看到了别慌是环境问题不是配置文件问题。另一个 v2 的坑以 root 身份跑提取时新版会提示需要显式加参数sudo binwalk -e --run-asroot firmware.bin不加这个扫描结果照常输出但提取阶段会静默跳过你以为命令跑完了一看输出目录是空的。5.2 v3Rust 重写之后参数表得重新对着看binwalk v3 是 Rust 重写的版本速度提升非常明显大文件扫描快了一个量级但命令行参数和 v2 有差异。我整理了一份对照表具体以你本机binwalk --help为准用途v2 写法v3 写法大致对应基础扫描binwalk filebinwalk file提取binwalk -e filebinwalk -e file递归提取binwalk -Me filebinwalk -Me file熵值分析binwalk -E filebinwalk -E file反汇编扫描binwalk -A filebinwalk -A file手动按偏移 dumpbinwalk -D png:png file用-D/--dd看着差不多但输出风格和内部签名库都变了v3 默认的输出更精简v2 那种长长的签名表在 v3 里格式不同。我建议是如果只是做常规固件提取v2 够用而且资料多如果要批量扫大镜像、对速度有要求再上 v3。两者可以共存用不同的可执行文件名区分开。5.3 提取失败的排查顺序遇到-e跑完什么也没出来按这个顺序查第一看 stdout 里有没有WARNING: Extractor.execute failed这类信息会直接告诉你缺哪个外部程序。第二看输出目录_firmware.bin.extracted/里有没有东西。binwalk 的提取策略是能识别就解解不了就只 dump 出偏移处的原始数据块所以目录里出现一堆.7z、.gz文件但没解开说明缺解包器。第三检查磁盘空间。-Me递归提取是能吃掉几十 GB 的空间不够时 binwalk 会莫名其妙中断。这也是我前面强调工作目录放 ext4 而不是/mnt/c的原因之一跨文件系统的 IO 性能在递归提取时会成为瓶颈。6. 实战拆一个固件再从图里抠出 outguess 藏的数据6.1 场景和目录规划假设你手上有个路由器固件firmware.bin里面除了正常的文件系统还夹着一张logo.jpg出题人用 outguess 往里塞了一段文字。这类组合在 CTF 和硬件提取里都挺常见。先说目录规划这是我踩过坑之后养成的习惯所有工作都在 WSL 的家目录下做不要放在/mnt/c理由后面第 8 节细说。mkdir -p ~/work/firmware cd ~/work/firmware cp /mnt/c/Users/me/Downloads/firmware.bin .6.2 用 binwalk 定位用 dd 精确切分先看整体binwalk firmware.bin输出会列出每个可识别结构的偏移、类型。看到类似DECIMAL HEXADECIMAL DESCRIPTION 0 0x0 TRX firmware header 28 0x1C LZMA compressed data 1048576 0x100000 Squashfs filesystem说明这是一个 TRX 头 LZMA Squashfs 的组合。直接提取sudo binwalk -e --run-asroot firmware.bin如果 binwalk 自动提取不干净就手动来。找到 Squashfs 偏移用 dd 切出来再解dd iffirmware.bin ofrootfs.squashfs bs1 skip1048576 unsquashfs -d rootfs rootfs.squashfsbs1很慢但最保险大文件可以用bs512 skip$((1048576/512))提速。切出来的文件用file和xxd | head再确认一次魔数别偷懒我因为偏移差几位白白多花了半小时的事不止一次。6.3 outguess 的安装先查仓库没有就编译Kali 仓库里 outguess 的可用性不完全固定先查apt-cache policy outguess有就直接sudo apt install -y outguess。没有就源码编译依赖很干净sudo apt install -y build-essential autoconf automake libjpeg-dev git clone https://github.com/crorvick/outguess.git cd outguess ./configure make -j$(nproc) sudo make install如果仓库里没有configure脚本先跑./autogen.sh生成。编译过程里最常见的两个问题一是找不到libjpeg头文件装libjpeg-dev就行二是运行时提示outguess: error while loading shared libraries: libjpeg.so.8: cannot open shared object file这是老版本 outguess 针对 libjpeg8 链接的现代系统的库叫libjpeg.so.62。暴力解法是建软链接但我不太推荐在生产环境这么干容易影响其他程序# 权宜之计仅限自己机器上做实验 sudo ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so.62 /usr/lib/x86_64-linux-gnu/libjpeg.so.8更干净的办法是找维护良好的 fork 重新编译或者用容器隔离这个环境。6.4 提取隐藏内容与结果核对outguess 的用法很直接。有密码的outguess -k secretkey -r logo.jpg hidden.txt没密码的outguess -r logo.jpg hidden.txt参数含义-r表示读取模式从 JPEG 里提取-k指定口令输出写到hidden.txt。反过来写入是outguess -k secretkey -d payload.txt cover.jpg stego.jpg提取出来先别急着看内容对不对先看输出的统计信息Reading logo.jpg.... Extracted datalen is 12345这个datalen是 outguess 报告的隐藏数据长度。如果你明明知道有内容却提到一堆乱码八成是口令错了——outguess 不会告诉你密码错误它照样按错误的密钥流去解出来就是垃圾。这是它和加密工具的一个关键区别别以为是文件坏了。7. 为什么 binwalk 扫不出 outguess 藏的东西7.1 两种隐藏压根不在同一个层面上这是我特别想讲清楚的一点。很多人拿着 outguess 处理过的 JPG 去喂 binwalk扫完发现什么异常都没有于是怀疑工具坏了。实际上binwalk 看的是文件结构层面的特征——魔数、已知文件头、压缩流特征、熵值突变。它在文件里找的是这段字节看起来像 Squashfs 头这里熵值突然升高说明有压缩数据。outguess 改的是JPEG 编码后的 DCT 系数的最低位。它不新增数据块不改变文件长度到能被察觉的程度图像解码出来视觉上完全正常。你在文件结构层面看它就是一张普通 JPEG熵值曲线也是普通 JPEG 的形态。binwalk 看不到它是完全正常的不是 bug。同样的道理strings、file、exiftool对 outguess 也基本无效——除非出题人额外把口令提示写进了 EXIF 注释里。7.2 该用哪把锤子工具选择决策表遇到可疑图片或文件按这个顺序判断现象该用的工具说明文件结构里有可疑数据块binwalk -e、foremost文件追加、拼接、嵌套JPEG 尾部有多余字节dd切割 file经典的steghide/cat拼接JPEG 系隐写outguess、steghide、stegdetect改 DCT 系数或频率域PNG 系隐写zsteg、pngcheck改 IDAT 的位平面完全看不出异常zsteg -a、steghide info先用探测类工具试别硬猜需要可视化各种 LSB 分析工具位平面可视化一眼看出问题steghide在 Kali 里是自带的和 outguess 用途相近但算法不同两者互相提不出对方的数据。做这类题时我习惯是先用zsteg -a扫一遍对 PNG 极其有效再用steghide info试探有没有东西最后针对 JPEG 上 outguess不敢赌、都试一遍。7.3 outguess 常见报错和边界情况除了前面说的libjpeg.so.8还有几个Couldnt open input file路径问题或者文件本身不是 JPEG。outguess 只支持 JPEG给它 PNG 会直接报错。提取出来datalen是 0 或极小可能图片确实没有隐写也可能隐写容量太小塞的是很短的字符串。重新保存过的图片提不出东西这是最坑的情况。JPEG 是有损压缩图片只要经过一次重压缩DCT 系数就被改动了嵌入的数据就毁了。所以从聊天工具里转发、截图保存过、用看图软件另存为过的图基本没法用。做这类分析一定要用原始文件。容量限制outguess 的隐写容量和图片大小、质量有关大概是文件大小的百分之几。塞大文件会报容量不足。8. WSL 与 Windows 之间的文件、路径与性能陷阱8.1 /mnt/c 的速度和你想的完全不一样WSL2 里访问/mnt/c/...走的是 9P 文件系统协议中间隔了一层小文件读写的性能损失非常大。我实测过解压一个几万文件的前端项目在 ext4 家目录下是十几秒在/mnt/c下面要几分钟。做固件提取这种会产生成千上万个小文件的操作时这个差距会让你崩溃。结论就是源码、工作目录、虚拟环境全部放在 WSL 的家目录里。Windows 侧访问这些文件用\\wsl$\kali-linux\home\用户名\这个路径资源管理器里能直接打开也可以映射成网络驱动器。反过来如果文件在 Windows 侧用cp拷进来再做处理别直接在原地操作。8.2 路径、权限和换行符三个具体问题路径映射Windows 的C:\Users\me\firmware.bin在 WSL 里是/mnt/c/Users/me/firmware.bin盘符小写反斜杠换正斜杠。写脚本时记住这一点。权限前面提到/etc/wsl.conf里的metadata挂载选项。没开这个你在/mnt/c下的文件上执行chmod x是不生效的脚本会因为 Permission denied 跑不起来。开了之后 Linux 权限位会被记录在扩展属性里。换行符Windows 侧编辑过的 shell 脚本带 CRLF在 Linux 下执行会报bad interpreter: /bin/bash^M。处理方式sudo apt install -y dos2unix dos2unix script.sh或者一次性把仓库里所有脚本处理掉find . -type f -name *.sh -exec dos2unix {} 。8.3 在 VSCode 里连 WSL 干活的一些配置VSCode 装 WSL 扩展之后在 WSL 终端里code .就能直接打开当前目录编辑器跑在 Windows 侧、文件和后端进程在 WSL 侧体验很好也不会碰到跨文件系统的性能问题。几个我调过之后觉得值的设置终端字体用Cascadia Code、JetBrains Mono或Maple Mono都是等宽带连字的长时间看 hexdump 和日志眼睛舒服很多开启terminal.integrated.defaultProfile.linux指向默认 shell把files.eol设成\n从源头避免换行符问题。另外如果你要跑sudo binwalk这类需要提权的命令建议在 VSCode 的集成终端里跑而不是让它去调系统终端路径和权限上下文都更清楚。9. 一张速查表以及我自己的操作顺序把整条链路压缩成一张表方便你对照排查阶段关键动作最容易出问题的地方装 WSL 与 Kaliwsl --install -d kali-linux锁定 WSL2下载慢可用离线包--import基础配置/etc/wsl.conf开 systemd 与 metadata改完忘记wsl --shutdownKali 换源改kali.sourcesdeb822补Signed-By新旧配置重复、缺 keyring更新apt updateapt full-upgrade时钟漂移导致not valid yet工具链源pipx、pip、conda、npm 分别配pip 的 PEP 668 限制别硬破binwalkapt 装 v2 或源码装 v3补齐解包器缺7z/unsquashfs导致提取不全提取binwalk -e --run-asroot异常时 dd 手动切偏移算错、磁盘空间不足outguess仓库没有就源码编译注意 libjpeg 版本图片被重压缩过数据已毁文件管理工作目录放 ext4Windows 侧走\\wsl$在/mnt/c下跑重 IO 操作按我自己的习惯整套流程会这么走一遍先确认 WSL 是 2 并且时间正常改kali.sources换到 TUNA 并apt full-upgrade装齐p7zip-full、squashfs-tools、mtd-utils这批解包器pipx管 Python 工具然后把工作目录建在家目录下开工。这套顺序是我被时钟漂移和/mnt/c的性能问题各坑过一次之后定下来的每次省下的排查时间比一开始多花的那两分钟值太多了。最后补一个我觉得挺有用的小习惯在开始动任何系统配置之前先在 WSL 里跑一次wsl --export备份或者至少把/etc/apt/整个目录复制一份出来。固件分析这类活儿经常要装一堆编译依赖和冷门解包器环境搞脏是迟早的事有个干净的还原点比事后一个个卸载要舒服得多。