首页
论坛
课程
招聘
基于linker实现so加壳补充-------从dex中加载so
2021-10-12 17:48 19985

基于linker实现so加壳补充-------从dex中加载so

2021-10-12 17:48
19985

基于linker实现so加壳技术(补充)

总述

之前的文章给大家展示了一个so文件加壳的整体方法,而且给了一个比较简单的例子,后来我实现了一下将so写在dex中然后通过hook关键函数的方式得到so的地址。但是在实际使用过程中我发现了一个问题,就是有些got表中的变量,通过plt调用使用了页对其指令,这就要求我们的so必须在一块对其的内存上,如下图,并且inline hook也好难实现,而且dex是以只读的方式加载到内存中的,我还需要hook掉关键函数改掉它的属性,基于这三个问题,写了这篇补充
1:so地址页对其&第一个PT_LOAD和第二个PT_LOAD之间有多余占位数据
2:实现libart.so中的inlinehook
3:hook dex加载函数更改只读权限
4: 修正getsoinfo函数

so地址页对其&多余数据

由于像上面那种变量或者函数(例如strlen函数)在使用过程中,存在需要取页开始的情况,我们就必须保证so在内存中的偏移%0x1000等于0,所以我之前设想的直接在dex末尾接so内容的方式就不可取了,而且我们附在dex末尾的so是linking view,数据都在相对于文件的偏移上面,而so的执行需要Execution View,代码中lr这种函数跳转用的都是相对于so起地址的物理地址偏移,所以强行用静态的so文件会使调用函数的地址不对,而我又不想再次使用mmap将已经加载到内存中的so,再搞出来单独装载,所以想了一个折中的办法,利用系统通过ElfReader::Load结束的soinfo直接将此so的Execution View 整体dump出来,这一步可以用frida也可以用ida,或者用我上篇文章写的装载函数(当然这种更好因为不会触发任何反调试,因为我没有调用init_arry和JNI_Onloade当中的函数),在演示demo中我采用了第一种方式(不想写装载了有点累...),用idc脚本从ida里面dump一段内存

1
2
3
4
5
6
7
8
9
10
11
static main(void)
{
auto fp, begin, end, dexbyte;
fp = fopen("d:\\1.so", "wb");
begin = 0x0000007366280000;
end = begin + 0x0036000;
for ( dexbyte = begin; dexbyte < end;dexbyte ++ )
{
fputc(Byte(dexbyte), fp);
}
}

搞下来的so直接复制粘贴到dex末尾即可,由于需要对其,所以需要补0,当然如果想不让人看出来就补乱码,后面so也应该加密,只有在使用的时候再解密,我这里没有加密,只是补0和正常的复制,最后把filesize和checksum等一系列参数补充完整即可

由于Execution View后面都是节头去掉的部分所以都是0.这样就能解决对齐的问题嘛?答案是可以的,因为在DexClassloader加载dex的路上的函数MapFileAtAddress,是用的页对其,所以我们补完0之后so也一定是页对其的

搞定完这里,把so和插件dex都写入一个b.txt,然后直接用DexClassLoader加载起来就好,期间我模仿之前寒冰老师出的ctf题的写法,将b.txt搞到了资源目录然后使用的时候再复制到cache目录。

1
2
3
copyAssetAndWrite("b.txt",getApplicationContext());
 ....
DexClassLoader loader=new DexClassLoader(path,"/sdcard","/sdcard",context.getClassLoader());

这样这部分的准备工作就完成了。

实现libart.so中的inlinehook

