文章总结： 文章详细分析了LockBit4.0勒索软件解密器的问题，发现客户支付赎金后仍无法解密文件的原因是解密器在处理大文件时存在逻辑缺陷，特别是文件尾部的Poly1305校验码损坏导致解密失败。作者通过逆向分析和修复该问题，成功恢复了大量关键数据，并建议受害者不要盲目支付赎金，而应寻求专业团队协助。
综合评分： 91
文章分类： 恶意软件,应急响应,漏洞分析,逆向分析

---

【病毒分析】缴纳了巨额赎金依旧无法解密？最新LockBit4.0解密器分析

原创

solarsec

solar应急响应团队

2025年6月25日 11:19

前情提要：LockBit 是自2019年以来最活跃的勒索软件组织之一，采用双重勒索策略并具备高度专业化运营能力。尽管在2024年遭遇国际打击并被揭露核心身份，该组织仍迅速恢复并于2025年推出LockBit 4.0版本。2025年5月，其运营数据库泄露暴露了大量内部细节。详情可见【独家揭秘】LockBit 4.0 解密器失效真相｜首发谈判日志＋万字深剖：发展脉络 · TTP 演进 · 2025最新 IOC。

1.背景

客户在遭遇勒索事件后因业务中断极为焦急，遂委托第三方公司代为与黑客进行谈判，并按照对方要求支付了巨额赎金，成功获取了解密器。然而在实际使用过程中发现，该解密器恢复效果极差：大量文件，尤其是体积较大的数据库文件未能成功解密，部分已“解密完成”的文件也严重损坏，无法正常打开或使用。第三方公司多次尝试再次联系黑客寻求技术支持，但对方已彻底失联，未再回应，导致数据恢复陷入困境。最终，第三方公司在无力解决问题的情况下，将客户引荐至我们团队，希望借助专业技术手段修复受损文件并挽回关键数据。

我们不建议受害者向黑客支付赎金购买所谓的恢复工具，因为在整个交易过程中主导权完全掌握在黑客手中，支付手段多为比特币等匿名加密货币，既难以追溯也无法保障交易安全，黑客可能在收款后拒绝提供解密工具，或者故意发送错误密钥，导致数据依然无法恢复，受害者也缺乏有效的申诉途径和法律保障，因此支付赎金不仅不能确保数据恢复，详情可参考文章【病毒分析】交了赎金也无法恢复–针对国内某知名NAS的LVT勒索病毒最新分析。

为协助客户最大程度挽回损失，我们在获取原始解密器后，第一时间对其进行了逆向分析，最终发现其在处理大文件时存在明显逻辑缺陷。通过修复该问题，我们成功恢复了大量此前无法解密的关键数据文件。本文将重点介绍此次解密器逆向分析的关键过程与修复技术细节。

1.1聊天记录展示

以下为该客户与 LockBit 黑客组织在赎金谈判期间的部分聊天记录截图。该谈判记录来源于2025年5月 LockBit 团伙被执法机构打击后泄露的大量运营数据，我们通过对其中的谈判日志进行梳理和还原，成功定位到该客户的完整交互过程。目前，该谈判页面已被黑客关闭，原始对话 ID 无法通过公开入口访问。我们已将相关内容导入至 SAR 勒索情报平台的“谈判分析”模块，并对其语义内容进行归类标注，平台也集成了“一键翻译”功能，帮助用户高效、直观地理解英文沟通中的关键威胁、推脱话术及赎金策略。

[图1] 客户支付赎金

[图2] 客户反馈使用黑客提供的解密器解密后显示很多文件无法修复，解密器存在问题

[图3] 客户发给黑客恢复异常文件，黑客表示从未遇到该情况，开始推脱问题

[图4] 黑客持续拖延

[图5]黑客提供了恢复文件，但客户验证后非所需文件

[图6]客户反馈问题，黑客长时间未回复

[图7]客户申请退款，黑客不予理会

