1、前言

網上已經有大量的web端接口解析的方法了，但是對客戶端的接口解析基本上找不到什么資料，本文主要分析網易云音樂PC客戶端的API接口交互方式。

通過內部的代理設置，使用fiddler作為代理工具，即可查看交互流程：

可以大致看一下交互方式，通過HTTPS POST交互，POST了一串params的內容，內容加密，返回JSON內容，我要做的重點就在于解析params的生成方式，用于模擬這次交互。

(Tan1993：這是后續編寫的內容，截圖很多都是后補的，所以可能會出現使用不同的調試工具，不同的環境，不同的時間等，不影響閱讀。另外本人工作主要是linux網絡方向的，像是這次只是我的一點業余愛好，也很少會去逆向東西，如果出現一些比較業余的操作或想法時，還望指出)

2、初步了解

下載最新版PC版網易云安裝（目前是2.3.0.196231版本），分析在程序所在目錄下的文件。

動態鏈接庫與可執行文件：

第一個最讓我注意的時libcurl，這個網絡庫可以用于HTTP協議交互，如果通過該庫與服務器交互， od斷點到curl_easy_perform再往回推就可以判斷轉換算法位置了，然而事實比我想象的復雜多了，這個庫僅在程序剛運行時用于一些無關的網絡交互（Tan1993：記不清了，好像是版本還是客戶端信息相關的請求）。

第二個是libcef，這個是個基于C/C++的Web browser控件，可以簡單理解為就是個瀏覽器的殼子（Tan：為什么說關鍵API沒用到libcurl庫，因為除了開始時cef框架還沒初始化前網絡交互用到那個庫而已，一點cef環境起來了，都是通過JS ajax交互了）。

其他的除了cef依賴的dll外，兩個主程序和cloudmusic.dll都比較值得關注。

資源文件：

除了在package下的其他都是cef庫依賴的資源文件。

都是未知的格式，一般看到未知格式的文件，我都會用7z嘗試打開看看，是不是某種歸檔格式文件，這個一下就蒙中了，是zip格式的。

除了幾個通過后綴就能看出來的皮膚文件，還有兩個比較可疑的文件，翻一翻比較大的orpheus.ntpk文件，里面可以看到都是網頁相關的資源文件，看到那個core.js，就讓我聯想到網頁版API提取時用到的那個core.js文件了，腦海里就想著替換然后對轉換流程動態分析了，事實有點不盡人意，該zip文件加密了。

OK，調研階段結束，在不進行逆向解析前，能了解到的也就止步于此了。

3、第一輪嘗試

其實一開始我是把目光放在libcurl上面的，在斷點到curl庫的函數上時發現只有程序剛運行時觸發過幾次，后面所有網絡交互都不用這個庫了，就轉戰到cef上。而cef的重點在于內部的JS文件，能提取到該文件才是關鍵的。

0×2712即CURLOPT_URL宏，eax中存放著url的字符串指針，基本上都是無關的url。

第一個任務來了，逆向尋找特征串，也就是密碼，這里斷點到系統文件操作API上，斷到CreateFileW，一頓的F9后可以看到加載到default.skin文件了（圖中是native.ntpk，同類型的加密ZIP文件），后續就單步調試下去。

然后看到一個比較特別的內存塊，一看就是PNG格式的文件頭，就可以判斷這一步資源已經解壓縮到內存了。

往上推幾步，斷點，縮小范圍，再跟下來，看看哪里做了解壓操作，再一步步跟函數。（Tan1993：可能比較業余，但我也只能一點點縮小范圍在一點點看流程，憑經驗判斷可能會做什么操作，縮短到比較短的范圍，不然一堆匯編碼真的會受不了，感謝世界上程序員的思想都是接近的吧）。

得知密碼后，就可以解壓出core.js文件了（Tan1993：這里僅提供思路，不提供便民服務哈）

又是這一堆讓人窒息的混淆，卡得懷疑人生，先解壓縮再看吧。

解壓后，搜幾個關鍵字，比如params，eapi，batch等最上面HTTP交互時的一些特征

關鍵代碼，像這樣混淆的JS代碼，如果不通過調試器跟蹤，很難看懂，目前能可以看出也只有channel.serialData應該時比較關鍵的轉換函數，但是搜索了整個JS文件都找不到函數定義，不知道是不是混淆到哪個奇怪的地方了。

雖然cef自帶DevTools，但是已經被屏蔽掉了也無法在程序里調出來，所以我想在JS文件中加上alert調試關鍵參數。然后我修改了core.js文件，按原來的密碼壓縮回去。但程序根本就起不來，為什么呢，看看原版的.ntpk文件，很明顯還有一些奇怪的東西和zip文件一起合成了這個ntpk文件格式。根據經驗判斷很可能時類似于數字簽名的東西（Tan1993：之前我也會對一些可能被篡改的檔案末尾對整個文件加鹽生成一個hash值用于校驗，但是后續跟完網易云的數字簽名方式讓我又學習了不少）。

4、第二輪嘗試

為了方便調試，我需要替換掉資源文件中的core.js文件，但是該資源文件不僅僅加密壓縮了，還有一些其他內容存在，所以這次跟代碼就是為了了解除了zip文件本身以外其他部分內容的作用。

還是斷到CreateFileW函數上，其實第一輪跟代碼的時候我就已經發現了部分調用系統加密服務提供程序 (CSP)庫的函數。

一步步跟過來，發現用的是SHA1數字簽名算法（Tan1993：不是很了解CSP庫，但這個是為Windows系列操作系統制訂的底層加密接口，和我理解的SHA不太一樣，我姑且將程序內部的那部分稱為公鑰，與文件頭部的校驗數據進行校驗）。

文件頭NTPK，文件長度0x0D5C5B，校驗串長度0×100

剛好差了0×110長度，除了0×100用于校驗的數據，還有0×10的頭部。

由于我是無法在不知道私鑰的情況下，再次對該文件進行簽名的，所以我只能把程序內部的用于校驗的公鑰一并替換，再生成一個對應的檢驗數據，從而通過系統驗證，或者直接把驗證部分的代碼跳轉邏輯修改掉（Tan1993：其實可能改分支流程修改會更簡單也說不定，但我一開始選擇的是替換公鑰重新生成校驗數據）。

int GenKey(HCRYPTPROV hProv)
{
	HCRYPTKEY hKey;
	HANDLE hFile = NULL, hOutFile = NULL;
	DWORD dwSize = 0, dwRead = 0, dwWrite = 0, dwBlobLen = sizeof(bRsaKey);
	BYTE *pbFileData = NULL;
	int ret = -1;

	// 先讀取原版的dll，加載到內存中
	hFile = CreateFileW(L"cloudmusic_src.dll",
		GENERIC_READ, FILE_SHARE_READ, NULL,
		OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

	dwSize = GetFileSize(hFile, NULL);
	pbFileData = new BYTE[dwSize];
	ReadFile(hFile, pbFileData, dwSize, &dwRead, NULL);
	CloseHandle(hFile);

	if (!memcmp(pbFileData + 0x7C3438, bRsaKey, sizeof(bRsaKey)))
	{
		// 重新生成密鑰對
		CryptGenKey(hProv, AT_SIGNATURE, CRYPT_EXPORTABLE, &hKey);
		memset(bRsaKey, 0, sizeof(bRsaKey));
		CryptExportKey(hKey, NULL, PUBLICKEYBLOB, 0, bRsaKey, &dwBlobLen);
		// 將新生成的公鑰覆蓋原本dll中的公鑰
		memcpy(pbFileData + 0x7C3438, bRsaKey, sizeof(bRsaKey));
		// 隨帶把debug端口開了（后續再解釋）
		SetDebugPort(pbFileData);
		hOutFile = CreateFileW(L"cloudmusic.dll",
			GENERIC_WRITE, FILE_SHARE_READ, NULL,
			CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
		// 寫回到dll中
		WriteFile(hOutFile, pbFileData, dwSize, &dwWrite, NULL);
		CloseHandle(hOutFile);
		ret = 0;
	}
	delete[] pbFileData;
	CryptDestroyKey(hKey);
	return ret;
}

int EncFile(HCRYPTPROV hProv, LPCWCHAR wstrInFile, LPCWCHAR wstrOutFile)
{
	HCRYPTHASH hHash;
	DWORD dwSize = 0, dwRead = 0, dwWrite = 0, dwOutSignSize = 0;
	HANDLE hFile = NULL, hOutFile = NULL;
	BYTE *pbFileData = NULL, *pbSignData = NULL;

	// 打開帶密碼的壓縮文件
	hFile = CreateFileW(wstrInFile,
		GENERIC_READ, FILE_SHARE_READ, NULL,
		OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

	dwSize = GetFileSize(hFile, NULL);
	pbFileData = new BYTE[dwSize];
	ReadFile(hFile, pbFileData, dwSize, &dwRead, NULL);
	CloseHandle(hFile);

	// 打開輸出文件
	hOutFile = CreateFileW(wstrOutFile,
		GENERIC_WRITE, FILE_SHARE_READ, NULL,
		CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
	// 寫入文件頭
	WriteFile(hOutFile, bHead, sizeof(bHead), &dwWrite, NULL);
	// 寫入原壓縮文件長度
	WriteFile(hOutFile, &dwSize, sizeof(int), &dwWrite, NULL);

	// 創建并計算Hash值
	CryptCreateHash(hProv, CALG_SHA, 0, 0, &hHash);
	CryptHashData(hHash, pbFileData, dwSize, 0);
	CryptSignHash(hHash, AT_SIGNATURE, NULL, 0, NULL, &dwOutSignSize);
	pbSignData = new BYTE[dwOutSignSize];
	CryptSignHash(hHash, AT_SIGNATURE, NULL, 0, pbSignData, &dwOutSignSize);

	// 寫入Hash值大小
	WriteFile(hOutFile, &dwOutSignSize, sizeof(int), &dwWrite, NULL);
	// 寫入Hash值（校驗數據）
	WriteFile(hOutFile, pbSignData, dwOutSignSize, &dwWrite, NULL);
	// 寫入原壓縮文件
	WriteFile(hOutFile, pbFileData, dwSize, &dwWrite, NULL);

	CloseHandle(hOutFile);

	delete[] pbSignData;
	delete[] pbFileData;

	CryptDestroyHash(hHash);
	return 0;
}

截了一部分代碼，用于修改cloudmusic.dll中的二進制數據，偏移是根據內存加載地址與基址算的，直接固定偏移修改即可。

到這一步其實我已經可以替換掉core.js文件并且可以alert彈出對話框，顯示一些JS運行時數據了，雖然alert彈框并不是那么好用。

通過alert我可以看到加密前的內容，也就是具體發了哪些數據，以及加密后是什么樣子的，很可惜的是當我嘗試alert(channel.serialData)時發現是[native code]，按我個人理解應該是系統二進制函數才會顯示這個的吧（對JS并不是非常了解），懷疑是庫函數，但查詢無果，后來想了想會不會是JS調用了C++代碼（憑我對cef粗糙的理解），我嘗試去查了一下，果然是可以的，那么很有可能這部分加密轉換的代碼還是在主程序中，這就很頭疼了，剛從主程序逆向脫離出來到JS這個自由的世界，又要回到看匯編碼的環境了。

5、第三輪嘗試

這一輪主要目的是找到channel.serialData在主程序的位置，根據我對cef的理解，應該是在程序啟動時，注冊了一部分回調函數，可以從注冊的時候找到回調函數入口，然后等觸發channel.serialData動作時，從回調函數跟代碼跟下來。

根據DLL版本，我找到了對應的cef源碼版本，cef注冊回調時是整個結構體的，必須找到對應的版本避免新版本結構體不一樣導致偏移位置有差異。

在看源碼的過程中發現結構體里有個很有意思的字段，一個debug端口，調研了一下，這個端口很有用了，可以遠程DevTools，這樣還用什么alert。

如果要在調用初始化前把結構體改掉，要么API Hook修改，要么靜態文件修改，文件修改的話只能舍棄一些無用代碼來改這個結構體了，我選了一個不影響的賦值語句，改成給這個地址賦9222。

對照源碼中結構體計算偏移值

原本修改cloudmusic.dll的代碼中增加個代碼段修改的方法

// 修改Debug Port為9222
void SetDebugPort(BYTE *pbFileData)
{
	if (!memcmp(pbFileData + 0x14EED, bSettingAsm, sizeof(bSettingAsm)))
	{
		bSettingAsm[2] = 0x94; // 結構體偏移
		bSettingAsm[6] = 0x06; // 0x2406也就是9222端口
		bSettingAsm[7] = 0x24;
		memcpy(pbFileData + 0x14EED, bSettingAsm, sizeof(bSettingAsm));
	}
}

現在我就可以通過http://127.0.0.1:9222遠程訪問DevTools了。可當我打開網頁時一片空白，這時候又憑借我對cef粗略的了解，在程序目錄下，并沒有devtools相關的資源，其實只要把資源文件補上就可以了（官網已經沒有這么老的資源文件檔案了，這個還是我網上找的3.1916版本的devtools資源文件）

這時候所有JS調試命令都可以改成console.log來進行了，方便了好多。

回到正題，從注冊來跟代碼實在是太痛苦了。一個是注冊的內容比較多，一層疊一層的，而且程序用的是C++ warp的C語言版本的cef庫，和源碼對照跟的時候還是有點差別的。這時候我想到一個非常好的方法，那就是制造一個死循環。

6、第四輪嘗試

上面就提到了，我放棄了從注冊一步步跟蹤回調函數的麻煩方案，而是在JS中知道一個死循環，不停的調用channel.serialData函數，等程序單核滿載時，只需要將調試器附加程序，點一點暫停，基本上就是這個函數相關業務流程的代碼了（JS到機器碼代碼按我理解應該在堆上，而加密的代碼應該在程序代碼段上，所以我定位的時候可以忽略掉很多JS的代碼，找到真正相關的代碼位置）

實際上，channel.serialData的匯編碼也非常多，流程也分了好多部分，這部分工作量實在是降不下來，但是很多可能是為了防止靜態分析的代碼，部分特征串是運行時生成的，但是因為這部分特征串都是固定的，所以是可以不用去仔細琢磨的（然而我花了一兩天來看那一堆匯編碼來算出特征串，非常郁悶，早知道就逆推就好，但說實話，光逆推也會很難，主要是要有一定理解）

簡單說明一下轉換流程

1、 輸入url（請求部分）和data（提交的json數據）

2、 拼成”nobody” + url + “use” + data + “md5forencrypt”字符串

3、 對字符串計算MD5

4、 二次拼接url + “-36cd479b6b5-” + data + “-36cd479b6b5-” + md5

5、 0×10對齊，缺少的部分會以缺少的位數來填充

6、 私有轉換方法（也許是我不知道的一種加密方式？）

附上一部分分析的圖

待加密數據，0×10字節對齊，每次處理0×10字節的數據

輔助加密數據（動態生成，但是是固定的，我還傻傻去復現了一遍生成流程）

開始對0×10進行轉換

一堆異或和位移計算，這個還是很好復現到C的代碼中的，這個比較長就不全粘貼了。

循環轉換完后再按照”%02X”格式snprintf到字符串即可。我沒有過多去理解這個加密算法究竟是什么原理，只是直譯匯編碼。

后來嘗試反過來解析，看了一早上沒看出來，簡單描述一下為什么難以逆轉的問題。

內存塊mem

a1b1b1c1a1b1b1c1 a2b2b2c2a2b2b2c2 ………

eax = a1a2a3a4

ebx = b1b2b3b4

ecx = c1c2c3c4

edx = d1d2d3d4

eax = mem[a4 * 8] ^ mem[b3 * 8 + 3] ^ mem[c2 * 8 + 2] ^ mem[d1* 8 + 1]

ebx = mem[a3 * 8] ^ mem[b2 * 8 + 3] ^ mem[c1 * 8 + 2] ^mem[d4 * 8 + 1]

ecx = mem[a2 * 8] ^ mem[b1 * 8 + 3] ^ mem [c4 * 8 + 2] ^ mem[d3* 8 + 1]

edx = mem[a1 * 8] ^ mem[b4 * 8 + 3] ^ mem[c3 * 8 + 2] ^mem[d2 * 8 + 1]

然后在得知后面的eax，ebx，ecx，edx逆推原來的，感覺不太可能，但是mem并不是沒有規律的一個內存塊，而且數組索引時也做了些巧妙的偏移，事實上內存塊確實有不少規律（比如a1是偶數時b1是a1的一半，c1是a1 ^ b1），而且和索引時的偏移可能會相得益彰，如果能看出竅門說不定還是能解的，有興趣的小伙伴也可以研究一下（Tan1993：個人沒學過加密學，只略懂一部分概念）

7、匯總

其實到這一步，我可以通過遠程devtools來看發送前未加密的內容以及結構，同時我也可以通過已經復現的加密方法，對不同業務數據加密發送出去。我發現有一部分請求數據返回內容也是加密的，但這個是可以在客戶端控制e_r的值來控制是否需要返回加密內容的。

寫個模擬客戶端下載歌曲的小Demo，本來發送和接收都是加密的數據的下載接口，就可以通過服務器驗證實現下載了，解析到此告一段落，雖然過程中還有很多內容值得研究，如果有機會以后會繼續挖掘。

8、總結

由于并沒有找到任何的參考資料，斷斷續續也研究了一周時間。除了實現了目標以外，還是有不少收獲的，比如比較有趣的加密算法，數字簽名方法，cef庫，還有一些逆向的思路。

比較遺憾的是沒有把解密的算法也解析出來，同時在客戶端控制e_r的值來控制返回數據是否加密顯然不是好方法，官方只需要忽略這個參數強制對部分API返回加密數據，正常的客戶端也沒有任何影響（難道有平臺相關性所以才把這個參數放到客戶端的嗎？）。

（Tan1993：視情況考慮是否在github提供源碼）

9、彩蛋

將一件有趣的事，當時我嘗試在一臺國外IP的服務器上調用web的api接口時發現不能適用，獲取不到數據，然后我又跟了一便JS代碼發現邏輯不一樣，其中發現了一個很有意思的特征串（在你們看不到的地方，總有調皮的程序員）：

總結

以上是生活随笔為你收集整理的网易云音乐PC客户端加密API逆向解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。