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.
Evil Font Demos/Labs !!DON'T MISS THIS!!
The word docx demos do NOT work on mobile due to the way mobile phones render fonts.
Table of Contents
Installation
pip install evilfonttool
From source
git clone https://github.com/DoctorEww/EvilFontTool.git
cd EvilFontTool
pip install .
For development (editable install):
pip install -e .
Dependencies
Installed automatically via pip:
fonttools — font parsing and manipulationbrotli — WOFF2 compression (used by fonttools)python-docx — DOCX generationreportlab — PDF generationpdf2image — PDF-to-image conversionpdfminer.six — PDF text/layout extractionPillow — 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.
Poppler install windows helper script
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"
Where can I find fonts to use?
Usage Tips
- 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.
PDF's Woes Explained
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.
Usage
All functionality is exposed via a single CLI with four subcommands.
create — Generate the font family for use in HTML or DOC files
evilfonttool create <reference_font> <output_dir> <font_name>
| Argument |
Description |
reference_font |
Path to a .ttf or .woff source font |
output_dir |
Directory to write fonts and CSS into |
font_name |
Internal name prefix for the generated font family |
Example:
evilfonttool create fonts/Arial.ttf output/ 'Arial'
Outputs:
output/fonts/*.woff — web fonts, one per characteroutput/ttffonts/*.ttf — TTF fonts for document embeddingoutput/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.)
web — Generate an Evil Font HTML file
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).
| Argument |
Description |
input_human_file |
Text visible to human readers. Can be multiple lines |
input_computer_file |
Text visible to machines / AI. Can be multiple lines |
output_file |
Path for the generated HTML file |
Example:
evilfonttool web human.txt computer.txt output/index.html
doc — Generate a Evil Font DOCX file
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.
| Argument |
Description |
input_human_file |
Text visible to human readers. Can be multiple lines |
input_computer_file |
Text visible to machines / AI. Can be multiple lines |
output_file |
Path for the generated DOCX file |
font_name |
Font family name (must match create step) |
--author |
DOCX document author metadata (default: none) |
--ttf-dir |
Directory of Evil Font TTFs (e.g. <output_dir>/ttffonts). If given, the fonts actually used are embedded directly into the .docx, so the deception renders correctly without installing them system-wide. Only embeds letters included in the human file. |
Example:
evilfonttool doc human.txt computer.txt output/secret.docx MyFont --author "Finance Team" --ttf-dir output/ttffonts
pdf — Convert an Evil Font DOCX into a copy-paste-safe PDF
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.
| Argument |
Description |
input_docx |
Path to the Evil Font DOCX (from the doc step) |
output_file |
Path for the generated PDF file |
--ttf-dir |
Directory of Evil Font TTFs (e.g. <output_dir>/ttffonts), exposed to LibreOffice so the disguise renders. Omit only if the fonts are installed system-wide or embedded in the file |
--dpi |
Rasterisation quality of the visible layer (default: 200) |
--soffice |
Path to the LibreOffice binary (default: soffice) |
--ink-font |
TTF for the invisible copy layer (default: a system sans) |
--title |
PDF document title metadata (default: Untitled) |
--author |
PDF document author metadata (default: none) |
--subject |
PDF document subject metadata (default: none) |
--producer |
PDF document producer metadata (default: none) |
Requires LibreOffice (soffice) and poppler-utils — see Dependencies.
Example:
evilfonttool pdf output/secret.docx output/secret.pdf --ttf-dir output/fonts/ttffonts --title secret
Ethical Use & Disclaimer
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.
Staying Safe from Evil Fonts
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.
What can I do against Evil Fonts?
- 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.
What can the industry do to protect against Evil Fonts?
- 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.
Contributing
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.
- Fork the repo
- Create a feature branch (
git checkout -b feature/my-feature)
- Commit your changes
- Open a pull request with a clear description of what changed and why
Help me somethings not working!
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.
EvilFontTool — это инструмент обмана на основе шрифтов для red teaming и исследований безопасности. Он генерирует «Evil Fonts» — шрифты с переназначенными глифами, из-за которых документ показывает людям один текст, а терминалы, ИИ-системы и копипаст видят совершенно другой.