Galgame封包逆向入门

这里就简单聊一下封包逆向分析的一些注意点吧，其实也是初入逆向的注意点了，本质差不多。

正向基础

• 语言基础：ASM、C、C++
• 平台基础：Win32、PE、GDI、DirectX
• 引擎基础：游戏引擎架构

虽然说的逆向，其实和正向的水平、见识、经验是强相关的，如果你没写过相关的程序又怎么谈逆向？怎么入手呢？显然是无从下手的。

所以这个ASM、C、C++的基础还是要多去补补，多去看看，会写不算啥，懂得每一行代码写下去的效果和背后的原理才有用，这边很经典的就是把写C、C++的代码然后切到汇编去看看大概啥样子，汇编也不是说要求你要用来写程序，至少是能看懂和知道一些常见汇编指令的用处，还有栈帧，函数调用约定这些也是基础中的基础了。

当然上面只是谈论了语言方面的基础，还有平台相关的，一般Galgame都是Windows平台的，所以Win32编程也是必修课，PE结构也是必须会的，接下来就是游戏使用的图形API，比如GDI，DirectX这些也是需要了解的，至少自己用过这些，不然很难去谈逆向这块的事，但是图形API和封包逆向没有太多关系就是了。

上述知识算是基础中的基础了，必须是要扎实的，接下来就是架构上的思维了，你至少也得大概有个模糊的印象，一个游戏引擎是如何工作的，如果你不知道，那又要从什么地方去入手？显然也是无从入手，所以有能力的可以去看看一些开源的游戏引擎，看看人家大概是怎么写的，有怎么样的架构在里面，这样逆向的时候才知道人家写这些代码到底是为了什么，更有助于理清楚游戏整体架构，这样逆起来就比较轻松，不然看着一堆函数调用只能干瞪眼。

把握心态

• 少见多怪、世事难料、稍安勿躁
• 多调试，多跟踪，多喝水，多放松
• 逆出来，不一定是水平多高，也许只是碰巧
• 逆不出来，喝口水保存好文件，待有思路再战

还是想在开头强调一下心态部分，逆向毕竟是逆天改命的事，道路坎坷自不必多说。

遇到实在没有头绪的，可以适当放下，不要死磕到底，现在没有思路，说明水平和经验没到位，可以先留着，等日后见识和水平提高了，再来分析。

逆向本质上就是把代码抄出来罢了，甚至都不需要你设计或写出来，单纯的抄而已。

但这和你的见识有很大关系，本质上就是经验主义。

逆不出来，说明正向开发上没有经验或平时练的太少，没有去关心底层的实现细节。

当然有时候其实啥也不会，瞎捣鼓也能破解一些软件，这也和一些经验，套路密不可分，但其实我觉得这基本算是运气的因素，不过我们也不能总是靠运气，这显然是行不通的，但有些时候运气确实也是一个关键因素。

反正这就是一门需要心细、耐心的活。

封包结构

• 运气问题：能猜先猜，不能再逆

• 拿来即用：学会在网上搜索现成资料

• 温故知新：自己对着已有结构重新分析

• 灵活运用：切记结构变化多样要灵活不死板

如果要逆向游戏的封包，那必然得了解常见的封包结构，因为正常人，如果设计一个封包，大概率就是往这些常见的封包结构上靠拢的，也可以称之为一种模式，或者说大概的特征。

反正大家用的电脑都是差不多架构的，写的程序也是差不多结构的，自然决定了写出来的封包大概率相似。

那也不是说没有与众不同的，只能说这是少数，所以这里也就要求大家逆向的时候一定要保持灵活，不要生搬硬套自己脑子里的经验结构。

那么这些常见的结构去哪看呢？

其实GitHub就有不少解包项目，可以去看看他们的源码，不过有些并没有直接把封包的文件结构写在代码里，而放在了具体读取封包数据的地方，我其实并不是喜欢这种，你得看它读取封包数据才能在脑子里构建结构，我一般都会把结构写成一个结构体放在代码里，让别人能看明白。

不过也没办法，反正人家是这样写了，作为一个初学者，本就没什么资料，也只能将就了。

还有个就是之前推荐的书《揭秘数据解密的关键技术》里面也有讲一些封包的结构可以去看看。

如果有源码，一定要跑起来，自己单步去调试，去理解里面每一行代码的意义，把源码看得差不多了，就要找对应封包的游戏来自己对着逆一下，练习分析的过程和总结自己的难点，后面再去想办法突破和补充自己缺的部分。

加密算法

• 普通加密多种多样不便总结

• Run Length Encoding（RLE）

• LZSS、LZ77、LZXX系列的变种

• Huffman、ZSTD、ZLIB

