軟體中的數據分析 之二

延續上一篇，接下來聊一下比較不常見，但是卻是價值比較大的分析類型。

這一種型態的問題解決之所以那麼稀少，主要還是因為要發現問題的運氣成分非常重，更不要說成功地解出問題。不過，如果回顧這些相關的案例，它們被發現的觸發點，還是有相似之處: 多半是在解第一類問題的時候，陰錯陽差找到一些令人驚訝的事實，而被有觀念的人棄而不捨地繼續鑽研。在之前的篇幅當中，曾經提到因為測試 Excel 大檔的功能，無意中發現 Office 的長尾現象，就是其中一個。

而這裡我再舉一個例子，讓大家進一步了解這種現象。

自 XP 引進 Watson 的遙測資料蒐集功能之後，如何儲存並分析這些資料是一個很大的挑戰，它的規模其實超乎原來 M 社的預期。在使用者同意傳回的前提之下，回傳的資料大致分成兩類: 第一類是前一篇所說明的事先計畫好的遙測資料，而另一類 (它的量其實超過六成以上)是當系統中的應用程式發生記憶體毀損，或是某一段程式執行同一段碼過久，系統就會發出一個對話方塊，詢問使用者要不要回傳記憶體的內容 (memory dump) 給 M 社，做進一步的分析。

我記得有一個數據是，即使在多數的使用者都使保守不願傳回的情況下，M 社還是每天會收到超過一百萬次的回傳。那個時候我們都笑稱那些資料是 "應用程式垃圾"；仔細想一下就能了解，如果這些回傳是由 M 社自己寫的或是友商的應用程式所產生的還好，的確可以回朔問題的發生點，找出先前沒有找到的 bug。但是實際的情況是，這些回傳有八成以上我們不認識的應用所製造出來的。這讓毀損程式碼的分析變成補可能的任務，M 社再有錢也找不到那麼多人來做反組譯和 trace 的工作。早期有許多的資料其實跟廢物沒啥兩樣。

不過，M 社究竟是對資料具有極大興趣的公司，也不因為很難做就放棄。還是投入了很多工程師和研究人員，試著將這些回傳做自動的分類，有些是從毀損點的程式碼模式，有些是從毀損時堆疊的資料內容，看看找不找得出 pattern。我得印象很深刻，其中有一個團隊，甚至將 machine code 和 data 再記憶體中的分布做成圖型，試著用電腦視覺的方式找模式。

其中一個很有價值的發現，是一位工程師在檢視 dump 中的資料段的內容時，發現了一連串 IP 的位置。剛好這位工程師之前在防毒產品的團隊待過，懷疑這些 IP 是 "殭屍網路" 的其中一部份，經過反組譯，確認有一段的確是惡意程式的一部分。這位工程師就大膽的假設，寫惡意病的人跟一般 developer 一樣，程式也會有 bug，也會當掉。好玩的是，即使寫 malware 的人刻意在檔案中對 IP 特別加密以避免被防毒程式掃到，但是它在記憶體內一定會回復成名碼的形式，不然程式沒辦法用。這樣如果在 dump 中找到殭屍網路的 IP，有九成九是個惡意程式，值得進一步追查。

這個假設一出來，有好幾位工程師持續去驗證，果然找出許多已知的惡意程式的片段。之後公司發現這有非常大的價值，甚至還與執法和國安位合作，成立了獨立的產品組，對大型企業或是公務單位提供分析惡意程式的服務，是屬於超高利潤的事業。

這裡真正想提的是，這類的案例雖然稀少，也不容易使用可重複的程序尋找資料背後的 insight。但是如果每個開發成員能夠對資料時時保持好奇心和敏感度，當資料出現有趣特徵的時候，才能及時把握，進一步挖出有價值的金礦。