01The question
Is the creation metadata of the submitted .docx consistent with the date printed in the document, or does it indicate the file was created or edited later?
02Background
A fictional dispute at Delta Lojistik turns on whether a contract existed on the date it bears. The .docx file and the workstation image where it was found were provided. The examination compares independent time sources inside and around the file.
03Constraints
- Document metadata is set by the application and can be edited; it is one source among several, not decisive alone.
- A file copied between systems takes new file-system creation times; those were interpreted with that in mind.
04Evidence received
05Examination method
Read the OOXML core and app properties
The .docx was opened as a ZIP package. docProps/core.xml gave dcterms:created and dcterms:modified and the revision count; docProps/app.xml gave the editing-time total and the application version. These were recorded with the exact XML values.
Inspect the package's internal entry times
Each file inside the ZIP carries a local modification time in its directory entry. These were compared with core.xml; a package whose internal entries are all newer than the claimed creation date indicates later authoring or re-saving. The application version string was compared with the versions available on the claimed date.
OOXML core.xml and app.xmlHex viewer and data inspectorTimestamp decoder
Compare with file-system times on the host
On the workstation image, the $MFT $STANDARD_INFORMATION and $FILE_NAME times for the file were read and compared with each other and with the document metadata. A $FILE_NAME creation time later than the claimed date, and an application version not yet released on that date, are independent of the document's editable metadata.
$MFT (NTFS Master File Table)NTFS $STANDARD_INFORMATION vs $FILE_NAMETimestamp decoder
Weigh the independent sources together
No single time was treated as decisive. The conclusion rested on sources that an editor cannot easily align: the application version string, the ZIP entry times, and the host $FILE_NAME times, all normalised to UTC.
OOXML core.xml and app.xmlNTFS $STANDARD_INFORMATION vs $FILE_NAMELocal time to UTCtimebases
06Findings
Established
The document was created later than the date it bears.
BasisThe application version named in app.xml was not released until after the claimed date, the ZIP internal entry times are all later, and the host $FILE_NAME creation time agrees.
Probable
The core.xml created date had been set to an earlier value than the true authoring time.
BasisThe created date contradicts the application version and the package entry times; editing the field is the simplest explanation.
07Limits
- The examination dates the file, not the agreement; a later file can still record an earlier real agreement.
- File-system creation time reflects when the file arrived on that volume, which may differ from authoring.
- The finding is about this file; another copy could carry different metadata.
08Report excerpt
docProps/app.xml names an application build first released after the date on the contract. Every entry inside the .docx ZIP has a modification time later than that date, and the host $FILE_NAME creation time agrees. We find the file was created later than the date it bears (established); the earlier core.xml created value appears to have been set by hand (probable).
09Lessons
- The application version string is hard to fake consistently; it often settles a backdating question.
- Use sources an editor cannot easily align (ZIP entry times, version strings, $FILE_NAME) rather than the editable created field alone.
- Date the file, and say clearly that dating the file is not dating the agreement.