EvilFontTool

A font-based deception tool for red teaming, security research, and whatever else.

EvilFontTool hides machine-readable text inside a document that displays completely different text to a human reader. It does this using Evil Fonts — fonts that intentionally deceive the viewer by rendering a different letter than understood by a computer. By remapping font glyphs, the document's visible characters show humans one thing while terminals, AI systems, and clipboard copy paste see another.

• View the Demos → Here

• View the Evil Font Labs → Here

The word docx demos do NOT work on mobile due to the way mobile phones render fonts.

• Installation
• Usage Tips
• PDFs Woes Explained
• Usage
• Ethical Use & Disclaimer
• Staying Safe from Evil Fonts
• Contributing
• Help me somethings not working!

pip install evilfonttool

git clone https://github.com/DoctorEww/EvilFontTool.git
cd EvilFontTool
pip install .

For development (editable install):

pip install -e .

Installed automatically via pip:

• fonttools — font parsing and manipulation
• brotli — WOFF2 compression (used by fonttools)
• python-docx — DOCX generation
• reportlab — PDF generation
• pdf2image — PDF-to-image conversion
• pdfminer.six — PDF text/layout extraction
• Pillow — image handling for the PDF pipeline

System requirements (not installed by pip — must be on your PATH):

• LibreOffice — required for the pdf command, which shells out to soffice --headless to convert DOCX to PDF. The pdf command is experimental on Windows and may not work as intended.
  • Ubuntu/Debian: sudo apt install libreoffice
  • macOS: brew install --cask libreoffice
  • Windows: download installer
• poppler-utils — required by pdf2image to render PDF pages for the pdf command
  • Ubuntu/Debian: sudo apt install poppler-utils
  • macOS: brew install poppler
  • Windows: poppler for Windows (add the Library\bin folder to path) Or see below.

Install poppler into ~\Documents\poppler and add to path.

