Blogs on Osservatorio Nessuno - Association for the promotion and protection of digital rights

Demystifying phone unlocking tools: A technical overview

Thu, 07 May 2026 00:00:00 +0000

This post is a written description of a presentation titled Phone unlocking tools and where to find them that we have delivered privately to different events and organizations, including Primavera Hacker 25, the Freedom of the Press Foundation, and the Public Interest Technology Group. It provides a technical overview of how commercial forensic tools compromise mobile devices, focusing on the specific attack surfaces exploited at each stage of the device lifecycle. Further posts will focus on sample analysis, and defenses. See also the previous posts of this serie:

Introduction

Commercial phone unlocking tools are not magic. They exploit the same classes of vulnerabilities that security researchers publish about at conferences and in academic papers. What makes them distinctive is not the novelty of the techniques, but the systematic commercialization of exploitation: acquiring or developing exploits for each hardware and software combination, and reaching a certain degree of stability, packaging them into automated workflows that require minimal operator expertise.

This post aims to demystify the technical foundations of these tools. The attack vectors available to a forensic examiner with physical access to a device are constrained by well-understood boundaries: the boot chain, the trusted execution environment, the secure element (when present), and the kernel’s peripheral driver stack. This post mostly details Android internals, however iOS equivalent concepts are technically similar.

Much of the background research referenced here comes from Quarkslab, whose extensive publications on TEEs, and Android’s data encryption architecture have been invaluable to understand these tools. Their work, alongside reporting from Amnesty International’s Security Lab and other NGOs, and analysis by the GrapheneOS project, provides the empirical basis for the claims made in this post.

Hardware security architecture

Before examining attack vectors, it is necessary to understand the hardware security architecture of modern Android devices. The following sections describe the components that forensic tools must eventually hack or bypass.

The System-on-Chip: Normal World and Secure World

Modern ARM-based mobile processors implement TrustZone™, a hardware security extension that partitions the processor into two execution environments: the Normal World and the Secure World. The Normal World runs the Android operating system, user applications, and the Linux kernel. The Secure World runs a separate, minimal operating system, the Trusted OS, along with small, specialized applications known as Trusted Applications (TAs).

SoC diagram showing Normal World and Secure World partitions, with the TEE running Trusted Applications and communicating with an optional Secure Element over SPI

The two worlds share the same physical processor cores but are hardware-isolated: the Normal World cannot directly read or write Secure World memory. Communication between the two happens through a monitor, a piece of code running at the highest privilege level (EL3 on ARMv8), which handles context switches triggered by Secure Monitor Call (SMC) instructions. Each physical processor core effectively provides two virtual cores, with the Non-Secure bit in the Secure Configuration Register determining which world is active at any given time.

The Trusted OS hosts critical security services. Two are directly relevant to device unlocking:

Gatekeeper: responsible for verifying user credentials (PIN, password, pattern). It implements rate-limiting to throttle brute-force attempts and, upon successful authentication, issues a signed authentication token.
Keymaster: the key management service that stores and operates on cryptographic keys. Some keys are authentication-bound, meaning they can only be used after Gatekeeper has issued a valid token.

Different SoC vendors ship different TrustZone™ implementations. Google (and AOSP in general) uses TrustyOS; Qualcomm uses QSEE; Samsung uses TEEGRIS (on both Exynos and MediaTek SoCs in Samsung devices); Huawei uses TrustedCore; Trustonic’s Kinibi is also often found on MediaTek and Exynos SoCs. The security properties vary between implementations.

The Secure Element

A Secure Element (SE) is a physically separate, tamper-resistant hardware chip that provides an additional layer of security beyond the TEE. Unlike the Secure World, which runs on the same SoC as the Normal World, a Secure Element is an independent processor with its own boot chain, its own firmware, and its own cryptographic key storage.

In the Android ecosystem, the Secure Element is exposed through the StrongBox API (introduced in Android 9). Google’s Pixel phones, starting with the Pixel 3, include the Titan M chip as their Secure Element, that was later upgraded with the Titan M2 from Pixel 6 onward. On Apple devices, the equivalent is the Secure Enclave Processor (SEP).

The Secure Element’s role in device encryption is to hold key-encryption keys and enforce rate-limiting for credential verification in hardware that the main SoC cannot tamper with, even if fully compromised. This is an important distinction: on a device without a Secure Element, compromising the TEE is sufficient to extract or bypass credential-derived keys. On a device with a Secure Element, the attacker must additionally compromise a separate, hardened chip.

Unfortunately, only flagship devices typically include a Secure Element. Most mid-range and budget devices rely solely on the TEE for credential protection. This architectural gap is the single most important factor determining the chances that a device has to resist forensic unlocking when powered off.

The boot chain

The boot chain establishes a chain of trust from immutable hardware to the running operating system. Each stage verifies the integrity of the next before executing it.

Boot flow diagram showing Boot ROM → Preloader → Trusted OS and Monitor (Secure World) / Bootloader → OS (Normal World), with the Secure Element running its own boot chain

The chain proceeds as follows:

Boot ROM: the first code executed at power-on. It is burned into silicon at manufacture and is, in principle, immutable and unpatchable (with a few modern exceptions to deploy patches for vulnerabilities). The Boot ROM verifies and loads the next stage (the preloader or secondary bootloader). It forms the hardware root of trust.
Preloader/Secondary Bootloader (BL2): loaded and verified by the Boot ROM. On MediaTek SoCs, this is often called the preloader. It initializes hardware, loads the Trusted OS into the Secure World, and loads the main bootloader into the Normal World.
Trusted OS: loaded into the Secure World by the preloader. It hosts Gatekeeper, Keymaster, and other Trusted Applications. Its integrity is verified by the preloader as part of the secure boot chain.
Bootloader (BL3): the Normal World bootloader (e.g., Little Kernel on MediaTek, ABL on Qualcomm). It enforces Android Verified Boot (AVB), anti-rollback protections, and device-state checks before loading the Android kernel.
Android OS: the Linux kernel and userspace. Verified Boot (dm-verity) ensures the integrity of system partitions at runtime.

When a Secure Element is present, it runs its own independent boot chain in parallel: Boot ROM → Bootrom EXT → Bootloader → OS. The Secure Element’s boot chain is entirely separate from the SoC’s, providing the most isolation.

If any stage in the boot chain is compromised, all subsequent stages are untrustworthy. This is why Boot ROM vulnerabilities are so devastating: they are often unpatchable, they undermine everything built on top, and they affect every device using the vulnerable silicon for its entire hardware lifetime.

Android data encryption

Understanding the attack vectors requires understanding what the attacker is ultimately trying to obtain: the decryption keys for the user’s data.

Full Disk Encryption vs. File-Based Encryption

Android has used two encryption schemes over its history:

Full Disk Encryption (FDE) encrypts the entire data partition with a single key, derived from the user’s credentials. The key must be available before the OS can boot, so the user is prompted for their PIN or password at boot time. FDE was the default until Android 6 and has been deprecated since Android 13.

File-Based Encryption (FBE) encrypts individual files with different keys, allowing more granular access control. FBE has been the default since Android 7 and is required since Android 10. It divides storage into two classes:

Device Encrypted (DE) storage: available immediately after boot, before the user authenticates. Used for system-critical functionality (alarms, phone dialer, Direct Boot). The DE key is derived without user credentials.
Credential Encrypted (CE) storage: available only after the user authenticates for the first time after boot. This is where all user data resides—messages, photos, application data. The CE key is derived from the user’s credentials, stretched through scrypt, and protected by keys held in the TEE (and, when present, the Secure Element).

CE key derivation: The role of credentials

Quarkslab’s Android Data Encryption in depth provides the most detailed public analysis of how the CE key is derived. The process, in simplified form, proceeds as follows:

The user’s credentials (PIN, password, or pattern) are stretched using scrypt, a memory-hard key derivation function, with parameters and salt stored in DE-protected files under /data/system_de/<uid>/spblob. The scrypt step is intentionally slow: it introduces a negligible delay for a single authentication attempt but makes brute-forcing computationally expensive.
The stretched credentials are combined with other material to form a password blob, which is sent to the Gatekeeper Trusted Application in the TEE. Gatekeeper verifies the blob against a stored password handle using an HMAC with an internal key. If verification succeeds, Gatekeeper issues a signed authentication token.
The authentication token is presented to Keymaster, which uses it to unlock an authentication-bound key. This key is used to perform the first decryption of the Synthetic Password, an intermediate secret stored in encrypted form on the filesystem.
The Synthetic Password is decrypted a second time using a key derived from the user’s credentials (the applicationId). This second decryption uses AES-GCM, which provides authenticated encryption: if the wrong credentials are supplied, the GCM tag will not match and decryption will fail. This is the cryptographic check that ultimately binds the CE key to the correct credentials.
From the Synthetic Password, the system derives the CE file encryption keys used by the Linux kernel’s fscrypt subsystem to decrypt individual files.

The critical observation is that user credentials are cryptographically embedded in the key derivation chain. There is no way to bypass them purely through software attacks: an attacker who compromises the TEE can bypass the authentication token check, but they still need to brute-force the credentials through scrypt to derive the correct key material.

Key derivation with a Secure Element (Weaver)

On devices with a Secure Element, the key derivation process includes an additional step. Instead of relying solely on Gatekeeper in the TEE, the system uses Weaver, a service running on the Secure Element. Weaver stores a secret value that is released only upon correct credential verification and enforces its own independent rate-limiting.

This means that even if an attacker fully compromises the TEE, or other Trusted Applications as shown by Synacktiv’s Kinibi TEE blogpost, they cannot extract the Weaver secret or bypass its throttling, if implemented properly. Brute-forcing must proceed online, at the rate the Secure Element permits, which, for a device like the Pixel with Titan M, means exponential backoff.

Attack vectors

With the architecture established, we can now map the specific attack surfaces that forensic tools exploit. These fall into two main categories, corresponding to teo device states: powered off or powered on but never unlocked (BFU), and powered on and previously unlocked (AFU).

BFU attacks on devices without a Secure Element

The most complete form of BFU attack targets the boot chain itself. If an attacker can compromise the Boot ROM or the preloader, they can break the entire chain of trust, including the TEE.

BFU attack diagram on a device without a Secure Element: the attacker exploits the Boot ROM or enters recovery mode, compromises the preloader and Trusted OS, extracts the scrypt hash, and performs offline brute force of the PIN

The attack proceeds as follows:

Boot ROM exploitation: the attacker connects to the device via USB and exploits a vulnerability in the Boot ROM (or uses a vendor-specific download/recovery mode, such as MediaTek’s Download Mode or Qualcomm’s EDL mode) to gain code execution before the bootloader runs.
Boot chain patching: with Boot ROM-level access, the attacker patches or replaces the preloader to disable secure boot verification of subsequent stages. This allows loading a modified Trusted OS and modified Trusted Applications.
TEE patching: the attacker replaces or patches Gatekeeper to accept any credentials and issue valid authentication tokens regardless of input. They also patch or extract keys from Keymaster. As Quarkslab demonstrated in their proof-of-concept on Samsung A22 devices (MT6769V and MT6833V SoCs), this involved patching Samsung’s TEEGRIS operating system: first disabling verification of the root filesystem, then disabling TA signature verification, and finally patching Gatekeeper’s credential comparison to always succeed.
Key material extraction: with a rooted Android system and a compromised TEE, the attacker extracts the encrypted Synthetic Password and the intermediate decryption result from Keymaster.
Offline brute force: the attacker now has all the material needed for offline brute-forcing. The brute-force loop is:
- Generate a candidate password
- Stretch it through scrypt with the stored parameters
- Derive the applicationId
- Attempt AES-GCM decryption of the Synthetic Password
- If the GCM tag matches, the correct credentials have been found

Because this brute-force runs entirely offline, on the attacker’s hardware, it is bounded only by computational resources and password complexity. A numeric PIN of six digits or fewer is trivially recoverable. Even longer numeric PINs fall quickly on dedicated hardware. Only a strong alphanumeric and symbols password provides meaningful resistance.

MediaTek devices are particularly vulnerable to this attack. Multiple MediaTek SoCs contain Boot ROM vulnerabilities that are publicly known and exploited by open-source tools such as MTKClient. Because Boot ROM code is immutable, these vulnerabilities cannot be patched: every device using the affected silicon is permanently compromised, regardless of Android version or security patch level. Quarkslab’s proof-of-concept targeted exactly this class of device, demonstrating the full chain from Boot ROM exploit to CE key recovery.

BFU attacks on devices with a Secure Element

When a Secure Element is present, the attack chain is fundamentally harder. Even if the attacker achieves everything described above, they still cannot extract the Weaver secret from the Secure Element, under normal circumstances. Chances of a Secure Element exploit are pretty low, especially as being distributed as part of a widely available forensics commercial suite.

BFU attack diagram on a device with a Secure Element: the attacker can compromise the Boot ROM, preloader, and Trusted OS, but the Secure Element enforces rate-limited online brute force

As anticipated, the Secure Element runs its own independent boot chain on physically separate silicon. Its keys cannot be extracted by the main SoC, and its rate-limiting logic is enforced in hardware that the attacker does not control.

The result is that brute-force can often only proceed online: each attempt must query the Secure Element, which enforces some kind of backoff. This slows down the attack significantly. A ten-digit PIN that falls in seconds to offline brute-force may take a long time against a properly implemented Secure Element. An alphanumeric password becomes likely unbreakable.

This is why, according to Cellebrite’s own February 2025 support matrix, brute-force capabilities are generally not available for Pixel devices with Titan M. The Secure Element is doing exactly what it was designed to do.

That said, the Secure Element is not immune to vulnerabilities. Quarkslab demonstrated code execution on the Titan M chip through CVE-2022-20233, a single-byte out-of-bounds write in the Keymaster task that could be exploited to hijack execution flow. This vulnerability has since been patched, but it demonstrates that Secure Elements, while vastly more resistant than TEE-only configurations, can still have issues. Google is offering up to $1,500,000 for a zero-click vulnerabilities on the Pixel Titan M2.

AFU attacks: The lock screen is just UI

After the first unlock, the threat model fully changes. In AFU state, the CE decryption keys are loaded in memory and remain there. The lock screen is no longer a cryptographic barrier, it is just a user interface element, a screen overlay that prevents interaction but does not re-encrypt data.

This means that an AFU attacker does not need to brute-force credentials at all. They need to achieve code execution in the kernel or a privileged process, at which point they have direct access to the decrypted filesystem. The lock screen is bypassed, and no encryption needs to be broken.

The primary attack surface in AFU state is the USB interface. When a device is locked but in AFU state, the USB controller remains active and exposes the device’s kernel to a substantial attack surface.

USB attack surface diagram: an attacker connects a peripheral emulator to the USB controller, which reaches approximately 200 kernel drivers (MTP, MSC, HID, Audio, CVC, and others) behind the lock screen

As the diagram illustrates, a peripheral emulator connected to a locked device’s USB port can interact with the kernel through approximately 200 reachable drivers, including MTP (Media Transfer Protocol), MSC (Mass Storage Class), HID (Human Interface Device), Audio, and CVC (Communication Voice Class) subsystems. Each of these drivers is a potential attack surface for memory corruption vulnerabilities.

The exploit used by Cellebrite against a Serbian activist’s device in December 2024, as documented by Amnesty International, attempted to use at least three Linux kernel USB driver vulnerabilities:

CVE-2024-53104: a vulnerability in the USB Video Class (UVC) driver.
CVE-2024-53197: an out-of-bounds write in the ALSA USB-audio driver, triggered when a malicious USB device provides a bNumConfigurations value exceeding allocated memory. This vulnerability affects legacy code present since Linux kernel 2.6.26 (2008) and was confirmed by CISA to be actively exploited in the wild.
CVE-2024-50302: a memory leak in the HID subsystem that exposes uninitialized kernel memory, including encryption keys and authentication tokens, when processing crafted USB HID reports.

