170 lines
No EOL
6.4 KiB
Groff
170 lines
No EOL
6.4 KiB
Groff
.TH SECRET 1 "13. October 2025" "ISA Project" "User Commands"
|
||
.SH NAME
|
||
secret \- transfer files via ICMP covert channel
|
||
.SH SYNOPSIS
|
||
.B secret
|
||
.RB \-r
|
||
.I file
|
||
.RB \-s
|
||
.I ip|hostname
|
||
.br
|
||
.B secret
|
||
.RB \-l
|
||
.SH DESCRIPTION
|
||
.B secret
|
||
is a client/server application that transfers files through a covert communication channel embedded within ICMP Echo-Request and Echo-Reply messages. The application encrypts files using AES-256 encryption before transmission, creating a steganographic channel that appears as routine network diagnostics.
|
||
|
||
The application operates in two modes:
|
||
.IP "Client Mode"
|
||
Reads a file, encrypts it, fragments it into ICMP-sized packets, and transmits it to a target host.
|
||
.IP "Server Mode"
|
||
Listens for incoming ICMP packets containing encrypted file data, reassembles and decrypts the data, and saves the file to the current directory.
|
||
|
||
All file data is encrypted using AES-256-CBC with a key derived from the user's login name using PBKDF2 with SHA-256. Each transfer uses a unique initialization vector and salt for security.
|
||
|
||
.SH OPTIONS
|
||
.TP
|
||
.BR \-r " " \fIfile\fR
|
||
Specifies the file to transfer. The file path can be absolute or relative. This option is required for client mode.
|
||
.TP
|
||
.BR \-s " " \fIip|hostname\fR
|
||
Specifies the target IP address or hostname where the file should be sent. This option is required for client mode.
|
||
.TP
|
||
.BR \-l
|
||
Enables server mode. The application will listen for incoming ICMP file transfers and save received files to the current directory. This option cannot be combined with \fB\-r\fR or \fB\-s\fR.
|
||
.TP
|
||
.BR \-h
|
||
Display usage information and exit.
|
||
|
||
.SH PROTOCOL
|
||
The application implements the ICMP-based File Transfer Protocol (IFTP), a custom protocol designed for reliable file transfer over ICMP. Every IFTP packet embeds a 26-byte IFTP header inside the ICMP Echo payload followed by a variable payload (typically 0–1400 bytes).
|
||
|
||
.PP
|
||
.TS
|
||
box;
|
||
l l l l.
|
||
Field Size Offset Description
|
||
_
|
||
Magic Number 4 bytes 0 Protocol identifier (0xDEADBEEF)
|
||
Session ID 2 bytes 4 Unique 16-bit session identifier
|
||
Message Type 1 byte 6 START/DATA/END/ACK/NACK/HEARTBEAT
|
||
Flags 1 byte 7 Bitflags (e.g. COMPRESSED/URGENT/FRAGMENTED/ENCRYPTED)
|
||
Sequence Number 4 bytes 8 Monotonic packet counter (network byte order)
|
||
Fragment Current 4 bytes 12 Zero-based fragment index
|
||
Fragment Total 4 bytes 16 Total fragment count
|
||
Payload Length 2 bytes 20 Length of payload in bytes (0–1400)
|
||
CRC32 4 bytes 22 CRC32 over header + payload (network byte order)
|
||
.TE
|
||
|
||
.PP
|
||
.SS START packet metadata
|
||
The START packet payload carries session initialization metadata required by the receiver: filename (up to 256 bytes), file size (8 bytes), IV (16 bytes) and salt (32 bytes). The server validates the metadata (filename sanitation, size limits) before acknowledging the START.
|
||
|
||
.PP
|
||
.SS Notes
|
||
.IP
|
||
- All multi-byte numeric fields are transmitted in network byte order.
|
||
- The Magic Number MUST be 0xDEADBEEF to identify IFTP traffic.
|
||
- CRC32 covers the IFTP header and payload to detect corruption; checksum failures cause a NACK.
|
||
- Fragment Current / Fragment Total allow reassembly of files that exceed a single ICMP payload.
|
||
- Message types include explicit ACK/NACK responses; NACKs carry an error code in the payload when applicable.
|
||
|
||
.PP
|
||
.SS Transfer Sequence
|
||
.IP "1. Handshake"
|
||
Client sends START packet with file metadata (name, size, encryption parameters). Server responds with ACK.
|
||
.IP "2. Data Transfer"
|
||
Client fragments and encrypts the file, sending DATA packets with sequence numbers. Server acknowledges each packet.
|
||
.IP "3. Completion"
|
||
Client sends END packet. Server finalizes decryption and sends final ACK.
|
||
|
||
.SS Security Features
|
||
.IP "Encryption"
|
||
AES-256-CBC with PBKDF2 key derivation (600,000 iterations)
|
||
.IP "Authentication"
|
||
CRC32 checksums for packet integrity
|
||
.IP "Session Isolation"
|
||
Unique session IDs and cryptographic parameters per transfer
|
||
|
||
.SH EXAMPLES
|
||
.SS Client Examples
|
||
Transfer a text file to a remote host:
|
||
.br
|
||
.B # secret -r document.txt -s 192.168.1.100
|
||
|
||
Transfer a file using relative path with parent directory:
|
||
.br
|
||
.B # secret -r ../test.file -s 192.168.1.100
|
||
|
||
Transfer a binary file using absolute path and hostname:
|
||
.br
|
||
.B # secret -r /path/to/archive.tar.gz -s fileserver.example.com
|
||
|
||
.SS Server Examples
|
||
Start server to listen for incoming transfers:
|
||
.br
|
||
.B # secret -l
|
||
|
||
.SH EXIT STATUS
|
||
.B secret
|
||
exits with status 0 on success, and non-zero on failure.
|
||
|
||
.SH NOTES
|
||
.SS Root Privileges
|
||
This program requires root privileges to create and use raw sockets for ICMP packet manipulation. Run with
|
||
.B sudo
|
||
or as the root user.
|
||
|
||
.SS Network Considerations
|
||
.IP "MTU Handling"
|
||
Files larger than the network MTU (typically 1500 bytes) are automatically fragmented into multiple ICMP packets.
|
||
.IP "Firewall"
|
||
Ensure ICMP traffic is not blocked by firewalls between client and server.
|
||
.IP "IPv4/IPv6"
|
||
The application supports both IPv4 and IPv6 networks automatically based on the destination address.
|
||
|
||
.SS File Handling
|
||
.IP "Output Location"
|
||
Server mode saves received files to the current working directory with their original filenames.
|
||
.IP "Overwrite Behavior"
|
||
Existing files with the same name will be overwritten without warning.
|
||
.IP "Permissions"
|
||
Created files inherit standard permissions based on the current umask.
|
||
|
||
.SH DIAGNOSTICS
|
||
The application provides detailed status information during operation:
|
||
.IP "Client Mode"
|
||
Reports transfer progress, fragment counts, and acknowledgment status.
|
||
.IP "Server Mode"
|
||
Logs incoming connections, session information, and completion status.
|
||
.IP "Error Reporting"
|
||
All errors are reported to standard error with descriptive messages.
|
||
|
||
.SH SECURITY
|
||
.SS Encryption Strength
|
||
Uses industry-standard AES-256 encryption with secure key derivation. The encryption key is derived from the user's login name using PBKDF2 with 600,000 iterations and a random 32-byte salt.
|
||
|
||
.SS Covert Channel Properties
|
||
The ICMP traffic generated by this application closely resembles normal network diagnostic traffic, providing a steganographic communication channel.
|
||
|
||
.SS Limitations
|
||
.IP "Key Distribution"
|
||
Both client and server must run under the same username for successful decryption.
|
||
.IP "Packet Loss"
|
||
The current implementation assumes reliable network delivery and does not implement retransmission for lost packets.
|
||
|
||
.SH FILES
|
||
.TP
|
||
.I /proc/net/icmp
|
||
System ICMP statistics (informational)
|
||
|
||
.SH AUTHOR
|
||
Written by Roman Necas (xnecasr00) for the ISA course project at FIT VUT.
|
||
|
||
.SH SEE ALSO
|
||
.BR ping (8),
|
||
.BR icmp (7),
|
||
.BR openssl (1),
|
||
.BR socket (7)
|
||
|
||
RFC 792 - Internet Control Message Protocol |