DATA abort定位方法

時間：2018-11-06 10:14:01

關鍵字： data abort

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]這是我一直收藏的一篇文章，出處已經(jīng)無法知道。根據(jù)自己實踐增加了部分說明，現(xiàn)在分享出來。?該方法只能定位顯性泄漏，定位到的Ｃ語句一定產(chǎn)生泄漏了，但可能這個位置是 “ 理論上 ” 不會出問題的代碼．那

這是我一直收藏的一篇文章，出處已經(jīng)無法知道。

根據(jù)自己實踐增加了部分說明，現(xiàn)在分享出來。

該方法只能定位顯性泄漏，定位到的Ｃ語句一定產(chǎn)生泄漏了，但可能這個位置是 “ 理論上 ” 不會出問題的代碼．那么這是由于同進程內(nèi)其他代碼泄漏而影響了進程的堆區(qū)或棧區(qū)（隱性泄漏，這個地方不會產(chǎn)生data?abort?exception），然后被定位出來的代碼才被動地顯性泄露，產(chǎn)生data?abort 。

首先在DEBUG版本中定位DATA?ABORT的方法，地球人應該都知道了吧，我就不廢話了。Platform ? Builder或VS2005、EVC這類IDE工具會在DEBUG模式下自動停在出錯的那句，情況就很顯然了。

RELEASE版本下的泄漏就要稍微麻煩一點，如何快速定位呢？

案例一：用EVC編譯的應用程序泄漏

首先我做了一個內(nèi)存泄漏的程序MemoryLeakTest.exe，里面做了一個泄漏的函數(shù) ：

編譯的時候注意先在project?settings里的Link頁里勾選“Generate?mapfile”，會生成一個map文件。

另外，VS2005/VS2008也可以在工程屬性中找到類似的選項，然后指定 MAP 文件名即可。

把編譯出來的RELEASE版本可執(zhí)行文件放到CE5平臺下運行。出錯的時候串口打印了一句

Data?Abort:?Thread=83ad1d38?Proc=820266d0?'MemoryLeakTest.exe'
AKY=00000021?PC=00011008(MemoryLeakTest.exe+0x00001008)?RA=00011030(MemoryLeakTest.exe+0x00001030)?BVA=81000000?FSR=0000000d

這句是系統(tǒng)自動輸出的。我們得到了一個關鍵的信息：PC指針。和PC指針在MemoryLeakTest.exe中的偏移量。然后打開編譯時生成的MemoryLeakTest.map文件，文件內(nèi)容如下:

MemoryLeakTest

Timestamp?is?46fcbb17?(Fri?Sep?28?16:28:07?2007)

Preferred?load?address?is?00010000

Start?????????Length?????Name???????????????????Class
0001:00000000?00000258H?.text???????????????????CODE
0002:00000000?00000014H?.xdata??????????????????DATA
0002:00000014?00000014H?.idata$2????????????????DATA
0002:00000028?00000014H?.idata$3????????????????DATA
0002:0000003c?00000010H?.idata$4????????????????DATA
0002:0000004c?0000000cH?.idata$6????????????????DATA
0002:00000058?00000000H?.edata??????????????????DATA
0003:00000000?00000010H?.idata$5????????????????DATA
0003:00000010?00000004H?.CRT$XCA????????????????DATA
0003:00000014?00000004H?.CRT$XCZ????????????????DATA
0003:00000018?00000004H?.CRT$XIA????????????????DATA
0003:0000001c?00000004H?.CRT$XIZ????????????????DATA
0003:00000020?00000004H?.CRT$XPA????????????????DATA
0003:00000024?00000004H?.CRT$XPZ????????????????DATA
0003:00000028?00000004H?.CRT$XTA????????????????DATA
0003:0000002c?00000004H?.CRT$XTZ????????????????DATA
0003:00000030?00000009H?.bss????????????????????DATA
0004:00000000?00000038H?.pdata??????????????????DATA
0005:00000000?00000010H?.rsrc$01????????????????DATA
0005:00000010?00000000H?.rsrc$02????????????????DATA

??Address?????????Publics?by?Value??????????????Rva+Base?????Lib:Object

?0001:00000000????????MemoryLeak@@YAXXZ????????00011000?f???MemoryLeakTest.obj
0001:00000010???????WinMain????????????????????00011010?f???MemoryLeakTest.obj
0001:0000002c???????WinMainCRTStartup??????????0001102c?f???corelibc:pegwmain.obj
0001:000000a0???????_cinit?????????????????????000110a0?f???corelibc:crt0dat.obj
0001:00000210???????exit???????????????????????00011210?f???corelibc:crt0dat.obj
0001:00000228???????_XcptFilter????????????????00011228?f???coredll:COREDLL.dll
0001:00000238???????__C_specific_handler???????00011238?f???coredll:COREDLL.dll
0001:00000248???????LocalFree??????????????????00011248?f???coredll:COREDLL.dll
0002:00000014???????__IMPORT_DESCRIPTOR_COREDLL?00012014?????coredll:COREDLL.dll
0002:00000028???????__NULL_IMPORT_DESCRIPTOR???00012028?????coredll:COREDLL.dll
0003:00000000???????__imp___C_specific_handler?00013000?????coredll:COREDLL.dll
0003:00000004???????__imp_LocalFree????????????00013004?????coredll:COREDLL.dll
0003:00000008???????__imp__XcptFilter??????????00013008?????coredll:COREDLL.dll
0003:0000000c???????/177COREDLL_NULL_THUNK_DATA?0001300c?????coredll:COREDLL.dll
0003:00000010???????__xc_a?????????????????????00013010?????corelibc:crt0init.obj
0003:00000014???????__xc_z?????????????????????00013014?????corelibc:crt0init.obj
0003:00000018???????__xi_a?????????????????????00013018?????corelibc:crt0init.obj
0003:0000001c???????__xi_z?????????????????????0001301c?????corelibc:crt0init.obj
0003:00000020???????__xp_a?????????????????????00013020?????corelibc:crt0init.obj
0003:00000024???????__xp_z?????????????????????00013024?????corelibc:crt0init.obj
0003:00000028???????__xt_a?????????????????????00013028?????corelibc:crt0init.obj
0003:0000002c???????__xt_z?????????????????????0001302c?????corelibc:crt0init.obj
0003:00000030???????__onexitend????????????????00013030?????