The Cellebrite Turbo Link device, a specialized hardware adapter that connects between the forensic workstation and the target device, likely functions as a peripheral emulator capable of presenting itself as multiple USB device types in rapid succession, probing for each vulnerability to achieve kernel-level code execution.

Many of these USB drivers are loaded by default and remain reachable even when the device is locked. The kernel does not distinguish between a legitimate USB accessory and a malicious peripheral emulator, thus this is the main weakness that AFU exploitation often relies upon.

AFU attacks on locked devices in practice

AFU attack flow: USB exploit achieves kernel code execution, bypassing the lock screen to access user processes and decrypted CE storage

Once the attacker achieves kernel code execution through USB driver exploitation, the lock screen is irrelevant. The attacker can:

Directly read the decrypted filesystem, since CE keys are already in memory
Perform a Full File System (FFS) extraction of all user data
Access application data, messages, photos, credentials, and metadata
Potentially install persistent backdoors

As we already knew, a device in AFU state is fundamentally less secure than a device in BFU state, regardless of the strength of the user’s password or the presence of a Secure Element. The Secure Element protects credential-derived keys at boot; it does not protect already-decrypted data in memory after the first unlock.

This is confirmed by Cellebrite’s February 2025 support matrix, which shows AFU extraction capabilities even for devices (including recent Pixels with stock Android) that resist BFU attacks. Notably, according to the same documentation, GrapheneOS on Pixel devices resists AFU extraction, probably thanks to the attack surface reduction and the USB restrictions that are implemented beyond stock Android.

A note on iOS: checkm8 and USB Restricted Mode

Apple devices face analogous attack surfaces. The checkm8 exploit, publicly released in 2019, targets an unpatchable Boot ROM vulnerability present in all Apple devices from the iPhone 4S through the iPhone X (A5 through A11 SoCs). Like MediaTek Boot ROM vulnerabilities, checkm8 cannot be fixed through software updates: every affected device is permanently exploitable.

For newer Apple devices, AFU attacks rely on USB-based exploitation. Apple introduced USB Restricted Mode in iOS 11.4.1 to mitigate this: if the device has been locked for more than one hour, the Lightning or USB-C port is restricted to charging only, disabling data connections that forensic tools require.

However, Quarkslab’s analysis of CVE-2025-24200 (reported by CitizenLab) revealed that USB Restricted Mode was bypassable. The vulnerability, reported by Citizen Lab and patched in iOS 18.3.1, allowed a physical attacker to re-enable USB data connections on a locked device by exploiting a flaw in the Accessibility framework. The profiled daemon, which handles device management settings, failed to check whether the device was locked before processing requests to disable USB Restricted Mode. In other words, the USB port was only soft-disabled: something as simple as a logic bug in the policy enforcement allowed it to be re-enabled.

Defensive implications

The attack vectors described above lead to a clear set of defensive priorities.

BFU is your best defense

The most impactful single action when facing potential device seizure is to power the device off. This returns it to BFU state, where:

CE storage is encrypted and keys are not in memory
USB driver exploitation cannot yield decrypted data
The attacker must compromise the boot chain and brute-force credentials
On devices with a Secure Element, brute-force is rate-limited by hardware

Auto-reboot: returning to BFU automatically

If a device cannot be manually powered off, an automatic reboot mechanism provides the next best defense. After a configurable period without user authentication, the device reboots, returning to BFU state and purging decryption keys from memory.

GrapheneOS has implemented this feature for years. Apple introduced it in iOS 18. Stock Android on Pixel devices gained a limited version in Android 15, but its implementation remains less configurable and less aggressive than GrapheneOS’s. The feature is the most useful if the timeout is short (2-4 hours) and loses its value when its multiple days, as Google enforces likely as a result of negotiation with law enforcement.

USB port restriction

Disabling USB data transfer when the device is locked directly eliminates the AFU attack surface described above. Android 15 introduces USB restriction options; iOS has had USB Restricted Mode since version 11. GrapheneOS provides more trustworthy and configurable USB restriction.

Password strength

The brute-force analysis makes the case for strong passwords unambiguous:

A 4-digit PIN: trivially crackable offline, and crackable even online within hours to days
A 6-digit PIN: trivially crackable offline; crackable online within days to weeks depending on rate-limiting implementation
A pattern: equivalent to or weaker than a short PIN in entropy
An alphanumeric password of 10+ characters with mixed case and symbols: computationally unlikely to brute-force offline through scrypt; almost impossible to brute-force online against a Secure Element

The password is only required at boot. Biometric authentication (fingerprint, face recognition) handles daily unlocking, unless the user is in a jurisdiction where physical coercion is likely, whether lawfully or not. The marginal inconvenience of entering a strong password once after each reboot is minimal compared to the protection it provides.

Device choice

According to Cellebrite’s own February 2025 documentation:

MediaTek-based devices: effectively no mitigation possible against BFU attacks due to unpatchable Boot ROM vulnerabilities.
Most non-Pixel, non-Samsung Android devices: considered unlockable, with few exceptions, due to a combination of delayed security updates, weak TEE implementations, and absent Secure Elements.
Samsung devices (Exynos): partial protection, varying by model and patch level.
Google Pixel with stock Android: resistant to BFU attacks on recent models, but AFU file system extraction is possible.
Google Pixel with GrapheneOS: resistant to both BFU and AFU attacks on recent models (6a and newer). This is the strongest protection available on any Android device.

It is worth noting that alternative Android distributions such as LineageOS or CalyxOS, while valuable for other reasons, do not meaningfully change the forensic unlocking picture from the stock or vendor ROM.

Application-level encryption

Applications that implement their own encryption layer with a separate password can provide defense-in-depth against full device compromise. Password managers’ master password vaults are a good example: even if the entire device filesystem is extracted, the vault remains encrypted under a key that the forensic tool has not obtained.

However, the effectiveness of application-level protection depends on several factors: whether the app actually implements its own encryption independently from the OS credential protection, whether decryption keys remain in memory after first unlock (making them vulnerable to AFU extraction), whether the app relies on the system biometric authentication (which, without a Secure Element, is broken along with the rest of the OS key hierarchy), and whether notifications or message previews are cached in plaintext outside the app’s encrypted storage.

Conclusion

The way these tools operate is not magic nor secret. The more we collect samples, reverse engineer and read promotional and support material, the better we understand capabilities and defenses.

As we said many times these tools simply shouldn’t commercially exist. The companies that build these tools are active participants in the zero-day vulnerability trade, stockpiling security flaws that weaken every device, for every user, everywhere. The technical defenses described here are effective but place the burden on individuals and communities.

References

Quarkslab, “Android Data Encryption in depth” (2023)
Quarkslab, “Introduction to Trusted Execution Environment: ARM’s TrustZone™” (2018)
Quarkslab, “A Deep Dive into Samsung’s TrustZone™” (series)
Quarkslab, “Attacking Titan M with Only One Byte” (2022)
Quarkslab, “First analysis of Apple’s USB Restricted Mode bypass (CVE-2025-24200)” (2025)
Quarkslab, “Reverse Engineering Samsung S6 SBoot” (series)
Synacktiv, “Kinibi TEE: Trusted Application exploitation” (2018)
Amnesty International Security Lab, “A Digital Prison: Surveillance and the suppression of civil society in Serbia” (2024)
Amnesty International Security Lab, “Cellebrite zero-day exploit used to target phone of Serbian student activist” (2025)
GrapheneOS, “Discussion on Cellebrite Premium July 2024 documentation” (2024)
Samsung Knox, “Encryption systems description”
Google, “Titan Hardware Chip documentation”
Google, “Titan M makes Pixel 3 our most secure phone yet” (2018)
Android Source, “File-Based Encryption”
Android Source, “Full-Disk Encryption”
Bjoern Kerler, “MTKClient” — open-source tool exploiting MediaTek Boot ROM vulnerabilities

Morpheus: A new Spyware linked to IPS Intelligence

Thu, 23 Apr 2026 00:00:00 +0000

If you are an activist or journalist concerned about the security of your devices, or if your device has been seized and you need technical assistance, contact us.

We have analyzed a sample of a previously unknown Android spyware, likely developed in Italy. It is named “Morpheus”, version 2025.3.0, and we describe its capabilities, including abusing accessibility features, automatically enabling ADB and issuing commands, disabling microphone and camera indicators, pairing additional WhatsApp devices, taking screenshots, recording audio and video, and more. We link part of the infrastructure to IPS Intelligence, and discover some potentially related companies, Rever Servicenet and Iris Telecomunicazioni.

The Spyware

Infection

As reported many times both by us and other well-documented cases by activists and other sources, the infection mechanism is the usual for low cost spyware: deny a service to the target and then social engineer them to install an app in order to restore or obtain such service. This is often applied to mobile data, but not necessarily restricted to it. In this case, the person under attack received an SMS pointing to assistenza-sim.it. The app impersonated the Fastweb ISP.

First Stage: The Dropper

The dropper uses the com.android.cored package name, with versionCode="1" and versionName="0.9.23".

The dropper application is a fork of solrudev’s SimpleInstaller, an open-source rudimentary Android package installer wrapper that makes it easy to install third-party apps.

The code of the installer’s io.github.solrudev.simpleinstaller.sampleapp.ui.MainActivity was edited to automate the installation of the second stage of the spyware. The second stage is directly embedded inside the APK at /assets/mobile-config.apk.

Once the person under surveillance executes the dropper:

It checks if the second stage is already installed querying for the com.android.core package name
If it is not the case, it copies the mobile-config.apk from the assets folder of the APK to the device storage
If an external intent with action action_gustavo is received, the dropper installs the second stage
If the user has granted REQUEST_INSTALL_PACKAGES and READ_EXTERNAL_STORAGE permissions to the dropper, it installs the second stage

Infection first stage: informing of an update

Infection first stage: second stage successfully installed

Second Stage: The Agent

The agent uses the com.android.core package name, with versionCode="1" and versionName="2025.3.0".

Inside of the AndroidManifest.xml the application defines multiple activities, receivers and services. The most interesting are:

com.android.main.SplashScreenActivity with label Mobile Config
com.android.main.FakeServiceActivity with label Impostazioni microG alias of SplashScreenActivity, posing as a fake microG Settings icon.
com.android.main.Launcher2Activity with label PlayProtect alias of SplashScreenActivity, posing as a fake Google Play Protect icon.
com.android.main.LauncherActivity with label Mobile Config alias of SplashScreenActivity
com.android.main.MainActivity
com.android.main.AboutAppActivity, showing a generic about UI.
com.android.main.EmptyActivity
com.android.main.ForcePermissionsActivity, forcing the user to enable the required permissions.
com.android.broadcast.CoreBroadcastReceiver, a receiver with RECEIVE_BOOT_COMPLETED permission.
com.android.admin.DeviceAdminSampleReceiver, a receiver with BIND_DEVICE_ADMIN permission.
com.android.core.CoreService, a service with BIND_ACCESSIBILITY_SERVICE permission.

The CoreService handles all the Accessibility actions. Accessibility Services are designed to help users with disabilities access their devices. Such applications can read the whole screen, click on graphical elements, interact with other applications. Unfortunately, this powerful capability is often exploited by malware, prompting Google to roll out a series of mitigations.

The sample declares isAccessibilityTool="true" in the manifest to pose itself as a legitimate accessibility tool and to obtain the full Accessibility permission set. Starting with Android 13, apps that are sideloaded (installed outside of Google Play) are blocked from obtaining Accessibility privileges due to the Restricted Settings feature. The dropper‑installation technique circumvents this restriction, allowing the malicious app to gain the needed permissions despite the intended protection.

The CoreBroadcastReceiver listens for the system’s boot‑completed broadcast, enabling the app to re‑launch automatically after a device reboot and thereby maintain persistence. The DeviceAdminSampleReceiver is the component that receives Device‑admin callbacks, allowing the application to acquire and manage Device‑admin privileges.

When the person under attack launches the app, they see a screen that offers to scan for problems with either the SIM or the network connection, a phishing pretext designed to coerce them into cooperation.

Once the scan finishes, the Update configurations button becomes enabled; tapping it opens the Settings page where the app requests Accessibility privileges.

The second stage (agent) welcome screen

Techniques

Abusing Overlay & Accessibility to Bypass Biometric Authentication

If the preceding shenanigans weren’t alarming enough, the sheer number of permissions the app requests further confirms its malicious intent.

Permissions request from the second stage

The SYSTEM_ALERT_WINDOW permission is extremely powerful as it lets a malicious app draw UI elements on top of every other app and even system components. This is often abused by malware to trick the user into interacting with a legitimate-looking app while performing unwanted actions on a previously installed underlying app, such as WhatsApp.

This overlay is displayed above all other UI elements, including system interfaces such as notifications, the status bar (battery indicator, time, etc.), volume level indicators, and the screenshot overlay.

By analyzing where the spyware uses this overlay window we discovered that it implements various Accessibility Workflows. Each workflow consists of a sequence of steps that specify which Accessibility action to perform—e.g., clicking a button, locating a UI element by XPath or by its visible text, and so on.

After granting Accessibility permissions, the spyware starts a Permission Workflow that creates an overlay with a fake update process and a fake reboot screen. In background, the workflow performs all the steps to grant all the needed permissions. This includes enabling Developer Options, turning on Wireless Debugging, and locally pairing to the ADB daemon.

Conveniently, during the fake update the app disables the touchscreen by setting FLAG_NOT_TOUCHABLE on the whole full-screen overlay, leaving the user partially unable to respond to the infection.

The second stage performing a fake software update

The second stage displaying a fake reboot overlay

Code snippet showing the workflow for granting Device Admin capabilities

After the fake update, the spyware launches a second workflow called WhatsApp Workflow. This workflow shows an overlay that presents a survey asking the targeted person what problem they’re experiencing, while in the background it silently opens WhatsApp and links a new malicious device.

On devices where Android fingerprint login is enabled, WhatsApp Linked Devices requires a biometric confirmation before the pairing can complete. This prevents malicious actors from adding themselves and access all the chats and messages while the phone is unlocked.

However, the spyware handles this scenario by triggering WhatsApp’s biometric request in the background and displaying a fake biometric UI on the overlay. When the person under surveillance taps the fingerprint sensor on the counterfeit dialog, they unknowingly grant the spyware full access to their WhatsApp account.

The agent’s overlay requiring biometric authentication, while using it to add a WhatsApp device underneath

Elevating Privileges through ADB

As explained earlier, during the Accessibility Workflow the spyware turns on Wireless Debugging and pairs itself with the ADB daemon. This gives it elevated shell privileges and is performed by the omglib-impl.jar component.

The ADB connection feature is named DISPERAZIONE

The agent establishes a local communication channel to ADB, and then executes a prepackaged shell script named commands.txt. The script is organized in four distinct phases, each covering a different aspect of the Android privileges it requires.

In the first phase, the agent performs a series of pm grant commands to silently grant itself every dangerous runtime permission it had declared without any user prompt. WRITE_SECURE_SETTINGS and USE_ICC_AUTH_WITH_DEVICE_IDENTIFIER (the latter normally reserved for carrier apps) are granted in the same batch. The agent then registers as a notification listener, allowlists itself from Doze (excluding itself from the battery saving mode) via cmd deviceidle whitelist, lifts every background execution restriction through appops, and finally promotes itself to Device Administrator with dpm set-active-admin. By the end of this phase the agent has unprompted access to essentially every sensitive data source on the device, unconstrained background execution, and protection against non-administrative uninstall.

The second phase consists of a number of anti-detection commands. Three commands in particular are worth highlighting:

cmd device_config put privacy camera_mic_icons_enabled false default
settings put global package_verifier_user_consent -1
[AND_SDK>30] service call sensor_privacy 10 i32 0 i32 0 i32 1 i32 0

The first line disables the green camera and microphone indicator introduced in Android 12. The camera_mic_icons_enabled key lives in Android’s SystemUI DeviceConfig, the service managing the flag used by SystemUI to decide whether to render the indicator. This flag is not available to end-users and normal applications, but it can be performed by the shell user through ADB. The exact command line used by this sample was circulating on XDA for years. The issue was only silently fixed in Android 16, which now returns a SecurityException when setting dangerous flags.

