The defence counsel for Aaron Caffrey, who is on trial at Southwark Crown Court, had said that his client's computer could have been compromised by a hacker who had altered the system's log files -- which record how the machine is being used -- and staged an attack from the teenager's computer.
But Professor Neil Barrett, technical director at Information Risk Management and an expert witness at the trial, told the court that after examining the physical location of data blocks on Caffrey's computer, there was no evidence that the log files had been altered at a later date.
"If you edit a file after you finish writing it to disk, it results in block fractures. The block that corresponds to the edited text would be written elsewhere. The disk blocks that correspond to this file show no evidence of fracturing and were sandwiched between files that were created before and after it," Barrett told the court.
Barrett conceded that a hacker could, in theory, have planted a different log file on Caffrey's computer, but said it would be obvious that it was inserted later because of the physical position of the file's data blocks. "There is obviously a way of introducing (the file) on the computer, but not in the correct place," he said.
Caffrey's counsel questioned the validity of Barrett's evidence because the witness had not physically examined the actual hard disk from Caffrey's computer, but an image of it that was sent to him on CD-ROM. Barrett argued that this did not make a difference because the image was "forensically sound".
The case continues.
Talkback
Fire this expert.
THe log file would not be fractured if
1) the log file got shorter, or
2) the device file was edited.
Besides, windows protects its event logger.
The log file can only be modified by
editing the disk, there would be no trace.
Windows doesn't do nearly enough to "protect" syslogs, assuming that logging has been enabled and properly configured to begin with.
Best Practices call for active, ongoing archival of individual system syslogs to at least one known-to-be-secure repository system that is not the generator of the original logfiles. You then test for tampering by comparing the (various) archived copies, as a time series of data, against one another. That's where you look for and perhaps find syslog discrepancies.
Given syslogs residing on the very same system that generated them, any number of things could happen to those log files... not the least of which could be filesystem defragmentation, which can and does fully defrag syslogs (provided that the event logging service is taken offline and/or redirected to write to a different set of target files and/or that the defrag occurs before GUI boot).
More compelling evidence would be the presence/absence of significant time gaps in syslog entries (indicating rather inept syslog deletions) and/or syslog entry forgeries (attempting to cover the deletions of legitimate entries).
This "expert"'s so-called block/sector-level analysis of the disk blocks/sectors on which the log files were eventually found to reside, at least as described and (probably) summarized in the article, leaves too much to be desired. It make this expert sound too "block-headed" to be believed, let alone to convict on.
Direct editing of a so-called file, using a disk-level binary editor, would not necessarily "fracture" unfractured blocks, but it would require artful and precise forgeries to cover time gaps created by deleted entries.
Surely any image taken from a hard drive would be subject to defragmentation as part of the imaging process? Is the actual drive still available for examination?
A true sector-level disk image, with no "dead-space" skipping and no "image compression" should almost preserve the exact sector-level state of the original drive, as long as the orignal drive was properly mounted for forensic analysis (absolutely no external write capabilities).
But there are possible, and potentially serious exceptions...
I do not know how hardware-level bad sector sparing would be copied and/or missed by COTS sector-level disk imaging tools.
I believe most COTS tools simply skip already mapped "bad sectors" and also slip-stream in any on-the-fly "spare sectors," swapped in (by hardware), for bad/failing sectors .
Did the examiners:
- mount the original disk on a *hardware* disk duplicating device, with read-only capability
- temporarily disable all error correction on the original disk prior to taking a duplicate image TO A ZERO-MEDIA-DEFECT DUPLICATE of the original disk (make, model, factory & firmware revision)
- duplicate the internal sector-sparing tables from the original disk
- then manually reconstruct the same sector-sparing tables on the zero-defect duplicate disk
???...
I can't think of any other way to identically duplicate the original disk, if one is going to convict over arguments of contiguous and/or non-contiguous disk blocks/sectors.
An image recorded to CDROM or DVD could not possibly be an exact sector-level duplicate of the original disk, unless the original disk, itself was also a CDROM or DVD.