Lesson 5.1 · Commands and communications· 2 min read
Messages, protocols, and data movement
Separate transport, message structure, command selection, collection, and transfer when studying communications code.
- Platform:
- Cross-platform
- Language:
- Concepts
- Difficulty:
- Intermediate
What you will learn
Separate transport, message structure, command selection, collection, and transfer when studying communications code.
Before you begin: Configuration and serialization; command dispatch tables.
Several boundaries sit behind one message
A communication-capable program combines different responsibilities: representing a message, moving it, interpreting it, selecting work, and handling a result. Studying one function in isolation can blur those boundaries. Start by naming which responsibility the function owns and which it delegates.
MITRE's Command and Control overview describes adversary communication with controlled systems. The teaching model here stops at a local message record. It contains no transport, listener, remote handler, shell invocation, or executable task.
A local message record
{
"version": 1,
"message_id": "example-001",
"kind": "demonstration-result",
"body": {"label": "finished"}
}Read the fields as separate claims. A version identifies a representation contract. An identifier can associate records. A kind names the expected body shape. None of those fields authenticates the sender or proves delivery. The label is just text until some consumer interprets it.
Transport is not the application protocol
A report that mentions a transport does not fully describe the messages carried over it. The application still needs to define message boundaries, valid structures, meaning, and errors. Conversely, reading a message parser does not prove that a particular transport is used in the build under discussion.
When examining retries and scheduling, distinguish an attempted send, a completed transfer, and an acknowledged application result. A repeated record could represent retransmission rather than repeated execution. You need the implementation's state and acknowledgement rules before deciding which interpretation fits.
Collection, staging, and transfer
Collection means obtaining data; staging means preparing or retaining it for a later step; transfer moves it across a boundary. Those activities may be implemented separately. A buffer containing data is evidence of that buffer, not proof that its contents left the host. A network operation alone does not establish which application data it carried.
For a source study, draw the data flow from producer to serializer to any transport boundary and finally to the result consumer. Mark unobserved links as unknown. This approach supports a careful explanation of exfiltration-related capabilities without treating all network code as data theft.
Exercise
A local record says finished, but the send function returns an error. What can you conclude about processing and delivery? What if a second identical record appears later?
Check your understanding
The text alone establishes neither processing success nor delivery. A repeated record could be retried data or new work. Compare identifiers, call paths, and result handling before choosing an explanation. Keep the uncertainty explicit in the behavior map.