The second line disables Play Protect’s install time verifier consent. The third, guarded by an Android 11+ check, is a raw binder transaction into SensorPrivacyService, the system service backing the Quick Settings “Camera access” and “Microphone access” toggles. If the user had explicitly hit the microphone kill switch in “Quick Settings”, this one liner silently flips it back.

In the third phase the spyware disables a number of known Antivirus software, including Google’s own SafetyCore, Bitdefender, Sophos, Avast, AVG, Malwarebytes, along with a handful of smaller “cleaner/antivirus” apps popular on low end devices. None of these requires root, and persists across reboots since the Android security model treats user’s installed anti-malware software like ordinary apps.

In the fourth phase the sample executes per-OEM command blocks that target the battery optimization and “phone manager” packages each brand of Android distribution uses to aggressively kill background processes. Oppo/ColorOS, Samsung, Motorola, Realme, and Huawei each get their own setup. The most thorough block is for MIUI/HyperOS: the script disables roughly a dozen MIUI specific packages then issues a sequence of commands to control behaviors like autostart, background activity, background location, and lock screen display, as MIUI restricts some by default even after the equivalent AOSP permissions are granted.

The MIUI block ends with a final line:

settings put system locked_apps "[{\"u\":0,\"pkgs\":[\"com.android.core\"]},{\"u\":-100,\"pkgs\":[\"com.jeejen.family.miui\"]}]"

locked_apps is a MIUI specific secure settings key backing MIUI’s “Lock app in Recents” feature, which pins a package against user initiated force stop from the task switcher.

Attribution

“Aprafoco”, Spaghetti & Gomorra

In the spyware code we found several Italian linguistic artifacts, and references to Italian pop‑culture items and television series.

The sample contains a native library named libaprafocofb.so. Its name (“A pra foco”, a malapropism for “a tra poco” meaning “in a short time”) comes from a well‑known on‑air slip by journalist Luca Giurato. This library is a fork bomb (hence the fb suffix in the name) that repeatedly creates new processes to exhaust system resources, forcing a reboot.

Inside the Downloader component, used to download new modules remotely from the Command-and-Control server, a class named GomorraException is used to raise network-related errors.

Code snippet invoking a GomorraException with a quote from the series

Second code snippet invoking a GomorraException with a quote from the series

Finally, a function named spaghettiTime is present to derive an MD5 hash.

Targets

Even though the spyware appears to be made in Italy, our analysis revealed translations and artifacts for several languages, both in the on‑screen text and in the strings used by the Accessibility Workflows.

Specifically, the spyware includes support for devices with the following locales: Italian, English, Spanish, Romanian, French, and Arabic. The depth of support and the set of available features, however, differ considerably from one locale to another.

The spyware also has multiple customization to be able to run on different Android ROMs and OEM devices, namely: Xiaomi / Redmi / POCO (MIUI & HyperOS), Realme (realmeUI), Samsung (OneUI), OnePlus/OPPO (OxygenOS/ColorOS), Motorola / Nokia / Google (AOSP Stock, CalyxOS), and more.

Finally, it’s important to highlight that the sample uses Google’s Firebase services, leaking to Google the correlation between spyware infection and the target’s Google identity, as also Spyrtacus does.

The Malware Infrastructure

The malware’s configuration data are stored in an encrypted format. After decryption, the payload reveals a network endpoint: [number].game‑host.org. DNS resolution for this domain returns the IP address 109.239.245.172 and listens on TCP ports 8443 and 4443. game‑host.org is one of the many domains offered by Oracle’s DNS hosting service Dyn.

The IPv4 address 109.239.245.172 belongs to air2bite s.r.l. ORG‑AS1270‑RIPE, a retail Internet service provider. A search for other hosts that share the same fingerprint yields a precise set; all of the endpoints indexed by Shodan are located in Italy. While a few of these servers are hosted on networks operated by other consumer or business ISPs such as TIM, the majority reside in IP ranges owned by Mobile Service Integration. Representative examples include 195.120.31.91 and 212.210.1.211.

All of the related RIPE role objects reference the same contact MSI50-RIPE, which lacks a name, physical address, or any corporate identifiers: details that are normally provided for a legitimate business. The listed e‑mail address, mobservint@gmail.com, is a free, ad‑hoc account. This combination of generic identifiers (e.g., assistenza, service, mobile, sim, internet, navigazione) and free‑mail contacts and services is a pattern frequently observed among surveillance‑technology providers and distributors.

“Mobile Service Integration” name appears in many small ranges (4-16 ips), announced by TIM. This is a classic business scenario for small enterprises to have their own naming in the registry. The IPs in these ranges also host other services. For instance, 217.56.196.66 has a TLS service on port 443 that presents the following self signed certificate.

Subject: C=IT, ST=Italia, L=Lazio, O=IPS, OU=Mobile, CN=www.mcgplus.mobile.com/emailAddres

The certificate’s Organization (O) attribute is explicitly set to the literal string “IPS”. Moreover, other IP addresses that exhibit the same fingerprint as the spyware, such as 2.116.18.124, show a corresponding RIPE database record that associate directly IPS with “Mobile Service Integration”, using what looks like a fake company address.

Whois information for 2.116.18.120 - 2.116.18.127 linking IPS INTELLIGENCE PUBLIC SECURITY S.P.A. to Mobile Service Integration

Recommendations

If you believe you’re an at‑risk individual or suspect you’ve been targeted, follow these steps right away.

Review Recent Activity

Recall anything unusual: a surprising message, a phone call, or a service outage. Did anyone ask you to install software, click a link, or share credentials? Did any of your contacts get an alert from Signal or WhatsApp that your device changed?

Verify Linked Devices on Messaging Apps

App	How to Check
WhatsApp	Menu → Settings → Linked Devices
Signal	Menu → Linked Devices
Telegram	Menu → Settings → Privacy & Security → Active Sessions

If anything looks off, terminate the session immediately and change the app’s PIN/password.

Audit Google Account Sessions

Open Google Account → Security and sign-in → Your devices.
Review the list of devices and locations.
Click Sign out on any device you don’t recognize.
Enable 2‑step verification for added protection.

Check Battery Usage

Spyware constantly running in the background can cause noticeable battery drain. Go to Settings → Battery and review which apps are consuming the most power: unfamiliar or system‑looking apps near the top of the list are a red flag. If your phone’s battery life has become noticeably shorter, check the usage charts (where available) to identify when the drain started, as this may help pinpoint when the infection occurred.

Reach Out for Help

If any of the above checks raise red flags, contact us or your trusted support organization as soon as possible.

IoCs

IPs:

109.239.245.172
195.120.31.91
212.210.1.211

Domains:

assistenza-sim.it and subdomains
gamehosts-621ba.appspot.com

Android package names:

com.android.core
com.android.cored
com.android.corew

Conclusion

The spyware we have identified, Morpheus, follows the classic “low‑cost spyware” model: it makes up for the absence of zero‑day exploits with an elaborate social‑engineering narrative and a surprisingly large amount of effort spent supporting multiple ROMs, device models, and languages.

While IPS Intelligence is a well‑known commercial surveillance provider, this is, to our knowledge, the first report linking them to the distribution and operation of spyware.

Morpheus is extremely invasive: it can record audio and video, silently pair a WhatsApp device, erase evidence, and deliberately weaken the security of the infected phone, among other malicious capabilities.

As repeatedly emphasized by EDRi, numerous NGOs, and other civil‑society organizations, tools of this nature should not exist. The companies that develop, sell, and operate them, as well as the entities that commission their use, must be held accountable.

Italian spyware maker SIO still developing and distributing Spyrtacus

Thu, 09 Apr 2026 00:00:00 +0000

We analyzed a 2025 sample of the Spyrtacus spyware, version 8.71. Among its capabilities it can record the screen and take screenshots, record voice calls, export WhatsApp messages, upload files, and dynamically execute downloaded modules. We confirm attribution to SIO S.p.A. and provide a small set of IoCs to detect infections of this malware family.

Flowchart of the infection, control, and collection process

The Spyware

Infection Method

Like the majority of low-cost spyware, infection starts by receiving an SMS instructing the victim to install a carrier‑provided app to keep their mobile service working. The SMS contains a tinyurl.com shortened link, which, after a series of redirects, points to a phishing page that mimics the victim’s mobile provider website. The threat actor maintains pre‑made pages for all major Italian carriers.

In this case the URL displays a page that imitates ho. mobile (ho‑mobile.it) and offers a download link to the malicious APK.

The application itself pretends to be the ho. mobile official app, advertising a new 5G promo. This tactic is common among low‑cost spyware families that rely on coercing users into installing malicious apps rather than employing sophisticated exploit chains.

Screenshot of the app information

The Agent

In our case the application used the package name com.elysium.core, while its main activity was named it.taog.app.MainActivity. The application manifest reports versionCode="871" and versionName="8.71".

The app is signed with a key belonging to:

CN=Aziz Oukil, OU=Unknown, O=Unknown, L=Sant'Anastasia, ST=NApoli, C=IT

It is obfuscated with DexGuard 9.x. However, a string containing spyrtacus-agent can be found in the resources.

The Spyrtacus name is not new; this sample is likely a newer variant of the well‑known agent used by SIO.

During its first run the malware gathers device information, including IMEIs, and sends everything to a Dispatcher server via the /Dispatcher/GetParams endpoint. If no errors occur, the Dispatcher returns a set of parameters that enable or disable the spyware’s features.

Some of the parameters control whether the malware:

uses FTP to collect files (and whether those files are encrypted),
records ambient audio,
takes screenshots at a configurable interval, and
installs a legitimate app as a second stage from Google Play

The malware can also download additional remote modules. The modules are AES‑encrypted DEX files that are loaded from memory through Android’s InMemoryDexClassLoader. The key to decrypt the modules is retrieved along with other parameters from the Dispatcher.

It is worth noting that in our sandboxed analysis we kept our sample offline, so we could not retrieve any of the module payloads.

During the onboarding process the Dispatcher server also returns the IP address of a Command‑and‑Control (C2) server that the agent will use thereafter. The C2 is then reached via a multitude of protocols including FTP, MQTT(S), HTTP(S), and Google’s Firebase services.

Screenshot of the app permissions

Attribution

To validate the server’s certificate, the agent loads a key store embedded in the res/raw/ks file. The key store contains the following Issuer line:

C=IT, CN=Artemide/Spartacus, L=Roma, O=Coliseum, ST=Unknown, OU=Lotta Greco‑Romana

The same certificate is being served from an IP address belonging to AS206173 (an ISP named “NAVIGAZIONE INTERNET”, i.e., “Internet Connectivity”). This ASN is registered to SIOPLUS S.R.L. (VAT ID 10253360969), a subsidiary of SIO S.p.A..

All of SIO subsidiaries

To further confirm the attribution, we downloaded the favicon of one of the C2 servers.

The C2 favicon:

Favicon from a Spyrtacus C2 server

And the favicon from asigint[.]it, another SIO subsidiary:

Favicon from the official Asigint website

Extras

As we anticipated, the application uses Google’s Firebase services, which is common for most Android apps because Firebase is ubiquitous on the platform.

In the context of spyware, however, this is noteworthy since it leaks to Google the correlation between spyware infection and the victims’ Google identity.

The following are the Firebase projects used by Spyrtacus:

https://assist-online.firebaseio.com
https://dusty-apricot.firebasestorage.app

To further corroborate the attribution, and in line with what TechCrunch previously reported about the Neapolitan dialect found in the spyware’s comments, we uncovered the following strings in the binary:

LA CODA INVIO E' VUOTA -- STATT BBUON
PARAMETRI CONNESSIONE RICEVUTI -- SCATENATE L'INFERNO!

These strings reflect the developers’ native‑language comments and further tie the sample to the known SIO‑related code base.

Previous Samples & Analysis

In the past, other Spyrtacus samples were analyzed, in particular see the following list:

Version 8.65 from October 2024

https://tria.ge/241022-g6l3aatfkj/static1

Version 8.20 from April 2022

https://tria.ge/220401-nh9xrsbaa7/behavioral1

Version unknown from 2019

Apparently, a newer version of the spyware agent 8.72 exists, as documented: https://www.lawfulinterceptionacademy.eu/clir/.

IoCs

IPs:

5.56.12.150
89.46.67.218

Domains:

supporto-mobile.it
srv.servicemnt.com

Android package names:

com.elysium.core
it.taog
org.util.carriersvc
sys.base.service

C2 favicon SHA256 hash:

ef2e1c47166fe0c5ab3bf5216baf6ad6b96f759e15ac218d1a1a3cdcc9e0994f

Conclusion

As previously stated, and as supported by many NGOs, mercenary spyware should simply not exist. We reiterate the call to ban these tools and hold their operators and developers accountable, and we continuously advocate for that through our contributions and participation in the EDRi network.

Google is turning Android into a walled-garden monopoly. We must prevent it

Sat, 28 Feb 2026 00:00:00 +0000

In August 2025, Google announced that as of September 2026, it will no longer be possible to develop apps for the Android platform without first registering centrally with Google.

The registration will require all developers to:

Pay a fee to Google
Agree to Google’s Terms and Conditions and to any future changes Google may impose unilaterally.
Provide Google with their government-issued ID
Upload evidence of the developer’s private signing key
List all current and future application identifiers

This will be mandatory for every Android developer, even when they plan to distribute their app only on third-party channels (app stores like F-Droid, Aurora, Obtainium, etc), a clear violation of Europe’s DMA (Digital Markets Act).

The security argument

We are aware that most malware and spyware is distributed via the so-called side-loading mechanism (a pejorative term indicating the direct installation of software of your choosing on the device that you own without intermediaries).

Google’s argument is that by centralizing all the developer registration, it would be easier to detect and ban threat actors and malware, with Google’s oversight.

However, this argument does not stand the test of reality. Just a few months ago it was found yet again that malware was distributed on the Play Store itself.

On the contrary, alternative app stores like F-Droid are actively pursuing real mitigation strategies, like Reproducible Builds.

The use of spyware is not illegal in most European countries, and states such as Italy make extensive use of it, often without adequate safeguards or transparency. In this context, it is unclear what Google’s role would be if a state were to request the distribution of surveillance tools through its platform. Even if the company wished to oppose such a request, it might find itself legally obliged to authorize them.

In the meantime, however, Google may already have weakened or rendered impracticable independent alternatives, such as third-party app stores and decentralized distribution mechanisms, which currently represent spaces of pluralism and potentially greater security. Concentrating decision-making power in a single private entity does not equate to greater protection; rather, it creates a single point of political and legal pressure.

If the goal is to protect users, the solution is not to strengthen technological monopolies but to strengthen democratic rules, transparency, and public accountability. Making the use of spyware illegal at the European level would not eliminate crime, but it would provide a structural safeguard for fundamental rights, independent of the commercial or strategic choices of any single company.

Keep Android Open

We believe in an open ecosystem, not mandated by “Evil” companies. For this reason we signed the Keep Android Open letter.

Along with multiple organizations, we call upon Google to:

Immediately rescind the mandatory developer registration requirement for third-party distribution.
Engage in transparent dialogue with civil society, developers, and regulators about Android security improvements that respect openness and competition.
Commit to platform neutrality by ensuring that Android remains a genuinely open platform where Google’s role as platform provider does not conflict with its commercial interests.

EDRi, an ISP, and a packed agenda

Thu, 25 Dec 2025 00:00:00 +0000

This year, Osservatorio Nessuno embarked on projects in every direction: growing our technical work, expanding our software portfolio, strengthening our advocacy, and improving our internal structure.

We welcomed our first non-founding members, and we are deeply grateful for their participation. We presented the Osservatorio and both its advocacy and technical work at several events, took part in studies on NGOs and digital rights, taught classes to journalists, and contributed to work at the IETF.