?entry?point?at????????0001:0000002c

?Static?symbols

?0001:0000010c???????doexit?????????????????????0001110c?f???corelibc:crt0dat.obj

OK，首先，里面有一句“Preferred?load?address?is?00010000”，這意味著DATA?ABORT那句的PC=00011008(MemoryLeakTest.exe+0x00001008)?我們必須把括號里的0x1008加上這個load?address的偏移量，得到0x11008（注意不能直接用PC，一會兒再給個案例就知道了），然后我們在函數(shù)偏移列表里看Rva+Base這欄，找到0x11008落在了MemoryLeak函數(shù)的地址范圍里，所以是MemoryLeak函數(shù)泄漏了。

案例二：在OAL層做了一個泄漏的函數(shù)，用Platform?Builder進行RELEASE版編譯并LINK到NK.exe里，然后應用程序MemoryLeakPB.exe調(diào)用該函數(shù)導致泄漏

步驟類似，只是Platform?Builder默認就會在RELEASE目錄下生成.map文件。應用程序去調(diào)用泄漏的OAL函數(shù)時，出現(xiàn)

Data?Abort:?Thread=822fc000?Proc=820267c0?'MemoryLeakPB.exe'
AKY=00000041?PC=8023e3c8(NK.EXE+0x0003e3c8)?RA=8023e1d4(NK.EXE+0x0003e1d4)?
BVA=8e000000?FSR=00000005

注意我們這次是NK.EXE里制造泄漏，所以PC指針不是在0x00011008這樣的Slot?0低地址了，而是在0x80000000以上的KERNEL區(qū)域了。
nk.map很長，我選擇關鍵段落來貼

************************************************************
kern

?Timestamp?is?46fca696?(Fri?Sep?28?15:00:38?2007)

? Preferred?load?address?is?00010000

?...
0001:0003d2c8???????OALIoCtlHal_GetDeviceId????0004e2c8?f???oal_ioctl:deviceid.obj
0001:0003d398???????OALIoCtlHal_MemoryLeak???? 0004e398 ?f???oal_ioctl:leaktest.obj
0001:0003d438???????OALIoCtlHal_DdkCall????????0004e438?f???oal_io:ioctl.obj
...
************************************************************

所以?NK.EXE?+?0x0003e3c8?=?0x10000(Preferred?load?address)?+?0x0003e3c8?=?0x4e3c8,?落在了OALIoCtlHal_MemoryLeak函數(shù)里

結論：原理上很簡單，就是利用DATA?ABORT消息中的PC值，配合MAP文件可以快速定位到泄漏的函數(shù)。定位到之后，嘿嘿，誰LEAK誰請客咯。

用上文的方法，不但網(wǎng)友kevin沒有成功定位到泄漏的原因（見后面回帖，他定位到微軟USBFN的MDD層代碼)，我這項目組里的人也沒抓到原因(定位到PRIVATE下LoadLibrary函數(shù)相關的代碼)。昨晚我想了下，這個方法的確有漏洞，早上我做了個試驗，建立個DialogBox,主處理函數(shù)如下

我運行了幾次，每次該進程的BaseAddr?=?0x1A000000,? 而 ?&gpTest?=?0x1A013860 ，在進程的全局變量區(qū)； malloc 之后 gpTest?=?0x00030230 在進程的堆區(qū)。所以我：
(1)?在 ID_LEAK 按鈕按下后，模擬一次內(nèi)存泄漏，直接對 &gpTest 地址上的數(shù)值改寫，把 malloc 后的 0x00030230 改成 0x00000000,? 注意雖然該處已經(jīng)泄漏了，但是并沒有產(chǎn)生 data?abort?exception.

(此處當然不會出錯！如果出錯，那么給 gpTest 賦值為空時一樣會出錯)
(2)?然后在 ID_CLOSE 按鈕按下后，裝做不知道前面那處泄漏，代碼風格嚴謹?shù)叵扰袛嘞轮羔樖欠駷榭?，然后試圖在 malloc 得到的堆區(qū)? 0x00030230 地址上寫個值，但是由于 gpTest 這個指針已經(jīng)被改寫為指向其他進程空間了，所以在 *gpTest?=?1 這句產(chǎn)生 data?abort?exception 并停下來了。

（說明? gpTest ?的值被誤修改了，否則不會出錯）
(3)?所以，按照上文的方法，只能抓到 *gpTest?=?1 這句泄露，而實際上這句是無辜的，真正的元兇 *((int*)0x1A013860)?=?0x1C000000 這句卻沒有被抓出來。