<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    ?DOCX 文檔解析及隱藏信息提取算法

    VSole2021-12-30 13:08:48

    摘 要:

    DOCX 是一種融合可擴展標記語言(Extensible Markup Language,XML)、對象連接與嵌入 (Object Linking and Embedding, OLE) 技術、ZIP 壓縮技術為一體的文檔組織形式,  其格式復雜、應 用廣泛,信息隱藏方式靈活且難以發現。通過研究 DOCX 文檔,解析文檔結構,提出在此類文檔中 進行信息隱藏的可能性,并有針對性的設計了基于關聯對象隱藏信息和基于文檔擴展空間隱藏信息 的檢測和提取算法,分析兩種算法的適用性,為電子數據取證技術人員的專業工作提供一定幫助。

    內容目錄:

    1    DOCX 文檔結構解析

    1.1   [Content_Types].xml 文件解析

    1.2    rels 文件解析

    1.3  docProps 文件夾解析

    1.4    文檔內容解析

    2    DOCX 文檔信息隱藏方法

    2.1    基于關聯對象的信息隱藏

    2.2    基于文檔擴展空間的信息隱藏

    3    DOCX 文檔隱藏信息檢測提取算法

    3.1    基于關聯對象隱藏信息的檢測提取算法

    3.2    基于文檔擴展空間隱藏信息的檢測提取算法

    3.3    算法分析

    微軟的 Office 是目前最常使用的辦公軟件套裝,其中的一個組件 Word 是文字處理的必備工具。早期的 Word 使用的是 DOC 文檔,是一種復合文檔,由頭部和扇區組合而成,其中的文字、圖片、公式 等信息以流的形式被區分,分別存儲在不同的倉庫 中;而現在主流的 DOCX 文檔采用的文件組織方式則是一種基于壓縮文件的新型可擴展標記語言(Extensible Markup Language,XML) 格式。與之前的 DOC 類型相比,DOCX 格式的文件打包方式可以  減少文件大小、節省磁盤空間。由于 DOCX 格式結  合壓縮和 XML 格式, 能加載語音、文字、圖像、視頻、鏈接等多媒體,DOCX 文檔結構復雜;因此,一旦存在隱藏信息,比較難以發現。對于從事電子數據取證的專業人員,如果不能深入了解 DOCX 文檔的  組織結構,則無法從中提取隱藏的有效信息,勢必影響證據分析和證據鏈的形成。基于此,本文針對DOCX 文檔進行研究,通過解析文檔結構,提出信息隱藏的可能性并設計對應的隱藏信息提取算法。

    01 DOCX 文檔結構解析

    DOCX 文 檔 的 文 件 頭 為“50 4B 03 04”,與 ZIP 文件頭類似,  這是由于 DOCX 文檔的結構是按 照壓縮原理設計的;因此 DOCX 文檔的目錄結構展開來看和壓縮文件一樣具有文件系統的文件組織 形式,并以樹狀結構排列,包含目錄和子目錄,其 中葉子節點是一些文件流。

    DOCX 文檔中所包含的文件夾和文件各自定義 數據和屬性,但相互之間有一定的聯系,而完整地  讀取其內容需要借助對應的應用程序。應用程序讀  寫文檔時,能夠將全部的目錄、文件解壓出來并打  開指定的目錄,  讀寫出其中某個文件流。一般來說, DOCX 文檔包含 [Content_Types].xml 文件、docProps 文件夾、rels 類文件和文檔內容類文件(一般在 word、custom 等文件夾下),如圖 1 所示。

     

    圖 1   DOCX 文檔的目錄結構

    1.1   [Content_Types].xml 文件解析

    [Content_Types].xml 文件對整個文檔中內容所對應的媒體類型進行說明。在 DOCX 文檔中每使 用一類 媒體或元數 據,[Content_Types].xml 都要增 加一項類型包定義來說明,其中包含了所增加的媒體或元數據對應的入口位置以及解釋方式,例如,rels 的媒體類 型是“application/vnd.openxmlformats- package.relationships+xml”,由這個頂級包負責解釋。 因此,應用程序讀取 DOCX文件時,先解析[Content_ Types].xml,就可以在 [Content_Types].xml 中得到文 檔所用到的格式、內容、圖片等所對應的媒體類型 以及保存的位置,為下一步調用指出入口,具體如  圖 2 所示。對于大部分 DOCX 文檔來說,[Content_ Types].xml 的內容都是類似的,也就是說文檔格式  的媒體類型一樣,生成的文件夾和子文件夾以及文件名稱相同,只是在項目數量上有區別,例如某個文檔沒有插入圖片,在 [Content_Types].xml 中就會缺 少  語句。 

    圖 2   [Content_Types].xml 內容示例

    1.2    rels 文件解析

    rels 是 relationships 的縮寫,  用來定義文檔格式 與媒體類型之間的對應關系。讀取 DOCX 文檔時, 根據 rels 可以快速得到各部件和媒體類型格式包的 對應關系,此時不需要考慮具體的格式,可以節 省讀取時間,因此統一命名為 rels 類型。[Content_ Types].xml 中解 釋 了 rels 的媒體類 型, 屬 于 Office Open XML 的文件格式,可以按照 XML 讀取內容。在根 _rels 文件夾和 word、custom 等文件夾下都存 儲有 rels 類文件,根文件夾下的 rels 文件解釋文檔 中主部件和頂級包的關系,如圖 3 所示,對主部 件 app.xml、core.xml 和 document.xml 定義了對應系。word 文件夾下的 rels 文件 document.xml.rels 列 出 document.xml 所需的其他部件,如果文檔中有用 戶自定義的一些屬性,則會在 custom 文件夾下分別 創建以 item 命名的 rels 文件,進一步解釋當前文件 夾下子部件和包的對應關系。

    圖 3   rels 內容示例

    1.3  docProps 文件夾解析

    docProps 文 件 夾 中 包 括 core.xml、app.xml、 custom.xml 等, 在根文件夾下的 rels 文件中解釋了這 些 xml 文 件 和 包 的 對 應 關 系。custom.xml 記錄文檔的自定義屬 性,core.xml 和 app.xml 用 于記 錄 DOCX 文檔的主屬性。core.xml 中的信息涵蓋了文 檔的創建時間、修改時間、標題、作者等 OpenXML文檔格式的通用文件屬性,app.xml 描述 DOCX 文 檔的其他一些屬性 ,例如文檔類型、安全屬性、只讀信息、版本等特有的文件屬性,這些內容以新 型 文 件 系 統(New Technology File System,NTFS) 主文件流的方式保存 ,與文件屬性中的詳細信息 保持一致。core.xml 和 app.xml 涵蓋了文檔詳細信息的各個項目內容,如圖 4 所示。

    圖 4   core.xml、app.xml 和文檔屬性的對應

    1.4    文檔內容解析

    word、custom 等文件夾保存了用戶對文檔的各種操作。custom 中 以 item 為首命名的 xml 文件解釋文檔中的自定義數據部件,這個部件對文檔的整 體內容影響不大,即使缺失也可以正常讀取文檔內 容。word 文件夾中包含了大量 xml 文件,用來解 釋文檔的頁眉、頁腳、批注、腳注、尾注、web 設 置、自定義設置、格式、內容等,具體地,是在 header1.xml、footer1.xml、comments.xml、footnotes. xml、endnotes.xml、websettings.xml、styles.xml、 settings.xml、document.xml 等文件中解 釋。此外,還有一些子文件夾如 theme、embeddings、media 等對文檔中涉及的其他對象進行了說明, theme 文件夾中的theme1.xml 記錄文檔的格式主題,media 文 件夾中存放著插入文檔中的圖片、視頻等其他格式文件的縮略圖,embeddings 文件夾中存放著文本文檔等類型的文件。這些 xml 文件按照 WordXML 的語法格式對內容進行組織 ,具有很高的靈活性。在這些文件中,document.xml 非常關鍵,它是用來記錄 DOCX 文檔正文內容的文件,文檔內容在 … 中解 釋,在 body 體內有 3 類節點, 分別是: 表示段落格式、 表示字符格式、 表示文本內容。其中, 包含在  體 中, 包 含 在  體 中。WordXML對不同的段落、字符格式進行相應的語法指定,例 如某段文本為粗體,則用  表示。圖 5 為 document.xml 中的一段 體,文檔的格式內容都有詳細解釋。

    圖 5 document.xml 示例

    media 文件夾和 embeddings 文件夾會對文檔中所插入的圖片、對象等內容詳細解釋。圖片類以源文件的形式保存在 media 文件夾中,其他類型的對象在 embeddings 文件夾中以 OLE 形式保存二進制內容,media 文件夾中只保存縮略圖。圖 6 為測試文檔中分別插入 exe、mp3、txt、jpg 等對象,在media 文件夾中都以 image 為首命名,jpg 對象大小不變,在本示例中對源文件“示例 .jpg”和“image4.jpg”分別計算Hash 值,得到二者的 MD5 值都為“BB139707C16E35A85A6D94B7BEB023A5”, 表示文件內容沒有發生改變;但其他對象很明顯有改變。要提取其具體內容,需要進一步分析。

    圖 6 DOCX 插入對象的存儲方式

    embeddings 文件夾中的 bin 文件指向其他對象,DOCX 對這些對象采用 OLE 技術進行封裝,延續 了復合文檔技術,以扇區鏈的方式對數據流進行存 儲 。文檔頭在首扇區,大小為 512 個字節,其后是 Sectors 區,Header 中的參數包括復合文檔標識、版本號以及扇區、短扇區等定義。圖 7 為插入文件“示 例 .exe”在 DOCX 中生成的 OLE 對象 oleObject.bin 的文件頭。

    圖 7   DOCX 插入 OLE 對象的 Header 示例

     示例中 OLE 對象扇區大小為 512 個字節, 短扇區大小為 64 個字節,扇區分配表(Sector Allocation Table,SAT),短 扇 區 分 配 表(Short Sector Allocation Table, SSAT) 都是占用 1 個扇區,目錄流位于第 1 扇區。目錄流按照紅黑樹的結構對 數據進行組織,根據 Header 中的參數,結合 SAT 為文件流創建的扇區編號 SID 鏈,從目錄流的入口 得到數據存放的位置,并從文件頭開始提取,可以得到插入的源文件。按照 Header 參數計算后,在偏移 16 進制數 0A BC 處發現文件內容。該文件以 “MZ”開頭,與 exe 文件頭一樣,說明找到了正確 的文件保存位置。其他類型的 OLE 對象可采用同樣方法提取文件內容 。

    02 DOCX 文檔信息隱藏方法

    上文研究了 DOCX 文檔的組織結構,對常用 的部分做了解析。筆者發現,盡管 DOCX 文檔組織 結構嚴密,但由于內容復雜,部分文件存在冗余, 給信息隱藏提供了一些機會。事實上,電子數據取 證人員在處理案件時也曾遇到這類隱藏數據。在 DOCX 文檔中隱藏數據時需要結合其組織結構,找到對文檔沒有影響并且不易被發現的位置。xml、rels 以及插入文檔的對象之間存在關聯,隱藏信息時一般都會對這些關系進行梳理后找到隱藏位置并自我偽裝。

    2.1    基于關聯對象的信息隱藏

    [Content_Types].xml 作 為 DOCX 文 檔 的 入 口,文檔中每添加一類對象, 就需要在 [Content_Types]. xml 進行聲明,那么如果所添加的對象沒有在其中 聲明,是否 DOCX 就無法對其識別解釋,而實際達到隱藏數據的目的呢?筆者將上文中的測試文件改 變擴展名為 zip 后,在 media 文件夾中添加 jpg 文件 image.jpeg, 結果 DOCX文檔能夠正常打開,而添加 png 文件 image.png 后, 文檔出現了錯誤。對 [Content_ Types].xml 的內容進行分析,發現內容中存在語句:


    結合前面的解析,該語句是對 jpg 類型的聲明,如果文檔插入有此類對象,則默認存在其他 jpg 對 象。而 [Content_Types].xml 中缺少 了對 png 類 型對象的聲明,所以文檔在 media 文件夾中發現 png 對象后會出現錯誤。按照這個思路篡改 [Content_ Types].xml 內容,添加語句:

    < Default  ContentT ype="im age/png" Extension="png"/>

    發現 DOCX 文檔可以正常使用。

    除了可以在 media 文件夾下隱藏圖片類對象, 還可以在 embeddings 文 件 夾 下 隱 藏 exe、mp3 等其他類型的對象。按照 DOCX 的語法,在 media 文件夾下隱藏的文件需要命名為 image 開頭, 在 embeddings 文件夾下隱藏的文件需要命名為 oleObject 開頭,否則應用程序無法正常打開。

    為何所隱藏的文件能正常存在于文檔中而不 被 DOCX 識別到呢?上文研究證明了隱藏文件能正 常存在于文檔是由于在 [Content_Types].xml 中對對 象的類別進行了聲明,下面進一步分析實現隱藏的原因。

    在 rels 文件中對文檔與媒體類型之間的關系進 行了解釋。圖 2 中是對頂級包和媒體類型之間確立 關聯關系,插入文檔中的具體對象則在子文件夾 中的 rels 文件詳細關聯解釋, 例如上文中插入“示例 .exe”后, 先在 [Content_Types].xml 中添加語句: Extension="emf"/>聲明在 image 文件夾下添加這個文件的縮略圖, 還需要對 word 下的 rels 文件增加的兩行語句:



    這兩行語句分別對 media 文件夾下的縮略圖和 embeddings 文件夾下的 OLE 對象解釋關聯關系。

    綜上所述,可以得出:由于 rels 中沒有解釋 image.png 對象的關聯關系,導致了應用程序讀取DOCX 文檔時,無法形成數據鏈,遺漏了存在于media 文件夾下的 image.png,從而實現了信息的隱藏。

    2.2    基于文檔擴展空間的信息隱藏

    DOCX 文檔的文字內容存在于 document.xml 中,結合其他 xml 文件解釋頁面、段落、字符內容及格   式設置。這些 xml 文件必須符合 OfficeXML 格式和語  法,如果在 xml 文件中添加信息進行隱藏,則會因語法錯誤造成 DOCX 文檔不能正常讀取。如果希望隱藏少量關鍵信息,則可以在擴展空間中操作 , 這種方式不會改變文檔大小, 隱蔽性強, 不易被發現。

    由于 DOCX 采用了 ZIP 壓縮格式 [9] ,可以根據 ZIP 文件格式找到擴展空間,按照一定規律在擴展 空間中對信息進行隱藏。ZIP 結構包括數據區(50 4B 03 04 標志)、目錄區(50 4B 01 02 標志)和結 束標志區(50 4B 05 06 標志)3 部分, 其中, 數據 區和目錄區按照壓縮文件記錄排列。數據區所占空 間最大,包括頭結構和數據,頭結構如圖 8 所示, 文件名長度為 001CH(28 個字節) ,擴展記錄長 度為 0108H(264 個字節), 即文件名后的 264 個 字節為擴展記錄,擴展記錄的前 8 個字節為有效內 容,其他用 0 填充,這樣就存在 256 個字節的填充 區域,這部分擴展空間是冗余的,可以填充任何 數值。

    圖 8   DOCX 數據區頭結構

    在這個拓展區域中填充“password:123”后,文檔正常讀取,證明針對此區域的信息篡改不會對 DOCX 文檔造成任何影響,那么就可以利用這些拓 展記錄的填充區域隱藏數據。

    03 DOCX 文檔隱藏信息檢測提取算法

    上文中驗證了在 DOCX 文檔中隱藏信息的可能  性, 在實際工作中需要檢測并提取到這些隱藏信息。 針對上述信息隱藏方法,筆者分別設計了基于關聯對象隱藏信息的檢測提取算法和基于文檔擴展空間隱藏信息的檢測提取算法。

    3.1    基于關聯對象隱藏信息的檢測提取算法

    基于關聯信息的信息隱藏是對 [Content_Types].xml、document.xml.rels 和 media、embeddings 文件夾下插入對象的關聯關系進行篡改后實現的,那么 檢測并提取這些信息,就要按照這個思路對這些關 聯信息進行檢測,如果出現關系鏈不完整的情況, 則意味著存在隱藏信息。

    具體算法流程如下:

    (1)按照 ZIP 格式解壓 DOCX 文檔;

    (2)檢索 [Content_Types].xml,如果檢測到語句:

    < D e f a u l t C o n t e n t T y p e = " i m a g e / * " Extension="*"/>;

    (3) 則 繼 續 檢 索 /word/_rels/document.xml. rels,如果檢測到語句包含:

    T yp e= "http: //s ch em as . openxm lfor m ats .o rg/ offi c eDo cume nt/ 2006/re l a t i o nshi ps/ i ma g e "Target="media/image?.*

    則提取 Target 的值;

    (4) 如果Target 的值包含“emf”,則檢索 / word/embeddings 文 件 夾,   否 則 檢 索 /word/media 文 件夾;

    (5)如果存在與(3)中不匹配的文件名,則確定該文件為隱藏文件,提取該文件。

    3.2    基于文檔擴展空間隱藏信息的檢測提取算法

    擴展空間中隱藏信息是在對 DOCX 文檔解壓 以前進行的,因此檢測提取這些信息針對的是原始 DOCX 文檔。通過檢索文檔的編碼找到擴展空間, 提取冗余空間內容并分析獲得隱藏信息。具體算法流程如下:

    (1)檢索文檔 16 進制內容,設置檢索關鍵字 為“504B0304”,自上向下開始檢索;(2)當檢索到關鍵字,按照 16 進制從當前位 置向后偏移 1 個字節,提取該雙字節數值 len1,繼 續向后偏移 2 個字節,提取該雙字節數值 len2;(3)繼續向后偏移 len1+8 個字節,從當前位 置開始提取 len2-8 個字節長度的內容;(4) 分析提取的內容,  如果不是 0, 則確定為 隱藏數據;(5) 繼續向下檢索關鍵字“504B0304”,  如 果命中,則按(2)~(4)處理。

    3.3    算法分析

    上面兩個算法分別針對不同的隱藏方式,在實際應用中可能存在兩種方式并存的情況,因此要同時采用兩個算法進行檢測。第一個算法的操作對象是目錄和文檔內容,如果文檔插入對象較多,則會影響檢測速度。第二個算法是針對文檔的源文件開展檢索,運行速度較快,但是提取的內容為二進制, 需要結合實際情況用智能分析手段判斷數值的實際含義。

    04 結 語

    隨著對 DOCX 文檔更深入詳細的解析,利用 其組織結構中的漏洞進行信息隱藏的手段會越來越多。本文通過研究的信息隱藏方法,針對解壓前的 源文件和解壓后的目錄樹,提出了檢測算法。該算 法涵蓋了 XML、OLE、插入對象等,覆蓋面較廣、 可操作性強;但提取的可疑信息是否為有效線索, 特別是如何獲知擴展空間中二進制源碼的含義,還需要進一步思和研究。此外,document.xml 等 xml 文件中包含的文檔內容、格式,core.xml 和 app. xml 中解釋的文檔屬性,以及 OLE、IMG 等部件中的對象等都是 DOCX 文檔的關鍵組成 ,如何針對 這些重要部分進行信息篡改、設計檢測算法,也值得繼續開展研究和討論。

    引用本文: 秦志紅 .DOCX 文檔解析及隱藏信息提取研究 [J]. 通信技術,2021,54(11):2557-2563.

    xml語言信息隱藏
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    DOCX 是一種融合可擴展標記語言(Extensible Markup Language,XML)、對象連接與嵌入 (Object Linking and Embedding, OLE) 技術、ZIP 壓縮技術為一體的文檔組織形式, 其格式復雜、應 用廣泛,信息隱藏方式靈活且難以發現。通過研究 DOCX 文檔,解析文檔結構,提出在此類文檔中 進行信息隱藏的可能性,并有針對性的設計了基于關聯對象隱
    首先,從拍攝時間來看,有四個關鍵詞:10月30日、天氣晴朗、拍攝者背對著太陽、一架倫敦飛往香港的波音747。將這個航班的KML文件上傳到谷歌地球,可以準確地再現這架飛機在2019年10月30日的行動軌跡。截止今日,2021年01期CISAW網絡情報分析方向培訓報名已超額,為保證培訓質量,即刻起本期報名通道正式關閉,不再招收任何學員。
    在2020年夏季,我們發現了一個未知的多模塊C ++工具集,該工具集可用于可追溯到2018年的針對性強的工業間諜攻擊。最初,我們對該惡意軟件感興趣的原因是其稀有性,該活動的明顯針對性以及存在在代碼,基礎架構或TTP...
    云函數簡介 云函數是騰訊云為企業和開發者們提供的無服務器執行環境,可以無需購買和管理服務器的情況下運行代碼。只需使用平臺支持的語言編寫核心代碼并設置代碼運行的條件,即可在騰訊云基礎設施上彈性、安全地運行代碼。SCF是實時文件處理和數據處理等場景下理想的計算平臺。服務端配置云函數基礎配置選擇自定義創建,地域自選,部署模式,代碼部署,運行環境Python3.6,其余默認即可。
    用戶名:加密密碼:密碼最后一次修改日期:兩次密碼的修改時間間隔:密碼有效期:密碼修改到期到的警告天數:密碼過期之后的寬限天數:賬號失效時間:保留。查看下pid所對應的進程文件路徑,
    1.虛假移動應用程序可以竊取用戶Facebook憑據 Facestealer是于2021年7月披露的一款間諜軟件,可以通過Google Play的欺詐性應用程序竊取用戶的Facebook憑據。近日,研究人員發現了200多款與Facestealer間諜軟件有關的應用程序,用戶成功登錄帳戶后,應用程序會收集cookie,隨后間諜軟件會加密所有個人身份信息(PII)并將其發送到遠程服務器。
    GoldPickaxe.iOS 采用了一種全新的分發方式,利用 Apple 的移動應用測試平臺 TestFlight 進行傳播。平臺將其刪除后,攻擊者采用多階段的社會工程學方式說服受害者安裝移動設備管理(MDM)配置文件,借此完全控制受害者的設備。
    在安全領域引入機器學習算法,能夠準確識別復雜多變、高危惡意的 XSS 攻擊,提高了安全設備對威脅攻擊的檢測能力。
    釣魚常用手法總結
    2022-03-24 13:48:29
    雷神眾測擁有對此文章的修改和解釋權。如欲轉載或傳播此文章,必須保證此文章的完整性,包括版權聲明等全部內容。未經雷神眾測允許,不得任意修改或者增減此文章內容,不得以任何方式將其用于商業目的。
    無文件惡意軟件攻擊是一種完全在進程內存中工作的惡意代碼執行技術。在無文件攻擊中,不會將任何文件放入硬盤。由于硬盤上沒有要檢測的偽像,這些攻擊可以輕松避開基于檢測的網絡安全解決方案,如下一代防病毒(NGAV)、終端保護平臺(EPP)以及終端檢測和響應(EDR、XDR、MDR)。也稱為內存攻擊,無文件惡意軟件攻擊已經存在了十多年。最初,它們構成的威脅有限,因為它們很少見,并且可以在系統重新啟動時刪除。
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类