Does anybody know of a way to prevent the timestamp of an executable from changing? I'm trying to generate a consistent hash code for the .exe but I think the timestamp may be preventing that from happening. Each time I recompile the code (VS C++) the FastSum generates a different checksum.
Thanks!
The PE file format (as in your EXE) has a timestamp field. Check out "Table 2. IMAGE_FILE_HEADER Fields" at this link: http://msdn.microsoft.com/en-us/library/ms809762.aspx
It seems like if you really wanted to, you could edit TimeDateStamp in a hex editor, or write a small program to do it for you. If I read the above document correctly, it looks like it's 4 bytes at offset 10.
I'm not sure what the consequences are of changing this. My guess is it may make you unable to find symbols when you debug the program. Maybe instead of changing this field in your binary you should hash regions outside the PE header. (The link I provide may help you determine where that would make sense.)
Depending on what you have to checksum, you can either strip off the COFF header (where the timestamp resides) or the Optional Header. In the latter case, you just only save the section table and section data (the binary content of the executable). If you make sure your source code is not changed and compile and link flags are not changed, the section data should remain the same. If you want to include version numbers or size of code in the checksum, you must include the Optional Header.
To find the start of Optional Header, follow the procedure:
Read 4-byte signature base address from 0x3c.
Goto the signature offset.
Offset 20 bytes. This is the start of the Optional Header.
You should expect 0x10b here if it is 32-bit exe file or 0x20b if 64-bit.
To find the start of section table, follow the procedure:
Read 4-byte signature base address from 0x3c.
Goto the signature offset.
offset 16 bytes.
Read 2-byte Optional Header size here.
Goto the Optional Header.
Offset Optional Header size bytes. This is the start of the section table.
You should expect a section name here (like ".text", ".data", etc).
For complete specification of PE & COFF format, download this: Microsoft PE and COFF Specification.
Which timestamp? Last accessed? You can't prevent that changing if you are accessing it - however you could take note of it and then change it back?
For a hash - what do you mean? A method of ensuring that the .exe hasn't changed? I'd use a CRC.
File timestamps are something controlled and maintained by the OS - they're not internal to the file (including executables) itself.
Related
Is it possible to replace embedded resources [e.g. styles, images, text] in a Linux [ELF] binary?
I noticed that I can change text but if I type more text or if I remove text, then the segmentation faults start coming up. I have not gone through the ELF spec yet but I am wondering if it is possible.
I managed to extract the images from the binary using the mediaextract
project but I need to do just the opposite without breaking the binary structure.
This answer is specific for Qt's resource system (.qrc, rcc).
From the docs:
Currently, Qt always stores the data directly in the executable, even on Windows, macOS, and iOS, where the operating system provides native support for resources. This might change in a future Qt release.
So yes, the Qt resources are contained in the binary.
rcc'ing a .qrc file yields a .cpp file containing (mainly) simple char arrays which represent resource data, the resource names and some other metadata.
Compiling such a .cpp file creates byte fields in the binary.
You can alter such resources within a binary, but only in very limited ways.
For starters, if the binary contains any kind of self-check (like hashing the data section and comparing it to some pre-calculated hash), you will not be able to change the data in a reasonable way.
If your data doesn't have the same byte length as the original data, you can't simply replace it because it would alter the internal layout of the binary and invalidate relative addresses.
In case of replacing with shorter strings you might get away with zero-padding at the end.
Resources are compressed by default (in the ZIP format). It is possible to turn off compression.
If compression was turned on during compilation (which you don't control, as it seems), you'd need to create new data which compresses to the same length as the original.
I'm developping a blackberry 10 mobile application using the momentics IDE (native sdk).
In my code, I want to add a function that should check if a file is corrupted or not .
How should I do proceed ?
Two methods I can think of: -
1) If you're writing out the file, ensure you have a specific set of bytes that you write out at the end. When reading the file in, move to the end of the file and check if those bytes are present. If not, the file didn't finish writing and can be considered corrupt. Alternatively to this is to write out the size of bytes to the beginning of the file and check to see if the rest of the file size is equal to that number when it is read back in.
2) If you're checking a file that doesn't change, store a hash of the contents of the file and at run-time, generate the hash and compare it to the one you've stored. If they differ, the file has been modified and you can consider it corrupt.
What do you mean by corrupted?
If you want to see if the file is what you expect or not, you can calculate a hash of the file, like SHA-256 or whatever hashing algorithm you like, store the hash values, and then in your application simply calculate the hash values of the files, compare to what you expect, and if they're the same, there is most probably no corruption.
You might want to have a look here.
I have a text file (>50k lines) of ascii numbers, with string identifiers, that can be thought of as a collection of data vectors. Based on user input, the application only needs one of these data vectors at runtime.
As far as I can see, I have 3 options for getting the information from this text file:
Keep it as a text file, extract the required vector at run-time. I believe the downside is that you can't have a relative path in the code, so the user would have to point to the file's correct location (?). Or alternatively, get the configure script to inject the absolute path as a macro.
Convert it to a static unsigned char using xxd (as explained here) and then include the resulting file. Downside is that a 5MB file turns into a 25MB include file. Am I correct in thinking that this 25MB is loaded into memory for the duration of the runtime?
Convert it to an object and link using objcopy as explained here. This seems to keep the file size about the same -- are there other trade-offs?
Is there a standard/recommended method for doing this? I can use C or C++ if that makes a difference.
Thanks.
(Running on linux with gcc)
I would go with number 1 and pass the filepath into the program as an argument. There's nothing wrong with doing that and it is simple and straight-forward.
You should have a look at the answers here:
Directory of running program
The top voted answer gives you a glue how to handle your data file. But instead of the home folder I would suggest to save it under /usr/share as explained in the link.
I'd preffer to use zlib (and both ways are possible:side file or include with compressed data).
in first exe i have defined array of char with some special bytes as label, i mapping it to memory from another exe, finding needed label and putting in it new data, but this data could be shorter then defined array, so i want to cut this array to needed size! how can i do it?
There is no fine and simple way to cut out pieces of PE file.
Obvious solution is to additionally define a length field in the original (in your terms first) exe and mark it with another label. Then additional work of second exe would be to write to this field actual data length.
EDIT: If cutting is your primary goal you must also keep in mind that:
Control sum of a PE will change. Location of control sum field in PE header is not hard to find though.
PE file is aligned. All sections are aligned. The alignment could be found in the header too.
If you cut one section it would cause great consequences. Take a look at PE file header structure.
Reference:
http://msdn.microsoft.com/en-us/library/ms809762.aspx
As stated, will renaming a file change the CRC? I've checked in plain text files and it didn't. Does this apply to all files of all formats?
CRC is calculated on the contents of the file. The file name is just an entry in the file system that allows access to the file. It's not part of the file itself, so it's not part of the CRC.
CRC is normally calculated on file content, but there's no prison sentence prescribed for writing a CRC utility that includes the filename. Check your particular utility's documentation, or I'd say it's safe to trust the results implied by your experiment.