smali调试总结
一. 开始调试
smali调试从最早的重打包用各种JAVA IDE进行调试, 到后来的可以不用重打包用xposed插件, 在到最后的修改系统源码刷机或者修改boot.img刷机一劳永逸
apk可调试可以为下面几个点满足一个几个,
1. invoke-static {}, Landroid/os/Debug;->waitForDebugger()V
2. AndroidManifest.xml中Application注明android:debuggable为true
3. 修改系统/system/build.prop或者default.prop让ro.debuggable=1即可调试所有进程,然而直接修改会出现问题
linux系统下可以用getprop和setprop命令来读写, Android系统下只能读取,
Android下可以通过System.getProperty("ro.debuggable");来获取指定的属性
system/build.prop和default.prop，都是init进程来进行解析的, 这些ro开头的属性信息只能init进程进行修改
所以对于ro.debuggable属性我们可以
①. 修改系统源码, 编译android源码，然后刷入到设备中
这个过程我已经做成功过了,参考之前的文章<<编译android源码绕过反调试>>
②. 直接导出手机里面boot.img, 然后修改里面的ro,debuggable, 然后刷机回去(对于第三方没有源码的手机这样做是有意义的)
我没有做过, 看雪上有人做过了
<<修改Nexus5的boot.img - 打开系统调试>>
③. 第三用一些别人写的第三方工具
比如mprop, 这个的原理是注入到init进程进行修改
当然需要root权限, 开启selinux之后, 可能需要忽略安全策略选项
可能不兼容所有的android设备, 当然肯定是需要root权限的
或者使用xposed的插件, tx应急安全响应中心有一个dbopener也可以实现类型的效果
之前网上流行的smalidea无源码调试android程序估计也是类似的方法, XInstaller插件
总结一下就是:
方法3不用重打包, 方法1, 2都需要重打包
我们熟悉了解调试的流程, 我们就可以在流程上做手脚, 来进行反调试, 当然如何进行反调试又是另外一个话题了
重打包的话, 可以看我之前写的一个脚本程序, 可以一键重打包, 当然脚本写的还不够完美
<<一键调试脚本的使用>>
启动并等待调试器
安装完apk之后, 我们可以通过adb shell命令调试的方式启动apk
adb shell am start -D -n 包名/主Activity
二. 映射原理
adb shell ps | grep antivirus
u0_a36 5766 154 907116 29496 ffffffff b7544d11 S com.qihoo.antivirus
adb forward tcp:8700 jdwp:5766
这里说明下为什么要这样做, 该命令的格式如下:
adb forward [协议名]:[本地端口号] [协议名]:[远程端口号]
这样就完成了一个映射关系, 发到远程端口的数据都会映射到本地指定的端口上,实质上就是客户端和服务端的关系
8700端口号可以随便给, 比如你需要用Android Studio来链接调试器, 就在配置远程调试器界面加上
刚刚那里映射为8700 AndroidStudio里面就填多少
当然也可以使用DDMS, ddms会默认从8600开始映射列表起第一个app
不过ddms和手动adb forward会有冲突, 开启ddms之后就会出问题
当然建议用第一种方法, 这样可以写成脚本完成自动化, 当然这样就需要注意使用logcat了
小贴士:
当我们adb forward了很多次之后, 我们可以使用如下命令来管理
adb forward --list 查看当前所有映射关系
adb forward --remove--all 移除所有映射管理
adb forword --remove tcp:8700 移除本地指定映射关系
之后就可以开始调试了
