张晨：极限救援：PostgreSQL全文件勒索病毒恢复的史诗级挑战
内容提要
本文介绍了一起高难度PostgreSQL勒索病毒数据恢复案例。攻击者加密了所有数据文件，导致数据字典完全损坏。作者利用PDU工具的dropscan能力，将用户提供的704张表结构与单个数据文件逐一匹配，成功恢复了四分之三的核心表数据。尽管部分小表因数据页全毁无法找回，且最终数据未交付客户，但此案例突破了传统恢复极限，验证了碎片扫描匹配技术的可行性。
延伸解读
技术突破点：碎片扫描匹配
本文的核心创新在于将PDU工具的dropscan能力从碎片匹配扩展到单表文件匹配。在数据字典完全损坏的情况下，通过用户提供的704张表结构逐一与数据文件匹配，成功恢复了四分之三的核心表。这一方法突破了传统恢复的局限，为类似场景提供了新思路。
恢复的局限与风险
该方法存在明显局限：对于结构重复的表，无法自动区分，需要客户参与；若表结构重复过多，恢复结果难以保证。此外，小表因数据页全毁可能无法恢复。本文案例中，有10张表因数据页完全丢失而无法找回，说明恢复并非万能，需提前设定合理预期。
数据交付的遗憾
尽管技术上成功恢复了大部分核心表数据，但最终数据未交付给客户，原因未明。这提醒我们，数据恢复不仅是技术问题，还涉及客户信任、合同条款等外部因素。技术成功不等于项目成功，沟通与交付环节同样关键。
Q&A
PostgreSQL全文件勒索病毒恢复案例中，攻击者是如何加密数据文件的？
攻击者加密了数据库目录中的每个文件，并将文件后缀改为.9jeael。加密规则是加密每个文件的开头、中间和结尾各32 MB的数据。
在PostgreSQL数据字典完全损坏的情况下，作者采用了什么技术来恢复数据？
作者利用PDU工具的dropscan能力，将用户提供的704张表结构与单个数据文件逐一匹配，通过碎片扫描匹配技术来恢复数据。
为什么在PostgreSQL数据字典损坏后，表结构对于数据恢复至关重要？
因为PostgreSQL数据页不存储每列的长度信息等元数据，行数据只是一堆字节，如果没有表结构，就无法准确解析这些字节的含义，导致数据恢复极其困难。
在恢复过程中，作者如何处理被加密的文件头部？
由于每个文件的前32 MB被加密，作者在扫描时设置文件头偏移量从32 MB开始，跳过无效的加密部分，只对剩余部分进行匹配。
本次PostgreSQL勒索病毒恢复的最终结果如何？
成功恢复了四分之三的核心表数据，并导入数据库无错误。剩余10张表因数据页完全损坏无法恢复。但最终由于某些不可控因素，恢复的数据未交付给客户。
在恢复过程中，作者遇到了哪些挑战？
挑战包括：数据字典完全损坏，无法直接解析数据文件；文件头部被加密，需要跳过；需要区分主表文件、索引文件、TOAST文件等；部分小表数据页完全损坏无法恢复；以及匹配过程中需要客户参与区分重复表结构。
