Chapter 8 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Bytes and words"]
N2["8.2 FILETIME"]
N3["Lab — decoding a FILETIME"]
N4["8.3 Reading the result"]
N5["8.4 Memory hierarchy"]
N6["8.5 CPU and evidence"]
N7["8.6 Time zones"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Bytes and words"]
N2["8.2 FILETIME"]
N3["Lab — decoding a FILETIME"]
N4["8.3 Reading the result"]
N5["8.4 Memory hierarchy"]
N6["8.5 CPU and evidence"]
N7["8.6 Time zones"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Bytes and words]
|
v
[8.2 FILETIME]
|
v
[Lab — decoding a FILETIME]
|
v
[8.3 Reading the result]
|
v
[8.4 Memory hierarchy]
|
v
[8.5 CPU and evidence]
|
v
[8.6 Time zones]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) explain byte order; (2) decode a Windows FILETIME; (3) relate memory hierarchy to volatility; (4) recognise errors from wrong data interpretation.
8.1 Bytes and words
Computers store multi-byte numbers in a byte order. x86 and most ARM systems in common use are little-endian: the least significant byte comes first. Forensic tools must know the order to read structures correctly.
The 32-bit value 0x12345678 is stored as 78 56 34 12 on a little-endian machine and as 12 34 56 78 on a big-endian one. Network protocols traditionally use big-endian, so a single investigation can involve both orders. Priya's parser takes the byte order as an explicit argument rather than assuming one, and her tests include a structure whose value differs visibly under the two readings.
8.2 FILETIME
Windows records many timestamps as a 64-bit count of 100-nanosecond intervals since 1 January 1601 UTC, stored little-endian. Carrier (2005) describes how file-system structures store such values on disk.
The odd epoch dates from the Gregorian calendar cycle used when the format was designed. Converting means dividing by ten million to get seconds and then adding the result to 1601-01-01. Because the count is in 100-nanosecond units, some file systems store more precision than a display shows, and some tools truncate it. Priya keeps the raw integer in her notes next to the converted date.
Lab — decoding a FILETIME
"""Decode a little-endian Windows FILETIME from synthetic bytes."""
import struct, datetime
raw = bytes.fromhex("00e0c9a3c4d3d901")
ticks = struct.unpack("<Q", raw)[0]
dt = datetime.datetime(1601, 1, 1, tzinfo=datetime.timezone.utc) + datetime.timedelta(microseconds=ticks // 10)
print("raw bytes:", raw.hex())
print("ticks (100 ns):", ticks)
print("UTC:", dt.isoformat())
big = struct.unpack(">Q", raw)[0]
print("misread as big-endian ticks:", big)
Run with python3 lab_filetime.py. Verified output:
raw bytes: 00e0c9a3c4d3d901
ticks (100 ns): 133370505499107328
UTC: 2023-08-21T00:15:49.910732+00:00
misread as big-endian ticks: 63272100002257153
8.3 Reading the result
The eight synthetic bytes decode, little-endian, to 133,370,505,499,107,328 ticks, which is 2023-08-21 00:15:49.910732 UTC. Read big-endian, the same bytes give a meaningless number. Getting byte order wrong produces dates that are plausible-looking garbage or absurd, so tools are validated on known values.
A good validation set covers several kinds of value: a known recent date, the epoch itself (zero ticks), a date before 1970 to catch tools that assume Unix time, and the largest plausible value. Each has an expected output written down in advance. If a tool shows the zero value as 1970 instead of 1601, it has applied the wrong epoch, and every date it reports is shifted by 369 years.
8.4 Memory hierarchy
Registers, cache, RAM and storage differ in speed and persistence. The faster layers are smaller and more volatile, which is why RFC 3227 lists them first in collection order.
Approximate speeds make the point: a register read takes under a nanosecond, cache a few nanoseconds, RAM around a hundred, and an SSD tens of microseconds. Capacity runs the other way. Anything that exists only in the faster, smaller layers disappears within moments of power loss, which is why collection planning starts at the top of the hierarchy.
8.5 CPU and evidence
Running processes, open network connections and encryption keys may exist only in RAM. Memory acquisition must be planned before power-off decisions.
Memory can hold decrypted content of encrypted volumes, injected code that never touched disk, and network connections that have closed but not yet been cleaned up. Capturing it changes the system slightly, because the capture tool itself has to run. The plan records which tool was used, where its output was written and what changes were expected, so the effects of collection can be told apart from evidence.
8.6 Time zones
FILETIME values are UTC; display tools may convert to local time. Reports should state which.
Not every timestamp is UTC. Some FAT file systems store local time without a zone, and some application logs use the device's local setting. Priya's report includes a small table listing each source, how it stores time, and the offset applied. When daylight saving changes during the period of interest, she points out the ambiguous hour explicitly rather than letting the conversion silently choose one reading.
Other epochs
Unix systems count seconds since 1 January 1970 UTC; some formats use other origins or units, such as milliseconds. Priya keeps a reference table of epochs and units and checks every new artefact against a value she sets herself on a test machine before trusting any decoder output in a timeline.
Worked example
A colleague's script shows a file created in year 30,000. Priya checks: the script read the bytes big-endian. Corrected, the date is plausible and matches a second tool.
Synthetic case. The bytes are synthetic.
Errors and limits
A correctly decoded timestamp shows what the system recorded, not necessarily the true time; clocks can be wrong or changed.
Exercises
- EX022 — Decoded time. What UTC time does the lab decode? Rubric: 3 = 2023-08-21 00:15:49.91 UTC; 2 = date only; 1 = wrong; 0 = none.
- EX023 — Year 30,000. What caused the absurd date, and how was it checked? Rubric: 3 = big-endian read; fixed and compared with second tool; 2 = one; 1 = vague; 0 = none.
- EX024 — Recorded vs true. Why might a correct decode still not give the true time? Rubric: 3 = system clock wrong or changed; 2 = partial; 1 = it always does; 0 = none.
Synthesis
Byte order and epochs must be known exactly; validated decoding and stated time zones keep timelines correct.
Continue studying — chapter 08 of 50
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →