首先發現這個報文是和手機端就不一樣，當手機向pc傳送訊息時，是先傳送乙個不知名報文，然後pc端返回一段比較長的報文，然後才會收到真實資料報文。
通過記憶體斷點，目前發現pc端返回的斷點可能是用來給真實收到的報文解密的。
具體除錯方式如下：
下記憶體斷點，檢視訪問資料段的地方。（這裡記憶體斷點下在靠後的部分，前面部分是一些標示位，可能進不了加密段）
而後進入乙個函式，偏移為100215a0,這裡修改函式備註為procecv26
共有5個引數，分析可知第乙個是收到的報文，第二個是解碼後的報文，第三個作為功能標示位，讓函式進入不同的功能塊。第四和第五個引數用來生成秘鑰，用於後續加密。
除錯發現第三個標識位功能大概如下：
1：處理收到的第一條通知報文吧，每次手機發訊息給pc，都會現有一條很短的訊息收到，處理完之後才能收到真正的訊息內容。
16：解密收到的報文實際內容（17也可以這裡，猜測不是單純的判斷是哪個數字，而是位操作判斷進入哪個流程，這裡沒細看）
5：加密要傳送的資料吧應該是
除錯發現，該演算法對稱加密，加解密進入同乙個流程。但是加解密跳轉的地方不一樣，加密待傳送資料在676處
繼續往上跟，進入偏移10b91740模組函式，但是這裡ida無法分析這個函式。直接從彙編層看，最終呼叫部分如下：
主要加密引數就是這個ebx和 esp+28h所儲存。
通過ollydbg跟一遍，了解下當前**跳轉過程：分別在1790、1833、18b5發生跳轉。而後算出這兩個引數的由**得到：
ebx： 函式的第乙個入參
esp+28h:函式的第乙個入參+偏移0x174得到.
上述的函式如果看xmm指令較吃力的話，可以再看看偏移10026800處的乙個函式，這個是在比較老的cpu上處理的解密函式，沒有xmm相關模組。
使用peid的kanal的外掛程式檢視，發現其中有aes加密，如圖：
在dll的偏移9797b1處下斷點，可以看到在接受訊息時斷下來了。而後往上找，找到加密部分的**，
97b830：其中第乙個入參是加密原文，返回時第二個是加密後密文。
這裡發現，當傳送資料較少時，直接傳送原文，傳送資料較多時，會先經過一步zlib壓縮，一步步通過呼叫堆疊網上找，找到壓縮部分**：
加密環節到此走完：
9774e1偏移的函式當資料過長時壓縮資料
97b830偏移的函式進行aes加密
215a0二次加密的函式進行加密 這裡就得到最終傳送的組包了
反之解密流程也是先外層解密，而後aes解密，然後zlib解壓縮。這裡解壓的時候看到了789c開頭的壓縮塊，判斷是通過zlib方式解壓的，不過這裡也沒有寫**驗證。各個函式偏移也通過逆向跟蹤全部得到：
第乙個外層解密函式，和外層加密函式在一起，只是根據第三個引數進入不同的分支，沒有細看了就。
通常加密部分**也離解密部分不遠，通過嘗試，在找到的加密函式附近的函式下斷點，找到了解密函式。
解壓函式是通過對aes解密後的資料塊下記憶體訪問斷點，以下就進入了解壓模組，但是這裡太裡層，跳出這個大迴圈就找到了解壓函式。
215a0外層解密函式
97b9d0內層aes解密函式，
7895d0 zlib的解壓函式，其中入參中棧頂攜帶解壓前資料，第二個引數攜帶解壓前資料大小，ecx暫存器儲存解壓後位址，解壓後的資料080012xx開頭，其中xx代表長度，從當前位置算起。
通過編寫dll注入工具，輸出流程中所有的輸入和輸出。
最後的**，寫的還是比較匆忙了。。
在現有基礎上，hook的**可以隨意新增了，實現自己想要的功能，什麼聊天記錄儲存的應該很容易了。
微信PC端多開的秘密
小林告訴我他是這樣做的，寫了乙個批處理 start d wechat wechat.exe start d wechat wechat.exe 我試了一下，果然如此！隨後我又加了一行，竟然還能啟動3個 接著我在網路上搜了一下，原來這一招早就被人用過了，看來是我火星了。不過到底為什麼用這種方式就能多開...
手機端跳轉微信支付問題 PC端類似
使用者側步驟 3 支付成功，使用者收到支付憑證，同時商戶後台收到支付成功的通知。4 中間頁進行h5許可權的校驗，安全性檢查 7 商戶在展示頁面，引導使用者主動發起支付結果的查詢 10 展示最終的訂單支付結果給使用者。常見問題 1 頁面 正常流程使用者支付完成後會返回至發起支付的頁面，如需返回至指定頁...
微信支付之pc端掃碼支付
看文件是最簡單暴力的方式，千萬不要去看一些文章寫得真的是。好像我也是寫文章的 嗯 基本流程 首頁頁面引入 步驟1 var obj new wxlogin 然後就沒有然後了，就是這麼簡單。這裡的 引數 主要看一下文件非常詳細。有些同學可能就有些疑問了？文件上明明寫著 為什麼我沒有去去做呢？這個就要從安...