Skype 錄音與自動答錄機：API Hook 核心技術深度解析

Skype 憑藉優異語音品質成為全球熱門通訊軟體。早期版本缺乏內建錄音功能，筆者於 2006 年針對業務需求，研究並實作了一套 Skype 錄音與自動答錄機系統。本文揭秘其核心編程思路與關鍵代碼，為音頻編程愛好者提供參考。

常規錄音路徑為何失效？

嘗試用標準錄音 API（選取「立體聲混音」錄對方、「麥克風」錄自己）會發現：

• 啟用「立體聲混音」時，麥克風訊號被丟棄 → 對方聽不到我方聲音。
• 啟用「麥克風」錄音時，通道已被 Skype 佔用 → 我方程式無法二次開啟。

結論：常規錄音機制無法同時捕獲雙向語音流。

核心突破：Win32 API Hook 技術

所有語音軟體最終都會呼叫 Windows 底層音頻 API（位於 winmm.dll）。利用系統 Hook 修改這些 API 入口地址，在 Skype 調用前攔截、複製音頻數據，再轉交原函數執行，即可「神不知鬼不覺」地獲取雙向語音數據。

需 Hook 的 6 個關鍵 API

Hook 實作架構（DLL 注入）

程式必須編譯為 DLL 注入 Skype 進程。使用《Windows 核心編程》中的 CAPIHook 類修改 API 地址：

// 定義函數指標類型
typedef MMRESULT (WINAPI *PFN_waveOutWrite)(HWAVEOUT, LPWAVEHDR, UINT);
// ... 其他 5 個同理

// 修改 API 入口
CAPIHook g_waveOutWrite("winmm.dll", "waveOutWrite", (PROC)Hook_waveOutWrite, TRUE);
// ... 其他 5 個同理

攔截播放數據（對方聲音）

MMRESULT WINAPI Hook_waveOutWrite(HWAVEOUT hwo, LPWAVEHDR pwh, UINT cbwh)
{
    // pwh->lpData 緩衝區即為對方語音數據
    SendDataToMainWnd(pwh->lpData,
        pwh->dwBytesRecorded > 0 ? pwh->dwBytesRecorded : pwh->dwBufferLength,
        ENUM_CATCHSOUNDTYPE_waveOutWrite);

    // 呼叫原始 API
    return ((PFN_waveOutWrite)(PROC)g_waveOutWrite)(hwo, pwh, cbwh);
}

攔截錄音數據（我方聲音）

MMRESULT WINAPI Hook_waveInPrepareHeader(HWAVEIN hwi, LPWAVEHDR pwh, UINT cbwh)
{
    // 錄音緩衝區滿時會調用此函數準備下一塊，當前緩衝已含錄製數據
    SendDataToMainWnd(pwh->lpData,
        pwh->dwBytesRecorded > 0 ? pwh->dwBytesRecorded : pwh->dwBufferLength,
        ENUM_CATCHSOUNDTYPE_waveInPrepareHeader);

    return ((PFN_waveInPrepareHeader)(PROC)g_waveInPrepareHeader)(hwi, pwh, cbwh);
}

後續處理：MP3 壓縮與雙聲道分離

• 攔獲的輸入/輸出數據獨立存儲，壓縮時分別寫入左/右聲道，播放時宛如雙方面對面對話。
• 採用 hw_mp3_enc.dll 庫進行 MP3 編碼（效果足夠電話錄音級）。

自動答錄機邏輯

兩種實現路徑：

1. 切換混音通道播放預錄語音：來電超過設定響鈴數 → 自動摘機 → 切換錄音通道為「立體聲混音」 → 播放「請留言」語音。（本專案採用）
2. 直接注入音頻數據流：更靈活（可實現變聲等特效），但控制難度大。

關鍵效能優化：多線程架構

Hook 回調函數執行效率直接影響通話品質。耗時操作（MP3 編碼、寫檔）必須拋給工作線程處理，否則會導致通話卡頓、數據丟失。

介面展示與已知限制

• 測試環境：Windows XP + Skype 2.5 ✅
• Skype 3.0+ 版本錄音異常，推測其在 waveInPrepareHeader 前清理了數據。建議嘗試捕獲 MM_WIM_DATA 訊息獲取錄音數據，留待有興趣者攻克。

完整關鍵代碼已打包，商業邏輯代碼因版權未公開。歡迎技術交流。