encapsula

v1.2.0

Published

2 months ago

Terminal-based steganography tool for hiding encrypted messages in files using AES-256 encryption

Downloads

🔐 Encapsula

Terminal-Based Steganography & Encryption Tool

Hide encrypted messages inside any file — invisibly.

Features • Installation • How It Works • Security • Roadmap

📋 Table of Contents

🎯 Overview

Encapsula is a terminal-based steganography tool that combines AES-256-GCM authenticated encryption with adaptive LSB steganography to hide secret messages inside ordinary files. Unlike traditional encryption that produces obvious encrypted files, Encapsula embeds your encrypted data within existing files (images, documents, executables, etc.), making the presence of hidden data nearly undetectable.

Why Encapsula?

🔒 Authenticated Encryption: AES-256-GCM with built-in integrity verification
🧠 Adaptive Key Derivation: scrypt with memory-adaptive parameters (up to 2^15)
👁️ Invisible Storage: Messages hidden within normal files using LSB steganography
🎨 Multi-Format Support: PNG (LSB), JPEG (APP15), WebP (custom chunk), generic (trailer)
🔀 Randomized Embedding: HMAC-based PRNG for secure pixel positioning in PNGs
🚫 Zero Password Storage: Passwords never saved to disk
💻 Beautiful Terminal UI: Interactive command-line interface with progress tracking
🎯 Simple Workflow: Upload → Message → Password → Done

✨ Features

| Feature | Description | |---------|-------------| | AES-256-GCM Encryption | Authenticated encryption providing both confidentiality and integrity | | scrypt Key Derivation | Memory-hard KDF with adaptive N (2^12 to 2^15) for brute-force resistance | | LSB Steganography | Least Significant Bit embedding in PNG images with randomization | | Multi-Format Embedding | PNG (LSB), JPEG (APP15 marker), WebP (chunk), generic files (trailer) | | Authenticated Encryption | GCM mode provides cryptographic verification of data integrity | | Random Salt & IV | Per-file cryptographic randomness prevents pattern analysis | | Adaptive Parameters | Automatically adjusts to available system memory | | Multi-line Messages | Support for complex, formatted secret messages | | Interactive TUI | Terminal-based user interface with real-time progress tracking | | Cross-Platform | Works on Windows, macOS, and Linux | | Secure Memory Handling | Passwords cleared from memory after use | | Auto-Download | Encoded files automatically copied to Downloads folder |

📦 Installation

NPX (Recommended - No Installation)

npx encapsula

Global Installation

npm install -g encapsula
encapsula

From Source

git clone https://github.com/admin12121/Encapsula.git
cd Encapsula
npm install
npm run build
npm start

Requirements

Node.js 20 or higher
Terminal with ANSI color support
Minimum 128MB free RAM (512MB recommended for optimal scrypt parameters)

🚀 Quick Start

Encoding (Hiding a Message)

Launch Encapsula
```
npx encapsula
```
Navigate to Encode Tab (Press Tab key)
Upload Host File (Press Enter)
- Select any file (PNG, JPEG, WebP, PDF, video, etc.)
- For best steganography: use PNG images
Enter Secret Message
- Type your multi-line message
- Press Ctrl+S when finished
Set Password
- Enter a strong password (minimum 8 characters recommended)
- Press Enter
Done!
- Encoded file saved to Downloads folder
- Original file remains unchanged

Decoding (Retrieving a Message)

Navigate to Decode Tab (Press Tab)
Upload Encoded File
Enter Password (same as encoding)
View Decrypted Message
- Message displayed on screen
- Optionally saved to .dec.txt file

🔍 How It Works

Encapsula uses a three-layer security approach: key derivation for password hardening, authenticated encryption for confidentiality and integrity, and steganography for concealment.

Encoding Process Flowchart

