Encoding Capabilities#

Prompt Attack features an advanced encoding module that enables users to encode adversarial prompts in various formats. Encoding is an essential tool in adversarial testing, allowing security teams to simulate obfuscated inputs often used in real-world attacks. These encodings help evaluate an LLM’s ability to decode and process manipulated data without exposing vulnerabilities or generating unsafe outputs.

This guide outlines the supported encoding methods, their applications in adversarial testing, and the distinction between free and paid features.

Why Encoding Matters in Adversarial Testing#

Encoding is a common technique used in real-world attacks to obfuscate malicious intent. Attackers often encode inputs to bypass security measures such as content filtering, validation, or detection mechanisms. For example, malicious code could be Base64-encoded to evade detection or URL-encoded to manipulate web queries. Testing how an LLM handles such encodings ensures robust defenses against adversarial inputs.

Prompt Attack allows users to simulate these scenarios and analyze an LLM’s ability to:

  • Process Encoded Inputs Safely: Ensure the model doesn’t inadvertently decode and act on harmful instructions.

  • Resist Obfuscation Techniques: Validate that the LLM can reject obfuscated data or respond safely.

  • Assess Decoding Logic: Identify vulnerabilities in how encoded inputs are handled.

Available Encoding Methods#

Prompt Attack supports a wide range of encoding formats, categorized into free and paid options. Below is a detailed list of each encoding method, its purpose, and its applications in security testing.

Free Encodings#

These encoding methods are available to all users at no additional cost:

  1. Base2 (Binary) Represents each character as binary code (e.g., “A” becomes “01000001”). This tests the model’s ability to process binary data safely and reject unauthorized requests encoded in binary form.

  2. Base8 (Octal) Converts characters into octal (Base8) representation, commonly used in low-level data encoding. Example: “A” becomes “101”. This ensures the LLM can resist attacks that encode prompts in less common numerical systems.

  3. Braille Converts text into Braille Unicode characters (e.g., “hello” becomes ⠓⠑⠇⠇⠕). While primarily a representation for visually impaired communication, Braille encoding tests the model’s ability to process text in alternative symbolic systems.

  4. Diacritics Obfuscates text using diacritical marks (e.g., accents, tildes) to resemble standard characters. Example: “hello” becomes “h́èl̃l̇ö”. This evaluates the LLM’s resilience to altered text representations often used for evading detection.

  5. MD5 Hash Generates an MD5 hash of the input. Example: “hello” becomes “5d41402abc4b2a76b9719d911017c592”. Although irreversible, testing with MD5 hashes ensures the model does not improperly interpret or process cryptographic data.

  6. Reverse Reverses the input text. Example: “hello” becomes “olleh”. This tests the LLM’s ability to handle reversed instructions or detect maliciously obfuscated input.

  7. Rot5 Rotates numerical digits (0–9) by 5 places. Example: “12345” becomes “67890”. This helps test how numerical obfuscation affects the model’s ability to decode and respond correctly.

  8. Rot13 A common text rotation technique that shifts each letter (A–Z, a–z) by 13 places in the alphabet. Example: “hello” becomes “uryyb”. This encoding tests the LLM’s handling of basic textual transformations.

  9. Rot25 Similar to Rot13 but rotates letters by 25 places. Example: “A” becomes “Z”. This evaluates how the LLM processes variations in text rotations.