Email address obfuscation/collection robot countermeasure code generation | ZeroTools

This tool generates conversion codes to hide email addresses and phone numbers from automated collection bots. On the operation panel, you can select between two modes: 'Create email link (mailto)' and 'General text / phone number'.

When the email link creation mode is selected, and 'info@example.com' is entered as the email address to hide and 'Contact us' as the link name to display, the output is code containing an HTML <a> tag.

At this time, mailto: is automatically prepended to the entered address for processing. On the other hand, if the general text mode is selected, the input string itself, such as '03-1234-5678', becomes the conversion target, and a link is not generated.

The link name cannot be configured, and the input value becomes the conversion target as it is. These conversion target data entered into the form are dynamically processed into strings using JavaScript within the browser.

Apart from the overall site communication, this obfuscation conversion of the input target itself utilizes a mechanism completed within the browser.

However, the generated code is merely a reversible representation of the original string in a different notation. Therefore, it has no strength as encryption and lacks functions to protect secret information or prevent the arrival of spam.

It is necessary to use it with an understanding of the format in which the output results will be executed.

As one of the obfuscation algorithms, 'HTML numeric character reference' is provided. This method acquires the Unicode code point of the entered character and converts it into a hexadecimal HTML entity (&#x...;).

In the implementation, it uses codePointAt(0) to acquire the code point value considering surrogate pairs, and concatenates it as a string.

For example, for 'info@example.com', 'i' becomes i, and subsequent characters are sequentially converted to form the output code.

In the email link mode, special characters like & and < in the link name entered, such as 'Contact us', are HTML-escaped to & and <, and then the character references are embedded in the href attribute of the <a> tag.

The greatest characteristic of this method is that restoring the characters does not require the execution of JavaScript. The browser interprets the character references as their original characters at the stage of parsing HTML and renders them on the screen.

Therefore, it displays correctly even in environments where JavaScript is disabled. However, because this is a simple replacement process, it is specified so that even general collection programs parsing HTML can easily restore the string.

The degree of obfuscation remains elementary.

As more complex representations, two JavaScript methods are provided: 'JS String.fromCodePoint' and 'Base64 decode script'. In the code point method, the string is divided character by character, and its code points are output as comma-separated numeric values.

For example, a JavaScript expression like String.fromCodePoint(105,110,102,111...) is generated and reconstructed at runtime. In the Base64 method, the input string is converted to a UTF-8 byte array (Uint8Array) using TextEncoder, which is then turned into a binary string using String.fromCharCode, and finally Base64-encoded with the btoa function.

At runtime, it dynamically expands to the original string combining atob and TextDecoder. When using these methods in the email link mode, a <script> tag is placed immediately after the <a> tag, and it overwrites the link destination property of the DOM element using document.currentScript.previousElementSibling.href.

In the case of the general text mode, a text node is inserted immediately before the script tag itself using document.currentScript.before(document.createTextNode(...)).

Thereby, even if HTML tags are included in the output code, they are treated as strings to prevent unintended tag execution.

The fourth conversion method, 'ROT13 character substitution', is a classic substitution cipher technique that shifts alphabets from A to Z and a to z by 13 characters respectively.

For example, 'A' is replaced with 'N', and 'i' with 'v'. The implementation of ROT13 in this tool uses the JavaScript regular expression /[a-z]/gi to target only ASCII letters for substitution.

Japanese characters, numbers, and symbols (such as at signs and hyphens) are not substituted and are maintained as they are. The output code includes a process that applies the same 13-character rotation function .replace(/[a-z]/gi, ...) again to the substituted string literal to revert it to the original string.

Additionally, < and > in the string literal are escaped like \u003c and \u003e to prevent parse errors caused by script closing tags.

Importantly, all conversion methods of this tool, including ROT13, possess 'reversibility' aimed at restoring the original string.

Because it is not an irreversible process like a hash function, restoring the original data from the output code is easy. It is inappropriate for the purpose of hiding highly confidential information.

In the 'Obfuscated code output' panel on the right side of the screen, there are two tabs: 'Obfuscated code' and 'Browser preview'.

In the text area of the 'Obfuscated code' tab, the HTML and JavaScript code generated according to the selected method is output as is.

This code can be retrieved to the clipboard from the copy button, though there is no success wait or failure display, and is immediately available.

On the other hand, the 'Browser preview' tab is not a sandbox environment that actually executes the generated obfuscated code to verify its operation.

Here, the input value of the link name set for the email address to hide or the general text is simply displayed as text. In other words, within the preview screen, evaluation of the output JavaScript code or launching of an email app via link click is not performed at all.

This is a function to visually confirm whether the entered content matches the user's expectations. How the code is actually interpreted by the browser and reflected in the DOM is determined only when the user pastes the code into the HTML of their own website and loads it in a browser.

There is a clear difference between the preview on the tool and the actual execution process.

When pasting the generated code into an actual website, attention must be paid to the environment and security requirements of the target site.

Especially when selecting methods using JavaScript (String.fromCodePoint, Base64, ROT13), inline scripts (<script>...</script>) are included in the code.

If the target website's Content Security Policy (CSP) restricts the execution of inline scripts, the execution of the restoration code is blocked, and nothing is displayed on the screen or an error occurs.

Also, in the text editors of some blog services and CMSs, inputted <script> tags may be automatically deleted or escaped to be invalidated for security reasons.

In that case, it is necessary to check the DOM tree using the browser's developer tools to verify whether the text node has been added correctly.

Furthermore, the limitations as a measure against spam bots must be recognized. Recent advanced collection programs use headless browsers to execute JavaScript and read the page contents after the DOM is completed.

Against such programs, the obfuscation will be undone, so there are cases where it does not function as a countermeasure against automated collection.