在支付赎金后，由于解密效果严重不达预期，第三方公司曾多次尝试向黑客申请退款，但对方已不再回应，彻底失联。至此，客户初次委托的这家负责代谈和支付赎金的公司也已无计可施。最终，第三方公司将客户引荐至我们团队。我们在详细分析加密逻辑与解密器结构后，成功修复了解密逻辑中的关键问题，帮助客户完整恢复了数万个受影响的重要文件。

下文将对该解密器的技术机制进行深入分析，并在第四章我们会公开发布针对此次事件免费的恢复工具。如果您也遭遇了类似问题，欢迎联系我们协助处理——更重要的是，面对勒索攻击切勿盲目缴纳赎金，应在专业团队协助下开展分析研判与恢复评估。这次能够挽回，更多时候则可能再无机会。

1.2 谈判模式解析

| 角色层级 | 关键职责 | 典型细节 | 价值/收益 |
| — | — | — | — |
| 核心团队（Boss） | – 开发/维护加密器 – 搭建 DLS 泄露站、谈判后台 – 统一托管密钥 & 赎金钱包 | – 777 USD BTC 门槛才能拿到后台账号 – 技术服务费≈赎金 20% | “品牌方”——控制生态规则、抽成 |
| Affiliate（加盟攻击者） | – 渗透、横移、窃取数据 – 部署勒索程序 | – 自带 0day/钓鱼资源 – 享受全套自动化控制台 | “渠道商”——拿 80% 赎金 |
| Negotiator（谈判员） | – 受害者沟通、催款 – 调整赎金策略 | – 常见口头禅：Let me ask my boss | “前台客服”——加速回款 |
| 辅助服务商 | – 洗钱、流量租赁、初级代理 | – 兑换所 / Mixer / Bulletproof VPS | “外包供应链”——降低风险 |

在对话中可以看到黑客回复“我去告诉老板”，许多读者可能会疑惑：“黑客还有老板？”事实上，这句话揭示了LockBit家族背后的运作模式——RaaS（勒索软件即服务）。在RaaS模式下，与受害者沟通的通常是谈判人员或附属成员，他们并不是核心操盘者，而是“加盟代理”。整个组织结构中，核心团队负责开发与维护勒索软件本体、构建数据泄露站点、谈判门户等基础设施，并提供技术支持；而附属成员负责前期渗透、横向移动、数据窃取及部署勒索程序。两者之间按照约定比例分成收益，比如LockBit的核心团队会抽取约20%的赎金作为“技术服务费”。

据泄露的聊天记录显示，想要成为LockBit的附属成员并获取其后台权限，需支付约777美元的比特币费用。因此，这类“黑客集团”并非传统意义上的单人作案，而是高度产业化、分工明确的黑色供应链体系，“老板”也确实存在，只不过藏在幕后的平台操控者而已，关于运营模式与策略可参考【独家揭秘】LockBit 4.0 解密器失效真相｜首发谈判日志＋万字深剖：发展脉络 · TTP 演进 · 2025最新 IOC。

1.3 关键时间线

| 时间（UTC+8） | 事件节点 | 说明 |
| — | — | — |
| 2025/3/24 6:31 | 客户委托第三方与 LockBit 谈判支付赎金 | [图1] |
| 2025/3/25 14:55 | 解密后显示很多文件无法修复，解密器存在问题 | [图2] |
| 2025/03/24～03/30 | 黑客多次以「我去问老板」推脱，未给解决方案 | [图3] |
| 2025/03/27～04/02 | 双方持续沟通，黑客让客户持续等待 | [图4] |
| 2025/4/3 1:11 | 黑客提供100GB补偿数据链接，但非客户所需文件 | [图5] |
| 2025/4/9 4:28 | 客户反馈问题，黑客频繁失联 | [图6] |
| 2025/4/21 6:42 | 客户要求退款，黑客不予理会 | [图7] |
| 2025/4/23 | 第三方将客户转介至 Solar 团队 | |
| 2025/4/24 | Solar 团队收到样本完成逆向，定位逻辑缺陷 | |
| 2025/4/26 | 解决BUG问题，定制恢复工具 | |
| 2025/4/27 | 完成所有问题文件修复，客户检测文件无异常 | |
| 2025/6/27 | 公众号发布针对此次事件恢复工具 | |