本来这里想写压缩算法的，但还是写了“加密算法”，因为压缩本质上也会改变原来的数据，我这就姑且也认为是一种加密了。

了解结构，我们就可以解析出封包里的资源文件数据了，但是这通常伴随着，资源文件数据被加密（以后加密也代指压缩），那么我们也就必须逆向相关的解密算法才能得到真正的数据，当然有些时候整个封包都被加密了，这时候连结构也没办法分析，也就只能先解密才能分析了。

加密算法多种多样，也没有一种固定的模式，有单纯xor的，有用一张表来解密的，有用密钥生成表再用表来解密的，还有在这些基础上各种嵌套的，反正多种多样。

不过论他们的本质，也就是对数据的字节、位，进行一定的运算，所以这通常伴随着循环，说白了，如果你看到一堆循环运算的玩意，大概率和解密有关，因为他要循环读取数据嘛，不然怎么解密呢？但还是要说切勿死板模式化，因为有些游戏是可以依据具体的格式比如PNG，按照PNG的chunk一点点解密的。

现在你可能会觉得，啊，这也太难了吧！

但由于游戏自身也需要解包得到资源文件，那么游戏执行文件就带有解密的算法，所以这一部分还是比较简单的，我们只需要跟踪具体数据的读取流程，就基本能跟踪到解密算法的位置。这里的跟踪也就是我们对文件读取相关的API下断点，然后在读取数据的缓冲区下硬件断点。

如果我们需要封包回去，那就会涉及到在理解已有解密算法的基础上，构建加密算法，让游戏的解密算法正确解密数据，这里面其实有几种方向。

• 直接hook掉游戏解密算法部分，让它直接跳过，这样就可以不用构建加密算法了，当然这就要求我们去改游戏程序了。
• 构建假的加密算法，也就是我们利用解密算法里的一些特征来跳过真正的解密部分，比如LZSS解密部分，我们可以直接把标志位都设为不压缩，来达到不写压缩算法也可以让游戏正常读取的目的。
• 直接写出完整的加密算法。
• 看看游戏里是否也带有相关的加密算法，比如CMVS的LZSS算法，它的解压函数和压缩函数都在游戏里有可以直接扣。

正常的加密算法就不好说了，但是压缩算法可以说说，有些游戏也会对压缩后的数据套一层加密，或者套一层加密再压缩。

常见的大概就有这么几种（开头说的），当然，实际上会用的，也不一定就是这些，也有可能是一些魔改的（因为很多都是开源算法可以随便改），但本质上都会和这些类似，所以了解这些常见的压缩算法，有助于我们逆向游戏里那些私有的算法。

常见文件结构

• BMP、PNG、JPG、WEBP
• OGG，WAV，MP3
• 当然还是一些其它的，了解越多越好，比如ZLIB压缩的数据文件头也有一定特征

熟悉常见的资源文件的结构是非常重要的。

• 比如熟悉常见资源文件的文件头，我们就可以很快的对一个封包是否加密做出判断。

• 如果你熟悉PNG的结构，可以在封包里搜索PNG的头和尾标志，来直接初步分析这个封包是否加密，或封包的结构，甚至可以直接把文件提取出来，在逆向过程中，也可以快速判断内存中的数据。

• 有些游戏会判断资源文件的文件头，这也是一个突破点，可以找到资源的Buffer，或支持多少格式。

• 看到游戏使用libpng的库，这也是一个突破，可以用来跟踪游戏的图片读取，或者资源读取。(所以就是说，要了解一些游戏开发常用的开源库)

• 游戏内私有的图片格式，可能很大程度就是BMP，PNG，JPG那些魔改而来的。

• 当然还有很多好处，这里就不展开了。

所以熟练常见的文件结构，还是非常重要的，会给我们在逆向中带来很多帮助和便利。

反正，至少也得熟悉一下文件头吧，方便从二进制数据直接判断是哪种格式的文件。

从这方面来讲的话，这些常见的资源文件都有比较明显的文件头，游戏内自己私有的文件也一般都有这种特征明显的文件头，利用这点也可以辅助我们分析和整理内部各个函数作用情况。

x64dbg

这个就不用多说了吧，基础工具，相当于吃饭的碗筷

这边就不给出功能的具体说明和使用了，只给大家一个关键词，自己去查查去用用体会一下这些功能

• 单步，步入，步过，软硬件断点，常量、字符串搜索，修改、保存。这些应该是喝水一样了吧
• dump窗口改编码，这肯定要知道，毕竟有时候内存数据会是GBK，SJIS，UTF16，UTF8之类的
• Ctrl+R这个是查看引用，可以类比与 IDA 里的 x，Ctrl + - / + 返回前进
• 线程窗口，内存map窗口，句柄窗口，符号窗口（如果这几个都不熟的话，建议多练练）
• scylla插件

