微信閃退動(dòng)態(tài)表情包大全

微信閃退動(dòng)態(tài)表情圖是一款十分有意思也是有自主創(chuàng)新使用價(jià)值的表情圖，這款表情圖來源于是在每個(gè)微信圈中廣為流傳著一個(gè)天線寶寶的GIF神情。在iOS版的微信上，只需打開了包括這一GIF神情的交流對(duì)話框，就會(huì)導(dǎo)致微信閃退。諸位朋友有沒有感覺特別的奇妙，下邊就為各位產(chǎn)生詳細(xì)介紹。

微信閃退環(huán)境狀況：

5月17日起，在每個(gè)微信圈中廣為流傳著一個(gè)天線寶寶的GIF神情。在iOS版的微信上，只需打開了包括這一GIF神情的交流對(duì)話框，就會(huì)導(dǎo)致微信閃退。

在開展深入分析以前，對(duì)崩潰緣故做好了猜想：（1）iOS系統(tǒng)軟件內(nèi)置GIF解析作用存在的問題；（2）手機(jī)微信自身完成GIF解析的作用，因?yàn)閷?duì)鍵入數(shù)據(jù)的校檢不嚴(yán)苛，導(dǎo)致出現(xiàn)異常。

通過檢測(cè)，發(fā)覺iOS版QQ不受影響，因而可以清除iOS的GIF解析難題。

微信閃退gif基本原理：

1、樣版精減

原始的GIF樣版有1MB之多，不利精準(zhǔn)定位造成難題的實(shí)際數(shù)據(jù)，因而他們必須對(duì)樣品開展精減。根據(jù)010 Editor開啟初始樣版GIF，運(yùn)用GIF模版解析，產(chǎn)生解析出現(xiàn)異常，這就表明樣版GIF的文件格式存在的問題。

從模版解析的狀況表明，在38幀一切正常的照片數(shù)據(jù)后，發(fā)生了出現(xiàn)異常的數(shù)據(jù)。如下圖所示，因而人們將一切正常數(shù)據(jù)一部分清除，僅保存出現(xiàn)異常數(shù)據(jù)，開展下一步精減。

可以見到，剩下的出現(xiàn)異常數(shù)據(jù)的一部分有10多萬個(gè)，根據(jù)二分法的形式開展檢測(cè)和清除。實(shí)際便是，刪掉一半后，檢測(cè)此外一半是不是可以導(dǎo)致崩潰。

假如崩潰了，表明造成出現(xiàn)異常的數(shù)據(jù)在保存的一半中，相反則表明在刪掉的一部分中。

通過持續(xù)的清除后，出現(xiàn)異常的數(shù)據(jù)就在下面的圖的藍(lán)紫色一部分中。只需含有GIF的圖象數(shù)據(jù)一部分含有這種出現(xiàn)異常數(shù)據(jù)，就會(huì)導(dǎo)致iOS微信閃退。

2、調(diào)節(jié)剖析

通過樣版精減，大家早已發(fā)覺了造成出現(xiàn)異常的數(shù)據(jù)部位。那麼，如今就必須聯(lián)系實(shí)際的調(diào)節(jié)，來明確具體造成出現(xiàn)異常的數(shù)據(jù)。

以iOS手機(jī)微信6.5.7版為例子，崩潰產(chǎn)生時(shí)的啟用棧如下所示，崩潰產(chǎn)生于手機(jī)微信內(nèi)部，表明是手機(jī)微信本身的GIF解析作用存在的問題。

通過對(duì)相關(guān)函數(shù)的逆向分析，最后明確了造成出現(xiàn)異常的數(shù)據(jù)。最先來觀察sub_100B6CBF0這一涵數(shù)，針對(duì)GIF中的數(shù)據(jù)開展循環(huán)系統(tǒng)搜索，假如存有0x21和0xF9，那麼當(dāng)今數(shù)據(jù)就表明是一個(gè)GraphicControlExtension構(gòu)造，并然后對(duì)GraphicControlExtension數(shù)據(jù)開展解析。

假如當(dāng)今搜索到的數(shù)據(jù)為0x2C，就表明檢索到一個(gè)ImageDescriptor，跳出來while循環(huán)系統(tǒng)，開展具體照片數(shù)據(jù)的解析。這兒也就是出現(xiàn)異常數(shù)據(jù)的起止部位！

一切正常的幀數(shù)據(jù)的ImageDescriptor數(shù)據(jù)如下所示：

而造成出現(xiàn)異常的數(shù)據(jù)中，正好存有0x2C這一重要的分節(jié)符，導(dǎo)致以下白框中的數(shù)據(jù)被解析變成一個(gè)ImageDescriptor?？梢砸姷?，ImageWidth特性為0，ImageHeight特性為0x100。

下面，這一部分出現(xiàn)異常的數(shù)據(jù)就會(huì)進(jìn)到sub_100B6CE90涵數(shù)開展解析。因?yàn)镮mageWidth為0，導(dǎo)致與ImageHeight乘積后相當(dāng)于0，在new buffer時(shí)，傳到的尺寸主要參數(shù)為0，這也是第一個(gè)難題，但這并不會(huì)導(dǎo)致卡屏，依然可以分派一個(gè)較小的堆塊。

造成崩潰的編碼如下所示，在else block中，sub_100B6C4F0的功效沒有實(shí)際追蹤，猜想是開展lzw壓縮包解壓，并回到壓縮包解壓后的數(shù)據(jù)長短v21。

因?yàn)関10 = 0x0000010000000000，斷開成unsigned int后為0，這就導(dǎo)致 v10 – 1 – v21 為負(fù)值，做為memset