一. 開始調試
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 移除本地指定映射關係
以後就能夠開始調試了