Android逆向工程

在Root前提下，我們可以使用Hooker方式綁定so庫，通過逆向方式篡改數值，從而達到所謂破解目的。然而，目前無論是軟件加固方式，或是數據處理能力後臺化，還是客戶端數據真實性驗證，都有了一定積累和發展，讓此“懶技術”不再是破解修改的萬金油。再者，閱讀彙編指令，函數指針替換，壓棧出棧等技術需要一定技術沉澱，不利於開發同學上手。

兩年前，也是因爲懶，很懶，非常懶，堆積了足夠的動力，寫了一個基於人工模擬方式，對一個特定規則的遊戲進行暴力破解。我們都知道，人工模擬方式，繞過了大量防破解技術，只要還是人機交互模式，並且滿足一定的遊戲規則，基本是無法防禦的。

技術實現原理

因涉及到安全方面的考量，本文主要圍繞技術實現原理和關鍵技術點進行闡述。

技術要求：

支持多分辨率
支持多點觸摸
支持輸入速率動態變更
處理能力峯值需要達到30fps

實現方式分三步：

劫持屏幕
分析數據
模擬輸出

1.劫持屏幕

先說說劫持屏幕，做過截屏功能的同學應該清楚，Root了之後能訪問設備“dev/graphic”文件夾，裏面有fb0, fb1, fb2三個screen buffer文件。這裏用到的是fb0文件。

拋出一個問題，當前主流屏幕分辨率都在1920*1080區間，一張圖片的緩存能去到2M左右，要達到30fps的性能指標，光是屏幕數據的讀寫耗時，就滿足不了要求。怎麼做呢？

一般在做圖像處理的時候都會想到parallel programming。然而，這裏的圖片是時間相關的，不適宜採用多線程任務派發。

懶人一番思量後，發現一條捷徑，共享內存讀取，請看以下代碼。

mapbase = mmap(0, **mapsize, PROT_READ, MAP_SHARED, fd, offset);

這行代碼廣泛存在於各個截屏代碼片段中，精髓在於PROT_READ 和 MAP_SHARED上。先科普一下mmap參數中這兩個參數吧。

prot ：映射區域的保護方式。可以爲以下幾種方式的組合：

PROT_EXEC 映射區域可被執行
PROT_READ 映射區域可被讀取
PROT_WRITE 映射區域可被寫入
PROT_NONE 映射區域不能存取

flags ：影響映射區域的各種特性。在調用mmap()時必須要指定MAP_SHARED 或MAP_PRIVATE。

MAP_FIXED 如果參數start所指的地址無法成功建立映射時，則放棄映射，不對地址做修正。通常不鼓勵用此旗標。
MAP_SHARED 對映射區域的寫入數據會複製迴文件內，而且允許其他映射該文件的進程共享。
MAP_PRIVATE 對映射區域的寫入操作會產生一個映射文件的複製，即私人的“寫入時複製”（copy on write）對此區域作的任何修改都不會寫回原來的文件內容。
MAP_ANONYMOUS建立匿名映射。此時會忽略參數fd，不涉及文件，而且映射區域無法和其他進程共享。
MAP_DENYWRITE只允許對映射區域的寫入操作，其他對文件直接寫入的操作將會被拒絕。
MAP_LOCKED 將映射區域鎖定住，這表示該區域不會被置換（swap）。

因爲我們不需要寫屏，所以prot只需要採用PORT_READ；而我們期望避免屏幕數據的多次創建，flags就需要用到MAP_SHARED，這樣文件句柄fd指向的內存塊數據就會實時變更，無需多次創建，拷貝，釋放數據。

2.分析數據

截取到屏幕數據就好辦了，對每一幀進行數據處理，這裏完全就是算法問題了。懶人都用搓算法，大概的思路就是：7*7宮格，對於所有相連的兩個同色item做了橫向映射表和縱向映射表，然後輪尋處理5連，4連和3連。裏面還有一些涉及到實現細節的映射表重置與預判，因爲不是本文重點，就帶過了。

void Handle_X_Combination() {

    LOGE("Handle_X_Combination");

    gen_Horizontal_Matrix(6);

    get_Horizontal_X_Match();

    gen_Vertical_Matrix(0, 6);

    get_Vertical_X_Match();
}

下面是程序運行時的Log信息片段，以供大家參考。

3. 模擬輸出

算法會輸出當前屏幕的一個模擬手勢操作隊列，最精彩的當然放到最後，也是此工程的技術點，怎麼模擬輸出手勢的問題。

Android所給予的截屏和模擬操作分別爲 adb screenshot 和 adb shell sendevent (根據android版本，有些機型用的是input event，記得沒錯的話～)
所有需要adb處理的指令，都不能採用高併發方式調用，要不然要麼機器重啓，要麼指令堵塞。所以adb這條路不通。
怎麼辦呢？

懶人又一番思量後，linux系統大都採用文件buffer，直接將指令寫文件吧。其實adb也是寫文件，不過adb做了一層轉譯，這裏涉及到設備層指令代碼，不同機型定義的指令代碼不盡相同。

要完成此任務，首先要弄清楚幾件事情：

一個點擊事件的構成是怎樣的
一個滑動事件的構成多了什麼
事件的指令代碼分別代表什麼

萬能的adb給了我一些思路，adb shell getevent，會打印出當前event的指令。再科普一下，event有很多，包括compass_sensor，light_sensor，pressure_sensor，accelerometer_sensor等等。
我們這裏監聽的是，touchscreen_sensor。

有了上面的指導信息，要構建一個模擬操作函數就很容易了。操作屏幕打印出想要的模擬的手勢，然後寫下來就好了。一共會有這麼幾個模擬操作函數需要創建：

void simulate_long_press_start_event(int touch, int fromX, int fromY); void simulate_long_press_hold_event(int touch, int fromX, int fromY); void simulate_long_press_end_event(int touch); void simulate_press_event(int touch, int fromX, int fromY); void simulate_move_event(int touch, int fromX, int fromY, int toX, int toY);

下面給出一個我寫好的範例出來，大家可以依葫蘆畫瓢，把剩下的寫好。

void simulate_press_event(int touch, int fromX, int fromY) {

    pthread_mutex_lock(&global.writeEventLock);

    LOGE("simulate_press_event");

    INPUT_EVENT event;

    // 0. Multi-Touch
    // 此項目非必要，因爲沒有用到多點觸摸，是另一個項目使用到了
    event.type = 0x3;
    event.code = 0x2f;
    event.value = touch;
    write(global.fd_event, &event, sizeof(event));

    // 1. ABS_MT_TRACKING_ID:
    // 理論上必要，因爲Android事件輸入是批量處理的，需要用到輸入id，
    // 但是這裏偷懶使用了同步鎖，並且沒有多點觸摸需求，所以不會有Tracking_ID串擾問題，也就不需要記數了
    event.type = 0x3;
    event.code = 0x39;
    event.value = global.event_id > 60000 ? 10 : global.event_id++;
    write(global.fd_event, &event, sizeof(event));

    // 2. At screen coordinates:
    // 觸摸點x，y座標
    event.type = 0x3;
    event.code = 0x35;
    event.value = fromX;
    write(global.fd_event, &event, sizeof(event));
    event.type = 0x3;
    event.code = 0x36;
    event.value = fromY;
    write(global.fd_event, &event, sizeof(event));

    // 4. Sync
    // 數據同步到設備
    event.type = 0x0;
    event.code = 0x0;
    event.value = 0x0;
    write(global.fd_event, &event, sizeof(event));

    event.type = 0x3;
    event.code = 0x39;
    event.value = 0xffffffff;
    write(global.fd_event, &event, sizeof(event));

    // 4. Pure event separator:
    // 結束符
    event.type = 0x0;
    event.code = 0x0;
    event.value = 0x0;
    write(global.fd_event, &event, sizeof(event));

    pthread_mutex_unlock(&global.writeEventLock);
}

爲了大家對Android逆向有一個簡單的理解，我們看下面幾個問題。

首先，請大家查閱源碼：
frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardware.cpp

截取其中關鍵的兩段：

渲染方式聲明：

