吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 74309|回复: 271
上一主题 下一主题
收起左侧

[Android 原创] 扒尽手游的底裤——Cocos2dx与LuaJIT完全解密

    [复制链接]
跳转到指定楼层
楼主
ttimasdf 发表于 2017-11-18 01:31 回帖奖励
本帖最后由 ttimasdf 于 2017-11-18 16:41 编辑

为了满足收集欲,想要拿下某个卡牌类游戏的所有立绘。在逆向的过程中,开拓了一些前人没有发掘的领域,无论是中文还是英文都没有相应的资料。本文证明了,即使Lua源码被编译过,也不是绝对的安全。厂商们打的小算盘可能是——没有成熟的工具,不好破解。但是对于了解原理的安全研究者,这不是问题。反而对于不了解原理,着重于快速开发复用代码的游戏开发者来说,没有成熟的防护体系,无论是自己造轮子还是用别人的轮子,造成的威胁都会更大。

由于不知道会有什么影响,担心会让抄袭之风来的更快,在此有选择性的隐去一些非关键源码和细节,但是思路都在这里一点没有删减,权当自己的笔记和对游戏厂商的警醒。我们开始咯~

先上一张解密后的样图。

玩过的童鞋可能一眼就能认出来,嘿嘿嘿。游戏名叫妖萌战姬,游戏本身我不多作评价。本文所分析的版本为官网下载20170922版本,截至本文发布时为官方最新版。

编译修改Luajit-lang-toolkit

解包后发现所有的png资源全部加密了打不开(嘿,但是音频还没有加密……不过并不会有人看嘛)。结合lib发现游戏是cocos2x与Lua编写。虽然Lua出了名的好逆,但是查看文件头后发现是编译后的LuaJIT……还是最新的2.1版。一番操作后找到一个项目 luajit-lang-toolkit(以下简称LLT),不过用起来有点小问题。make以后在src文件夹生成了luajit-x程序,与luajit的命令行工具参数一样。

$ luajit-x -bl main
-- BYTECODE -- main:0-0
0001    TGETV    1   0   0
0002    KSHORT   2   1
...
0020    KSHORT   2   1
0021    ITERN    1   1   2
0022    FORL     0 => -32744

-- BYTECODE -- main:0-0
0001    TDUP     0   0
0002    TGETS    0   0   1  ; "__G__TRACKBACK__"
0003    KPRI     0 500
...
0072    TGETS    0   0  19  ; "LAUNCHERPKG"
0073    TGETV    0   0  26
0074    KSHORT   1  30
0075    ITERN    0   2   2
0076    TSETV    0   0  31
0077    ITERN    0   2   1
0078    UNM      1   0
0079    TSETV    0   0  32
0080    ITERN    0   1   2
0081    FORL     0 => -32685

我们可以看到……啥也看不到……但是官方命令行工具的反汇编结果却大有不同。

你看人家至少有个RET啊!

$ luajit -bl main
-- BYTECODE -- main:0-0
0001    GGET     1   0      ; "print"
0002    KSTR     2   1      ; "----------------------------------------"
0003    CALL     1   1   2
...
0019    GGET     1   0      ; "print"
0020    KSTR     2   1      ; "----------------------------------------"
0021    CALL     1   1   2
0022    RET0     0   1

-- BYTECODE -- main:0-0
...
0043    KSTR     0  18      ; ""
0044    GSET     0  19      ; "LAUNCHERPKG"
0045    GGET     0  13      ; "cc"
0046    TGETS    0   0  20  ; "LuaLoadChunksFromZIP"
0047    KSTR     1  21      ; "lib/"
0048    GGET     2   3      ; "GAME_BIT"
0049    KSTR     3  22      ; "/launcher.zip"
0050    CAT      1   1   3
0051    CALL     0   1   2
0052    GGET     0  23      ; "package"
0053    TGETS    0   0  24  ; "loaded"
0054    GGET     1  19      ; "LAUNCHERPKG"
0055    KSTR     2  25      ; "launcher.launcher"
0056    CAT      1   1   2
0057    KPRI     2   0
...
0073    GGET     0  26      ; "require"
0074    KSTR     1  30      ; "app.MyApp"
0075    CALL     0   2   2
0076    TGETS    0   0  31  ; "new"
0077    CALL     0   2   1
0078    MOV      1   0
0079    TGETS    0   0  32  ; "run"
0080    CALL     0   1   2
0081 => RET0     0   1

