9102年了贝攒，我想大部分人使用微信的頻率應(yīng)該都會(huì)高于QQ了吧。
以前在QQ傳文件的時(shí)候时甚，哪里會(huì)想到會(huì)有文件大小限制饿这，幾G、幾十G的文件隨意傳撞秋。
而現(xiàn)在长捧，用微信傳文件，很尷尬吻贿，只能傳100M或更小的文件串结。
為什么做這個(gè)限制？我想可能是因?yàn)槲⑿乓婚_(kāi)始就是手機(jī)應(yīng)用舅列。
- 最初手機(jī)存儲(chǔ)空間并不像電腦那么大肌割，所以微信可能認(rèn)為手機(jī)存不下（而現(xiàn)在256G是標(biāo)配了）。
- 更重要的是帐要，手機(jī)使用流量把敞，大文件消耗流量更多，用戶肯定受不了（現(xiàn)在流量也不貴了榨惠，再說(shuō)還有WIFI呢）奋早。
所以限制文件大小，合情合理赠橙。
但是耽装，現(xiàn)在微信也出了PC版本了，也有很多用戶在使用PC版本微信期揪，還在限制100M就有點(diǎn)說(shuō)不過(guò)去了掉奄。
你說(shuō)怕手機(jī)收到后下載耗流量，確實(shí)有點(diǎn)浪費(fèi)凤薛，那你服務(wù)端可以區(qū)分一下嘛姓建，用戶也可以自己確認(rèn)是否下載啊诞仓。
但是，微信并沒(méi)有做什么速兔，這就很影響PC上微信的使用體驗(yàn)了狂芋。
我要用微信傳大文件啊（100M以上）憨栽，因?yàn)槲襋Q密碼忘了帜矾，因?yàn)槲遗笥裃Q密碼忘了...
好，既然如此屑柔，你不做...還是...你不做屡萤，那就我來(lái)做！
1掸宛、突破本地100M限制
下載最新的PC微信（當(dāng)時(shí)2.6.8.65）死陆，開(kāi)始分析微信對(duì)文件大小限制是如何做的，然后一一突破唧瘾。
在選擇文件過(guò)程中就做了100M限制措译。
嗯，文件大小首先就想到了GetFileSize饰序，下個(gè)斷點(diǎn)看看领虹。
bp KERNEL32!GetFileSize
bp KERNEL32!GetFileSizeEx
0:000:x86> kvn
# ChildEBP RetAddr Args to Child
00 0075cf6c 7908f015 c78f272a 10977de0 00000001 KERNEL32!GetFileSizeEx
01 0075cfec 7908ed8c 109a7218 0000001f 00000020 WeChatWin!IMVQQEngine::`default constructor closure'+0x2f735
0:000:x86> g
Breakpoint 2 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77 jmp dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:000:x86> kvn
# ChildEBP RetAddr Args to Child
00 0075e810 7908fd9e c78f0396 00000000 0e61c3a4 KERNEL32!GetFileSizeEx
01 0075eb50 792e5b5c 00000306 0000000f 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x304be
0:000:x86> g
Breakpoint 2 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77 jmp dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:008:x86> kvn
# ChildEBP RetAddr Args to Child
00 0378e530 79a9eba3 00000002 00000000 00000000 KERNEL32!GetFileSizeEx
01 0378e5c4 79a9ee3d 00000002 00000000 00000000 WeChatWin!_ASSERT+0x553c3 //10aeeba3
0:008:x86> g
艾瑪啊，觸發(fā)有點(diǎn)多啊求豫，頭疼塌衰。算了，換個(gè)思路蝠嘉。點(diǎn)擊發(fā)送文件按鈕最疆，會(huì)彈出文件選擇對(duì)話框，這是微軟提供的蚤告。
寫(xiě)過(guò)win32 gui或者mfc程序的同學(xué)應(yīng)該想到了努酸，對(duì)彈出文件選擇對(duì)話框的函數(shù)下斷點(diǎn)。
不是~bp shell32!SHBrowseForFolderW這是目錄選擇杜恰，也不是bp shell32!SHFileOperationW~获诈，而是這個(gè)：bp comdlg32!GetOpenFileNameW
Breakpoint 5 hit
COMDLG32!GetOpenFileNameW:
7523e810 8bff mov edi,edi
0:000:x86> kvn
# ChildEBP RetAddr Args to Child
00 0075cffc 7908eac2 0075d014 c78f0306 1097cb80 COMDLG32!GetOpenFileNameW (FPO: [1,1053,4])
01 0075ebc0 7907e81c 000003e9 00000000 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x2f1e2 //100deac2
02 0075ebd8 792e586f 000003e9 00000000 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x1ef3c
03 0075ec38 792e556e c78f0492 00000000 0075ed54 WeChatWin!IMVQQEngine::`default constructor closure'+0x285f8f
04 0075ec54 753e48eb 00521896 000007e7 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x285c8e
05 0075ec80 753c613c 792e54a0 00521896 000007e7 USER32!_InternalCallWinProc+0x2b
06 0075ed64 753c528e 792e54a0 00000000 000007e7 USER32!UserCallWinProcCheckWow+0x3ac (FPO: [SEH])
07 0075edd8 753c5070 000007e7 0075ee18 7968d71f USER32!DispatchMessageWorker+0x20e (FPO: [Non-Fpo])
08 0075ede4 7968d71f 0075edfc 00000000 00d90000 USER32!DispatchMessageW+0x10 (FPO: [Non-Fpo])
09 0075ee18 79666f9e 77779830 754207b0 00000001 WeChatWin!WCSGetInstance+0x2388f
0a 0075f0a0 00d91918 00d90000 00a72bf2 00000000 WeChatWin!StartWachat+0x14e
0b 0075f8bc 00d930b9 00d90000 00000000 00a72bf2 WeChat+0x1918
0c 0075f908 77776359 00520000 77776340 0075f974 WeChat+0x30b9
0d 0075f918 77a57a94 00520000 b5777c1c 00000000 KERNEL32!BaseThreadInitThunk+0x19 (FPO: [Non-Fpo])
0e 0075f974 77a57a64 ffffffff 77a78e17 00000000 ntdll_779f0000!__RtlUserThreadStart+0x2f (FPO: [SEH])
0f 0075f984 00000000 00d9312b 00520000 00000000 ntdll_779f0000!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
根據(jù)返回地址7908eac2計(jì)算到在IDA中地址100deac2，用IDA翻看一下函數(shù)怎么做的箫章。
微信可以同時(shí)選擇多個(gè)文件烙荷，這里循環(huán)獲取到路徑镜会，限制最多10個(gè)檬寂，然后進(jìn)入sub_100DEED0處理。
v24 = -GetOpenFileNameW(&v44);
if ( *filename )
{
while ( 1 )
{
memset(&String1, 0, 0x208u);
lstrcatW(&String1, (LPCWSTR)String);
lstrcatW(&String1, filename); // 構(gòu)造完整路徑
v46 = 0;
*(_OWORD *)sigle_filepath = 0i64;
sub_104822F0((int *)sigle_filepath, &String1, 0xFFFFFFFF);
LOBYTE(v73) = 4;
sub_10056060((unsigned int *)&filepath1, (unsigned int)sigle_filepath);
LOBYTE(v73) = 3;
if ( ++ii > 10 ) // 最多10個(gè)文件
break;
filename += lstrlenW(filename) + 1; // 下一個(gè)文件
if ( !*filename )
goto LABEL_35;
}
...
sub_104822F0((int *)&filepath__, *filepath1_, 0xFFFFFFFF);
sub_100DEED0((int)v61, v33, filepath__.buf, filepath__.len, (int)v41, v42, v43);
進(jìn)入函數(shù)sub_100DEED0之后戳表，一下就看到獲取文件大小的函數(shù)桶至，然后是判斷文件是否大于100M昼伴。
v16 = f_FileUtils::fileSize_10475050(&path);
filesize = v16.LowPart;
if ( filesize > 0 )
{
if ( filesize >= 104857600 ) // 100M
{
//100M提示框
}
}
}
先手工windbg修改一下指令，驗(yàn)證是否正確镣屹。把0x6400000改為0圃郊，jl改成jge即可。篇幅原因女蜈，不展開(kāi)了持舆。
通過(guò)調(diào)試確認(rèn)，100M以上文件繞過(guò)這個(gè)限制伪窖。
.text:100DF347 07C cmp esi, 6400000h
.text:100DF34D 07C jl loc_100DF263 //0f8c10ffffff=>0f8d10ffffff(jge)
=>
.text:100DF347 07C cmp esi, 0
.text:100DF34D 07C jge loc_100DF263 //0f8c10ffffff=>0f8d10ffffff(jge)
但是還沒(méi)完逸寓，依然會(huì)彈框，居然還有二次驗(yàn)證覆山。
調(diào)試函數(shù)sub_100DEED0竹伸，單步繼續(xù)往下走，看看是哪里彈框簇宽。最終找到在sub_10099D70這個(gè)函數(shù)里還有校驗(yàn)勋篓。
v33 = sub_104FF8F0(v7 + 337);
sub_10099D70((_BYTE *)v7[344], (size_t *)&path, (char *)(v33 == 0));
同樣進(jìn)入sub_10099D70，找到校驗(yàn)代碼魏割。
v7 = f_FileUtils::fileSize_10475050(a2);
filesize = v7.LowPart;
if ( filesize > 0 )
{
if ( filesize > 104857600 ) // 100M
{
//100M提示框
}
}
windbg修改一下指令譬嚣，驗(yàn)證是否正確。把0x6400000改為0钞它，jle改成jge即可孤荣，調(diào)試確認(rèn)繞過(guò)檢查。
.text:1009A34C 0AC cmp esi, 6400000h
.text:1009A352 0AC jle loc_1009A25C//0f8e04ffffff =>0f8d04ffffff(jge)
=>
.text:1009A34C 0AC cmp esi, 0
.text:1009A352 0AC jge loc_1009A25C//0f8e04ffffff =>0f8d04ffffff(jge)
過(guò)了這兩處檢查后须揣，文件成功顯示在輸入框中盐股。
不過(guò)直接發(fā)送依然失敗，顯示“上傳文件大小不能大于100M”耻卡，應(yīng)該是服務(wù)器做了檢查疯汁。
另外，微信還支持拖動(dòng)文件發(fā)送卵酪，經(jīng)過(guò)前面兩步的突破幌蚊，此時(shí)拖入文件依然提示“發(fā)送的文件大小不能大于100M”。
那繼續(xù)把這個(gè)干掉吧溃卡。拖動(dòng)文件首先想到的就是DragQueryFileW溢豆，加上斷點(diǎn)試試。
bp shell32!DragQueryFileW
0:000:x86> kv
# ChildEBP RetAddr Args to Child
00 004fdbec 790ce89a 0f1a3978 ffffffff 00000000 SHELL32!DragQueryFileW
01 004fded8 7577104b 038ca6c0 0c6b0bf8 00000001 WeChatWin!IMVQQEngine::`default constructor closure'+0x6efba//1011e89a 1011e8c9
02 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x2eb (FPO: [Non-Fpo]) (CONV: stdcall) [com\ole32\com\rot\getif.cxx @ 658]
03 004fdf5c 75dd4f3d 75770d60 004fe178 0000000c RPCRT4!Invoke+0x34
0:000:x86> kv 4
# ChildEBP RetAddr Args to Child
00 004fdbec 790ce8c9 0f1a3978 00000000 004fdcc0 SHELL32!DragQueryFileW (FPO: [Non-Fpo])
01 004fded8 7577104b 038ca6c0 0c6b0bf8 00000001 WeChatWin!IMVQQEngine::`default constructor closure'+0x6efe9//1011e8c9
02 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x2eb (FPO: [Non-Fpo]) (CONV: stdcall) [com\ole32\com\rot\getif.cxx @ 658]
03 004fdf5c 75dd4f3d 75770d60 004fe178 0000000c RPCRT4!Invoke+0x34
確實(shí)拖動(dòng)中會(huì)斷下瘸羡，但經(jīng)過(guò)分析并不是關(guān)鍵代碼漩仙，沒(méi)有對(duì)文件進(jìn)行處理，另外斷下后，再跑起來(lái)队他，拖動(dòng)文件失敗卷仑。
所以另想他法。又想到了前面沒(méi)有用處的getfilesizeex,再來(lái)嘗試一下麸折。
0:004> bp kernel32!getfilesizeex
0:004> g
Breakpoint 6 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77 jmp dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:000:x86> kv
# ChildEBP RetAddr Args to Child
00 004fde4c 791a9fc6 c74c6e8e 00000001 038ca6c0 KERNEL32!GetFileSizeEx
01 004fdec8 790cea71 0c700528 7a00c9dc 004fdf18 WeChatWin!IMVQQEngine::`default constructor closure'+0x14a6e6 //101f9fc6
02 004fded8 75770ed2 038ca6c0 0c700528 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x6f191
03 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x172 (FPO: [Non-Fpo])
嘿嘿锡凝，沒(méi)想到一下子找到了關(guān)鍵位置，getfilesizeex建了一功垢啼。
filesize = f_FileUtils::fileSize_10475050(v52);
if ( sub_106DEFCB(*((_DWORD *)v2 + 463)) == 2 )
{
if ( filesize.QuadPart > 0x1900000 )
goto LABEL_28;
}
else if ( filesize.QuadPart > 104857600 )
{
//100M提示
}
同樣的方式窜锯，把0x6400000改為0，ja改成jbe芭析，繞過(guò)這個(gè)校驗(yàn)衬浑。
.text:101FA196 078 81 7D C0 00 00 40 06 cmp dword ptr [ebp+filesize], 6400000h
.text:101FA19D 078 0F 87 76 FE FF FF ja loc_101FA019
=>
.text:101FA196 078 81 7D C0 00 00 00 00 cmp dword ptr [ebp+filesize], 0
.text:101FA19D 078 0F 86 76 FE FF FF jbe loc_101FA019
OK，到這里放刨，本地100M限制就成功突破工秩，下面繼續(xù)看看如何繞過(guò)服務(wù)器限制。
2进统、突破服務(wù)器100M限制
前面提到助币，能夠選擇大于100M文件之后，點(diǎn)擊發(fā)送依然會(huì)失敗螟碎，提示“上傳文件大小不能大于100M”眉菱。
很明顯服務(wù)器做了上傳文件限制。
所以如何突破這個(gè)限制呢掉分？
額俭缓，動(dòng)不了服務(wù)器代碼啊...
能夠想到的就是在文件發(fā)送前，自動(dòng)分割文件為小于100M的多個(gè)文件酥郭，然后將分割的文件自動(dòng)發(fā)送出去华坦，在接收方，把收到的每個(gè)文件再自動(dòng)合并不从。
如此服務(wù)器也不會(huì)說(shuō)文件大于100M了惜姐，對(duì)于用戶來(lái)說(shuō)，體驗(yàn)也是一致的椿息。
是的歹袁，我就是這么實(shí)現(xiàn)的。
首先寝优，找到發(fā)送文件的函數(shù)条舔。
由于之前分享過(guò)如何找到發(fā)送消息的函數(shù)，詳情請(qǐng)看文章微信PC端技術(shù)研究(3)-如何找到消息發(fā)送接口乏矾，所以這里不詳細(xì)分析如何找到發(fā)送文件的函數(shù)了孟抗。
直接拿來(lái)用迁杨，就是這個(gè)函數(shù)sub_102382E0。
.text:100CC124 DE0 83 EC 14 sub esp, 14h
.text:100CC127 DF4 8B CC mov ecx, esp ; filepath
.text:100CC129 DF4 89 65 A0 mov [ebp-60h], esp
.text:100CC12C DF4 57 push edi ;
.text:100CC12D DF8 E8 FE 5E 3B 00 call sub_10482030
.text:100CC132 DF4 83 EC 14 sub esp, 14h
.text:100CC135 E08 8B CC mov ecx, esp
.text:100CC137 E08 89 65 9C mov [ebp-64h], esp
.text:100CC13A E08 FF 75 B4 push dword ptr [ebp-4Ch]
.text:100CC13D E0C E8 EE 5E 3B 00 call sub_10482030
.text:100CC142 E08 8D 85 40 FB FF FF lea eax, [ebp-4C0h] ; wxid
.text:100CC148 E08 C6 45 FC 0F mov byte ptr [ebp-4], 0Fh
.text:100CC14C E08 50 push eax ;
.text:100CC14D E0C E8 AE F9 F9 FF call sub_1006BB00
.text:100CC152 E0C 8B C8 mov ecx, eax
.text:100CC154 E0C C6 45 FC 0C mov byte ptr [ebp-4], 0Ch
.text:100CC158 E0C E8 83 C1 16 00 call sub_102382E0 //發(fā)送文件
接口大概是這個(gè)樣子的夸浅。
void __stdcall fakeWechatSendMsg1(int unk, wchar_t* wxid, int len1, int maxlen1, int unk1, int unk2, wchar_t* path, int len2, int maxlen2, int unk3, int unk4, int a1, int a2, int a3, int a4, int a5, int a6)
然后hook sub_102382E0仑最，拿到path文件路徑后扔役，獲取文件大小帆喇，如果大于100M，則分割文件亿胸，然后重新調(diào)用sub_102382E0把分割文件發(fā)送出去坯钦。大概代碼如下：
bool fakeWechatSendMsgInternal(DWORD dwEcx, wchar_t* wxid, wchar_t* filepath)
{
int filesize = XxGetFileSize(filepath); //獲取文件大小
if (filesize > FILE_SIZE_100M) {
return ExtendSendFile(dwEcx, wxid, filepath);
}
return false;
}
bool ExtendSendFile(DWORD dwEcx, wchar_t* wxid, WCHAR* filepath)
{
std::vector<std::wstring> filevec;
if (SplitFile(filepath, filevec) && filevec.size() > 0) { //分割文件
for (int i = 0; i < filevec.size(); i++) {
SendFileMsg(wxid, (WCHAR*)filevec[i].c_str()); //發(fā)送分割文件
}
return true;
}
return false;
}
OK，突破服務(wù)器100M限制也完成了（詳細(xì)實(shí)現(xiàn)代碼請(qǐng)移步SuperWeChatPC開(kāi)源項(xiàng)目）侈玄。
不過(guò)在測(cè)試中婉刀，發(fā)現(xiàn)bug多多（說(shuō)的是微信）。
- 經(jīng)測(cè)試自帶單文件發(fā)送功能序仙，100M突颊，甚至99M、或者更小點(diǎn)的文件潘悼，發(fā)送到最后都沒(méi)成功律秃，微信bug or 網(wǎng)絡(luò)問(wèn)題？
- 96M左右可以成功治唤，55M左右文件可以妙傳棒动，不穩(wěn)定，這個(gè)可能網(wǎng)絡(luò)問(wèn)題宾添，但是我怎么也是100M寬帶啊船惨。
- 自帶多個(gè)文件同時(shí)發(fā)送，40M都無(wú)法發(fā)送成功缕陕。
- 有時(shí)還會(huì)提示：文件無(wú)法發(fā)送粱锐，已超過(guò)今日發(fā)送限制。
- 而此時(shí)選擇10M以內(nèi)文件依然能夠發(fā)送成功扛邑。
所以最后卜范，我不得不面對(duì)現(xiàn)實(shí)，把文件分割成了每個(gè)10M大小的文件進(jìn)行嘗試鹿榜，終于一個(gè)大于100M的文件發(fā)送成功了海雪，并且非常穩(wěn)定！
3舱殿、總結(jié)
簡(jiǎn)單總結(jié)一下奥裸，我是如何讓微信發(fā)送成功100M以上文件的。
- 首先沪袭、突破本地100M限制湾宙，也就是選擇100M文件限制樟氢，最終patch三個(gè)點(diǎn)繞過(guò)判斷即可。
- 然后侠鳄，hook發(fā)送文件接口埠啃，把大于100M文件分割，然后自動(dòng)發(fā)送小文件伟恶。
- 最后碴开，接收方自動(dòng)合并文件（并沒(méi)有做，哈哈）
因?yàn)榻邮辗讲](méi)有做自動(dòng)合并的功能博秫，所以需要自己合并一下潦牛，也很簡(jiǎn)單。
//使用windows原生命令合并文件
copy /b Test_100M.pdf._1+Test_100M.pdf._2+Test_100M.pdf._3 Test_100M.pdf
讓這個(gè)功能更完美挡育，還需要做：
- 刪除分割的小文件
- 接收方自動(dòng)合并文件
- 微信修復(fù)bug巴碗，能夠100M分割（@tencent @weixin)
最后，想試用大文件傳輸功能即寒，請(qǐng)下載最新的https://github.com/anhkgg/SuperWeChatPC橡淆。
歡迎PR、star母赵、試用逸爵。
參考：