#ifdef EGL_ANDROID_swap_rectangle  
    if (extensions.hasExtension("EGL_ANDROID_swap_rectangle")) {  
        if (eglSetSwapRectangleANDROID(display, surface,  
                0, 0, mWidth, mHeight) == EGL_TRUE) {  
            // This could fail if this extension is not supported by this  
            // specific surface (of config)  
            mFlags |= SWAP_RECTANGLE;  
        }  
    }  
    // when we have the choice between PARTIAL_UPDATES and SWAP_RECTANGLE  
    // choose PARTIAL_UPDATES, which should be more efficient  
    if (mFlags & PARTIAL_UPDATES)  
        mFlags &= ~SWAP_RECTANGLE;  
#endif

具體渲染操作：

void DisplayHardware::flip(const Region& dirty) const  
{  
    checkGLErrors();  

    EGLDisplay dpy = mDisplay;  
    EGLSurface surface = mSurface;  

#ifdef EGL_ANDROID_swap_rectangle      
    if (mFlags & SWAP_RECTANGLE) {  
        const Region newDirty(dirty.intersect(bounds()));  
        const Rect b(newDirty.getBounds());  
        eglSetSwapRectangleANDROID(dpy, surface,  
                b.left, b.top, b.width(), b.height());  
    }  
#endif  

    if (mFlags & PARTIAL_UPDATES) {  
        mNativeWindow->setUpdateRectangle(dirty.getBounds());  
    }  

    mPageFlipCount++;  
    eglSwapBuffers(dpy, surface);  
    checkEGLErrors("eglSwapBuffers");  

    // for debugging  
    //glClearColor(1,0,0,0);  
    //glClear(GL_COLOR_BUFFER_BIT);  
}

這段代碼主要用來檢查系統的主繪圖表面是否支持EGL_ANDROID_swap_rectangle擴展屬性。如果支持的話，那麼每次在調用函數eglSwapBuffers來渲染UI時，都會使用軟件的方式來支持部分更新區域功能，即：先得到不在新髒區域裏面的那部分舊髒區域的內容，然後再將得到的這部分舊髒區域的內容拷貝回到要渲染的新圖形緩衝區中去，這要求每次在渲染UI時，都要將被渲染的圖形緩衝區以及對應的髒區域保存下來。注意，如果系統的主繪圖表面同時支持EGL_ANDROID_swap_rectangle擴展屬性以及部分更新屬性，那麼將會優先使用部分更新屬性，因爲後者是直接在硬件上支持部分更新，因而性能會更好。

在Android源碼中有以下對framebuffer的結構定義：
hardware/libhardware/include/hardware/gralloc.h

typedef struct framebuffer_device_t {  
    struct hw_device_t common;  

    /* flags describing some attributes of the framebuffer */  
    const uint32_t  flags;  

    /* dimensions of the framebuffer in pixels */  
    const uint32_t  width;  
    const uint32_t  height;  

    /* frambuffer stride in pixels */  
    const int       stride;  

    /* framebuffer pixel format */  
    const int       format;  

    /* resolution of the framebuffer's display panel in pixel per inch*/  
    const float     xdpi;  
    const float     ydpi;  

    /* framebuffer's display panel refresh rate in frames per second */  
    const float     fps;  

    /* min swap interval supported by this framebuffer */  
    const int       minSwapInterval;  

    /* max swap interval supported by this framebuffer */  
    const int       maxSwapInterval;  

    int reserved[8];  

    int (*setSwapInterval)(struct framebuffer_device_t* window,  
            int interval);  

    int (*setUpdateRect)(struct framebuffer_device_t* window,  
            int left, int top, int width, int height);  

    int (*post)(struct framebuffer_device_t* dev, buffer_handle_t buffer);  

    int (*compositionComplete)(struct framebuffer_device_t* dev);  

    void* reserved_proc[8];  

} framebuffer_device_t;

以上聲明中，成員函數compositionComplete用來通知fb設備device，圖形緩衝區的組合工作已經完成。引用參考［2］的文章說明，此函數指針並沒有被使用到。那麼，我們就要找到在哪裏能夠獲取得到屏幕渲染完成的信號量了。

這個問題建議大家先行閱讀所有引用參考文章。然後因爲懶，這裏就直接給出大家結論，過程需參考surfaceflinger的所有源碼。

