> A font-based deception tool for red teaming, security research, and whatever else.
E hides machine-readable text inside a document that displays completely different text to a human reader. It does this using E — fonts that intentionally deceive the by rendering a different letter than understood by a computer. By remapping font glyphs, the document's characters show humans one thing while terminals, AI systems, and clipboard copy paste see another.
> The word docx demos do NOT work on mobile due to the way mobile phones render fonts.
---
---
For de (editable install):
Installed automatically via pip:
fonttools — font parsing and manipulationbrotli — WOFF2 compression (used by fonttools)python-docx — DOCX generationreportlab — PDF generationpdf2image — PDF-to-image conpdfminer.six — PDF text/layout extractionPillow — image handling for the PDF pipelineSystem requirements (not installed by pip — must be on your PATH):
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.sudo apt install libreofficebrew install --cask libreofficepdf2image to render PDF pages for the pdf commandsudo apt install poppler-utilsbrew install poppler~\Documents\poppler and add to path.---
* Ubuntu: /usr/share/fonts
* Windows: C:\Windows\Fonts
*
* 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> (E embeds them itself) or Word on Windows. LibreOffice's own "embed fonts" option does not work for E.
The pdf command doesn't rely on E at all. It renders the DOCX to an image (so the page is a picture, not text), then draws the real computer text on top as fully in, selectable text. Copy-paste and text extraction read that in 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 in letters (in letters don't survive PDF con). From there, export directly from Word or use "Print to PDF." This keeps e 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 in fonts, then convert to PDF → more annoying, but produces different IOCs than Option 1.
> If anyone figures out how to pull off Option 2 *with* in 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.
create — Generate the font family for use in HTML or DOC files| 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:
Outputs:
output/fonts/*.woff — web fonts, one per characteroutput/ttffonts/*.ttf — TTF fonts for document embeddingoutput/fonts.css — -face declarations for web use---
.txt files.computer_file must be equal to or longer than the corresponding line in human_file---
web — Generate an Evil Font HTML 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 to human readers. Can be multiple lines |
| input_computer_file | Text to machines / AI. Can be multiple lines |
| output_file | Path for the generated HTML file |
Example:
---
doc — Generate a Evil Font DOCX file> 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" sa works fine, but LibreOffice's does not -- I could never get it to embed E correctly. Pass --ttf-dir instead: E embeds the fonts itself, directly into the .docx, without relying on Word or LibreOffice's embedding at all.
| Argument | Description |
|---|---|
| input_human_file | Text to human readers. Can be multiple lines |
| input_computer_file | Text 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:
---
pdf — Convert an Evil Font DOCX into a copy-paste-safe PDFRenders the DOCX with LibreOffice so the PDF looks identical to the document, then o the hidden payload as an in copy layer so it survi in every .
> 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 layer (default: 200) |
| --soffice | Path to the LibreOffice binary (default: soffice) |
| --ink-font | TTF for the in 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:
---
You are responsible for how you use this tool. Deploying this technique against systems or indi without explicit authorization is unethical and may be illegal. The authors provide this tool to help defenders understand and test for this class of — not to enable attacks.
---
This tool was created to help red teamers 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 indi 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.
* 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 / In. It is easy for an attacker to switch the website you are downloading from.
* Never open email attachments from untrusted sources.
* Remember that E rely on tricking an observer to be effective. A user must take an action for E to be a risk. Without taking a risky action, E 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' a new attack surface, an impro 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 , and where you're 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.
开发语言:Python
Star 数:350
该项目属于红蓝攻防方向的开源资源,代码结构清晰,适合安全研究人员学习参考。项目围绕A font-based deception tool for red teaming, security research, and whatever else.展开,提供了可运行的实现,对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。
从技术实现角度看,此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论,梳理项目的初始化流程、核心模块职责与数据流转,逐步掌握其中的技术细节与设计思路。
1. 下载源码压缩包,解压到本地环境。
2. 根据项目类型准备对应的运行环境与依赖。
3. 按照 README 中的步骤完成配置与部署。
4. 在隔离的测试环境中运行验证,避免影响生产系统。
本资源来源于开源社区,仅供安全研究、技术学习与合法授权范围内的攻防演练使用,请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。
| 资源标题 | EvilFontTool - A font-based deception tool for red teaming, secur |
| 所属分类 | 红蓝攻防 |
| 发布作者 | admin |
| 发布时间 | 2026-10-06 00:43:02 |
| 下载权限 | 免费下载 |
| 附件数量 | 2 个下载链接 |
| 浏览次数 | 186 |
| 讨论数量 | 0 |
| 主题状态 | 正常讨论中 |