看雪论坛
发新帖
6

[原创]简单粗暴的so加解密实现

ThomasKing 2014-8-26 21:42 93648
以前一直对.so文件加载时解密不懂,不了解其工作原理和实现思路。最近翻看各种资料,有了一些思路。看到论坛没有类似帖子,故来一帖,也作为学习笔记。限于水平,本菜没有找到安卓平台一些具体实现思路,这些方法都是借鉴其他平台的实现思路和本菜的YY,肯定会有不少疏漏和错误之处,还请各位大牛指正,感激不尽!

简单粗暴的so加解密实现
一、  概述
利用动态链接库实现安卓应用的核心部分,能一定程度的对抗逆向。由于ida等神器的存在,还需要对核心部分进行加密。动态链接库的加密,在我看来,有两种实现方式:1. 有源码; 2、无源码。无源码的加密,类似window平台的加壳和对.dex文件的加壳,需要对文件进行分析,在合适的地方插入解密代码,并修正一些参数。而如果有源码,则可以构造解密代码,并让解密过程在.so被加载时完成。(当然,应用程序加载了.so文件后,内存中.so数据已经被解密,可直接dump分析。同时,也有一些对抗dump的方法,这里就不展开了)。
下文只针对有源码这种方式进行讨论,分析一些可行的实现方法。主要是包含对ELF header的分析(不是讨论各个字段含义); 基于特定section和特定函数的加解密实现(不讨论复杂的加密算法)。

二、  针对动态链接库的ELF头分析
网上有很多资料介绍ELF文件格式,而且写得很好很详细。我这里就不重复,不太了解的朋友,建议先看看。以下内容,我主要从链接视图和装载视图来分析ELF头的各个字段,希望能为读者提供一些ELF文件头的修正思路。
这里,我再罗嗦列出ELF头的各个字段:
typedef struct {
  unsigned char  e_ident[EI_NIDENT];  /* File identification. */
  Elf32_Half  e_type;    /* File type. */
  Elf32_Half  e_machine;  /* Machine architecture. */
  Elf32_Word  e_version;  /* ELF format version. */
  Elf32_Addr  e_entry;  /* Entry point. */
  Elf32_Off  e_phoff;  /* Program header file offset. */
  Elf32_Off  e_shoff;  /* Section header file offset. */
  Elf32_Word  e_flags;  /* Architecture-specific flags. */
  Elf32_Half  e_ehsize;  /* Size of ELF header in bytes. */
  Elf32_Half  e_phentsize;  /* Size of program header entry. */
  Elf32_Half  e_phnum;  /* Number of program header entries. */
  Elf32_Half  e_shentsize;  /* Size of section header entry. */
  Elf32_Half  e_shnum;  /* Number of section header entries. */
  Elf32_Half  e_shstrndx;  /* Section name strings section. */
} Elf32_Ehdr;
e_ident、e_type、e_machine、e_version、e_flags和e_ehsize字段比较固定;e_entry 入口地址与文件类型有关。e_phoff、e_phentsize和e_phnum与装载视图有关;e_shoff、e_shentsize、e_shnum和e_shstrndx与链接视图有关。目前e_ehsize = 52字节,e_shentsize = 40字节,e_phentsize = 32字节。
下面看看这两种视图的排列结构:

直接从图中,可以得到一些信息:Program header位于ELF header后面,Section Header位于ELF文件的尾部。那可以推出:
e_phoff = sizeof(e_ehsize);
整个ELF文件大小 = e_shoff + e_shnum * sizeof(e_shentsize) + 1
e_shstrndx字段的值跟strip有关。Strip之前:.shstrtab 并不是最后一个section.则 e_shstrndx = e_shnum – 1 – 2;

而经过strip之后,动态链接库末尾的.symtab和.strtab这两个section会被去掉. 则e_shstrndx = e_shnum – 1。

使用ndk生成在\libs\ armeabi\下的.so文件是经过strip的,也是被打包到apk中的。可以在\obj\local\armeabi\下找到未经过strip的.so文件。到这里,我们就可以把http://bbs.pediy.com/showthread.php?t=188793 帖子中提到的.so文件修正。如果e_shoff和e_shnum都改成任意值,那么修正起来比较麻烦。
感觉上好像e_shoff、e_shnum等与section相关的信息任意修改,对.so文件的使用毫无影响。的确是这样的,至少给出两个方面来佐证:
1.  so文件在内存中的映射

相信了解elf装载(执行)视图的朋友肯定清楚,.so文件是以segment为单位映射到内存的。图中红色区域的section是没有被映射的内存,当然也在segment中找不到。
2.  安卓linker源码
在linker.h源码中有一个重要的结构体soinfo,下面列出一些字段:
struct soinfo{
    const char name[SOINFO_NAME_LEN]; //so全名
    Elf32_Phdr *phdr; //Program header的地址
int phnum; //segment 数量
unsigned *dynamic; //指向.dynamic,在section和segment中相同的
//以下4个成员与.hash表有关
unsigned nbucket;
unsigned nchain;
unsigned *bucket;
unsigned *chain;

unsigned *preinit_array;
unsigned preinit_array_count;
//这两个成员只能会出现在可执行文件中

  //指向初始化代码,先于main函数之行,即在加载时被linker所调用,在linker.c可以看到:__linker_init -> link_image -> call_constructors -> call_array
unsigned *init_array;
unsigned init_array_count;
void (*init_func)(void);
//与init_array类似,只是在main结束之后执行
unsigned *fini_array;
unsigned fini_array_count;
void (*fini_func)(void);
}
另外,linker.c中也有许多地方可以佐证。其本质还是linker是基于装载视图解析的so文件的。
基于上面的结论,再来分析下ELF头的字段。
1) e_ident[EI_NIDENT] 字段包含魔数、字节序、字长和版本,后面填充0。对于安卓的linker,通过verify_elf_object函数检验魔数,判定是否为.so文件。那么,我们可以向位置写入数据,至少可以向后面的0填充位置写入数据。遗憾的是,我在fedora 14下测试,是不能向0填充位置写数据,链接器报非0填充错误。
2) 对于安卓的linker,对e_type、e_machine、e_version和e_flags字段并不关心,是可以修改成其他数据的(仅分析,没有实测)
3) 对于动态链接库,e_entry 入口地址是无意义的,因为程序被加载时,设定的跳转地址是动态连接器的地址,这个字段是可以被作为数据填充的。
4) so装载时,与链接视图没有关系,即e_shoff、e_shentsize、e_shnum和e_shstrndx这些字段是可以任意修改的。被修改之后,使用readelf和ida等工具打开,会报各种错误,相信读者已经见识过了。
5) 既然so装载与装载视图紧密相关,自然e_phoff、e_phentsize和e_phnum这些字段是不能动的。

根据上述结论,做一个面目全非,各种工具打开报错的so文件就很easy了,读者可以试试,这里就不举例,你将在后续内容中看到。

三、  基于特定section的加解密实现
这里提到基于section的加解密,是指将so文件的特定section进行加密,so文件被加载时解密。下面给出实例。
假设有一个shelldemo应用,调用一个native方法返回一个字符串供UI显示。在native方法中,又调用getString方法返回一个字符串供native方法返回。我需要将getString方法加密。这里,将getString方法存放在.mytext中(指定__attribute__((section (".mytext")));),即是需要对.mytext进行加密。
加密流程:
1)  从so文件头读取section偏移shoff、shnum和shstrtab
2)  读取shstrtab中的字符串,存放在str空间中
3)  从shoff位置开始读取section header, 存放在shdr
4)  通过shdr -> sh_name 在str字符串中索引,与.mytext进行字符串比较,如果不匹配,继续读取
5)  通过shdr -> sh_offset 和 shdr -> sh_size字段,将.mytext内容读取并保存在content中。
6)  为了便于理解,不使用复杂的加密算法。这里,只将content的所有内容取反,即 *content = ~(*content);
7)  将content内容写回so文件中
8)  为了验证第二节中关于section 字段可以任意修改的结论,这里,将shdr -> addr 写入ELF头e_shoff,将shdr -> sh_size 和 addr 所在内存块写入e_entry中,即ehdr.e_entry = (length << 16) + nsize。当然,这样同时也简化了解密流程,还有一个好处是:如果将so文件头修正放回去,程序是不能运行的。

解密时,需要保证解密函数在so加载时被调用,那函数声明为:init_getString __attribute__((constructor))。(也可以使用c++构造器实现, 其本质也是用attribute实现)
解密流程:
1)  动态链接器通过call_array调用init_getString
2)  Init_getString首先调用getLibAddr方法,得到so文件在内存中的起始地址
3)  读取前52字节,即ELF头。通过e_shoff获得.mytext内存加载地址,ehdr.e_entry获取.mytext大小和所在内存块
4)  修改.mytext所在内存块的读写权限
5)  将[e_shoff, e_shoff + size]内存区域数据解密,即取反操作:*content = ~(*content);
6)  修改回内存区域的读写权限
(这里是对代码段的数据进行解密,需要写权限。如果对数据段的数据解密,是不需要更改权限直接操作的)

利用readelf查看加密后的so文件:

运行结果很简单,源码见附件

注意:并不是所有的section都能全加,有些数据是不能加密的。比如直接对.text直接加密,会把与crt有关代码也加密,只能选择性的加密。下面将介绍如何实现

四、  基于特定函数的加解密实现
上面的加解密方式可谓简单粗暴。采用这种方式实现,如果ELF头section被恢复,则很容易被发现so多了一个section。那么,对ELF中已存在的section中的数据部分加密,可以达到一定的隐藏效果。
与上节例子类似,命名为shelldemo2,只是native直接返回字符串给UI。需要做的是对Java_com_example_shelldemo2_MainActivity_getString函数进行加密。加密和解密都是基于装载视图实现。需要注意的是,被加密函数如果用static声明,那么函数是不会出现在.dynsym中,是无法在装载视图中通过函数名找到进行解密的。当然,也可以采用取巧方式,类似上节,把地址和长度信息写入so头中实现。Java_com_example_shelldemo2_MainActivity_getString需要被调用,那么一定是能在.dynsym找到的。
加密流程:
1)  读取文件头,获取e_phoff、e_phentsize和e_phnum信息
2)  通过Elf32_Phdr中的p_type字段,找到DYNAMIC。从下图可以看出,其实DYNAMIC就是.dynamic section。从p_offset和p_filesz字段得到文件中的起始位置和长度

3)  遍历.dynamic,找到.dynsym、.dynstr、.hash section文件中的偏移和.dynstr的大小。在我的测试环境下,fedora 14和windows7 Cygwin x64中elf.h定义.hash的d_tag标示是:DT_GNU_HASH;而安卓源码中的是:DT_HASH。
4)  根据函数名称,计算hash值
5)  根据hash值,找到下标hash % nbuckets的bucket;根据bucket中的值,读取.dynsym中的对应索引的Elf32_Sym符号;从符号的st_name所以找到在.dynstr中对应的字符串与函数名进行比较。若不等,则根据chain[hash % nbuckets]找下一个Elf32_Sym符号,直到找到或者chain终止为止。这里叙述得有些复杂,直接上代码。
for(i = bucket[funHash % nbucket]; i != 0; i = chain[i]){
  if(strcmp(dynstr + (funSym + i)->st_name, funcName) == 0){
    flag = 0;
    break;
  }
}
6)  找到函数对应的Elf32_Sym符号后,即可根据st_value和st_size字段找到函数的位置和大小
7)  后面的步骤就和上节相同了,这里就不赘述

解密流程为加密逆过程,大体相同,只有一些细微的区别,具体如下:
1)  找到so文件在内存中的起始地址
2)  也是通过so文件头找到Phdr;从Phdr找到PT_DYNAMIC后,需取p_vaddr和p_filesz字段,并非p_offset,这里需要注意。
3)  后续操作就加密类似,就不赘述。对内存区域数据的解密,也需要注意读写权限问题。

加密后效果:

运行结果与上节相同,就不贴了。

五、  参考资料
http://blog.csdn.net/forlong401/article/details/12060605
《ELF文件格式》
Android linker源码:bionic\linker
Android libc源码:bionic\libc\bionic
谷歌:ELF链接视图与装载视图相关资料
------------------------------------------------------------------------
基于上面的方法,我写了一个CrackMe.apk的注册机程序供大家玩耍。输入3~10位的username和regcodes,8位的校验码,字符范围:A~Z、a~z、0~9。若校验通过,则提示:congratulation! You crack it!.
附件:
shelldemo.zip
shelldemo2.zip
CrackMe.apk

上个pdf,这个太乱了。
简单粗暴的so加解密实现.pdf
上传的附件:
最新回复 (95)
2
万抽抽 2014-8-26 21:48
2
我就是来顶你的!
Asfy 2014-8-26 22:29
3
支持支持~~~~
Fido 2014-8-26 23:36
4
学习...谢谢分享
1
Nermor 2014-8-27 09:39
5
这下又有的玩了; 攻防攻防~~~
1
鬼谷子c 2014-8-27 10:02
6
楼主的分析过程很详细,测试用例也很好,大赞~
OnlyEnd 2014-8-27 10:20
7
赞、好好研究下!
6
ThomasKing 2014-8-27 10:47
8
额。。。
6
ThomasKing 2014-8-27 10:50
9
多谢鬼哥前来支持
hwuyule 2014-8-27 11:04
10
擦。。。这么给力 晚上吃什么
xunbu 2014-8-27 11:38
11
顶!精力充沛啊!
4
我是小三 2014-8-27 11:41
12
研究出一个注册码
yfw
qqqq
HCunR1em

上传的附件:
  • 1.png (36.18kb,66次下载)
6
ThomasKing 2014-8-27 12:09
13
[QUOTE=我是小三;1312274]研究出一个注册码
yfw
qqqq
HCunR1em

[/QUOTE]

好快的速度。
无心无聊 2014-8-28 15:28
14
大神级别,论坛有位仁兄unwww秒脱so库的方法不知道楼主知道不。
6
ThomasKing 2014-8-28 17:42
15
额。 不知道,求教。
pwelyn 2014-8-29 09:35
16
这个比较不错 顶一下
4
Xbalien 2014-8-29 11:00
17
顶一下,支持
xugui 2014-8-29 12:02
18
高手啊, 正在研究andorid逆向
zhczf 2014-8-29 14:10
19
楼主发表这么精彩的技术文章,来支持一下
wodexinren 2014-8-29 16:41
20
来的正好,准备开搞移动安全
暮色丶 2014-8-30 14:34
21
没玩过安卓...求大大带带入门
2
JoyFei 2014-8-30 20:47
22
赶快加精吧
无心无聊 2014-8-31 16:41
23
大家都求教了,可惜人家不愿意教。。
biyetianya 2014-9-2 12:44
24
成功的感觉很好吧
biyetianya 2014-9-2 12:46
25
坚决支持
cacorothuo 2014-9-2 17:24
26
支持。不过有几点
1.  .text理论上是完全可以加密的。
2.  多加节无所谓,只要把节表和strtab删掉即可。
3.  解密完后一定要cache刷新一下
4. __attribute__((constructor))这个方式也不错,但可以通过扩充init_array来完成。
6
ThomasKing 2014-9-2 18:48
27
多谢指点! 不过我不太明白大大的意思:
1. 那如果.text都加密了,与CRT相关的代码如何处理?
2. 多加的节应该放在文件末尾吧? 直接插在中间的话,就需要把后面的segment移位偏移吧
3. 为什么要cache下?通过什么实现?
4. 声明 __attribute__((constructor))属性,编译器会把此函数加入init_array中。那扩充init_array是通过section属性声明来实现么?
求大大解释,小弟不胜感激!
cacorothuo 2014-9-3 09:45
28
你说的CRT是加密解密代码吗?这个可以放到自定义的节中啊。
多加的节是放在末尾的
cache的原因是解密前的指令还有可能在cache当中,解密后刷新一下可以恢复解密后的指令。
扩充init_array可以新建一个init_array节啊,把原先的拷贝过去,重新做好重定位,就可以了。
丘比龙 2014-9-3 09:52
29
这些需要被加壳来写代码配合。你新建的init_array要吗在被加壳中so写代码配合。要么扩充节。
而扩充节那要修复就多了。
6
ThomasKing 2014-9-3 11:20
30
多谢大大指点!
之前小弟没说清楚,不好意思,。 我说的CRT代码是与运行库相关代码。 这些代码编译器自动加上放在.text段。 我之前测试过,如果直接把.text段全加密,是不行的。
前段时间,小弟做双重加密的时候,就遇到时灵时不灵的情况。听大大这么说,我估计是cache没刷。那cache怎么刷呢? 请大大指点下
6
ThomasKing 2014-9-3 11:22
31
嗯,多谢大大指点!
cacorothuo 2014-9-3 12:07
32
哦。我试过.text完全加密,倒没出现过问题。时灵时不灵的问题就是没有刷新cache的缘故。
http://stackoverflow.com/questions/6046716/how-clear-and-invalidate-arm-v7-processor-cache-from-user-mode-on-linux-2-6-35

或者google   flush cache
6
ThomasKing 2014-9-3 13:07
33
多谢大大指点!
华仔在吗 2014-9-3 21:45
34
感谢分享。。。。。
wule 2014-9-5 19:55
35
这么好的贴,不知说点什么好了,顶!!
5
boyliang 2014-9-9 22:52
36
非常好的技术贴,描述也很详细易懂,赞一个。
风过果落 2014-9-10 08:53
37
感谢楼主分享~~~~
6
ThomasKing 2014-9-10 10:50
38
多谢大大鼓励支持!
fkunlam 2014-9-10 11:14
39
不错吖,感谢分享吖。
lifangjie 2014-9-16 15:51
40
我是顶你的,你帮我了我的大忙
6
ThomasKing 2014-9-16 18:42
41
多谢支持鼓励。
fanfu 2014-11-28 17:07
42
ThomasKing出品,必属精品,细细研读,收获不小,多谢谢大神。。
xiaogangha 2015-2-4 16:43
43
有没有人遇到过。。程序报错
02-04 08:40:32.481: A/libc(948): Fatal signal 4 (SIGILL) at 0x4a2c13de (code=1), thread 948 (example.soshell)
xiaogangha 2015-2-11 08:53
44
也就是这个函数报错,
if(mprotect((void *) ((base + info.st_value) / PAGE_SIZE * PAGE_SIZE), npage, PROT_READ | PROT_EXEC | PROT_WRITE) != 0){
                print_debug("mem privilege change failed");
        }
没有权限??
ydyyes 2015-2-14 21:53
45
mark
Colbert仔 2015-2-17 16:34
46
ThomasKing兄,我试了你的解密代码解密出错,原因是nblock = ehdr->e_entry >> 16;的值为0,通过LOG发行ehdr->e_entry的值为0,这是为何,如何解决?多谢!
Colbert仔 2015-2-17 16:35
47
ThomasKing兄,我试了你的解密代码解密出错,原因是nblock = ehdr->e_entry >> 16;的值为0,通过LOG发行ehdr->e_entry的值为0,这是为何,如何解决?多谢!
fanslinux 2015-2-17 16:36
48
多谢分享!
Colbert仔 2015-2-19 16:20
49
找到原因了,我改了elf head,把entry置为0了,多谢大神的无私分享!
Colbert仔 2015-2-19 18:25
50
整个ELF文件大小 = e_shoff + e_shnum * sizeof(e_shentsize) + 1

应该为
整个ELF文件大小 = e_shoff + e_shnum * sizeof(e_shentsize) - 1吧?
返回



©2000-2017 看雪学院 | Based on Xiuno BBS | 知道创宇带宽支持 | 微信公众号:ikanxue
Time: 0.013, SQL: 9 / 京ICP备10040895号-17