┌─────────────────────────────────────────────────────────────────┐
│                        ENCODING WORKFLOW                         │
└─────────────────────────────────────────────────────────────────┘

    ┌──────────────┐
    │  User Input  │
    │  (Message +  │
    │  Password)   │
    └──────┬───────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  1. Generate Random Salt & IV            │
    │     • Salt: 16 random bytes              │
    │     • IV: 12 random bytes (GCM)          │
    │     • crypto.randomBytes() - CSPRNG      │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  2. Key Derivation (scrypt)              │
    │     • Password + Salt → scrypt KDF       │
    │     • Adaptive N: 2^15 → 2^12 (512MB mem)│
    │     • Parameters: r=8, p=1               │
    │     • Output: 32-byte AES-256 key        │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  3. Authenticated Encryption (AES-GCM)   │
    │     • Algorithm: AES-256-GCM             │
    │     • Input: plaintext message           │
    │     • Output: ciphertext + 16-byte tag   │
    │     • Tag verifies integrity             │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  4. Build 60-Byte Header                 │
    │     • Magic: "ECAP" (4)                  │
    │     • Version, flags, params (8)         │
    │     • Payload length (4)                 │
    │     • KDF params: kdf, logN, r, p (4)    │
    │     • Salt (16), IV (12), Tag (16)       │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  5. Format-Specific Embedding            │
    │                                          │
    │  ┌─ PNG: LSB Steganography              │
    │  │  • Header: LSB in first N pixels     │
    │  │  • Payload: randomized LSB positions │
    │  │  • HMAC-PRNG shuffles pixel indices  │
    │  │  • 1-2 bits per RGB channel          │
    │  │                                       │
    │  ┌─ JPEG: APP15 Marker Segment          │
    │  │  • Insert after SOI marker           │
    │  │  • Header + ciphertext in marker     │
    │  │                                       │
    │  ┌─ WebP: Custom Chunk                  │
    │  │  • Insert as WebP chunk              │
    │  │  • Follows WebP RIFF structure       │
    │  │                                       │
    │  └─ Other: Trailer Append                │
    │     • Signature: "ECAPTR" (6)           │
    │     • Length (4) + Header + Ciphertext  │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────┐
    │  Output File │
    │  (Carrier +  │
    │   Hidden)    │
    └──────────────┘

Decoding Process Flowchart

┌─────────────────────────────────────────────────────────────────┐
│                        DECODING WORKFLOW                         │
└─────────────────────────────────────────────────────────────────┘

    ┌──────────────┐
    │ Encoded File │
    └──────┬───────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  1. Detect Carrier Type & Extract Data   │
    │                                          │
    │  ┌─ PNG: LSB Extraction                 │
    │  │  • Read header from LSB bits         │
    │  │  • Parse randomization flag          │
    │  │  • Extract payload using HMAC-PRNG   │
    │  │                                       │
    │  ┌─ JPEG: Find APP15 Marker             │
    │  │  • Scan for APP15 segment            │
    │  │  • Extract header + ciphertext       │
    │  │                                       │
    │  ┌─ WebP: Find Custom Chunk             │
    │  │  • Parse WebP structure              │
    │  │  • Extract chunk data                │
    │  │                                       │
    │  └─ Other: Find Trailer                 │
    │     • Search for "ECAPTR" signature    │
    │     • Read length, extract payload     │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  2. Parse 60-Byte Header                 │
    │     • Verify magic: "ECAP"               │
    │     • Check version compatibility        │
    │     • Extract: salt, IV, tag, params     │
    │     • Read payload length                │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  3. Key Derivation (scrypt)              │
    │     • User password + extracted salt     │
    │     • Use stored logN, r, p parameters   │
    │     • Must match encoding key exactly    │
    │     • Output: 32-byte AES key            │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────────────────────────────────┐
    │  4. Authenticated Decryption (AES-GCM)   │
    │     • Use extracted IV and tag           │
    │     • Decrypt ciphertext                 │
    │     • Verify authentication tag          │
    │     • Fails if tampered/wrong password   │
    └──────┬───────────────────────────────────┘
           │
           ▼
    ┌──────────────┐
    │   Original   │
    │   Message    │
    │  (Plaintext) │
    └──────────────┘