那么同时又产生了第二个问题,就是如何定位我的真正so的首地址。既然我将so加到了dex的末尾,那么我就可以通过dex+偏移的方式来访问我的so,那么问题又来了如何搞到dex的首地址呢?这里有2种办法,第一种就是从maps文件里面搜索,但是这样又不是很优雅,最终没有采纳。我最后是借鉴了寒冰老师的脱壳的思路,在LoadClass的关键路径上hook来搞定,我选择了LoadMethod函数,它的第一个参数就是c层的DexFile对象,那么hook搞定呢,用现成的hook框架?感觉特征太多而且就失去了学习的价值,还是自己写一个来的实在,首先想一个,既然是hook LoadMethod那么是不是用got表hook,来简单的搞定,扫了好几眼发现got表种没有这个函数555...,那么就只能挑战linline hook了。

寻找LoadMethod函数地址

由于LoadMethod函数是导出函数,所以我们可以从libart.so的导出表里面找到它的地址,通过类型为PT_DYNAMIC的段就能找到,这里由于上篇文章已经介绍了elf的文件格式所以这里只贴一点代码不做过多的介绍

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
   char line[1024];
    int *startr;
    int *end;
    int n=1;
    FILE *fp=fopen("/proc/self/maps","r");
    while (fgets(line, sizeof(line), fp)) {//从maps种扫描libart.so的地址
        if (strstr(line, libname) ) {
            __android_log_print(6,"r0ysue","");
            if(n==1){
                startr = reinterpret_cast<int *>(strtoul(strtok(line, "-"), NULL, 16));
                end = reinterpret_cast<int *>(strtoul(strtok(NULL, " "), NULL, 16));
            }
            else{
                strtok(line, "-");
                end = reinterpret_cast<int *>(strtoul(strtok(NULL, " "), NULL, 16));
            }
            n++;
        }
    }
    size_t   gnu_nbucket_ = 0;
    // skip symndx
    uint32_t     gnu_maskwords_ = 0;
    uint32_t  gnu_shift2_ =0;
    ElfW(Addr)*  gnu_bloom_filter_= nullptr;
    uint32_t*  gnu_bucket_ = nullptr;
    uint32_t*  gnu_chain_ = nullptr;
//导出表4
    int phof=0;
    Elf64_Ehdr header;
    memcpy(&header,startr,sizeof(Elf64_Ehdr));
    uint64 rel= 0;
    size_t size=0;
    long* plt= nullptr;
    char* strtab_= nullptr;
    Elf64_Sym* symtab_= nullptr;
    Elf64_Phdr cc;
    memcpy (&cc,((char*)(startr)+header.e_phoff),sizeof(Elf64_Phdr));
    for(int y=0;y<header.e_phnum;y++){
        memcpy(&cc, (char *) (startr) +header.e_phoff+sizeof(Elf64_Phdr) * y, sizeof(Elf64_Phdr));
        if(cc.p_type==6) {//程序头偏移
            phof=cc.p_paddr-cc.p_offset;
        }
    }
    for(int y=0;y<header.e_phnum;y++){
        memcpy(&cc, (char *) (startr) +header.e_phoff+sizeof(Elf64_Phdr) * y, sizeof(Elf64_Phdr));
        if(cc.p_type==2) {//p_type=2代表找到了动态段
            Elf64_Dyn dd;
            for(y=0;y==0||dd.d_tag!=0;y++) {
                memcpy(&dd, (char *) (startr) + cc.p_offset + y * sizeof(Elf64_Dyn)+0x1000,
                       sizeof(Elf64_Dyn));
 
                if(dd.d_tag==0x6ffffef5){//找到了 DT_GNU_HASH段也就是导出表
 
                    gnu_nbucket_ = reinterpret_cast<uint32_t*>((char*)startr + dd.d_un.d_ptr-phof)[0];
                    // skip symndx
                    gnu_maskwords_ = reinterpret_cast<uint32_t*>((char*)startr + dd.d_un.d_ptr-phof)[2];
                    gnu_shift2_ = reinterpret_cast<uint32_t*>((char*)startr + dd.d_un.d_ptr-phof)[3];
 
                    gnu_bloom_filter_ = reinterpret_cast<ElfW(Addr)*>((char*)startr + dd.d_un.d_ptr + 16-phof);
                    gnu_bucket_ = reinterpret_cast<uint32_t*>(gnu_bloom_filter_ + gnu_maskwords_);
                    // amend chain for symndx = header[1]
                    gnu_chain_ = reinterpret_cast<uint32_t *>( gnu_bucket_ +
                                                               gnu_nbucket_-reinterpret_cast<uint32_t *>(
                                                                       (char *) startr +
                                                                       dd.d_un.d_ptr-phof)[1]);
 
                }
                if(dd.d_tag==5 ){//得到字符串表的首地址
                    strtab_=reinterpret_cast< char*>((char *) startr+dd.d_un.d_ptr-phof);
                }
                if(dd.d_tag==6 ){//得到符号表的首地址
                    symtab_= reinterpret_cast<Elf64_Sym *>((
                            (char *) startr + dd.d_un.d_ptr-phof));
                }
            }
        }
 
 
    }

