SECRET(1)

NAME
secret - transfer files via ICMP covert channel

SYNOPSIS
secret -r file -s ip|hostname
secret -l

DESCRIPTION
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:

Client Mode
    Reads a file, encrypts it, fragments it into ICMP-sized packets, and transmits it to a target host.

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.

OPTIONS

-r file
    Specifies the file to transfer. The file path can be absolute or relative. This option is required for client mode.

-s ip|hostname
    Specifies the target IP address or hostname where the file should be sent. This option is required for client mode.

-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 -r or -s.

-h  Display usage information and exit.

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).

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)

  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.

  Notes

    - 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.

  Transfer Sequence

1. Handshake
    Client sends START packet with file metadata (name, size, encryption parameters). Server responds with ACK.

2. Data Transfer
    Client fragments and encrypts the file, sending DATA packets with sequence numbers. Server acknowledges each packet.

3. Completion
    Client sends END packet. Server finalizes decryption and sends final ACK.

  Security Features

Encryption
    AES-256-CBC with PBKDF2 key derivation (600,000 iterations)

Authentication
    CRC32 checksums for packet integrity

Session Isolation
    Unique session IDs and cryptographic parameters per transfer

EXAMPLES

  Client Examples
Transfer a text file to a remote host:
# secret -r document.txt -s 192.168.1.100 Transfer a file using relative path with parent directory:
# secret -r ../test.file -s 192.168.1.100 Transfer a binary file using absolute path and hostname:
# secret -r /path/to/archive.tar.gz -s fileserver.example.com

  Server Examples
Start server to listen for incoming transfers:
# secret -l

EXIT STATUS
secret exits with status 0 on success, and non-zero on failure.

NOTES

  Root Privileges
This program requires root privileges to create and use raw sockets for ICMP packet manipulation. Run with sudo or as the root user.

  Network Considerations

MTU Handling
    Files larger than the network MTU (typically 1500 bytes) are automatically fragmented into multiple ICMP packets.

Firewall
    Ensure ICMP traffic is not blocked by firewalls between client and server.

IPv4/IPv6
    The application supports both IPv4 and IPv6 networks automatically based on the destination address.

  File Handling

Output Location
    Server mode saves received files to the current working directory with their original filenames.

Overwrite Behavior
    Existing files with the same name will be overwritten without warning.

Permissions
    Created files inherit standard permissions based on the current umask.

DIAGNOSTICS
The application provides detailed status information during operation:

Client Mode
    Reports transfer progress, fragment counts, and acknowledgment status.

Server Mode
    Logs incoming connections, session information, and completion status.

Error Reporting
    All errors are reported to standard error with descriptive messages.

SECURITY

  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.

  Covert Channel Properties
The ICMP traffic generated by this application closely resembles normal network diagnostic traffic, providing a steganographic communication channel.

  Limitations

Key Distribution
    Both client and server must run under the same username for successful decryption.

Packet Loss
    The current implementation assumes reliable network delivery and does not implement retransmission for lost packets.

FILES

/proc/net/icmp
    System ICMP statistics (informational)

AUTHOR
Written by Roman Necas (xnecasr00) for the ISA course project at FIT VUT.

SEE ALSO
ping(8), icmp(7), openssl(1), socket(7) RFC 792 - Internet Control Message Protocol