Abstract
A Python client/server lab for studying remote-administration architecture in a controlled, authorized environment. It wires together system telemetry, input-event capture, screen recording, and packet-level network observation behind a single dispatch channel, framed as a defensive-security learning artifact rather than a deployment tool.
1. What This Is
I built this as a security-learning prototype to understand how Python client/server administration tooling is structured. The repository includes an explicit legal and ethical warning; I present it here strictly as an architectural study, not an operational guide.
The practical value is defensive: the same primitives—process enumeration, input hooks, screen capture, packet sniffing, remote command execution—appear in both legitimate remote-administration products and malicious software. Understanding the module layout and data flow helps when writing detection rules or hardening endpoints against similar behavior.
2. How It Works
The prototype follows a simple request/response loop. A controller process opens a socket to a target lab machine, sends a named action, and the target dispatches to the matching local module, executes it, and ships the result back. All testing is confined to systems where access is explicitly authorized.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Channel setup | Authorized lab host | Python socket | Persistent client/server connection |
| 02 | Action dispatch | Named command from controller | Protocol handler | Routed to local module |
| 03 | Module execution | Local system state | psutil / pynput / Pillow / scapy | Telemetry, image, keystroke, or packet data |
| 04 | Result return | Module output | Socket channel | Structured payload to controller |
| 05 | Observation | Behavior notes, permission effects | Manual analysis | Detection and hardening findings |
3. Implementation Notes
3.1 System telemetry
psutil provides process lists, CPU/memory usage, and OS metadata. The module returns a flat snapshot; the controller decides what to log or alert on. This is the same data surface a legitimate monitoring agent exposes, which is exactly why it is a useful detection baseline.
3.2 Input and capture
pynput registers keyboard and mouse hooks for controlled input-event logging. Pillow handles screen-grab and webcam-frame capture. Both run only while the lab session is active; no persistence mechanism is implemented.
3.3 Network observation
scapy is used for packet-level experimentation on the lab interface. The goal is to see what a sniffing module can observe and how that overlaps with what a network-monitoring product would flag.
3.4 Command and file transfer
The prototype includes a remote-command stub and a file-transfer path so I could trace how an administration channel coordinates actions and returns results. These are intentionally minimal—no shell, no scripting engine—just enough to understand the round-trip.
4. Constraints
-
Authorized-use only
No persistence, no covert deployment, no unauthorized access. The repo carries an explicit legal warning and I treat it as a hard boundary.
-
No transport security
The socket channel is plaintext with no authentication or encryption. Fine for a single-host lab; it would be trivially intercepted or spoofed on any shared network.
-
Single-target scope
The prototype assumes one controller and one target. There is no multi-host orchestration, load handling, or concurrent-session management.
-
No error recovery or logging
Module failures surface as raw exceptions on the channel. There is no retry logic, structured logging, or graceful degradation—acceptable for a learning artifact, not for production.
5. Next
- a. Add TLS and token-based authentication to the client/server channel so the transport model matches what a real remote-admin product would require.
- b. Write Sigma or YARA detection rules for the telemetry, input-hook, and packet-sniffing patterns exercised in the lab, to close the loop between offense and defense.
- c. Document the permission-model differences between Windows and Linux for each module (admin vs. user, kernel vs. userspace hooks) so the lab findings transfer to cross-platform hardening guidance.
— end of report —