最近公司研究一个变速软件,本来就是一个很小的功能,就是在用户游戏的时候能够加速减速这个功能,
并且对于网络的游戏并没有做要求,实现的思路主要是给目标进程注入自己写的so,然后再hook住gettimeofday,
clock_gettime 这两个比较关键的刷帧的时间函数,改变其返回值,达到刷帧变慢或者变快的效果,然后
实现游戏变速的功能。


  功能要求那是相当的简单,但是实现起来发现却没有那么简单,有几个技术关键点要完成,并且对月linux下的so
加载要有一些了解才行。

  技术关键点

  1 能够顺利的将自己编写的so注入到目标进程中

  2 能够正确找到目标进程调用要hook的函数的so库,并且替换其got表中的地址,
    换成自己的函数地址。

  3 直接找到目标进程中的地址空间中的目标函数的地址,比如send,recv,gettimeofday 这些基础的
    函数一定在libc.so中也就是glibc中的,所以根据目标进程的maps表这些函数的实现地址也一定在
    libc.so所占的地址空间中。找到这个函数的实际地址以后,首先通过mprotect 修改页面的属性,
    让页面属性能够写入,然后喂入一段自己编写的汇编代码,跳转到自己的函数里面,达到hook的目的。

  4 使用ptrace函数附着到目标进程以后,截获相关的系统调用,当系统调用出现以后,修改系统调用的
    参数,达到修改函数实现的目的。

  上面几个关键的技术点,其中2和3 需要以1 为基础点,而4 则可以脱离1独立存在。

  下面分别描述一下几个技术的关键点的实现方法和需要注意的事项。

  关键技术点1  将自己编写的so注入到目标进程中

  这个的实现网上一搜索一大堆,关键核心点就是attach到目标进程,然后找到目标进程的mmap函数的地址
  调用mmap函数
  通过 map_base = (uint8_t *)regs.ARM_r0; 得到mmap函数的返回值,这个时候就可以将精心编写好的
  一小段汇编代码写入到这个map_base这个地址上了,其实这个地址是目标进程的地址。
  并且权限是 parameters[2] = PROT_READ | PROT_WRITE | PROT_EXEC;  // prot
  可读,可写,可执行的。
  同时还需要得到 目标进程的 dlopen  dlsym dlclose 这三个加载库的函数的地址,这是需要在汇编中
  调用的,这些都准备好了以后,给汇编代码准备了栈空间传递了要注入的库的路径的空间以后,然后将
  那一小段汇编代码拷贝到目标进程的地址  
  ptrace_writedata( target_pid, remote_code_ptr, local_code_ptr, 0x400 );

  接着就执行
   memcpy( ®s, &original_regs, sizeof(regs) );
   regs.ARM_sp = (long)remote_code_ptr;
   // change pc to execute instructions at remote_code_ptr
   regs.ARM_pc = (long)remote_code_ptr;  

   sp指针是r13 堆栈寄存器,然后pc是r15 执行寄存器,强制赋值以后就执行汇编代码了,
   而汇编代码也很简单
   就是调用了一下 dlopen 将要注入的so注入到目标进程中去了,仅仅将so注入到目标进程中其实没有什么
   用的,所以需要dlsym 中获取要注入的so库的一个函数,再调用一下这个函数,这个函数要干很多事情的
   最重要的就是修改目标进程中加载的so的got表,修改成要hook的自己的函数,这部分具体要在关键技术点
   2 详细说明,记住这个函数是 so_entry 即可

   关于技术关键点1 就这么点东西需要分析的。当然最后还需要父进程的上下文,然后detach子进程。

  关键技术点2:

  根据第一步,将编写好的so给注入到目标进程了,而注入的so就开始 so_entry
  so_entry 这个函数首先需要注入者写好要修改目标进程的哪个so库,和哪个函数,哪个函数还好说,毕竟做
  不同的功能hook的函数是很明确的,比如你做游戏变速,肯定要hook gettimeofday和clock_gettime 这些
  函数了,你做流量监控肯定要hook  connet send recvmsg 这些函数了,你做电话或者短信防火墙就要hook
  电话或者短信相关的函数。
  但是修改目标进程的哪个so库,的确是一个比较麻烦的事情,android上层应用普通的进程都会挂载很多很多
  的so库,并且你修改了a.so 的got表,但是java应用程序是通过b.so 调用的要hook函数,那么对不起,你
  同样没有办法hook住想要的hook的函数,因为你只是修改了a.so中的got表的该函数的跳转地址,所以这种方
  法的弊端在于你需要要了解你要hook的函数在这个应用中使用哪个so库调用的,或者你把maps表所有的so的  
  got表都修改一遍,反正就是挺麻烦的。

  其中具体方法就是 do_hook 这个函数,找到so的基地址以后,再通过解析elf文件,找到got表地址的偏移
  量,根据这个偏移量再加上基地址  得到got表的地址 got_shdr->sh_offset + module_base

  接着再把 所在页的
      mprotect((uint32_t *) entry_page_start, page_size, PROT_READ | PROT_WRITE);
  属性变换成可读可写,最后将hookfun的地址替换got表的跳转地址
   // replace GOT entry content with hook_func's address
   memcpy((uint32_t *) entry_addr, &hook_func, sizeof(uint32_t));

  下面的这段trace分析很好的说明了这个过程

