idaandroid调试

A. IDA6.5不支持远程调试android x86的虚拟器么

调试so必须可以。
Debugger→Attach→Remote Armlinux/Android debugger
Attach进程
CTRL+S找so
计算偏移找地址，F2下断后就OK
触发断点

B. 如何调试Android SO中的init函数

1.Root设备

Root权限下才能快乐调试。
使用市面上的各种Root师傅工具。

2.连接设备

将设备打开调试模式在开发者选项里。
将IDA安装目录中dbgsrv文件夹下的android_server推送到设备系统目录并赋可执行权限。在高于IDA6.6版本才能调试高版本android，此时调试低版本Android SO时，需要使用的是android_nonpipe。
在PC端输入命令:

adb shell su
adb shell android_server的路径/android_server

保持上面窗口，在命令行窗口进行端口转发：

adb forward tcp:23946 tcp:23946

为什么是23946呢，IDA和push进设备的android_server默认用都用23946端口进行通讯。当然可以修改。

3.打开IDA

附加或者启动进程的过程不再多言。

4.定位INIT函数

比较便捷的方法是找一份与设备同系统版本号的android源码。解析执行SO文件的地方在linker.c（cpp）中。
因为不同版本有差异，我就不上图了。

高版本时在do_dlopen()下的CallConstructors()里面，但是编译系统时往往将其和find_library融合在其父函数中，查找时需注意。一个简便方法是源码中搜索“INIT”四个字.
先将设备中的linker pull出来用IDA分析来确定调用INIT的具体位置。
因为linker在Android进程中加载非常早，所以它在IDA中的地址可以不用修正直接拿来用。

5.下断在INIT

下断点后，执行Apk中触发加载该SO的功能。
正常情况下就能停在该SO的INIT前了。

C. 如何对android vold进程进行二进制动态调试

为了保护关键代码被逆向分析，一般放在应用程序初始化过程中，如init_array，或jni_onload函数里进行检查代码执行。 1.调试检测 对调试器的检测（ida，gdb,strace, ltrace等调试工具） a.父进程检测 b.当前运行进程检测

D. android怎么动态调试dex

1.1 安装JDK
java环境的搭建请自行查找资料，这里不做详述。
1.2 安装Android SDK
下载地址：http://developer.android.com/sdk/index.html。
下载完安装包后解压到任意一目录，然后点击运行SDK Manager.exe，然后选择你需要的版本进行安装，如图：

1.3 安装Eclipse集成开发环境
下载地址：http://www.eclipse.org/downloads。选择Eclipse for Mobile Developers，解压到任意目录即可。
1.4 创建Android Virtual Device
动态调试可以用真实的手机来做调试环境，也可以用虚拟机来做调试环境，本文采用虚拟机环境。因此创建虚拟机步骤如下：
1打开Eclipse –>windows->Android Virtual Device

2点击Create，然后选择各个参数如图：

这里Target 就是前面步骤中安装的SDK 选择任意你觉得喜欢的版本就可以。点击OK 就创建完毕。
1.5 安装 APK改之理
这个是一个很好用的辅助调试的软件，请自行搜索下载。
1.6 安装 IDA6.6
IDA6.6开始支持安卓APP指令的调试，现该版本已经提供免费下载安装，请自行搜搜。
0x02 Dalvik指令动态调试
2.1 准备工作
安卓APP应用程序后缀为apk，实际上是一个压缩包，我们把它改后缀为rar打开如图：

其中classes.dex是应用的主要执行程序，包含着所有Dalvik指令。我们用APK改之理打开apk，软件会自动对其进行反编译。反编译后会有很多smail文件，这些文件保存的就是APP的Dalvik指令。
在APK改之理里双击打开AndroidManifest.xml，为了让APP可调试，需要在application 标签里添加一句android:debuggable="true" 如图：