上面这些就是基础中的基础了，如果你看到上面的都有些没什么印象，就要多去看看了

下面是一些比较进阶的功能

• 打印log、条件断点 （你是否去用过log功能？是否用过条件断点？）
• 添加注释，添加标记，查看注释，查看标记（啊？不注释你逆什么？）
• 导入导出数据库（你是否把IDA识别的函数导入看x64dbg？）
• Tracing （这个好吧，其实不太常用，除非你跟踪有些壳的玩意）

反正差不多就是上面说的这些，如果有不清楚的，记得去用用看看，这些基本都常用的。

IDA Pro

IDA主要是静态分析用，如果说小打小闹，用x64dbg玩玩还行，要干比较复杂的结构逆向，x64dbg这种就效率很低了，但x64dbg也还是需要的，因为很多时候静态分析是比较难看出来的，但主要还是因为IDA Pro有比较先进的汇编转C风格代码功能，这让我们可以一定程度摆脱看一堆汇编发愣的情况，也对结构梳理有很大帮助。

所以一般推荐的方法是，动静结合，也就是我们可以用x64dbg来定位关键部分，或观察一个函数的大概功能，然后在IDA Pro里逆大概的逻辑，这样可以跳过大部分暂时还不需要深入去逆的部分，以此来提高效率，等后面有需要再慢慢把细枝末节的地方逆出来。

说到动静结合，IDA Pro能够把一些库函数分析出来，也就是把某个地址的函数名给标出来（当然这是IDA通过一些特征识别的，有些时候是不准的），我们可以把这个地址对应的函数名用一个插件（x64dbgida）导入到x64dbg里去，这样动态调试的时候就不会跑到库函数里去兜圈子了，不要到时候发现看了半天，是在库函数里，那就尴尬了，我们自己逆出来的函数名也可以导到x64dbg里，这样也方便调试观察。

说的函数名，不知道是我的问题，还是IDA的问题，我好像也没找到有什么地方可以筛选自己标记的函数名，所以我一般标记函数名都会有一个前缀，比如CMVS的字符串复制函数，我会写出 CMVS::StrCpy，这样下次想找我自己标记的函数的时候，直接搜索CMVS就可以在函数窗口里找到全部自己标记的函数了

由于IDA Pro的反编译一般默认是转C风格的代码（当然也可以改成别的语言，但一般来说没C语言好），这就要求我们C语言基础特别的扎实了（汇编至少是要能看懂的，但不要求用汇编来写程序），如果你C语言基础比较差，到时候，F5一按，基本是懵逼的状态，因为里面大概率都是v1，v2，还有一堆指针转来转去的，所以这个基础不好，就算从汇编换到C语言也没办法逆（当然了这个功能不是万能的，还是要求大家掌握C语言常见语言编译成汇编的样子，因为这玩意终究是机器识别的，有时候是会有问题的）

当然C语言基础扎实，也只是基础中的基础，C++的各种基本语法的汇编C语言形式也得非常熟练，因为游戏引擎基本都是C++开发（Galgame的引擎），所以之前我也推荐过一本书叫《C++反汇编与逆向分析技术揭秘》。

所以说，其实IDA能否用好，本质上还是和你自己的C\C++水平有很大关系

IDA Pro还有个要点就是要用好自定义结构体功能，给那些一个指针一堆偏移的结构使用，这样可以让结构更加清晰，特别是逆向C++程序的时候，要是看着this+12，this+4，this+8这种谁不晕啊。这边要特别指出的是，网上一些添加结构体的教程过于复杂，也不方便操作，我们一般添加结构体是按shift+f1，也就是打开Local Types窗口来添加。

还有

• 字符串搜索、常量搜索
• 注释（块注释，行注释）
• 函数命名/搜索/修改，交叉引用、变量命名/套用结构体/map、制图
• 常见异常情况（比如函数识别失败，参数识别错误）
• 查看入口点（main、winmain、oep、dll导出函数）
• 各种插件的使用

这些就大家自己去网上搜索了解了（让你了解，不是让你随便看看:D）。

函数分析

• 重点把握函数的输入输出（输入的指针，参数，全局变量的使用），以此先来推测函数功能（多用x64dbg调试）

• 多查看函数在什么地方被引用，以此来拓宽对函数功能的认识，一些函数可能是内部的公共函数，此时相当于标准库的作用

• 多整理函数内部成员的结构（偏移），使用结构体套用

• 对于类成员函数，对this指针的偏移重点分析观察

• 对于存在虚表的函数，没有直接地址的函数，通过调试观察

