教會微信:突破文件發送100M限制

9102年了,我想大部分人使用微信的頻率應該都會高於QQ了吧。

以前在QQ傳文件的時候,哪裏會想到會有文件大小限制,幾G、幾十G的文件隨意傳。

而現在,用微信傳文件,很尷尬,只能傳100M或更小的文件。

爲什麼做這個限制?我想可能是因爲微信一開始就是手機應用。

  • 最初手機存儲空間並不像電腦那麼大,所以微信可能認爲手機存不下(而現在256G是標配了)。
  • 更重要的是,手機使用流量,大文件消耗流量更多,用戶肯定受不了(現在流量也不貴了,再說還有WIFI呢)。

所以限制文件大小,合情合理。

但是,現在微信也出了PC版本了,也有很多用戶在使用PC版本微信,還在限制100M就有點說不過去了。

你說怕手機收到後下載耗流量,確實有點浪費,那你服務端可以區分一下嘛,用戶也可以自己確認是否下載啊。

但是,微信並沒有做什麼,這就很影響PC上微信的使用體驗了。

我要用微信傳大文件啊(100M以上),因爲我QQ密碼忘了,因爲我朋友QQ密碼忘了…

好,既然如此,你不做…還是…你不做,那就我來做!

1、突破本地100M限制

下載最新的PC微信(當時2.6.8.65),開始分析微信對文件大小限制是如何做的,然後一一突破。

在選擇文件過程中就做了100M限制。

1.png

嗯,文件大小首先就想到了GetFileSize,下個斷點看看。

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

艾瑪啊,觸發有點多啊,頭疼。算了,換個思路。點擊發送文件按鈕,會彈出文件選擇對話框,這是微軟提供的。

寫過win32 gui或者mfc程序的同學應該想到了,對彈出文件選擇對話框的函數下斷點。

不是~bp shell32!SHBrowseForFolderW這是目錄選擇,也不是bp shell32!SHFileOperationW~,而是這個: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])

根據返回地址7908eac2計算到在IDA中地址100deac2,用IDA翻看一下函數怎麼做的。

微信可以同時選擇多個文件,這裏循環獲取到路徑,限制最多10個,然後進入sub_100DEED0處理。

v24 = -GetOpenFileNameW(&v44);
if ( *filename )
    {
      while ( 1 )
      {
        memset(&String1, 0, 0x208u);
        lstrcatW(&String1, (LPCWSTR)String);
        lstrcatW(&String1, filename);           // 構造完整路徑
        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個文件
          break;
        filename += lstrlenW(filename) + 1;     // 下一個文件
        if ( !*filename )
          goto LABEL_35;
      }
...
sub_104822F0((int *)&filepath__, *filepath1_, 0xFFFFFFFF);
sub_100DEED0((int)v61, v33, filepath__.buf, filepath__.len, (int)v41, v42, v43);

進入函數sub_100DEED0之後,一下就看到獲取文件大小的函數,然後是判斷文件是否大於100M。

    v16 = f_FileUtils::fileSize_10475050(&path);
    filesize = v16.LowPart;

if ( filesize > 0 )
    {
      if ( filesize >= 104857600 )              // 100M
      {
         //100M提示框
      }
   }
}

先手工windbg修改一下指令,驗證是否正確。把0x6400000改爲0,jl改成jge即可。篇幅原因,不展開了。

通過調試確認,100M以上文件繞過這個限制。

.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)

但是還沒完,依然會彈框,居然還有二次驗證。

調試函數sub_100DEED0,單步繼續往下走,看看是哪裏彈框。最終找到在sub_10099D70這個函數裏還有校驗。

v33 = sub_104FF8F0(v7 + 337);
sub_10099D70((_BYTE *)v7[344], (size_t *)&path, (char *)(v33 == 0));

同樣進入sub_10099D70,找到校驗代碼。

v7 = f_FileUtils::fileSize_10475050(a2);
  filesize = v7.LowPart;
if ( filesize > 0 )
  {
    if ( filesize > 104857600 )                 // 100M
    {
        //100M提示框
    }
}

