YanoSecA packet capture records traffic visible at a particular place and time. Triage means selecting the evidence that can answer a question. Reassembly puts captured pieces into a connection’s byte order; a stream view can then display those bytes. An HTTP object is content carried in a message body, such as a file.
This lesson supplies typed request/response fragments, not a capture. Cleartext is directly readable data. TLS encryption conceals application content unless suitable decryption material is available. A stream tool cannot assume plaintext merely because a connection carries web traffic.
Before you begin
- Recommended first
- Hex, Base64, and XOR in code, Encoding, hashing, and encryption, Notes: scope, command, result, time, Steganography, and the first checks
- Estimated time
- 15 min reading, 15 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:
- Select the activity stream and read its response body.
- Record that the body was typed, not exported from a capture.
- Require secrets before treating an encrypted payload as a recoverable object.
01Example
Worked typed cleartext fragment. It illustrates input and body without claiming a capture or a complete HTTP transcript.
Request: GET /seal.txt
Declared response body: seal
Interpretation: this model supplies four ASCII body bytes.
No packet capture, decryption or object export is represented.02Export needs the bytes to be present
A cleartext fragment that supplies a body lets you read that body. An encrypted payload without suitable secrets does not let you read the same content. Decryption material means relevant keys or session secrets; which material works depends on the negotiated protocol and configuration.
A real capture may also omit packets or begin after an exchange, preventing full reconstruction even for unencrypted traffic. The typed activity deliberately supplies six body bytes, so its reasoning is complete on paper. No pcap or pcapng file exists for this lesson, and its fragments are not ready-to-transmit complete messages.
Choose the relevant connection and distinguish visible HTTP bytes from encrypted data requiring secrets.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Playback is optional. Step through at your own pace.
Declared request
GET /seal.txtdeclared requestNo request was sent.Declared response body
sealdeclared response bodySupplied ASCII byte positions
73 — sbody byte 065 — ebody byte 161 — abody byte 26c — lbody byte 3The model explicitly declares the response body seal.
Follow the explanation
- The model explicitly declares the response body seal.
- The declared body corresponds to four ASCII byte positions.
Read every state and value
1. The model explicitly declares the response body seal.
- Example
- Supplied teaching sample
- Visible Item
- GET /seal.txt · body
- Current mappings
- None
- Annotations
- Item: GET /seal.txt; Text: No request was sent.
2. The declared body corresponds to four ASCII byte positions.
- Example
- Supplied teaching sample
- Visible Item
- GET /seal.txt · body · 73 — s · 65 — e · 61 — a · 6c — l
- Current mappings
- Four declared ASCII bytes
- Annotations
- Item: body; Text: No capture, decryption or export is represented.
03Read the activity body
Use the activity stream to /ribbon.txt. It is different from the worked /seal.txt fragment.
Label: original fictional cleartext HTTP. Not a Wireshark export. No packet was captured.
Worked stream: 192.0.2.10:12345 to 192.0.2.20:80
GET /seal.txt HTTP/1.1
Host: lamp.example
Response body: seal
Activity stream: 192.0.2.10:12346 to 192.0.2.20:80
GET /ribbon.txt HTTP/1.1
Host: lamp.example
HTTP/1.1 200 OK
Content-Length: 6
Response body: ribbon
Addresses are documentation addresses. Do not contact them.
Label: the activity object from stream.txt.
Body bytes, as letters: ribbon
Six bytes. Provenance: typed into the fictional stream. Not extracted from a capture file.
Label: capture gap.
No pcap or pcapng was written for this lesson.
stream.txt and object.txt are the complete evidence for the cleartext activity.
The question about an encrypted payload is a separate card in the lesson text.
No key log was created.
- Find GET /ribbon.txt and copy its destination and path as labels from the fictional stream. The documentation addresses are not targets to contact.
- Read its declared Content-Length: 6 and body ribbon. Count the six ASCII letters; the body and length agree in this model.
- Record the source as typed cleartext. Leave capture reconstruction and export unperformed; object.txt repeats the authored body rather than proving an extraction.
- Stop with this content-and-provenance note. Do not capture traffic or collect browser secrets.
04Optional challenge
For about ten optional minutes, draw a name-lookup record followed by a separate TCP connection record in the fictional story. Label the lookup’s job as finding an address and the later HTTP body as application content. Neither a name lookup nor a port number alone establishes the object’s bytes.
05Fresh 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.
Stream card A: independent fictional typed cleartextOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
All addresses are documentation labels; no lookup or connection is permitted. No capture exists for this card.
S1: 192.0.2.31:42001 → 192.0.2.80:80; GET /cedar.txt; body birch.
S2: 192.0.2.31:42002 → 192.0.2.80:80; GET /cedar.txt; body cedar.
S3: 192.0.2.31:42002 → 192.0.2.80:80; GET /elm.txt; body elm.
Task constraints: select source port 42002 and request path /cedar.txt together. Each labeled row is one declared exchange.
Encrypted card B: independent gapOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A separate actual encrypted payload is described, but no relevant keys or session secrets are supplied. Its plaintext and complete reconstructed application stream are not provided. No decryption is performed.
Incomplete card C: separate cleartext gapOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A saved capture is described as starting after a response began. A few cleartext body fragments are present, but the earlier body bytes are missing.
06Explain the evidence and its limit
Optional self-check: identify an exchange by fields, cite its supplied body and write a provenance and completeness limit.
Review it: distinguish typed examples from captures, keep unrelated streams separate, and require suitable secrets and sufficient bytes before claiming an encrypted object export.
07Common mistakes
If every web connection seems exportable as plaintext, identify whether the supplied data is cleartext and whether relevant secrets are present.
If an object has fewer bytes than expected, keep capture completeness and message boundaries as possible gaps; do not invent missing content.
If the body card is called a capture export, preserve its actual origin: it was typed as part of the teaching model.
References
- Wireshark TLS wiki
TLS decryption guidance explains why suitable secrets and compatible traffic are needed.
- Wireshark user guide
TLS decryption guidance explains why suitable secrets and compatible traffic are needed.