直接撸汇编可以,但是LLT可以解析更多的东西,怎么办?我仔细参考了一下opcode表,发现很多指令与正确指令之间在指令表之间(比如第一行的TGETVGGET)只有两个指令的距离。再翻了翻LLT的issues里面有提到了2.1版本,某人还为他写了个patch。我才明白——因为2.1的指令表与2.0相比,中间插入了两个指令,因此后面的指令在表中的位置都相应后挪。

我完善了一下这个patch,将更新的指令表加入了读写过程中,修改后的版本位于我的Github中的v2.1分支。运行修改后的版本输出就正常了。

$ luajit-x -bxg main
1b 4c 4a 02             | Header LuaJIT 2.0 BC
02                      | Flags: BCDUMP_F_STRIP
                        | .. prototype ..
b6 01                   | prototype length 182
00                      | prototype flags None
01                      | parameters number 1
05                      | framesize 5
00 08 00 16             | size uv: 0 kgc: 8 kn: 0 bc: 23
                        | .. bytecode ..
36 01 00 00             | 0001    GGET     1   0      ; "print"
27 02 01 00             | 0002    KSTR     2   1      ; "---------------
                        | -------------------------"
42 01 02 01             | 0003    CALL     1   1   2
...
36 01 00 00             | 0019    GGET     1   0      ; "print"
27 02 01 00             | 0020    KSTR     2   1      ; "---------------
                        | -------------------------"
42 01 02 01             | 0021    CALL     1   1   2
4b 00 01 00             | 0022    RET0     0   1
                        | .. uv ..
                        | .. kgc ..
05                      | kgc: ""
0e 74 72 61 63 65 62 61 | kgc: "traceback"
63 6b                   | 
0a 64 65 62 75 67       | kgc: "debug"
06 0a                   | kgc: "\
...
15 5f 5f 47 5f 5f 54 52 | kgc: "__G__TRACKBACK__"
41 43 4b 42 41 43 4b 5f | 
5f                      | 
00                      | kgc: <function: main:0>
                        | .. knum ..
00                      | eof

这个工具可以列出文件的hexdump与子程序的栈帧、局部变量等信息,是我特别心水的地方。下面进入逆向部分。

首先先把所有字节码反汇编并保存至src目录。在命令行中运行

ls | xargs -I% sh -c 'echo "Processing %" && luajit-x -bxg "%" > "src/%.lasm"'

查看PNG头发现字样img.libla,在png以外的文件里查找此字符串

$ grep libla . -R | grep -iv png
Binary file ./lib/armeabi/libcocos2dlua.so matches

如此看来解密过程应该就在libcocos2dlua.so中。先拖IDA里让它分析起来。好吧勉强承认一下南辕北辙了(没事Lua部分后面用到)。

分析libcocos2dlua

在这个so文件里搜索img.libla 定位到函数cocos2d::Image::isMpi(uchar const*,int) 。去cocos2d-x官方文档里查询了一下竟然连Image这个类都没有。感觉不太可能,翻2.x版本的文档找到了对应的类CCImage,一直往后翻发现3.4是最后一个拥有这个类的版本。在字符串里搜一下3. 找一下有没有具体版本,有了意外发现。

.rodata:0119FB8B 0000004D C E:\\MyWorkSpace\\ACGProj\\cocosEngine\\Quick-Cocos2dx-361\\/cocos/./math/Vec3.cpp

噫~原来是用了框架。在GitHub上找到这个框架,作者表示选择了“公认最稳定的版本”3.3。 其实就是懒得学新API了吧。 随便搜一搜还能找到很多有意思的加密方式(见参考资料)。我们开心的开始带源码作业。但是简单搜索后却发现源码里根本没有这个函数。我们回到IDA中,查看调用这个函数判断文件类型的地方。

signed int __fastcall cocos2d::Image::detectFormat(cocos2d::Image *this, const unsigned __int8 *a2, int a3)
{
  cocos2d::Image *v4; // [sp+4h] [bp-14h]@1
  int v5; // [sp+8h] [bp-10h]@1
  unsigned __int8 *v6; // [sp+Ch] [bp-Ch]@1
  signed int v7; // [sp+14h] [bp-4h]@2

  // ...省略...
  else if ( cocos2d::Image::isATITC(v4, v6, v5) & 1 )
  {
    v7 = 7;
  }
  else if ( cocos2d::Image::isMpi(v4, v6, v5) & 1 )
  {
    v7 = 10;
  }
  else
  {
    cocos2d::log("cocos2d: can't detect image format", &GLOBAL_OFFSET_TABLE_);
    v7 = 11;
  }
  return v7;
}