windbg修改一下指令,驗證是否正確。把0x6400000改爲0,jle改成jge即可,調試確認繞過檢查。

.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)

過了這兩處檢查後,文件成功顯示在輸入框中。

2.png

不過直接發送依然失敗,顯示“上傳文件大小不能大於100M”,應該是服務器做了檢查。

2_1.png

另外,微信還支持拖動文件發送,經過前面兩步的突破,此時拖入文件依然提示“發送的文件大小不能大於100M”。

那繼續把這個幹掉吧。拖動文件首先想到的就是DragQueryFileW,加上斷點試試。

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

確實拖動中會斷下,但經過分析並不是關鍵代碼,沒有對文件進行處理,另外斷下後,再跑起來,拖動文件失敗。

所以另想他法。又想到了前面沒有用處的getfilesizeex,再來嘗試一下。

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]) 

嘿嘿,沒想到一下子找到了關鍵位置,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,繞過這個校驗。

.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限制就成功突破,下面繼續看看如何繞過服務器限制。

2、突破服務器100M限制

前面提到,能夠選擇大於100M文件之後,點擊發送依然會失敗,提示“上傳文件大小不能大於100M”。

很明顯服務器做了上傳文件限制。

所以如何突破這個限制呢?

額,動不了服務器代碼啊…

能夠想到的就是在文件發送前,自動分割文件爲小於100M的多個文件,然後將分割的文件自動發送出去,在接收方,把收到的每個文件再自動合併。

如此服務器也不會說文件大於100M了,對於用戶來說,體驗也是一致的。

是的,我就是這麼實現的。

首先,找到發送文件的函數。

由於之前分享過如何找到發送消息的函數,詳情請看文章微信PC端技術研究(3)-如何找到消息發送接口,所以這裏不詳細分析如何找到發送文件的函數了。

直接拿來用,就是這個函數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 //發送文件

接口大概是這個樣子的。

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,則分割文件,然後重新調用sub_102382E0把分割文件發送出去。大概代碼如下:

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()); //發送分割文件
        }
        return true;
    }
    return false;
}

OK,突破服務器100M限制也完成了(詳細實現代碼請移步SuperWeChatPC開源項目)。

不過在測試中,發現bug多多(說的是微信)。

  • 經測試自帶單文件發送功能,100M,甚至99M、或者更小點的文件,發送到最後都沒成功,微信bug or 網絡問題?
  • 96M左右可以成功,55M左右文件可以妙傳,不穩定,這個可能網絡問題,但是我怎麼也是100M寬帶啊。
  • 自帶多個文件同時發送,40M都無法發送成功。
  • 有時還會提示:文件無法發送,已超過今日發送限制。
  • 而此時選擇10M以內文件依然能夠發送成功。

所以最後,我不得不面對現實,把文件分割成了每個10M大小的文件進行嘗試,終於一個大於100M的文件發送成功了,並且非常穩定!

3.png

3、總結

簡單總結一下,我是如何讓微信發送成功100M以上文件的。

  1. 首先、突破本地100M限制,也就是選擇100M文件限制,最終patch三個點繞過判斷即可。
  2. 然後,hook發送文件接口,把大於100M文件分割,然後自動發送小文件。
  3. 最後,接收方自動合併文件(並沒有做,哈哈)

因爲接收方並沒有做自動合併的功能,所以需要自己合併一下,也很簡單。

//使用windows原生命令合併文件
copy /b Test_100M.pdf._1+Test_100M.pdf._2+Test_100M.pdf._3 Test_100M.pdf

讓這個功能更完美,還需要做:

  1. 刪除分割的小文件
  2. 接收方自動合併文件
  3. 微信修復bug,能夠100M分割(@tencent @weixin)

最後,想試用大文件傳輸功能,請下載最新的https://github.com/anhkgg/SuperWeChatPC

歡迎PR、star、試用。

參考:

  1. https://www.cnblogs.com/MakeView660/p/6400083.html
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章