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