Although this question is a bit broad, I feel that I can provide an acceptable answer by at least explaining some ways that I've used file format structures in reversing.
First of all, a reverse engineer "in the workforce" always has some goal. For example, a malware analyst working at an antivirus company may analyze a sample to:
- Learn how the same works
- Learn novel techniques that it used to defeat the antivirus system
Reverse engineering is simply learning about how a given system works. A file format is part of this system, and as such, simply learning about how the file format works, what its magic value is, what type of data is stored there, what the header consists of, and so on are all part of the reverse engineering process for some projects.
One project that I worked on involved learning how the PE format header of some files differed from the PE format header of other files. In doing this, I needed to find out why the Windows operating system would properly load certain PE files, and would refuse to load other PE files, based on some data modifications in the PE file headers.
This project was not open source, so I cannot go into too much detail, but I can tell you that people who want to prevent reverse engineering will use tools/algorithms called "packers" and "software protectors" and one component of these tools is that they will obstruct, corrupt, or otherwise mutate the data in the PE header on disk. One example of why someone would do this is because the PE header has a list of all external libraries and functions which will be called by the executable. This list is called
IMAGE_IMPORT_DESCRIPTOR for each DLL such as kernel32.dll and ntdll.dll which has a list of
IMAGE_IMPORT_BY_NAME (can also be ordinal imports) which lists out all of the functions to be used by the executable. An easy way to learn about how a program works is to simply view this list of imports because if a program will use networking, there will be networking imports, if it uses cryptography, there will be crypto imports, and so on.
So to prevent this, software packers and protectors will often destroy this table on-disk and then rebuild it dynamically after the program is run. In order to effectively analyze the program, reverse engineers often have to dump the program after it is loaded in memory and rebuild the tables with a tool like ImpRec. Having a solid understanding of the PE file format makes this task possible.
In the case of my aforementioned project, I needed to find out when a bit was set in a header member, why the OS would treat the file differently than if that bit was cleared. This involved learning the file format, then using WinDbg as a kernel debugger to find out why
NtCreateProcess would not load certain files.
I had a file parser that I needed to test for security vulnerabilities. One of the parser's main jobs is to read the file format header data structures, interpret them, and then act upon that data. Think of what happens when Adobe Photoshop opens up a JPEG file, for example. For this task, I had to study the documentation for the file format to better understand what those data structures did, then I wrote a custom fuzzing tool to inject arbitrary malformed data into the headers in an attempt to exploit the parser application.