2.样本文件基础信息

2.1 样本文件基本信息

| 描述 | 说明 |
| — | — |
| 名称 | lbg32_decryptor.exe |
| 大小 | 60,416 bytes |
| 加密后缀 | .JDXsjci2V |
| 操作系统 | windows |
| 架构 | 80386 |
| 类型 | exe |
| 字节序 | 小端 |
| MD5 | 4ce976e0a424227a374d485a71924bda |
| SHA1 | 29730aa767167746c67c137521fbec46af5ebbfe |
| SHA256 | 0a582aae66ecbb7dac6437fb3090061df8bcc160e35e5c588258e3d79b41f59f |

2.2 勒索信

2.3 其他注意事项

加密器和解密器中的密钥不匹配,但是算法相同,替换密钥即可解密.32位为通用解密器(用32位和64位加密的文件都可以被该解密器解密),在客户主机上有部分文件无法解密.

3.解密流程图

3.1 主要行为流程图

3.2 解密算法流程图

4.逆向分析

脱壳方法十分简单,为简单压缩壳,找到oep下断即可.在此不再赘述.

4.1 遍历本地驱动器

先获取本地驱动器属性,存入数组,并挂载隐藏分区.

4.2 遍历共享驱动器

遍历共享驱动器,并加入队列.

4.3 本地驱动器队列

遍历本地驱动器,跳过cd-rom驱动器,测试共享驱动器是否可连通.

4.4 扫描arp缓存

arp缓存中的主机也会被扫描,并解密.

4.5 文件解密

读取本地驱动器队列.进入解密函数.阻塞解密每个驱动器中的文件.

使用windows api遍历目录,根据白名单决定是否写入目录双向链表.

不处理的目录名如下:

[".","..","Windows","$Recycle.Bin","AllUsers","Boot","chocolatey","Microsoft Visual Studio","System Volume Information"]

不处理的文件名包含字符串如下:

["exe","lnk","dll","cpl","sys","Restore-My-Files"]

创建文件句柄,读取文件,判断大小,决定是否处理该文件.解密校验用字符串”FBIsosite”,进行第一次校验,并拷贝黑客私钥.

代码内联造成此处代码十分臃肿.此处是x25519密钥交换的主要算法,即标量乘法.

计算自定义hash.

加密器中的hash算法,与解密器中的完全相同,故引用注释.

黑客使用了openssl库中的poly1305算法,和源码对比可得.

此处同样有部分函数内联.

引用加密器分析的部分操作.

salt定义:

BYTE salt[] = { 32,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0 };

解密加密文件所用的密钥.此处密钥是正确的,但是使用poly1305校验不通过,原因是文件部分损坏,见实验部分.

后面为对于文件的分块解密,解密算法和加密算法完全相同(因为chacha20是异或流加密).

以下内容摘自加密器分析:

然后为共享驱动器创建生产者-消费者模式的遍历路径和解密文件两个线程,使用同样的方法解密每一个驱动器中的文件.

解密线程.

4.6 重启服务

最后根据hash比对得出被停止的服务(与加密器中停止的服务相同),并启动之.

4.7 关于数据未恢复bug的实验

从客户提供的样本文件来看，部分数据在解密过程中仍无法成功恢复。同时，由于客户仅提供了解密器，尚未获取到对应的加密器样本，因此我们在尚未排查提取加密器的情况下，基于加解密算法互为逆过程的前提，对现有的脱壳修复版本（已去除动态基址）进行实验验证，以进一步排查解密失败的根本原因.

4.7.1 实验一

4.7.1.1 目的

判断加密器和解密器算法是否互逆.

4.7.1.2 第一步

使用python生成x25519的一对密钥对.

