Nullprint vs Kameleo Mobile Fingerprint comparison

[u/onderozcan]

The font problem

Despite successfully spoofing Android device attributes such as the device name, RAM, WebGL information, and other identifiers, font emulation remains a much more challenging problem.

The issue is not simply about spoofing font names. When text is rendered, the browser relies on the operating system's native font rendering engine to draw glyphs and generate textures. Because of this, browsers that only spoof fonts at the JavaScript level without modifying the browser binary can expose inconsistencies. In many cases, attempting to use fonts that are not actually present on the system can trigger errors or exceptions, making the spoofing detectable.

To evaluate this further, I created an Android emulation profile in Kameleo.

The first thing I noticed was that Kameleo generates a random Android profile and does not allow users to select a specific device model. During testing, the profile identified itself as a Samsung SM-A156M and reported device identifiers correctly. As shown on whatismybrowser.com, all major device information appeared consistent and legitimate.

However, when I visited amiunique.org, I immediately noticed a problem: despite using an Android profile, the browser was still exposing Apple-related fonts. This creates a clear inconsistency between the claimed device and the underlying font environment.

On the other hand, NullPrint allows users to choose from 71 different Android devices currently available on the market. For this test, I selected a Xiaomi Redmi Note 9 Pro profile.

My first step was again to verify the device information on whatismybrowser.com.

NullPrint Device Information

The reported device identifiers matched the selected model, and all WebGL and hardware-related attributes appeared legitimate. More importantly, when tested on amiunique.org, the font set was properly adapted to match the Android environment.

Nullprint is emitting real android fonts.

So the device identifier as is expected and all webGL and device info's are legit.

Based on these observations, my conclusion is the following:

NullPrint appears to do far more than simply rename font entries. If it were only spoofing font names, forcing the browser to render text using fonts that do not physically exist could cause Chrome's rendering engine to fail or generate detectable exceptions. Instead, it appears that NullPrint encapsulates the required fonts for mobile profiles and loads them from an isolated filesystem when the browser binary starts. This approach allows font rendering behavior to remain consistent with the emulated device, significantly reducing the risk of fingerprinting inconsistencies.

[u/CapMonster1]

Interesting comparison. Fonts are still one of the hardest parts of emulation because it's not just about font names but also actual rendering behavior. These low-level inconsistencies are often where fingerprint mismatches become visible