• 对于存在虚表的函数，重点观察表里的函数指针，指向函数的关联性

• 利用RTTI的特性，一定程度上可以直接获取类方法名称

• 函数过于复杂不需要死磕到底，先分析输入和输出的结果，大概把握函数的功能，后续有需要再仔细把整个函数逆出来

入手分析

其实上面也提到了，下硬件断点来定位关键位置，这里就引出了从关键位置开始回溯分析的方法和从main函数开始从头分析的方法

从main函数从头分析有助于整体把握游戏的结构，同时也可以在上下文不那么复杂的情况下，尽可能分析出库函数和模板方法类，从而为后续分析提供方便。

这里有注意点是，类似功能的函数地址基本会连续，或者同一个类的成员函数地址也大概率会连续，所以当你看到一个字符串复制函数的时候，可以看下一个地址或上一个，也许就是字符串搜索之类的函数，找到类似的函数一定要交叉引用，看看这函数在别的地方是怎么用的，也就是套用上面函数分析的观点。

从另一个角度看，从头分析将会耗费大量的时间，难以直接定位关键部分，所以回溯分析的作用就也是在这里，但是回溯分析就会出现很多不清楚作用的函数，比如有些函数可能在main函数里使用了，就是个公共函数，由于你不是从头分析的，这个函数在这边使用的时候又很复杂，而且其它函数你也没分析过，整个上上下下都是不清楚功能的函数，这样就很不利于你把握整个函数逻辑了，这个时候就要去整理这些函数的作用，其实算是回到老路上了，或直接上x64dbg追着参数和数据方向调试，这样可能又会漏掉一些关键部分，或者逻辑实在是太绕导致跟不下去。当然了还有种情况是，这部分逻辑很简单，所以直接回溯分析速度就是最快的了。

所以两种方法都有优劣，要适当结合，逆向的方法论就是从模糊到清晰，不断去调试，去观察，去整理，减少不确定度，可以是从各个方面的，因为有时候从A到B之间的逻辑过于复杂，你很难从A直接分析到B，但是可以利用回溯分析的方法，直接从B开始分析反推，从而减少A到B之间的不确定度，以此来打通A到B的逻辑。

好不好逆很多时候也和你逆出来了多少这个程序的内容，有没有理清楚这个程序的大概架构有很大关系，所以这也是开头说的，正向水平决定逆向水平。

文件操作相关API

这块我就不想多说了，因为我之前写过两篇文章讨论这个事情，具体就参考这两篇文章吧

https://github.com/Dir-A/Dir-A_Essays_MD/tree/main/方法论

下面就列出一些API函数、库函数，看看大家自己是否有用过或了解熟悉

• CreateFile A/W、ReadFile
• GetFileAttributes A/W
• fopen / wfopen / fopen_s / wfopen_s 、 fread / fclose
• FindFirstFile A/W 、_findfirst、 _wfindfirst
• malloc / free
• operator new / operator new[ ] / operator delete / operator delete[ ]
• VirtualAlloc / VirtualFree
• HeapAlloc / HeapFree / HeapCreate / HeapDestroy / GetProcessHeap
• LocalAlloc / GlobalAlloc

如果上述的API函数、库函数不熟练的建议都用用，多去看看他们的原理和实现。

（所以说之前说的下硬件断点，不就是从这些入手吗？）

在必经之路ReadFile处对读取的数据，下断点来快速定位游取封包解密的位置

在游戏处理数据的过程中下断点，快速从复杂的逻辑中定位核心部分，再从核心部分回溯分析各输入和输出

标准库

• 记住你的标准库方法不一定和游戏的标准库方法通用！

• Hook的时候互操作优先选用系统API，实在不行定义函数指针调用游戏本身的库函数

• 如果游戏自身有一套内存管理，最好逆向出来直接使用

• 记住标准库的一些方法是对系统API的封装

• 很多问题可以直接从系统API入手

• 做到从源头拦截的效果

其实这个问题和上面是一样的，主要就是想强调，标准库和系统API的关系，以及这里面引出来的问题和思路

开发过程中不可避免的会使用标准库，一是跨平台方便，二是提高开发效率，所以标准库一直都是广泛应用的

C语言的标准库，还好说，IDA基本都能识别，C++因为用的模板编写的标准库，所以识别起来比较困难，
但常见的std:string std::vector 之类的还是应该去看看，有能力的一定要去看标准库的源码

不过话又说回来了，标准库的实现不是统一的，只是有这么个标准，不同编译器有不同的行为和实现，
但是Windows上一般的Galgame引擎都是MSVC编译的，所以重点熟悉MSVC的实现，其它也大同小异，多看看就行了。