4.7.1.3 第二步

将公钥和私钥硬编码分别写入加密器和解密器的对应地址.

加密器.   公钥foa: 0x1c390

解密器.   私钥foa: 0x1e4a0

4.7.1.4 第三步

保存文件并运行加密器,等待加密完成.

4.7.1.5 第四步

运行解密器.成功扫描并解密文件.

4.7.1.6 结论

加解密器的算法没有问题.问题只能出在数据损坏上.

4.7.2 实验二

4.7.2.1 目的

获得被加密文件中数据损坏的位置.

4.7.2.2 第一步

解压样本包至虚拟机中勒索病毒可访问到的路径.选定一个文件.

img

选择此文件.

4.7.2.3 第二步

物理机打开解密器源码.

找到此函数,根据解密流程图给程序分段打点.

打点后的解密主函数如下:

DWORD dec_a_file(const wchar_t* from_path)
{
        wchar_t dst_path[MAX_PATH+1] = { 0 };
        wcscpy(dst_path, from_path);
        *(PathFindExtension(dst_path)) = 0;
        HANDLE fp = CreateFile(from_path,GENERIC_READ,NULL,NULL,OPEN_EXISTING,NULL,NULL);
        if (INVALID_HANDLE_VALUE == fp)
        {
                return0;
        }
        LARGE_INTEGER tmp_fs;
        GetFileSizeEx(fp, &tmp_fs);
        ULONGLONG file_size = tmp_fs.QuadPart - 92;
        tmp_fs.QuadPart = -92;
        BYTE info[92] = { 0 };
        DWORD read_bytes = 0;
        SetFilePointerEx(fp, tmp_fs, NULL, FILE_END);
        ReadFile(fp, info, 92, &read_bytes, NULL);
        if (!is_file(info) || (read_bytes != 92))
        {
                CloseHandle(fp);
                return0;
        }
        HANDLE fp2 = CreateFile(dst_path, GENERIC_WRITE,NULL, NULL, CREATE_ALWAYS, NULL, NULL);
        if (INVALID_HANDLE_VALUE == fp2)
        {
                CloseHandle(fp);
                return0;
        }
        BYTE* file_pub = info + 60;
        BYTE shared_key[32] = { 0 };
        curve25519_donna(shared_key, hacker_priv, file_pub);
        //1.密钥交换输出点
        printf("shared_key: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;32; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", shared_key[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");

&nbsp; &nbsp; &nbsp; &nbsp; BYTE output[32] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE output2[32] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE ctx[216] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE chacha20_ctx[32] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_init(ctx,&nbsp;32);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_update(ctx, shared_key);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_update(ctx, file_pub);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_final(ctx, output);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;memset(ctx,&nbsp;0,&nbsp;216);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_init(ctx,&nbsp;24);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_update(ctx, output);
&nbsp; &nbsp; &nbsp; &nbsp; fake_sha512_final(ctx, output2);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;//2.自定义hash输出点
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("custom_hash: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;24; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", output2[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");

&nbsp; &nbsp; &nbsp; &nbsp; init_chacha20_ctx(chacha20_ctx, output, output2);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;//3.chacha20密钥拓展输出点
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("chacha20_key_expanded: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;32; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", chacha20_ctx[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");

&nbsp; &nbsp; &nbsp; &nbsp; BYTE* nonce = output2 +&nbsp;16;
&nbsp; &nbsp; &nbsp; &nbsp; BYTE* enced_file_key = info +&nbsp;12;
&nbsp; &nbsp; &nbsp; &nbsp; BYTE v175[32] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE v176[24] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE poly_1305[64] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; trans_or_gen_key(0, poly_1305,&nbsp;64, chacha20_ctx, nonce,&nbsp;0);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;//4.poly1305密钥生成输出点
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("poly1305_key: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;64; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", poly_1305[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");

&nbsp; &nbsp; &nbsp; &nbsp; POLY1305 plctx = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE poly_result[16] = {&nbsp;0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; BYTE salt[] = {&nbsp;32,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0&nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; Poly1305_Init(&plctx, poly_1305);
&nbsp; &nbsp; &nbsp; &nbsp; Poly1305_Update(&plctx, file_pub,&nbsp;32);
&nbsp; &nbsp; &nbsp; &nbsp; Poly1305_Update(&plctx, enced_file_key,&nbsp;32);
&nbsp; &nbsp; &nbsp; &nbsp; Poly1305_Update(&plctx, salt,&nbsp;16);
&nbsp; &nbsp; &nbsp; &nbsp; Poly1305_Final(&plctx, poly_result);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;//5.poly1305结果和文件校验值输出点
&nbsp; &nbsp; &nbsp; &nbsp; BYTE* check_cmp = info +&nbsp;44;
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("hash_of_file: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;16; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", poly_result[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("check_code_in_file: ");
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(int&nbsp;i =&nbsp;0; i <&nbsp;16; i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("%02X", check_cmp[i]);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;printf("\n\n");

&nbsp; &nbsp; &nbsp; &nbsp; trans_or_gen_key(enced_file_key, v175,&nbsp;32, chacha20_ctx, nonce,&nbsp;1);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(DWORD j =&nbsp;0; j <&nbsp;24; j++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v176[j] = v175[j] ^ v175[j +&nbsp;8];
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; section_arr all_sections;
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(file_size >&nbsp;0x100000)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ULONGLONG block_sz =&nbsp;0, gap_sz =&nbsp;0, block_start =&nbsp;0;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; block_sz =&nbsp;9&nbsp;* (ULONGLONG)(file_size /&nbsp;100);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; gap_sz = ((file_size -&nbsp;27&nbsp;* (ULONGLONG)(file_size /&nbsp;100)) >>&nbsp;1);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; block_start = block_sz + gap_sz;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(0, block_sz,&nbsp;1));
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(block_start, block_sz,&nbsp;1));
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(block_start *&nbsp;2, file_size - block_start *&nbsp;2,&nbsp;1));
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(block_sz, gap_sz,&nbsp;0));
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(block_start + block_sz, gap_sz,&nbsp;0));
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.unwind();
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.sort();
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;else
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_sections.push_back(section_uint64(0, file_size,&nbsp;1));
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(DWORD i =&nbsp;0; i < all_sections.secs.size(); i++)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; section_uint64& current = all_sections.secs[i];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; LARGE_INTEGER tmp_fs;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tmp_fs.QuadPart = current.start;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DWORD cursz = (DWORD)current.size;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; SetFilePointerEx(fp, tmp_fs,&nbsp;NULL, FILE_BEGIN);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; SetFilePointerEx(fp2, tmp_fs,&nbsp;NULL, FILE_BEGIN);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;memset(tmp,&nbsp;0,&nbsp;0x100000);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ReadFile(fp, tmp, cursz,&nbsp;NULL,&nbsp;NULL);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(current.is_enc)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; file_block_trans(tmp, tmp, cursz, v175, v176);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DWORD written =&nbsp;0;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; WriteFile(fp2, tmp, cursz, &written,&nbsp;NULL);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; CloseHandle(fp);
&nbsp; &nbsp; &nbsp; &nbsp; CloseHandle(fp2);
&nbsp; &nbsp; &nbsp; &nbsp; DWORD dwAttribute = GetFileAttributes(from_path);
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(dwAttribute &nbsp;& &nbsp;FILE_ATTRIBUTE_READONLY)
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dwAttribute &= ~FILE_ATTRIBUTE_READONLY;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; SetFileAttributes(from_path, dwAttribute);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DeleteFile(from_path);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dwAttribute = GetFileAttributes(dst_path);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dwAttribute |= FILE_ATTRIBUTE_READONLY;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; SetFileAttributes(dst_path, dwAttribute);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;else
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DeleteFile(from_path);
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;return1;
}

4.7.2.4 第三步

解密器输入选定的文件,收集输出结果.

结果如下:

4.7.2.5 第四步

ida调试打断点,获取黑客解密器的运行数据.

断点1: 取edx.

断点2: 取esi.

断点3: 断在0x40e901,输出取高亮变量(ida可双击打开).

断点4: 断在0x40e946,取高亮变量(双击打开).

断点5: 取edx.

4.7.2.6 第五步

收集断点结果.

断点1:

断点2:

断点3:

断点4:

断点5:

可以发现,只有断点5(文件中校验值)与成功解密的输出不一样.

4.7.2.7 第六步

patch掉poly1305校验的两处判断关键跳转,然后f9执行:

第一处:

第二处:

得到结果:

文件得以成功解密.

4.7.2.8 结论

数据损坏的位置在被加密文件中的16bytes的poly1305校验码处.

5.分析结论

本次解密失败的根本原因在于：加密文件尾部的 Poly1305 校验码发生了损坏，导致解密器在验证文件完整性时计算出的校验值与实际存储值不一致，从而触发了解密流程中的校验失败判断，终止了解密操作。通过Patch跳过该校验逻辑后，文件得以成功恢复，进一步确认了解密算法本身无误，问题确实源于校验数据的损坏。

以下是solar安全团队近期处理过的常见勒索病毒后缀：

| | | |
| — | — | — |
| 收录时间 | 病毒家族 | 相关文章 |
| 2025/01/14 | medusalocker | 【病毒分析】深入剖析MedusaLocker勒索家族：从密钥生成到文件加密的全链路解析 |
| 2025/01/15 | medusa | 【病毒分析】“美杜莎”勒索家族：从入侵到结束的全流程深度解析 |
| 2024/12/11 | weaxor | 【病毒分析】新崛起的weaxor勒索家族：疑似mallox家族衍生版，深度解析两者关联！ |
| 2024/10/23 | RansomHub | 【病毒分析】Ransom Hub:唯一不攻击中国的2024全球Top1勒索家族——ESXi加密器深度解析 |
| 2024/11/23 | Fx9 | 【病毒分析】Fx9家族首次现身！使用中文勒索信，熟练勒索谈判 |
| 2024/11/04 | Makop | 【病毒分析】揭秘.mkp后缀勒索病毒！Makop家族变种如何进行可视化加密？ |
| 2024/06/26 | moneyistime | 【病毒分析】使用中文勒索信及沟通：MoneyIsTime 勒索家族的本地化语言转变及其样本分析 |
| 2024/04/11 | babyk | 【病毒分析】BabyK加密器分析-Windows篇 【病毒分析】Babyk加密器分析-NAS篇 【病毒分析】Babyk加密器分析-EXSI篇 【病毒分析】Babuk家族babyk勒索病毒分析 【成功案例】利用多款国产内网渗透工具勒索数十台虚拟机的babyk解密恢复项目 |
| 2024/09/29 | lol | 【病毒分析】全网首发！全面剖析.LOL勒索病毒，无需缴纳赎金，破解方案敬请期待下篇！ 【工具分享】.LOL勒索病毒再也不怕！完整破解教程分享+免费恢复工具首发 |
| 2024/06/10 | MBRlock | 【病毒分析】假冒游戏陷阱：揭秘MBRlock勒索病毒及其修复方法 |
| 2024/06/01 | Rast gang | 【病毒分析】Steloj勒索病毒分析 |
| 2024/06/01 | TargetOwner | 【病毒分析】技术全面升级，勒索赎金翻倍，新版本TargetOwner勒索家族强势来袭？ |
| 2024/11/02 | Lockbit 3.0 | 【病毒分析】Lockbit家族Lockbit 3.0加密器分析 【成功案例】RDP暴露引发的蝴蝶效应：LockBit组织利用MSF工具及永恒之蓝漏洞进行勒索入侵 【成功案例】lockbit家族百万赎金不必付！技术手段修复被加密的数据库，附溯源分析报告 【病毒分析】繁体勒索信暗藏玄机！要价50万RMB赎金的Lockbit泄露版分析 |
| 2024/05/15 | wormhole | 【病毒分析】Wormhole勒索病毒分析 |
| 2024/03/20 | tellyouthepass | 【病毒分析】locked勒索病毒分析 【病毒分析】中国人不骗中国人？_locked勒索病毒分析 |
| 2024/03/01 | lvt | 【病毒分析】交了赎金也无法恢复–针对国内某知名NAS的LVT勒索病毒最新分析 |
| 2024/03/04 | phobos | 【病毒分析】phobos家族2700变种加密器分析报告 【成功案例】某集团公司的Phobos最新变种勒索病毒2700解密恢复项目 【病毒分析】phobos家族faust变种加密器分析 【成功案例】某集团公司的Phobos最新变种勒索病毒jopanaxye解密恢复项目 【病毒分析】phobos家族Elbie变种加密器分析报告 |
| 2024/03/28 | DevicData | 【病毒分析】DevicData勒索病毒分析 【病毒分析】DevicData家族扩散：全球企业和机构成为勒索病毒头号攻击目标！ |
| 2024/02/27 | live | 【病毒分析】独家揭秘LIVE勒索病毒家族之1.0（全版本可解密） 【病毒分析】独家揭秘LIVE勒索病毒家族之1.5（全版本可解密） 【病毒分析】独家揭秘LIVE勒索病毒家族之2.0（全版本可解密） |
| 2024/08/16 | CryptoBytes | 【独家破解】揭秘境外黑客组织的20美元锁机病毒：深度逆向分析+破解攻略！赎金？给你付个🥚 |
| 2024/03/15 | mallox | 【病毒分析】mallox家族malloxx变种加密器分析报告 【病毒分析】Mallox勒索家族新版本：加密算法全面解析 【病毒分析】全网首发！袭扰国内top1勒索病毒家族Mallox家族破解思路及技术分享 【成功案例】间隔数月双团伙先后利用某ERP0day实施入侵和勒索的解密恢复项目 【病毒分析】mallox家族rmallox变种加密器分析报告 【病毒分析】Mallox家族再进化：首次瞄准Linux，勒索新版本全面揭秘！ |
| 2024/07/25 | BeijngCrypt | 【病毒分析】全网首发！以国内某安全厂商名字为后缀的勒索病毒分析 |
| 2025/03/11 | 银狐 | 【病毒分析】潜伏在AI工具中的幽灵：银狐家族社工攻击的深度剖析 |
| 2025/03/07 | CTF赛题 | 【病毒分析】伪造微软官网+勒索加密+支付威胁，CTF中勒索病毒解密题目真实还原！ 【病毒分析】2024年网鼎杯朱雀组REVERSE02——关于勒索木马解密详解 |
| 2025/05/14 | 888 | 【病毒分析】888勒索家族再出手！幕后加密器深度剖析 |

勒索攻击作为成熟的攻击手段，很多勒索家族已经形成了一套完整的商业体系，并且分支了很多团伙组织，导致勒索病毒迭代了多个版本。而每个家族擅用的攻击手法皆有不同，TellYouThePass勒索软件家族常常利用系统漏洞进行攻击；Phobos勒索软件家族通过RDP暴力破解进行勒索；Mallox勒索软件家族利用数据库及暴力破解进行加密，攻击手法极多防不胜防。

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/12/12 | 【攻击手法分析】勒索病毒如何轻松绕过安全设备防线：第二篇-流量致盲，无声突破 |
| 2024/12/11 | 【攻击手法分析】勒索病毒如何轻松绕过安全设备防线：第一篇-驱动漏洞一击致命 |

而最好的预防方法就是针对自身业务进行定期的基线加固、补丁更新及数据备份，在其基础上加强公司安全人员意识。

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/06/27 | 【教程分享】勒索病毒来袭！教你如何做好数据防护 |
| 2024/06/24 | 【教程分享】服务器数据文件备份教程 |

案例介绍篇聚焦于真实的攻击事件，还原病毒家族的攻击路径和策略，为用户提供详细的溯源分析和防护启示；

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/06/27 | 【案例介绍】赎金提高，防御失效：某上市企业两年内两度陷入同一勒索团伙之手 |
| 2024/01/26 | 【成功案例】某集团公司的Phobos最新变种勒索病毒jopanaxye解密恢复项目 |
| 2024-03-13 | 【成功案例】某集团公司的Phobos最新变种勒索病毒2700解密恢复项目 |
| 2024-04-01 | 【成功案例】间隔数月双团伙先后利用某ERP0day实施入侵和勒索的解密恢复项目 |
| 2024-04-26 | 【成功案例】利用多款国产内网渗透工具勒索数十台虚拟机的babyk解密恢复项目 |
| 2024-05-17 | 【成功案例】RDP暴露引发的蝴蝶效应：LockBit组织利用MSF工具及永恒之蓝漏洞进行勒索入侵 |
| 2024-11-28 | 【成功案例】lockbit家族百万赎金不必付！技术手段修复被加密的数据库，附溯源分析报告 |

漏洞与预防篇侧重于技术层面的防御手段，针对病毒利用的漏洞和安全弱点，提出操作性强的应对方案：

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2025/01/08 | 【漏洞与预防】RDP弱口令漏洞预防 |
| 2025/01/21 | 【漏洞与预防】MSSQL数据库弱口令漏洞预防 |
| 2025/02/18 | 【漏洞与预防】远程代码执行漏洞预防 |
| 2025/04/10 | 【漏洞与预防】Atlassian Confluence存在远程代码执行漏洞 |
| 2025/04/17 | 【漏洞与预防】畅捷通文件上传漏洞预防 |
| 2025/05/27 | 【漏洞与预防】Microsoft Windows 文件资源管理器欺骗漏洞预防 |

应急响应工具教程篇重点分享应急响应过程中常用工具的安装、配置与使用说明，旨在帮助读者快速掌握这些工具的操作流程与技巧，提高其在实际应急场景中的应用熟练度与效率。

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2025/01/10 | 【应急响应工具教程】Splunk安装与使用 |
| 2025/02/07 | 【应急响应工具教程】取证工具-Volatility安装与使用 |
| 2025/02/20 | 【应急响应工具教程】流量嗅探工具-Tcpdump |
| 2025/02/26 | 【应急响应工具教程】一款精准搜索文件夹内容的工具–FileSeek |
| 2025/03/03 | 【应急响应工具教程】一款自动化分析网络安全应急响应工具–FindAll |
| 2025/03/13 | 【应急响应工具教程】Windows 系统操作历史监控与审计工具-LastActivityView |
| 2025/03/20 | 【应急响应工具教程】镜像取证之挂载镜像——Arsenal Image Mounter |
| 2025/04/03 | 【应急响应工具教程】Windows 系统综合排查工具Hawkeye |
| 2025/04/08 | 【应急响应工具教程】Linux下应急响应工具whohk |
| 2025/05/15 | 【应急响应工具教程】Windows日志快速分析工具——Chainsaw |
| 2025/06/05 | 【应急响应工具教程】Logman 系统性能与日志采集工具 |

如果您想了解有关勒索病毒的最新发展情况，或者需要获取相关帮助，请关注“solar专业应急响应团队”。

全国热线| 400-613-6816

更多资讯| 扫码加入群组交流

喜欢此内容的人还喜欢

【紧急警示】Weaxor最新变种“.wxx”来袭，批量入国内知名财务类管理系统发起勒索攻击！

索勒安全团队

【紧急通告】Outlook公布高危漏洞CVE‑2025‑47176，攻击者可远程执行代码！

索勒安全团队

【病毒分析】888勒索家族再出手！幕后加密器深度剖析 索勒安全团队

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：solar应急响应团队 solarsec《【病毒分析】缴纳了巨额赎金依旧无法解密？最新LockBit4.0解密器分析》