wordpress网站的CDN设置百度智能云官网

wordpress网站的CDN设置,百度智能云官网,代理网络app,个人推广网站以快制快#xff1a;利用生成式AI加速逆向工程XLoader 2025年11月3日 研究作者: Alexey Bukhteyev 核心要点 XLoader 仍是目前最难分析的恶意软件家族之一。其代码仅在运行时解密#xff0c;并受多层加密保护#xff0c;每一层都使用隐藏在二进制文件不同位置的密钥。即使是…以快制快利用生成式AI加速逆向工程XLoader2025年11月3日研究作者: Alexey Bukhteyev核心要点XLoader仍是目前最难分析的恶意软件家族之一。其代码仅在运行时解密并受多层加密保护每一层都使用隐藏在二进制文件不同位置的密钥。即使是沙箱也束手无策其规避技术会阻止恶意分支运行而真实的C2域名则隐藏在数十个假域名中。新版本的发布速度超过了研究人员分析的速度分析工作几乎总是在与时间进行一场注定失败的赛跑。生成式AI改变了平衡。研究人员无需再花费数天时间进行细致的手动分析、手动编写解密例程和逆向工程脚本现在可以利用AI在几小时内检查复杂函数、识别算法并生成可用的工具从而加速获取解密后的代码、字符串和失陷指标。Check Point Research展示了一种通过ChatGPT网页界面直接进行恶意软件分析的新方法。通过导出IDA Pro的数据并在ChatGPT云端进行分析我们证明了无需依赖模型上下文协议或实时的反汇编会话仅使用AI进行深度静态逆向工程是可行的。这种方法不仅摆脱了对本地重型工具的依赖还使得分析结果更易于重现、共享并促进了研究团队间的协作。在本研究中我们使用一个全新的XLoader 8.0样本来演示如何将基于ChatGPT的云端静态分析与MCP用于运行时密钥提取和实时调试验证相结合。我们记录了关键任务花费的时间并提供了真实的提示词示例展示了工作流程如何从一个完全加密的二进制文件开始直至恢复隐藏的C2域名。引言XLoader是一种广泛传播的、具有信息窃取能力的恶意加载器。它于2020年首次出现是知名信息窃取软件FormBook代码库的重构版本此后经历了显著的加固和功能扩展。除了Windows变种其开发者还推出了macOS版本不过在野外似乎远没有那么普遍。XLoader是极难分析的恶意软件典型范例。它结合了多种保护层带有额外混合步骤的自定义加密、伪装成有效但无意义的汇编代码的加密块、混淆的API调用、向系统进程的注入以及一系列沙箱规避技术。此外XLoader会加密其网络流量并将真实的C2地址隐藏在数十个诱饵和虚假域名中。XLoader的一个重要特点是其持续开发。作者定期发布新版本将内部机制修改得面目全非并添加新的反分析方法。因此先前的研究很快就会过时。在早期版本中提取配置需要利用复杂的算法拉取出几个密钥同时获取解密数据只需要剥离两层混淆和加密。版本5引入了内置打包器而在版本6和7中分析师不得不处理数十个相互解密、在每一阶段提取中间密钥的链式函数。对于XLoader的新手而言入门门槛已经变得非常高除了分析本身还需要额外的时间上手。当一个研究周期完成时恶意软件的下一个迭代版本可能已经发布了——如果发生了重大变化就需要另一项耗时的调查。当我们开始这项研究时XLoader 8.0刚刚被发现。似乎XLoader的开发者正在赢得这场竞赛。但随着生成式模型的兴起我们问自己AI能否改变游戏规则帮助我们更快地分析如此复杂的恶意软件为了探索这一点我们以两种方式应用了生成式AI辅助一是通过与我们的分析工具进行实时的MCP连接集成二是利用ChatGPT的项目和文件上传功能来处理导出的数据。事实证明每种方法都有其独特的优势结合起来能让我们更有效地解决逆向工程任务。在这项研究中我们专注于第二种方法并以一个最新的XLoader样本为例展示如何在没有MCP的情况下有效地使用ChatGPT进行逆向工程任务。动机为了防御XLoader从每个新版本中提取最新的失陷指标IoCs至关重要——包括真实的C2域名和URL、加密密钥以及版本标识符。这些失陷指标为检测签名提供支持并有助于追踪活跃的攻击活动。获取IoCs的主要方法是从样本中提取并解密恶意软件的配置数据。挑战在于XLoader不断变化的策略几乎在其自动化提取工具和脚本一开发出来时就将其破坏。恶意软件作者经常特意调整加密方案和打包方法来挫败这些努力。昨天还能用的自动配置提取器今天可能就失效了这意味着每个主要版本都需要一个全新的逆向工程周期。沙箱提供的帮助微乎其微激进的规避XLoader会检查虚拟机和分析工具的迹象。如果检测到恶意分支可能根本不会运行。即时解密关键函数和数据在使用前一直保持加密状态并在使用后不久恢复加密。沙箱可能永远无法捕获其解密状态。即使你设法在沙箱中转储进程内存通常也会得到一个不连贯的快照加密和解密的数据片段混杂在一起缺少那个确切时间点未在内存中的任何内容。无用的内存转储当尝试在调用某些API函数如NtResumeThread或NtAllocateVirtualMemory的确切时刻获取内存转储时你只会得到几乎完全加密的代码。C2伪装恶意软件真实的命令与控制域名隐藏在众多诱饵之中。捕获的网络流量通常不完整并且包含大量噪音。简而言之沙箱并不能解决问题。它无法提供可重现的转储或完整的失陷指标集。最可靠的方法仍然是静态分析逐一解包所有内容解密配置并提取失陷指标。缺点是为每个新版本手动执行此操作既缓慢又费力。这就是我们希望生成式AI能够成为“力量倍增器”的地方。两种AI辅助分析方法最近几个月许多逆向工程师开始通过模型上下文协议将LLM与IDA Pro集成以创建AI辅助的工作流程。这种智能体方法允许模型直接与反汇编器和调试器交互但它也有其自身的实际挑战。例如某些MCP客户端设置缺少ChatGPT界面的一些功能如“项目”或文件上传并且仍然需要维持一个活跃的IDA会话和稳定的连接。我们探索了两种互补的工作流程以应用GPT-5来破解XLoader实时MCP集成使用MCP我们让LLM直接访问我们的分析工具。这使得AI能够查询反汇编器、检查内存甚至实时控制调试器。基于ChatGPT的“离线”数据管道我们将IDA Pro数据库反汇编、反编译代码、字符串等和恶意软件二进制文件导出到ChatGPT环境中。然后我们要求ChatGPT对这些数据进行静态分析并在其云端沙箱内生成、优化并执行自己的Python脚本。不需要与我们的工具建立实时连接。每种方法都有其优势。MCP提供了一种智能体的、交互式的工作流程而离线管道则提供了一种自包含的、易于共享和重现的分析。这些方法并不相互排斥——你可以同时使用两者为每项任务选择合适的工具。MCP使用实时工具进行智能体分析将LLM接入IDA的想法并不新鲜。例如思科Talos的研究人员曾演示过将LLM作为“逆向工程助手”与IDA集成。在我们的设置中我们使用MCP将ChatGPT与IDA Pro桥接起来同时与x64dbg调试器和VMware虚拟机对接。这为LLM提供了一个观察恶意软件执行的实时窗口。图 1 – 通过MCP将LLM与逆向工程环境集成。除了静态分析和注释IDA数据库外这种实时集成还使AI能够执行以下操作按需提取实时数据。在关键函数处设置断点以便在运行时从内存中获取解密后的缓冲区或加密密钥。执行“实验和观察”循环。假设某个函数的功能然后从调试器中代入真实的运行时数据并比较输出根据结果调整分析。实时协助解包。如果样本自解密或解包代码则通过这些例程在中间值或解密代码一出现时就将其转储出来。然而MCP方法也并非没有缺点设置和资源需求这需要正在运行的IDA Pro实例和其他工具。分析师的计算机构成了循环的一部分该环境必须保持启动和稳定。单任务焦点标准的IDA不支持在一个界面中进行多个独立分析。如果我们想并行分析两个样本并获得AI协助我们需要两个独立的IDA会话和MCP连接。网络依赖性工作流程依赖于可靠的互联网连接。连接中断或MCP故障可能会在分析中途造成干扰。有限的ChatGPT UI功能当使用基于API访问的自定义MCP客户端时我们无法利用ChatGPT自身界面的一些便利功能例如长期的项目历史记录或轻松的文件管理。在许多情况下这些问题是可以控制的实时交互的好处超过了麻烦。诸如MCP SuperAssistant浏览器扩展之类的解决方案通过将ChatGPT界面和MCP连接性结合在一起减少了摩擦。最近ChatGPT引入了开发者模式可以直接使用MCP无需第三方插件。无论你使用插件还是内置模式工作流程仍然依赖于绑定到正在运行的工具链和稳定连接的实时MCP会话。如果上述任何要求难以满足例如你无法让IDA持续运行或者需要与没有相同设置但需要轻松共享分析进度的同事协作那么不同的方法可能更可取。这就是我们开发“离线”数据管道作为替代方案的原因。离线IDA导出管道在云端使用AI进行逆向工程我们的第二种方法完全摒弃了实时连接。在这里AI作为一个自给自足的分析师基于样本的完整静态快照进行工作。工作流程很简单我们将能从IDA Pro数据库导出的所有内容都导出为结构化格式。这包括每个函数的反汇编和反编译器输出、交叉引用列表、可读字符串甚至原始的二进制文件本身。我们将.zip文件上传到ChatGPT。例如我们的导出包包含以下文件ida_export.zip ├── meta.json # 基本信息样本名称、哈希值、映像基址等 ├── index.json # 将名称/有效地址映射到函数索引的查找表 ├── functions.jsonl # NDJSON格式反汇编、交叉引用、字节、函数原型等 ├── strings.jsonl # 二进制文件中的字符串列表及其引用 ├── data.jsonl # 全局变量、数组、命名数据引用 ├── decomp/ # 函数的反编译伪代码如果可用 │ ├── func_or_sub_XXXXXXXX.c │ └── ... └── sample.bin # 恶意软件样本本身实际上最好将存档上传到ChatGPT项目。仅附加在聊天中的文件可能会在会话重启后消失而项目中的文件在整个参与过程中都可用并且可以在不同的聊天中重复使用。我们还编写了一个初始提示词解释数据的组织方式以及AI应如何格式化其输出。本质上我们教会了AI如何阅读我们给它的“电话簿”以及我们希望它如何记录笔记。设置好之后这个管道允许ChatGPT完全在其自身环境中进行深度静态分析。我们可以要求它查找加密算法、追踪复杂的控制流甚至编写并执行Python脚本来从sample.bin中解密一些数据。许多此类任务可以在不需要我们提供任何新信息的情况下完成——AI基于我们提供的数据工作通过运行Python脚本在需要时验证其逻辑。如果出现错误它会修复脚本并重新运行测试重复此过程直到结果收敛。与我们之前的方法相比所有这些步骤分析、编写代码、测试、修正都在单个循环中运行无需数十次本地的MCP调用。这种方法有几个明显的好处无需持久的本地会话如果我们的IDA崩溃或我们关闭了笔记本电脑这都没有关系因为ChatGPT可以从云端访问它所需的一切。我们不需要实时照看连接。易于重复和共享由于分析的整个状态都捕获在我们的导出文件中任何拥有存档和提示词的人都可以重现该分析。更好地利用ChatGPT的功能在ChatGPT界面内部我们可以利用文件上传、持久的聊天历史和可编辑的画布等功能。便于协作多名研究人员可以独立处理同一样本之后通过共享suggestions.json文件合并结果无需比对IDB文件。安全的脚本执行ChatGPT可以直接在安全的云环境中对“活动”样本进行原型设计和测试分析脚本并将可用的输出交付给分析师。极快的上手速度无需设置MCP服务器或配置复杂的集成。广泛的适用性该概念不局限于x86二进制文件或IDA。也就是说离线方法并非万能的“魔法棒”。有些情况下我们仍然需要求助于实际的调试因此需要MCP。此外离线管道虽然功能强大但并非在所有场景下都适用。出现问题及我们如何解决不出所料使用AI处理离线的IDA导出数据并非一帆风顺。我们遇到了一些关于AI性能的问题并通过在提示词中添加严格的规则来解决。猜测缺失值有时模型会尝试捏造缺失的数据例如在运行时动态计算的加密密钥。为了防止这种“幻觉”我们强制规定“证据优先”的规则每个数值和每个算法都必须有来自导出数据的证据支持。塑造输出以匹配期望例如一个字符串解密例程预期会返回可打印文本但由于提取密钥时出错输出是损坏的。为了让输出“看起来正确”模型应用了Base64编码。我们禁止任何仅为了使结果看起来有效而进行的“美容”转换如Base64。相反模型必须在密钥或算法中找到实际的错误并重新运行测试直到输出正确。索要存档中已有的数据早期模型有时会索要我们已经提供过的数据。我们通过制定“本地优先”的规则来修复这个问题首先在存档文件中搜索。有了这些预防措施我们的AI“助手”成为了静态分析工作中可靠的分析师。GPT-5实践分析XLoader内置的加密器在处理较旧的ChatGTP模型时要获得正确结果需要将任务分解为许多小步骤并明确告诉模型该做什么甚至需要指出确切的代码地址和要应用的算法。没有这种详细程度的指示输出结果就不可预测。这种方法更接近于“基于文本的编程”需要我们深度参与。而使用GPT-5我们可以提出更广泛、更抽象的任务。以下我们展示一个混合方法的例子分析XLoader内置的加密器将IDA导出作为主要数据源同时使用MCPx64dbg进行结果验证。我们向AI助手提供了处理数据的指示后收到了一份简短的报告图 2 – IDA导出初始报告。接下来我们刻意将任务表述得对分析样本一无所知以模拟对XLoader不熟悉的人的操作。我们的第一个提示词尽可能抽象“从入口点开始对样本进行初步分析并提供简短报告。”处理这个简单提示花了8分46秒。结果我们的助手正确识别了RC4实现并得出结论该样本是加壳的。值得注意的是仅基于模型可用的数据它推断该样本看起来与XLoader相似。图 3 – 初步分析报告入口点分析。此外它还检测到了API调用混淆。图 4 – 初步分析报告推测调用VirtualProtectEx函数。它还成功识别了执行权移交给解密后代码的位置。图 5 – 初步分析报告调用解密后代码中的原始入口点。在这个阶段我们的首要任务是尽快到达有效载荷。因此我们首先要求助手查找所有密码学函数调用然后分析有效载荷具体是如何解密的。我们发现主有效载荷块经过两轮RC4首先是对整个缓冲区进行RC4解密然后使用不同的密钥以256字节的块进行第二轮解密。图 6 – 初步分析报告描述两轮RC4加密。此外助手设法收集了解密后代码中原始入口点的虚拟地址。加密块在二进制文件中的偏移量。加密数据块的大小。下一步是获取实时密钥并验证结果。此时我们转向了MCP。在其中一步我们还要求助手读取一段解密数据以验证静态解密的正确性。最终它获得了以下密钥阶段1密钥阶段2密钥它还获得了一段解密后的代码图 7 – 在x64dbg中由AI控制的调试。在从内存中读取到最终密钥后我们要求助手识别这些密钥是在哪里、通过何种算法生成的并使用上一步捕获的实时数据验证分析是否正确。最终AI生成了一个能够解包所分析样本的工作脚本。然而该脚本并不具有普适性因为它用于定位密钥的模式与这个特定样本紧密绑定。因此当我们尝试将其应用于其他版本的样本时脚本失败了需要进一步手动微调。除了创建通用解包器的最后一步整个分析耗时约40分钟需要进行39次MCP调用。下表列出了我们使用的提示词以及每个分析步骤所花费的时间。提示词耗时MCP调用次数初始提示词指令37秒0从入口点开始对样本进行初步分析并提供简短报告8分46秒0查找并仔细检查所有对已发现的密码学函数的调用4分13秒0分析主有效载荷块解密4分13秒0在所需地址设置断点并捕获所需数据。… 开始前请提供计划。9分7秒39查找阶段1和阶段2 RC4密钥的计算方式…6分56秒0继续到阶段2密钥派生4分40秒0为阶段1和阶段2密钥实现离线重现器。然后实现一个完整的静态解密器…1分13秒0总计39分8秒39分析解包后的样本在我们手动创建了一个名为oep_start的函数对应原始入口点之后我们在IDA中打开了解包后的样本并再次应用了导出脚本。我们还创建了一个新项目来分析解包后的样本。甚至在没有开始深入研究之前就可以明显看到IDA未能识别大部分代码而且许多已识别的函数看起来无效。图 8 – IDA中解包后的XLoader样本。这可能意味着代码以某种方式被混淆或者函数被加密了。事实上正如我们在引言中提到的我们知道XLoader使用即时函数解密。对于一些函数应用了多层加密。为了实验我们想看看在没有我们指导的情况下AI助手是否能自行确定这一切。我们使用与分析加壳样本时相同类型的提示词开始了分析。在初步分析之后我们识别出混淆API调用的使用。使用RC4加密并在RC4使用前后进行额外修改。某种“阶段1构建器”。图 9 – 分类报告及“阶段1构建器”函数。函数解密方案一接下来我们要求助手专注于所谓的stage-1 builder周围的逻辑并定位相关函数的交叉引用。AI助手识别出了90个类似的函数。这些函数派生出6字节的头尾标记使用这些标记在内存中定位目标区域用六个NOP指令覆盖标记转换该区域然后将执行权转移到一个硬编码的唯一地址。图 10 – 函数加密方案分析结果以及分析后重命名的函数。助手还实现了内联的Python代码片段并解密了其中一个加密函数向我们提供了所有数据、密钥以及部分解密后的代码图 11 – 关于成功解密其中一个函数的报告。有趣的是在这种情况下甚至不需要使用MCP因为提取的密钥的有效性很容易被AI验证如果解密后能够定位代码的起始和结束标记就意味着密钥和算法被正确恢复了。此外我们可以看到解密后的数据看起来并不随机这表明函数确实被正确解密了。AI在重新实现算法方面表现得非常好。然而它未能完全实现一个无需人工辅助就能解密所有函数的通用脚本。问题出现在定位构建20字节有效RC4密钥所需的所有XOR修饰符上。挑战在于有效的RC4密钥是通过将其4字节组件与一个4字节的修饰符进行XOR运算而派生的每个加密函数的修饰符都是唯一的。虽然内部种子总是位于包装函数内部的标记附近但助手无法实现一个通用的方法来找到外部种子因为它可能被放置在调用函数内的各个位置并可能特意与其他常量混合在一起。图 13 – 创建函数解密脚本时遇到的局限性报告。我们必须手动修改脚本以确保它能够正确定位所有外部种子。此外我们还修改了定位剩余常量的规则以使脚本真正健壮并能与其他样本一起工作。因此AI显著减少了分析和脚本开发所需的时间但在现阶段它还无法完全取代人类。很明显XLoader的创建者故意通过将关键常量分散在多个函数中来复杂化密钥构建过程其程度之深以至于AI都无法开发出定位它们的算法。我们在此不披露我们如何推导密钥以免给XLoader开发者任何优势。最终应用脚本后我们在第一轮解密了51个函数。许多解密后的函数也包含对加密函数的类似调用。连续应用脚本三次后我们从最初发现的90个函数中总共解密了77个函数。图 14 – 解密后的函数示例带有已修补的6字节头部标记。将生成的样本加载到IDA后我们可以看到仍有大量代码块未被识别图 15 – 大量代码块仍未被IDA识别。在快速审查中我们还识别出几个仍然保持加密状态的函数图 16 – 应用解密脚本后仍保持加密的函数。还值得注意的是在上述描述的第一种方案中加密函数是使用6字节序列定位的这些序列在解密后被六个NOP指令替换。这意味着函数必须有一个有效的、未加密的序言。同时在图16的右侧我们可以看到一个缺少有效序言的加密函数。这可能表明使用了不同的解密方法。函数解密方案二我们重新导出了数据库并将其加载到ChatGPT中。我们使用以下提示词开始了分析并上传了77个函数的解密日志在所分析的方案中加密函数使用6字节序列定位这些序列在解密后被六个NOP指令替换。这意味着函数必须有一个有效的、未加密的序言。一些加密函数没有有效的序言例如sub_407293、sub_411053、sub_415343。这可能表明对它们使用了不同的方法。尝试找到它。值得注意的是我们在提示词中指出了缺少有效序言这一点。没有这个观察结果AI助手无法识别额外的解密器。图 17 – 发现的第二种解密/修补方案。新发现的方案使用XOR计算4字节的头部和尾部标记。头部标记锚定在实际入口点之前一个字节。解密后代码在缓冲区指针加一字节的位置写入规范的序言并用NOP指令修补尾部标记。函数体使用两层解密。第1层密钥由ai_rc4key20_build函数构造然后与一个1字节的修饰符进行XOR运算。第2层密钥通过将头部标记与16个零字节连接而成。函数解密方案三在最新的方案中同样使用4字节标记来查找函数的开始和结束。与前一种方法一样应用了两层加密并且使用相同的密钥解密第一层。然而第二层的20字节密钥被嵌入到包装器内部并使用一个4字节的值进行修改。此外可能会使用一个单独的函数来处理第二层的解密和修补过程。图 21 – 用于处理第二层解密和修补过程的函数。我们在XLoader中识别出三种不同的函数解密方案方案1– 最常见。在此方案中加密函数已经以有效的序言开始。所有函数复用全局的20字节基础密钥但每个函数还有一个唯一的4字节XOR修饰符。基础密钥和修饰符相结合派生出每个函数专用的RC4密钥。方案2– 使用4字节标记和两层加密。第一层使用由一个专用的密钥构建函数产生、然后用一个单字节进行XOR调整的20字节密钥。第二层密钥由4字节头部标记与十六个零字节连接而成。方案3– 与方案2类似但第二层密钥并非从头部标记派生。相反每个包装器嵌入其自己的20字节常量用于解密前缀直至一个标记值然后应用相同的序言/尾部修补。值得注意的是为了实现通用的静态解密器我们仍然需要自己将任务分解成更小的步骤定位包装函数、提取20字节密钥、恢复4字节修饰符、以及识别和计算标记位置。只有在确认每一步都可靠运行并为每个函数生成正确数据后我们才将它们组合成单个解密器。同时AI显著减少了实现正则表达式尽管仍需要手动调整以及分析和实现加密算法所需的时间。通过每次解密迭代我们都获得了一批新的解密函数其中一些包含解密其他函数所需的密钥。通过对四种迭代顺序应用所有三个解密器我们最终成功解密了101个函数。不幸的是无法精确测量此任务所花费的时间因为它需要大量的额外工作和手动修正。然而这个阶段无论对我们还是LLM来说都是最复杂和耗时的。我们还得到了一个包含对已分析函数建议名称的suggestions.json文件。这非常有用因为我们可以将此文件保留用于其他分析会话并轻松地将其导入到当前的IDB中甚至在新的IDB中导入在解密函数之后而无需与旧的数据库进行比对。我们现在拥有了一个完全解密的样本这使得我们可以使用相同的方法继续进行分析。API调用去混淆现在我们有了一个完全解密的样本我们可以对其应用相同的方法。我们首先加载suggestions.json然后执行导出。如前所述即使在样本的最初分析期间助手就已经指出了混淆API调用的存在。该样本的导入地址表是空的并且没有包含库名或函数名的纯文本字符串。由于我们通过上传解密样本创建了一个新的干净会话我们决定测试分析结果的可重现性。因此在第一个提示词中不提供任何提示我们要求助手识别API调用混淆机制。四分钟后我们收到了对算法的描述图 22 – 其中一种API解析算法的描述。有趣的是在第一次分析和第二次分析期间我们的AI助手识别出了负责API哈希解密的不同函数。接下来我们使用以下简单的提示词生成API调用去混淆脚本实现一个用于去混淆API调用的IDAPython脚本。用模块!函数、原始ID和有效地址注释解析器和每个调用点针对IDA 9。记录所有去混淆尝试。我们得到了一个具有以下功能的脚本图 23 – API调用去混淆IDAPython脚本的描述。由于助手没有访问IDA的权限我们必须手动测试脚本。如果有错误我们将结果发回聊天并请求修正。我们进行了五次迭代花了大约20分钟才获得一个完全可用的版本。因此我们还要求助手分析替代路径分析例程sub_404603作为替代的API哈希解密器。恢复其算法。查找调用点。扩展IDAPython去混淆器。我们又进行了五次迭代花了14分钟才获得一个功能完整的脚本。XLoader使用相同的哈希解密机制来查找沙箱痕迹、虚拟机以及研究人员环境中典型的进程。在修复问题的同时我们还添加了基于字典的哈希暴力破解这使我们能够自动注释特定于某些规避技术的函数和字符串。图 24 – 去混淆后的API函数和字符串标识符。总的来说从第一个提示词到获得功能完整的API去混淆脚本大约花费了AI助手一小时的工作时间。这个数字不包括本地测试或编写提示词所花费的时间。对于这个任务人工投入是最小的。关键API调用的额外保护在审查API调用去混淆结果时我们注意到一些函数是通过一个有趣的包装器调用的。这个函数充当一个安全调用蹦床它在调用函数指针之前临时加密几乎整个映像然后在调用返回后解密相同的区域。这种机制之所以引人注目是因为该函数几乎始终处于加密状态因此很难在没有静态解密的情况下检测到其存在。在内存转储中它仅以加密形式出现。同时如果某些安全软件或沙箱试图分析或转储受此包装器保护的API调用发生时的进程内存该机制会有效地屏蔽恶意代码。总共有20个函数受到这种方式保护包括与进程、线程、内存和文件操作相关的NTAPI例程以及几个WinSock函数。图 27 – 受“安全调用蹦床”保护的API调用列表。字符串解密样本中没有可读的字符串。同时代码中有一系列短小的例程它们共享相同的骨架序言分配一个小的栈帧并初始化一个局部数组其大小因函数而异。随后是一组重复的、具有相同顺序和参数签名的调用图 28 – XLoader代码中加密字符串的示例。让我们分析其中一个函数。由于我们为此任务启动了一个新的会话我们指示AI助手信任现有的、简要描述每个函数行为的注释这样它就不会重新分析已经涵盖过的例程。结果我们确定这个函数使用一个先前解密的例程中的算法来解密字符串。请注意AI如何仅从一个简短的提示词就构建了调用图并描述了每个例程的行为图 29 – 字符串解密桩的调用图和描述。通过一个简单的提示词我们轻松获得了加密密钥和解密后的字符串。图 30 – 字符串解密结果包含派生的密钥和密文。现在我们有信心AI助手理解了加密字符串的存储方式、密钥的派生方式并且已经分析和正确重新实现了解密算法现在我们可以继续实现脚本来解密剩余的字符串。这次我们使用了一个稍微详细的提示词因为我们希望特定的信息同时出现在注释和控制台输出中实现一个解密字符串的IDAPython脚本针对IDA 9。要求 - 找到对解密器函数sub_4050F3的每次调用并用解密后的字符串进行注释。 - 对于每个字符串输出调试信息加密的缓冲区、XOR调整字节、长度和解密后的字节。 - 以十六进制打印所有二进制数据。这次我们很幸运立即得到了一个可用的脚本我们用它解密了175个字符串图 31 – IDA中解密后的字符串。分析所需的总时间约为20分钟。我们现在有了一个具有去混淆字符串和API调用的解密样本可以像普通二进制文件一样进行分析。然而XLoader并不那么简单即使在这个阶段一些数据仍然保持加密状态。解密域名提取失陷指标列表始终是恶意软件分析中的关键任务。网络指标如域名和URL尤其重要因为它们有助于通过流量分析检测和分类恶意软件。这就是为什么提取域名至关重要——即使有些可能是诱饵或处于非活跃状态。在恢复的字符串中我们看到了64个Base64编码的条目。回顾XLoader的版本历史我们发现从版本2.8开始它开始以Base64形式存储加密的域名。毫无疑问这64个Base64字符串代表了我们必须解密的域名。早在版本4XLoader就增加了两层使用不同密钥的改进RC4加密使得解密更加复杂。在后期版本中这个过程变得更加复杂。总的来说为了获得解密的域名我们需要剥离至少五层首先识别密钥在哪里以及如何初始化然后解密初始化加密字符串的函数解密字符串本身对结果进行base64解码再应用另外两层解密。同时获取每一层的密钥是最困难的部分因为生成它们所需的不同数据片段分散在多个函数中很难定位。在继续之前我们更新了字符串去混淆脚本使其也重命名负责检索解密字符串的函数并为所有处理Base64编码字符串的函数分配ai_dec_domain_{NN}前缀。然后我们导出了数据库为域名解密做准备。所有对ai_dec_domain_{NN}函数的调用都发生在一个单一的函数ai_dec_func_0内部图 32 – 域名生成函数。我们使用最简单的提示词开始分析这个函数分析 ai_dec_func_0 (0x00404913)分析结果是我们获得了详细的描述显示ai_dec_func_0是XLoader的阶段1域名构建器。对于给定的域名索引它从ai_dec_domain_NN中提取匹配的种子字符串进行base64解码然后运行一个密钥化的、带差异转换的RC4其密钥是一个存储在ctx0x23D0处的20字节密钥并与域名索引进行字节异或。结果被重新编码为base64并写入输出缓冲区。这是一个中间产物不是最终的ASCII域名。图 33 – 域名生成函数分析报告。一个特殊的“令牌”分支在a5222时启用用于为URL生成路径字符串。接下来我们要求助手重现ai_dec_func_0实现的转换。由于我们的脚本已经在上一步检索了解密后的字符串并将其作为注释添加我们请求同时使用这些字符串以及重复的字符串解密ai_dec_domain_NN反汇编中的注释包含base64编码的加密域名。取ai_dec_domain_01中的那个然后用ai_dec_func_0进行转换返回最终字符串。结果我们的助手未能自行定位ctx0x23D0处的密钥。图 34 – AI无法定位密钥。这并不奇怪因为导出的数据中没有包含对该结构体字段的引用。因此我们不得不手动定位该密钥的初始化位置并将该信息提供给AI助手。你可以在ai_dec_func_4 (0x00407293)中找到ctx0x23D0的初始化也可以检查sub_404453。在提取密钥之后我们再次尝试现在你有了所需的密钥。取ai_dec_domain_01的字符串然后用ai_dec_func_0进行转换返回最终字符串。结果我们得到了ai_dec_domain_01返回的字符串经过第一层解密后重新进行Base64编码的中间值。由于字符串仍然是加密的而且我们尚不知道接下来会发生什么我们需要进一步调查你返回的字符串仍然是加密的。追踪从ai_dec_func_0开始的完整转换链... 输出最终域名和简洁的逐步流程将所有密钥/IV以十六进制打印。如果缺少任何值请准确说明它是什么以及在哪里读取。结果我们发现获得的Base64字符串会再次被解码然后使用一个在函数ai_dec_func_11内部生成的20字节密钥通过第二层进行解密。这个密钥还会与一个SALT_DWORD进行异或。然而SALT_DWORD的初始化在ai_dec_func_11中缺失因此助手无法自行检索它。图 37 – AI无法定位阶段2密钥。与之前的情况一样我们手动恢复了缺失的值。复杂性在于使用的不是偏移量0x25C8而是基础值0x2000加上后来添加的0x5C8这使得搜索稍微困难一些。我们不仅提供了推测SALT_DWORD初始化发生的函数地址还提供了相关的代码片段。在分析过程中我们的AI助手确认密钥是正确的并成功解密了对应于ai_dec_domain_01的域名图 38 – 成功解密域名的结果。现在AI助手可以自动解密所有域名了。让我们通过要求它解密前16个域名来验证这一点解密从ai_dec_domain_00到ai_dec_domain_15的域名。输出表格索引源_base64最终_域名。从ai_dec_domain_NN反汇编注释中获取每个函数特定的base64字符串。最终我们获得了一个包含完全解密的域名的表格。现在让我们回想一下在分析的一开始我们发现了ai_dec_func_0的一个独立分支当最后一个值等于222时被激活。在这种情况下会生成一个4字符的标签该标签后来成为URL的一部分。以前这个标签对于所有域名和恶意软件活动都是相同的。现在每个域名都有自己的标签。我们尝试使用以下提示词解密前16个域名的标签重现 ai_dec_func_0 在 a5222 且域名索引 0..15 时的输出。作为回应助手提供了恶意软件如何生成这些4字符标签的描述以及包含前16个标签的表格。图 39 – 域名生成函数在“令牌”模式下的描述。结论自首次出现以来XLoader一直是一个不断变化的目标每个新版本都在提高安全分析师和防御者的门槛。XLoader从一个双层谜题演变成一个由嵌套解密器、分散的密钥材料和仅在运行时出现的代码构成的迷宫。多年来这意味着当研究人员完全解开一个样本时攻击者已经在下一个版本中领先一步。生成式AI改变了这种平衡。结合基于云端的分析和偶尔的MCP辅助运行时检查我们将大量机械性的逆向工程工作委托给了LLM。我们不再花费数小时手动重写解密例程而是要求我们的AI模型来完成并在几分钟内获得可工作的原型。AI的使用并没有消除对人类专业知识的需求。XLoader最复杂的保护措施如分散的密钥派生逻辑和多层函数加密仍然需要手动分析和有针对性的调整。但是分类、去混淆和脚本编写等繁重工作现在可以大大加快。曾经需要数天的工作现在可以压缩到数小时。对于防御者来说这不仅仅是生产力的提升。更快的周转意味着更新的CjCFFIeR8ym/owPWlcCcHgBVd/b5mMK4Q8QsvZEaK2dVtB6JA3GdoXzlmEeXtOAQfgesvwt2upPCOsG4GD7Oxz6u5CSyL1A0d7uLvD5gk更多精彩内容 请关注我的个人公众号 公众号办公AI智能小助手对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号网络安全技术点滴分享