maps表(部分)

400dc000-4011f000 r-xp 00000000 103:02 565       /system/lib/libc.so
4011f000-40122000 rw-p 00043000 103:02 565       /system/lib/libc.so

40729000-407cb000 r-xp 00000000 103:02 585       /system/lib/libdvm.so
407cc000-407ce000 r--p 000a2000 103:02 585       /system/lib/libdvm.so
407ce000-407cf000 rw-p 000a4000 103:02 585       /system/lib/libdvm.so
407cf000-407d4000 rw-p 000a5000 103:02 585       /system/lib/libdvm.so

41c20000-41c23000 r-xp 00000000 103:04 588087    /data/data/com.example.socketcomm/lib/libsocketclient.so
41c23000-41c25000 rw-p 00002000 103:04 588087    /data/data/com.example.socketcomm/lib/libsocketclient.so

5c06c000-5c070000 r-xp 00000000 00:0c 84482      /dev/libhook.so
5c070000-5c071000 r--p 00003000 00:0c 84482      /dev/libhook.so
5c071000-5c072000 rw-p 00004000 00:0c 84482      /dev/libhook.so


11-20 13:12:31.509: I/cheatecore-hookso(19676): [+] lib loaded ...
11-20 13:12:31.509: I/hook(19676): [+] base address of /system/lib/libdvm.so: 0x40729000(libdvm.so 虽然got表中有send函数,但是应用并没有通过这个库来调用
socket 的send函数,所以修改这个so的got表项其实是没有用处的)
11-20 13:12:31.517: I/hook(19676): [+] got entry offset of send: 0xa5f40
11-20 13:12:31.517: I/hook(19676): [----]1-407cef40
11-20 13:12:31.517: D/hook(19676): [+] hook_fun addr: 0x5c06d24d(这个地址在libhook.so中r-xp)
11-20 13:12:31.517: D/hook(19676): [+] got entry addr: 0x407cef40(这个地址在libdvm.so中rw-p)
11-20 13:12:31.517: D/hook(19676): [+] original addr: 0x400f5f15(这是send的真实实现地址,在glib也就是libc.so这个库中r-xp中)
11-20 13:12:31.517: D/hook(19676): [+] page size: 0x1000
11-20 13:12:31.517: D/hook(19676): [+] entry page start: 0x407ce000(mprotect 修改页属性的时候需要从整页开始)
11-20 13:12:31.517: I/cheatecore-hookso(19676): [+] module_path /system/lib/libdvm.so function send  address is : 0x400f5f15


11-20 13:12:31.524: I/hook(19676): [+] base address of /data/data/com.example.socketcomm/lib/libsocketclient.so: 0x41c20000
(libsocketclient.so got表中有send函数,但是应用通过这个库来调用socket 的send函数,所以修改这个so的got表项是可以生效的)
11-20 13:12:31.524: I/hook(19676): [+] got entry offset of send: 0x3fdc
11-20 13:12:31.524: I/hook(19676): [----]1-41c23fdc
11-20 13:12:31.524: D/hook(19676): [+] hook_fun addr: 0x5c06d24d
11-20 13:12:31.524: D/hook(19676): [+] got entry addr: 0x41c23fdc
11-20 13:12:31.524: D/hook(19676): [+] original addr: 0x400f5f15 (这是send的真实实现地址,在glib也就是libc.so这个库中r-xp中和上面的一样)
11-20 13:12:31.524: D/hook(19676): [+] page size: 0x1000
11-20 13:12:31.524: D/hook(19676): [+] entry page start: 0x41c23000
11-20 13:12:31.524: I/cheatecore-hookso(19676): [+] module_path /data/data/com.example.socketcomm/lib/libsocketclient.so function send  address is : 0x400f5f15  

    目前这种调试方法在实践中有一个问题,就是在变速 unity3d比如神庙逃亡 这类游戏的时候,即便修改了所有的so的got表,发现也没有生效,这个问题尚在研究,
    当中。



   关键技术点3:  这个方法比较关键技术点2来说可以说是简单粗暴,不美观,但是很霸道,分析elf文件,查找got表等操作都和关键技术点2是一样,唯一不同的是
   对于 original addr: 0x400f5f15(这是send的真实实现地址,在glib也就是libc.so这个库中r-xp中)
   这个send函数的真实地址的处理方式不同,因为已经找到send函数的地址了

    entry_page_start = PAGE_START(original_addr, page_size);
   LOGD("[+] entry page start: 0x%x", entry_page_start);
   result = mprotect((uint32_t *) entry_page_start, page_size, PROT_READ  | PROT_WRITE | PROT_EXEC);

  找到页的边沿地址,然后通过mprotect 函数给其赋予 PROT_READ  | PROT_WRITE | PROT_EXEC 这样权限
  在那个地址上喂入一段汇编代码,完成跳转即可。


  关键技术点4:
  只是以前实验了一下,觉得原理可行,但是尚未深究...


  附件有个例子,里面包含两个程序,一个是android应用,一个是命令行的注入程序,里面实现了so注入和拦截socket 的send recv函数,但是没有是实现直接向地址里面写入自己的汇编代码的功能...