『壹』 網路游戲數據編程修改
SELECT GAME選擇目前在記憶體中您想攔截的程式，您只需雙擊該程式名稱即可。
TRACE追蹤功能。用來追蹤擷取程式送收的封包。WPE必須先完成點選欲追蹤的程式名稱，才可以使用此項目。 按下Play鍵開始擷取程式收送的封包。您可以隨時按下 | | 暫停追蹤，想繼續時請再按下 | | 。按下正方形可以停止擷取封包並且顯示所有已擷取封包內容。若您沒按下正方形停止鍵，追蹤的動作將依照OPTION里的設定值自動停止。如果您沒有擷取到資料，試試將OPTION里調整為Winsock Version 2。WPE 及 Trainers 是設定在顯示至少16 bits 顏色下才可執行。
FILTER過濾功能。用來分析所擷取到的封包，並且予以修改。
SEND PACKET送出封包功能。能夠讓您送出假造的封包。
TRAINER MAKER製作修改器。
OPTIONS設定功能。讓您調整WPE的一些設定值。
FILTER的詳細教學
- 當FILTER在啟動狀態時 ，ON的按鈕會呈現紅色。- 當您啟動FILTER時，您隨時可以關閉這個視窗。FILTER將會保留在原來的狀態，直到您再按一次 on / off 鈕。- 只有FILTER啟用鈕在OFF的狀態下，才可以勾選Filter前的方框來編輯修改。- 當您想編輯某個Filter，只要雙擊該Filter的名字即可。
NORMAL MODE：
範例：
當您在 Street Fighter Online ﹝快打旋風線上版﹞游戲中，您使用了兩次火球而且擊中了對方，這時您會擷取到以下的封包：SEND-> 0000 08 14 21 06 01 04 SEND-> 0000 02 09 87 00 67 FF A4 AA 11 22 00 00 00 00 SEND-> 0000 03 84 11 09 11 09 SEND-> 0000 0A 09 C1 10 00 00 FF 52 44 SEND-> 0000 0A 09 C1 10 00 00 66 52 44
您的第一個火球讓對方減了16滴﹝16 = 10h﹞的生命值，而您觀察到第4跟第5個封包的位置4有10h的值出現，應該就是這里了。
您觀察10h前的0A 09 C1在兩個封包中都沒改變，可見得這3個數值是發出火球的關鍵。
因此您將0A 09 C1 10填在搜尋列﹝SEARCH﹞，然後在修改列﹝MODIFY﹞的位置4填上FF。如此一來，當您再度發出火球時，FF會取代之前的10，也就是攻擊力為255的火球了！
ADVANCED MODE：
範例： 當您在一個游戲中，您不想要用真實姓名，您想用修改過的假名傳送給對方。在您使用TRACE後，您會發現有些封包裡面有您的名字出現。假設您的名字是Shadow，換算成16進位則是﹝53 68 61 64 6F 77﹞；而您打算用moon﹝6D 6F 6F 6E 20 20﹞來取代他。1) SEND-> 0000 08 14 21 06 01 042) SEND-> 0000 01 06 99 53 68 61 64 6F 77 00 01 05 3) SEND-> 0000 03 84 11 09 11 094) SEND-> 0000 0A 09 C1 10 00 53 68 61 64 6F 77 00 11 5) SEND-> 0000 0A 09 C1 10 00 00 66 52 44
但是您仔細看，您的名字在每個封包中並不是出現在相同的位置上
- 在第2個封包里，名字是出現在第4個位置上- 在第4個封包里，名字是出現在第6個位置上
在這種情況下，您就需要使用ADVANCED MODE- 您在搜尋列﹝SEARCH﹞填上：53 68 61 64 6F 77 ﹝請務必從位置1開始填﹞- 您想要從原來名字Shadow的第一個字母開始置換新名字，因此您要選擇從數值被發現的位置開始替代連續數值﹝from the position of the chain found﹞。- 現在，在修改列﹝MODIFY﹞000的位置填上：6D 6F 6F 6E 20 20 ﹝此為相對應位置，也就是從原來搜尋欄的+001位置開始遞換﹞- 如果您想從封包的第一個位置就修改數值，請選擇﹝from the beginning of the packet﹞
了解一點TCP/IP協議常識的人都知道，互聯網是將信息數據打包之後再傳送出去的。每個數據包分為頭部信息和數據信息兩部分。頭部信息包括數據包的發送地址和到達地址等。數據信息包括我們在游戲中相關操作的各項信息。那麼在做截獲封包的過程之前我們先要知道游戲伺服器的IP地址和埠號等各種信息，實際上最簡單的是看看我們游戲目錄下，是否有一個SERVER.INI的配置文件，這個文件里你可以查看到個游戲伺服器的IP地址，比如金庸群俠傳就是如此，那麼除了這個我們還可以在DOS下使用NETSTAT這個命令，
NETSTAT命令的功能是顯示網路連接、路由表和網路介面信息，可以讓用戶得知目前都有哪些網路連接正在運作。或者你可以使用木馬客星等工具來查看網路連接。工具是很多的，看你喜歡用哪一種了。
NETSTAT命令的一般格式為：NETSTAT [選項]
命令中各選項的含義如下：-a 顯示所有socket，包括正在監聽的。-c 每隔1秒就重新顯示一遍，直到用戶中斷它。-i 顯示所有網路介面的信息。-n 以網路IP地址代替名稱，顯示出網路連接情形。-r 顯示核心路由表，格式同"route -e"。-t 顯示TCP協議的連接情況。-u 顯示UDP協議的連接情況。-v 顯示正在進行的工作。
--------------------------------------------------------------------------------
三：怎麼來分析我們截獲的封包？
首先我們將WPE截獲的封包保存為文本文件，然後打開它，這時會看到如下的數據（這里我們以金庸群俠傳里PK店小二客戶端發送的數據為例來講解）：
第一個文件：SEND-> 0000 E6 56 0D 22 7E 6B E4 17 13 13 12 13 12 13 67 1BSEND-> 0010 17 12 DD 34 12 12 12 12 17 12 0E 12 12 12 9BSEND-> 0000 E6 56 1E F1 29 06 17 12 3B 0E 17 1ASEND-> 0000 E6 56 1B C0 68 12 12 12 5ASEND-> 0000 E6 56 02 C8 13 C9 7E 6B E4 17 10 35 27 13 12 12SEND-> 0000 E6 56 17 C9 12
第二個文件：SEND-> 0000 83 33 68 47 1B 0E 81 72 76 76 77 76 77 76 02 7ESEND-> 0010 72 77 07 1C 77 77 77 77 72 77 72 77 77 77 6DSEND-> 0000 83 33 7B 94 4C 63 72 77 5E 6B 72 F3SEND-> 0000 83 33 7E A5 21 77 77 77 3FSEND-> 0000 83 33 67 AD 76 CF 1B 0E 81 72 75 50 42 76 77 77SEND-> 0000 83 33 72 AC 77
我們發現兩次PK店小二的數據格式一樣，但是內容卻不相同，我們是PK的同一個NPC，為什麼會不同呢？ 原來金庸群俠傳的封包是經過了加密運算才在網路上傳輸的，那麼我們面臨的問題就是如何將密文解密成明文再分析了。
因為一般的數據包加密都是異或運算，所以這里先講一下什麼是異或。 簡單的說，異或就是"相同為0，不同為1"（這是針對二進制按位來講的），舉個例子，0001和0010異或，我們按位對比，得到異或結果是0011，計算的方法是：0001的第4位為0，0010的第4位為0，它們相同，則異或結果的第4位按照"相同為0，不同為1"的原則得到0，0001的第3位為0，0010的第3位為0，則異或結果的第3位得到0，0001的第2位為0，0010的第2位為1，則異或結果的第2位得到1，0001的第1位為1，0010的第1位為0，則異或結果的第1位得到1，組合起來就是0011。異或運算今後會遇到很多，大家可以先熟悉熟悉，熟練了對分析很有幫助的。
下面我們繼續看看上面的兩個文件，按照常理，數據包的數據不會全部都有值的，游戲開發時會預留一些位元組空間來便於日後的擴充，也就是說數據包里會存在一些"00"的位元組，觀察上面的文件，我們會發現文件一里很多"12"，文件二里很多"77"，那麼這是不是代表我們說的"00"呢？推理到這里，我們就開始行動吧！
我們把文件一與"12"異或，文件二與"77"異或，當然用手算很費事，我們使用"M2M 1.0 加密封包分析工具"來計算就方便多了。得到下面的結果：
第一個文件：1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 892 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 083 SEND-> 0000 F4 44 09 D2 7A 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 005 SEND-> 0000 F4 44 05 DB 00
第二個文件：1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 70 6B 00 00 00 00 05 00 05 00 00 00 1A2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 843 SEND-> 0000 F4 44 09 D2 56 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 B8 6C 79 F6 05 02 27 35 01 00 005 SEND-> 0000 F4 44 05 DB 00
哈，這一下兩個文件大部分都一樣啦，說明我們的推理是正確的，上面就是我們需要的明文！
接下來就是搞清楚一些關鍵的位元組所代表的含義，這就需要截獲大量的數據來分析。
首先我們會發現每個數據包都是"F4 44"開頭，第3個位元組是變化的，但是變化很有規律。我們來看看各個包的長度，發現什麼沒有？對了，第3個位元組就是包的長度！ 通過截獲大量的數據包，我們判斷第4個位元組代表指令，也就是說客戶端告訴伺服器進行的是什麼操作。例如向伺服器請求戰斗指令為"30"，戰斗中移動指令為"D4"等。 接下來，我們就需要分析一下上面第一個包"F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 89"，在這個包里包含什麼信息呢？應該有通知伺服器你PK的哪個NPC吧，我們就先來找找這個店小二的代碼在什麼地方。 我們再PK一個小嘍羅（就是大理客棧外的那個咯）：SEND-> 0000 F4 44 1F 30 D4 75 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 8A 19 00 00 00 00 11 00 02 00 00 00 C0 我們根據常理分析，游戲里的NPC種類雖然不會超過65535（FFFF），但開發時不會把自己限制在字的范圍，那樣不利於游戲的擴充，所以我們在雙字里看看。通過"店小二"和"小嘍羅"兩個包的對比，我們把目標放在"6C 79 F6 05"和"CF 26 00 00"上。（對比一下很容易的，但你不能太遲鈍咯，呵呵）我們再看看後面的包，在後面的包里應該還會出現NPC的代碼，比如移動的包，游戲允許觀戰，伺服器必然需要知道NPC的移動坐標，再廣播給觀戰的其他玩家。在後面第4個包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"里我們又看到了"6C 79 F6 05"，初步斷定店小二的代碼就是它了！（這分析里邊包含了很多工作的，大家可以用WPE截下數據來自己分析分析）
第一個包的分析暫時就到這里（裡面還有的信息我們暫時不需要完全清楚了）
我們看看第4個包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"，再截獲PK黃狗的包，（狗會出來2隻哦）看看包的格式：SEND-> 0000 F4 44 1A DA 02 0B 4B 7D F6 05 02 27 35 01 00 00SEND-> 0010 EB 03 F8 05 02 27 36 01 00 00
根據上面的分析，黃狗的代碼為"4B 7D F6 05"（100040011），不過兩只黃狗伺服器怎樣分辨呢？看看"EB 03 F8 05"（100140011），是上一個代碼加上100000，呵呵，這樣伺服器就可以認出兩只黃狗了。我們再通過野外遇敵截獲的數據包來證實，果然如此。
那麼，這個包的格式應該比較清楚了：第3個位元組為包的長度，"DA"為指令，第5個位元組為NPC個數，從第7個位元組開始的10個位元組代表一個NPC的信息，多一個NPC就多10個位元組來表示。
大家如果玩過網金，必然知道隨機遇敵有時會出現增援，我們就利用游戲這個增援來讓每次戰斗都會出現增援的NPC吧。
通過在戰斗中出現增援截獲的數據包，我們會發現伺服器端發送了這樣一個包：F4 44 12 E9 EB 03 F8 05 02 00 00 03 00 00 00 00 00 00 第5-第8個位元組為增援NPC的代碼（這里我們就簡單的以黃狗的代碼來舉例）。 那麼，我們就利用單機代理技術來同時欺騙客戶端和伺服器吧！
好了，呼叫NPC的工作到這里算是完成了一小半，接下來的事情，怎樣修改封包和發送封包，我們下節繼續講解吧。
--------------------------------------------------------------------------------
四：怎麼冒充"客戶端"向"伺服器"發我們需要的封包？
這里我們需要使用一個工具，它位於客戶端和伺服器端之間，它的工作就是進行數據包的接收和轉發，這個工具我們稱為代理。如果代理的工作單純就是接收和轉發的話，這就毫無意義了，但是請注意：所有的數據包都要通過它來傳輸，這里的意義就重大了。我們可以分析接收到的數據包，或者直接轉發，或者修改後轉發，或者壓住不轉發，甚至偽造我們需要的封包來發送。
下面我們繼續講怎樣來同時欺騙伺服器和客戶端，也就是修改封包和偽造封包。 通過我們上節的分析，我們已經知道了打多個NPC的封包格式，那麼我們就動手吧！
首先我們要查找客戶端發送的包，找到戰斗的特徵，就是請求戰斗的第1個包，我們找"F4 44 1F 30"這個特徵，這是不會改變的，當然是要解密後來查找哦。 找到後，表示客戶端在向伺服器請求戰斗，我們不動這個包，轉發。 繼續向下查找，這時需要查找的特徵碼不太好辦，我們先查找"DA"，這是客戶端發送NPC信息的數據包的指令，那麼可能其他包也有"DA"，沒關系，我們看前3個位元組有沒有"F4 44"就行了。找到後，我們的工作就開始了！
我們確定要打的NPC數量。這個數量不能很大，原因在於網金的封包長度用一個位元組表示，那麼一個包可以有255個位元組，我們上面分析過，增加一個NPC要增加10個位元組，所以大家算算就知道，打20個NPC比較合適。
然後我們要把客戶端原來的NPC代碼分析計算出來，因為增加的NPC代碼要加上100000哦。再把我們增加的NPC代碼計算出來，並且組合成新的封包，注意代表包長度的位元組要修改啊，然後轉發到伺服器，這一步在編寫程序的時候要注意演算法，不要造成較大延遲。
上面我們欺騙伺服器端完成了，欺騙客戶端就簡單了，^-^
發送了上面的封包後，我們根據新增NPC代碼構造封包馬上發給客戶端，格式就是"F4 44 12 E9 NPC代碼 02 00 00 03 00 00 00 00 00 00",把每個新增的NPC都構造這樣一個包，按順序連在一起發送給客戶端，客戶端也就被我們騙過了，很簡單吧。
以後戰斗中其他的事我們就不管了，盡情地開打吧，呵呵。 本欄文章均來自於互聯網，版權歸原作者和各發布網站所有，本站收集這些文章僅供學習參考之用。任何人都不能將這些文章用於商業或者其他目的。( ProgramFan.Com )
『貳』 在EXCEL同一工作表中,如何實現在不同sheet中數據快速追蹤
使用超鏈接呀
在sheet1中單元格中輸入關鍵字，然後右鍵「超鏈接」，在鏈接到下面點擊「文檔中的位置」；然後選擇要鏈接的工作表中的單元格
『叄』 App頁面上的數據如何追蹤和統計的現成的工具有哪些
1. Android 渠道追蹤方法
眾所周知 Google Play 無法在中國使用，所以國內 Android 市場被數十家應用商店（ 豌豆莢、網路助手、酷市場、360手機助手等等 ）佔領，Android 渠道追蹤主要圍繞上述渠道展開。
方法 1：每個渠道打渠道包
具體來說就是開發者為每一個渠道生成一個渠道安裝包，不同渠道包用不同的 Channel ID （渠道標識）來標識；當用戶下載了 App 之後，運營人員就可以通過渠道標識查看各個渠道的數據。
Android 渠道打包機制：
雖然這樣可以統計到不同渠道的來源數據，但是當渠道數量變多、抑或同一渠道在多個平台上做推廣的話，打渠道包的做法就捉襟見肘了。
方法 2：使用平台方提供的數據
部分第三方推廣平台提供渠道數據，然而只依賴平台方的「一面之詞」是很難找到真正的優質渠道。
2. iOS 渠道追蹤方法
和 Android 的開放生態不一樣，iOS 則是一個完全封閉的系統；除了少部分越獄機器，絕大部分 App 都是從 App Store 中下載。在蘋果一家獨大以及嚴格的審核制度下，Android 打包的做法在這里就完全行不通。
為了追蹤 iOS 渠道數據，開發者們想出了很多黑科技，下面我介紹一下常見的三種做法。
方法 1：通過 IDFA 追蹤渠道
IDFA 的全稱是 Identifier for Advertisers ，即廣告標識符的含義，這是蘋果專門給各廣告提供商用來追蹤用戶而設的標識。
通過 IDFA 追蹤渠道：
今日頭條作為廣告提供商可以獲取用戶的 IDFA，當你在上面投放的 App 被用戶下載激活，你的 App 也可以獲取用戶的 IDFA。將廣告提供商提供的 IDFA 和自己獲取的 IDFA 匹配，即可追蹤渠道來源。
缺點是 IDFA 只能用於 App 類型的渠道，如果你在網頁上投放廣告是不支持的；同時，用戶可以在iPhone 設置中選擇關掉 IDFA 獲取許可權。
方法 2：通過 Cookie 追蹤渠道
iOS 9 裡面引入了 SFSafariViewController 類，一方面是用戶體驗更好了，同時可跨 App 與 Safari 共享 Cookie。
通過 Cookie 追蹤渠道：
當用戶點擊廣告鏈接時，監控伺服器可以接收到 Cookie 中含有的渠道信息；用戶在 App Store 中下載激活 App，這個時候監控伺服器再次收到 Cookie 信息。系統匹配前後兩次 Cookie ，即可追蹤渠道。
缺點是基於SFSafariViewController 的追蹤必須在 iOS 9 及以上版本才有效，而且微信公眾號廣告、朋友圈廣告仍然無法實現追蹤。
上述方法可以實現部分平台、部分渠道的追蹤監測，然而三大缺點也是顯而易見：
（1）割裂了 Android 和 iOS 兩個平台的渠道數據，難以整合分析；
（2）Android 投放需要重復打包，效率低下；
（3）iOS 渠道範圍限制多，無法大規模推廣。
Part 2 | 基於用戶設備標記的解決方案
下面我們介紹一種快速、靈活的解決方案 ––– 基於用戶設備標識的追蹤方法，它可以同時兼容 Android 和 iOS 兩個平台、適用於大部分投放渠道。
1. 基於用戶設備標記的追蹤原理
上面介紹的基於 IDFA 和 SFSafariViewController 的兩種方法均受到 iOS 的限制，而用戶的設備標記則不受系統的影響。在 GrowingIO【渠道來源】解決方案中，我們將「IP + UserAgent + 設備 ID」組合設置為用戶的設備標記。
通過用戶設備標記追蹤渠道：
用戶點擊含有 UTM 追蹤參數的廣告鏈接後，GrowingIO 伺服器檢測到用戶的設備標記以及 UTM 渠道參數。鏈接跳轉到應用商店（ Android 和 iOS 均可以）後，用戶下載安裝並激活 App，此時 GrowingIO 伺服器第二次收到用戶的設備標記。
系統匹配前後兩次的標記，可以確定用戶的渠道來源，同時 UTM 參數含有的詳細渠道信息一並呈現。
2. 用戶設備標記方法的特點
當然，基於用戶設備標記的方法也有一定不足。當小部分用戶所處的網路環境前後變化時（如從 WiFi 切換到 4G），此時 IP 前後不一致就會導致匹配失敗。
但是相比於前面的 4 種方法，基於用戶設備標記的渠道追蹤方法顯然更有優勢：
第一點，打通了 iOS 和 Android 的渠道來源，可以將【操作系統】加入用戶屬性整合分析；
第二點：避免了 Android 平台重復打渠道包的工作；
第三點：規避了 iOS 原有諸多限制，適用於更加廣泛的推廣渠道；
第四點：只需修改推廣鏈接中的參數、無需改動安裝包，適合大規模、多渠道、敏捷的推廣需求。
同時，廣告鏈接中含有的渠道參數（ 廣告來源、廣告媒介、廣告名稱、廣告內容、廣告關鍵字 ）可以一同加入用戶屬性數據中，方便後期對用戶數據進行多維度的對比、交叉分析。
Part 3 | App 渠道數據分析兩大思路
有了 App 渠道追蹤數據後，我們可以將 UTM 的五個參數作為維度，從數量和質量兩個思路出發，進行 App 渠道數據分析。
1. 數量：找到獲客成本最低的渠道
根據業務需要，我們選取廣告來源（ utm_source ）和廣告關鍵詞 ( utm_term ) 兩個維度，計算出不同渠道的獲客數量並評估獲客成本。
某 O2O 類 App 先後在 3 個渠道上進行了 2 次投放，投放內容先後是「美食」和「外賣」。通過 UTM，我們監測到每個渠道、每次投放的 「App 新增用戶量」，然後計算出平均獲客成本。
從廣告來源上看，渠道 1 的平均獲客成本最低；從廣告關鍵詞上看，「外賣」主題的廣告平均獲客成本最低。從客單價的角度出發，接下來可以針對性優化投放渠道和投放內容，大幅度降低投放成本、提高拉新效率。
2. 質量：找到獲客價值最高的渠道
「App 新增激活用戶量」和「獲客成本」這兩個指標是從數量的角度進行分析，但是數量大、價格低並不一定代表渠道用戶質量高。我們還需綜合考慮用新用戶在接下來的表現，以及新用戶所能帶來的價值。
方法 1：用戶行為數據分析
在這個過程中，我們重點參考用戶留存指標，包括次日留存率、三日留存率、七日留存率、三十日留存率等等。
我們按訪問來源（utm_source）分析新用戶的留存度，發現渠道 2 的三十日留存率高達 14%，而渠道 1 為 8%、渠道 3 為 6%。從留存度上來看，渠道 2 獲取的新用戶價值顯著更高。
方法2：用戶價值分析
除了用戶行為指標，財務指標也非常具有參考性。按照廣告來源（utm_source）我們統計出不同渠道獲取到的新用戶的財務價值，如新用戶在第一個月的月付費率（MPR）和用戶平均收益（ARPU）。
通過分析發現，渠道 2 獲取的新用戶首月付費率（42%）最高，用戶平均收益（30 元）也是最高的。雖然渠道 2 的獲客成本略高於渠道 1，但是從收益的角度來說，投資渠道 2 顯然是一種更加明智的選擇。
綜合上述指標，該 O2O 類 App 在下個月的市場投放中將資源集中到了渠道 2，同時主打「外賣」主題內容。還是和上個月同樣的市場預算，但是新增用戶卻提高了 150%、新用戶留存率提升了 240%，這是一個巨大的增長。