Encryption Details

🔑 Key Derivation (scrypt)

Encapsula uses scrypt, a memory-hard key derivation function designed to resist hardware-accelerated brute-force attacks:

Password (User Input)
    ↓
Random 16-byte Salt (per file)
    ↓
scrypt(password, salt, N, r, p)
  • N = 2^logN (adaptive: 2^15 to 2^12)
  • r = 8 (block size)
  • p = 1 (parallelization)
  • maxmem = 512MB
    ↓
32-byte AES-256 Key

Why scrypt over PBKDF2?

Memory-Hard: Requires significant RAM, making GPU/ASIC attacks expensive
Adaptive: Automatically reduces N on memory-constrained systems
Strong Default: N=2^15 (32,768 iterations) is ~32x stronger than typical PBKDF2
Time-Memory Tradeoff: Attackers cannot trade time for memory

Adaptive Algorithm:

Try N = 2^15 (preferred)
  ↓
If memory error → reduce to 2^14
  ↓
If memory error → reduce to 2^13
  ↓
Continue until success (minimum 2^12)

The chosen logN is stored in the header, ensuring proper decryption.

🔐 AES-256-GCM Authenticated Encryption

Encapsula uses AES-256-GCM (Galois/Counter Mode), providing both confidentiality and integrity:

Plaintext Message + Random 12-byte IV + 32-byte Key
    ↓
AES-256-GCM Encryption
    ↓
Ciphertext + 16-byte Authentication Tag

AES-256-GCM Properties:

Block Cipher: AES with 256-bit key
Mode: Galois/Counter Mode (authenticated encryption)
IV Size: 12 bytes (96 bits) - optimal for GCM
Tag Size: 16 bytes (128 bits) - prevents tampering
Authentication: Tag cryptographically verifies data integrity

Security Benefits:

✅ Confidentiality: Message content hidden from adversaries
✅ Integrity: Detects any modification to ciphertext
✅ Authenticity: Verifies data hasn't been tampered with
✅ No Padding Oracles: GCM is a stream cipher mode
✅ Parallel Processing: Faster than CBC mode

Steganography Methods

Encapsula adapts its embedding strategy based on file type:

📸 PNG: LSB Steganography with Randomization

For PNG images, Encapsula uses Least Significant Bit (LSB) embedding with optional randomization:

Basic LSB Embedding:

Original Pixel: RGB(11010110, 10110011, 01011010)
                    ↓       ↓       ↓
Embed 3 bits (1,0,1):
Modified Pixel: RGB(11010111, 10110010, 01011011)
                         ↑         ↑         ↑
                    (LSB changed to match data bits)

Randomized Positioning (FLAG_RANDOMIZED):

Generate HMAC-based PRNG from password
Shuffle pixel indices pseudo-randomly
Embed bits in shuffled order
Decoder uses same PRNG to reconstruct order

Capacity Calculation:

Header: 60 bytes × 8 bits = 480 bits (stored in first 480 LSBs)
Payload: Remaining RGB bytes × bits_per_channel
  • 1 bit/channel: capacity = (pixels × 3) - 480 bits
  • 2 bits/channel: capacity = (pixels × 6) - 480 bits

Example: 1920×1080 PNG (2,073,600 pixels)

1-bit mode: ~776 KB capacity
2-bit mode: ~1.5 MB capacity

📷 JPEG: APP15 Marker Segment

JPEG format allows custom application-specific marker segments:

JPEG Structure:
[SOI][APP0 (JFIF)][...image data...][EOI]
          ↓
[SOI][APP15 (Encapsula)][APP0][...image data...][EOI]
       ↑
    Header + Ciphertext stored here

Advantages:

✅ Standard JPEG structure maintained
✅ Most viewers ignore unknown markers
✅ No visual artifacts
✅ Fast extraction (no pixel processing)

🎞️ WebP: Custom Chunk

WebP uses a chunk-based RIFF container format:

WebP Structure:
RIFF[size][WEBP][VP8 ...][ALPH ...][EXIF ...]
                              ↓
RIFF[size][WEBP][VP8 ...][ECAP (Encapsula)][ALPH ...]
                           ↑
                    Custom chunk with payload

📄 Generic Files: Trailer Append

For files without format-specific embedding:

[Original File Content][EOF]
                         ↓
[Original File Content][ECAPTR][Length][Header][Ciphertext][ECAPTR]
                         ↑                                     ↑
                   Start signature                       End signature

Trailer Structure:

Offset  | Size     | Description
--------|----------|-------------------------------------------
0       | 6 bytes  | Signature: "ECAPTR" (Encapsula Trailer)
6       | 4 bytes  | Payload length (Big Endian UInt32)
10      | 60 bytes | Header (salt, IV, tag, params)
70      | N bytes  | Ciphertext
70+N    | 6 bytes  | End signature: "ECAPTR"

Why This Works:

Most programs ignore trailing data after EOF
PDFs, executables, videos remain functional
Large capacity (limited only by filesystem)
Fast extraction via signature search

🛡️ Security Analysis

What Makes It Secure

| Security Feature | Implementation | Benefit | |-----------------|----------------|---------| | AES-256-GCM | Authenticated encryption with 256-bit keys | Quantum-resistant symmetric encryption | | Random IVs | crypto.randomBytes(12) per message | Prevents pattern analysis and replay attacks | | Random Salts | crypto.randomBytes(16) per file | Prevents rainbow table attacks | | scrypt KDF | Memory-hard with adaptive N (2^12–2^15) | Resists GPU/ASIC brute-force attacks | | Authentication Tag | 128-bit GCM tag | Detects tampering and wrong passwords | | No Password Storage | Cleared from memory post-use | No plaintext password leakage | | Steganographic Concealment | Hidden within normal files | Reduces detection probability | | Randomized Embedding | HMAC-PRNG for PNG positioning | Prevents statistical analysis | | Adaptive Security | Adjusts to system capabilities | Balances security and compatibility |

Cryptographic Strength

Key Space:

AES-256: 2^256 possible keys (~10^77)
Brute force time: Billions of years with current technology

scrypt Parameters (N=2^15, r=8, p=1):

Memory required: ~64 MB per attempt
Makes parallel attacks (GPU/ASIC) prohibitively expensive
Estimated cost: >$1 million to crack a strong password

GCM Authentication:

128-bit tag provides 2^128 security against forgery
Probability of successful random tag: 1 in 340 trillion trillion trillion

Known Limitations & Mitigations

1. Password Strength Dependency

Issue: Weak passwords reduce effective security
Mitigation:

scrypt makes brute-force expensive even for moderate passwords
Recommend 12+ character passwords with mixed case, numbers, symbols
Tool does not enforce password policy (user responsibility)

2. Visual Capacity Limits

Issue: High-capacity embedding in PNGs may cause subtle visual artifacts with 2-bit LSB
Mitigation:

Default to 1-bit mode for visual quality
2-bit mode only for large payloads
Use JPEG/WebP/trailer for maximum stealth

3. File Format Preservation

Issue: Some aggressive compression/optimization may strip hidden data
Risk: JPEG re-encoding, PNG optimization, PDF compression
Mitigation:

Store backups of encoded files
Verify integrity after file transfers
Use lossless formats when possible

4. Metadata Leakage

Issue: File modification timestamps may indicate alteration
Mitigation:

Not currently addressed in v1.x
Planned for v2.0: timestamp preservation option

5. Memory Dumps

Issue: Password strings may briefly exist in JavaScript heap
Risk: Low (requires privileged system access during encoding)
Mitigation:

Passwords cleared immediately after use
Future: Use secure buffer implementations

Threat Model

What Encapsula Protects Against:

