Can Ghidra show when a file was compiled?

[NTOTL]

After I imported a file in Ghidra for malware analysis, I could not find the information about when the file was compiled. Can Ghidra display the timestamp when the file was compiled?

[d-millar]

@NTOTL The answer is yes but with a few caveats. Both Windows' PEs and Linux COFFs have timestamps in the headers. You can view the headers in Ghidra by importing them the usual way and opening up the header sections or importing them as binaries and applying the relevant scripts. If I remember correctly, the timestamp is in the third field of the COFF subsection of the headers and should correspond to the creation time.

That said, it's very easy to remove or fake this timestamp, and there is really nothing that guarantees its validity. The loader does not depend on the value in any way, so any value is valid in some sense.

[d-millar]

P.S. If you need more details on the header, Ange Albertini has some fabulous reference materials, e.g. https://code.google.com/archive/p/corkami/wikis/PE.wiki

[NTOTL]

@d-millar Thank you for your reply. I am new to Ghidra and I am having trouble opening up the header sections. This is what I did: after I import my .exe file in Ghidra, in the Data Type Manager window and under the PE folder, there is an "IMAGE_FILE_HEADER" file, I assume this is the file that should contain the information I am looking for, but I don't know what to do next.

[dev747368]

@NTOTL the data type manager is just a view of the possible data types defined for your program. Some of the data types might not even be used in your program, or may be used more than once. The Listing window is where you see the data in your program.

There is a right-click menu action (Find Uses Of) in the data type manager that will search your program for any uses of the data type. You can use that to find where the IMAGE_FILE_HEADER is used in the Listing window.

[NTOTL]

Thank you so much for the detailed instructions.

[d-millar]

@NTOTL Sorry about that - was in a bit of a rush, could have been more explicit!

Given you mentioned you file was a .exe, let me use notepad.exe as an example. There are a couple of ways to do this. All give similar results, but you might as well know how to do all of them. :)

So the easiest thing to do is let Ghidra more or less do all the work for you. I'll start up Ghidra, launch the CodeBrowser tool, and do File->Import File-> directory walk to notepad.exe. The default import will be as a Portable Executable (PE). You can say yes to analyze if you want, but for your particular task you don't even have to do that.

The Listing view should now show notepad.exe based at 0x140000000. What you actually looking at at this point are the image headers as they would be loaded into memory. If, for some reason, you're not seeing this or want to see only this, you can go to the Program Trees view and select "Headers" under the folder marked "notepad.exe".

The Headers segment is not a proper segment from the perspective of the PE loader, but so many people find it useful we auto-generate it at import. What you're actually seeing is the PE data type applied to the bytes in the beginning of the file. You could have done this yourself by importing the program as "Binary" instead of "PE" and dragged the data type "PE" onto the raw bytes at the beginning of the file. (You were very close to having done exactly the right thing - the IMAGE_FILE_HEADER data type is a piece of the PE data type.)

Now that we have the data type applied either by default for a "PE" import or by applying it to the "Binary" import, we still need to find what you're looking for. In this case, I'm going to cheat because I know where it is, but there are ways to search through the Listing or to filter types in the Data Type Manager view that would also get you there. (Yell if you'd like more details.)

So, close the IMAGE_DOS_HEADER using the little minus/plus control and scroll down past the IMAGE_RICH_HEADER and the group of blank bytes below until you get to IMAGE_FILE_HEADER within IMAGE_NT_HEADER at roughly 0x1400000fc. (It may help to open the "Edit Listing Fields" menu in the toolbar and resize the name field so you can read the "Mnemonic" and "Field Name" fields more clearly.)

Open IMAGE_FILE_HEADER. This is the beginning of what is generally referred to as the COFF header. The third field should say TimeDateStamp. For my copy of notepad, it has the value 329A7791h. Believe it or not, this is what you are looking for. This is the file creation time measured in seconds from January 1, 1970 UTC. At this point, I cheat again and go to the website https://www.epochconverter.com/hex. Entering 329A7791 into the converter, I get Nov. 25, 1996 11:52 EST. Hmmm, well, I have to say this is the first time I've actually done this - and merde this is the create time proper, not the compile time. That's disappointing.

I may have let you down here - apologies. Will do a bit more research. I always assumed this was the compile time proper, but I don't think I believe that in this case.

Leaving for aside my possible abject failure, there is one other way to get the same information. In addition to (1) importing the file as a PE, or (2) importing the file as "Binary" and dragging the "PE" data type onto its start, you could also have (3) imported the file as "Binary" and run the "PE_Script" from the Script Manager. (This might give slightly better results than dragging the "PE" data type if I remember correctly and should produce almost the same results as the normal import.)

OK, I'm going to do some more research now on compile vs create times, but, if any of this is unclear, give us another shout.

Cheers, D

[d-millar]

OK, a little bit of follow-up.... It appears that as of the release of Windows 10 the timestamp field is now basically just a hash, i.e. it's unique per file but no longer represents an actual time. Sort of sad that. Apparently, Microsoft wants to be sure that when you compile the same code you get exactly the same result, and, for obvious reason, the timestamp throws a wrench into that plan. You learn something every day - whether you like it or not, no?