iOS可執行檔的簡單反ida

標籤：style   blog   http   io   ar   color   os   使用   sp   

ida就不用我就廢話了，這篇主要講解如何通過對mach－o檔案簡單的更改達到反ida靜態分析的目的。

先說一下mach－o檔案格式的節。

?

?

1. struct?section?{?/*?for?32-bit?architectures?*/??
2. ????char????????sectname[16];???/*?name?of?this?section?*/??
3. ????char????????segname[16];????/*?segment?this?section?goes?in?*/??
4. ????uint32_t????addr;???????/*?memory?address?of?this?section?*/??
5. ????uint32_t????size;???????/*?size?in?bytes?of?this?section?*/??
6. ????uint32_t????offset;?????/*?file?offset?of?this?section?*/??
7. ????uint32_t????align;??????/*?section?alignment?(power?of?2)?*/??
8. ????uint32_t????reloff;?????/*?file?offset?of?relocation?entries?*/??
9. ????uint32_t????nreloc;?????/*?number?of?relocation?entries?*/??
10. ????uint32_t????flags;??????/*?flags?(section?type?and?attributes)*/??
11. ????uint32_t????reserved1;??/*?reserved?(for?offset?or?index)?*/??
12. ????uint32_t????reserved2;??/*?reserved?(for?count?or?sizeof)?*/??
13. }; ?

屬性的主要作用是告訴載入，本節要載入到記憶體的虛擬位址（addr），大小（size），及節在檔案物理地址的位移(offset)。

實際上mach－o檔案格式詳細的指導了載入器如何負載檔案到記憶體，但是ios並沒有完全按照格式來載入，對可執行檔合法性的驗證只是做到了segment一層，對於節section一層並沒有驗證，載入器只是簡單的將段地址線性映射到記憶體，粒度很大，沒有細化到節，所以節屬性在載入的時候沒有用，但是ida是個好學生，完全依靠mach格式來分析檔案，bug就出現了。（實際上在win下，od也有類似的bug），那麼下面我們來手動變更檔，達到ida不能載入，ios卻能正常啟動並執行效果。

實驗1：更改節的物理地址位移。

1，首先將檔案拖到ida，我們看到TEXT段下面的2個節。

“__text"與"__stub_helper"

HEADER:0000408C DCB "__text",0,0,0,0,0,0,0,0,0,0; sectname

HEADER:0000408C DCB "__TEXT",0,0,0,0,0,0,0,0,0,0; segname

HEADER:0000408C DCD 0xAD00 ; addr

HEADER:0000408C DCD 0xD6938 ; size

HEADER:0000408C DCD 0x6D00 ; offset

HEADER:0000408C DCD 3 ; align

HEADER:0000408C DCD 0 ; reloff

HEADER:0000408C DCD 0 ; nreloc

HEADER:0000408C DCD 0x80000400 ; flags

HEADER:0000408C DCD 0 ; reserved1

HEADER:0000408C DCD 0 ; reserved2

HEADER:000040D0 DCB "__stub_helper",0,0,0; sectname

HEADER:000040D0 DCB "__TEXT",0,0,0,0,0,0,0,0,0,0; segname

HEADER:000040D0 DCD 0xE1638 ; addr

HEADER:000040D0 DCD 0xE88 ; size

HEADER:000040D0 DCD 0xDD638 ; offset

HEADER:000040D0 DCD 2 ; align

HEADER:000040D0 DCD 0 ; reloff

HEADER:000040D0 DCD 0 ; nreloc

HEADER:000040D0 DCD 0x80000400 ; flags

HEADER:000040D0 DCD 0 ; reserved1

HEADER:000040D0 DCD 0 ; reserved2

?

“__text”節的的記憶體載入地址為 0xad00，檔案位移為0x6d00

"__stub_helper"節的的記憶體載入地址為 0xE1638，檔案位移為0xDD638

2，我們將“__text”的的檔案位移更改為"__stub_helper"的檔案位移，修改後保持檔案，繼續拖到ida下分析，如：

?

HEADER:0000408C DCB "__text",0,0,0,0,0,0,0,0,0,0; sectname

HEADER:0000408C DCB "__TEXT",0,0,0,0,0,0,0,0,0,0; segname

HEADER:0000408C DCD 0xAD00 ; addr

HEADER:0000408C DCD 0xD6938 ; size

HEADER:0000408C DCD 0xDD638 ; offset

HEADER:0000408C DCD 3 ; align

HEADER:0000408C DCD 0 ; reloff

HEADER:0000408C DCD 0 ; nreloc

HEADER:0000408C DCD 0x80000400 ; flags

HEADER:0000408C DCD 0 ; reserved1

HEADER:0000408C DCD 0 ; reserved2

HEADER:000040D0 DCB "__stub_helper",0,0,0; sectname

HEADER:000040D0 DCB "__TEXT",0,0,0,0,0,0,0,0,0,0; segname

HEADER:000040D0 DCD 0xE1638 ; addr

HEADER:000040D0 DCD 0xE88 ; size

HEADER:000040D0 DCD 0xDD638 ; offset

HEADER:000040D0 DCD 2 ; align

HEADER:000040D0 DCD 0 ; reloff

HEADER:000040D0 DCD 0 ; nreloc

HEADER:000040D0 DCD 0x80000400 ; flags

HEADER:000040D0 DCD 0 ; reserved1

HEADER:000040D0 DCD 0 ; reserved2

?

兩個節的物理位移都為0xDD638。

雙擊“__text”節，進入代碼的。

可以看到左下角，物理地址為0xdd638，實際上這是錯誤的，物理地址應該為0x6D00。我們可以得出結論，ida直接使用了節的物理地址，偷懶了，實際上應該使用段地址來計算。

實驗2:給節的物理位移更改為一個遠超檔案大小的數。

HEADER:0000408C ; Sections

HEADER:0000408C DCB "__text",0,0,0,0,0,0,0,0,0,0; sectname

HEADER:0000408C DCB "__TEXT",0,0,0,0,0,0,0,0,0,0; segname

HEADER:0000408C DCD 0xAD00 ; addr

HEADER:0000408C DCD 0xD6938 ; size

HEADER:0000408C DCD 0xFFFFFFFF ; offset

HEADER:0000408C DCD 3 ; align

HEADER:0000408C DCD 0 ; reloff

HEADER:0000408C DCD 0 ; nreloc

HEADER:0000408C DCD 0x80000400 ; flags

HEADER:0000408C DCD 0 ; reserved1

HEADER:0000408C DCD 0 ; reserved2

?

更改後儲存檔案，拖到ida，

iOS可執行檔的簡單反ida