5月17日左右，微信群中出現了可使iOS版微信閃退的GIF表情。

5月26日傍晚，360安全研究員宋申雷對表示，微信知道這個漏洞兩周了，但是攔截策略依然不行，第一個crash出現時就對樣本做了hash 攔截，這都兩周了，改一個字節的版本都有多少個了。

此外，他還指出，現在不在原圖改字節了，直接把有漏洞的最后一幀構造到任意的GIF中。

為了更好地促進讀者了解其中的機制，360NirvanTeam對于此事件進行了具體的技術分析。

一、背景情況

5月17日起，在各個微信群中流傳著一個天線寶寶的GIF表情。在iOS版的微信上，只要打開了包含這個GIF表情的聊天窗口，就會造成微信閃退。

在進行具體分析之前，對崩潰原因進行了猜測：（1）iOS系統自帶GIF解析功能存在問題；（2）微信自己實現GIF解析的功能，由于對輸入數據的校驗不嚴格，導致異常。

經過測試，發現iOS版QQ不受影響，因此可以排除iOS的GIF解析問題。

二、原因分析

1、樣本精簡

初始的GIF樣本有1MB之多，不利于定位引起問題的具體數據，因此我們需要對樣本進行精簡。通過010 Editor打開原始樣本GIF，利用GIF模板解析，發生解析異常，這就表示樣本GIF的格式存在問題。

從模板解析的情況顯示，在38幀正常的圖片數據后，出現了異常的數據。如圖所示，因此我們將正常數據部分移除，僅保留異常數據，進行下一步精簡。

可以看到，剩余的異常數據的部分有10多萬個，通過二分法的方式進行測試和排除。具體就是，刪除一半后，測試另外一半是否可以導致崩潰。

如果崩潰了，說明引起異常的數據在保留的一半中，反之則說明在刪除的部分中。

經過不斷的排除后，發現異常的數據就在下圖的紫色部分中。只要帶有GIF的圖像數據部分帶有這些異常數據，就會導致iOS微信閃退。

2、調試分析

經過樣本精簡，我們已經發現了引起異常的數據位置。那么，現在就需要結合實際的調試，來確定實際引起異常的數據。

以iOS微信6.5.7版為例，崩潰發生時的調用棧如下，崩潰發生于微信內部，說明是微信自身的GIF解析功能存在問題。

經過對相關函數的逆向分析，最終確定了引起異常的數據。首先來觀察sub_100B6CBF0這個函數，對于GIF中的數據進行循環查找，如果存在0x21和0xF9，那么當前數據就表示是一個GraphicControlExtension結構，并接著對GraphicControlExtension數據進行解析。

如果當前查找到的數據為0x2C，就表示搜索到了一個ImageDescriptor，跳出while循環，進行實際圖片數據的解析。這里也就是異常數據的起始位置！

正常的幀數據的ImageDescriptor數據如下：

而引起異常的數據中，恰好存在0x2C這個關鍵的分隔符，導致下述紅框中的數據被解析成了一個ImageDescriptor。可以看到，ImageWidth屬性為0，ImageHeight屬性為0x100。

接下來，這部分異常的數據就會進入sub_100B6CE90函數進行解析。由于ImageWidth為0，導致與ImageHeight相乘后等于0，在new buffer時，傳入的大小參數為0，這是第一個問題，但這并不會導致閃退，仍然可以分配一個很小的堆塊。

引起崩潰的代碼如下，在else block中，sub_100B6C4F0的作用沒有具體跟蹤，猜測是進行lzw解壓縮，并返回解壓縮后的數據長度v21。

由于v10 = 0x0000010000000000，截斷成unsigned int后為0，這就導致 v10 – 1 – v21 為負數，作為memset第三個參數，相應的unsigned int形式就是一個很大的正數。在memset時，就會導致崩潰，這是第二個問題。

三、總結

這個問題的根本原因是微信實現了自己的GIF解析功能，但由于對輸入數據的校驗不嚴格，導致異常的數據被解析，引起崩潰。

在5月17日當天，這個GIF開始流傳后，微信似乎在服務器端做了屏蔽，使得這個GIF無法被正常接收，但我們只要隨便修改一下GIF中的任意一個字節，就能繞過這個屏蔽措施。

同時由于iOS應用上架需要經過蘋果審核，需要額外耗費一定時間，這就使得這個Bug即使修復后，所有用戶也無法立刻更新。

目前最新的iOS微信6.5.8版本仍然存在崩潰的問題。