而调用这个函数的地方附近又是这样。

int __fastcall cocos2d::Image::initWithImageData(cocos2d::Image *this, const unsigned __int8 *a2, int a3)
{
  // ... 解压被压缩的图片数据
        v6 = cocos2d::Image::detectFormat(v8, (const unsigned __int8 *)v11, (int)v10);
    }
    *((_DWORD *)v8 + 10) = v6;
    if ( v6 > 0xA )
    {
      // ... 未知格式错误处理
    }
    else
    {
      switch ( v6 )
      {
        case 1u:
          v12 = cocos2d::Image::initWithPngData(v8, (const unsigned __int8 *)v11, (int)v10) & 1;
          break;
        case 0xAu:
          v12 = cocos2d::Image::initWithMPIData(v8, (const unsigned __int8 *)v11, (int)v10) & 1;
          break;
        case 0u:
          v12 = cocos2d::Image::initWithJpgData(v8, (const unsigned __int8 *)v11, (int)v10) & 1;
          break;
        case 2u:
        //... 

于是我们的目的就明确了——开发者魔改了cocos2d::Image::initWithImageData加入了自己的文件格式,并在 detectFormat 识别格式时调用 isMpi 判断并指定输入文件是否为自己的私有文件格式,然后自己写了一个initWithMPIData并在其中进行了解码或解密操作。我们要做的就是解析或利用这个函数的反向过程来解密图片资源。

以直接调用方式绕过资源加密

开始我尝试了用unicorn-engine模拟运行。但是后来发现函数里调用了malloc等标准库函数,处理起来很麻烦。IDA调试的选项也被我pass掉了,结合cocos2dx在CCImage.cpp中对图片的处理过程可知,内存里面存的是原始的RGBA数据,即使做出来内存dump也卵用无。折腾两天后决定利用NDK自己写一个wrapper,利用这个函数已导出的特性,从so里面获取这个函数并调用它来为我们解密。

我们先从已有代码入手判断一下Image类的结构。结合一下 CCImage.hCCImage.cppcocos2d::Image::initWithPngData 与其在IDA中反汇编的对应关系整理如下。

class CC_DLL Image : public Ref
{
        static const int MIPMAP_MAX = 16;
    unsigned char *_data;  // *(this_ + 20)
    ssize_t _dataLen;  // *(this_ + 24)
    int _width;  // *(this_ + 28)
    int _height; // *(this_ + 32)
    bool _unpack;  // *(this_ + 36) 来自初始化函数,实际并未读写
    Format _fileType;  // *(this_ + 40)
    Texture2D::PixelFormat _renderFormat;  // *(this_ + 44)
    MipmapInfo _mipmaps[MIPMAP_MAX];   // *(this_ + 48) pointer to mipmap images
    int _numberOfMipmaps;  // *(this_ + 176)

    // false if we cann't auto detect the image is premultiplied or not.
    bool _hasPremultipliedAlpha;  //  *(this_ + 180) 在一个判断后可能读写
    std::string _filePath;

其中要注意,这里一定要打开IDA的Show casts显示强制类型转换,例如*((_DWORD *)this + 6) = 4 * v5;这一句中实际被赋值的成员变量的偏移量不是6个字节而是6*DWORD=24字节。

我们据此编写这个对象的测试用例

class Image {
public:
    int __stub1[5];
    unsigned char *_data;  // *(this_ + 20)  wr
    int _dataLen;  // *(this_ + 24) w
    int _width;  // *(this_ + 28)  wr
    int _height; // *(this_ + 32)  wr
    int __stub2;
    int _fileType;  // *(this_ + 40)
    int _renderFormat;  // *(this_ + 44)  w (read in ::hasAlpha)
    char __stub3[132];  // 180-44-4
    bool _hasPremultipliedAlpha;  //  *(this_ + 180) possible w
};

// ...
printf("Image layout:\n"
           "_data: %d\n"
           "_datalen: %d\n"
           "_width: %d\n"
           "_height: %d\n"
           "_fileType: %d\n"
           "_renderFormat: %d\n"
           "_hasPremultipliedAlpha: %d\n",
           offsetof(Image, _data),
           offsetof(Image, _dataLen),
           offsetof(Image, _width),
           offsetof(Image, _height),
           offsetof(Image, _fileType),
           offsetof(Image, _renderFormat),
           offsetof(Image, _hasPremultipliedAlpha)
           );

经NDK编译在armv7设备上运行结果如下(如果编译遇到缺标准库问题,在Application.mk里指定一下GNU C++运行时即可)

Image layout:
_data: 20
_datalen: 24
_width: 28
_height: 32
_fileType: 40
_renderFormat: 44
_hasPremultipliedAlpha: 180

bingo~由于里面的成员变量都是int或指针一类的东西,所以不怎么需要考虑对齐的问题。如果有问题的话参考一下下面参考资料里的ARM文档。

然后就是编写程序了。C++类成员函数在编译时被mangle成一个乱乱的字符串,在IDA里或objdump都可以获得,原样拿来并用dlsym寻找函数指针,用我们伪造的Image类作为第一个参数的this指针调用即可。至于如何将Image对象的内容保存为png,这个就留给大家作为思考题,方法是类似的。伸手党我们都是拒绝的。

注意,这里没有写但是我已经提前分析过我们要调用的函数对Image类的读写状况,对成员变量的所有操作都是先写入再读取,不存在未初始化的情况。如果大家要用类似方法调用其他函数,也要注意传入的数据成员的值。

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <dlfcn.h>
#include "CCImage.h"

#define assert(cond, err) if (!(cond)) {printf(err);exit(1);}

typedef bool (*initWithMPIData_t)(Image*, char *, ssize_t);
const char* initWithMPIData_mangled = "_ZN7cocos2d5Image15initWithMPIDataEPKhi";

int main(int argc, char** argv) {
    assert(argc > 1, "usage: decrypt [encrypted_png]\n");

    Image *img = new Image();

    FILE *f = fopen(argv[1], "rb");
    assert(f != NULL, "File not exists!");

    fseek(f, 0, SEEK_END);
    long fsize = ftell(f);
    printf("Source file size: %ld\n", fsize);
    fseek(f, 0, SEEK_SET);

    char *buf = (char *)malloc(fsize + 1);
    fread(buf, fsize, 1, f);
    buf[fsize] = 0;    
    fclose(f);
    assert(!memcmp(buf, "img.libla", 9), "File already decrypted~~\n");

    void* handle = dlopen("/data/local/tmp/libcocos2dlua.so", RTLD_LAZY);
    assert(handle != NULL, "libcocos2dlua.so missing or corrupted!\n");

    initWithMPIData_t initWithMPIData_ptr = (initWithMPIData_t) dlsym(handle, initWithMPIData_mangled);

    assert(initWithMPIData_ptr != NULL, "Image::initWithMPIData not found\n");
    printf("Image::initWithMPIData found at: %p\n", initWithMPIData_ptr);

    initWithMPIData_ptr(img, buf, fsize);
    printf("Decrypted image %d x %d, raw size %d.\n",
        img->_width, img->_height, img->_dataLen);

        // 留给大家的思考题

    return 0;
}

push到手机上运行一下。顺便一提,1.out.png和1.png的大小是完全一样的。说明这个算法完全可逆。就是我懒而已……

$ ./decrypt assets/res/photo/imgs/normal/1.png
Source file size: 92363
Image::initWithMPIData found at: 0xe8185854
Decrypted image 488 x 720, raw size 1405440.
Saving to assets/res/photo/imgs/normal/1.out.png

OK,然后用shell脚本批量处理一下就可以把所有文件都解密掉了。接下来我们要做的就是,将每个图片与他的角色匹配起来,顺便看一看能不能挖掘出其他的信息。

LuaJIT探幽

这是一个三国题材的游戏,我们搜索关键字“赵云”,定位到类 app.data.db.cardDef 。这里再赞一下LLT,kgc和knum信息都是官方工具无法dump出来的。而官方文档又晦涩难懂(还一堆TODO干脆就是没写完),稍微好一点的教材就是LLT对字节码解析过程的源代码了。

在这里就结合一下例子来解释一下 LuaJIT 生成的二进制文件格式。看最左边的hex与右侧的数字注释

1b 4c 4a 02             | Header LuaJIT 2.0 BC                                | 1
02                      | Flags: BCDUMP_F_STRIP                                | 2
                        | .. prototype ..
ce b9 16                | prototype length 367822                        | 3
02                      | prototype flags PROTO_VARARG                | 4
00                      | parameters number 0                                | 5
03                      | framesize 3                                                | 6
00 99 02 00 85 06       | size uv: 0 kgc: 281 kn: 0 bc: 774        | 7
                        | .. bytecode ..
34 00 00 00             | 0001    TNEW     0   0
35 01 00 00             | 0002    TDUP     1   0
3e 01 01 00             | 0003    TSETB    1   0   1
..... 此处省略770行,都是汇编
4c 00 02 00             | 0773    RET1     0   2
                        | .. uv ..
                        | .. kgc ..
01 00 63                | ktab narray: 0 nhash: 99                        | 8
0e 63 61 72 64 53 63 6f | ktabk string: "cardScore"
72 65                   | 
03 d0 0f                | ktabk int: 2000
  1. 3 bytes固定头部"\x1bLJ",第四位02是bytecode版本,01为LuaJIT 2.0,02为LuaJIT 2.1。2.1版本目前没有官方文档,只能从代码略窥一二。区别见参考资料patch。
  2. flags定义参考LLT源码bytecode.luabc2
  3. 用ULEB128表示的不定长数字开始一个“节”(prototype,相当于一个函数定义)并指定节的长度,若读到0则认为文件结束。
  4. flag参考同上,1byte
  5. 参数数量,1byte
  6. 栈帧大小3 猜测与内存分配相关,1byte
  7. 此处四个数字分别为:
    1. uv: Upvalue来自调用者的变量,1byte
    2. kgc: 动态分配的变量数量(猜测,翻译是garbage collected?),可存储字符串(str*B指针)、数组(karray)或字典(khash),ULEB128
    3. kn: 常量,可理解为const,ULEB128
    4. bc: bytecode,汇编码条数(每条指令都是4bytes定长),ULEB128
  8. kgc格式:类型(字符串或数组/字典)1位,若类型为数组或字典。此处为01表示数组。
    1. 数组/字典(ktab)格式,在kgc类型后紧跟的2bytes
    2. narray:存储的数组元素个数(可理解为Python中的*args)
    3. nhash:存储的字典元素个数(可理解为Python中的**kwargs)
    4. 紧跟一串ktabk按上面两个值来计数。一个数组元素一个ktabk,一个字典元素两个ktabk
    5. ktabk的类型在LuaJIT的lj_bcdump.h文件的 BCDUMP_KTAB_XXX 枚举定义中。int为03,字符串为05加上字符串长度。此项类型为ULEB128

我解释的比较概括,更准确的定义需要参考官方文档上的范式。

我们可以看见,字节码格式非常紧凑,几乎没有浪费什么空间。而且不得不说,写程序解析原始字节码比读取LLT输出的文本要容易得许多……所以我写了一个。

下面的脚本用于解析LuaJIT产生的文件并将其中的常量信息提取到一个csv文件中。

#!/usr/bin/env python3
import sys
from pathlib import Path
import csv

target = Path("app.data.db.cardDef" if len(sys.argv) < 2 else sys.argv[1])

def readULEB128(file):
    result = offset = 0
    while True:
        byte = file.read(1)
        result += (byte[0] & 0x7F) << offset
        offset += 7
        if byte[0] < 0x80:
            return result

def readKtabk(file):
    type_ktab = readULEB128(file)
    assert type_ktab == 3 or type_ktab > 4, \
        "Unsupported ktab type {} at position {}".format(type_ktab, file.tell())
    if type_ktab == 3:
        return readULEB128(file)
    else:
        ret = file.read(type_ktab-5)
        try:
            return ret.decode()
        except UnicodeDecodeError as e:
            print("ERROR at pos", file.tell(), str(e))
        return ret.hex()

def main():
    with target.open('rb') as f:
        f.seek(5)                       # skip header
        length_total = readULEB128(f)   # read proto leng
        print("proto length", length_total)
        prototype_start_pos = f.tell()
        f.seek(4, 1)                    # skip flag, param, frame, uv
        num_vars = readULEB128(f)
        _ = readULEB128(f)              # kn not used
        num_bytecode = readULEB128(f)
        f.seek(num_bytecode*4, 1)   # skip bytecode

        kgcs = []

        for _ in range(num_vars):       # read one kgc per time
            type_kgc = f.read(1)[0]
            assert type_kgc == 1, \
                "Unsupported variable {} at {}".format(type_kgc, f.tell())
            print("== reading new one from", f.tell())

            narray = readULEB128(f)
            nhash = readULEB128(f)
            array = []
            hashes = {}
            for _ in range(narray):
                array.append(readKtabk(f))
            for _ in range(nhash):
                key = readKtabk(f)
                val = readKtabk(f)
                print("Reading key: ", key, "val:", val)
                hashes[key] = val

            kgcs.append(hashes or array)  # a ktab may only contain one

        assert f.tell() - prototype_start_pos == length_total, \
            "What happened?? file corrupted? at {}".format(f.tell())

        assert f.read(1)[0] == 0, "More prototypes following, I'm tired"

        print("Dump success!")

    with open("dumpinfo.csv", 'w') as csvfile:
        csvfile.write('\ufeff')
        writer = csv.DictWriter(csvfile, sorted(kgcs[0].keys()))
        writer.writeheader()
        writer.writerows(kgcs)

        print("dumped into dumpinfo.csv")

if __name__ == '__main__':
    main()

得到类似下面格式的csv。表头被我删去了。太长,丑。但是下面这一串信息里面已经包含了绝大多数我们可能需要的信息,包括角色攻击力、生命值、售价、技能ID、语音ID等等,甚至还有放大招的时候喊的口号。也有很大的潜力哦~

0,0,0,0,0,0,0,0,9,7,1,17,430,75,327,327,327,1,1,1,14500,14500,14500,65,0,2000,5,0,6,1250,0,90,240,道为核心   天道无为   道法自然  且善且行,3273,3,60,30,100,150,45,5,327,136,Y01,249,255,481,3272,130,1400,130,梦里繁花,3,75,左慈,0,0,0,0,35,240,5,0,0,3273,23,24,24,0,0,1,1,1,0,0,149,290,5,5,0,0,0,0,0,0,0,0,0,6,6,100,45,0,0,0,350,45,0
15,15,38,25,746,115,60,0,2,8,1,15,260,42,15,15,15,1,1,1,2500,2500,2500,120,0,1,2,1150,7,1300,600,124,232,什么  你说现在不流行用剑了?,0,0,0,0,0,180,60,5,15,150,S03,320,267,743,745,79,1500,140,,0,35,木鹿大王,0,0,0,0,120,246,5,0,0,747,0,13,14,15,15,0,1,1,1,1,110,232,0,4,0,0,0,0,0,0,0,0,0,4,4,500,60,0,0,0,150,60,0
15,5,37,10,744,130,35,0,2,8,1,15,260,42,15,15,15,1,1,1,2500,2500,2500,120,166,1,2,1150,5,1300,600,112,210,什么  你说现在不流行用剑了?,0,0,0,0,0,150,45,4,15,145,S03,290,230,743,743,50,1500,130,,0,45,木鹿大王,0,0,0,0,105,200,4,0,0,747,0,13,14,15,15,0,1,1,1,1,100,210,0,5,0,0,0,0,0,0,0,0,0,4,4,200,45,0,0,0,150,45,0
710,5,39,15,716,115,60,0,9,7,1,17,430,76,710,710,710,1,1,1,50000,50000,50000,150,0,2000,5,0,8,1350,0,237,286,尝尝这南蛮之地的烈火吧 ,0,0,0,0,0,260,65,6,710,165,M02,250,246,495,715,105,1500,145,含光剑 ,7,60,祝融,0,0,0,0,115,210,6,0,0,717,46,50,33,0,0,1,1,1,0,0,139,305,5,3,0,0,0,0,0,0,0,0,0,6,6,250,65,0,0,0,650,65,0
0,0,0,0,0,0,0,0,2,8,1,24,440,95,308,308,308,1,1,1,10000,10000,10000,165,185,400,2,1200,9,1300,1500,151,309,切...(无视)...,0,0,0,0,0,600,70,6,308,160,Y02,439,304,2308,352,91,2900,155,青龙偃月刀,1,60,关羽,0,0,0,0,160,309,6,0,0,352,0,39,17,18,18,0,1,1,1,1,139,312,2,4,0,0,0,0,0,0,0,0,0,4,4,600,70,0,0,0,500,70,0

搜索一下文首配图的文件编号2308,找到大概在关羽那行的第……呃……58列。当然这列有名字就叫icon,而名字顾名思义列名就叫name。继续祭出python把解密输出目录中所有名字中含编号的文件批量重命名。

import csv
from pathlib import Path

with open("dumpinfo.csv") as csvfile:
    reader = csv.DictReader(csvfile)
    for row in reader:
        icon = row['icon']
        name = row['name']
        for f in Path().rglob(icon+'.png'):
            f.rename(f.with_name('{}-{}.png'.format(icon, name)))

大功告成!

这部分是弄完了,但是学无止境嘛~好了我学PIL去了,再把图切切剪剪做个卡牌合集去(逃

防护措施

  • 加壳反制静态分析。
  • 不要导出敏感函数。
  • 增加加密函数上下文依赖性。(划重点)
  • 混淆。(有成熟方案吗?)

参考资料



免费评分

参与人数 120吾爱币 +116 热心值 +119 收起 理由
12xf + 1 + 1 求技术支持 QQ32488885
sxgcb + 1 + 1 用心讨论,共获提升!
ZRC110 + 1 热心回复!
lct2000 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
SuperZc + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
welsonzhu + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
love1983year + 1 + 1 我很赞同!
迷之裙摆 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
hyc120500 + 1 + 1 大神就是厉害
黑色的牛 + 1 我很赞同!
LLshowpin + 1 谢谢@Thanks!
SomnusXZY + 1 + 1 热心回复!
zamliage + 1 + 1 果然是大神啊!
Likey + 1 + 1 一本正经的看完,一脸蒙蔽的离开
zhuzaiting + 1 + 1 谢谢@Thanks!
xxzj990 + 1 + 1 不明觉厉
劣酒先生 + 1 + 1 我很赞同!
Halry + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
孤梦拾遗 + 1 + 1 热心回复!
烟火撩人 + 1 + 1 一脸懵逼
aipanpann + 1 + 1 热心回复!
每周三帖 + 1 我很赞同!
niconico128 + 1 + 1 我很赞同!
puluter + 2 + 1 我很赞同!
52pojie3009 + 1 + 1 谢谢@Thanks!
Prider + 1 + 1 感谢您的宝贵建议,我们会努力争取做得更好!
jacklee2014 + 1 + 1 谢谢@Thanks!
有梦想的男银 + 1 + 1 已答复!
cxfzaysb + 1 + 1 我很赞同!
jacky520510 + 2 + 1 热心回复!
15926574863 + 1 热心回复!
Link土豆 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
QingTianGG + 1 + 1 谢谢@Thanks!
tomcath + 1 + 1 用心讨论,共获提升!
153153 + 1 + 1 热心回复!
不懂破解 + 2 + 1 看不懂的一律加分
zhaojunkai + 1 + 1 谢谢@Thanks!
EddieZzz + 1 用心讨论,共获提升!
whlvd + 1 + 1 道路漫长,还有你我/
行思无疆 + 1 + 1 谢谢@Thanks!
xlfgh + 1 + 1 我看不明白,所以觉得厉害
q502986650 + 1 + 1 已答复!
只手过河 + 1 + 1 谢谢@Thanks!
mxh372100 + 1 + 1 热心回复!
吾2破解 + 1 + 1 我很赞同!
Amor残梦 + 1 + 1 我很赞同!
llalone + 1 + 1 我很赞同!
很快再相见123 + 1 + 1 我很赞同!
长大以后 + 1 + 1 谢谢@Thanks!
落花看花落 + 1 + 1 愣~是没看懂~感觉好~NB
小枫丶 + 1 + 1 用心讨论,共获提升!
Orizh + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
sunnylds7 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
昨天的梦 + 1 + 1 我很赞同!
zctsir + 1 我很赞同!
芝士就是力量 + 1 我很赞同!
lonely_coder + 1 + 1 谢谢@Thanks!
308biye + 1 + 1 鼓励转贴优秀软件安全工具和文档!
Kainarx + 1 + 1 谢谢@Thanks!
laughingsir38 + 1 + 1 学习了 大神
瑞銘 + 1 + 1 我很赞同!
pzhzijc + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
lm180180 + 1 + 1 谢谢 @Thanks!
南国十三 + 1 + 1 用心讨论,共获提升!
海底总动员 + 1 我很赞同!
幻辰 + 1 + 1 可以的 强
soyiC + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
cr7890 + 1 + 1 谢谢@Thanks!
InternetDog + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
天下客 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
kingtod + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
未来时 + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
yuridexiaoyu + 1 + 1 谢谢@Thanks!
梦儿小虐 + 1 + 1 我很赞同!
lokey + 1 + 1 谢谢@Thanks!
no_one + 1 + 1 热心回复!
gelei52166 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
疯狂醉虎 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
lovenexon + 1 + 1 厉害了我的哥,加油加油给大家带来好的作品!话说资源可以放出来不
流年回忆 + 1 + 1 感谢发布原创作品,吾爱破解论坛因你更精彩!
soulovess + 1 + 1 我很赞同!
TMD2017 + 1 + 1 用心讨论,共获提升!
pk8900 + 1 + 1 I fule YOU!崇拜~~~~~
hf5240376 + 1 + 1 一本正经的看完,一脸蒙蔽的离开
sec0ces + 1 + 1 虽然还没研究过,但感觉很厉害的样子!
qaz003 + 1 + 1 大虾。。你吓到我了。。。
snccwt + 1 + 1 热心回复!
zhoulinxxxxx + 1 + 1 用心讨论,共获提升!
wbr90 + 1 + 1 热心回复!
DFFJZ + 1 + 1 不仅题目骚,内容更骚!
Kasugano + 1 + 1 用心讨论,共获提升!
云幻灭 + 1 + 1 用心讨论,共获提升!
lecv1 + 1 + 1 刁爆了,楼主刁爆了
zhiyi1120 + 1 + 1 谢谢@Thanks!
8说了开冲 + 1 + 1 我很赞同!
xr5101616 + 1 + 1 我很赞同!
森林forest + 1 + 1 我很赞同!
蒼澜月 + 1 + 1 用心讨论,共获提升!
az526588225 + 1 + 1 这是一个圈钱的游戏,充钱活动停不下来
喷豆浆的油条 + 1 我很赞同!

查看全部评分

本帖被以下淘专辑推荐:

发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

来自 249#
 楼主| ttimasdf 发表于 2017-12-24 22:54 |楼主
本帖最后由 ttimasdf 于 2017-12-24 23:06 编辑
烟雨破解 发表于 2017-12-19 16:51
@ttimasdf 不错标题很狂妄很自大,呵呵据我所知关于luajit早在四年前,某助手就做了关于刀塔传奇这个luajit ...

嗯哼,谁都藏着掖着啊,没办法,大家都要赚钱钱呢。文章里提到的那个反编译器,维护者最后更新是2016年2月,luajit 2.1第一个beta啥时候出的?2015年。现在啥时候?2017都快完事了,不自己魔改一下还是用不了。

光环现在现在的技术积累已经把游戏“插件”做成远控木马的程度了,实时监控,插件热更,一键阻断,后端还有一个数据平台,能干很多鬼事,你说一个脏牛能打掉多少vivo?腾讯tinker啥时候开源的?2016年。他们自己写的这个方案,多少年了?有人分享过吗?这能分享吗?有人敢分享吗?

给别人看是一回事,自己知道是另一回事
推荐
can_nia 发表于 2017-11-18 15:40
沙发
亲亲宝贝A静 发表于 2017-11-18 01:51
3#
烛光与香水 发表于 2017-11-18 02:55
不明嚼栗
4#
黑白夜丶 发表于 2017-11-18 03:58
说出来你可能都不信,我一步步下来认真的看完了,参考意义较大。
5#
今夜无雨 发表于 2017-11-18 07:01
这个真要膜拜下了。膜~拜~
6#
rrrkkkooo 发表于 2017-11-18 07:44
好东西,可惜目前看不懂
7#
xzdjm 发表于 2017-11-18 07:47
这就是传说中的逆向吗?太高大上了。
8#
MMAKI 发表于 2017-11-18 08:23 来自手机
新的技术贴要支持
9#
shian1988 发表于 2017-11-18 08:31
谢谢分享,进来学习一下,学习需要一点时间。。
10#
幽弥狂 发表于 2017-11-18 08:38
膜拜大佬
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则 警告:本版块禁止灌水或回复与主题无关内容,违者重罚!

快速回复 收藏帖子 返回列表 搜索

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - LCG - LSG ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2024-3-19 14:12

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表