How can I get a file structure using Ghidra

[boatbuccaneer]

I have started a project to try to create an emulate for an old game server, but I cannot sniff the package because the server is down since 2016.

So, I decided to check the client binary and try to send the expected value to it.

I already made the client send the request for my address editing it with a Hex editor.

The first request that the client make is getting for a file called `client.xml` in the server. Looking in the binary with Ghidra, I have found only one reference for this file, so the context of it seem narrow.

However, I don't know how to identify what this `client.xml` file must have. My bet is that function has the answer.

I would like to know what I can do the get the structure the structure of this file.

Sorry if the question is not well structured. This is my first thread here.

One more thing, Ghidra says it compiler is the visualstudio.

 

[zipper20032]

Welcome to RE. I suggest you to try IDA Pro with HexRays decompiler, also it's more friendly. Having the HexRays decompiler, this one is interpreting ASM to C/C++ but still it's a hell of a mess in there so you need to figure out what function is doing what, but better than nothing.

When it comes to RE the network protocol, you should actually start looking for winsock things (if it's winsock), like send() and recv() functions or similar ones at first because you need a starting point. (You really can't look in every thousands of functions). Then you can trace back and looking at cross references/xrefs (where send() or recv() is being called from) and you can trace down what functions are used for encrypting (for send() to client) and decrypting (for recv() from client) the packets. You can do this while working on your emulator in parallel with reverse engineering the game client files. You need to find to emulate the network protocol and here's a lot of trial and error in both your server project and in your client, then, the half of the job is done.

Also, get a packet sniffer and check the TCP/UDP packets sent by client, document them in an Word/Excel document. Try looking at packets to see if the first packets of the game are different for each run of the client (that would mean dynamic encryption keys if the packets are different).

XML files are having some designated XML classes and objects (depending on what libraries developers used), so when the client is reading an XML, it should use some XMLNodes class objects or something similar to identify the strings inside the XML. Again, looking for strings with IDA inside that game file, you could see where the string is being used and trace it to the function which is reading the XML nodes inside, so if you know the name of the file, you can trace it where the client is using it.

Also, you can use IDA Pro's debuggers, so you could open the game, add breakpoints in IDA where you think is interesting, and run the client with the debugger. (Remember that running an executable with the IDA Pro's debugger, this will change every function names, meaning loading in memory will affect the function addresses because of the handle's offset address, so you will need to start over with the files. So, just have 2 copies of your IDA Pro generated files, one for looking into functions, one for debugging.

Document everything you think it's important, so you won't spend tons of hours searching for the same thing.