从零打造简单SODUMP工具.PDFVIP

Powered by ThomasKing. All Rights Reserved. 2014.11.03 从零打造简单的SODUMP 工具 Author: ThomasKing 最近翻看之前的帖子，发现基于linker init_array 加密的SO 文件的静态分析稍微麻烦。 虽然原理很清楚，但是需要dump 之后再进行section 修复才能放入ida。可以看到，上述两 步骤其实很机械。那么应该可以实现一个自动化工具，帮助我们解决上述问题，让我们可以 精力专注于其他地方，提高效率。实现上述工具需要解决两个问题：1 应对各种加密算法 2 section 重建。Section 重建在 /showthread.php?t=192874 已经讨论，就 不再赘述，仅仅改进一些不足之处。 一、应对各种加密算法策略 在/showthread.php?t=192020viewgoodnees=1prefixid= 等帖子中 提到的SO 文件都基于init_array 实现。为了静态分析，不得不分析出算法，并实现对SO 解 密，以便静态分析。而且，不同的SO 采用不同的加密算法。这个步骤时间的花费，取决于 分析人员对各种常用的加密算法RC4、TE 等了解程度，这是比较纠结的事情。 那如何应对各种加密算法，成为工具实现的关键。直接实现各种算法，这个显然是不行 的。那只能通过某种方法来绕过。想了很久，也没有很好的解决策略。不过有一点，熟悉 SO 机制的读者都知道，linker 可是应对自如！那看来只能借linker 之手，来帮助我们实现。 Linker 除了在程序运行初加载外，还有就是通过dl 函数会调用，即dlopen、dlsym、dlerr 和dlclose 。啰嗦下dlopen 和dlsym 函数原型： void * dlopen( const char * pathname, int mode); void*dlsym(void*handle,constchar*symbol) ； 通常，使用dlopen 打开加载某SO 后，会返回一个handle 对象，然后根据handle 对象 调用dlsym 查找某函数符号，实现调用。仔细分析可以发现，这个过程和程序在运行初是类 似的；另外，linker 只会加载某一S0 一次，那么linker 应该维护了一个数据表来记录。进一 步分析还可以发现，这个void *handle 对象应该指向了当前打开SO 的数据对象。有了这个 思路，翻看dl 函数源码(位于：\bionic\linker\dlfcn.c，不是在bionic\libdl\libdl.c)，dlopen 源 码： void *dlopen(const char *filename, int flag) { soinfo *ret; pthread_mutex_lock(dl_lock); ret = find_library(filename); if (unlikely(ret == NULL)) { set_dlerror(DL_ERR_CANNOT_LOAD_LIBRARY); } else { ret-refcount++; } pthread_mutex_unlock(dl_lock); return ret; } 标红部分可以看到，ret 就是handle。翻看linker 源码，其实际为：soinfo 结构体(截取部分 结构) Powered by ThomasKing. All Rights Reserved. 2014.11.03 struct soinfo { const char name[SOINFO_NAME_LEN]; Elf32_Phdr *phdr; // Elf32_Phdr 实际内存地址 int phnum; unsigned entry;