author:獵豹安全中心
在HackingTeam泄漏的文件，我們發現了有針對主流聊天軟件中的語言進行監控的代碼，其中包括國內常用的微信。下面就以微信為例，來分析一下HackingTeam是如何實現語言監控的。
語音監控的相關代碼在core-android-audiocapture-master文件夾下，通覽全部源碼之后，我們發現，語音監控的實現，主要是通過ptrace實現代碼注入，將一個動態庫注入到微信的進程中實現的。由于Android系統對權限的控制，要實現該目的，必須要擁有管理員權限才可以。也就是說，惡意軟件需要先獲取root權限，之后才能進一步實現語音監控。
下面進入主題，說說是如何實現語音監控的。
core-android-audiocapture-master\dbi_release文件夾里面是程序主要代碼，包括的文件如下
其中，hijack文件夾下包含了一份進程注入的代碼，該代碼的主要功能就是通過ptrace將一個動態鏈接庫(*.so文件)注入到指定的進程里面，并執行。實際上關于進程注入的代碼，之前已經有過很多個版本了，關于細節就不再贅述。相信在不久之后，基于HackingTeam泄漏版進行改寫的hijack將會大量的出現。
當動態鏈接庫文件被注入到微信進程之后，會直接調用初始化函數，該函數即為libt.c中的my_init函數。
在my_init函數開始部分，首先對系統版本進行了判斷，并根據不同的版本采取不同的措施。
為了更容易理解，我們選取android 4.0的環境，看看my_init都做了寫什么事情。
可以看到很多HOOK_coverage_XX形式的變量，這實際上是函數調用的宏定義。相關的定義在hijack_func\hooker.h文件中
根據上圖可以知道，HOOK_coverage_XX實際上是調用了help_no_hash函數。那么我們先來總結一下help_no_hash函數都做了些什么，該函數在libt.c文件中定義。
首先，help_no_hash調用find_name來獲取指定函數地址。find_name的實現在util.c文件中，過程就是通過指定的pid讀取/proc/
經過find_name的調用，就可以找到funcname函數的實際地址，就是addr的值。之后通過判斷addr的值，就可以知道該函數指令集是ARM還是THUMB。并根據不同的指令集進行不同的處理。重點看一下ARM指令集的處理
根據上圖，可以看到，主要內容就是初始化hook變量，hook變量的類型是struct hook_t *，隨后修改funcname函數的前12個字節，實現inline hook。
對于THUMB指令集，實現的功能也類似。都是inline hook，只是在具體指令上有些差別。此處就不再贅述了。
綜合上述的信息，總結一下，help_no_hash函數的主要功能就是對于指定的函數實現inline hook。相信該部分代碼以后也會流行起來的。但是該段代碼雖然寫的比較漂亮，但是依舊存在一些問題，諸位發揮拿來主意的時候，最好還是多測試一下。
回到主題，既然知道了help_no_hash是實現了inline hook功能，那么就來總結一下，都hook了哪些函數。
上表總結了hook關系。我們重點關注的是”Hook函數”這一項，里面的內容就是實際的代碼。各個函數主要是實現監控并記錄的功能，我們挑選一個比較有代表性的”newTrack_h”來進行分析。
newTrack_h函數實現是在hijack_func\hooker_thumb.c文件中。
由于使用的是inline hook，并且目的是監控，而非控制，所以，在每個Hook函數開始位置都有相似的調用原始函數的過程。通過helper_precall和helper_postcall來實現安裝和卸載inline hook的功能。
之后經過一些無關緊要的操作，生成一個struct cblk_t *類型的結構體變量cblk_tmp，并進行初始化。
然后為cblk_tmp->filename生成一個值，作為保存的文件名。
以cblk_tmp->filename作為文件名創建文件
繼續對cblk_tmp的成員變量進行賦值，最后放入哈希表中，方便后續的查找等操作。
至此，newTrack_h函數的主要流程就描述完了。相信大家一定很奇怪，說好的語音監控呢？根本沒有看到啊。事實上，用于記錄語音的操作是在recordTrack_getNextBuffer3_h和playbackTrack_getNextBuffer3_h中實現的，從名字就能看出來，這兩個函數分別用于在錄音和播放的時候，用于記錄音頻內容。由于這兩個函數比較復雜，我們只重點介紹一下音頻記錄相關的部分。
選取playbackTrack_getNextBuffer3_h進行分析，該函數實現在用戶播放語音的時候，進行記錄。
在函數的開始部分，依舊是調用原始的函數。
之后，會根據系統版本，通過硬編碼的偏移值，獲取系統結構地址。
然后將信息寫入文件
注意到，bufferRaw就是音頻的信息，根據之前的表格，可以看到playbackTrack_getNextBuffer3_h實際上是對AudioFlinger::PlaybackThread::Track::getNextBuffer函數進行的Hook，其參數AudioBufferProvider::Buffer *的內容，就是音頻內容，也就是bufferRaw的來源。通過記錄bufferRaw，就能記錄原始的音頻內容了。
在recordTrack_getNextBuffer3_h函數中也有類似的操作，就不贅述了。
從記錄方式上來看，該代碼按照自己定義的方式來記錄信息的，生成的也是bin文件。所以生成的文件并不能直接用于播放。好在HackingTeam預留了一個轉換文件，在decoder\ decoder.py文件中，實現了將記錄的bin文件轉換為wav文件的功能。
至此，語音監控功能的源碼分析也就基本完成了。總體看來，HackingTeam的代碼寫的還是非常漂亮的，其中動態庫注入部分，以及inline Hook部分源碼，預計在未來一段時間會被借鑒與各種Android項目中。但是這分代碼依舊存在一些問題，首先是必須root權限才能正確執行，而且在實現的過程中，使用了一些硬編碼，而Android系統本身碎片化十分嚴重，各種定制ROM流行，這就使得硬編碼只能適配少數一部分系統，而無法做到對所有Android系統都有效。相信這也是一種無奈之舉吧。