某Vape LiteV3.4.2破解版的账户窃取分析

在论坛中发现了该样本，帖子使用了Codex分析，但某绒的人工分析结果是无恶意行为，于是对其进行分析

原贴分析行为：

加载器分析

静态分析

Loader.exe

新鲜日期的64位程序，没有保护

根据Codex的分析，该文件中有个a.class

我们使用IDA分析该文件，定位到了主函数中，启动了一个线程，调用了DefineClass，但是这些指向的buf没有找到类文件的特征，甚至没有找到指向内容，于是决定动态调试

dump class文件

搜索字符串找到对应引用位置，下断点运行

单步跟到框处函数处

该函数的返回值是明显的CLASS文件魔数特征，发现这里有一个循环，反复调用了该函数

在该循环条件终止时，定位到类文件对应内存空间位置

将这一块内存都dump出来

得到这样的文件：

按照魔术头分隔，用asm修复一下

得到7个类文件

类文件分析

静态分析

a.class中有一个不能反编译的方法，让我们详细看看它：

由于是ZKM25，翻了翻没有什么现有的反混淆器

于是顶着indy混淆手动翻一翻，毕竟INVOKESPECIAL这种用不了indy

观察到Socket创建

压缩文件的输出流，不过用的是字节流直接输出，意味着不落地

说明可能是创建压缩文件通过Socket传输到外部

动态调试

反射调用a函数

把提取的jar作为库导入idea项目

创建一个default包的类，在这里调用a.a

由于ZKM混淆器的renamer使得存在命名重复签名不同的方法，从而不能直接调用，只能使用反射调用

public static void main(String[] args) throws Exception {
    System.out.println(a.class);
    Method[] methods = a.class.getDeclaredMethods();
    for (Method method : methods) {
        method.setAccessible(true);
        if (method.getName().equals("a") && Modifier.isStatic(method.getModifiers()) && method.getParameters()[0].getType() == long.class) {
            System.out.println("ssss");
            
            method.invoke(null, 15186841654917L);
            
            System.out.println("hello");
        }
    }
}

这样可以定位到唯一的方法，从而调用指定方法。

ZKM混淆添加的这个方法参数是暴力测出来的，代码如下：

while (true) {
    try {
        invoke = method.invoke(null, sbs[sb1]);
    } catch (InvocationTargetException e) {
        System.out.println(sb1++);
        continue;
    }
    System.out.println(sbs[sb1]);
}