irm (irm https://api.github.com/repos/oschwartz10612/poppler-windows/releases/latest).assets[0].browser_download_url -OutFile ~\Documents\poppler.zip
Expand-Archive ~\Documents\poppler.zip ~\Documents\poppler -Force
$bin = (gci ~\Documents\poppler -Recurse -Filter pdftotext.exe)[0].DirectoryName
[Environment]::SetEnvironmentVariable('Path', [Environment]::GetEnvironmentVariable('Path','User') + ";$bin", 'User'); $env:Path += ";$bin"

• Ubuntu: /usr/share/fonts
• Windows: C:\Windows\Fonts
• https://fonts.google.com/
• The internet??

• Generate fonts and pdf's on Linux. The pdf command is experimental on Windows and may not work as intended.
• The pdf command does not work on complex word documents ex. columns. Feel free to open an issue if theres a feature you really want it to support.
• To embed fonts, use doc --ttf-dir <ttffonts_dir> (EvilFontTool embeds them itself) or Word on Windows. LibreOffice's own "embed fonts" option does not work for Evil Fonts.

The pdf command doesn't rely on Evil Fonts at all. It renders the DOCX to an image (so the visible page is a picture, not text), then draws the real computer text on top as fully invisible, selectable text. Copy-paste and text extraction read that invisible layer instead. There are a few other tools that can do this, but nothing as easy as the pdf command when you already have a DOCX you like.

If you want a genuine Evil Font PDF, you need to build the Word doc without invisible letters (invisible letters don't survive PDF conversion). From there, export directly from Word or use "Print to PDF." This keeps everything in a single layer, giving the document different IOCs than the well-known two-layer trick used by the pdf command. The pdf command exists purely because that manual process is tedious, and sometimes you just want a quick PDF copy of a Word doc.

TLDR;

• Option 1: (easy one) Use the pdf command → two-layer PDF, same mechanism as other tools (more well-known/detectable).
• Option 2: (real Evil Font one) Build a Word doc without invisible fonts, then convert via Print to PDF → more annoying, but produces different IOCs than Option 1.

If anyone figures out how to pull off Option 2 with invisible letters, I owe you a drink. Open an issue and I'll credit you in the README.

All functionality is exposed via a single CLI with four subcommands.

evilfonttool create <reference_font> <output_dir> <font_name>

Example:

evilfonttool create fonts/Arial.ttf output/ 'Arial'

Outputs:

• output/fonts/*.woff — web fonts, one per character
• output/ttffonts/*.ttf — TTF fonts for document embedding
• output/fonts.css — @font-face declarations for web use

• Plain .txt files.
• Each line in computer_file must be equal to or longer than the corresponding line in human_file
• Lines are matched positionally (line 1 to line 1, etc.)

evilfonttool web <human_file> <computer_file> <output_file>

Requires fonts.css and the generated fonts to be in the output directory so the HTML file can use it (or change the path in the HTML file).

Example:

evilfonttool web human.txt computer.txt output/index.html

evilfonttool doc <human_file> <computer_file> <output_file> <font_name> [--author AUTHOR] [--ttf-dir DIR]

The font_name must match the name used in the create step. The TTF fonts must be installed on the system, embedded via --ttf-dir, or embedded manually in Word (file -> options -> save -> embed fonts) for the deception to render correctly.

Word's own "embed fonts" save option works fine, but LibreOffice's does not -- I could never get it to embed Evil Fonts correctly. Pass --ttf-dir instead: EvilFontTool embeds the fonts itself, directly into the .docx, without relying on Word or LibreOffice's embedding at all.

Example:

evilfonttool doc human.txt computer.txt output/secret.docx MyFont --author "Finance Team" --ttf-dir output/ttffonts

evilfonttool pdf <input_docx> <output_file> [--ttf-dir DIR] [--dpi DPI] [--soffice PATH] [--ink-font FONT] [--title TITLE] [--author AUTHOR] [--subject SUBJECT] [--producer PRODUCER]

Renders the DOCX with LibreOffice so the PDF looks identical to the document, then overlays the hidden payload as an invisible copy layer so it survives copy-paste in every viewer.

Windows: This command is experimental on Windows and may not work as intended.

Requires LibreOffice (soffice) and poppler-utils — see Dependencies.

Example:

evilfonttool pdf output/secret.docx output/secret.pdf --ttf-dir output/fonts/ttffonts --title secret

You are responsible for how you use this tool. Deploying this technique against systems or individuals without explicit authorization is unethical and may be illegal. The authors provide this tool to help defenders understand and test for this class of vulnerability — not to enable attacks.

This tool was created to help red teamers validate the risks of font-based attacks against their organizations. It was also created to help blue teamers, researchers, and system owners understand the gaps in security that are left by intrinsically trusting user-supplied fonts. Below are some practical recommendations for individuals and industry to address or mitigate the problem fonts pose in modern operating systems and applications.

• Don't trust any content provided by untrusted sources. Check email senders and check domain names.
• Verify commands after pasting, before you execute them.
• Never run commands you don't understand.
• Don't run commands that pipe curl output directly into bash / Invoke-Expression. It is easy for an attacker to switch the website you are downloading from.
• Never open email attachments from untrusted sources.
• Remember that Evil Fonts rely on tricking an observer to be effective. A user must take an action for Evil Fonts to be a risk. Without taking a risky action, Evil Fonts can't affect you.
• Don't upload documents created by someone else to AI tools.

• Don't allow custom fonts to render in Protected View (Microsoft Office Suite).
• Don't allow users to bring custom fonts, or limit the number of custom fonts.
• Treat a large number of custom fonts in a webpage or Word document as a malware signal.
• Warn users who use Win + R with a scary popup saying how this is very risky the first time they do it (idk how this isn't a thing already...).
• When processing documents with AI, render the document to an image and extract text with OCR. This has the added benefit of protecting against images with text in them.
• Don't ignore user-supplied fonts in threat models.
• Treat user-supplied fonts as what they are: untrusted user input.

Contributions are welcome. If you've found a new attack surface, an improvement to the font generation pipeline, or a defense technique worth documenting, please open an issue or PR.

1. Fork the repo
2. Create a feature branch (git checkout -b feature/my-feature)
3. Commit your changes
4. Open a pull request with a clear description of what changed and why

This tool is really hard to test due to the complexity of word documents, pdfs, and fonts. If you find a repeatable issue please open a GitHub issue and I will get to it as soon as I can.

Please include the following in the issue:

• OS + LibreOffice version, and where you're viewing the file (Word / LibreOffice / something else).
• Whether the fonts are installed, embedded, or neither.
• The exact command you ran and any terminal output (especially mismatch warnings).
• A minimal .docx / input that reproduces it, if you can share one.
• Anything else that could be causing the issues.