我們都知道Android在渲染屏幕的時候，一開始用到了double buffer技術，而後的4.0以上版本升級到triple buffer。buffer的緩存是以文件內存映射的方式存儲在dev\graphics\fb0路徑。每塊buffer置換的時候，會有唯一的，一個，信號量（注意修飾語）拋給應用層，接收方是我們經常用到的SurfaceView控件。SurfaceView內的OnSurfaceChanged() API 即是當前屏幕更新的信號量，除此之外，程序無從通過任何其他官方API形式獲取屏幕切換的時間點。這也是Android應用商場爲何沒有顯示當前任意屏幕的FPS數值的軟件（補充一下，有，需要Root，用到的就是本文後續介紹的技術。準確來說，是本文實現了一遍他們的技術）。

本文將在稍後的獨立章節說明如何實現強行暴力獲取埋在系統底層surfaceflinger service內的信號量。

Hooker 代碼注入

系統屏幕切換所用到的函數是在surfaceflinger內的elfswapbuffer()函數，要獲取得系統屏幕切換的信號量，需要劫持surfaceflinger service內的elfswapbuffer()函數，替換成我們自己的newelfswapbuffer()函數，並在系統每次調用newelfswapbuffer()函數時，此向JNI層拋出一個信號量，這樣就能強行獲得屏幕切換狀態量。

而，這樣做，需要用到hooker技能，向系統服務注入一段代碼，勾住elfswapbuffer()函數的ELF表地址，然後把自己的newelfswapbuffer()函數地址替換入ELF表內。在程序結束後，需要逆向實現一遍以上操作，還原ELF表。

程序用到了以下兩個核心文件：

一個文件負責注入系統服務，另一個負責感染系統程序。

Inject surfaceflinger

int main(int argc, char** argv) {

    pid_t target_pid;
    target_pid = find_pid_of("/system/bin/surfaceflinger");
    if (-1 == target_pid) {
        printf("Can't find the process\n");
        return -1;
    }

    //target_pid = find_pid_of("/data/test");
    inject_remote_process(target_pid, argv[1], "hook_entry",  argv[2], strlen(argv[2]));

    return 0;  
}

Infect surfaceflinger

int hook_entry(char * argv) {

    LOGD("Hook success\n");

    LOGD("pipe path:%s", argv);

    if(mkfifo(argv, 0777) != 0 && errno != EEXIST) {
        LOGD("pipe create failed:%d",errno);
        return -1;
    } else {
        LOGD("pipe create successfully");
    }

    LOGD("Start injecting\n");

    elfHook(LIB_PATH, "eglSwapBuffers", (void *)new_eglSwapBuffers, (void **)&old_eglSwapBuffers);

    while(1){

        int fPipe = open(argv, O_TRUNC, O_RDWR);
        if (fPipe == -1) {
            LOGD("pipe open failed");
            break;
        } else {
            LOGD("pipe open successfully");
        }

        char command[10];
        memset(command, 0x0, 10);

        int ret = read(fPipe, &command, 10);
        if(ret > 0 && strcmp(command, "done") == 0) {
            LOGD("ptrace detach successfully with %s", command);
            break;
        } else {
            LOGD("ret:%d received command: %s", ret, command);
        }

        // close the pipe
        close(fPipe);

        usleep(100);

    }

    elfHook(LIB_PATH, "eglSwapBuffers", (void *)old_eglSwapBuffers, (void **)&new_eglSwapBuffers);

}

我們能看到以上代碼還用到了pipe管道通訊，那是因爲注入的是一段二進制可執行代碼，而我們在退出程序時需要與此二進制代碼通訊，以便正常退出。

關於代碼的hook，大家可以參考之前的文章：點擊打開鏈接

xiangzhihong8 博客專家

發佈了1002 篇原創文章 · 獲贊 2000 · 訪問量 414萬+

他的留言板關注

Android逆向工程

技術實現原理

1.劫持屏幕

2.分析數據

3. 模擬輸出

Hooker 代碼注入

如何使用 JS 判斷用戶是否處於活躍狀態

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

android插件化之路

android 特賣列表倒計時卡頓問題

AnimatedPathView實現自定義圖片標籤

Android動態加載入坑指南

Android逆向工程

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結