skip to content

In Wireshark, how do you carve an executable a host downloaded over plain HTTP out of a capture, and when will Export Objects miss it?

level: middleimportance: must knowfreq 30%

answer

  1. a menu, not copy and paste
  2. built from reassembled bodies
  3. filename comes from the URI
  4. encrypted, partial or undecodable bodies
  5. tshark can do it in bulk

basics

~20 s

File > Export Objects > HTTP lists each HTTP body Wireshark reassembled; Save writes the bytes out for hashing. Bodies inside undecrypted TLS never appear, and bodies with missing segments or an encoding Wireshark cannot decompress come out truncated or absent.

solid answer

~50 s

Open the capture, optionally isolate the download with `http.request` or its `tcp.stream`, and use **File > Export Objects > HTTP**. The list shows packet number, hostname, content type, size and a filename taken from the last part of the URI; **Text Filter** narrows it, **Save** writes one object and **Save All** writes every one. In bulk, `tshark --export-objects http,<dir>` does the same. Hash the result and examine it only in a sandbox. Export Objects sees only what the HTTP dissector reassembled: if the capture lacks segments the body is truncated or absent, and HTTPS shows nothing until Wireshark can decrypt it. A gzip or brotli body is saved decompressed; in Wireshark 4.6, one it cannot decompress, or any encoded body while **Uncompress entity bodies** is off, is not listed. The filename and content type are the client's and server's claims, not a verdict on the bytes.

code

bash · 3 lines
bash
mkdir -p ./carved
tshark -r incident-0412.pcapng -q --export-objects http,./carved
sha256sum ./carved/*

go deeper

for a junior

Recall the menu path File > Export Objects > HTTP, the columns it shows, and that Save writes the object to disk.

for a middle

Explain that the list is built from reassembled bodies, why HTTPS, missing segments and undecodable encodings leave objects out, and how tshark --export-objects does it in bulk.

for a senior

Show that you treat the filename and content type as claims, hash before handling, and check the capture is complete before relying on a carved file.

for a principal

Decide where carving belongs in an incident process: who may handle carved malware, where it is examined, and what stays attached to it as evidence.

## What Export Objects does A file sent over HTTP crosses the wire as the **body** of a response, split across many TCP segments. **Export Objects** scans the dissected traffic of one protocol and lists every object the dissector rebuilt, so you can write it to disk without stitching bytes together by hand. In a suspicious-download investigation it turns "the host fetched something from that server" into a file you can hash and examine. ## Carving the download 1. Open the capture and, if it is large, narrow the view first: `http.request` shows the requests, and the download's `tcp.stream eq N` isolates its connection. 2. Choose **File > Export Objects > HTTP**. With a live capture running, the list refreshes every few seconds. 3. Find the object by packet number, hostname, content type, size or filename; type part of a name into **Text Filter** to narrow the list. 4. Press **Save** for one object, which proposes the name from the Filename column, or **Save All** to write every object into a folder. 5. Record the packet number, stream index and hash next to the file, so someone else can find the same object in the same capture. ## Reading the list | Column | What it holds | What it does not prove | |---|---|---| | Packet | The frame in which the object was found | Not the first frame of the transfer | | Hostname | The host named in the request | Not which server actually answered | | Content Type | The `Content-Type` the server sent | Not what the bytes really are | | Size | The size of the object in bytes | Not that the transfer completed | | Filename | For HTTP, the final part of the request URI | Not the name the client saved it under | A file called `invoice.pdf` served as `application/pdf` can be an executable; check the first bytes and the hash, not the row. ## When the object is missing or wrong - **Encrypted traffic.** Over HTTPS the HTTP bodies are inside TLS records. Nothing is listed until Wireshark can decrypt the session, which needs the session's key material. - **Missing segments.** The body is rebuilt from what the capture holds. A capture that dropped segments or started mid-transfer gives a truncated object or none. - **Reassembly switched off.** The HTTP body is collected through TCP and HTTP reassembly, on by default. Turned off, bodies show as Continuation data and objects are lost or cut short. - **Content encoding.** With **Uncompress entity bodies** on, the default, a gzip, deflate or brotli body is saved **decompressed**. If Wireshark cannot decompress it, or that preference is off, Wireshark 4.6 does not send the encoded body to Export Objects at all. - **A response without its request.** If the capture missed the request, the body can still be listed, but without a hostname or filename; match it by packet number and stream instead. - **Size is what was rebuilt.** The Size column counts the bytes Wireshark holds for the object, not the length the server announced, so a listed row is not proof of a complete transfer. ## Other protocols in the same menu The Export Objects menu also covers DICOM, FTP-DATA, IMF, SMB and TFTP, and HTTP/2 bodies appear in the HTTP list. Each dissector has its own conditions: | Protocol | Filename comes from | What the capture must contain | |---|---|---| | HTTP, HTTP/2 | The last part of the request URI | The reassembled body, decrypted if it ran over TLS | | SMB | The file the client opened | The file being opened on that connection, or Wireshark cannot tell which file the data belongs to | | TFTP | The read or write request | The request and every data block, with none missing, up to the last block | | IMF | The subject of the email | The captured message | ## Carving in bulk and handling the result `tshark` writes every object of a protocol into a directory with `--export-objects <protocol>,<destdir>`, and `--export-objects help` lists the protocol names. Duplicate filenames are not overwritten; a number is added before the extension. - Hash every carved file at once, before anyone opens it. - Examine executables only in an isolated analysis environment, never on the workstation that holds the capture. - Keep the capture beside the carved file; the object proves nothing without the traffic it came from. Evidence handling and integrity proof are a forensics subject of their own.

  • Why can the file you export from Wireshark differ from the bytes that crossed the wire even when the capture is complete?
    Export Objects saves the decoded entity body: chunked transfer coding removed and, with 'Uncompress entity bodies' on, gzip, deflate or brotli content encoding undone. That is what the client application received, not the literal wire bytes. When you need the wire bytes, use Follow TCP Stream and save the Raw view instead.
  • How do you get a file out of a capture when it was copied over SMB or TFTP instead of HTTP?
    Use the same menu, File > Export Objects > SMB or TFTP. For SMB, Wireshark must have seen the file being opened on that connection to know which file the data belongs to. For TFTP, it needs the request naming the file and every data block through the last, with none missing.

saying these in an interview costs you the question

  • Export Objects identifies a file's type by inspecting its contents.
  • If Export Objects lists a file, the capture holds every byte of it.
  • Export Objects can pull files out of HTTPS traffic without any key material.
  • The exported file is the gzip-encoded body exactly as it crossed the wire.
  • A carved executable is safe to open on the analyst's own workstation.