高手談Android NDK C++ RTTI 分析

  本文意在說明Android NDK 在實現C++ RTTI時的相關數據結構，并從匯編角度分析其內存布局，以幫助理解RTTI的實現原理，同時，分析在逆向過程中如何利用RTTI恢復C++類名信息。
 
       用ndk-build編譯C++代碼時，默認的C++運行時庫（libstdc++)是不支持RTTI的， 需要在Application.mk與Android.mk中進行配置。其它可以選擇的C++運行時庫有GAbi++、STLport、GNU STL、LLVM libc++, 各種庫又分靜態鏈接庫與動態鏈接庫。其中中STLport的RTTI是借用了GAbi++中的實現，另外GNU STL、LLVM libc++的實現也與GAbi++非常相似（相關數據結構的命名、結構都相似, 可能是因為都是基于Itanium C++ ABI（鏈接[3]）？）。
       所以本文將選擇STLPort為C++運行時庫， 在Application.mk中配置:
       APP_STL := stlport_static
       在Android.mk中配置：
       LOCAL_CPP_FEATURES := rtti
       另外，本文使用 Android NDK 10c編譯，編譯abi為armeabi，編譯32位代碼時其默認使用GCC 4.8。若使用其它版本NDK或者其它編譯器，可能與本文分析結果有差異。

一、C++ RTTI 簡介
        RTTI是Runtime Type Identification的縮寫，即運行時類型識別。程序能夠借此使用基類的指針或引用，來檢查這些指針或引用所指的對象的實際派生類型。C++通過typeid與dynamic_cast來提供RTTI。typeid返回一個typeinfo對象的引用，它記錄了與類型相關的信息，后文將詳細分析這個結構；dynamic_cast用于安全而有效地進行向下轉型(down_cast)，即安全地將一個基類指針轉換為一個派生類指針。
它們的基本使用方法如下：
classes.h文件：

class Base
{
      public:
      Base();
      virtual ~Base();
      virtual void Func();
      private:
      int mMember;
};

class Deriver1 : public Base
            {
public:
            Deriver1();
            virtual ~Deriver1();
            virtual void Func();
private:
            int mDeriver1Member;
            };

class Deriver2 : public Base
            {
public:
            Deriver2();
            virtual ~Deriver2();
            virtual void Func();
private:
            int mDeriver2Member;
            };
　　

main.cpp文件：
int main()
{
     Base base;
     Deriver1 deriver1;
     Deriver2 deriver2;

     cout<<typeid(int).name()<<endl;
     cout<<typeid(Base).name()<<endl;
     cout<<typeid(base).name()<<endl;
     Base *pBase = &deriver1;
     cout<<typeid(pBase).name()<<endl;
     cout<<typeid(*pBase).name()<<endl;

     cout << pBase << endl;
     Driver1 *pDeriver1 = dynamic_cast<Deriver1*>(pBase);
     cout << pDeriver1 << endl;

     Driver2 *pDeriver2 = dynamic_cast<Deriver2*>(pBase); //正確，返回NULL
     cout << pDeriver2 << endl;

     pDeriver2 = (Deriver2*)pBase;//錯誤
     cout << pDeriver2 << endl;

     pDeriver2 = static_cast<Deriver2*>(pBase); //錯誤
     cout << pDeriver2 << endl;
     return 0;
}
編譯成可執行文件，push到android 手機上運行，輸出：
i <------- typeid(int).name()， 變量類型
4Base <------- typeid(Base).name(), 類名
4Base <------- typeid(base).name()， 變量
P4Base <------- typeid(pBase).name(), Base的指針類型
8Deriver1 <------- typeid(*pBase).name(), pBase實際指向一個Deriver1
0xbec87a20
0xbec87a20 <----- 正確的轉換，指向deriver1的基類指針可以轉換為Deriver1類型指針
0x00000000 <----- 正確的轉換，因為指向deriver1的基類指針并不能轉換為Deriver2類型指針
0xbec87a20 <----- 錯誤，若繼續使用，可能會導致內存訪問出錯，即將Dervier1當Deriver2用
0xbec87a20 <----- 錯誤，若繼續使用，可能會導致內存訪問出錯

