1. 项目概述当Python脚本披上“千层甲”最近在分析一些安全事件时我遇到了一个相当“狡猾”的Python恶意样本。它不像那些直接扔个eval(open(bad.py).read())的初级脚本而是玩起了“套娃”游戏。你拿到手的可能是一个.zip解压出来是个.tar.gz再解压是个加密的文本文件解密后里面是一串base64解码后得到的还不是明文Python代码而是一堆看不懂的二进制数据——marshal序列化后的字节码对象。这种层层嵌套、步步为营的混淆方式目的就是增加分析人员的逆向难度拖延时间甚至让自动化分析工具直接“懵圈”。这个样本的核心手法正是利用了Python语言的动态性和丰富的内置模块将恶意负载Payload像洋葱一样一层层包裹起来。从最外层的通用压缩格式如zip、tar到中间层的简单编码如base64、hex再到最核心的Python字节码通过marshal或__pycache__中的.pyc混淆形成了一个典型的“压缩-编码-字节码”三层防御。对于安全研究人员、运维工程师或是任何需要审查不明Python脚本的开发者来说掌握一套系统性的“剥洋葱”方法至关重要。这不仅能帮你看清恶意代码的真面目更能深入理解Python代码是如何被“打包”和“隐藏”的从而提升你的代码审计和威胁狩猎能力。2. 核心思路拆解逆向“套娃”的完整链条面对一个多层混淆的样本最忌讳的就是一头扎进细节。我的思路是先进行“无损拆箱”像外科手术一样逐层剥离直到触及最核心的可执行代码逻辑然后再进行“静态还原”与“动态验证”。2.1 整体逆向流程设计一个高效的逆向流程应该是线性的、可回溯的。我通常遵循以下步骤文件指纹识别首先使用file命令、binwalk或通过Python的magic库识别文件的真实类型。很多时候一个文件后缀为.txt的文件实际可能是一个gzip压缩流。外层剥离针对常见的压缩包zip, tar, gzip, bz2和编码base64, hex, uuencode编写或使用现成的脚本进行循环解压和解码直到无法被这些工具自动识别为止。这一步是纯数据操作。中间层解析剥离外层后我们可能会得到一段Python代码字符串。但这段代码往往不是功能代码而是负责“解包”下一层的加载器Loader。需要静态分析这段加载器代码理解其如何还原出核心负载。核心层还原加载器通常会使用compile()、exec()、eval()并结合marshal.loads()或pickle.loads()来执行一段序列化的代码对象。我们的目标就是截获这个序列化的字节码数据块并将其反序列化、反编译为可读的Python源代码。分析与验证将还原出的源代码进行人工分析理解其恶意行为。必要时在绝对隔离的安全环境如沙箱、虚拟机中进行动态行为验证。这个流程的关键在于每一步都要保留输入和输出确保过程可复现。同时要警惕加载器代码中可能存在的反调试、环境检测等对抗手段。2.2 为什么选择“静态动态”组合拳纯粹静态分析面对高度混淆的代码可能束手无策尤其是当代码片段是动态拼接如字符串分割、异或运算后拼接或依赖特定运行时环境才能解密时。而纯粹动态分析直接运行在恶意样本面前风险极高可能瞬间导致系统被入侵。因此“静态引导动态取证”是更稳妥的策略。即通过静态分析理解大致的解密逻辑然后在一个受控的、无网络、无重要文件的隔离环境中运行经过我们改造的“解密脚本片段”只让它执行解密例程而不执行最终的恶意负载。例如我们可以将样本中exec(decrypted_payload)替换为print(decrypted_payload)或将其写入文件从而安全地提取出最终代码。3. 实战工具与准备打造你的Python逆向工具箱工欲善其事必先利其器。以下是我在分析Python恶意样本时核心依赖的工具和环境它们覆盖了从基础文件操作到深度字节码分析的整个链条。3.1 环境与基础工具隔离的Python环境这是铁律。使用virtualenv或conda创建一个全新的、隔离的Python环境用于分析。绝对不要在生产和开发环境中直接操作可疑样本。文本编辑器/IDEVSCode、Sublime Text或Vim需要具备良好的十六进制查看插件。有时需要直接查看文件的二进制内容。命令行工具file快速识别文件类型。binwalk强大的文件分析工具能识别嵌入的多重文件格式和压缩流。strings提取文件中的所有可打印字符串常用于快速发现URL、路径、密钥等线索。xxd或hexdump以十六进制格式查看文件对于分析非文本的marshal数据至关重要。Python内置库这是我们的主力军。zipfile,tarfile,gzip,bz2,lzma处理各类压缩。base64,binascii处理各类编码。marshal核心中的核心用于序列化和反序列化Python字节码对象。disPython反汇编器将字节码转换为人类可读的指令。inspect有时用于获取还原后代码对象的更多信息。ast抽象语法树对于还原出的源代码可以用ast模块进行解析和美化甚至安全地评估常量表达式。3.2 进阶分析与反编译工具uncompyle6 或 decompyle3当前最活跃的Python字节码反编译器能将.pyc文件或代码对象Code Object直接反编译成高质量的、近似原始的Python源代码。这是将marshal数据还原为可读代码的终极利器。安装pip install uncompyle6它支持多个Python版本但需要注意样本字节码的Python版本需与uncompyle6支持的版本匹配。xdis一个Python跨版本反汇编和字节码操作库。uncompyle6就依赖于它。当uncompyle6直接反编译失败时可以用xdis先进行反汇编人工分析关键逻辑。PyCharm Professional 或 VSCode with Python Debugger强大的调试器。可以在受控环境下对加载器代码进行单步调试观察变量状态动态提取解密后的关键数据。注意网络上有些所谓的“在线Python反编译”网站。强烈建议不要将任何可疑的、尤其是可能敏感的恶意样本代码上传到第三方在线服务这存在数据泄露和法律风险。所有操作应在本地隔离环境完成。4. 逐层拆解实战亲手剥开恶意样本的“洋葱”假设我们拿到一个名为suspicious_package.zip的文件。让我们一步步拆解它。4.1 第一层文件识别与通用解压首先使用file命令进行初步判断。file suspicious_package.zip如果输出显示是ZIP archive我们就用Python的zipfile来处理。但更稳妥的做法是使用binwalk因为它能递归发现内嵌文件。import binwalk import os def recursive_extract(file_path, output_dir): 递归解压文件直到无法识别出压缩/编码格式为止。 os.makedirs(output_dir, exist_okTrue) current_file file_path iteration 0 extracted_something True while extracted_something and iteration 10: # 防止无限循环 extracted_something False print(f[*] 分析迭代 {iteration}: {current_file}) # 使用binwalk扫描 for module in binwalk.scan(current_file, signatureTrue, quietTrue): for result in module.results: # 检查是否有已知的压缩/归档文件签名 if zip in result.description.lower() or \ gzip in result.description.lower() or \ tar in result.description.lower(): print(f [] 发现 {result.description} 于偏移 {result.offset}) # 这里简化处理实际应根据类型调用对应库 # 例如如果是zip使用zipfile.extractall # 本例假设我们手动处理 # 假设我们通过其他方式或已知确定第一层是zip # 实际分析中可能需要根据binwalk结果动态调用解压函数 iteration 1 print(f[*] 递归解压结束最终文件: {current_file}) return current_file # 实际手动操作可能更直接 import zipfile import tarfile import gzip import bz2 import lzma def extract_file(filepath): 根据扩展名或magic number尝试解压。 import magic mime magic.from_file(filepath, mimeTrue) if mime application/zip: with zipfile.ZipFile(filepath, r) as zf: zf.extractall(.) print(f[] 解压ZIP: {filepath}) return zf.namelist()[0] # 返回第一个文件名 elif mime application/gzip or filepath.endswith(.gz): with gzip.open(filepath, rb) as f: content f.read() new_name filepath.rstrip(.gz) with open(new_name, wb) as out: out.write(content) print(f[] 解压GZIP: {filepath} - {new_name}) return new_name # ... 处理其他格式 else: print(f[-] 无法解压: {filepath}) return filepath # 开始解压 next_file extract_file(suspicious_package.zip)经过几轮解压我们可能最终得到一个名为payload.bin或stage2.py的文件。payload.bin可能是一串base64编码的文本而stage2.py则是一个Python加载器。4.2 第二层解码与加载器分析如果得到的是payload.bin用文本编辑器打开如果是一串由A-Za-z0-9/组成的字符串那很可能就是base64。import base64 with open(payload.bin, r) as f: encoded_data f.read().strip() # 注意去除换行符 try: decoded_data base64.b64decode(encoded_data) # 判断解码后是文本还是二进制 try: decoded_text decoded_data.decode(utf-8) print([] Base64解码后为文本:) print(decoded_text[:500]) # 预览前500字符 with open(decoded_stage.py, w, encodingutf-8) as out: out.write(decoded_text) next_file decoded_stage.py except UnicodeDecodeError: print([] Base64解码后为二进制数据保存为文件。) with open(decoded_binary.bin, wb) as out: out.write(decoded_data) next_file decoded_binary.bin except Exception as e: print(f[-] Base64解码失败: {e})如果得到的是stage2.py或解码后得到的Python文件我们需要静态分析它。一个典型的恶意加载器可能长这样# stage2.py - 一个简单的加载器示例 import marshal, zlib, base64 # 加密或编码的字节码数据可能被分割、混淆 encrypted_code_segments [ eJxLZo...1, # 一段base64 789cf34d..., # 另一段可能是zlib压缩的hex ] def decrypt_and_execute(segments): full_data b for seg in segments: # 可能每段有不同的处理方式 if seg.startswith(eJ): data base64.b64decode(seg) else: data bytes.fromhex(seg) # 可能还有一层压缩 try: data zlib.decompress(data) except: pass full_data data # 核心步骤通过marshal加载字节码并执行 code_obj marshal.loads(full_data) exec(code_obj) # 危险在分析环境不要直接exec if __name__ __main__: decrypt_and_execute(encrypted_code_segments)分析要点找到数据源定位存储混淆代码的变量如encrypted_code_segments。理清代解密链看清数据是如何被一步步处理的base64decode-hex decode-zlib decompress- ...。定位核心调用找到marshal.loads()或pickle.loads()的位置以及最终的exec()或eval()调用。我们的目标不是运行exec(code_obj)而是截获code_obj。修改加载器将exec(code_obj)替换为保存代码对象的语句。# 修改后的分析脚本 analyze_loader.py import marshal, zlib, base64 from pathlib import Path # 原加载器的数据和解密函数 encrypted_code_segments [...] # 从stage2.py复制过来 def decrypt_and_save(segments, output_pathextracted_codeobj.bin): full_data b for seg in segments: # 复制原解密逻辑 if seg.startswith(eJ): data base64.b64decode(seg) else: data bytes.fromhex(seg) try: data zlib.decompress(data) except: pass full_data data # 关键修改不执行而是保存marshal数据 Path(output_path).write_bytes(full_data) print(f[] 已提取marshal字节码数据至: {output_path}) # 可以尝试直接加载看看是否是有效的marshal对象 try: code_obj marshal.loads(full_data) print(f[] 成功加载marshal对象类型: {type(code_obj)}) print(f[] 代码对象属性: co_name{code_obj.co_name}, co_argcount{code_obj.co_argcount}) return code_obj except Exception as e: print(f[-] 加载marshal对象失败: {e}) return None if __name__ __main__: decrypt_and_save(encrypted_code_segments)运行这个脚本我们就得到了最核心的extracted_codeobj.bin文件里面是序列化后的Python代码对象。4.3 第三层Marshal字节码反编译与源代码还原现在我们手握marshal序列化数据。marshal.loads()可以将其还原为一个代码对象types.CodeType但这个对象无法直接阅读。我们需要反编译。方法一使用uncompyle6直接反编译推荐import marshal import uncompyle6 import io # 加载marshal数据 with open(extracted_codeobj.bin, rb) as f: code_obj marshal.load(f) # 注意marshal.load从文件读取loads从bytes读取 # 将代码对象反编译为源代码字符串 output_io io.StringIO() try: uncompyle6.deparse_code2str(code_obj, outoutput_io) recovered_source output_io.getvalue() print([] 反编译成功源代码) print(recovered_source) with open(recovered_source.py, w, encodingutf-8) as f: f.write(recovered_source) except Exception as e: print(f[-] uncompyle6反编译失败: {e}) # 如果失败尝试反汇编方法二先反汇编再人工分析或尝试其他工具import dis import marshal with open(extracted_codeobj.bin, rb) as f: code_obj marshal.load(f) print([*] 字节码反汇编结果:) dis.dis(code_obj) # 也可以查看代码对象的详细信息 import types if isinstance(code_obj, types.CodeType): print(f\n[*] 代码对象详情:) print(f 文件名: {code_obj.co_filename}) print(f 函数名: {code_obj.co_name}) print(f 参数数量: {code_obj.co_argcount}) print(f 常量: {code_obj.co_consts}) print(f 变量名: {code_obj.co_names})如果uncompyle6因版本不兼容等问题失败反汇编结果虽然可读性差但能让我们看到关键的操作码如LOAD_GLOBAL,CALL_FUNCTION,IMPORT_NAME等结合常量池(co_consts)可以推断出大致的逻辑比如它导入了哪些模块os,socket,subprocess调用了哪些危险函数。方法三处理嵌套代码对象有时marshal加载出来的是一个顶层代码对象其常量(co_consts)中可能还嵌套着其他代码对象比如函数定义。我们需要递归地反编译所有代码对象。import marshal import uncompyle6 import io import types def decompile_code_obj(code_obj, indent0): 递归反编译代码对象及其常量中的子代码对象。 prefix * indent print(f{prefix}[*] 反编译: {code_obj.co_name} (at {code_obj.co_filename}:{code_obj.co_firstlineno})) # 反编译当前代码对象 output_io io.StringIO() try: uncompyle6.deparse_code2str(code_obj, outoutput_io) print(f{prefix}[] 成功:) print(output_io.getvalue()) except Exception as e: print(f{prefix}[-] 反编译失败进行反汇编:) import dis dis.dis(code_obj) # 递归处理常量池中的子代码对象 for const in code_obj.co_consts: if isinstance(const, types.CodeType): decompile_code_obj(const, indent 1) # 使用 with open(extracted_codeobj.bin, rb) as f: main_code_obj marshal.load(f) decompile_code_obj(main_code_obj)5. 疑难杂症与对抗技巧处理在实际分析中恶意样本作者会设置各种障碍。以下是一些常见对抗手段及应对策略。5.1 对抗技巧一字符串与常量混淆现象加载器或还原出的代码中字符串、函数名、模块名被分割、反转、异或或使用chr()拼接。# 示例字符串混淆 module_name .join([o, s]) # - os func_name chr(115) chr(121) chr(115) chr(116) chr(101) chr(109) # - system url_parts [htt, p://, evil., com/, path] url .join(url_parts[::-1]) # 反转拼接应对静态模拟执行对于简单的拼接、反转可以直接在脑中或写几行Python计算出来。使用Python交互环境将混淆代码片段复制到隔离的Python解释器中执行直接打印出结果。编写小脚本自动化对于固定的混淆模式如所有字符串都经过xor 0x42编写脚本批量还原。5.2 对抗技巧二代码自修改与运行时生成现象部分关键代码不是在脚本中写死的而是在运行时通过exec、eval或types.FunctionType动态生成的。# 示例运行时生成函数 code_str def malicious():\n import os\n os.system(calc.exe) dynamic_code compile(code_str, string, exec) exec(dynamic_code) malicious() # 动态生成的函数被调用应对动态调试在沙箱或调试器中运行到生成代码的位置然后检查生成的变量或命名空间。可以将exec(dynamic_code)改为print(dynamic_code)或检查locals()的变化。Hook关键函数在分析环境中可以临时重写exec、eval、compile函数让它们打印出输入的源代码字符串然后再执行原功能或直接跳过执行。import builtins original_exec builtins.exec def my_exec(source, globalsNone, localsNone): print(f[HOOK exec] 即将执行:\n{source}\n---) # 如果想阻止执行可以在这里return return original_exec(source, globals, locals) builtins.exec my_exec # 然后导入或运行可疑脚本5.3 对抗技巧三环境检测与沙箱逃逸现象样本会检测运行环境如在虚拟机、沙箱、调试器中或检查特定文件、进程、网络配置如果发现是分析环境则改变行为或直接退出。# 示例简单的沙箱检测 import os if os.path.exists(rC:\Windows\System32\vmware.exe): exit() # 检测到VMware退出 if debugpy in sys.modules: do_nothing() # 检测到VSCode调试器不执行恶意操作应对静态分析识别检测点仔细阅读还原出的代码找到if判断、try-except、os.path.exists、sys.modules检查等位置。环境模拟/补丁修改分析环境移除或绕过检测。例如在调试时临时修改os.path.exists函数的返回值。或者直接修改还原后的源代码注释掉检测相关的代码块。全系统仿真分析使用更高级的沙箱或仿真系统如QEMU来运行样本这类环境更难被检测。5.4 对抗技巧四多层嵌套与递归加载现象样本解密出的代码其功能仅仅是下载或解密下一阶段的负载形成“永无止境”的套娃。应对网络流量拦截在隔离环境中运行样本并配置透明代理如Burp Suite、Fiddler或使用mitmproxy拦截所有HTTP/HTTPS请求获取下一阶段Payload的下载地址和内容。文件系统监控使用ProcMonWindows或strace/inotifyLinux监控样本进程创建、写入的文件从而捕获它释放的下一阶段组件。设定分析深度阈值手动或自动分析时设定一个最大递归解压/解密层数比如10层防止陷入无限循环。通常真实的恶意负载会在3-5层内出现。6. 完整实战案例复盘让我们串联起所有步骤复盘一个虚构但典型的案例invoice.zip。初始文件invoice.zip。file命令显示为ZIP。解压得document.tar.gz。第一层解压解压tar.gz得payload.enc。file命令显示为data。strings查看发现末尾有提示base64。第二层解码base64 -d payload.enc stage1.py。得到Python加载器。分析加载器stage1.py内含经过zlib压缩和xor 0xAA混淆的marshal数据。编写脚本复制其解密逻辑但将最后的exec(code_obj)改为marshal.dump(code_obj, open(core.marshal, wb))。提取字节码运行修改后的脚本得到core.marshal。反编译使用uncompyle6反编译core.marshal成功得到清晰的Python源代码final_payload.py。分析恶意行为阅读final_payload.py发现其功能是从C2服务器hxxp://evil-c2[.]com/config下载一个配置文件根据配置在本地持久化写入启动项并窃取浏览器Cookie和加密货币钱包文件打包后上传。安全取证记录下C2地址、持久化路径、窃取的文件路径等指标IOCs用于威胁情报和系统排查。在整个过程中最耗时的部分往往是分析混淆的加载器逻辑和应对各种反分析技巧。耐心、细致的代码阅读和灵活的脚本编写能力是关键。7. 防御视角如何让你的代码免遭类似分析作为开发者了解攻击手法也是为了更好地防御。如果你的代码包含敏感逻辑如许可证校验、算法核心并希望增加逆向难度可以借鉴一些混淆思路但请注意没有绝对不可逆的混淆只能增加成本。代码混淆使用PyArmor、PyInstaller打包成二进制等工具进行商业级混淆和加密。核心逻辑下沉将最关键的计算逻辑用C/C编写编译成.pyd或.so扩展模块。远程验证将核心授权或逻辑放在服务器端客户端只做调用。完整性校验对自身文件进行校验防止被调试器修改。但务必权衡过度复杂的混淆会影响代码可维护性、运行性能并可能引发安全软件误报。对于绝大多数应用合理的代码架构和商业授权协议比技术混淆更有效。最后记住分析恶意样本的第一原则永远在隔离、无害的环境中进行。每一次成功的“剥洋葱”不仅是一次对威胁的化解更是对Python语言机制和攻击者思维的一次深度理解。保持好奇保持谨慎。