然后点击保存按钮，然后编译生成新的apk文件。接着打开Eclipse –>windows->Android Virtual Device，选择刚才创建的虚拟机，然后点击start，虚拟机便开始运行。偶尔如果Eclipse启动失败，报错，可以同目录下修改配置文件：

把配置参数原本为512的改为256 原本为1024的改为512，然后再尝试启动。
在SDK安装目录有个命令行下的调试工具adb shell，本机所在目录为E:\adt-bundle-windows-x86-20140702\sdk\platform-tools，把adb.exe注册到系统环境变量中，打开dos命令行窗口执行adb shell 就可以进入APP命令行调试环境，或者切换到adb所在目录来执行adb shell。

这里先不进入adb shell，在DOS命令行下执行命令：adb install d:\1.apk 来安装我们刚才重新编译好的APK文件。安装完毕会有成功提示。
2.2 利用IDA动态调试
将APP包里的classes.dex解压到任意一目录，然后拖进IDA。等待IDA加载分析完毕，点击Debugger->Debugger Options如图

按图所示勾选在进程入口挂起，然后点击Set specific options 填入APP包名称和入口activity 如图：

其中包的名称和入口activity 都可以通过APK改之理里的AndroidManifest.xml 文件获取：

1
2
3

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.simpleencryption">
<application android:allowBackup="true" android:debuggable="true" android:icon="@drawable/creakme_bg2" android:label="@string/app_name" android:theme="@style/AppTheme">
<activity android:label="@string/app_name" android:name=".MainActivity">


然后在IDA点击Debugger->Process Options

其他默认不变，端口这里改为8700。这里默认端口是23946，我在这里困扰了很久，就是因为这个端口没有改为8700所致。然后我们看看这个8700端口是怎么来的。在Android SDK里提供了一款工具DDMS，用来监视APP的运行状态和结果。在SDK的TOOLS目录有个DDMS.BAT的脚步，运行后就会启动DDMS。由于我的本机安装了SDK的ADT插件，DDMS集成到了Eclips中，打开Eclips->Open perspective->ddms就启动了DDMS。
如图所示：

在DDMS选中某个进程后面就会注释出它的调试端口,本机这里是8700。
到此所有的工作就准备就绪，然后就可以下断点来调试该APP了。我们在APK改之理中在com目录下查看smali文件 发现MainActivity.smali里有一个感兴趣的函数getPwdFromPic()，那么我们就对它下断以跟踪APP的运行。
在IDA里搜索字符串getPwdFromPic，发现onClick有调用该函数
我们在onClick 函数开始位置按F2下断如图：

然后点击上图中绿色三角形按钮启动调试如图：

调试过程中有一个问题出现了很多次，浪费了我大量的时间，就在写文章的时候，操作时还是遇到了这样的问题。就是点击启动后IDA提示can’t bind socket，琢磨了很久终于找到原因了，当打开过一次DDMS后 每次启动Eclips都会启动DDMS 而8700端口正是被这个DDMS给占用了，然后每次都会启动失败，解决办法就是 虚拟机运行起来后关闭掉Eclips，这时一切就正常了！
事例中是一个APP crackme 提示输入密码才能进入正确界面。这个时候我们输入123，点击登陆，IDA中断在了我们设置断点的地方，这时选中ida->debugger->use source level debugger，然后点击ida->debugger->debugger windows->locals打开本地变量窗口，如图：

然后按F7或F8单步跟踪程序流程，同时可以观察到变量值的变化，也可以在IDA右键选择图形视图，可以看到整个APP执行的流程图:

如上图所示 变量窗口中我们输入了123 被转化成的密码是么广亡，pw变量也显示出了正确的密码，其实这个时候已经很容易判断出正确密码了。
0x03 Andoid原生动态链接库动态调试
通常为了加密保护等措施，有时dex执行过程中会调用动态链接库文件，该文件以so为后缀，存在于APP文件包里。

这里我们以动态附加的方式来调试原生库。
3.1 准备工作
1、将IDA->dbgsrv目录下的android_server拷贝到虚拟机里，并赋予可执行权限
DOS命令分别为：
adb shell pull d:\ android_server /data/data/sv
adb shell chmod 755 /data/data/sv

2、启动调试服务器android_server
命令：adb shell /data/data/sv
服务器默认监听23946端口。
3、重新打开DOS窗口进行端口转发，命令：
adb forward tcp:23946 tcp:23946 如图：

3.2 利用IDA进行动态调试
1、虚拟机里启动要调试的APP 2、启动IDA，打开debugger->attach->remote Armlinux/andoid debugger

端口改为23946 其他保持不变，点击OK

如上图，选中要调试的APP 的数据包名，然后点击OK。
正常情况下，IDA会把APP进程挂起。
3、由于当前程序不是在动态链接库领空，这时我们要重新打开一个IDA，用它打开需要调试的so文件，找到需要下断的位置的文件偏移，并做记录，然后关闭后面打开的这个IDA。
4、在原IDA界面按下ctrl+s键，找到并找到需要调试的so，同时记录该文件的加载基址。然后点击OK 或者cancel按钮关闭对话框。
5、按下快捷键G 输入基址+文件偏移所得地址，点击OK 就跳转到SO文件需要下断的地方，这时按下F2键设置断点。当APP执行到此处时便可以断下来。
3.3 在反调试函数运行前进行动态调试
程序加载so的时候，会执行JNI_OnLoad函数，做一系列的准备工作。通常反调试函数也会放到JNI_OnLoad函数里。进行4.2中第2步时也许会遇到如下情况：

这时APP检测到了调试器，会自动退出，那么这时调试策略需要有所改变。
接着4.1第3步后，在DOS命令行执行命令：
adb shell am start -D -n com.yaotong.crackme/com.yaotong.crackme.MainActivity

来以调试模式启动APP 如图：
com.yaotong.crackme是APP包名称，com.yaotong.crackme.MainActivity是执行入口 这些可以用APK改之理查看。

这时由于APP还未运行，那么反调试函数也起不了作用，按照4.2中第2步把APP挂起。这时IDA会中断在某个位置

然后点击debugger->debugger opions设置如下：

点击OK 后按F9运行APP，然后再DOS命令下执行命令：
jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700

这时APP会断下来，然后按照4.2中的3、4、5补找到JNI_OnLoad函数的地址并下断，然后按F9 会中断下来。然后便可以继续动态跟踪调试分析。

E. ida android-server在哪

防止二次打包一般会用到如下几种手段:1.Java代码中加入签名校验(直接修改smali文件绕过)2.NDK中加入签名校验(ida查看直接hex修改就可以绕过)3.利用二次打包工具本身的缺陷阻止打包(manifest欺骗，图片修改后缀等等)

F. 如何把ida 的android

微软有一个工具叫做dependencywalker或者VisualStudio附带的一个工具mpbin可以查看dll的导出函数名称，函数参数和调用方式（比如__cdecl或__stdcall）在工具里无法显示，需要使用IDA或者OllyDbg等反汇编器将DLL反汇编，通过定位导出函数结尾的retn指令判断参数个数和调用方式。由被调用者平栈通常为__stdcall，由调用者平栈则是__cdecl，平栈的字节数除以字长（例如retn0C中的0C在x86下是除以4，在x64下除以8）即可得到参数个数（这也是通常，具体问题可能需要具体分析），至于参数意义，那就完全需要头文件支持，或者分析反汇编代码的意义了。在IDA里，还可以使用F5快捷键将反汇编代码转换为C代码，能稍稍方便一点。最后一个问题，至于思路的话，你可以查看DLL的导出函数，然后使用Detours类库将原来的函数HOOK一下，做个旁路，在HOOK函数中打印调用内容，这样你在日志文件或调试输出中就能看见调用规律了。纯属个人建议。还有一个工具叫做APIMonitor，能够检测API调用。

G. ida pro 查看android的dex文件怎么看