P.S. 上面看到顯示的類名與我們定義的不完全一樣，是因為為了保證每個類名稱在程序中的唯一性，編譯器會通過一定的規則對原始類名進行改寫，如想了解這一規則，可以以name mangling為關鍵詞進行搜索。

二、RTTI 相關數據結構
       上文說到typeid將返回一個typeinfo對象的const引用，RTTI就是依賴typeinfo類及其派生類來實現的，下面介紹下這些類。
在NDK路徑下\android-ndk-r10c\sources\cxx-stl\gabi++\include\typeinfo文件中有定義這個類：
class type_info
{
      public:
      virtual ~type_info();
//....
      private:
//....
            const char *__type_name; // 這個字段記錄改寫過后的類名
}；
       在NDK路徑下\android-ndk-r10c\sources\cxx-stl\gabi++\src\cxxabi_defines.h有定義一些typeinfo的派生類，此處挑一些我們感興趣的類列舉：
class __shim_type_info : public std::type_info{....}

// 無基類的類的typeinfo類型
class __class_type_info : public __shim_type_info{.....}

//只有一個public非虛基類，且基類偏移為0的類的typeinfo
class __si_class_type_info : public __class_type_info{
public:
           virtual ~__si_class_type_info();
           const __class_type_info *__base_type;
//......
}

// 有基類但不滿足 __si_class_type_info 約束條件的其它類的typeinfo
class __vmi_class_type_info : public __class_type_info{
public:
           virtual ~__vmi_class_type_info();
           unsigned int __flags;
           unsigned int __base_count;
           __base_class_type_info __base_info[1];
//......
}

// Used in __vmi_class_type_info
            struct __base_class_type_info{
public:
           const __class_type_info *__base_type;
           long __offset_flags;
// .......
}
        以第1小節中的程序為例，Base、Driver1的對象的內存布局如下：


        deriver2的內存布局與deriver1相似，這里沒有重復畫出。從上圖可以看到，每一個類的虛表索引為-1的位置存放著typeinfo的指針，并根據類的不同，該指針指向不同的typeinfo派生類實例。比如Base類無基類，所以其typeinfo指針指向__class_type_info的實例；而Deriver1繼承自Base, deriver1在其偏移為0的位置包含一個public非虛基類實例，所以它的typeinfo指針指向__si_class_type_info實例。使用dynamic_cast的時候，正是根據這些typeinfo指針來判斷一個基類指針是否可以轉換為一個派生類指針。而且由上可見，若一個待操作的類沒有虛函數表， typeid也只能返回其靜態類型。
下面我們通過反編譯代碼來驗證上面的關系圖。

三、逆向過程中利用RTTI恢復類名
       將第1小節中生成的可執行程序用IDA Pro打開，此處選用obj\local\armeabi\目錄下未經過strip的程序，以方便分析。
根據相關字符串，可以很快定位各個類的typeinfo信息：

各個類的虛函數表結構：

       細心的朋友可能有疑問，為什么會產生兩個構造函數？對于這個問題，可以參考鏈接[4]。
可見，從反編譯的代碼看，虛表、typeinfo信息關系與第3節中描述一致。
       對于通常的逆向分析，都沒有沒有上面的符號信息的。所以我們可以通過RTTI信息來恢復類名及其類間關系，為逆向工作提供便利。可以按以下步驟進行：

1. 定位__class_type_info, __si_class_type_info, __vmi_class_type_info虛函數表。

2. 查找對這些虛函數表的引用，我們可以得到這些typeinfo派生類的實例地址。而這些實例中type_name字段就表示原始類名。

3. 根據引用這些實例地址，就可以得到相關類的虛表地址，此處我們可以根據上一步得到的原始類名重命名虛表指針。

4. 查找引用這些虛表指針的代碼，通過都是類的構造函數，于是我們又可以重命名這些構造函數了。

以上步驟我們都可以通過IDAPython腳本自動完成。

四、小結
       其實上面只是分析了最簡單的單繼承情景，還有諸如多繼承、虛繼承等情景待分析，由于相關typeinfo類已經例出，相信分析難度不大。
       另外需要注意的一個地方，在反匯編后的代碼中，并不是直接引用虛表地址，而是引用虛表地址－8的位置，用這個位置+8寫入當作虛擬指針。
       以上分析過程與結論都來自個人認知，如有錯誤，歡迎指正。

網易云捕-高效的APP質量跟蹤平臺