 Welcome to Math Analysis for Hedgehogs. Did you know that you cannot trust any compiled timestamps in Windows system files? Well, here's why. So I would like to show you something. Just open a file in your System32 folder. You go to Windows, System32, scroll down a bit, you have a ton of DLLs in there. And open this file in Potex Analyzer. And now check the compiler date. In a lot of cases, the compiler date will not make sense. Okay, 2008, maybe that makes sense. Let's just pick some other file. Here we have one. That's 1981. That can't be right. And if you open files here, you will have like random compiler dates. Like they are all over the place. They can be in the future. They can be too far in the past to make sense. And like it's the case here. And why is this? Why are the timestamps like that? Now the answer is in the debug portion of the file. You see here there is a debug entry called repro. And whenever this entry exists, you cannot trust any of the time date stamps. Go to this entry. You see here repro hash. And you see here as a description for this debug entry type, it stands for PE determinism or reproducibility. What does this mean? That means this file has been compiled with a specific linker flag called be repro. And that linker flag causes the file to override all timestamps with a part of this repro hash. And that part of the repro hash are the last two bytes. Because if you check this, the time date stamp here, that's again this with 1981. So that's the exact same one you saw in the PE headers. And here is the actual value. And that is 16, 7F to E, F5. 16, 7F to E, F5. You see that? So this is actually the last part of the repro hash that is used for the timestamp. And not only for this timestamp, for the compiler date, but for all of the timestamps, or almost all of the timestamps you find throughout the file. So it's also used for the timestamps in the debug entries. So all of these debug entries, they have timestamps as well. And that's what is used here. The purpose of this linker flag for reproducibility is that if you do not change the code, the resulting executable is guaranteed to have the very same contents. And if you use timestamps, those contents will change because the timestamps are dependent on the compile date. So in order to make this work and produce the very same file contents for every compilation, if the code didn't change, you need to replace the timestamps. And they just replace the timestamps with part of the repro hash. So that explains it. And now you know, whenever this debug part or this debug entry is present, do not trust any timestamp.