android调试 反汇编

android调试　反汇编  

转：http://www.apkbus.com/forum.php?mod=viewthread&tid=577
在移植Android过程中会遇到很多Crash的情况，尤其是启动Android过程中。一般这些问题都可以通过看代码能解决，当然也有一些比较“妖娆”的问题，非常难找到头绪，在logcat日志也只会打印一些崩溃的堆栈，这些信息很难帮助我们定位问题。根据个人一个实例来介绍一下在Android移植过程中反汇编的用法。

       首先先看一下我遇到的一个logcat关于Crash的信息，我们来看看效果图：



       通过这个log信息我们可以看到libc.so崩溃了，再研究堆栈发现是libsqilte.so引起的，那么具体是哪一个函数崩溃了呢？这里面没有信息。另外内核加载动态库是动态加载的，就算我们反汇编出来libc.so和libsqlite.so，符号表也没有办法和log中地址对应上，除非我们能知道内核加载libc.so和libsqlite.so的基地址，这样我们就可以通过偏移找到相应的函数了。很幸运，Android确实规定了系统中的大部分库的内核加载地址。文件的位置在build/core下，有对应平台的map文件，比如：Arm平台文件名叫做prelink-linux-arm.map，Mips平台叫做prelink-linux-mips.map。我是在Mips平台出的问题，所以应该用prelink-linux-mips.map文件来定位。文件内容如下：





       从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0x7EF00000，libsqlite.so加载到 0x7B100000。我们可以对照一下Crash的log信息也对应的上，说明这个文件在Android加载过程中起了作用。

       下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具，我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。

Java代码：

1. mips-linux-gnu-objdump -dS libc.so > libc.dump
   
2. mips-linux-gnu-objdump -dS libsqlite.so > libsqlite.dump

复制代码

这样就可以得到libc和libsqlite的符号表。然后通过符号表，Android加载动态库的基地址，log信息就可以定位到那个函数出问题了，如果你对对应平台汇编语言熟悉的话可以阅读汇编代码找出问题。本文就不具体讲怎样利用这个三个文件信息了。有了这个三个文件，稍一研究就可以明白怎样分析了。

        一般情况下，Crash都不是Android源码的问题，最有可能的是内核有些模块没有编译进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。

        这些就是提供给我们的方法，在出现这样的事情的时候不要一下子全部删掉代码，也不要把项目给删掉。可以用用我们eoe提供的这个方法看看能不能给调试好。希望这个反汇编能给大家一些帮助。