We showcased a pre-release of Bugbane, released and deployed Patela and then upgraded it, joined the EDRi network, researched mobile forensics tools and spyware, and launched a spin-off NGO.

We also received unprecedented support: people donated funds, hardware, time, and knowledge. This collective effort made a real difference and allowed us to do more than ever before.

A new website

As some may have noticed, we also carried out a significant website redesign and reorganization. Beyond its updated visual identity, the new website focuses on accessibility and performance. It is fully static and uses no JavaScript, allowing it to work reliably in Tor Browser even with the safest security settings, while maintaining good accessibility.

We are grateful to everyone who reported accessibility issues in the past, and we remain committed to continuously reviewing and improving the website based on this feedback.

ProcioNet APS

Building on our experience of doing BGP from our own basement, we wanted to push for even greater independence and control. The first step, however, is navigating a complex landscape of commercial terms—peering, transit, backhaul—and engaging with a daunting number of intermediaries. While France, for instance, has a long-running tradition of nonprofit (or at least associative) ISPs, Italy has had very few examples, none of them fiber-powered. While we are not yet digging our own trenches, we aim to start by using the EU-funded Open Fiber network, pursuing economic sustainability in the short term and greater control over the longer horizon.

For this purpose, together with a group of friends, we founded ProcioNet APS. For English speakers, procione means “raccoon” in Italian, hence the wordplay with the Net suffix. APS stands for something close to a Social Promotion Association, which differs from the Osservatorio’s OdV (Volunteer Organization) status. ProcioNet aims to set up a network for its members, focused on research, accessibility, and reducing the digital divide. Services will be provided exclusively to members and, where applicable, at cost price.

Beyond being a technically challenging and enjoyable project, ProcioNet pursues one of Osservatorio Nessuno’s core political goals: reclaiming infrastructure. By doing so, we plan to layer internet-access–specific advocacy and research on top of it, pursuing privacy-preserving deployments where possible (an approach rarely taken by commercial providers), and resisting censorship both through technical means where feasible and through advocacy where it is not.

ProcioNet logo, a raccoon on a telegraph pole

European Digital Rights (EDRi)

In the spring, we began the process of joining EDRi as affiliates, the first step toward becoming full members. We are very grateful to the EDRi membership team for their friendliness and for guiding us through the process, as well as to all EDRi members who supported our participation.

EDRi is organized into working groups that address digital rights issues from different perspectives and through different strategies. As we do not have dedicated professional advocacy staff, we are currently focusing on issues closest to our mission, such as limiting the increase of securitization, the use of spyware against civil society, and efforts to weaken or bypass encryption, including initiatives like Chat Control.

We are still new to this space, and observing how the broader civil society ecosystem operates has been highly instructive. We hope to deepen our involvement and participate more actively, including in more in-person meetings, throughout 2026.

So many events

This year, members of Osservatorio Nessuno took part in a wide range of events, from academic cryptography conferences to documentary and journalism festivals, from self-organized gatherings to international standards bodies. Almost all of them were self-funded by the attending members, with only a few exceptions linked to our professional work. Despite limited resources, we managed to attend, contribute, and learn across communities that rarely meet in the same room.

Through these experiences, we observed how cost, travel, and accessibility shape who can be in the room and, by extension, who helps shape the technologies and policies that define the Internet itself. Most of this is not new; it’s been well studied and reported by other NGOs and researchers. This is simply our firsthand account!

We chose events based on a mix of personal interest, existing community ties, whether we knew people or trusted the atmosphere, and relevance to our advocacy and networking work as an organization. To reiterate, we did not use any Osservatorio funds for these trips. We are all volunteers, and our limited organizational finances are fully dedicated to maintaining our infrastructure, servers, utilities, and bandwidth, which already keeps our budget tight.

Event	Type	Area	Location	Participants	Ticket (€)	Cost estimate (€)	Total (€)
FOSDEM	Community	Open-source	Brussels	2	0	400	800
Real World Crypto	Academic	Cryptography	Sofia	1	380	500	880
IT NOG	Community	Networking	Bologna	1	0	100	100
SGKM	Academic	Media studies	Chur	1	290	600	890
Hackmeeting	Community	Activism / Tech	Cagliari	3	0	150	450
TumpiCon	Private	Security	Pinerolo	3	0	200	600
Global Gathering	Community	Advocacy	Estoril	2	40	500	1080
DIG Festival	Community	Journalism	Modena	1	0	100	100
Romhack	Community	Security	Roma	1	20	300	320
EDRi Privacy Camp	Community	Advocacy	Brussels	1	0	300	300
Tor Community Gathering	Community	Tor	Odense	2	0	400	800
RIPE	Int’l Org	Networking	Bucharest	1	400	900	1300
Transparency.dev	Community	Development	Gothenburg	1	0	500	500
Linux Day	Community	Open-source	Torino	1	0	0	0
IETF	Int’l Org	Standards	Montreal	1	990	1600	2590
39C3	Community	Activism / Tech	Hamburg	4	190	600	3160

See the Tor Projects’s blog post for a summary of the Tor Community Gathering and a bonus picture.

This table does not include all the events where we were invited to participate, or which were remote, such as presenting at Nexa Center, or at Primavera Hacker, where we gave a talk remotely.

Reflections on access and inequality

One recurring observation is that the further one moves from grassroots or volunteer-driven events, the higher the barriers to entry. Events like IETF, RIPE, or Real World Crypto, while essential, remain prohibitively expensive for unaffiliated participants. High registration fees, travel costs, and luxury venues make it difficult for small nonprofits, activists, or independent researchers to take part. This reinforces existing power structures and limits diversity in technical governance spaces. Travel funds and scholarships often serve to fill inclusion quotas, not to change the underlying structures or power dynamics. Their existence is, of course, welcome, but their impact is limited, especially in contexts like RIPE, where votes determine policy, or the IETF, where consensus often forms in side meetings and informal gatherings.

We would rather see less luxury and more accessibility:

no expensive cities or venues that are hard to reach or require difficult visas (why does the IETF still meet in the US or China?),
membership fees adjusted for nonprofits,
academic conferences free for students and affordable for small organizations,
an end to extravagant dinners and shows that exclude more than they include.

Politics of participation

Building authority in these spaces takes both years and connections. Employers, institutional backing, or professional titles often matter far more than anyone admits. Social backgrounds are downplayed or dismissed, and the result is often an insular bubble of tech workers who, despite good intentions, can become detached from the realities faced by underrepresented people. Worse, this detachment is sometimes masked by corporate narratives about improving the world through technology. The dissonance, even for us as relatively privileged Italian technologists, is difficult and at times sad to navigate.

Conclusion

ProcioNet isn’t quite ready to launch yet. We’re currently dealing with a substantial amount of paperwork and planning, as the operation is neither simple nor inexpensive. There are also a couple of developments we can’t announce just yet, but they build directly on the work we carried out this year.

As in the past few years, we’ll be around at 39C3, and we’ll also be back with a talk at FOSDEM, this time presenting Bugbane (see the schedule).

Patela v2: From certificates to hardware

Sat, 13 Dec 2025 00:00:00 +0000

A year ago, we wrote about Patela v1, our diskless Tor relay orchestration system built for exit nodes running on System Transparency’s stboot. The core idea was simple: nodes boot from read-only images, generate their own keys, and encrypt the keys locally and back them up on the server. In this post, we present an updated architecture that attests the nodes’ TPMs and removes the need for backups.

Evolving the architecture

In v1, node identity was based on mTLS certificate digests. We embedded client certificates at compile time using a script, and the SHA-256 hash of each certificate became the node’s database identity.

// V1: Identity = hash(certificate)
let node_id = sha256(client_cert);

The authentication flow was the following: the client presents a certificate, the server validates it against its CA, then the server uses the cert digest as a database key. However, it was both cumbersome and not what we ultimately wanted to achieve; we used it as a shortcut to start the early testing. Instead, the goal was to have the keys directly in the TPM, so that they could be stored inside the chip and never backed up, having them bound to the hardware, without requiring any disk.

V2 replaces this by making the TPM the source of truth:

// V2: Identity = (EK_public, AK_public, AK_name)
let node_identity = (ek_public, ak_public, ak_name);

Here’s how it works:

Endorsement Key (EK): Every TPM chip has a unique EK burned in at manufacture time. It cannot be changed, extracted, or cloned.
Attestation Key (AK): A key that proves the holder controls the specific EK. The AK is generated at runtime and certified by the EK.
AK Name: A cryptographic digest of the AK’s public parameters, computed by the TPM.

The server stores this triplet in the database:

CREATE UNIQUE INDEX idx_nodes_tpm_identity
ON nodes(ek_public, ak_public, ak_name);

Now, authentication to the configuration server requires physical possession of that specific TPM chip.

Trust on first use (TOFU)

We don’t validate EK certificates against TPM manufacturer CAs yet: when a node first connects, the server has no cryptographic proof the EK came from real hardware versus a software emulator. It’s on our todo list, but it doesn’t add a lot of guarantees in itself for our use case.

We then use TOFU: new nodes are created with enabled=0. An administrator should know when a new node is supposed to register, and can just run patela node enable <node_id> before the node can authenticate. This prevents random devices from auto-joining the network, while keeping the whole flow mostly automated.

Sometimes it’s ok to not have backups

The flow was this:

Client generates an AES key inside the TPM
Client generates Tor relay keys
Client encrypts relay keys using TPM-bound AES key
Client uploads encrypted blobs to server
On boot, client downloads blobs, decrypts with TPM

This approach enabled diskless Tor relays to maintain a persistent identity. Tor relays have reputation and are trusted in the network based on a few parameters, but mostly their stability and the time they’ve been running. Keeping long term keys is fundamental for our relays to be useful. The difference is that now the actual relay keys live only in TPM persistent storage, removing the requirement of backups. In the end, hardware failures should be rare enough for this type of binding to make sense.

As we have not fully integrated Tor with the TPM, the key is currently stored as a byte string in the non-volatile storage, meaning it is still possible to export it. As the TPM standard does not support operations for Ed25519, this is unlikely to change in the short term, though we acknowledge it is suboptimal.

Improved configuration

In V1, every relay got the same hardcoded torrc template, string-formatted:

