[原创]某平台文件加密分析

前言本贴内容记录对文件解密常见还原方法以及思路，如有不妥请多多指教,如有侵权违规请沟通删除。问题描述再挂载盘时发现内部文件乱码，包括.php，.sh，ELF文件等
还有这文件头还原方法1. 方法一修改root密码在使用时发现控制台挂载尝试修改其中passwd如下

通过Shadow更改已知密码，看是否能进入bash
查看目标文件是否加密
成功解除方法二内存取证通过暂停虚拟机运行的方法，在虚拟机暂停时会生成一个.vmem文件，但要注意到的是它能提取的是：当时在内存中出现过、被缓存过、被映射过、被进程打开过的PHP文件内容。在这里通过脚本可以看到，提取出来的有限，且不是很规范。

加密分析对于最初问题描述来看，文件的加密方法可能在以下三种；1.PHP层解密比如PHP加载器、隐藏扩展、自动预加载之类。2. 应用层解密比如某个守护进程启动时，先把文件解开，再让Apache/PHP/后端去读。3. 文件系统层透明解密（最可能）也就是磁盘上看到的是密文，但系统运行时看到的是明文。第一种PHP层解密常用手段1. PHP扩展/Zend扩展解密通过：extension=xxx.so，zend_extension=xxx.so在PHP执行前拦截文件、解密源码、替换opcode。2. 商业Loader/私有Loader比如类似：ionCube，SourceGuardian，私有加载器表现是：磁盘上不是正常PHP运行时却能正常执行3. auto_prepend_file/auto_append_file注入每次执行PHP之前，自动先跑一个脚本。这个脚本可以做：解密，include劫持，动态eval，注册stream wrapper4. 脚本自身动态解码常见特征：base64_decode，gzinflate，gzdecode，openssl_decrypt，eval拼接函数名再调用，也可能先解密到临时文件再include。5.stream wrapper/autoloader劫持比如：stream_wrapper_register()改include_path，phar://、data://等包装器，autoload时动态加载真实内容等等核心判断思路如果只有PHP文件异常，优先怀疑PHP层loader/动态解码。如果PHP、ELF、shell 脚本、配置文件在同一目录里都表现成：离线看是乱码运行时正常那更像是：文件系统级透明解密  第二种应用层解密一现象思路是：某个程序先把密文处理成明文，然后业务程序再去读这个明文。它和文件系统层最大的区别是：解密动作是某个用户态程序主动做的；明文通常会以某种形式“落下来”或“存在某处”常见模式1启动时批量解密到另一个目录比如：/var/ceshi.enc/存密文启动脚本运行后，解到/var/ceshi/然后Apache/PHP/daemon去读/var/ceshi/现象离线看密文目录是乱码，运行后的目录是正常文件，能看到某个进程在启动时做了解包/解密动作2 启动时解密到临时目录比如解到：/tmp/...，/dev/shm/...，/run/...然后再：include这些临时文件，execve这些临时ELF。建软链接/绑定挂载到正式路径现象原始路径可能还是密文，但程序真正执行的是临时明文副本3 按需解密不是一次性全解，而是：访问某个PHP时现解启动某个daemon时现解用完再删现象平时看不到明文只有运行那个功能时才会出现4 解密到内存，不落盘某个守护进程把密文读出来，在内存里解密，然后：直接exec内存对象通过匿名映射供子进程使用，或者通过IPC/socket把内容给后端现象磁盘上找不到明文副本但进程内存和打开文件映射异常
重点看几类东西：1. 异常进程ps auxps -ef --forest关注自定义守护进程，很早启动的wrapper，名字伪装成系统组件的程序，会拉起 Apache/PHP/后端的父进程2. 启动链systemctl list-units --type=servicesystemctl cat <service>看ExecStart，ExecStartPre，Environment，额外shell脚本等等  第三种文件系统层透明解密它的核心是：磁盘底层存的是密文，但系统把某个目录“挂载”成明文视图。上层程序并不知道自己在读密文，它看到的就是正常文件。也就是说：PHP不需要自己解密，daemon不需要自己解密，Apache也不需要自己解密，因为它们打开那个路径时，内核/文件系统层已经把内容还原好了。它以为自己在读普通文件，实际上文件系统层先解密，再把明文返回给它常见实现方式1 eCryptfs最典型的“目录级透明加密”。特点是某个目录作为密文底层，再挂载成明文视图，未挂载时你看到的是乱码/密文块，挂载后同一路径或另一路径看到的是明文2 dm-crypt / LUKS这个更偏块设备层。特点：整个分区在底层是加密的，解锁后挂载成普通文件系统，上层看到的一切都正常，不过这种一般离线镜像层面表现和eCryptfs有点不同。3 overlay/bind/FUSE +解密组件也可能不是传统 eCryptfs，而是：FUSE 文件系统做透明解密，overlay 把明文层盖在密文层上，bind mount把另一个已解密目录映射过来等等怎么看主要不是盯“异常业务进程”，而是盯： 1. 挂载点mountcat /proc/mountsFindmnt -A看有没有：Ecryptfs，fuse，overlay，crypt，异常bind mount2. 目录是不是挂载覆盖点比如：离线镜像里/var/ceshi是密文目录，运行系统里/var/ceshi 实际被挂载成另一个视图检查findmnt /var/ceshifindmnt /var/www/html3. 谁触发了挂载如果是透明解密，往往会有某个启动动作：shell 脚本，systemd service，守护进程，伪装成系统程序的二进制也就是说：“第三种”底层是挂载机制，但“触发第三种的人”仍然可能是第二种里提到的异常进程/异常启动链。综上所述猜测是第三种，mount一下。

很明显eCryptfs挂载接下来寻找设在开机触发这个`eCryptfs`挂载通过寻找发现一个很可疑的程序：/usr/sbin/ModemManager通过string搜索mount发现如下内容，不太符合名字，正常来说是管modem的，不该负责挂载`eCryptfs`
进入main函数查看
发现自定义base64字典解码size_t sub_177D()
  char haystack[20488]; // [rsp+10h] [rbp-5010h] BYREF
  unsigned __int64 v2; // [rsp+5018h] [rbp-8h]

  v2 = __readfsqword(0x28u);
  s_ = 0;
  memset(&s_, 0, 0x5000u);
  sub_158A(
    bW91bnRhMXRhZWNyeXC0ZnLhM3Zgcf9veEQyZWHhM3Zgcf9veEQ

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291139.htm