FontEnigma

2»

Comments

  • Michael Rafailyk
    Michael Rafailyk Posts: 208
    edited September 26
    LeMo aka PatternMan aka Frank E Blokland said:
    if you type the alphabet in one direction, the obfusction in the opposite direction will become clear when you copy the result into a text editor. Evib~dvoo~hklggvw}
    If you need to preserve the entered text so that it is available for copy-pasting, here's an idea that came to mind – with duplicating the text element – one for typing the text and one for displaying the font.

    Here is the link to a test layout. Green cursor is the upper (operable) element – here you see only cursor. Blue text is the lower element with displayed font – the text is copied here with JavaScript.
    https://jsfiddle.net/4p8zgfhx/

    Explanation.

    Place two text elements above each other (absolutely positioned inside the container), with the same font size and line height (to synchronise the caret position). Lower text element is the rendered font with obfuscation, that user will see. Upper text element is the transparent font without obfuscation (and with empty glyphs), that user operate. Top element should have transparent text but visible caret. Both fonts should have the same horizontal metrics (for displayed letter) to synchronise the caret. Then use JS to copy text from user-operable upper element to lower element.
  • John Savard
    John Savard Posts: 1,209
    Simon Cozens said:
    Exactly. What does "protecting against the casual attacker" mean when the attack method of the casual attacker is to simply download the font from a web site where it's been provided by the sophisticated attacker?

    Well, one may not be able to protect against the sophisticated attacker cracking any technical means of copy protection one might be attempting to use with one's font.
    But one can certainly make use of things like DMCA takedown requests when one's cracked font is appearing on somebody's web site. That would be protection against the casual attacker.
    Another example of protecting against the casual attacker would be to insist that people using the font for a web site use some copy protection mechanism. However, my understanding is that these days the most commonly used browsers don't support copy protection for web fonts any longer; and back when they did, each browser supported a different scheme. Absent a means of copy protection, one just looks at the page source, then the CSS file source if necessary, and downloads the font, which is within the abilities of a casual attacker.
  • Michael Rafailyk
    Michael Rafailyk Posts: 208
    John Savard said:
    However, my understanding is that these days the most commonly used browsers don't support copy protection for web fonts any longer; and back when they did, each browser supported a different scheme. Absent a means of copy protection, one just looks at the page source, then the CSS file source if necessary, and downloads the font, which is within the abilities of a casual attacker.
    There is a technique for loading a font as an encoded flow. It's good enough protection from a lazy attacker who just know how to save the file from a page cache (because now the font there is encoded), however it is still not a bulletproof approach. The problem is that the font customer (website owner) needs to do an extra steps for this (PHP, JS), and this is a huge stumbling stone. I would say, a stone unliftable for most. Not to mention that many people won't agree to the font not being stored in the cache but being dynamically loaded every time.

    So all these discussed techniques can only give an initial effect on the font market / type tester website, until the font is purchased.
    But one can certainly make use of things like DMCA takedown requests when one's cracked font is appearing on somebody's web site. That would be protection against the casual attacker.
    Usually, by that time the font has already been downloaded many times, most of which occur in the first few days.

    Another idea that requires some technical resources (startup for some enthusiasts) is to have a database of malicious addresses (where fonts are usually leaked) and automatically scan it regularly for certain font names. It sounds crazy, but who knows what the future holds. In a better world where governments were concerned about this, some anti-crime agency would be handling all of this. In a better world.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    Hi Michael, although I find it hard to imagine a scenario where users need to copy readable text from the type tester, maybe hiding the obfuscation at first sight would be useful, and implementing it should not be too difficult. The current version of FontEnigma (which uses a somewhat more complex obfuscation than the initial release) already translates pasted text on the fly. The reverse should also be possible by intercepting the copy event and replacing the selection with decoded text before it is written to the clipboard. I will give this a try in the near future.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    edited September 30
    The latest version of FontEnigma now decodes text copied or cut from the type tester. So instead of getting obfuscated strings like ‘U§ir€’ when copying something like ‘E=mc²’, you now get the actual readable text as displayed.

    DTLs FontEnigma type tester

    It might not be a game-changer, but it definitely makes things a bit neater and more user-friendly.
  • Roel Nieskens
    Roel Nieskens Posts: 203
    It might not be a game-changer, but it definitely makes things a bit neater and more user-friendly.
    And a lot easier to reverse engineer :-)
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    Yes, perhaps a little. However, basically this information was already available, as the submenu shows.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    In the latest version of FontEnigma, I have added a couple of things to help make it harder to grab the fonts or inspect the page easily.

    Obfuscating font paths in FontEnigma

    First, the browser’s context menu is disabled on desktop (both right-click and keyboard). On mobile it is still allowed, otherwise users would not be able to copy and paste text. The oncontextmenu event is also locked on the <body>, in case someone tries to override it.

    More importantly, the woff2 font files are now XOR-encrypted, and then decrypted on the fly in the browser using JavaScript. Once decoded, the fonts are loaded using FontFace and referenced via a temporary ‘blob:’ URL, which disappears as soon as the page is refreshed or closed.

    I must admit, however, that all of this together only adds up to a small additional hurdle that a serious attacker can undoubtedly get around.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    In addition, the ‘blob;’ URL now expires immediately.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    As mentioned, the XOR‑encrypted fonts (for example ‘typeface.woff2.xor’) are decrypted on the fly in the browser. The resulting ‘blob:’ URLs are ephemeral: they disappear or are replaced when the page is refreshed or closed. The original font file paths and directory structure are never exposed to the page.

    Keeping the original source paths hidden and limiting access are therefore the most important defenses. That said, if an attacker can observe the decrypted bytes (for example via DevTools, an instrumented browser, or a man‑in‑the‑browser attack), no purely client‑side measure can prevent extraction: this is, of course, an inherent limitation of rendering assets in the user’s browser. I would not be surprised if some of you managed to do that.

    The XOR encryption I use is intentionally lightweight: with a 256‑bit (or larger) key it provides a practical layer of obfuscation for this use case. The primary goal is to make casual downloading and automated harvesting more difficult. That said, the encryption is relative: after all, in the browser at runtime the decrypted bytes exist in memory, even if extracting them is not straightforward.

    The JavaScript involved is simple and lightweight as well. It is easily portable to any site and requires minimal changes to fonts‑related CSS. That makes it feasible to distribute the script together with encrypted webfonts to customers. Each customer receives a unique XOR key and the font files for that customer are encrypted with that key. Without the key the encrypted files are useless –unless the client code is cracked, of course.

    Decryption and serving of the fonts is performed by that JavaScript, which we then heavily obfuscate. This adds friction but is a possible weakness too: obfuscation, no matter how elaborate, can be reversed. Cracking it, however, requires skill and patience, but it is possible. The key could be handled more securely (for example via server‑assisted, short‑lived keys), but that would require more server‑side work, and the design goal here is to keep client-integration simple.

    Client-side decryption and the obfuscated script can slightly slow down page loading, but I reduce this impact by loading fonts asynchronously and using caching. The effect on user experience is minimal. The sizes of the font files stay the same after being XOR-encrypted.

    In conclusion, customer-distributed font files include only XOR-based protection; the fonts themselves are not altered: Unicode codepoints and outlines remain intact. The DTL type tester, by contrast, applies an additional layer of font‑level obfuscation, since it exposes the full library for live rendering. These protections are designed to reduce the risk of unauthorized downloading and redistribution as much as possible, while keeping the fonts usable in their intended contexts.
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    The latest version of FontEnigma is a bit faster and has a cleaner look. It also includes stronger Unicode obfuscation: the code points of 400 characters have been scrambled across the ranges used by the displayed fonts. This makes full reconstruction considerably harder after converting captured ASCII back to binary.

    DTL’s FontEnigma

    The XOR encryption remains in place, but it mainly protects against a compromised server. As an aside, I have further hardened the site with additional nginx (reverse-proxy) and Apache rules. Penetration tests will likely still reveal minor, low-risk issues, because nginx’s proxying prevents those requests from reaching the top-level .htaccess file in Apache.
  • Roel Nieskens
    Roel Nieskens Posts: 203
    edited October 28
    I had to try :-)

    I was able to download the WOFF2 blob with the mixed up cmap. I set a breakpoint at the textarea's event handler. Stepping through the code showed where the input gets converted to the encoded output. You can then jump in the console and use the decoding-array to loop over the relevant characters to get their encoded variant. Updating the cmap in downloaded font accordingly would result in a working font, as far as I can tell. (edit: expanded a little on how I found the array)



    I don't think any of that made if back to the server, did you see anything @LeMo aka PatternMan aka Frank E Blokland?
  • LeMo aka PatternMan aka Frank E Blokland
    LeMo aka PatternMan aka Frank E Blokland Posts: 776
    Hi Roel, nice catch, and thank you for pointing that out. You are absolutely correct: updating the cmap accordingly would result in a functional font. Unfortunately, as far as I am aware, there is no way to prevent someone from setting a breakpoint using DevTools.

Categories