// V1: One template to rule them all
let torrc = format!(r#"
Nickname {name}
ORPort {ip}:{or_port}
DirPort {dir_port}
ContactInfo your@email.com
ExitPolicy reject *:*
...
"#, name = relay.name, ip = relay.ip_v4, ...);

This worked until it didn’t, as per-relay customisation was difficult to manage: some nodes needed custom ExitPolicy rules, while others needed different bandwidth limits depending on upstream, and in more rare circumstances, custom ports. Every configuration change meant code changes, recompilation, redeployment.

Now V2 introduces a configuration cascade:

 │┌────────────────────────┐
 O ││ Default Config │
 v │└───────────┬────────────┘
 e │ │ 
 r │┌───────────▼────────────┐
 r ││ Per-machine Config │
 i │└───────────┬────────────┘
 d │ │ 
 e │┌───────────▼────────────┐
 ││ Per-instance Config │
 ▼└────────────────────────┘

This is directly translated into the database schema:

-- Global defaults for all relays
CREATE TABLE global_conf (
 id INTEGER PRIMARY KEY,
 tor_conf TEXT, -- torrc format
 node_conf TEXT -- JSON for network settings
);

-- Per-node overrides
ALTER TABLE nodes ADD COLUMN tor_conf TEXT;
ALTER TABLE nodes ADD COLUMN node_conf TEXT;

-- Per-relay overrides
ALTER TABLE relays ADD COLUMN tor_conf TEXT;

When a client boots, the server resolves the configuration hierarchy:

// Pseudo-code for config resolution
let config = global_conf
 .merge(node_conf) // Node overrides global
 .merge(relay_conf); // Relay overrides everything

We wrote a torrc parser (server/src/tor_config.rs) to handle Tor’s configuration format. The parser validates against known Tor options and merges configs intelligently, as later values override earlier ones.

Now the workflow looks like this:

# Set global defaults (one time)
patela torrc import misc/default.torrc default

# Override ContactInfo for basement nodes
echo "ContactInfo basement@example.com" >> basement.torrc
patela torrc import basement.torrc node --id 3

# Give one relay extra bandwidth
echo "RelayBandwidthRate 100 MB" >> high-bandwidth.torrc
patela torrc import high-bandwidth.torrc relay --id murazzano

Configuration changes are just database updates, as the nodes will fetch the most recent one associated with them from the server at startup.

Auth via partial attestation

The protocol uses TPM2’s make_credential / activate_credential challenge-response:

Client sends: EK_public, AK_public, AK_name
Server replies: encrypted_session_token = make_credential(EK_public, AK_name, session_token)
Client decrypts: session_token = activate_credential(encrypted_session_token)
The client has now a bearer token that can be used to authenticate itself to the server.

The session_token is a Biscuit bearer token. Only the TPM with the matching EK can decrypt it via activate_credential. If the client successfully returns the decrypted token, the server has cryptographic proof the client possesses the specific TPM hardware.

What’s Next

We have two end goals, which will take some more development time and understanding. The first one is to seal the TPM secrets and storage via measured boot, and complete the setup with System Transparency and coreboot. It is ambitious, but in the end the systems should look like the following:

Hardware root of trust measures Coreboot
Coreboot measures the System Transparency’s stboot
The TPM unseals thanks to the previous correct measurements
stboot boots only correctly signed and transparency logged images
Only publicly reproducible and auditable images can be run

This would make the system resistant to physical compromises: even if the server is physically seized, and if a different firmware or bootloader is run, then the TPM wouldn’t unseal, making the keys non-recoverable in any alternate setup.

There are also some more simple usability improvements in our todo list: an example is how to properly display to operators config diffs between global/node/relay configs before applying.

Testing

The code is on GitHub: osservatorionessuno/patela

To run a v2 development setup:

# Server setup
export DATABASE_URL="sqlite:$PWD/patela.db"
cargo sqlx database reset --source server/migrations -y

# Set required config
cargo run -p patela-server -- torrc import misc/default.torrc default
cargo run -p patela-server -- node set ipv4_gateway 10.10.10.1 default
cargo run -p patela-server -- node set ipv6_gateway fd00::1 default

# Run server
cargo run -p patela-server -- run

# Client setup (requires TPM2 or swtpm emulator)
export TPM2TOOLS_TCTI="swtpm:host=localhost,port=2321"
cargo run -p patela-client -- run --server https://localhost:8020

# Approve the node (from server terminal)
cargo run -p patela-server -- list node
cargo run -p patela-server -- node enable 1

Conclusion

The code is still small at around 6000 lines of Rust across client and server, readable (enforced by cargo fmt and clippy), and partially documented. We are also still working on it. As anticipated, we will continue exploring until our setup is as robust as we want it to be.

This wouldn’t be possible without:

System Transparency: For stboot and the vision of verifiable boot infrastructure
tss-esapi: For Rust TPM bindings

Bugs, questions, patches: github.com/osservatorionessuno/patela/issues

Bugbane: Simplifying consensual Android forensics

Fri, 05 Sep 2025 00:00:00 +0000

In this blog post, we introduce Bugbane, an open-source Android app that makes consensual mobile forensics more accessible by leveraging Android’s local ADB service. We explain how it builds on tools like MVT and AndroidQF, guiding users through acquisitions and malware checks directly on their devices. We also highlight its reproducibility, secure export features, and our call for community feedback as development continues. Bugbane is still in early testing and not yet ready for general end-user release. Check out the GitHub repository.

We are grateful to Rowen S for their contributions to the app development and in writing this post.

Background

Mobile malware is often used against those standing up to power, but open-source tooling, community collectives, and civil society organizations can provide help to people who may otherwise be excluded from centralized forms of support: case in point, Amnesty International’s investigation into Pegasus and release of the Mobile Verification Toolkit.

Besides MVT, the open-source forensics ecosystem is sustained by ongoing community contributions — for example, the regularly updated stalkerware indicators list by Echap, or the digital investigations/mobile forensics platform PiRogue Tools Suite. Projects like AndroidQF have helped establish a shared format for consensual Android forensics data, while organizations such as SocialTIC have produced and translated extensive documentation to make these practices more accessible.

We’ve used MVT for triaging many times over the years, including during the recent Italian Paragon scandal, and when supporting local community members whose phones have been seized and later returned. These cases highlight the widespread abuse of Cellebrite forensic tools for minor offenses, often carried out with little regard for the rights of the victims. The triaging process helps to decide if deeper follow-up is needed, and requires a separate computer from which to run the inspection, in-person access to the potentially-infected device, command-line skills, and additional troubleshooting ability. In practice, this means that triaging is not accessible to everyone who might need it.

There have been attempts to move triage and analysis onto the device itself, most notably apkqf, which explored what level of on-device checks are possible using standard Android Platform APIs. These APIs are generally too limited to extract much of the information needed for reliable compromise checks, which are generally performed using Android Debug Bridge from a separate device. By design, most of the data available via ADB isn’t exposed to standard Android applications, due to Android’s increasing privilege separation and privacy protections; this is a good thing, because it means a given application installed on an Android phone is limited in how much sensitive information it can acquire, but it makes on-device analysis a little more difficult.

Since Android 11, ADB has also been available locally via Wireless Debugging. The pairing flow uses a PIN-based SPAKE2 exchange to authenticate and establish a TLS connection. While the common case is pairing from an external computer, the same flow can be done entirely on-device, letting an Android application on a stock (unmodified, unrooted) system talk to its own local ADB service via a short sequence of user-controlled steps. Apps like Shizuku use this functionality to acquire extra capabilities for standard Android applications, such as the ability to execute commands as the shell user.

Bugbane

We’re pleased to announce an early preview of our new project Bugbane, an open-source Android application to help users check their devices for indicators of malware by using a local ADB service. Bugbane implements a user-friendly wizard to guide users through setup, data acquisition, and self-triage steps:

Connecting to a trusted Wi-Fi network
Granting notification permissions (necessary for the pairing flow)
Enabling developer options (required for ADB use)
Enabling Wireless Debugging
Pairing Wireless Debugging

Once pairing is complete, Bugbane can perform an AndroidQF-compatible, one-click acquisition and save it to local storage; “acquisition” is the MVT/AndroidQF term for data used to scan for signs of compromise. Users can perform as many acquisitions as they want; disabling developer options after every acquisition is recommended in the app, and users can use the Bugbane wizard to re-enable it for any subsequent acquisitions.

Bugbane downloads the same indicators of compromise as MVT, and keeps the indicators up to date. Those indicators are used to check an acquisition for malware/stalkerware, just like with MVT.

Your browser does not support the video tag.

Bugbane guided ADB pairing process

Acquire now, detect later

Bugbane makes triage easier and more accessible, allowing users to self-test in just a few minutes without requiring another device. It also makes it practical for users to acquire data periodically without assistance.

Crucially, Bugbane supports analyzing past acquisitions with updated IOCs. Infections that have already ended or that weren’t detected in real time might still be identified later if users perform regular Bugbane scans. Typically, forensic analysis happens only when there are compelling motivations — for example, when someone in the same social circle is known to have been compromised — as well as access to individuals or organizations able to help. Regular acquisitions may lead to more detections over time, including retroactive detection when new public IOCs are released.

We hope this approach will provide support to a wider community, and will feed into more detailed, actionable threat intelligence.

Your browser does not support the video tag.

Bugbane acquisition and analysis

Committed to transparency

Bugbane is released under the GPLv3 license, with some components from Shizuku integrated under the Apache 2.0 license. In line with our commitment to security and transparency, we will distribute reproducible builds for the foreseeable future. Our CI already checks reproducibility across two different environments (Ubuntu 22.04 and 24.04), and we plan to fully support the F-Droid reproducible builds effort once we hit a stable release. Development is openly discussed and tracked on GitHub; feedback and community contributions are welcome in the repository.

Bugbane can export AndroidQF-compatible archives to device storage or through the system sharing dialog — allowing users to share data via email, Signal, or any other supported app. These archives are never exported in plaintext; they are always encrypted using age with a randomly generated, strong password. age is a file encryption software with multi-platform support, making it easy for others to decrypt safely. This way, users alerted by other sources — or who have self-detected something suspicious — can securely share the necessary data for further analysis.

Your browser does not support the video tag.

Bugbane encrypted export

Security as a priority

As with any security-focused tool, the security of the application itself matters. The certificate used for the ADB connection is never stored in plaintext; it’s encrypted with a Keystore-backed credential. Dependencies are kept to a minimum: the multi-ABI release APK is just ~12 MB, while per-ABI builds are ~6 MB. At present, acquisitions are stored unencrypted in the app’s protected storage. We plan to add password or biometric authentication to the app, so that stored acquisitions will be encrypted at rest and protected from unauthorized access.

What we’re looking for

The app is ready for testing, but not for general public release. So far, we’ve done only internal testing, and we’re now looking for a broader group to provide usability and stability feedback. As with any such application, avoiding a false sense of security is critical; there are usability concepts that need to be clearly communicated, such as that the absence of detections does not mean that a device is secure.

We’d also like to hear from organizations that might be interested in using Bugbane as a triaging tool: your feedback on common user pitfalls, real-world issues, and desired improvements will help us refine the app before general availability. We’re also open to implementing automated, secure sharing mechanisms — with explicit user consent — to better support civil society partners.

Conclusion

We’ll be at Global Gathering next week! While we won’t have a booth, we’d be happy to chat — reach out on Signal or drop us an email. We’ll also be at EDRi’s Privacy Camp on September 30 in Brussels, and at the Tor Community Gathering on October 3–5 in Denmark.

Development of Bugbane will continue, with a general public release planned before the end of the year. Soon, we’ll need more community involvement — not just for feedback, but also for translations and contributions.

As we’ve reiterated many times, stalkerware should never be available on mainstream App Stores, and government-backed spyware should not exist at all. Bugbane is our contribution to a collective response to these threats, acknowledging that when institutions fail, what remains is solidarity and collaboration.

The EU Commission's ProtectEU roadmap? A dangerous step toward permanent surveillance

Fri, 25 Jul 2025 00:00:00 +0000

The “roadmap” for the ProtectEU initiative, recently announced by the European Commission and framed as an effort to “ensure effective and lawful access” to data for law enforcement and judicial authorities, marks a reversal of democratic priorities: privacy and fundamental rights are treated as obstacles to be managed, rather than founding values to be protected.

In document COM/2025/349 final, drafted as part of the ProtectEU strategy, the new “internal security” plan unveiled by Commission President Ursula von der Leyen, we read that “security is the cornerstone upon which all fundamental freedoms are based.” This statement represents an ideological inversion, one that clashes with both the original framework of European integration and its foundational texts, starting with Article 2 of the Treaty on European Union and the Charter of Fundamental Rights of the EU, which place liberty and human dignity at the heart of the common legal order.

The Commission’s strategy risks turning exception into rule: permanent suspicion becomes standard, preventive data collection is institutionalized, and mass surveillance is established as a governing infrastructure. It is the same security-driven approach that has been promoted for over thirty years across political camps, one that has already eroded essential freedoms, from the right to peaceful protest to the free expression of dissent, wherever it has been implemented.

As a secondary consequence, it is now well documented that mass surveillance produces a chilling effect: the mere awareness of being watched leads to self-censorship, undermining pluralism. According to recent scholarship, it also narrows the space for personal and political development and drains public debate of participation. What is often at stake is not only privacy, but a portion of democracy’s very vitality.

A text to be rewritten or abandoned

The proposed roadmap contains a long list of critical issues, spanning a range of themes: from the misuse of AI in investigations to the all-too-familiar proposal to weaken encryption.

Data retention

One of the most critical issues is data retention. The Commission promises an “impact assessment”, but the goal is already evident: to update existing rules in order to ensure broader and more systematic access to data for authorities. In other words, a return to forms of indiscriminate data retention, a practice already declared unlawful in multiple rulings by the Court of Justice of the EU (e.g., CJEU, 8 April 2014. Digital Rights Ireland Ltd v Minister for Communications, Marine and Natural Resources and Others).

Yet another attack on encryption

The section dedicated to decryption is equally troubling. The Commission aims to promote “solutions that facilitate access to encrypted data” by 2030. Once again, encryption, which is one of the most effective tools available to protect sensitive communications, is in the crosshairs. This is a glaring contradiction, considering that the previous Commission, also led by Von der Leyen, recommended the use of Signal, a messaging app known for its end-to-end encryption.

Introducing backdoors into encryption technologies means making them vulnerable for everyone. There is no such thing as a “safe backdoor” that only authorities can access. Once a flaw is created, it is only a matter of time before it is exploited by malicious actors, criminal groups, or foreign and domestic governments. It is a spectacular act of self-sabotage within a strategy that claims to promote “Internal Security”.

AI for forensic analysis

The push to develop forensic computing tools and artificial intelligence for analyzing digital data poses a direct threat to the right to a fair trial. This type of analysis often relies on data obtained illegally, and is conducted through algorithms that are inevitably subject to ethnic, social, religious, and gender biases. As a result, it can only produce unfounded evidence, disproportionately affecting already vulnerable groups. The questionable nature of such evidence makes it inadmissible in court.

Safeguards are neither credible nor reliable

The roadmap repeatedly emphasizes that access to data must be “necessary, proportionate, and respectful of fundamental rights.” But in practice, we know that once a technology exists, it will be used and abused especially by those in power. We have seen this with every instance of mass surveillance, from the Snowden revelations to the ongoing spyware crisis, which is partly European in origin and continues to be ignored by the Commission. We also know, as was the case then, that export and usage controls are ineffective, and that state investigations are deeply lacking, even when they formally fulfill legal obligations.

Conclusion: A path toward surveillance as normality

The EU Commission’s current roadmap risks becoming the infrastructure of a European digital panopticon. It is time to firmly restate that privacy is not the problem: it is part of the solution. Defending it is not an obstacle to justice, but a precondition for a truly democratic society.

We call on civil society organizations, legal advocacy groups, data protection authorities, and Members of the European Parliament to urgently raise the debate around ProtectEU, before it becomes binding law without meaningful public scrutiny.

Italy's intelligence oversight committee (COPASIR) report on Graphite spyware raises more questions than it answers

Sat, 07 Jun 2025 00:00:00 +0000

The long-awaited report by the Italian Parliamentary Committee for the Security of the Republic (COPASIR) on the use of Graphite spyware is now public. Yet rather than clarifying events, the document raises further concerns about government accountability, the cost of surveillance, and the extent of state overreach. Below we highlight some of the most troubling findings. The full report is available on the website of the Italian Parliament (in Italian).

COPASIR Graphite report

Targeting a humanitarian NGO for five years

The report confirms that Luca Casarini, a prominent figure in the humanitarian NGO Mediterranea Saving Humans, was intermittently placed under surveillance for at least five years. Initially, traditional methods were used; under the current government, however, the highly invasive Graphite spyware was deployed. Mediterranea is no secretive organization: its search and rescue missions in the Mediterranean are conducted under the watch of international observers and journalists.

This raises serious questions about what could justify such a prolonged and intrusive operation targeting an organization whose goals and methods are transparent and lawful. The mismatch between the invasive tools employed, the years-long duration of the operation, and the meager investigative results is alarming — and difficult to justify.

An inconsistent government narrative

The Italian government has made conflicting and shifting statements regarding the spyware scandal. At first, it downplayed the existence of any victims; then, it acknowledged that contracts with the Israeli spyware vendor Paragon were still in effect. Later, it claimed the contracts had been suspended. According to Haaretz, Prime Minister Giorgia Meloni even contacted Netanyahu directly to seek clarification.

The COPASIR report, however, offers a different account: it states that the contract was unilaterally terminated by the Italian intelligence agencies, contradicting the government’s earlier version of events.

Is COPASIR trusting graphical interfaces?

The report devotes considerable attention to the “traceability” of actions carried out using Graphite spyware:

Another legal issue related to the use of modern interception technologies, as emerged during hearings, is that data are saved in non-deletable databases by the public agencies using the system, unless the service provider is involved in the deletion process (p. 23, translation from Italian)

According to the information gathered by the Committee during its inquiry, every use of the Graphite spyware is logged: the operator must authenticate with a username and password, and each operation is recorded in a database or “acquisition log” and in an audit register. The database is located on the client’s premises, collects information about the target, and is not accessible to the company. The audit log, which is also hosted on servers located at the client, records all operations and system accesses, including technical access for maintenance or updates by the company. Furthermore, data in the database can be deleted by the client, but audit logs cannot be altered by the client. During site visits to the agencies on May 7, 2025, the Committee specifically requested and obtained assurances that the contents of the operations would not be accessible to Paragon Solutions. (p. 13, translation from Italian)

But such assurances are fragile. The absence of a graphical interface to modify audit logs does not guarantee their immutability. If the audit system is under the client’s control, anyone with sufficient access could tamper with it—especially given that several months passed between the initial media exposure (January 31) and the start of any formal investigation. Only an independent forensic analysis could credibly verify the integrity of these logs.

One striking example is the case of journalist Francesco Cancellato, officially deemed not to have been targeted, according to COPASIR. The explanation offered is that his device appeared in the detection results due to “false positives.” Yet his phone was not the only one affected, as multiple members of his newsroom also showed signs of compromise.

Is it reasonable to expect private citizens or NGOs to provide definitive “proof” in cases where the very nature of spyware is to remain invisible, leave no trace, and render verification nearly impossible? This dynamic shifts the burden of proof to the victim, while conveniently sparing those with full operational control and privileged access from further scrutiny.

The naïveté of such claims would be ironic, if not outright offensive, given the double standards they reveal. Authorities would never settle for a graphical confirmation in lieu of a forensic audit if it were a citizen or activist under investigation. Yet here, the possibility of tampering isn’t even considered. Victims and overburdened NGOs (often assisting hundreds of cases worldwide) are expected to conduct even deeper forensic investigations, despite the abundance of circumstantial and corroborating evidence: multiple infected journalists, a Meta notification, and partial independent confirmation by Citizen Lab.

An extortion-based business model

One passage from the report is particularly alarming:

Phone numbers with an Italian prefix are not among those contractually excluded from being subjected to surveillance through Graphite spyware. (p. 18, translation from Italian)

In plain terms: to prevent Italian citizens from being spied on by Paragon’s foreign clients, the Italian state must pay. The only way to exempt a country code from the list of potential surveillance targets is to negotiate and pay for a contractual exclusion.

This reveals a business model based on extortion: if a government doesn’t pay, its citizens remain vulnerable to being targeted by foreign governments using Paragon’s tools.

Update – June 10

In the meantime, Paragon has publicly responded to the COPASIR investigation, claiming it had offered technical cooperation to Italian authorities to verify whether its spyware had been used against Francesco Cancellato, and that it terminated its contract with Italy after the authorities declined to proceed.

These statements should be treated with caution, as Paragon is a directly involved party with a clear interest in protecting its commercial image. However, on one point we agree: the investigation into the Fanpage journalists remains inadequate. And once again, we see conflicting versions from Paragon and the Italian government, raising more questions than they answer.

Conclusion

Once again, advanced surveillance tools are being used against activists and journalists, not just in the exceptional cases that are often cited to justify their deployment. As previous cases in Poland, Spain, Greece, and elsewhere have shown, often in democratic countries spyware is used to target dissenting or inconvenient voices—with enormous financial costs, dubious investigative outcomes, and serious risks to global cybersecurity.

The Italian government must take responsibility, provide full transparency on the actual use of Graphite, and immediately end all contracts with companies like Paragon. The European Union should act—as urged by Citizen Lab—to restrict the use of such technologies, ban their production within Europe, and sanction the companies involved.

Patela: A basement full of amnesic servers

Mon, 05 May 2025 00:00:00 +0000

The Osservatorio has finally activated its first experimental nodes on a diskless infrastructure, physically hosted in our own space and designed for low power consumption. In this post, we explain the reasons that led us to work on this project and the implementation we developed. We are also releasing the source code and documentation for the software we wrote, which we will continue to improve and which we hope will be useful for replicating our setup.

Motivations and Threat Model

As we’ve often pointed out, running Tor nodes involves certain risks and fairly common issues—often due to the fact that, in the event of investigations or other problems, the authorities are not always competent enough to understand how Tor works, or, even if they are, they may still choose to act indiscriminately despite knowing they’re not targeting the actual party under investigation. There are many precedents: in Austria, in Germany, in the United States, in Russia, and likely many others. Some of our members have personally experienced that this can also be the case in Italy.

In order to protect ourselves, our infrastructure, and the anonymity and privacy of our users, we must therefore consider a range of possible scenarios, including:

Attempts to disrupt our operations
Seizure of servers and data analysis
Physical compromise of the servers
Remote compromise of the servers

In the first case, the main obstacle is the constant stream of abuse reports and complaints about the activity of our network. In order to ensure our operations, as we’ve mentioned in previous posts, we now manage our own network with IP addresses we own, routed directly to our physical location—minimizing, as much as technically possible (for now!), the number of intermediaries with access or control over our infrastructure.

Since the beginning of the project, we’ve followed two main intuitions: the first is that by approaching classic problems in less conventional ways, we might find solid solutions and also pave the way for other organizations and projects (like buying a physical space!). The second is that, to keep interest alive, both among our members and externally, our activities must be fun, engaging, and innovative.

Network infrastructure

As already mentioned, we operate a router at a datacenter in Milan that announces our AS and IP space. It is currently connected to our basement via an XGS-PON 10G/2.5G link, but our goal is to expand our presence geographically and, where possible, reuse the same network resources (we’ll share more updates on this soon).

Network infrastructure diagram.

One of the key elements of this architecture is that we only trust machines to which we have exclusive access. This means that even our main router at the MIX in Milan is considered potentially untrustworthy. For this reason, our main focus is on our datacenter in Turin.

Diskless infra and System Transparency

System Transparency is a project originally funded by Mullvad for their VPN infrastructure, and now actively developed and maintained by Glasklar Teknik.
The goal of the project is to develop a set of tools to run and certify transparent systems. The idea is as follows: first, system images must be reproducible—that is, ISO files or similar images should be bit-for-bit rebuildable by anyone from source code, in order to prove the absence of tampering (or backdoors). Second, everything needed to reproduce these images must be public and well-documented, as should the images themselves. Finally, at least two additional properties must be ensured: first, only authorized system images should be allowed to run; second, there must be a public, immutable list of all authorized images (a so-called transparency log).

To summarize, in sequence, the concept of system transparency requires:

Building the system in a reproducible way
Distributing all materials and instructions needed for reproduction
Signing system images with securely stored keys
Submitting all signatures to a transparency log

Among the various tools provided by the System Transparency project, stboot does most of the heavy lifting. The server boots from a minimal local image which, thanks to stboot, downloads and verifies the next stage: a reproducible and signed system image intended to run Tor (or, in the future, other services). Because of the signature verification, we can safely host these images remotely or in the cloud without major security concerns.

stboot boot screenshot.

Since the diskless system is still experimental—and although our goal is to make the entire infrastructure easily replaceable—we still run a few services and devices in a more traditional setup:

Maintenance VPN server on a separate network, used for remote administrator access.
DHCP server: only internal IPs are assigned from a private network range and used for debugging and maintenance.
DNS server: best practices from the Tor project recommend running a local DNS resolver to reduce the risk of traffic analysis via domain resolution. In a Tor connection, exit nodes are responsible for resolving domains. For this reason, we’ve set up our own local recursive DNS server.
HTTP server: used to serve the operating system image to the servers.
Managed switch: we’ve been gifted a beautiful managed switch! Many thanks to those who chose to support us in this way!

Patela

The problem with diskless software is that it doesn’t remember anything—not even the few configurations or keys needed to function correctly. In our case, there are just a few essential configurations for a Tor relay:

Tor’s configuration file, /etc/torrc
The relay’s identity keys, /lib/tor/keys/*
Various network settings (IP and NAT)

These configurations also need to be generated on the machine and updated later. For example, we need to be able to update the list of nodes that make up our family. Clearly, maintaining a separate OS image for each machine would be both impractical and hard to maintain.

While tools like ansible-relayor exist, we chose a different approach based on practical and security considerations. We prefer each node to generate its own keys and manage its own configuration, and for the configuration to be applied in pull mode rather than push. In other words, the node itself periodically checks for configuration updates, and only the node should have control over its keys. This is an important security distinction: a compromised configuration server should not be able to affect the security of the node or its keys.

And that’s how patela was born.

Patela is a minimal software tool that downloads and uploads configuration files to a server. The server communicates network configurations (primarily assigning available IPs and the gateway via an API), and the client reads and applies them. All other files that would normally need to persist between reboots are encrypted locally using the TPM and then uploaded in encrypted form to the configuration server. This way, the configuration server never has access to the machine’s keys and cannot directly compromise it—except possibly through Denial of Service, such as distributing invalid IPs or corrupted backups.

The system offers the following advantages:

Resistance to certain physical attacks, as encryption keys are stored in the TPM
Anti-forensic by default, since no data is stored on disks or persistent media
Nodes can be reset by reinitializing the TPM
In the future, we could perform remote attestation to certify that the running system images match those we published
With remote attestation, TPM unsealing could happen only if the system image is genuine, ensuring a strong chain of trust

Logical diagram of patela.

Rust and tools

Since Tor is being rewritten in Rust, and will soon offer everything needed to replace the classic C-Tor implementation even for relays, we decided to align with this and adopt the same language for better future compatibility.

During development, it became clear that a flexible toolchain was essential, especially given the need to use C libraries and support multiple platforms. While patela’s architecture isn’t conceptually very complex, making a piece of software like this maintainable over time, with so many components, is no easy task. Fortunately, the Rust ecosystem and its tooling have matured significantly in recent years, now offering almost everything we need. In practice, we aim to build both a client and a server, and we need:

A database, for the server
A library to download and upload resources, for the client
External libraries (TPM, mTLS, crypto, etc.)
Compatibility with multiple 64-bit architectures, for the client (arm64, x86_64)
For the client, the ability to cross-compile with the target system’s libraries

Containers are often used to meet requirements like ecosystem consistency. However, our goal is to build a simple, lightweight architecture that works on low-power machines and can modify global network configurations.

There are also several things we explicitly want to avoid, some due to personal preference, others based on our chosen constraints:

Splitting the project into many components, libraries, or subprojects, which leads to extra maintenance overhead
Client and server, while performing different roles, mostly rely on the same libraries and data structures
The compiled binary is the only required file: no packages or archives. And with System Transparency, dynamic linking wouldn’t help either—we would still need to rebuild the system image for every update
Writing a Makefile to cover all these goals would likely be longer and more complex than writing the project itself

And here are the projects that helped us achieve all of this with just a few lines of code and relatively little effort:

cargo: the package manager that just works
clap: a solid foundation for building command-line tools
sqlx: a small, simple, and elegant SQL library
actix web: a well-known and mature web framework
constgen: lets us embed constants at compile-time, avoiding external archive management
cargo zigbuild: integrates the Zig compiler with cargo, making cross-compilation straightforward
rustls: pure joy compared to communicating directly with OpenSSL

Compilation and configuration

Once the patela binary is compiled—with all required assets included—it’s enough to copy it into the system image before signing and distributing it.

As mentioned earlier, we use constgen, which makes it easy to generate compile-time constants, for example, embedding the client’s SSL certificates and the Tor configuration template.

let server_ca_file = env::var("PATELA_CA_CERT").unwrap_or(String::from("../certs/ca-cert.pem"));
let client_key_cert_file = env::var("PATELA_CLIENT_CERT").unwrap();

let server_ca = fs::read(server_ca_file).unwrap();
let client = fs::read(client_key_cert_file).unwrap();

let const_declarations = [
 const_declaration!(pub SERVER_CA = server_ca),
 const_declaration!(pub CLIENT_KEY_CERT = client),
]
.join("\n");

Although cargo supports cross-compilation, when using external C dependencies like tpm2-tss, we must ensure that the libc used during compilation is compatible with the one present in our system images. As mentioned earlier, the Zig compiler—integrated directly with cargo via cargo-zigbuild—allows us to specify the target libc version, along with the architecture and kernel:

$ cargo zigbuild --target x86_64-unknown-linux-gnu.2.36

Network

We’ve previously discussed how to run multiple Tor servers on the same network interface with different IPs using a high-level firewall like Shorewall.
Now we’ve applied the same rules using nftables, the native Linux interface for writing network rules.

Two rules are required: one to match packets by user ID, and another to configure source NAT.

$ nft 'add rule ip filter OUTPUT skuid <process id> counter meta mark set <mark id>'
$ nft 'add rule ip filter <interface> mark and 0xff == <mark id> counter snat to <source ip>'

The rules are therefore applied directly by patela, using the nftl library.

Biscuits, mTLS and TPM

We use Mutual TLS (mTLS) for communication. Unlike traditional TLS, where only the client verifies the server, mTLS involves mutual authentication. This offers a double benefit and elegantly solves multiple problems: on the one hand, TLS natively provides transport security and certificate revocation mechanisms; on the other, client certificate authentication allows us to uniquely identify each node or machine. We can then save and track metadata such as the assigned IP, name, and other related info in the server’s database.

The main drawback of mTLS is managing certificates and their renewal. Everyone gets one bold choice per project — otherwise, where’s the fun? Ours was Biscuit, a token-based authentication system similar to JWT. The only reason we use a session token is to avoid authenticating every single API endpoint.

On the client side, the magic lies in the TPM. Libraries and examples are often sparse, and working with TPMs can be frustrating.
In our case, we need a key to survive across reboots, because it’s the only persistent element on the server.

We use a Trust On First Use (TOFU) approach: on first boot, the client generates a primary key inside the TPM and uses it to encrypt a secondary AES-GCM key, which is used to encrypt configuration backups. The AES-GCM key is then stored on the server, encrypted with the TPM. This means only the physical node can decrypt its backup. To revoke a compromised node, we simply delete its encrypted key from the server. The logic for detecting whether a TPM has been initialized runs entirely on the client and is implemented in patela.

In the future, directly integrating relay long-term keys with arti could be a better and more efficient solution, especially if combined with a robust measured boot process to control unsealing.

Future work

This post summarizes what we consider just the first phase of our project. We know there’s still a lot to do and improve, and we’d like to share our current wishlist:

Open source network stack: both in our Milan exchange point and in our datacenter we use routers running proprietary software (Mikrotik CCR2004-1G-12S+2XS and Zyxel XGS1250-12). We’d love to convert both to open source software on open hardware.
Open source Cantina-OS: for now we’ve only published the patela code, but we’ll soon release our OS image configurations too.
Better certificate management: right now, we recompile patela for each physical node to embed the correct TLS certificate. We’d like to switch to a shared client certificate and move authentication to the TPM via remote attestation. This would simplify update workflows and enable attestation even for virtual machines.

In practice

We’ve launched four exit nodes, running with patela and System Transparency:

All four are running on a single Protectli with coreboot, pushing over 1 Gbps of effective total bandwidth.

The Protectli machine in our basement.

5x1000 donation campaign: Fiscal year 2024

Sun, 30 Mar 2025 00:00:00 +0000

How to insert Fiscal Code inside 5x1000

2024 was a year full of good intentions — and, incredibly, also of many concrete results! Some we had envisioned long ago, others emerged along the way.

From the beginning, our goal was to experiment in order to increase the number of Tor exit nodes in Italy. To be honest, we haven’t deployed many yet, but we’ve laid solid foundations for the future:

we became an Autonomous System (AS214094)
we acquired IP addresses
and we can now deploy fiber across Italy

In short, we’re very close to becoming a full-fledged network operator.

But Tor has never been our only goal. We’ve never set boundaries for ourselves, other than doing what we believe is right and what we genuinely enjoy.

Over the past year, we have:

contributed to investigative journalism
conducted independent research on surveillance in Italy

In the coming months, our infrastructure dedicated to Tor will be ready, based on a fully open source and reproducible architecture.

We’re working on several research projects that we plan to publish soon, and we can’t wait to get out of our basement and share our adventures.

You can support us too

Right now, there’s an easy way to support us at no cost to you. When filing your taxes in Italy, simply list our tax code as your 5x1000 beneficiary: 97871010019

Thank you for being with us — and for believing in what we do.

A deep dive into Cellebrite: Android support as of February 2025

Sun, 16 Mar 2025 00:00:00 +0000

In the previous blog post, we summarized part of the Cellebrite product history, and grasped some insights on the market of surveillance software and equipment aimed at mobile forensics. In this blog post, we will explore the current unlocking capabilities, as per their February 2025 documentation distributed to customers. We’ll also introduce some concepts and terminology, and hint at basic mitigations, though proper follow up will come in subsequent posts.

For a very detailed and insightful write-up to help understand Android encryption, read “Android Data Encryption in depth” by Quarkslab or watch their RECON23 talk.

Glossary

To understand the following content, it is useful to recap some of the terminology generally used in the field:

Cold: Powered off device, with content likely to be encrypted at rest.
Warm/Hot: Powered on device, likely in AFU state or unlocked.
File Based Encryption (FBE): A method of encrypting individual files rather than the entire disk, allowing different encryption keys for different files based on user authentication and device state.
Full Disk Encryption (FDE): A method of encrypting the entire storage of a device requiring the PIN or passphrase to decrypt upon boot. Used mostly before Android 7, deprecated from Android 13 onwards.
After First Unlock (AFU): A powered-on device that has been unlocked at least once after boot.
Before First Unlock (BFU): A powered-off device or a powered-on device that has not been unlocked since boot.
Trusted Execution Environment (TEE): A secure, isolated environment within a processor that handles cryptographic operations and protects sensitive data from the main operating system. If no secure element is present, it is the main security context.
Secure Element (SE/eSE/iSE): A hardware security chip, supported from Android 9 onwards, that implements cryptographic operations and key storage in a dedicated hardware component, such as the Titan chip. It is complementary to the TEE and not a requirement to run Android or FBE.
Keystore: A system service in Android that provides a secure way to store and manage cryptographic keys. It ensures keys are not accessible to user-space applications and can only be used in secure operations, such as encryption, decryption, and signing. Keystore supports hardware-backed security when available.
Keymaster: A lower-level component that works with Keystore, handling cryptographic operations within a Trusted Execution Environment (TEE) or secure element module (e.g., Titan M/Titan M2).
Secure Startup: A feature on Samsung Knox devices using FDE that encrypts the main key with the user PIN or password. If not enabled, user credentials are not actually required to decrypt the data.
Credential Encrypted (CE) Storage: A type of encrypted storage that is only accessible after the user authenticates, ensuring sensitive data is protected until the device is unlocked.
Device Encrypted (DE) Storage: A form of encryption that protects data even before the user logs in, but is accessible after boot without requiring user authentication. It is generally used for system-critical files.
Full File System Extraction (FFS): A technique used to obtain a complete copy of a device’s file system, after operating system decryption. Analysis could also allow the retrieval of deleted files.
Brute Force (BF): Brute forcing PINs and passwords varies a lot depending on software and hardware implementations. The worst case is the extraction of encrypted keys and offline bruteforcing. Other cases include bypassing throttling on the TEE or secure elements for online bruteforcing.
Security Patch Level (SPL): Indicates the date or version of the latest security updates applied to a device.

For more information, read the GrapheneOS forum post discussing July 2024 Cellebrite capabilities, and the description of their encryption systems from Samsung Knox. All modern Android devices have a TEE. Some devices, for instance Google Pixels, can have an extra secure element, like the Titan M. Despite Google’s hardening efforts, exploitation is incredibly difficult, and vulnerabilities are very costly, but not impossible.

The February 2025 support matrix

Cellebrite, as far as we know, publishes a support matrix for Android-based and iOS-based devices monthly or at least multiple times a year. The latest version available at time of writing is version 7.73.1 released on February 2025.

Below is a description of the automated process. Clearly, if the phone is unlocked or if the PIN or password are already known, the process is straightforward.

High-level description of the automated process for obtaining file system dumps

Unlocking non-flagship devices is usually easier for several reasons:

Many manufacturers fail to promptly release security updates, or in some cases, never release them at all.
Different processors have varying security stacks and hardening measures. A secure element adds significant protections compared to a device with only a TEE, but it is not required and often not present.
It is well known that some MTK (MediaTek) processors are vulnerable to bootrom exploits and the whole trust chain can be compromised by anyone, including the TEE. Bootrom exploits are not patchable.
If a manufacturer has not invested in securing their devices, they may disable common security mitigations or introduce privileged software that weakens overall security.

Support matrix, high-level per chipset and manufacturer

As seen in the slides, there is a reason why almost every non-Pixel, non-Samsung device is considered unlockable, with only a few exceptions. Even using LineageOS, which typically ensures at least some level of security updates, does not make a significant difference if the underlying platform and binary blobs are not secure, which is almost never the case.

Support matrix, distinction between cold and hot per manufacturer.

Brute-force can take different forms. A root exploit could allow active bruteforcing, involving methods to bypass throttling or significantly speed up the process in various ways. A TEE exploit (or, for instance, a secure boot bypass as shown in MediaTek chips by Quarkslab) could allow for offline bruteforcing, making any numerical PIN shorter than 10 digits useless. This serves as a good reminder that a 6-digit PIN or pattern will always be cracked. Increasing the length and complexity, ideally by using a password instead, provides a meaningful layer of mitigation.

Support matrix, MediaTek- and Exynos-based devices.

As anticipated, if you have a MediaTek-based device, while it is still worth using a long password, there is practically no mitigation possible, except ditching it.

Support matrix, older Pixel devices up to the 5/5a.

Pixel devices remain quite a solid choice if kept updated. While it seems that for the standard Google ROM there are working exploits available to perform the FFS extraction in AFU state, on the contrary GrapheneOS additional hardening and protections are effective, and have been so since 2022. Brute force is generally not available, because the user credentials are stored in the secure element, and thus cannot be extracted and active attempts are heavily throttled.

Support matrix, newer Pixel devices until the 9.

As you could have guessed, the more solid choice for an Android device is a newer Pixel, running GrapheneOS and with a strong password. Biometric authentication works differently, and it is generally not the main target of these attacks, meaning unless your threat model implies that you could be physically coerced to unlock your device, it is safe to use. That said, using a strong password is a minor daily inconvenience: you will only be prompted for it after a power cycle. Applications that offer separate passwords and encryption, such as Signal or many password managers should have it enabled to maximize protections in case everything else fails.

Conclusions

If you think you could be in a situation where your device could be seized, it is always wise to turn it off first. You should also change your PIN, if you use one, as soon as possible in favor of a strong password. The same applies if your device currently has no PIN or if you are using a pattern. If you think there is a high chance of you being eventually targeted, you should move to a Pixel device using GrapheneOS, even just a secondhand older one (from the 6a onwards).

As we stated in the first blog post, this market is unregulated and is prone to countless abuses, as widely reported by Amnesty against civil society, but possibly in instances that could be harder to detect, such as surveillance connected to gender violence. While we do not currently have direct evidence of these occurrences, anybody with a license could be performing these services, and we know they have been sold in the double-digit figures in Italy alone.

A deep dive into Cellebrite: How it came to be

Sun, 16 Mar 2025 00:00:00 +0000

The widespread use of Cellebrite software is not a secret: we mentioned it very recently, as did Amnesty in their recent report covering abuses towards civil society and detailing vulnerabilities exploited. This blogpost is the first in a series of two: here we’ll explore the general history and development of the company, while in the second one we will provide a more detailed list of its capabilities updated as of February 2025. Cellebrite is not alone in this market; other competitors, especially regarding exploitation, include Greykey (previously Greyshift), recently acquired by Axon and integrated into Magnet Forensics.

A brief history

Our recent interest in Cellebrite arises from two key developments. First, we have seen a surge of activists asking us to examine phones that were returned after being seized. Second, sources familiar with the matter have confirmed that, following the recent Paragon scandal in Italy, Cellebrite has attempted to reassess its customer vetting practices. However, particularly in Italy, there have been longstanding reports of erratic sales policies and practices. To understand this, let’s take a step back: companies like Cellebrite operate in a largely unregulated market. While their primary customers are law enforcement agencies, their target customer base extends to a wide range of private companies and individuals. This raises significant concerns, as some of these customers may be operating outside the law—yet, in most cases, there is no oversight to hold them accountable.

The line of products sold by the company has undergone multiple rounds of rebranding and structural changes over the past four years, particularly since Signal published their research about it. Cellebrite has been in the market for a long time, initially focusing on dedicated hardware for efficient forensic extraction from mobile devices, even before smartphones existed. If you buy any of their older devices, you might be surprised to find that even end-of-life products, such as the relatively recent UFED Touch 2, still include cables for extracting data from Nokia 1100 phones. While forensic analysis has always been central to their business model, the need to unlock devices and bypass cryptography is a relatively recent development.

Outdated versions of Cellebrite hardware are sold all over the internet.

While, as far as we know, Cellebrite used to ship known exploits or unlocking methods for older models, the introduction of mandatory file-based encryption (FBE) and secure elements has shifted the approach to mobile security. Rumor has it that, while there was already demand in the market and some companies were involved, many were primarily repurposing jailbreaks, known chipset vulnerabilities, and similar techniques to achieve their goals. However, checkm8 changed the game for the entire industry—it made it possible to unlock all iPhones from the 4S up to the X, regardless of the software patch level. With these tools freely available and easily accessible, competitors—and even law enforcement agencies themselves—could perform the unlocking and extraction without relying on specialized vendors. As the market became more competitive, companies realized they needed to step up their game to retain and expand their customer base. This led to a significant increase in research efforts focused on acquiring and developing 0-day and 1-day vulnerabilities.

While the exploits required for these types of attacks are often very different from those used in spyware infections, since they rely on hardware access rather than message-based, browsing-based, or similar entry points, they are not necessarily simpler, especially for Apple devices. For Android, being based on Linux, things seem relatively more accessible due to a larger attack surface. This includes a wide range of USB-based drivers that have undergone little to no scrutiny over the years and are still shipped by default, often remaining loaded even when a phone is locked. Recent reports from Amnesty have highlighted these vulnerabilities. However, advanced mitigations, such as memory tagging and other new security features on Pixel phones, are making exploitation increasingly difficult.

Distributing exploits is such a difficult job

And here we arrive at the second major issue in this market: previously, Cellebrite kept its most valuable vulnerabilities private, requiring customers to physically ship the devices they wanted unlocked to certain locations. Additionally, the exploitation process was largely manual: human analysts would identify devices and attempt to determine the most suitable unlocking and extraction method if it was not already covered by the suite provided to customers. This approach proved problematic for several reasons. First, some customers were unwilling to send their devices across borders, as it could compromise the chain of custody. Second, in most democracies, defendants have the right to be present during non-reproducible forensic analyses that might alter evidence, something inherent to active exploitation attacks. Lastly, scalability was a major limitation, both due to the human effort required and the delays caused by shipping. From a business standpoint, an automated solution would have benefited both Cellebrite’s operations and its customers.

But this presents a fundamental challenge: if Cellebrite simply shipped its exploitation capabilities with their software suite, even with extensive obfuscation, skilled researchers could quickly reverse-engineer their vulnerabilities and expose them. This could happen either out of a commitment to security and democratic principles or, ironically, to collect bug bounties. As far as we know, Cellebrite has long used custom-made cables and, more recently, has attempted to enhance its capabilities with single multi-purpose adapters required for deploying their attacks. These hardware dependencies also make it more difficult for cracked versions of their suite to proliferate—something we have firsthand witnessed as being far from uncommon.

However, as long as the core logic had to run on the customer’s computer—or even on a dedicated tablet, as marketed in previous generations—it remained relatively easy to extract and analyze.

Here comes the idea: since tablets and similar devices were highly impractical and had limited resources, while current Inseyets software might require up to 128GB of RAM and 24-core Threadripper CPUs to run smoothly on large pieces of evidence and probably to support their “magic AI” (even generative AI, which, of course, would never hallucinate—especially in cases where people’s futures are at stake), they opted for a hybrid approach.

Instead of moving the entire suite to a dedicated appliance, Cellebrite decided to keep the main software running on the customer’s hardware. However, for selected customers permitted to purchase the Premium package (or whatever it is currently called—whether Premium Advanced Access, Advantage, Advanced Logical, or perhaps Premium ES, also known as Mobile Elite), they now ship a specialized embedded device: the Turbo Link.

Screenshot from the Turbo Link marketing brochure.

As we will see in the next post, the new software suite, along with the Turbo Link adapter, fully streamlines exploitation and extraction. The exploits likely never transit in cleartext on the customer’s machine and are only delivered when necessary, after the target device has been identified. From the limited pictures available, the Turbo Link appears to be actively cooled and includes an HDMI port, which requires a secondary cable from the kit to connect to the target device. A reasonable assumption about this setup is that exploits are likely end-to-end encrypted from Cellebrite’s servers to the Turbo Link device, which itself probably has to guarantee a certain level of both software and hardware integrity.

According to Amnesty, the use of an HDMI port is to simplify the emulation of media peripherals, often used for exploitation. On the other side, it is connected via USB to the customer’s computer. However, for customers who wish to scale beyond their contracts—or for those needing to unlock devices while being offline—Cellebrite also sells licenses for a centralized network server called the Enterprise Vault Server (EVS). According to the brochure and their promotional videos, it “supplies the resources necessary to gain access to advanced iOS and Android devices.”

Conclusions

We have explored some of Cellebrite’s history and business structure. In the next post, we’ll take a more practical look at how this translates into their current capabilities. In the coming months, we will publish mitigation strategies and guides to help you and your communities defend against these types of threats.

We’ll reiterate again: we strongly believe that vulnerability trading is intrinsically unethical, as it fuels a vicious cycle of insecurity that puts everyone at risk.

If you have information that could complement this piece, feel free to contact us. If you own old Cellebrite hardware that is end-of-life, or that no longer has a valid license, thus no longer useful, we are collecting older surveillance technology for archival purposes (more on this soon) and we will happily collect your e-waste. Visit the contacts page to discover how to get in touch with us securely.

Cellebrite and the routine use of digital surveillance in Italy

Sat, 08 Mar 2025 00:00:00 +0000

In recent years, authorities in several countries have intensified their use of digital surveillance tools to access mobile devices, often without proper adherence to legal procedures and without the informed consent of those affected—sometimes in blatant violation of existing laws, as demonstrated by the current Paragon and Graphite case. Osservatorio Nessuno recently assisted members of the No CPR Torino assembly (a collective opposing Italy’s Centri di Permanenza per il Rimpatrio, detention centers for migrants awaiting deportation) in discovering that their phones had been unlocked and forensically analyzed using Cellebrite tools, without being given sufficient prior notice to allow their legal consultants to verify that the procedure was conducted lawfully.

Archive photo of an extraction in progress using Cellebrite Touch 2

Evidence of Cellebrite use

A specific case concerns three phones that were seized on March 20, 2024, during an action at Malpensa Airport. The smartphones, protected by PINs and with encryption enabled, were returned with clear signs of compromise: two of them had their PINs written on a sticker on the back, an evident indication that they had been unlocked and analyzed. As far as we know, the devices were turned off and relatively up to date, requiring an unlock method that, according to Cellebrite’s own terminology, is classified as Before First Unlock (BFU), one of the most technically complex and expensive exploits to develop and acquire.

Using the Mobile Verification Toolkit, we confirmed the compromise and found unequivocal signs of the use of tools from the Israeli company. The extracted files matched those analyzed in a recent Amnesty International report, which denounces the use of Cellebrite and spyware to monitor journalists and activists in Serbia. The connection to Cellebrite and its UFED/Inseyets service suggests that Italian law enforcement sent the devices to third-party consultants who, equipped with these tools, extracted data from the phones without adequately informing the individuals concerned or their legal representatives.

We are currently in contact with international organizations and are assisting in an in-depth technical analysis. The results of this analysis will be published at a later date.

Cellebrite and the 0-day market: a threat to everyone

It is not just the pervasiveness of surveillance that is concerning, but also the fact that Cellebrite is active in the 0-day exploit market, which takes advantage of unknown vulnerabilities in operating systems to bypass security measures. This type of trade undermines the security of all users, including governments and businesses, fueling a vicious cycle of cybersecurity threats.

Osservatorio Nessuno strongly condemns the use of tools like Cellebrite against activists, journalists, and ordinary citizens. These tools, marketed as crime-fighting solutions, are instead often used to target political dissent and civil society. Furthermore, the companies that develop and sell them—particularly in the case of Cellebrite—are not required to follow any meaningful vetting process for their customers or users. As a result, they are often freely available for purchase by third parties, including phone shops, consultants, and private companies.

As an organization, we are committed to defending the right to privacy and digital security for everyone, especially those most vulnerable to state surveillance. We will continue to monitor these developments and provide support to anyone who has been a victim of abusive surveillance practices.

If you are an activist or journalist concerned about the security of your devices, or if your device has been seized and you do not have a technical consultant to assist you, contact us via Signal at this link or send an email to support@osservatorionessuno.org.

Updating Exit Policy and Contact Info for our (exit) relays

Wed, 05 Feb 2025 00:00:00 +0000

Contact Info changes

We have updated the ContactInfo field in the torrc configuration of all our relays to align with the proposed ContactInfo Information Sharing Specification. This standard defines a structured format for describing key attributes of a relay family operator. Ensuring operators are reachable and that relays are associated with trusted individuals or organizations is crucial for the health of the Tor Network.

To enhance transparency, we have also published proof of relay ownership in our public .well-known/tor-relay/rsa-fingerprint.txt.

As shown on the OrNetStats page, many organizations are already participating in this initiative by providing authenticated information, facilitating accurate recognition of their relays.

Exit Policy changes

For nodes physically hosted by us, specifically those in the 64.190.76.0/24 range (e.g., 4FCA270A887D2BB0666A05EF45B393C7A6B13214), we have adopted the most permissive exit policy possible, blocking only port 25.

Previously, exit policies on hosted nodes were tailored to minimize abuse complaints and maintain positive relationships with hosting providers. However, ports such as 22 (SSH), while sometimes exploited for brute-force attacks, serve essential legitimate uses that outweigh the risks.

Ultimately, port-based restrictions are not a security measure but rather a mitigation tactic to handle a useless volume of automated abuse reports. Our approach reflects our commitment to balancing network accessibility with responsible operation.

How to configure multiple Tor relays on the same interface with different IPs

Tue, 04 Feb 2025 00:00:00 +0000

The main bottleneck in Tor relays is often the processor’s clock speed. Since Tor does not support multithreading, the best solution is usually to run a separate Tor instance for each core (or thread). Given the cost of electricity, we are looking for hardware that is both power-efficient and cost-effective while still being capable of saturating the available bandwidth. The apu2, although no longer in production, remains an excellent machine, used for years and with stable support for coreboot. The model we are testing has the following specifications:

4 physical cores / 4 threads @ 1GHz
2GB DDR3 DRAM
4x Gigabit Ethernet

We want to determine the configuration that best optimizes resource usage, considering that we have access to a full IPv4 subnet and 2.5 Gbit of upload bandwidth.

Initial setup

A set of scripts is available to efficiently manage multiple Tor processes on the same system.

First, the default Tor service needs to be disabled:

systemctl disable tor
systemctl stop tor

Then, let’s create the desired instance:

tor-instance-create <name of the instance>

All configurations are located in /etc/tor/instances and can be managed as separate system services.

systemctl start tor@<name of the instance>
systemctl enable tor@<name of the instance>

We tested with 4 processes (one per core), but due to the limited available RAM, individual instances did not exceed 4 MB/s. The minimum memory required for each instance seems to be around 400-500 MB. We therefore changed the configuration and applied some optimizations:

Use zram to compress memory
Remove dbus: since we have no other services running, this allows us to save 50-80 MB of memory
Remove Unbound: while it is recommended as a best practice for exit nodes, we chose to explicitly specify our DNS servers in /etc/resolv.conf

This allowed us to reduce the base system’s memory usage and leave approximately 1.6 GB of free RAM for the Tor instances.

Network Configuration

We assigned 3 IPv4 addresses and 3 IPv6 on the same network interface because we have our dedicated subnets, but often the same IP is used with different ports (however, there is a limit imposed by the directory authorities on how many nodes can share the same IPv4, currently 8).

We thus have the following network interface:

5: enp2s0.835@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
 link/ether 00:0d:b9:4a:bf:71 brd ff:ff:ff:ff:ff:ff
 inet 64.190.76.2/24 brd 64.190.76.255 scope global enp2s0.835
 valid_lft forever preferred_lft forever
 inet 64.190.76.3/24 brd 64.190.76.255 scope global secondary enp2s0.835
 valid_lft forever preferred_lft forever
 inet 64.190.76.4/24 brd 64.190.76.255 scope global secondary enp2s0.835
 valid_lft forever preferred_lft forever
 inet6 2001:67c:e28:1::4/64 scope global
 valid_lft forever preferred_lft forever
 inet6 2001:67c:e28:1::3/64 scope global
 valid_lft forever preferred_lft forever
 inet6 2001:67c:e28:1::2/64 scope global
 valid_lft forever preferred_lft forever

However, after a few weeks, we were contacted by the Network Health Team because they detected that, despite having different IPv4 addresses, all our relays were exiting through the same one.

Note: It is crucial to provide accurate contact information when operating Tor nodes for this very reason. This is not the first time we have received warnings or suggestions on how to improve our setup.

To change the source IP of a Linux process, there are several solutions, including:

Manual iptables rules
RoutingPolicyRule in systemd
Management interfaces for iptables

We chose the third option with shorewall for convenience. The configuration is located in /etc/shorewall.

The files used to map processes to specific outgoing IP addresses are:

/etc/shorewall/mangle: marks outgoing packets based on a UID
/etc/shorewall/snat: applies source NAT to marked packets using the selected IP addresses

Here is an example configuration where packets from the UID tor-bludicapra are marked (2), and source NAT is applied on the enp2s0.835 interface with IP 64.190.76.2.

/etc/shorewall/mangle

#ACTION SOURCE DEST PROTO DPORT SPORT USER
MARK(2) $FW 0.0.0.0/0 - - - _tor-bludicapra

/etc/shorewall/snat

#ACTION SOURCE DEST PROTO DPORT SPORT IPSEC MARK
SNAT(64.190.76.2) - enp2s0.835 - - - - 2

The prerequisite is that the outgoing addresses are configured on the WAN interface (e.g., via /etc/network/interfaces).

Other relevant shorewall files, which do not require modifications for this configuration, are listed below in the order of filter processing:

/etc/shorewall/interfaces: for configuring the filtered interfaces
/etc/shorewall/rules: for firewall rules
/etc/shorewall/policy: for global policies

After each modification, you can verify the configuration and apply it:

shorewall check
shorewall reload

The little cheeses

From this experience, a small family of Italian cheeses was born:

Thanks for your 5x1000 contribution!

Fri, 27 Dec 2024 00:00:00 +0000

Today, the Italian Ministry of Labour and Social Policies credited our bank account with the 5x1000 donated by Italian residents when they filed their 2023 taxes.

The 5x1000 is a tax mechanism allowing Italian taxpayers to allocate 0.5% of their income tax to support nonprofit organizations, scientific research, cultural activities, or social initiatives of their choice. It provides a way for citizens to contribute to public-interest causes without incurring additional costs.

As publicly disclosed by the Italian Tax Authority, we received a total of €465.14 donated by 16 people.

We are thankful to everyone who supported us this year, and we hope for your continued support in 2025. If you want to donate, you can follow the instructions here.

If you are an Italian resident and want to designate your 5x1000 to us, our tax code is 97871010019.

How to BGP from your basement and other tales

Wed, 18 Dec 2024 00:00:00 +0000

As previously announced, we are now officially AS214094. Additionally, we have obtained the IPv6 PI subnet 2001:67c:e28::/48 and acquired the IPv4 subnet 64.190.76.0/24 through a transfer from ARIN. This means we not only control and receive any related abuse reports, but we also fully own and manage all our network resources at this time.

Taking it a step further, we secured a deal through a friendly provider to directly collect traffic at the Milan Internet Exchange Point (MIX) from our OpenFiber 10G/2.5G residential link. A few days ago, we installed our own router at MIX, which we own and manage, and began announcing our address space.

Here’s how it works: OpenFiber, a partially publicly owned infrastructure provider, offers different reselling options. Larger providers install their own OLT and network equipment at each local POP, while smaller providers can rely on OpenFiber’s own equipment for direct delivery to an Italian Internet Exchange Point. From there, we purchase our own uplink, which involves significantly higher costs but guarantees dedicated, high-bandwidth service.

This setup gives us the best of both worlds: we maintain independent physical space for server security while enjoying the same level of network control we would have if we were directly housed at MIX. This ensures network ownership goes as high as possible, while we retain the strongest physical isolation for our servers.

Simple infrastructure diagram

The current monthly cost for this setup—including the residential fiber rental, housing and power for our router at MIX, and a 1G/1G dedicated uplink—is approximately €300. This excludes the cost of network equipment at our headquarters and power usage. We are thrilled about this development, as it gives us control over a substantial part of our network infrastructure, reducing costs and eliminating potential issues when operating Tor nodes. Moreover, since OpenFiber allows traffic collection from all over Italy at MIX, we can easily distribute our IP space and network resources geographically.

We have ambitious plans for 2025, both in terms of technical research and infrastructure updates. Many of us will also attend 38C3. If you plan to be there and are curious about our project or want to chat, feel free to drop us an email.

We are deeply grateful to everyone who contributed this year—whether financially, with their time, or by sharing resources and knowledge. As we continue to expand, our costs are increasing, so please consider donating any amount. Donations are tax-deductible in Italy.

Currently, only a test node is running to perform bandwidth measurements and hardware benchmarks. Once the testing phase is complete, we will begin running and maintaining enough instances to utilize as many addresses as possible and fully saturate the link.

Mikrotik Router unboxing

Mikrotik Router at the Milan Internet Exchange

IrpiMedia and Osservatorio Nessuno: Unmasking digital violence

Sat, 30 Nov 2024 00:00:00 +0000

“This is an industry that should not exist” said Edward Snowden in 2021, referring to NSO Group’s infamous Pegasus and its competitors. It is evident that digital surveillance through spyware is one of the major threats to privacy and users worldwide.

Whether it involves spyware developed by criminals for extortion, advanced tools created by well-established European companies and authorized by major democratic governments (and non-democratic ones), or low-cost, amateur software designed to spy on children or partners, all these technologies ultimately generate violence.

It is precisely the latter type of spyware that Irpi, Italy’s leading investigative journalism organization, has focused on in a series of articles. These articles analyze leaks from SpyHide and PC Tattletale, while contacting users and victims to verify and delve deeper into their stories.

Osservatorio Nessuno provided technical support and contributed to the analysis of SpyHide’s data. Thanks to Irpi’s investigative work, this led to the publication of a series of articles: spiarelowcost (translated, lowcostspying) which we strongly recommend everyone to read.

Pc Tattletale’s website, before its closing down

Preventing and countering gender-based violence is a responsibility we all share—always. Software like SpyHide, which enables and encourages such violence, simply should not exist.

Read the articles in the spiarelowcost investigations:

For further insights, our friends and colleagues at stakkastakka interviewed the article’s main author. The podcast is available here (in Italian).

Are you a journalist or an organization in need of a partner for analysis or a technical opinion on an investigation? Contact us at support@osservatorionessuno.org.

If you require a secure communication channel, reach out to us on Signal clicking here or opening this link on your mobile device.

If you would like to submit anonymous information to Irpi for further analysis, consider using IrpiLeaks using the Tor Browser.

Censorship Attack against the Tor network

Thu, 31 Oct 2024 00:00:00 +0000

In the last few days, many Tor relay operators - mainly hosting relay nodes on providers like Hetzner - began receiving abuse notices.
All the abuses reported many failed SSH login attempts - part of a brute force attack - coming from their Tor relays.

Tor relays normally only transport traffic between a guard and an exit node of the Tor network, and per se should not perform any SSH connections to internet-facing hosts, let alone performing SSH brute force attacks.

After a first analysis by delroth, it was discovered that the majority of the Tor relays were not performing any SSH traffic at all.

Instead, a malicious actor began spoofing Tor relays’ IP addresses while performing a large-scale SSH brute-force attack, specifically targeting honeypots, and networks with intrusion detection systems that send (sometimes automated) abuse complaints.

In this way, the target host will receive SSH login attempts from the relay’s IP address instead of the actor’s real IP address.

Internet hosts making a high number of failed SSH login attempts are quickly added to blocklist, receive a lot of abuse notices, and their IP address will quickly get a “bad reputation”.
For these reasons providers usually take down hosts after a small number of abuse notices, most of the time without any appeal.

It is no news that many actors don’t like Tor.
This censorship attack directly undermines the Tor relay infrastructure health, by explicitly forcing abuse complaints to Tor relay operators.

At the moment of writing, the scale of the attack is still moderate and the actor is still unknown.
As for the solution, the best you can do as a relay operator against the flood of abuse complaints is to try to appeal, and run more nodes to replenish the ones that will be taken down.
If you are a provider, before sending bogus abuse complaints verify that the information is actually true and there are enough proofs to back it up, leaving a chance for the users to appeal.

We are Autonomous System 214094

Thu, 03 Oct 2024 00:00:00 +0000

We have registered with RIPE NCC as ORG-ON69-RIPE.

Thanks to a generous sponsoring LIR (Local Internet Registry) organization, we are now a sponsored organization, and we can request resources from the RIR. As such, we have applied for an Autonomous System number and have been assigned the number 214094.

We are in the process of obtaining a PI (Provider Independent) or Legacy IPv4 /24 block and IPv6 address space as well, in order to announce it directly from our local urban “datacenter”.

We have a headquarters and it is soon to become a small datacenter!

Mon, 15 Jul 2024 00:00:00 +0000

On April 11th, 2024, we signed the purchase agreement for a small basement in Turin, Italy. We chose this location mainly due to its connectivity options (OpenFiber, FiberCop, soon Digi), the small number of living units (only 4) in the building, and the low cost of the whole operation (about 3700 EUR for real estate value, plus 1500 EUR for legal costs).

Having a physical dedicated space offers a great opportunity for the organization’s operations, allowing us to:

Better isolate the organization’s activities, including legally, from both the members and the board of directors
Host dedicated infrastructure under our full control, with the option of video surveillance
Research and host experimental and potentially better infrastructure compared to the classic co-location options

The great advantage of being connected to OpenFiber and FiberCop is their business model: they offer their infrastructure to third-party providers without the necessity of being committed to a specific one. In case of legal problems, transitioning to a different provider can be simple, and we could eventually reach a point to manage even part of the upper infrastructure ourselves.

We will soon have many updates on this development, so stay tuned!

Inside view with fancy tiles

Outside plate view

Osservatorio Nessuno at school: Digital self-defense and hacker culture courses in Turin

Fri, 01 Jul 2022 00:00:00 +0000

In recent months, we had the pleasure of collaborating with I.I.S. Ettore Majorana in Turin for a series of meetings on digital security, hacker culture, and education for a critical approach to the use of technology. The experience was incredibly positive: we met curious students eager to better understand the mechanisms of the digital world and, most importantly, to protect their online privacy.

Why go to schools?

We live in an era where technology permeates every aspect of our daily lives. However, awareness of how computer systems work and how to protect oneself from digital threats is still limited. We believe that digital education must start at the local level and in schools, shaping informed users who can navigate the internet with critical thinking and autonomy.

Course program

Between March and June 2022, we organized a series of thematic afternoon lessons for Majorana students. Our approach was practical and interactive, always aiming to stimulate debate and active participation. Here are some of the topics covered:

Introduction to digital self-defense and hacker culture – An introduction to online privacy, the most common threats, and strategies for self-protection.
Linux and the command line – A journey into the world of free software, with practical exercises on shell usage and file and process management.
How the internet works – From OSI model layers to fundamental protocols, up to tools for monitoring and securing one’s connection.
Cryptography and digital security – How cryptography, blockchain, NFTs, and DRM work, and why cryptography is essential for online freedom.
Basic programming with Telegram Bots – Introduction to programming through the creation of bots on Telegram.
Social Media and the Fediverse – A critical analysis of social networks, user profiling, and decentralized alternatives.
Hacking and cybersecurity – Basic concepts of security testing, web application security, and defensive tools.
Streaming, online radio, and Audacity – Audio production techniques and managing an online radio station.

An experience worth repeating

The enthusiasm of the students and their active participation demonstrated that there is a strong need for education on these topics. For us at Osservatorio Nessuno, this is just the first of many initiatives: we are open to collaborating with other schools, associations, and groups that want to spread a free and informed technological culture.

If you are a teacher or part of an educational institution and would like to contact us, visit the contacts page.

Digital culture is a right: let’s defend it together!

General members assembly on January 10th, 2022

Mon, 10 Jan 2022 00:00:00 +0000

The general assembly has been scheduled for January 10th 2022 with the following agenda:

approval of the 2021 budget as required by art. 8 and 12 of the Statute
extras

The communication was sent via email to all members in compliance with the payment of the annual membership fee. If you have not received the email, please write to membership@osservatorionessuno.org.

Blogs on Osservatorio Nessuno - Association for the promotion and protection of digital rights

Demystifying phone unlocking tools: A technical overview

Introduction

Hardware security architecture

The System-on-Chip: Normal World and Secure World

The Secure Element

The boot chain

Android data encryption

Full Disk Encryption vs. File-Based Encryption

CE key derivation: The role of credentials

Key derivation with a Secure Element (Weaver)

Attack vectors

BFU attacks on devices without a Secure Element

BFU attacks on devices with a Secure Element

AFU attacks: The lock screen is just UI

AFU attacks on locked devices in practice

A note on iOS: checkm8 and USB Restricted Mode

Defensive implications

BFU is your best defense

Auto-reboot: returning to BFU automatically

USB port restriction

Password strength

Device choice

Application-level encryption

Conclusion

References

Morpheus: A new Spyware linked to IPS Intelligence

The Spyware

Infection

First Stage: The Dropper

Second Stage: The Agent

Techniques

Abusing Overlay & Accessibility to Bypass Biometric Authentication

Elevating Privileges through ADB

Attribution

“Aprafoco”, Spaghetti & Gomorra

Targets

The Malware Infrastructure

Company Information

Recommendations

Review Recent Activity

Verify Linked Devices on Messaging Apps

Audit Google Account Sessions

Check Battery Usage

Reach Out for Help

IoCs

Conclusion

Italian spyware maker SIO still developing and distributing Spyrtacus

The Spyware

Infection Method

The Agent

Attribution

Extras

Previous Samples & Analysis

IoCs

Conclusion

Google is turning Android into a walled-garden monopoly. We must prevent it

The security argument

Keep Android Open

EDRi, an ISP, and a packed agenda

A new website

ProcioNet APS

European Digital Rights (EDRi)

So many events

Reflections on access and inequality

Politics of participation

Conclusion

Patela v2: From certificates to hardware

Evolving the architecture

Trust on first use (TOFU)

Sometimes it’s ok to not have backups

Improved configuration

Auth via partial attestation

What’s Next

Testing

Conclusion

Bugbane: Simplifying consensual Android forensics

Background

Bugbane

Acquire now, detect later