Hexing an *.exe - does a timestamp gets also modified?

Question

I'm trying to hex a *.exe file to change the font from Arial to Tahoma. I already did it, the issue is that the program notices something has changed.

I'm relatively newbie to hexing, so I am not sure if whenever you hex an exe, some date also changes (and probably that's how the program notices it). Can anybody confirm this and if possible propose a solution?

Answer 1

Normally, the date timestamp on an executable is meaningless, because the timestamp won't be the original compile time, but instead the installation time. There's no way the executable could depend on an external timestamp to verify if it is intact.

Some executable files are digitally signed. This means that an cryptographic function is applied against the file using the publisher's key, and affixed to the executable. This signature can be verified by the OS (such as Windows), or by the executable itself.

Any changes to the binary structure of the executable will be noticed because the signature won't match the computed value. There's usually no way to generate the correct signature without the original key, which is a security feature that prevents tampering (e.g. to crack software, or a virus infection).

Beyond that, there can also be CRC (e.g. CRC-32) that can simply detect changes to the executable as well. In this case, the executable might be verifying the check internally, which you might be able to bypass by tracing through the executable code until you find the check routine and no-op (0x90) out the function call to the checking function.

Answer 2

It seems that the exe has a self-protection logic, which is quite normal nowadays. However, the ways to achieve this protection are not the same. Some use digital signatures, some use CRC checks, some use 3rd party module protection tools and so on. But I believe the 3rd party one is not your case as usually the modules generated by those tools are compressed and/or encrypted so that you couldn't find the information directly.

However, although it's possible to use that timestamp information to detect modification, it should be pretty rare to use timestamp only for the protection as anybody can change it using this sort of tools. You may revert the attributes if you have the original as it does not harm, but probably it won't work.

So, what's the next step? To overcome the problem, we need to know what sort of checking is done for modification detecting which must be much more complicated than hexing a module. After doing that, we may take some advanced approaches like in-process memory modification, cracking the detecting routine or hooking Windows API calls to achieve the goal of font replacement, but none of them can be achieved by hexing only. You need to learn how to use debuggers at least. Perhaps somebody cracked the file already for different purposes such as NO-CD patch and then you may grab it for hexing and probably it will work as the logic will be already deactivated. But please consider legality all the time before taking any action.

However, you're trying to just change the font in use. This looks somewhat legit for me - why don't you ask the application vendor to make an option to change fonts?