安全处理未知RAR归档：从只读校验到工程基线重建

简介这份压缩包来自前端开发者 Qiangu Yihao 的开源项目 Web是一份博客互动网站的 CSS 样式实现示例主要面向刚入门前端、希望理解 CSS 如何控制页面结构与视觉表现的开发者。资源共 9 个文件核心为 1 个 HTML 页面配合 5 张 JPG 与 3 张 PNG 图片素材整体约 181KB结构精简适合直接解压查看站点骨架、图片引用方式与样式组织思路。页面设计覆盖了博客常见的分区布局、导航与内容展示、图片素材编排等场景可以从中学习选择器、颜色与字体设定、按钮和链接样式、悬停反馈等基础而实用的 CSS 写法同时也可以此为原型延伸练习 Flexbox/Grid 布局、媒体查询以及过渡和动画等 CSS3 特性。资源源自 GitHub 开源仓库来源清晰已有 1630 人学习浏览适合作为入门级前端页面拆解与改写的练习素材。1. 2018-03-20-boya.rar 到底是什么一次旧项目交接里的“黑匣子”拿到一个交接包压缩包只有一个问题里面是什么2018-03-20-boya.rar 这样的文件名拆解下来是备份日期加代号 boya看起来像历史项目快照也可能是整机备份。我的第一反应从来不是双击解压把它当普通文件夹打开而是先把它当成一个不可信的黑匣子来处理。这篇笔记记录我面对这类存盘的常规做法如何用只读命令看清单、判断加密和损坏、避免路径穿越最后把它整理成一个可继续开发的基线。这篇内容适合正在接手旧系统、恢复数据库冷备、或从交接盘里挖掘可复用代码的工程师也可以用来帮助维护新人规避常见的解包陷阱。2. 先别双击解压让 RAR 归档先“自证身份”再决定怎么处理2.1 只读列出文件清单一行命令看清归档全部内容拿到这类打包文件后我不会马上双击。归档可能是业务工具打包也可能只是某人手工用 WinRAR 右键压出来的目录。我的习惯是先在命令行下只读列出条目最常用的三个工具是 unrar、7z 和 rar。Linux 机器上不一定全部安装但我一般会先看 unrar 有没有因为很多发行版默认只给 unrar 而不会给 rar 的完整命令。unrar l -p- 2018-03-20-boya.rarl表示 list只列出路径和基础属性不解开内容-p-是禁止密码询问。如果这是一个加密归档直接交互式等密码会把自动化脚本卡死。用-p-以后即使有密码命令也会直接跳过并返回一个非零码你至少能知道它不是在正常可读状态。如果你的机器上装了 7-Zip / p7zip用7z l -slt能得到更细的元数据每个条目自己的 Modified、Attributes、CRC 都会写出来。这个清单会被我存成一个临时文件之后的校验、修复和重建都会基于这份清单来对比。7z l -slt 2018-03-20-boya.rar boya.lst注意-slt是全量技术信息输出比较长几百个小文件时可能上万行所以最好重定向成文件而不是直接滚动屏幕。看完输出你会知道这个归档是单文件还是一个目录树有没有可执行文件有没有.git目录有没有配置文件、数据库备份脚本以及里面文件的 mtime 分布。这里有一个大多数人容易省掉的细节还要看最上面一行的格式信息。unrar在列出第一个文件前会显示档案格式比如 RAR 4.x和已用恢复记录等信息。如果显示Cannot open则要检查文件是否真的完整或者是否根本没有读权限。列出目录不是解压它不会修改任何文件状态所以这一步可以重复执行作为后续所有操作的安全起点。2.2 从文件名拆出“时间”和“代号”2018-03-20 与 boya 的真实含义将文件名拆开2018-03-20 明显是日期。但在实际项目交接里这个日期可能是备份生成时刻、服务发布日或报表导出日。它不能说明内部数据的时间范围。比如我遇到过文件名是2018-03-20的 RAR里面文件的 mtime 从 2017-06 一直分散到 2018-03还有一些文件的 mtime 是 2018-01-10。如果不做分辨就会把它们当成同一时间点的一致快照实际上并不是。boya 这个代号可能是拼音缩写也可能来自某个系统的前缀。我在不知道它指代什么的情况下一般会先用 grep 在名单里找能达成共识的模式比如 boya、boya-admin、boya-api、boya.sql 等关键字。文件系统本身就是最大的证据不要靠猜。grep -iE (boya|2018|backup|dump|sql|tar|env) boya.lst | head -80重定向到boya.lst是想把它作为后续追踪的证据而不是每次重新解析head -80是为了别让检索日志导致输出太长。grep 只处理文件名列表不处理压缩包内部内容因此这个操作的开销几乎可以忽略。从这些文件名能大致判断归档类型如果都是*.sql和*.conf那多半是数据库冷备加环境配置如果看到很多.log那可能是日志归档如果有一堆.php或.java那就是源代码快照。三个类型对应的提取策略不同日志和源代码的处理方式完全不同——日志可以直接扔到临时目录源代码则必须要保留目录结构。2.3 识别 RAR/RAR5 与固实压缩为后续选择工具版本RAR 格式有 RAR4 和 RAR5 两个不同系列。用file命令识别最直接file 2018-03-20-boya.rar输出如果是RAR archive data, v1d, os: Unix这类说明是 RAR4如果显示RAR archive data, v5则是 RAR5。RAR5 的加密、分卷命名、恢复记录机制和 RAR4 不互通因此需要安装支持 RAR5 的工具。老版本的 p7zip 可能能列目录但解压时报 Unsupported Methodunrar 也不能用太旧的发行版仓库。遇到这种情况我不建议马上去下载某个新版本而是先查操作系统的软件源里有没有可用版本避免为了解压一个包而在内网引入不必要的二进制依赖。另外要看固实压缩。用 7z 的-slt输出找到Solid 的条目或者用 unrar 列出信息看是否显示Solid archive。固实归档里每个文件不是独立压缩块坏了一个块后面所有文件都受影响这会影响你对“文件损坏”的判断。比如你unrar t发现第 12 个文件 CRC 错误后面 30 个文件也全部失败不要认为是 30 个独立的损坏很可能只是第一个块出了问题。固实压缩还意味着你不能只解压单个文件就跳过损坏块。想要把归档里的代码恢复出来你必须处理整个压缩链。如果只是想看其中某一个文件的内容解压前要先想清楚是否值得承担后续文件的连带风险。对 2018-03-20-boya.rar 这样未知内容的历史包我一般会先复制一个副本再用副本做任何可能的读取尝试原始包永远留着。3. 用最小命令集安全提取让未知 RAR 只能碰临时目录3.1 先做只读校验再走完整解压当文件清单和格式确认完下一步不是直接解压而是先做校验试跑。unrar t命令只读取归档并校验 CRC不会写任何文件unrar t -p- 2018-03-20-boya.rar这个命令会逐个文件做 CRC 校验如果归档里有损坏你能精确看到具体是哪个文件。注意它在固实归档上同样会把后续文件一并标错但它不会毁掉原包。7z t是同样的作用7z t 2018-03-20-boya.rar我一般两个都会跑。先跑 unrar 再跑 7z如果两个工具对同一个归档的结论不同一般说明工具版本差异或 RAR5 支持不完整比文件本身更值得警惕。两个都通过才开始正式提取。然后正式提取到隔离目录mkdir -p /tmp/boya_sandbox cd /tmp/boya_sandbox unrar x -p- -y /path/to/2018-03-20-boya.rarx保留完整路径-y自动覆盖-p-禁制密码询问。为什么要cd到空目录再用相对路径解压因为即使归档里出现绝对路径unrar 在指定解压目录后也会被限制在目录里不过对路径穿越仍要先检查。另外还要把解压目录放在/tmp而不是项目目录因为项目目录往往没有空间而且解压出来的可能有文件权限位特殊一旦直接落在业务目录会产生误触发告警。初学者常在这里踩坑老手会专门为这个操作准备一个挂载点。3.2 区分“加密”和“损坏”只看输出不行要看退出码校验遇到错误时先确认错误码。有些是加密导致有些是 CRC 损坏两者处理方式完全不同unrar t 2018-03-20-boya.rar echo $?exit code 0 是全部通过2 是警告3 是严重错误4 是加密/密码错误5 是磁盘/写入错误6 是打开文件失败7 是用户错误8 是内存错误9 是文件不存在或根本没有响应10 是未知格式。不同版本会有差异但常用的 unrar 命令基本沿用这套。对固定脚本而言我一般只看它是否等于 0否则进入人工分类。将判断写成脚本时不能只看一次$?最好把 echo 状态先保存因为 echo 也会覆盖当时的退出码。针对密码问题unrar t的输出会说Encrypted或Wrong password对于损坏则输出CRC failed。如果显示多个文件 CRC failed先看第一个文件前面的块是否标记为 solid。R$? if [ $R -eq 0 ]; then echo 校验通过 elif [ $R -ge 3 ] [ $R -le 9 ]; then echo 数据损坏或读取错误需要修复 else echo 密码或选项错误先检查口令 fi这段脚本的价值不在于精确到每一个退出码而在于区分“数据坏了”和“数据没坏但读不了”。大规模处理历史归档时人眼不可能盯着每一行错误只有把退出码归成少数几类才能快速找出需要重点处理的包。3.3 解压前先看磁盘占用和 inode解压 RAR 时经常忽略磁盘总占用。一个 RAR 里如果有一万个零碎小文件每个文件至少要占用 4K 块甚至更多。虽然原文件总大小只有 1.2GB但按块大小计算实际占用可能超过 2GB。你只看到free还有 1.5GB解压却提示 No space left。因此解压前用unrar l看一下总大小再df -h /tmp看目标分区。如果两个分区是同一个物理盘也别相信它。另外还要检查 inode 是否充足df -i /tmpinode 耗尽后所有 mkdir 都报 No space但 du 显示仍有大量容量。日志型归档尤其常见。归档里如果含上十万个文件建议提前在新挂载点上解压。对 2018-03-20-boya.rar 这种历史包我一般先跑一次unrar l -p-把总文件数和原大小记下来和df -h /tmp的输出对照后再动手。不要等到解压中段才临时换目录中断后残留的目录和文件会干扰第二次解压。3.4 解压出的文件如何快速分类解压完成后第一件事不是看代码是先拿一遍文件后缀统计确定手上拿的是“源代码包”还是“数据包”。一个简单的 shell 命令find /tmp/boya_sandbox -type f | sed s/.*\.// | sort | uniq -c | sort -nr | head -30这段命令把每个文件名按最后一个点后的字符作为后缀统计出现次数。注意它会误判带点的目录名但在项目分类时足够有效。结果如果前几位是 sql、conf、env、log那更像服务器快照如果是 java、xml、gradle、properties那就是源代码归档。然后你再决定下一步是恢复服务还是只做代码分析。如果统计结果里出现很多无后缀文件再用file判断真实类型file /tmp/boya_sandbox/* | head -40这一步能识别出 shell 脚本、二进制可执行文件、图片和 SQLite 数据库。对一个从未见过的新归档先知道内容到底长什么样远比猜测“boya”代表什么更有用。4. 处理损坏、乱码和缺依赖的三种常规策略4.1 归档损坏修复前先做快照损坏修复不是一上来就rar r。如果你对手里的 2018-03-20-boya.rar 没有任何还原渠道先复制一份原始文件再做任何操作否则一场自救变成二次灾难。这是一句血泪经验。命令cp 2018-03-20-boya.rar /tmp/boya_repair/ cd /tmp/boya_repair rar r -y 2018-03-20-boya.rar unrar t 2018-03-20-boya.rar这里用到rar r命令是完整 rar 工具带的功能。unrar 只是解压或测试没有修复能力。很多 Linux 发行版不会默认装rar命令这时候你需要装一下或者等对方重新上传可靠副本。rar r正常情况下会读恢复记录。如果没有恢复记录命令会提示没有恢复数据并退出。此时唯一能做的是尝试用7z x -y把未损坏部分解开然后接受丢文件的事实。不要试图用一个坏包反复重新解压期望某次结果变好——RAR 校验是严格的每次结果都一样。对于分卷归档如果只有主包和几个.rev恢复卷可以用rar x配合.rev路径。不过2018-03-20-boya.rar是一个单文件包所以这条只作提示。分卷会比单包的恢复更依赖工具版本最好在同样的操作系统上还原。4.2 中文文件名乱码跨平台存档的老问题很多历史归档是 Windows 机器打包压缩条目里的文件名编码是 ANSI也就是 GBKLinux 默认用 UTF-8 解码后就成了乱码。文件名能解压但后续无法用 shell 直接处理。最直接的办法是解压后做一次编码转换。先确认当前文件名到底是什么编码file -i /tmp/boya_sandbox/* | head -20后用convmv做转换convmv -f CP936 -t UTF-8 --notest -r /tmp/boya_sandbox-f CP936是输入编码-t UTF-8是输出编码--notest才真正改名-r递归。执行前先不带--notest跑一次让 convmv 列出改名计划避免批量改错。注意如果解压时字符已经损坏到不可逆比如解压工具做了二次转码那 convmv 也无能为力只能从原始归档中重新提取。因此我一般建议先用 unrar 解压到空目录不要直接修改原归档。另一个相关问题是乱码也可能出现在文件内容里。如果压缩包里的.conf文件是用 GBK 编码保存的读取时会看到乱码。此时可以用iconv单独转码iconv -f GBK -t UTF-8 /tmp/boya_sandbox/etc/boya.conf这条命令不会改原始文件只是把标准输出转成 UTF-8方便你判断配置内容。处理一个旧归档时这样只读转换比重写文件更安全。4.3 缺依赖旧的配置和数据库备份不能直接套到新环境归档内如果包含.sql、.conf、.env等旧环境文件解压之后直接运行大概率是失败的。这不是 RAR 的问题而是时间跨度问题。2018 年代的 MySQL 权限和分区字段可能和现在的新版本不兼容。比如旧 dump 里可能有TYPEMyISAM这类写法新版本会直接报 syntax error。你应该把它当成历史数据先找一份当时对应的服务端。常见做法是只从归档里抽取数据库结构结构转换成 SQL 后在新环境里手动修改分号和字符集而不是试图直接导入。head -80 /tmp/boya_sandbox/db/xxx.sql这个头部注释里会有 dump 工具版本和数据库版本标识。先看它再决定是否导入。配置文件也不要直接覆盖。有可能里面存着生产数据库地址和密码它需要的是从交接人员那里确认而不是通过归档推断。把.env当作线索而不是结论。我会先把.env里的变量名和业务代码里用到的常量做一次对应再决定哪些需要迁移到新的配置管理里。4.4 归档没有顶层目录如何从散落文件重建上下文有些 RAR 打包时没有保留上层目录解压后直接是几十个文件和两三个子目录。遇到这种情况我会先做文件类型统计再按照文件名里的共同前缀分组for f in /tmp/boya_sandbox/*; do basename $f | cut -d_ -f1; done | sort | uniq -c | sort -nr假设文件名都是boya_orders.sql、boya_users.sql这样的格式按前缀分组后就能还原出表或模块维度。如果文件名没有共同前缀那就用file按二进制类型分类file /tmp/boya_sandbox/* | head -40把可执行文件、文档、图片和压缩过的数据分开先处理业务数据源代码和媒体文件可以后面再慢慢补。这种解法经常在旧交接包里派上用场尤其是同事离职前手动打包的乱目录。对 2018-03-20-boya.rar 这样的历史包散落文件往往隐藏着当时临时生成的脚本分类后再看比直接翻各个目录更不容易漏。5. 避坑RAR 归档操作里的 5 个常见翻车点5.1 路径穿越与符号链接解压后多了一个 /etc 下的文件现象unrar x执行后日志显示正在写入文件../boya/xx实际解压目录周围多了一个目录。原因打包工具在创建归档时把原始文件相对路径写成了../这种条目都是不安全的不该直接解压。解决在任何完整解压前先用7z l -slt检查一下路径7z l -slt 2018-03-20-boya.rar | grep ^Path | cut -d -f2- | grep -E (\.\.|^/|\\\\)有输出基本可以判定归档被污染。这时要继续提取的话需要重写路径但常见工具不具备改包能力。我一般直接退回去找原始打包者否则这条路径穿越隐患会一直在。注意RAR 还支持符号链接条目Linux 下解压后可能创建链接指向其他目录。即便没有..也要检查unrar l -v里条目属性和 link target。将完整列表保存下来方便对可疑归档做审计。5.2 磁盘空间估算偏差导致解压中断现象解压一半报No space left on device但查看df -h显示剩余空间几个 GB。原因RAR 里小文件数量特别多文件系统为每个文件分配 inode 和数据块实际占用远大于文件逻辑大小。尤其是日志归档或者代码仓库快照经常几万个文件。解决先看unrar l -p- 2018-03-20-boya.rar | tail -5里显示的 Files 数目和总体大小。如果当前分区 inode 使用率已经超过 90%换一个挂载分区再解压。为避免中途翻车最好先df -i /tmp确认 inode 充足。用/tmp如果是 tmpfs 而不是系统盘也要注意。使用独立挂载点解包是最干净的。已经跑了一半失败也不要反复在同一目录继续解压——把已经解压部分清空重新开始否则残留文件可能造成第二次问题。5.3 把 mtime 当成发布时间导致误判现象从 RAR 里提取出的源代码文件 mtime 是 2018-03-20就认定这个版本是 2018 年 3 月发布的版本其代码一定是当时的最新技术。原因RAR 打包时默认保留原始 mtime同一批文件 mtime 可能是最后一次保存时间而不是打包时间。有些文件可能自 2017 年就没改过。所以归档文件名或校验收到的日期不等于代码版本划分标志。解决要看 mtime 分布规律而不是只看文件名。用命令统计7z l -slt 2018-03-20-boya.rar | grep -A2 ^Modified | sort | uniq -c | head -40统计完就会发现修改日期分布在多个时间段再去用版本控制记录确认代码分支。不要在没有任何版本元数据的前提下靠日期推断。如果归档里同时有 VCS 目录比如.git直接用git log看提交历史如果没有但只有一个快照那就只能按文件内部注释里的版本号来定位。5.4 解压工具版本不一致导致同一个 RAR 结果不同现象同一台开发机同一个 2018-03-20-boya.rar同事用 WinRAR 目录中能看到 100 个文件你用命令行解压却只有 90 个并且没有任何错误提示。原因RAR5 的加密和固实特性在旧版 unrar 中不被支持或者新版 p7zip 在某些 RAR4 自解压包的处理上和 WinRAR 有细微差异。这个问题的成因往往是工具链版本混乱而不是包本身有问题。解决固定工具。环境中使用 unrar 和 7z 两个工具交叉验证。先unrar t再7z t如果通过再解压。将工具版本写入交接文档unrar | head -2 7z | head -2把输出和文件清单一起存档之后如果出现“在不同机器上解压结果不同”先对比工具链再检查包。旧包很容易踩到 RAR5 与老工具兼容雷所以我更倾向于在内网服务器上装官方 rar 工具不用发行版仓库里的旧 p7zip 做生产校验。5.5 杀毒软件把解压出的文件当成木马删除现象unrar x正常完成但过几分钟发现某个文件不见了日志显示Virus detected。原因归档里可能包含老旧的破解工具、误报的脚本或真正的恶意程序。杀毒软件扫描到压缩包内特征时就隔离了。解决在隔离环境中解压解压目录放到沙箱目录并暂时加入杀毒软件排除。但这不是让你绕过安全检查。等提取完成后用sha256sum把每个文件记录下来人工审查可疑文件。有些历史交接包确实混入了后门脚本尤其是从外部供应商那里拿到的包。对这类文件不要直接执行也不要在服务器上保留。安全争议直接丢弃。这个步骤能让你在保证数据可用的同时不把风险带进生产环境。6. 把旧存档变成可靠的工程基线校验、锁定与重建6.1 用哈希和文件清单锁住“原始状态”当我确认这个归档可以安全使用后我会立刻把原始归档的哈希和文件清单保存下来。第一行保存原始归档的哈希不管以后是转储到对象存储还是下一次传输整个包的完整性始终可以比对。第二行保存文件清单-v会让每个文件的大小、时间戳和属性更完整。两个文件一起才算把旧包的原始状态锁定下来。sha256sum 2018-03-20-boya.rar boya.rar.sha256 unrar l -p- -v 2018-03-20-boya.rar boya.filelist.txt这里的关键是不要只记录归档哈希不记录解压后文件的哈希。有条件时对每个文件再生成一个 sha256find /tmp/boya_sandbox -type f -exec sha256sum {} \; boya.files.sha256这可以在出现“哪里不知道被改了什么”时通过 diff 快速定位。对长期维护的项目这份文件清单还能当一个简易的文件级索引检索时不用重新打开 RAR。6.2 建立“只读基线”然后才开始动手改下一步把解压后的目录复制到baselines下并整体设为只读mkdir -p baselines cp -a /tmp/boya_sandbox baselines/boya-20180320 chmod -R a-w baselines/boya-20180320cp -a保持属性、链接和时间戳chmod -R a-w去掉写权限防止后续误操作覆盖这个基线。如果还有某个数据库 dump 需要导入先从这个只读目录复制一份出来不要直接在原目录上改。之后的工作副本放在别的地方。我后来处理多个交接包时都会把数量清单和哈希先放进项目仓库的 docs/handover 里再开始业务分析。这样做的好处是就算三个月后有人拿错包或者删了文件也能通过基线恢复。今天写这个流程最重要的习惯是“先看后动”。一个 RAR 文件名再短里面都有可能有你完全没预料的东西不听信文件名不盲信解压工具把每个操作都当成有副作用的行为来设计才能把历史包袱变成可用的工程资产。希望这次整理能帮到你。本文还有配套的精品资源点击获取