① IDA pro 獲取不到全部的app進程列表
其實就是用戶的問題，真機usb鏈接電腦後，adb shell進去後是$，su轉為#，然後執行android_server，這樣是不行的，必須adb shell進入後就是#，這樣才表示是root在操作shell。
解決方案：建議在電腦上裝個靠譜助手，然後再測試。經測試，可以解決如題問題。
② Android studio 開發app，如何抵抗動態調試，反調試代碼怎麼寫請寫上詳細代碼。
為了保護關鍵代碼被逆向分析，一般放在應用程序初始化過程中，如init_array，或jni_onload函數里進行檢查代碼執行。
1.調試檢測
對調試器的檢測（ida，gdb,strace, ltrace等調試工具）
a.父進程檢測
b.當前運行進程檢測
例如對android_server進程檢測。針對這種檢測只需將android_server改名就可繞過
[objc] view plain
pid_t GetPidByName(const charchar *as_name) {
DIR *pdir = NULL;
struct dirent *pde = NULL;
FILEFILE *pf = NULL;
char buff[128];
pid_t pid;
char szName[128];
// 遍歷/proc目錄下所有pid目錄
pdir = opendir("/proc");
if (!pdir) {
perror("open /proc fail.\n");
return -1;
}
while ((pde = readdir(pdir))) {
if ((pde->d_name[0] < '0') || (pde->d_name[0] > '9')) {
continue;
}
sprintf(buff, "/proc/%s/status", pde->d_name);
pf = fopen(buff, "r");
if (pf) {
fgets(buff, sizeof(buff), pf);
fclose(pf);
sscanf(buff, "%*s %s", szName);
pid = atoi(pde->d_name);
if (strcmp(szName, as_name) == 0) {
closedir(pdir);
return pid;
}
}
}
closedir(pdir);
return 0;
}
c.讀取進程狀態(/proc/pid/status)
State屬性值T 表示調試狀態，TracerPid 屬性值正在調試此進程的pid,在非調試情況下State為S或R, TracerPid等於0
d.讀取 /proc/%d/wchan
下圖中第一個紅色框值為非調試狀態值，第二個紅色框值為調試狀態：
[objc] view plain
static void get_process_status(pid_t pid,const char* info,charchar *outline)
{
FILEFILE *fp;
char filename;
char line = {0};
snprintf( filename, sizeof(filename), "/proc/%d/status", pid );
fp = fopen( filename, "r" );
if ( fp != NULL )
{
while ( fgets( line, sizeof(line), fp ) )
{
if ( strstr( line, info ) )
strcpy(outline,line);
}
fclose( fp ) ;
}
return ;
}
static int getProcessStatus(int pid)
{
char readline = {0};
int result = STATUS_ELSE;
get_process_status(pid,"State",readline);
if(strstr(readline,"R"))
result = STATUS_RUNNING;
else if(strstr(readline,"S"))
result = STATUS_SLEEPING;
else if(strstr(readline,"T"))
result = STATUS_TRACING;
return result;
}
static int getTracerPid(int pid)
{
char readline = {0};
int result = INVALID_PID;
get_process_status(pid,"TracerPid",readline);
charchar *pidnum = strstr(readline,":");
result = atoi(pidnum + 1);
return result;
}
static int getWchanStatus(int pid)
{
FILEFILE *fp= NULL;
char filename;
char wchaninfo = {0};
int result = WCHAN_ELSE;
char cmd = {0};
sprintf(cmd,"cat /proc/%d/wchan",pid);
LOGANTI("cmd= %s",cmd);
FILEFILE *ptr; if((ptr=popen(cmd, "r")) != NULL)
{
if(fgets(wchaninfo, 128, ptr) != NULL)
{
LOGANTI("wchaninfo= %s",wchaninfo);
}
}
if(strncasecmp(wchaninfo,"sys_epoll\0",strlen("sys_epoll\0")) == 0)
result = WCHAN_RUNNING;
else if(strncasecmp(wchaninfo,"ptrace_stop\0",strlen("ptrace_stop\0")) == 0)
result = WCHAN_TRACING;
return result;
}
e. ptrace 自身或者fork子進程相互ptrace
[objc] view plain
ptrace me
if (ptrace(PTRACE_TRACEME, 0, 1, 0) < 0) {
printf("DEBUGGING... Bye\n");
return 1;
}
void anti_ptrace(void)
{
pid_t child;
child = fork();
if (child)
wait(NULL);
else {
pid_t parent = getppid();
if (ptrace(PTRACE_ATTACH, parent, 0, 0) < 0)
while(1);
sleep(1);
ptrace(PTRACE_DETACH, parent, 0, 0);
exit(0);
}
}
f. 防止mp
利用Inotify機制，對/proc/pid/mem和/proc/pid/pagemap文件進行監視。inotify API提供了監視文件系統的事件機制，可用於監視個體文件，或者監控目錄。具體原理可參考：http://man7.org/linux/man- pages/man7/inotify.7.html
偽代碼：
[objc] view plain
void __fastcall anitInotify(int flag)
{
MemorPagemap = flag;
charchar *pagemap = "/proc/%d/pagemap";
charchar *mem = "/proc/%d/mem";
pagemap_addr = (charchar *)malloc(0x100u);
mem_addr = (charchar *)malloc(0x100u);
ret = sprintf(pagemap_addr, &pagemap, pid_);
ret = sprintf(mem_addr, &mem, pid_);
if ( !MemorPagemap )
{
ret = pthread_create(&th, 0, (voidvoid *(*)(voidvoid *)) inotity_func, mem_addr);
if ( ret >= 0 )
ret = pthread_detach(th);
}
if ( MemorPagemap == 1 )
{
ret = pthread_create(&newthread, 0, (voidvoid *(*)(voidvoid *)) inotity_func, pagemap_addr);
if(ret > 0)
ret = pthread_detach(th);
}
}
void __fastcall __noreturn inotity_func(const charchar *inotity_file)
{
const charchar *name; // r4@1
signed int fd; // r8@1
bool flag; // zf@3
bool ret; // nf@3
ssize_t length; // r10@3
ssize_t i; // r9@7
fd_set readfds; // @2
char event; // @1
name = inotity_file;
memset(buffer, 0, 0x400u);
fd = inotify_init();
inotify_add_watch(fd, name, 0xFFFu);
while ( 1 )
{
do
{
memset(&readfds, 0, 0x80u);
}
while ( select(fd + 1, &readfds, 0, 0, 0) <= 0 );
length = read(fd, event, 0x400u);
flag = length == 0;
ret = length < 0;
if ( length >= 0 )
{
if ( !ret && !flag )
{
i = 0;
do
{
inotity_kill((int)&event);
i += *(_DWORD *)&event + 16;
}
while ( length > i );
}
}
else
{
while ( *(_DWORD *)_errno() == 4 )
{
length = read(fd, buffer, 0x400u);
flag = length == 0;
ret = length < 0;
if ( length >= 0 )
}
}
}
}
g. 對read做hook
因為一般的內存mp都會調用到read函數，所以對read做內存hook，檢測read數據是否在自己需要保護的空間來阻止mp
h. 設置單步調試陷阱
[objc] view plain
int handler()
{
return bsd_signal(5, 0);
}
int set_SIGTRAP()
{
int result;
bsd_signal(5, (int)handler);
result = raise(5);
return result;
}
③ android怎麼動態調試dex
根據android的官方文檔，如果要調試一個apk裡面的dex代碼，必須滿足以下兩個條件中的任何一個：
1.apk中的AndroidManifest.xml文件中的Application標簽包含屬性android:debuggable=」true」
2./default.prop中ro.debuggable的值為1
由於一般軟體發布時都會把android:debuggable設置為false，所以要達成條件1需要反編譯原apk，修改AndroidManifest.xml並進行重新打包，這樣不僅麻煩，而且很多軟體進行了加固，要破解很難。所以想辦法滿足第2個條件是個一勞永逸的辦法。
由於default.prop是保存在boot.img的ramdisk中，這部分每次重新啟動都會重新從rom中載入，所以要到目的必須修改boot.img中的ramdisk並重新刷到設備中。修改步驟如下：
1.從Google官方網站下載到boot.img
2.使用工具（abootimg，gunzip, cpio）把boot.img完全解開，獲取到default.prop
3.修改default.prop
4.把修改後的文件重新打包成boot_new.img
5.使用fastboot工具把boot_new.img刷入設備（fastboot flash boot boot_new.img）
具體可參考： http://www.cnblogs.com/goodhacker/p/4106139.html
由於我們這篇文章的重點是如何動態調試dex代碼，所以我們就假設該dex是可調試的。
1.用ida打開apk文件，選擇dex文件進行載入
2.設置debugger選項，Debugger->Debugger options->Set specific options，按如圖1所示進行設置，然後一路確定返回
3.找到要下斷點的位置，游標移到要下斷點的那一行，按f2下斷點
4.手機開啟調試選項，連接到電腦，運行apk
5.選中IDA pro窗口，按f9運行，如果出現如圖2的畫面，就說明設置成功，可以進行動態調試了。
④ 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 會中斷下來。然後便可以繼續動態跟蹤調試分析。
⑤ 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並重新刷到設備中。