P3D v4 Decompile a file

[RED COOL]

hello
i'm a bit curious about file formats and their structure

let's say we know a file structure (WIKI) and we want to decompile it

if i use C# or C++, will I just make a class that matches the file and then deserialize it?

and what about all those offsets? i know that we can read memory addresses in some languages, is it the same for files? we load a file then we take the memory address and we keep adding an offset and extracting data?

 

[scruffyduck]

Assuming you understand the format of a file which is essentially a sequence of bytes and you need to identify the way these are grouped together so you can decompile them into an object. The format will tell you the order in which things are stored, what the identifier is for each thing, how many bytes are used to represent it and the data types used.

So we might create a byte array for the file and starting at the first byte chunk it into the sections and contents. You might step through the file using a master pointer so you know where you are and increment that by the size of each section chopping it up and processing it as you go. Each section (or chunk) represents something, so in a scenery bgl file it might represent a taxiway or parking spot or runway.

You might create a main class that represents the file, but then that class may need to hold a list of other classes that represent the taxiway, parking spot or runway. Some of these classes will be simple (e.g. a taxi point) but others (e.g. a runway) may be a lot more complex and could hold a list of items defined by other classes such as runway extension, lighting, approach lights and so on. This may end up looking like a tree where the main class holding everything and the branches and so on being the items that make it up.

As mentioned earlier a file is just a sequence of bytes, offsets might be a pointer telling you where in the sequence to find something. In some cases the offset can lead directly to a particular item (or items) and in other cases you need to keep reading down the file taking off the bytes defined by the file format. For example an offset might tell you where in the file to find the data for taxi links, The first byte(s) at that point might tell you how many taxi links are to follow. Since you know that size in bytes of the data for one link you can step down the file picking off each one until you have completed the count.

I am sure there are lots of ways of doing this but memory addresses are not needed - it is more the address of a set of bytes that represent an object.

The ADE decompiler has around 80 classes representing different scenery elements. But this is just my way of doing it

 

[RED COOL]

I really like your way

Lets say i have heading information at Bytes [48]

Will i use convert.todouble (that byte )
Or it is more complex

 

[scruffyduck]

You need to look at the file format and the data type for that field. It may be two bytes or four bytes and you need to identify the data type and then the conversion method to get what you want

Heading is likely to be 4 bytes representing a FLOAT formatted number

 

[scruffyduck]

Also the value you get from a field may need further calculation to turn it into a meaningful value. Documents on the file format should tell you what calculations, if any, you need to do. File formats have been worked out by individuals reverse engineering the actual files. Officially the formats are proprietary and we do not have the designers information about them.

 

[WarpD]

I suggest looking up how to read files using C#, also learn the difference between reading text and reading binary.

 

[RED COOL]

I always use read bytes function from system.IO into an array , is there a better one ?