Java代码引起的NATIVE野指针问题（上）
朴英敏，小米MIUI部门。从事嵌入式开发和调试工作8年多，擅长逆向分析方法，主要负责解决安卓系统稳定性问题。 上周音乐组同事反馈了一个必现Native Crash问题，tombstone如下： pid:5028,tid:5028,name:com.miui.player>>>com.miui.player<<< signal11(SIGSEGV),code2(SEGV_ACCERR),faultaddr79801f28 r07ac59c98r100000000r2bea7b174r3400fc1b8 r4774c4c88r579801f28r6bea7b478r740c12bb8 r87c1b68e8r9778781e8slbea7b478fpbea7b414 ip00000001spbea7b148lr40c07031pc79801f28cpsr600f0010 backtrace: #00pc0000bf28<unknown> #01pc0002302f/system/lib/libhwui.so(android::uirenderer::OpenGLRenderer::callDrawGLFunction(android::Functor*,android::uirenderer::Rect&)+322) #02pc00015d91/system/lib/libhwui.so(android::uirenderer::DrawFunctorOp::applyDraw(android::uirenderer::OpenGLRenderer&,android::uirenderer::Rect&)+28) #03pc00014527/system/lib/libhwui.so(android::uirenderer::DrawBatch::replay(android::uirenderer::OpenGLRenderer&,android::uirenderer::Rect&,int)+74) #04pc00014413/system/lib/libhwui.so(android::uirenderer::DeferredDisplayList::flush(android::uirenderer::OpenGLRenderer&,android::uirenderer::Rect&)+218) #05pc0001d1cf/system/lib/libhwui.so(_ZN7android10uirenderer14OpenGLRenderer15drawDisplayListEPNS0_11DisplayListERNS0_4RectEi.part.47+230) #06pc0006820d/system/lib/libandroid_runtime.so 崩溃的原因是pc指向了一个没有可执行权限的内存地址上。 初步分析： 对应的代码如下: status_tOpenGLRenderer::callDrawGLFunction(Functor*functor,Rect&dirty){ if(mSnapshot->isIgnored())returnDrawGlInfo::kStatusDone; detachFunctor(functor); ... interrupt(); =>status_tresult=(*functor)(DrawGlInfo::kModeDraw,&info); 其中，Functor类重载了()操作符： classFunctor{ public: Functor(){} virtual~Functor(){} =>virtualstatus_toperator()(int/*what*/,void*/*data*/){returnNO_ERROR;} }; 因此，()操作其实就是调用了Functor类的一个虚函数，它的具体实现目前还不清楚。 对应的汇编代码如下： 23028:aa0baddr2,sp,#44 2302a:6803ldrr3,[r0,#0];r0是functor，r3=[r0]=functor.vtlb 2302c:689dldrr5,[r3,#8];r5=[r3+8]=[functor.vtlb+8]=Functor.operator() 2302e:47a8blxr5;callFunctor.operator() 崩溃时的寄存器值如下： r07ac59c98r100000000r2bea7b174r3400fc1b8 r4774c4c88r579801f28r6bea7b478r740c12bb8 r87c1b68e8r9778781e8slbea7b478fpbea7b414 ip00000001spbea7b148lr40c07031pc79801f28cpsr600f0010 可以看到，r5和pc值是相等的，可以知道，确定是崩溃在2302e这一行汇编代码中。 而查看寄存器对应的内存值，发现有点问题： memorynearr0: 7ac59c78000000180000001b735a9b3823831ef0 7ac59c8823831ef0735a9b500000001800000011 7ac59c9879822328777686980000001000000022 7ac59ca800000000000000000000000000000003 memorynearr3: 400fc1987c74c00000200000000000770d44acd8 400fc1a80000000000000000400fc1a8400fc1a8 400fc1b8400fc1b0400fc1b07c04acb87c78f008 400fc1c87c021d987c78ffc07983bbf07c04bfa8 [r0] = [7ac59c98] = 798223298，这个和r3值(400fc1b8)不一样， 同样 [r3+8] = [400fc1b8 + 8] = 7c04acb8，这个值也和r5值(79801f28)不一样。 这在平时的tombstone里是非常少见的! 乍一看非常不可思议，但仔细想想tombstone的生成过程，就能发现其中的问题。 原来寄存器信息是错位崩溃时的cpu context，保存在崩溃时的线程私有的信号栈和内核栈中，直到debuggerd去获取这个值，它是不会被修改的。 而内存是进程中的各个线程共享的，所以在发生异常到debuggerd打印内存信息这段过程中(其实是相对很长的一个过程)，别的线程是有可能修改内存值的。 为了证明别的线程在改这个内存值，在callDrawGLFunction()函数中的若干处打印了Functor和它的vtbl(虚函数表地址)值： status_tOpenGLRenderer::callDrawGLFunction(Functor*functor,Rect&dirty){ AOGI("functor=%p,vtbl=%p"); sleep(1); if(mSnapshot->isIgnored())returnDrawGlInfo::kStatusDone; AOGI("functor=%p,vtbl=%p"); sleep(1); detachFunctor(functor); ... AOGI("functor=%p,vtbl=%p"); sleep(1); interrupt(); AOGI("functor=%p,vtbl=%p"); sleep(1); status_tresult=(*functor)(DrawGlInfo::kModeDraw,&info); 抓到的log如下： 10-2721:19:45.79480278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x73648de0 10-2721:19:47.80180278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x73648de0 10-2721:19:48.80180278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x73648de0 10-2721:19:49.80180278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x73648de0 10-2721:19:50.80480278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x73648de0 10-2721:19:51.80480278027IOpenGLRenderer:functor=0x7a7b8530,vtbl=0x400fc1b8 可以确定确实有别的线程在修改这个值。 这里就存在两个可能性了： 1、别的线程也持有functor指针，并修改内容 2、functor是野指针，对应的内存已经还回系统，其他模块可任意使用。 而对象的vtbl一般是不会修改的，所以2的可能性更大一些。 为了查明是哪个线程在改，对functor指向的内存做了写保护操作： staticint**s_saved_vtbl=NULL; staticvoid*s_saved_functor=NULL; staticvoidmprotect_local(int**p){ //一旦发现vtbl有变化就将对应内存设置为只读 if(p!=s_saved_vtbl){ mprotect((void*)((unsignedint)s_saved_functor&0xfffff000),4096,PROT_READ); } sleep(1); } status_tOpenGLRenderer::callDrawGLFunction(Functor*functor,Rect&dirty){ int*ptr=(int*)functor; s_saved_functor=(void*)ptr; s_saved_vtbl=(int**)*ptr; if(mSnapshot->isIgnored())returnDrawGlInfo::kStatusDone; mprotect_local((int**)*ptr); detachFunctor(functor); mprotect_local((int**)*ptr); ... mprotect_local((int**)*ptr); interrupt(); status_tresult=(*functor)(DrawGlInfo::kModeDraw,&info); push到手机中复现问题，很容易抓到访问权限引起的crash。 而每次的crash的线程和位置都不一样，也就是不同的线程在不同的函数中读写这个地址。 这样基本上就确定是野指针问题，进入下一阶段的分析。 关于野指针： 所谓野指针就是一个对象被释放后又被使用，可能是释放的问题，也可能是使用的问题。 我们已经知道使用的位置，接下来要找出是从哪释放的。 找到释放对象的最笨的方法，是在free()函数里打印调用栈。 但这么做有两个问题： 1、log太量多，一秒内可能会有成千上万的malloc/free函数被调用。 2、打印调用栈的函数本身会调用free函数，这样会陷入死循环。 为了解决上面两个问题，需要用到hook技术。 关于hook技术： 要了解hook技术，得先了解外部函数的调用过程。 所谓外部函数就是外部模块中定义的函数。比如，libhwui.so中的某个源文件中调用了malloc函数，而这个malloc函数是libc.so中定义的。 当编译libhwui.so的这个源文件时，对应调用malloc的地方会生成如下的汇编代码: blxaddr 这里blx是arm的跳转指令，addr是目标地址，也就是malloc函数的地址，那这个malloc函数的地址如何确定? 这个编译的阶段是无法确定的，只有当运行时进程加载完libc.so以后，malloc函数的地址才能被确定。 所以编译器在编译的时候会在libbinder.so中留出一部分空间作为地址表，专门用于存放外部函数的地址，这个区域叫got表。 每一个本模块调用到的外部函数都对应got表中的一项。 当然got表里面的内容是在进程启动阶段，加载动态库时被连接器linker填充的。 而编译阶段我们只需要将代码写成： 1、从got表对应位置获取外部函数地址 2、跳转到这个外部函数的地址 这个动作需要由若干的指令来完成，所以跳转指令blx addr中的addr其实指向本模块的一组指令： blxcb74<malloc@plt> 这组指令所在的区域就是elf文件结构里的plt表，plt表中每一个外部函数都对应一个表项，如： 0000cb74 <malloc@plt>: cb74: e28fc600 add ip, pc, #0, 12 cb78: e28cca29 add ip, ip, #167936 ; cb7c: e5bcf1e8 ldr pc, [ip, #488]! ; 0000c8bc <free@plt>: c8bc: e28fc600 add ip, pc, #0, 12 c8c0: e28cca29 add ip, ip, #167936 ; c8c4: e5bcf3b8 ldr pc, [ip, #952]! ; 每一个plt表项都是做相同操作： 1、先获取got表中外目标函数对应的地址(前两行); 2、从got表中获取地址目标函数的地址，并赋给pc寄存器(第三行)。 下面给出got表和plt表在so文件中的位置： readelf -S libhwui.so [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 00000134 000134 000013 00 A 0 0 1 [ 2] .dynsym DYNSYM 00000148 000148 002420 10 A 3 1 4 [ 3] .dynstr STRTAB 00002568 002568 0056a4 00 A 0 0 1 [ 4] .hash HASH 00007c0c 007c0c 001134 04 A 2 0 4 [ 5] .rel.dyn REL 00008d40 008d40 002bc8 08 A 2 0 4 [ 6] .rel.plt REL 0000b908 00b908 000a78 08 A 2 7 4 =>[ 7] .plt PROGBITS 0000c380 00c380 000fc8 00 AX 0 0 4 [ 8] .text PROGBITS 0000d348 00d348 01ef30 00 AX 0 0 8 [ 9] .ARM.exidx ARM_EXIDX 0002c278 02c278 001fb8 08 AL 8 0 4 [10] .ARM.extab PROGBITS 0002e230 02e230 000930 00 A 0 0 4 [11] .rodata PROGBITS 0002eb60 02eb60 0036a4 00 A 0 0 4 [12] .fini_array FINI_ARRAY 00034010 033010 000004 00 WA 0 0 4 [13] .data.rel.ro PROGBITS 00034018 033018 001910 00 WA 0 0 8 [14] .init_array INIT_ARRAY 00035928 034928 00000c 00 WA 0 0 4 [15] .dynamic DYNAMIC 00035934 034934 000140 08 WA 3 0 4 =>[16] .got PROGBITS 00035a74 034a74 00058c 00 WA 0 0 4 [17] .data PROGBITS 00036000 035000 00025c 00 WA 0 0 4 [18] .bss NOBITS 0003625c 03525c 000068 00 WA 0 0 4 [19] .comment PROGBITS 00000000 03525c 000010 01 MS 0 0 1 [20] .note.gnu.gold-ve NOTE 00000000 03526c 00001c 00 0 0 4 [21] .ARM.attributes ARM_ATTRIBUTES 00000000 035288 00003e 00 0 0 1 [22] .gnu_debuglink PROGBITS 00000000 0352c6 000010 00 0 0 1 [23] .shstrtab STRTAB 00000000 0352d6 0000dc 00 0 0 1 我们的hook技术就是通过修改so的got表来截获so中的某些外部函数调用。 so的代码段是多个进程共享的，但它的数据段私有的，而got表就是数据段。 所以我们只修改music应用进程的libhwui.so的got表中free函数对应的项，影响范围将大大减少。 那改成什么值呢?一般是我们自己定义的函数，比如： voidinject_free(void*ptr){ ALOGI("freeptr=%p",ptr); dumpNativeStack(); dumpJavaStack(); free(ptr); } 为了不影响原来的逻辑，打印完debug信息，还是要调用原来被hook的函数。 有了hook技术后能完美的解决野指针中的两个问题，下面继续分析问题。 作者：朴英敏 来源：51CTO
