EvilFontTool: فونتهایی که چشم رو گول میزنن
خلاصهٔ کاملتر
EvilFontTool یه ابزار متنباز پایتونیه که ایدهٔ سادهای رو عملی میکنه: فونت رو جوری دستکاری کن که شکل ظاهریِ هر حرف با کدِ واقعیِ پشتش فرق کنه. توی مستندات پروژه اومده که نتیجهش «فونت شرور»ه؛ سندی که آدم موقع خوندنش یه چیز میبینه، ولی ترمینال، کلیپبورد و هر ابزاری که متن رو ماشینی میخونه چیز دیگهای تحویل میگیره.
ابزار سه حالت خروجی داره. با زیردستور create از روی یه فونت مرجع، یه خانوادهٔ فونت بهازای هر کاراکتر ساخته میشه؛ بعد web یه صفحهٔ HTML و doc یه فایل DOCX تولید میکنه. هر دو، دو تا فایل متنی ورودی میگیرن: یکی متنی که آدم میبینه و یکی متنی که کامپیوتر میخونه.
برای اینکه فریب درست رندر بشه، فونتها باید روی سیستم نصب یا داخل خود سند embed شده باشن. نویسنده میگه گزینهٔ embed خودِ LibreOffice برای این فونتها کار نمیکنه و به جاش باید سوییچ --ttf-dir رو پاس داد تا ابزار خودش فونتهای لازم رو مستقیم توی فایل .docx جاسازی کنه.
جالب اینه که زیردستور pdf اصلاً از فونت شرور استفاده نمیکنه: سند Word رو به تصویر تبدیل میکنه و متن واقعی رو بهصورت یه لایهٔ نامرئیِ قابلانتخاب روش میکشه، پس کپیپیست همون لایهٔ پنهان رو برمیداره. نویسنده خودش میگه این همون ترفند دولایهایه که ابزارهای دیگه هم دارن و به همین خاطر شناختهشدهتر و قابلتشخیصتره.
بخش پایانی مخزن به دفاع اختصاص داره. سمت کاربر: به سند و پیوست فرستندهٔ ناشناس اعتماد نکن، متنی رو که کپی کردی قبل از اجرا با چشم چک کن، و سند دیگران رو به ابزارهای هوش مصنوعی نده. سمت صنعت هم پیشنهاد میده رندر فونت سفارشی توی Protected View بسته بشه، تعداد زیاد فونت سفارشی توی یه سند سیگنال بدافزار حساب بشه و پردازش سند با هوش مصنوعی از مسیر رندر به تصویر و OCR انجام بشه.
نکات کلیدی:
- فونت شرور شکل ظاهری حرف رو از کد واقعیاش جدا میکنه؛ آدم و ماشین دو متن متفاوت میبینن
- خروجیها: صفحهٔ HTML، فایل DOCX و PDF؛ برای DOCX جاسازی فونت با --ttf-dir لازمه
- زیردستور pdf ترفند دولایهست، نه فونت شرور واقعی
- دفاع کاربر: چککردن متن کپیشده قبل از اجرا و ندادن سند ناشناس به ابزارهای هوش مصنوعی
- دفاع سازمانی: محدودکردن فونت سفارشی و استفاده از OCR موقع پردازش سند با هوش مصنوعی




