YanoSec
Progress0 of 152 lessons complete

Course / 10 Crypto and files / Lesson 14 of 19

What a memory image is

Estimated time: 18 min reading · 16 min activity

RAM is volatile memory used while programs run. A memory image is a copy acquired by a particular method at a particular time. Acquisition means obtaining that copy; the method, time, system and any missing regions affect what later analysis can establish.

Volatility analyzes memory samples to recover artifacts of runtime state. A plugin is a tool component for a particular analysis; it needs compatible input and supporting format/symbol information. The lesson uses a typed three-row process model, not a memory image, so no installation or large dump is required.

Before you begin

Estimated time
18 min reading, 16 min activity. Setup and optional practice may take longer.
Where you work
Read the supplied byte tables and authored records in any browser, with paper or a text editor. Preserve original files; inspect copies in any later lab. No scanner, image decoder, capture, memory acquisition or installation is required. Practical tool work remains separate from this reading activity.
Without a lab
All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.

After this lesson you can:

  • Find the name beside PID 422 in the model.
  • State the acquisition time and that the table was typed.
  • Limit the model to process rows present at that time.

01Example

Fresh snapshot example, separate from the supplied three-process activity.

Authored state at 08:00 UTC:
PID 90: ledger-reader
At 08:05 the process may have ended or changed.
The 08:00 row supports a claim about that modeled capture time.
It is not a complete record of all earlier activity.

02A snapshot holds what was captured

A PID is a process identifier assigned by a system. It identifies a process in its relevant context and time; numbers can be reused later. Read acquisition context before copying a process name.

A process that ended before acquisition or started afterward may not be represented. Capturing memory can be incomplete, and runtime state is not automatically a complete event history. Keep the model’s three names and acquisition time distinct from a real memory-reader result.

Read captured process state as a time-bounded snapshot and state what a small model cannot establish.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Supplied capture-time model

08:00 UTC contains the authored PID 90 ledger-reader row.

Authored 08:00 UTC snapshot

PID 90 in snapshotOriginal: PID 90: ledger-readerNow: PID 90: ledger-readerauthored snapshot

08:05 state

Later process stateOriginal: unknownNow: unknownnot captured

A snapshot supports time-bounded state, not complete history; this is authored state, not memory acquisition.

08:00 UTC contains the authored PID 90 ledger-reader row.

Follow the explanation

  1. 08:00 UTC contains the authored PID 90 ledger-reader row.
  2. 08:05 may differ; the earlier snapshot remains unchanged.
Read every state and value

1. 08:00 UTC contains the authored PID 90 ledger-reader row.

Example
Supplied capture-time model
Items
Value: PID 90: ledger-reader; Status: authored snapshot · Value: unknown; Status: not captured
Active Item
pid
Event Label
08:00 UTC contains the authored PID 90 ledger-reader row.
Visible Limit
A snapshot supports time-bounded state, not complete history; this is authored state, not memory acquisition.

2. 08:05 may differ; the earlier snapshot remains unchanged.

Example
Supplied capture-time model
Items
Value: PID 90: ledger-reader; Status: 08:00 only · Value: unknown: may have ended or changed; Status: not captured
Active Item
current
Event Label
08:05 may differ; the earlier snapshot remains unchanged.
Visible Limit
A snapshot supports time-bounded state, not complete history; this is authored state, not memory acquisition.
A snapshot supports time-bounded state, not complete history; this is authored state, not memory acquisition.

03Find PID 422

Use the printed table acquired in the story at 10:00 UTC on 2026-04-02. The method line explicitly says typed table.

Label: small process-state model. Not a memory image. Not Volatility output.
Acquisition time on the card: 10:00 UTC, 2026-04-02.
Method: typed table. No RAM was copied.

PID 410 name note-reader
PID 422 name lamp-index
PID 438 name clock

The table lists three names present in the model at 10:00.
It does not list earlier logins. It does not list processes that had already ended.

Download the process-state model

  1. Find PID 422 and copy its name, lamp-index, together with the modeled acquisition time.
  2. Compare PID 410, note-reader, to show why the identifier is needed rather than just a name guessed from the example.
  3. Write a bounded claim about the listed process state. Add the limit that neither ended processes nor a complete login history is provided.
  4. Stop after the three-part note: source/method, supported state and limit. Do not acquire RAM or download a public dump.

04Module case

For about fifteen minutes, complete the seven-row module case. For each artifact, identify source/method, one supported observation and one unperformed confirmation. The rows connect signatures, tags, offsets, a text chunk, a typed HTTP body, logs and process state. Preserve the distinction between an original artifact, an authored model and a historical tool record.

Label: ungraded Forensics and steganography module case.
About fifteen minutes. Use the supplied packet and keep the reasoning in notes.

Write one provenance line, one supported clue, and one limit for each row.

1. benign-note.txt is named like a text note. Offset 0 is the PNG signature.
   Supported clue: the leading bytes. Limit: a decoder has not confirmed the image.
2. metadata-table.txt Comment is spare cable. The JPEG file does not hold that tag.
   Supported clue: the card's Comment line. Limit: the DateTime line has no zone and was typed.
3. combined.bin places the PNG signature at offset 5 after NOTE and a line feed.
   Supported clue: the author offset. Limit: scan.txt is not a binwalk transcript.
4. owned-carrier.png contains a tEXt Comment, night lamp, because this lesson put it there.
   Supported clue: that chunk. Limit: other hiding methods were not inspected.
5. stream.txt activity body is ribbon. No capture file exists.
   Supported clue: the typed body. Limit: an encrypted payload without secrets is a different card.
6. On 2026-04-02 UTC, access R-19 is 11:00:09 and the auth ok for R-19 is 11:00:12.
   Supported clue: the order of those two stamps. Limit: the account label is not a person.
7. The memory model at 10:00 lists PID 422 as lamp-index.
   Supported clue: that row. Limit: the table is not every past login.

Stop when the seven limit lines are written. Do not acquire a real image, log, or capture.

Download the forensics module case

05Optional challenge

Spend about ten optional minutes drafting an acquisition form with system, time and timezone, method/tool, original-copy location and known gaps. Leave unobserved fields unknown. This is a planning exercise; it does not authorize copying memory that may contain secrets.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Snapshot card A: independent typed process modelOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Acquisition time in the story: 2026-06-08 14:30 UTC.
Method: typed table; no RAM acquisition or memory tool output.
PID 610 name note-viewer
PID 627 name map-reader
PID 645 name timer
These are modeled rows at the stated time. No earlier process list or login history is supplied.

Two-snapshot card B: separate same-system modelOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Snapshot B1 at 15:00 UTC lists PID 710 worker.
Snapshot B2 at 15:10 UTC does not list PID 710.
Both are typed partial state tables. No intervening events or complete acquisition coverage are provided.

07Explain the evidence and its limit

Optional self-check: draft a snapshot evidence note with system context, acquisition time/zone, source method, PID/name and known gaps.

Review it: distinguish a typed model from a memory image, keep PID meaning tied to time and avoid complete-history or verified-person claims.

08Common mistakes

If a PID seems permanent, attach the capture context and time; the same number can be reused later.

If three process rows become every past login, identify the evidence needed for a complete history and leave it unclaimed.

If the model is called Volatility output, retain its method line: these rows were typed, with no RAM acquisition or plugin run.

References

  • Volatility 3 README

    Official Volatility background describes recovering runtime artifacts from memory samples; no plugin run is required.

  • Volatility 3 documentation

    Official Volatility background describes recovering runtime artifacts from memory samples; no plugin run is required.