前言
本文基于anhkgg大佬的文章《微信PC端技術研究(2)-拿下語音》原文鏈接：
https://bbs.pediy.com/thread-249274.htm
anhkgg大佬的這篇文章找到了保存語音消息的接口，這里直接給出相關特征碼，方便定位(我使用的微信版本依舊是2.6.8.52)
偏移為0x30E326，下面的特征碼
基于保存語音的相關延伸
其實這個地方不單單有語音消息，還有圖片消息，當我們發送一條圖片消息時
[edi+0x30]的內容里面保存有這一次發送圖片的相關數據，包括微信ID等一系列原始的數據。我們當然可以在這個地方寫HOOK來保存圖片，但是沒有必要。因為這里的消息內容過多，處理起來相對會比較麻煩。
圖片處理的相關流程
既然這個地方是最原始的消息內容，那么后面肯定會對消息進行相關處理。而且我們已經知道微信的接收的圖片會用異或加密的方式保存到本地。那么我們不妨猜測一下圖片相關的處理流程。
首先接收到原始的消息后，會對消息進行一系列的處理，其中就包括判斷消息是否是圖片。那么如果是圖片則會取出圖片數據，然后在內存中對圖片進行加密。加密完成之后調用文件操作的API，寫入加密后的圖片到本地。
整個過程如圖所示：
自動保存圖片相關思路
既然了解圖片處理的流程，而且已經有了接收圖片消息的call，那么我們就可以在接收到圖片消息之后，在CreateFileW創建圖片之前，找到對圖片進行加密的算法和函數，將未加密前的圖片保存出來。
實戰保存聊天圖片
在OD中找到保存語音的call，發送圖片消息讓程序斷下的同時，對CreateFileW進行下斷。之后F9運行
此時文件路徑為xlog，這個明顯不符合我們的要求，繼續F9運行
一直找到圖片路徑帶有Image關鍵字時，在創建圖片
此時我們點擊K顯示堆棧，找到第一層返回地址，右鍵顯示調用
當微信運行到這里的時候，圖片加密已經完成，我們要在這個函數之前找到圖片的加密算法，其實就在上面一點點的位置，鼠標稍微往上翻一下就能看到
找到這個地方之后清除剩下的所有的斷點，只保留這一個
對保存圖片call的相關分析
再次發送一張圖片，程序斷下。這段代碼首先用循環的方式對圖片進行加密，循環的次數即ecx的值，也就是圖片的大小。其中有兩個數據比較重要。
我們先在內存中查看[ebp-0x14]的內容，想要知道這段數據是什么其實很簡單。先下CreateFileW斷點
當CreateFileW斷點斷下后，執行到返回，查看打開的文件句柄
此時打開的圖片句柄為0xF80，此時再下WriteFile斷點
WriteFile斷下后可以看到句柄為F80，寫入的緩沖區地址為39FE820，而[ebp-0x14]的地址正好也是39FE820。也就是說[ebp-0x14]這個位置保存的是加密后的圖片數據
回到之前的斷點，再次發送一張圖片，查看[ebp-0x4]的數據
此時[ebp-0x4]中保存了接收的圖片，而ecx保存了圖片的大小
這里借用PCHunter查看->進程內存，將這一段數據dump下來
問題就在于這里只是一張大小為4KB的縮略圖，回到OD，再次按F9運行
斷點斷下，但是此時ecx的值變成0x5A140
用同樣的方法dump下內存，大小為360KB，這個就是我們需要的原圖了。
也就是說這個地方會端下來兩次，第一次是縮略圖，第二次才是我們要的原圖。
代碼實現保存聊天圖片
示例代碼如下：
實際效果
原文鏈接：
https://blog.csdn.net/qq_38474570/article/details/101755586