✅ Passive observers (steganography conceals existence)
✅ Brute-force attacks (scrypt + strong passwords)
✅ Rainbow tables (random salts)
✅ Data tampering (GCM authentication tags)
✅ Chosen-plaintext attacks (random IVs)
✅ Bit-flipping attacks (authenticated encryption)

What Encapsula Does NOT Protect Against:

❌ Weak user passwords (tool cannot force strong passwords)
❌ Keyloggers or malware (operating system security required)
❌ Targeted statistical analysis by experts (LSB has detectable patterns)
❌ Quantum computers (in far future, AES-256 remains strong)
❌ Social engineering (user must keep password secret)

📸 Demo

Encapsula Demo

Interactive terminal interface showing the encode/decode workflow

🤝 Contributing

Contributions are welcome! Here's how you can help:

Report Bugs — Open an issue with reproduction steps
Suggest Features — Propose enhancements via GitHub Discussions
Submit PRs — Fix bugs or implement features
Security Audits — Help identify vulnerabilities (responsible disclosure)
Documentation — Improve guides, add examples
Testing — Write unit/integration tests

Development Setup

# Clone repository
git clone https://github.com/admin12121/Encapsula.git
cd Encapsula

# Install dependencies
npm install
npm i --save-dev @types/pngjs

# Build TypeScript
npm run build

# Run in development mode
npm run dev

# Run production build
npm start

Code Structure

Encapsula/
├── src/
│   ├── index.ts           # Entry point, tab navigation
│   ├── data.ts            # Configuration and constants
│   ├── loader.ts          # Startup/shutdown animations
│   ├── sections/
│   │   ├── home.ts        # Home screen with ASCII art
│   │   ├── encode.ts      # Encoding workflow (600+ lines)
│   │   └── decode.ts      # Decoding workflow (500+ lines)
│   ├── terminal/
│   │   ├── index.ts       # Terminal rendering and viewport
│   │   └── commands.ts    # Command processing
│   └── ui/
│       └── filePicker.ts  # File selection dialog
├── dist/                  # Compiled JavaScript (git ignored)
├── assets/                # Screenshots and media
├── package.json
├── tsconfig.json
└── README.md

Running Tests (Coming Soon)

npm test

Coding Standards

TypeScript strict mode enabled
ESLint for code quality
Secure crypto practices (no hardcoded keys, proper RNG)
Memory safety (buffer clearing, no leaks)
Error handling (graceful degradation)

📄 License

This project is licensed under the MIT License — see LICENSE file for details.

MIT License

Copyright (c) 2024 admin12121

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

⚠️ Disclaimer

Encapsula is provided for educational and legitimate privacy purposes only.

⚖️ This tool is not intended for illegal activities
👤 Users are responsible for compliance with local laws and regulations
🚫 The author assumes no liability for misuse or damages
🔐 Security depends on strong passwords and proper operational security
📊 No encryption is 100% unbreakable — use defense in depth

Legal Notice:

Encryption laws vary by jurisdiction (check local regulations)
Some countries restrict or ban cryptography without approval
Export restrictions may apply in certain regions
Corporate/enterprise use may require legal review

Best Practices:

Use strong, unique passwords (12+ characters, mixed case, symbols)
Keep software updated for latest security patches
Store backups of important encoded files
Do not reuse passwords across different files
Securely delete original plaintext after encoding
Verify file integrity after transfers

Remember: Security is a process, not a product. Always combine cryptographic tools with sound operational security practices.

🙏 Acknowledgments

Node.js Crypto Module — For cryptographic primitives (AES, scrypt, HMAC)
terminal-kit — For beautiful terminal UI rendering
pngjs — For PNG parsing and manipulation
jpeg-js — For JPEG format handling
Open Source Community — For inspiration, tools, and security research
Cryptography Researchers — For developing and analyzing scrypt, AES-GCM
InfoSec Community — For responsible disclosure and security improvements

Made with ❤️ by admin12121

Hiding in plain sight since 2024