分析群拉人功能的思路
首先思考一下群拉人功能背後的編程邏輯，第一步需要將一組聯繫人放到一個數組裡，然後拿到這一批人的微信ID，接著對這一批人發送一個群邀請。那麼我們就可以從聯繫人的微信ID入手，只要找到了那組微信ID，那麼就能下內存訪問斷點，進而找到群拉人的call
定位群拉人call
定位聯繫人的微信ID
首先在不選中聯繫人的情況下搜索微信ID
接著選中所有的地址，添加到下方地址欄
接著複製所有的內容，將其放到在線文本對比工具的A部分中
接著選中要添加的聯繫人，然後再次搜索微信ID，此時搜索的數量增加。因為當你選中聯繫人的時候，微信肯定要把這個選擇的聯繫人的ID放到已選聯繫人的數組裡。
接著同樣將這批地址放到文本對比工具的B部分中。接著我們需要找到點擊前沒有的地址，點擊後有的地址。也就是找到B有A沒有的地址。
接著我們在B部分裡找到了四個A部分沒有的地址，那麼問題在於怎麼篩選出唯一的一個地址呢？根據我們以往的經驗我們知道，存放微信ID的數據格式一般如下：
那麼我們可以大膽猜測，存放這個選中聯繫人的微信ID的地址的數據格式也是和之前的一樣。接著我們在OD中去查看這四個地址的數據格式，看是否和上述的數據格式一致
首先在CE中搜索選中的地址是否有上一級指針，如果沒有 直接pass這個地址
接著在OD中查看上一級指針的內容，發現這個數據結構比較符合我們的要求
再次查看另外一個地址，發現這個正好是我們預期的數據結構，完全符合
經過篩選我們發現三個地址都符合我們要的特徵
定位群拉人call
必須要執行的call
既然如此我們只能先挑一個最大的地址來碰運氣了，在這個地址中下內存訪問斷點(這一步需要經過多次排查)
點擊確定，讓程序斷下，
此時程序斷下，刪除訪問斷點，開始排查堆棧
在堆棧中我們發現了一個call，傳入了被邀請人的微信ID，那麼這個call就非常像我們找的邀請群成員的call，我們在這下個斷點，邀請好友讓程序再次斷下
如果想要驗證這個call是否是關鍵call，那麼可以修改微信ID，看看是否會將修改後的好友加進群。經過測試如果直接跳過這個call，那麼微信會直接崩潰，因為這個是組裝數據的必要的一個call。
但是我們發現這個地方只有被邀請人的微信ID，並沒有邀請的群ID，那麼我們需要繼續往後跟，很有可能這也是一個連續的call
可以不執行的call
從找到的call一直往後F8單步，接著我們在這個地方找到了一個call，傳入了一個群ID，那麼有沒有可能只要調用這兩個call就能完成邀請的動作了呢？我們來驗證一下
讓程序再次斷下，然後將這個je修改為jmp，跳過這個call，跳過之後好友還是被拉進群了，那麼說明這個call是一個沒有用的call。我們還要繼續往下找，找到傳入了群ID的那個call
必須要執行的call
當我們F8步過這個all的時候，發現將群ID寫入到了堆棧，說明這個call可能是我們需要的call，繼續往下單步
發現這裡有一個call將一個結構體壓入堆棧，這個結構體我們已經很眼熟，見過很多次了
數據窗口跟隨，發現裡面保存的就是微信ID，那麼這個call就很有可能是我們需要的邀請人進群的call了
當我們跳過這個call時，發現此時微信崩潰，也就是說這個call也是一定要執行的一個關鍵call
追蹤數據結構的來源
現在我們已經知道了哪些是必須要調用的call，現在我們需要拿到esi數據結構的來源
一直往上追溯，我們發現esi在這個地方被賦值，所以我們在這個call下斷點，讓程序斷下
程序斷下，查看esi的值，我們發現此時esi已經是我們需要追溯的結構體，所以我們還需要繼續往上找
繼續往上翻我們並沒呀找到任何給esi賦值的地方，所以我們猜測有可能是這個call傳入了一個微信ID，然後組裝數據結構，所以我們在這個call下斷點
斷點斷下，此時esi的緩存區為空，F8步過這個call
此時緩衝區內正是我們需要的數據，也就是說這個call是用於組裝數據的必須的call
另外 在這個地址還有一個往堆棧中寫入群號的call，這個call也是要調用的
現在我們只需要調用我們找到的前面三個call，就能夠完成拉人的功能，但是微信會崩潰
經過排查我們發現這個call，也是一個必須要調用的call，如果不調用的話 微信會直接崩潰
總結
想要寫代碼完成群拉人的功能，分為三個步驟。
第一步，調用下面的call，組裝數據
第二步，調用下面的call，防止微信崩潰
第三步，調用下面的call往堆棧中寫入群號
第四步，調用拉人的call