很容易就得到了导出表、符号表、字符串表的信息,接下来只需要模仿安卓源码中soinfo::gnu_lookup函数的写法来,获取我们的导出符号的函数地址就好,这里我直接将symbol_name.gnu_hash函数抽出来实现了一下,他这种计算hash的方式很简单,也就5行代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
char* name_=symname;
  uint32_t h = 5381;
  const uint8_t* name = reinterpret_cast<const uint8_t*>(name_);
  while (*name != 0) {
      h += (h << 5) + *name++; // h*33 + c = h + h * 32 + c = h + h << 5 + c
  }//实现symbol_name.gnu_hash
  int index=0;
  uint32_t h2 = h >> gnu_shift2_;
  uint32_t bloom_mask_bits = sizeof(ElfW(Addr))*8;
  uint32_t word_num = (h / bloom_mask_bits) & gnu_maskwords_;
  ElfW(Addr) bloom_word = gnu_bloom_filter_[word_num];
  n = gnu_bucket_[h % gnu_nbucket_];//模仿安卓源码直接抄
  do {
 
 
      Elf64_Sym * s = symtab_ + n;
 
 
      char * sb=strtab_+ s->st_name;
 
      if (strcmp(sb ,reinterpret_cast<const char *>(name_)) == 0 ) {
 
 
          break;
      }
  } while ((gnu_chain_[n++] & 1) == 0);

这样最终得到了我们传入符号在符号表当中的索引,那么只要拿到当中的st_value就是地址偏移了

1
void* mysym=(char *)startr+sb->st_value-phof

粗略的实现inline hook

由于水平太低有点看不懂大佬的思路.......,只能先自己思考一下如何实现inline hook了,由此提出以下几个问题
1.首先构想一个整体的思路,如何实现每个我们需要hook的函数都能跳转到我们自己的函数执行?
这个问题可以用一条指令就是b一个地址,但是又有一个问题,这个地址是有范围要求的,如果不在同一个so当中很难满足这个界限要求,这一点在https://armconverter.com/ 中可以得到验证,所以这种方式是不可以的,那么就只剩一种方式了br或blr一个寄存器的值,根据网上资料(实在太菜大佬的文章只能看懂这一点)x17和x16是不经常使用的(我只在安卓源码art_jni_dlsym_lookup_stub中看到了使用),那么就需要赋值和br来替换函数的前几条指令代码如下,一共用了16位来跳转到我自己的代码,所以要把这四条指令保存下来,这里保存指令我用的全局变量不知道有没有更好的方式,这里面我用的blr因为我还要跳回来所以不能用br,用br不会保存x30寄存器,就会直接跳回上一级函数,就不会执行原函数了,但是这样又有一个问题,就是我这4条指令可能会覆盖x30的入栈指令那么在之后的x30恢复的时候就会无法恢复x30,所以我决定在x30的入栈指令之后执行我的操作,具体做法是扫描指令如果满足STX29, X30, [SP,#0x80]这种类似的,才在他的后一位写入我们的跳转指令 ,如果直接扫到了最后,那么没办法了只能从开头开始,16进制和汇编的转换都可以从https://armconverter.com/ 当中找到这里就不在计算了,如下图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    int s=0;
    for(n=0;*(int*)((char *)startr+sb->st_value-phof+n)!=0xd65f03c0;n=n+4){
        int code=*(int*)((char *)startr+sb->st_value-phof+n);
        if(code>>32==0xa9&&(code&0xfff)==0xbfd){
          __android_log_print(6,"r0ysue","%x",n);
            s=1;
            break;
        }
 
    }
    if(s=1){
        n=n+4;
        }
    else{
        n=0;
    }
