如何在 Windows 应用程序中对扰乱的数据包进行逆向工程?
我有一个 Windows exe 应用程序,用于以明文方式将数据包发送到服务器。 这个应用程序(让我们称之为客户端应用程序)绝对是闭源的,但是一些聪明的黑客对二进制文件进行了十六进制编辑,并使其发送加扰的数据包。
现在,显然,这些数据包以可破译的方式进行加扰(否则服务器将无法理解它),但我想做的是编写一个模拟这个二进制应用程序的模拟器,将相同的数据包发送到服务器,并能够解读响应(如果它被扰乱)。
十六进制客户端需要额外的 dll 才能运行,而旧客户端则不需要。 我假设以某种方式,十六进制客户端设法加载该 dll(让我们称之为 client.dll),并且该 dll 的功能是通过挂钩某些 Windows api 来实现加扰/解扰,该 API 重新路由从client.exe进程。
如果有人可以指导我如何开始研究这一切是如何工作的,以及如何对扰乱进行逆向工程,那将非常感激。
我不知道要提供什么样的信息,但如果有任何缺少的信息,请回复,我会发布更多详细信息,如果有人想要二进制文件,我很乐意提供。
任何感兴趣的人都可以下载二进制文件:
http://dl.getdropbox.com/u/46623 /client.dll
http://dl.getdropbox.com/u/ 46623/newClient.exe
http://dl.getdropbox.com/u /46623/originalClient.exe
这些不会运行,因为需要资源文件 - 它们大约有 3 GB,太大而无法上传到任何地方。 为了保护有罪的人,名称已被更改 =) ,但这可能并不能保护 dll 的名称......
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我假设编写此钩子(为上述程序的数据包 I/O 添加加密)的人已经钩住相关的 Windows 套接字 API(
WSASend
、send
等)或挂钩用于发送/接收数据的内部程序函数。话虽这么说,我建议您使用挂钩检测程序(例如RkUnhooker)来找出实际被挂钩的内容。 一旦您知道了哪些 API 被挂钩,您还应该知道这些挂钩的去向,从那里开始,您必须手动对挂钩函数进行逆向工程。
至于学习如何做到这一点的主题,我无法指导您仅通过一个教程来教您所有内容,但我强烈建议您查看 Tuts4You 网站,它有大量的教程,可以满足您的所有需求。
如果可能,请上传已编辑的客户端和客户端的副本。 钩子DLL,如果我有时间我会给你编码复制加密& 解密功能。
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (
WSASend
,send
, etc) or hooked the internal program functions used to send/receive data.This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
您需要挂钩附加 DLL 导出的函数,并查看正在调用的函数以及传递给它们的参数。 这并不容易,因为您没有类型信息(例如 DLL 导出的函数签名)。
请查看 此处了解有关 API 挂钩的一些信息。 您还需要一个好的调试器,请尝试使用 Microsoft 的 Windbg。
据我所知,这里唯一的选择是黑盒测试,即向两个系统提供已知输入,然后比较彼此的响应以找出差异和相似之处。
现在,一旦您弄清楚如何使用附加 dll 中的函数,您就可以像原始应用程序一样自行使用它。
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.