Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Borland IMAGE_RESOURCE_DIRECTORY TimeDateStamp incorrectly decoded #42

Closed
ignacioj opened this issue Nov 14, 2023 · 8 comments
Closed
Assignees
Labels
bug Something isn't working

Comments

@ignacioj
Copy link

The IMAGE_RESOURCE_DIRECTORY TimeDateStamp of a Borland C++ compiled DLL is not decoded as MS DOS Timedatestamp. The IMAGE_FILE_HEADER TimeDateStamp is decoded correctly, 0x42db5dac (2005/07/18 07:43:40), but the IMAGE_RESOURCE_DIRECTORY TimeDateStamp value 0x32f26d74 is decoded as 1997/01/31 22:08:52 instead of 2005/07/18 13:43:40.
As far as I know Visual Studio never sets the IMAGE_RESOURCE_DIRECTORY TimeDateStamp so I suggest either always decode that value as MS DOS Timestamp or show both decodings, Epoch and MS DOS.
File: unrar.dll (SHA1: 1195ee4a5e1c19daf13ded219ba874e903f49a48)
https://www.virustotal.com/gui/file/f0055ca904b9641f889c81ca72a485c92305363dfef12edc569cf2ca0e4bb0d0/details

@hasherezade
Copy link
Owner

hi @ignacioj !
Thanks for reporting, it will be fixed in the next release.

@hasherezade hasherezade self-assigned this Nov 16, 2023
@hasherezade hasherezade added the bug Something isn't working label Nov 16, 2023
@ignacioj
Copy link
Author

As a side note: there is a delay of exactly six hours between the FILE_HEADER and RESOURCE_DIRECTORY timestamp. I know that these timestamps should always be considered UTC. I have no more data on the Borland C++ compiler nor any more executables obtained with that compiler, so I ask you this question in case you know, is this delay due to the fact that a timestamp is created in UTC and the other in local time? It would be strange but very interesting.
Thank you!

@ignacioj
Copy link
Author

I have not found information on Borland C++ executables but if the MS DOS timestamp format is local time I assume that the Borland Compiler follows that specification.
https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times
https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime

@hasherezade
Copy link
Owner

I also think it is a local time. That would make sense. Anyways, I am planning to make some testcases compiled with Borland C++, and will check it just to be sure.

@hasherezade
Copy link
Owner

hasherezade commented Nov 19, 2023

@ignacioj - my tests confirmed that it is a local time.
BTW - please check the last builds ( they are available via AppVeyor build server ) and let me know what do you think.
https://ci.appveyor.com/project/hasherezade/pe-bear/build/job/7t5751961p2wmabi/artifacts

@ignacioj
Copy link
Author

ignacioj commented Nov 19, 2023

I see that now it displays: Monday, 18.07.2005 13:43:40 (Local)
I think that some people could think that "Local" refers to their local time, instead of the local time of the place where it was compiled.
What do you think?
Maybe it should say "Compiler Local Time"?

@hasherezade
Copy link
Owner

@ignacioj - you are right that the "Local" may be misinterpreted by the user. I changed it to "Compiler Local Time". Check it out.
https://ci.appveyor.com/project/hasherezade/pe-bear/build/job/q8ie6i6ufoi4y4yo/artifacts

@ignacioj
Copy link
Author

Checked! Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants