一个 0 字节的载荷 归档里翻到这么个东西： 35shutdown/ .gitkeep 0 B &shutdown -s -t 360&/ .gitkeep 0 B 新建文件夹/ &shutdown -s -t 360&.zip 474 B &shutdown -s -t 360&/&shutdown -s -t 360&/ &shutdown -s -t 360& (2)/&shutdown -s -t 360&/ 整个目录 1 KB，唯一的非零字节是那个 474 字节的 zip。把 zip 拆开： ...
起因 归档里翻到一条书签，350 字节，正文就一行自己的话： 代码没有实际价值，被抹消了。 下面配了一张 CVE2025-31200.py 的截图。 我当时随手记了一句，没细看。这次把它放大逐行读完，发现「没有实际价值」这个评价还是太客气了——它不是被抹消了价值，它从来就没有过价值。而且顺着它摸到的那个 GitHub 仓库，比这段代码更能说明问题。 所以这篇讲两件事：这两份东西分别假在哪，以及怎么用三十秒判断一个「PoC」值不值得点开。 展品 A：一段只会 print 的利用代码 把它抄出来读，一共三块。 第一块，“payload”： malicious_audio = b'\x00' * 1024 * 1024 1 MB 的空字节。真正的音频解码器溢出，畸形之处在于 codec 参数、帧结构、长度字段——需要按目标格式精心构造。一百万个零不是构造物，是占位符。 ...
新样本 优先使用静态分析，那就先获取足够的信息再说吧。 用户名没有特别信息，反间谍软件吗，这个取名有点意思。 检查字符串，发现大量数据库相关代码 不太正常，很像一个普通软件，可能是被中木马了。 使用的数据库类型是SQLite 找到官网，看看源文件。 在看源文件之前发现一件神奇的事情： 数字签名正常，签名时间，啊？昨晚？ 这么新鲜的样本吗，而且数字签名正常也离谱。 获取的样本版本低了官网两个迭代版本。 ok，没事了。 ...
新样本 又是资源解密类型的样本，看看ida 哦？64位的样本，罕见。 根据提示，寻找加密内容 84是最大的，长度为6AB。 断一下loadResource，检查长度为6AB的资源读入。由于手比较快，没有记录下来。 ida跟随，得到程序包装的loadRes+resSize+malloc+memcpy一套组合拳 获取v5，然后断v5的内存。 读写命中，ida跟随。 这个子函数，有点像解密函数？ 啊？就结束了？有点突然啊 不急着惊喜，先检查一下解密后输出的是啥，确定一下先 本来想着先跳到解密后的内容，再查看输出到哪里的，结果是原地输出。 ...
新样本 或者也叫老样本VirusTotal - File - d95eb625d766c959d7026f3537dc3bf17bb90063cc6480507e6b28bb74a069b6 以及神秘的东方拼音和东方文字。 体验正常安装 反正有快照，作一下 有点看不懂这个软件是干啥的，没有一点提示吗 虽然也有这个程序其实没什么用但是套了个壳子反正都能装一个病毒的想法。 但是病毒究竟是不是这个程序可能还未可知。 也有一种操作是正常安装一个没用的软件，然后真正的病毒悄悄的在其他地方释放。 不管怎么说还是得首先排除这个可能性的 追踪安装 ...
NSIS解包 学长让我把解包工具都下一遍，终于也是有用了。7z解包只能看到插件看不到nsi文件。 不过还是得自己手动跑一遍手解。 起码我知道了最后解包出来应该长什么样 一个7z直接调用接口解压，另一个纯文本去里面找。 不过看起来没那么简单，那就来看看吧。 前面固定套路就几句话带过好了，不记了，懒。 断点 LoadLibEx 静态查找函数入口 找到install作为dll被调用的唯一函数，调用完毕后直接freeLib，所以只看install就好了 结合之前解包出来的脚本查看。 使用的解压方法：RtlDecompressBuffer 关键解压函数：sub_69C2B110 用简单粗暴的方式得到了压缩buf在内存中的地址，回头再来分析这个地址是从哪里来的，this看得我头昏眼花。 ...
这篇的边界先划清 第五次课的作业，四条课程目标： 1、了解带脚本的安装包基本结构和执行流程特点。 2、获取内部资源解压算法并还原安装包内部的脚本。 3、寻找该类安装的特征识别算法。 4、通过代码实现包识别和解包流程。 对象是真实恶意样本（杀软报 BAT/Ransom.BleachGap 一类的勒索投放器）。所以这篇的取舍是明确的： 函数地址、密钥、算法、手法，全都不脱敏。 恶意软件没有软件版权，把 key 藏起来只会让这份分析和这份代码都无法复核，那才是真的没意义。 载荷内容一行不放。 解出来的脚本、它的标签名、具体命令行，一律不贴。 这篇也不放截图。 OD 和 IDA 的截图恰恰是脚本内容最容易一整屏漏出去的地方，而讲方法不需要那个。 样本本体在仓库里，是 tagent 签名、用我公钥加密的容器，只有我能解开，但任何人都能验证它是我交付的那一份。 ...
上木马！ 听有个朋友说他挨了病毒，我看看怎么个事。 初次分析 先镜像，然后ida丢进去看一眼，没条理，双击一下逝逝，没反应 上火绒剑，只执行了一小部分就开始睡觉了 没读写关键目录，没创建子进程避免读日志，还真就在睡觉？ 一个笑话：未发现风险。 vt的报告里面除了联网以外也没见有做什么特别的事情，倒是一堆的反沙箱和虚拟机。 看来是被检查到了，得绕过一下。。。 喜欢翻字符串，刚刚试着运行后暂停回滚堆栈跳出循环，然后程序直接一步到底了，也没见发作。 这串字符串有点奇怪 因此紧接着，引用它的这串代码也有点奇怪。记录下来了。 但是太多了，分析不过来。 没见可读的字符串，不是勒索软件，联网也没进行，这个应该是检测到沙箱了，vt是有说联网的。 看来还是得先破他的沙箱检查。 ...
x64模式下 简易代码，定义tmp、tmp1、tmp2，tmp1和2将tmp分割为两部分。 在x64 debug下编译，发现tmp的长度从20变成了0x48，大小识别错误了。 但这没有太大的影响，也只是反应了ida的小错误而已。 但是在x86模式下会变成另一种情况 char20被断成一节节了，每个Int占4，那么v5(8)+v6(4)+v7(4)+v8(1)=17仍然小于20。 也就意味着ida把变量大小识别错误了，这在特定情况下会是致命的 探针工程（main() 与手抄回来的 main_0() 互为对照，x64/x86 两种配置）：https://cnb.cool/t1mmoc/tspace/pwngore/h11ida-size-probe 同一个错误的另一副面孔 —— sizeof(buf) 拿到的是指针宽度而不是文件长度 —— 见《没有源码时怎么找到主流程：一个带脚本的安装包》。
样本长什么样 526 行，277,699 字节。打开第一屏是这样的： @echo off %KPjSTBxCcolpNEgJWbqf%s%KPjSTBxCcolpNEgJWbqf%e%KPjSTBxCcolpNEgJWbqf%t%KPjSTBxCcolpNEgJWbqf%l%KPjSTBx... set "cblMLttYimYYgdCCrjSR=s" set "ksfjvFgWRcXVFNdVgrjk=t" set "XufOtBOOdJXCdrpMmnJU=!cblMLttYimYYgdCCrjSR!e!ksfjvFgWRcXVFNdVgrjk!" 人眼看到的是噪声，但两件事已经能读出来了：变量名全是随机大小写混合串，而且变量之间会互相引用（第三个 set 的值里套着前两个）。 先做一个最省事的动作：看体积集中在哪一行。 数出来是第 141 行，248,924 个字符——全文 90% 的体积在这一条行上。这个比例本身就是结论：一个正常的启动脚本不可能有 25 万字符的单行。后面会看到它是什么。 ...