张天爱大尺度吻戏视频:【转】 Android调试的必杀技——反汇编
来源:百度文库 编辑:中财网 时间:2024/04/30 11:42:10
Android调试的必杀技——反汇编
- 发布于: 2010 六月 27
- 目录: 嵌入式, 技术
- 评论: 1 条评论
在移植Android过程中会遇到很多Crash的情况,尤其是启动Android过程中。一般这些问题都可以通过看代码能解决,当然也有一些比较“妖娆”的问题,非常难找到头绪,在logcat日志也只会打印一些崩溃的堆栈,这些信息很难帮助我们定位问题。根据个人一个实例来介绍一下在Android移植过程中反汇编的用法。
首先先看一下我遇到的一个logcat关于Crash的打印信息:
I/DEBUG ( 1417): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***I/DEBUG ( 1417): Build fingerprint: 'generic/sdk/generic/:Eclair/ECLAIR/eng.simon.20100607.133011:eng/test-keys'I/DEBUG ( 1417): pid: 1434, tid: 1460 >>> system_server <<通过这个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文件来定位。文件内容如下:
# 0x7F100000 - 0x7FFF0000 Thread 0 stack# 0x7F000000 - 0x7F0FFFFF Linker# 0x70000000 - 0x7EFFFFFF Prelinked System Libraries# 0x60000000 - 0x6FFFFFFF Prelinked App Libraries# 0x50000000 - 0x5FFFFFFF Non-prelinked Libraries# 0x40000000 - 0x4FFFFFFF mmap'd stuff# 0x10000000 - 0x3FFFFFFF Thread Stacks# 0x00080000 - 0x0FFFFFFF .text / .data / heap# core system librarieslibdl.so 0x7EFF0000libc.so 0x7EF00000libstdc++.so 0x7EEF0000libm.so 0x7EE90000liblog.so 0x7EE80000libcutils.so 0x7EE00000libthread_db.so 0x7ED80000libz.so 0x7ED00000libevent.so 0x7EC80000libssl.so 0x7EC00000libcrypto.so 0x7EA00000libffi.so 0x7E980000libsysutils.so 0x7E900000# bluetoothliba2dp.so 0x7E780000audio.so 0x7E700000input.so 0x7E680000libhcid.so 0x7E600000libbluedroid.so 0x7E580000libbluetooth.so 0x7E500000libdbus.so 0x7E400000# extended system librarieslibril.so 0x7E300000libreference-ril.so 0x7E000000libwpa_client.so 0x7DC00000libnetutils.so 0x7DB00000# core dalvik runtime supportlibandroid_servers.so 0x7D900000#libicudata.so 0x7D700000libicuuc.so 0x7D500000libicui18n.so 0x7D380000libandroid_runtime.so 0x7D2a0000libnativehelper.so 0x7D200000libdvm-MIPS.so 0x7D180000libdvm.so 0x7D000000# graphicslibpixelflinger.so 0x7CF00000libsurfaceflinger.so 0x7CD00000libagl.so 0x7CC00000libGLESv1_CM.so 0x7CB00000libGLESv2.so 0x7CA00000libOpenVG_CM.so 0x7C900000libOpenVGU_CM.so 0x7C800000libEGL.so 0x7C700000libexif.so 0x7C500000libui.so 0x7C400000libsgl.so 0x7C000000# audiolibspeech.so 0x7BA00000libaudio.so 0x7B900000libsonivox.so 0x7B800000libsoundpool.so 0x7B700000libvorbisidec.so 0x7B600000libmedia_jni.so 0x7B500000libmediaplayerservice.so 0x7B480000libmedia.so 0x7B400000libFFTEm.so 0x7B300000libaudioflinger.so 0x7B200000# assorted system librarieslibsqlite.so 0x7B100000libexpat.so 0x7B000000libwebcore.so 0x7A000000libutils.so 0x79D00000libcameraservice.so 0x79C80000libhardware.so 0x79C70000libhardware_legacy.so 0x79C00000libapp_process.so 0x79B00000libsystem_server.so 0x79A00000libime.so 0x79800000libgps.so 0x79700000libcamera.so 0x79680000libqcamera.so 0x79400000# pv librarieslibpvasf.so 0x79200000libpvasfreg.so 0x79100000libomx_sharedlibrary.so 0x790e0000libopencore_download.so 0x79000000libopencore_downloadreg.so 0x78f00000libopencore_net_support.so 0x78e00000libopencore_rtsp.so 0x78d00000libopencore_rtspreg.so 0x78c00000libopencore_author.so 0x78a00000libomx_aacdec_sharedlibrary.so 0x789c0000libomx_amrdec_sharedlibrary.so 0x78990000libomx_amrenc_sharedlibrary.so 0x78970000libomx_avcdec_sharedlibrary.so 0x78958000libomx_m4vdec_sharedlibrary.so 0x78930000libomx_m4venc_sharedlibrary.so 0x788f0000libomx_mp3dec_sharedlibrary.so 0x788d0000libopencore_mp4local.so 0x78800000libopencore_mp4localreg.so 0x78700000libopencore_player.so 0x78400000# opencore hardware supportlibmm-adspsvc.so 0x783c0000libOmxCore.so 0x783a0000libOmxMpeg4Dec.so 0x78370000libOmxH264Dec.so 0x78340000libOmxVidEnc.so 0x78310000libopencorehw.so 0x78300000libopencore_common.so 0x78180000#libqcomm_omx.so 0xA5A00000# libraries for specific apps or temporary librarieslibcam_ipl.so 0x6F000000libwbxml.so 0x6E800000libwbxml_jni.so 0x6E400000libxml2wbxml.so 0x6E000000libaes.so 0x6DC00000libdrm1.so 0x6D800000libdrm1_jni.so 0x6D400000libwapcore.so 0x6D000000libstreetview.so 0x6CC00000libwapbrowsertest.so 0x6C800000libminiglobe.so 0x6C400000libearth.so 0x6C000000libembunit.so 0x6BC00000libneon.so 0x6B800000libjni_example.so 0x6B400000libjni_load_test.so 0x6B000000libjni_lib_test.so 0x6AC00000librunperf.so 0x6A800000libctest.so 0x6A700000libUAPI_jni.so 0x6A500000librpc.so 0x6A400000libtrace_test.so 0x6A300000libsrec_jni.so 0x6A200000libcerttool_jni.so 0x6A100000libacc.so 0x6A000000libbinder.so 0x69F00000libskia.so 0x69000000libGLES_android.so 0x68800000libRS.so 0x68000000libaudiopolicygeneric.so 0x67c00000librs_jni.so 0x67800000# Sigma Designs librarieslibcore.so 0x61400000libdisplay.so 0x61000000libdrm.so 0x60c00000libhw.so 0x60800000libplayback.so 0x60000000从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0x7EF00000,libsqlite.so加载到0x7B100000。我们可以对照一下Crash的log信息也对应的上,说明这个文件在Android加载过程中起了作用。
下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具,我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。
mips-linux-gnu-objdump -dS libc.so > libc.dumpmips-linux-gnu-objdump -dS libsqlite.so > libsqlite.dump这样就可以得到libc和libsqlite的符号表。然后通过符号表,Android加载动态库的基地址,log信息就可以定位到那个函数出问题了,如果你对对应平台汇编语言熟悉的话可以阅读汇编代码找出问题。本文就不具体讲怎样利用这个三个文件信息了。有了这个三个文件,稍一研究就可以明白怎样分析了。
一般情况下,Crash都不是Android源码的问题,最有可能的是内核有些模块没有编译进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。
以上是个人摸索出来的方法,如果你有更好的方法或者我的方法有错误,请你不吝指教。