根据android的官方文档，如果要调试一个App里面的dex代码，必须满足以下两个条件中的任何一个：
1.App的AndroidManifest.xm中Application标签必选包含属性android:debuggable="true"；
2./default.prop中ro.debuggable的值为1；

由于正常的软件发布时都不会把android:debuggable设置为true，所以要达成条件1，需要对app进行重新打包，这不仅每次分析一个App都重复操作，而且很多软件会对自身进行校验，重打包后执行会被检测到，所以想办法满足第2个条件是个一劳永逸的办法，我实际使用的方法就是满足第二个条件。
由于default.prop是保存在boot.img的ramdisk中，这部分每次重新启动都会重新从rom中加载，所以要到目的必须修改boot.img中的ramdisk并重新刷到设备中。

H. apk调试方法求助

方法一：

1、使用apktool的-d选项反编译apk文件

java -jar apktool.jar d -d target.apk -o output

2、在AndroidManifest的application节点中添加 android:debuggable="true"

3、在入口点的类的onCreate中添加如下代码等待调试

invoke-static{}, Landroid/os/Debug;->waitForDebugger()V

4、回编译apk

java -jar apktool.jar b -d output -o newTarget.apk

5、对apk进行签名

java -jar signapk.jar testkey.x509.pem testkey.pk8 newTarget.apk signed.apk

6、将签名后的apk安装到手机或者模拟器上

adb install signed.apk

7、将1中的smali代码导入到Android Studio中

file→open→output目录→下断点

8、打开Monitor查找相应的进程

运行→monitor 或者Tools ->Android ->Android Device Monitor

9、配置远程调试选项

Run→Editor Configurations→Defaults→Remote，点击+号新增一个，Host为localhost，Port为8700

10、打开apk，点击绿色的小虫子就可以开始调试了

方法二：无需修改原apk文件

1、用 Android killer等工具反编译apk文件

2、将smali代码入到Android Studio中，安装smaliidea插件

File→Settings→Plugins→Install plugin from disk…→Restart

3、配置远程调试选项，打开monitor

4、使用adb以debug方式启动apk

adb shell am start -D -n package/activitiyname

5、下断点开始调试，在watch中添加寄存器http://www.315nk.com/不清楚追问，希望能帮助到您

I. IDA怎么调试Android的send函数，求教

安卓手机用ida在apk执行前动态调试其so中的函数

方法1
1、解包对方APK，插入一个：对应SMALI： android.os.SystemClock.sleep(20000);const-wide/16 v0, 0x2710 #20秒invoke-static {v0, v(X-1)}, Landroid/os/SystemClock;->sleep(J)V这里(X-1)对应.local X。

2
另外，有的包在你要调试的那个SO里面有签名保护，反正你重新打了包之后会导致程序运行崩溃，这个相比JAVA修改困难些，建议你用那个签名漏洞来打包。事实上我调试那个SO也遇到过这样，然后打了个签名漏洞的包嵌入的延时函数就可以了。
方法2

1) am start -D -n 包名/类名；

2） IDA pro attach 进程， 设置新线程，加载so时断点，continue；

3） 打开ddms， 查看调试端口， jdb attach port；

4） 这个时候应该已经断在新线程，或者加载so处了，在你感兴趣的so处停下来；

5） 另外用ida 打开so，查看你感兴趣的函数偏移， 加上你感兴趣的so的基地址，打上断点，continue， 就大功告成了。

注意事项

windows下ida6.1不行，linux ida 6.4可以，不知是ida的问题还是windows的问题，你可以在linux下用wine测一下。
经验内容仅供参考，如果您需解决具体问题(尤其法律、医学等领域)，建议您详细

J. IDA pro 获取不到全部的app进程列表

其实就是用户的问题，真机usb链接电脑后，adb shell进去后是$，su转为#，然后执行android_server，这样是不行的，必须adb shell进入后就是#，这样才表示是root在操作shell。

解决方案：建议在电脑上装个靠谱助手，然后再测试。经测试，可以解决如题问题。