one= *(int*)((char *)startr+sb->st_value-phof+n);
two= *(int*)((char *)startr+sb->st_value-phof+n+4);
three[ns=*(int*)((char *)startr+sb->st_value-phof+n+8);
four[]=*(int*)((char *)startr+sb->st_value-phof+n+12);
 
*(int*)((char *)startr+sb->st_value-phof+n)=0x58000051;//
*(int*)((char *)startr+sb->st_value-phof+n+4)=0xd63f0220;
*(long**)((char *)startr+sb->st_value-phof+n+8)= reinterpret_cast<long*>(myloadmethod);//自己函数的地址


成功的跳到我写的函数,那么现在就构思如何写自己的壳函数了,有一个问题,就是arm64不能操作pc,所以我要如何控制回来的时候跳到哪里呢,我把目光盯向了x30,执行完RET这条汇编之后,pc会跳到x30处(也就是32位下的lr),那么只要我指定x30就好了,由于上面用了4条指令而我是在第2条指令跳转的,所以要把x30+8,这一段我发现如果不用裸函数写,他会自动加上对x30寄存器的保护,所以我选择了裸函数,之后就是对寄存器的保护就好了.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
void  __attribute((naked)) myloadmethod(){
    asm("add x30,x30,8");//指定跳回去的位置
    asm("sub SP, SP, #0x100");//申请栈
    asm("stp X29, X30, [SP,#0x10]");//保护寄存器
    asm("stp X0, X1, [SP,#0x20]");
    asm("stp X2, X3, [SP,#0x30]");
    asm("stp X4, X5, [SP,#0x40]");
    asm("stp X6, X7, [SP,#0x50]");
    asm("stp X8, X9, [SP,#0x60]");
    asm("stp X10, X11, [SP,#0x70]");
    asm("stp X12, X13, [SP,#0x80]");
    asm("stp X14, X15, [SP,#0x90]");
    asm("ldp X16, X17, [SP,#0x10]");//保存x30到x17,当然这里用mov或者ldr都行我复制粘贴省事了
    asm("mov X16,SP");//这里参数处理我们想好就先用栈替代
    asm("mov x0,x0");//占位,会改成BL _Z4pltsv,也就是我们自己写的第二个函数
    asm("ldp X8, X9, [SP,#0x60]");//寄存器恢复
    asm("ldp X10, X11, [SP,#0x70]");
    asm("ldp X12, X13, [SP,#0x80]");
    asm("ldp X14, X15, [SP,#0x90]");
    asm("ldp X0, X1, [SP,#0x20]");
    asm("ldp X2, X3, [SP,#0x30]");
    asm("ldp X4, X5, [SP,#0x40]");
    asm("ldp X6, X7, [SP,#0x50]");
    asm("ldp X29, X30, [SP,#0x10]");
    asm("add SP, SP, #0x100");
    asm("mov x0,x0");//之前在原函数中占位的第1条指令
    asm("mov x0,x0");//之前在原函数中占位的第2条指令
    asm("mov x0,x0");//之前在原函数中占位的第3条指令
    asm("mov x0,x0");//之前在原函数中占位的第4条指令
    asm("RET");
 
}

这里就是下一个问题了,我们如何执行我们自己的函数,又如何将原来的4条指令执行一遍,这里我选择了再做一层包装,再写一个跳转,这会就不用裸函数了,而且指令直接用b 相对地址就可以了,因为是在同一个so当中,由于我不知道在内存中他俩谁在前面,所以写了个判断,而且恢复占用指令的代码也写在了这个包装函数里面

1
2
3
4
5
6
7
8
9
10
int code;
if((long)myloadmethod>(long)plts){
    int off=(long)myloadmethod-(long)plts+48;
    code=0x97ffffff-off/4;
}else{
    int off=(long)plts-(long)myloadmethod-48;
    code=off/4|0x94000000;
}
 
*(int*)((char *)myloadmethod+52)= reinterpret_cast<int>(code);

在这个包装函数中,主要有2方面的内容,于是简单的代码就出来了
1.执行我们在外面传入的hook函数
2.恢复占用的指令

1
2
3
4
5
6
7
8
9
void plts(){
    func st=(func)fc;
    st();
    memcpy((char*)myloadmethod+0x60,&one,4);
    memcpy((char*)myloadmethod+0x64,&two,4);
    memcpy((char*)myloadmethod+0x68,&three,4);
    memcpy((char*)myloadmethod+0x6c,&four,4);
 
}

这样一个简单的inlinehook框架就写完了,就在我迫不及待的去试一下的时候,发现有个大问题,就是单个hook是没啥问题,但是要同时hook2个函数就不行了,因为我用了大量的全局变量,新的输入会覆盖旧的输入,5555...,而我的需求正好是hook 2个函数,气死我了,那么只能做一个思考了,如何完善这个框架,而且尽量做到不大改,因为上面太多了,那么既用了全局变量,就只能以数组的形式存储使用了,直接用一个全局变量ns存储我们的索引。

1
2
3
4
5
6
7
    one[ns]= *(int*)((char *)startr+sb->st_value-phof+n);
    two[ns]= *(int*)((char *)startr+sb->st_value-phof+n+4);
    three[ns]=*(int*)((char *)startr+sb->st_value-phof+n+8);
 
    four[ns]=*(int*)((char *)startr+sb->st_value-phof+n+12);
    funtab[ns]= reinterpret_cast<long>((char *) startr + sb->st_value - phof);
ns++;

那么在使用的时候又有一个问题,就是调用顺序可能和我们自己写的hook的顺序不太一样,所以如何确定我们调用的函数属于哪一个索引又是一个问题,这里我直接用之前的x30来确定,因为x30来自与原函数,所以与原函数不会差距太大,用这个来判断调用的函数属于哪个索引

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
void plts(){
    unsigned long addr=0;
    int uu;
    __asm__("mov %[input_n], x17\r\n"
    :[result_m] "=r" (addr)
    :[input_n] "r" (addr)
    );
    int yy=0;
    for(yy=0;yy<ns;yy++){
        if(addr-(unsigned long)funtab[yy]<0x100){
            break;
        }
 
    }
    func st=(func)fc[yy];
    st();
    memcpy((char*)myloadmethod+0x60,&one[yy],4);
    memcpy((char*)myloadmethod+0x64,&two[yy],4);
    memcpy((char*)myloadmethod+0x68,&three[yy],4);
    memcpy((char*)myloadmethod+0x6c,&four[yy],4);
    __android_log_print(6,"r0ysue","");
}

那么这里我们的框架就完善了,其实还有个问题我没有解决,就是如何更改参数,我这里只能先用栈来解决更改参数的问题(没想好如何解决是个败笔),那么就可以完成我们的hook来获得dex首地址了,hook写在init里面就好

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
void io(void* a,void*b){
    long** dex= static_cast<long **>(b);
     size= reinterpret_cast<size_t>(*(dex + 2));
    long* begin=(*(dex+1));
    if(size==0x392000&&fl==0) {//是我们自己大小的dex而且只取一次
        fl=1;
     realel= reinterpret_cast<long*>(begin );//拿到真正的dex地址
 
     jiake();//释放so,加壳函数上篇文章讲过了,所以这里不再赘述,只需注意修正got表中的变量的值即可
    }
}
 
void _init(){
    mainfun("_ZN3art11ClassLinker10LoadMethodERKNS_7DexFileERKNS_21ClassDataItemIteratorENS_6HandleINS_6mirror5ClassEEEPNS_9ArtMethodE", "libart.so",
            reinterpret_cast<void *>(io));
}

hook dex加载函数更改只读权限

那么现在就只剩下一个问题了,就是如何将dex加载进内存中,这里模仿寒冰老师的ctf赛题,java代码直接拿过来用就好,就是上面第一节的代码,但是这里有一个问题,DexClassLoader是以只读的方式将dex文件加载到内存中,我们需要可读可写可执行,所以需要改权限,但是这里又遇到了一个问题,调用mprotect的时候直接报错,Permission denied,我也不知道为啥在这里卡了好久,最后在 https://blog.csdn.net/earbao/article/details/120308836 中找到了答案,这里就要求我们取hook MapFileAtAddress将其第三个函数改为PROT_WRITE|PROT_READ|PROT_EXEC,这就是我刚才要优化我的inlinehook 框架的原因,我hook了2个函数一个是LoadMethod和MapFileAtAddress,更改代码如下

1
2
3
4
5
6
7
8
9
void jjj(void* a,void* b,int c,int d){
    d=7;
    __asm__("str %[input_n], [X16,#0x30]\r\n"//用到了刚才保存的寄存器,这里直接用
    :[result_m] "=r" (d)
    :[input_n] "r" (d)
    );
}
mainfun("_ZN3art6MemMap16MapFileAtAddressEPhmiiilbbPKcPNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEE", "libart.so",
            reinterpret_cast<void *>(jjj));

修正getsoinfo函数

这样程序就设计完成了,我试没有任何问题,我兴高采烈地去找大佬试一下,没想到打脸了,直接就崩溃了,得知他是bullhead之后,我就拿起了我的82年的Nexus 5x,调试了一下,发现获得soinfo指针那里直接返回了一个特别大的值,哎,看来不同型号的手机linker不一样,我打开ida易看果然,不同型号的手机linker中,__dl_g_soinfo_handles_map偏移不一样,我上篇文章用的是偏移,所以会有这个问题,如下图,左面是0xfa460右面是0xfd460

那么这就很烦了,好难受,上篇文章的内容就有局限性了,只能针对某一型号的手机,那是不可以的,我要解决问题,就还是从soinfo_from_handle这个inline函数入手,这会就看一看他是如何实现的,eee...,看不懂,还是看汇编吧,还是汇编友好一点。

1
2
3
4
5
6
7
8
9
static soinfo* soinfo_from_handle(void* handle) {
  if ((reinterpret_cast<uintptr_t>(handle) & 1) != 0) {
    auto it = g_soinfo_handles_map.find(reinterpret_cast<uintptr_t>(handle));
    if (it == g_soinfo_handles_map.end()) {
      return nullptr;
    } else {
      return it->second;
    }
 }

还是汇编简单一点,这部分内容就很容易理解了,只要拿到最后的x0就好,那么他做了什么呢
1.首先取了dl_g_soinfo_handles_map的值
2.然后将其中的值与他后面一个字节取余操作
3.取上一步结果乘8然后取首先取了
dl_g_soinfo_handles_map的值中的值加这个偏移
4.取2次地址中的值并且加0x18
5.最后再取一次它其中地址的值就是soninfo指针了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
.text:000000000000CC5C                 ADRP            X12, #__dl_g_soinfo_handles_map_ptr@PAGE
.text:000000000000CC60                 LDR             X12, [X12,#__dl_g_soinfo_handles_map_ptr@PAGEOFF]
.text:000000000000CC64                 LDR             X8, [X12,#(qword_FA468 - 0xFA460)]
.text:000000000000CC68                 CBZ             X8, loc_CCF4
.text:000000000000CC6C                 SUB             X9, X8, #1
.text:000000000000CC70                 AND             X10, X9, X8
.text:000000000000CC74                 CBZ             X10, loc_CC90
.text:000000000000CC78                 MOV             X11, X19
.text:000000000000CC7C                 CMP             X8, X19
.text:000000000000CC80                 B.HI            loc_CC94
.text:000000000000CC84                 UDIV            X11, X19, X8
.text:000000000000CC88                 MSUB            X11, X11, X8, X19
.text:000000000000CC8C                 B               loc_CC94
.text:000000000000CC90 ; ---------------------------------------------------------------------------
.text:000000000000CC90
.text:000000000000CC90 loc_CC90                                ; CODE XREF: __dl__Z10do_dlclosePv+5C↑j
.text:000000000000CC90                 AND             X11, X9, X19
.text:000000000000CC94
.text:000000000000CC94 loc_CC94                                ; CODE XREF: __dl__Z10do_dlclosePv+68↑j
.text:000000000000CC94                                         ; __dl__Z10do_dlclosePv+74↑j
.text:000000000000CC94                 LDR             X12, [X12]
.text:000000000000CC98                 LDR             X12, [X12,X11,LSL#3]
.text:000000000000CC9C                 CBZ             X12, loc_CCF4
.text:000000000000CCA0
.text:000000000000CCA0 loc_CCA0                                ; CODE XREF: __dl__Z10do_dlclosePv+A4↓j
.text:000000000000CCA0                                         ; __dl__Z10do_dlclosePv+CC↓j
.text:000000000000CCA0                 LDR             X12, [X12]
.text:000000000000CCA4                 CBZ             X12, loc_CCF4
.text:000000000000CCA8                 LDR             X13, [X12,#8]
.text:000000000000CCAC                 CMP             X13, X19
.text:000000000000CCB0                 B.NE            loc_CCC4
.text:000000000000CCB4                 LDR             X13, [X12,#0x10]
.text:000000000000CCB8                 CMP             X13, X19
.text:000000000000CCBC                 B.NE            loc_CCA0
.text:000000000000CCC0                 B               loc_CCEC
.text:000000000000CCC4 ; ---------------------------------------------------------------------------
.text:000000000000CCC4
.text:000000000000CCC4 loc_CCC4                                ; CODE XREF: __dl__Z10do_dlclosePv+98↑j
.text:000000000000CCC4                 CBZ             X10, loc_CCDC
.text:000000000000CCC8                 CMP             X13, X8
.text:000000000000CCCC                 B.CC            loc_CCE0
.text:000000000000CCD0                 UDIV            X14, X13, X8
.text:000000000000CCD4                 MSUB            X13, X14, X8, X13
.text:000000000000CCD8                 B               loc_CCE0
.text:000000000000CCDC ; ---------------------------------------------------------------------------
.text:000000000000CCDC
.text:000000000000CCDC loc_CCDC                                ; CODE XREF: __dl__Z10do_dlclosePv:loc_CCC4↑j
.text:000000000000CCDC                 AND             X13, X13, X9
.text:000000000000CCE0
.text:000000000000CCE0 loc_CCE0                                ; CODE XREF: __dl__Z10do_dlclosePv+B4↑j
.text:000000000000CCE0                                         ; __dl__Z10do_dlclosePv+C0↑j
.text:000000000000CCE0                 CMP             X13, X11
.text:000000000000CCE4                 B.EQ            loc_CCA0
.text:000000000000CCE8                 B               loc_CCF4
.text:000000000000CCEC ; ---------------------------------------------------------------------------
.text:000000000000CCEC
.text:000000000000CCEC loc_CCEC                                ; CODE XREF: __dl__Z10do_dlclosePv+A8↑j
.text:000000000000CCEC                 LDR             X0, [X12,#0x18]
.text:000000000000CCF0                 CBNZ            X0, loc_CC50

翻译成最终c代码如下,这样就能解决刚才的不同手机的适配问题了

1
2
3
4
5
6
7
8
9
10
11
12
void* nmm=(char*)startr+realoff;
char *next=(char*)nmm+8;
unsigned long map= reinterpret_cast<unsigned long>(strstr);
unsigned long mapnext=*next;
mapnext=map%mapnext;
 
 
nmm=(long*)((char*)(*(long*)nmm)+mapnext*8);
 
long* final= reinterpret_cast<long *>((char *) (**(long **) nmm) + 0x18);
void* soinfo= reinterpret_cast<void *>(*final);
return static_cast<uint64 *>(soinfo);

那么又产生了下一个问题,就是如何拿到dl_g_soinfo_handles_map。dl_g_soinfo_handles_map是linker中的符号的值,但不是导出符号的值,基于此我没有在动态段中找到它对应的的符号,如下图只有寥寥的几个符号

那怎么办呢,我想到了可以通过节头表索引,直接打开/system/bin/linker64文件读它的节头表,比读段简单了许多,代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
int fd;
 void *start;
 struct stat sb;
 fd = open("/system/bin/linker64", O_RDONLY); /*打开/etc/passwd */
 fstat(fd, &sb); /* 取得文件大小 */
 start = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
 __android_log_print(6, "r0ysue", "%p", start);
 Elf64_Ehdr header;
 memcpy(&header, start, sizeof(Elf64_Ehdr));
 int secoff = header.e_shoff;
 int secsize = header.e_shentsize;
 int secnum = header.e_shnum;
 int secstr = header.e_shstrndx;
 Elf64_Shdr strtab;
 memcpy(&strtab, (char *) start + secoff + secstr * secsize, sizeof(Elf64_Shdr));
 int strtaboff = strtab.sh_offset;
 char strtabchar[strtab.sh_size];
 memcpy(&strtabchar, (char *) start + strtaboff, strtab.sh_size);
 Elf64_Shdr enumsec;
 int gotoff = 0;
 int gotsize = 0;
 int strtabsize = 0;
 int stroff = 0;
 for (int n = 0; n < secnum; n++) {
     memcpy(&enumsec, (char *) start + secoff + n * secsize, sizeof(Elf64_Shdr));
     if (strcmp(&strtabchar[enumsec.sh_name], ".symtab") == 0) {
         gotoff = enumsec.sh_offset;
         gotsize = enumsec.sh_size;
         __android_log_print(6, "r0ysue", "%x", gotsize);
     }
     if (strcmp(&strtabchar[enumsec.sh_name], ".strtab") == 0) {
         stroff = enumsec.sh_offset;
         strtabsize = enumsec.sh_size;
         __android_log_print(6, "r0ysue", "%x", stroff);
     }
 }
 int realoff=0;
 char relstr[strtabsize];
 Elf64_Sym tmp;
 memcpy(&relstr, (char *) start + stroff, strtabsize);
 
 for (int n = 0; n < gotsize; n = n + sizeof(Elf64_Sym)) {
     memcpy(&tmp, (char *)start + gotoff+n, sizeof(Elf64_Sym));
     if(tmp.st_name!=0&&strstr(relstr+tmp.st_name,"soinfo_handles_map"))
         realoff=tmp.st_value;
 }

总结

这样就完成了上面4个问题的解决,比较基础,主要是对elf文件格式的一个解析,我只是提供了一个例子,没有对数据进行加密,正常情况下我觉得还应该对dex中的so信息进行加密保护效果才更强,而且我的hook貌似不稳定,又崩溃的几率,感谢大家观看


【公告】看雪团队招聘安全工程师,将兴趣和工作融合在一起!看雪20年安全圈的口碑,助你快速成长!

收藏
点赞0
打赏
分享
最新回复 (0)
游客
登录 | 注册 方可回帖
返回