理解/逆向工程顶层网络协议的好工具
手头有一个有趣的问题。我有一个通过客户端应用程序（不是浏览器）运行的角色扮演 MMOG，它将玩家的操作发送到服务器，服务器通过发回数据包来保持所有玩家的同步。
现在，游戏使用 TCP/IP 上的顶层协议来发送数据。但是，wireshark 不知道正在使用什么协议，并将 TCP 标头之外的所有内容显示为转储。
此外，此转储没有任何纯文本字符串。尽管游戏具有聊天功能，但在此转储中任何地方都看不到发送的聊天字符串为纯文本。
我的任务是对协议进行一些逆向工程，以找到有关数据包中包含的数据的一些非常基本的内容。
有谁知道为什么聊天字符串不以纯文本形式显示以及是否可能正在使用标准顶级协议？
另外，是否有任何工具可以帮助从转储中获取数据？
There is an interesting problem at hand. I have a role-playing MMOG running through a client application (not a browser) which sends the actions of my player to a server which keeps all the players in sync by sending packets back.
Now, the game uses a top layer protocol over TCP/IP to send the data. However, wireshark does not know what protocol is being used and shows everything beyond the TCP header as a dump.
Further, this dump does not have any plain text strings. Although the game has a chat feature, the chat string being sent is not seen in this dump as plain text anywhere.
My task is to reverse engineer the protocol a little to find some very basic stuff about the data contained in the packets.
Does anybody know why is the chat string not visible as plain text and whether it is likely that a standard top level protocol is being used?
Also, are there any tools which can help to get the data from the dump?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果它是加密的，您确实有机会（事实上，如果处理得当，您有 100% 的机会）：密钥必须驻留在您计算机上的某个位置。只需打开您最喜欢的调试器，观察从套接字传入的一点（呃，我希望是一百个字节左右）数据，在该数据上设置一个观察点，然后查看访问的内容的堆栈跟踪它。如果你真的很幸运，你甚至可能会看到它被解密。如果没有，您可能会通过查看堆栈跟踪（如果幸运的话）或通过使用现有的 IV / S-box 分析器之一（避免学术性的，它们中的大多数在没有很多麻烦的情况下无法工作）。许多加密算法使用可检测的“标准数据”块（这些是 IV/S 盒），这些是您在没有其他信息的情况下寻找的内容。无论你发现什么，谷歌它，并尝试覆盖他们的加密库来转储正在加密/解密的数据。从这些转储中，应该相对容易看出发生了什么。
重新创建加密会话可能会很有趣，但它需要调试器的技巧和大量的阅读。这可能会令人沮丧，但如果您花时间学习如何做到这一点，您就不会后悔:)
If it's encrypted you do have a chance (in fact, you have a 100% chance if you handle it right): the key must reside somewhere on your computer. Just pop open your favorite debugger, watch for a bit (err, a hundred bytes or so I'd hope) of data to come in from a socket, set a watchpoint on that data, and look at the stack traces of things that access it. If you're really lucky, you might even see it get decrypted in place. If not, you'll probably pick up on the fact that they're using a standard encryption algorithm (they'd be fools not to from a theoretical security standpoint) either by looking at stack traces (if you're lucky) or by using one of the IV / S-box profilers out there (avoid the academic ones, most of them don't work without a lot of trouble). Many encryption algorithms use blocks of "standard data" that can be detected (these are the IVs / S-boxes), these are what you look for in the absence of other information. Whatever you find, google it, and try to override their encryption library to dump the data that's being encrypted/decrypted. From these dumps, it should be relatively easy to see what's going on.
REing an encrypted session can be a lot of fun, but it requires skill with your debugger and lots of reading. It can be frustrating but you won't be sorry if you spend the time to learn how to do it :)
最佳猜测：加密或压缩。
即使 telnet 也支持有线压缩，尽管整个协议完全基于文本（嗯，非常接近）。
您可以尝试通过一些常见的压缩实用程序运行数据流，但我怀疑这对您有多大作用，因为它们很可能不传输压缩标头，只是强制执行一些预定义值。
如果它实际上是加密，那么你就完蛋了（没有太多、更多的努力，我什至不打算开始讨论）。
Best guess: encryption, or compression.
Even telnet supports compression over the wire, even though the whole protocol is entirely text based (well, very nearly).
You could try running the data stream through some common compression utilities, but I doubt that'd do much for you, since in all likelihood they don't transmit compression headers, there's simply some predefined values enforced.
If it's infact encryption, then you're pretty much screwed (without much, much more effort that I'm not even going to start to get into).
它很可能被压缩或加密。
如果它被加密了，你就没有机会了。
如果它被压缩，您将必须以某种方式找出数据的哪些部分被压缩，压缩部分从哪里开始以及压缩算法是什么。如果幸运的话，您将可以识别标准标题，尽管它们可能被删除以节省空间。
这一切都不简单。逆向工程很难。没有任何标准工具可以帮助您，您只需调查并尝试一些事情，直到找到答案。我的建议是向开发人员询问协议规范，看看他们是否愿意帮助支持您正在尝试做的事情。
It's most likely either compressed or encrypted.
If it's encrypted you won't have a chance.
If it's compressed you'll have to somehow figure out which parts of the data are compressed, where the compressed parts start and what the compression algorithm is. If your lucky there will be standard headers that you can identify, although they are probably stripped out to save space.
None of this is simple. Reverse engineering is hard. There aren't any standard tools to help you, you'll just have to investigate and try things until you figure it out. My advice would be to ask the developers for a protocol spec and see if they are willing to help support what you are trying to do.