Phantomdrive Open-Source USB Drive Conceals Encrypted Storage to Resist Coercion
Developer Ryan Walker has created Phantomdrive, an open-source USB storage device designed to protect users against forced decryption demands in jurisdictions with weak privacy laws. Unlike standard hidden-volume solutions such as VeraCrypt, Phantomdrive aims to prevent authorities from even detecting the existence of additional encrypted space.
The device presents itself to the host operating system as a conventional 8 GB drive upon first connection. Any data written to this visible area remains unencrypted until the user creates a text file containing the exact string password: PUTYOURPASSWORDHERE. The firmware then triggers a re-enumeration that exposes the hidden, AES-encrypted partition while simultaneously encrypting the previously visible area on the fly.
Hardware design centers on the CH569 microcontroller from the same family as the widely used CH340 USB-to-serial bridge. The chip provides native USB 3.0, SD/eMMC interfacing, and a hardware encryption block supporting the Chinese SM4 algorithm alongside standard AES operations. Storage is provided by an SD card rather than eMMC due to current pricing pressures; the entire assembly is sealed with epoxy resin so that physical access requires destruction of the enclosure.
Key derivation uses a per-device salt extracted from the USB serial number (for example, Phantomdrive:34FC1FA7145467F7) combined with 100,000 iterations of SHA-256. This approach eliminates rainbow-table attacks across multiple devices and raises the cost of brute-force attempts. The developer deliberately avoided memory-hard functions such as Argon2 because the limited RAM on the CH569 would make unlock times exceed acceptable limits.
Encryption defaults to AES-CTR mode, achieving approximately 9 MB/s write and 20 MB/s read throughput. AES-XTS is also implemented for users who prioritize resistance to ciphertext manipulation over speed, although it reduces performance to roughly 6 MB/s writes and 10 MB/s reads. Both modes were validated through functional tests and cross-checked against the OpenSSL reference implementation.
The firmware continuously inspects raw USB WRITE10 commands for the trigger string without interpreting any file system. When detected, the password is copied into RAM, the buffer is zeroed to prevent the secret from reaching the media, and the device switches partitions. Users are warned that high volumes of random data on the visible partition could theoretically produce a false-positive match.
All schematics, firmware sources, and mechanical files are released publicly, along with the supporting libraries originally developed for the hydrausb3 project. Pre-order pages are already live for those wishing to obtain early hardware units.
Related articles
Configuration Drift Silently Breaks Multi-Hop Chains in sing-box Reality Fleet
A post-mortem analysis of a censorship circumvention network using sing-box and Reality revealed that four out of seven nodes were unreachable due to outdated allowlists, even though all monitoring reported green status. The fleet consisted of 14 endpoints across seven machines and four providers, with traffic routed in two hops where entry nodes only knew client identities and exit nodes only knew destinations. White-list rules on entry nodes permitted only five addresses instead of all required relays, causing urltest to silently discard most chains without logging failures. Canary checks, external probes, and the relay-lockdown.sh script all passed because none compared the allowlist against the full signed configuration. Two private paid nodes lacked any route section entirely, exposing them to potential abuse. The issue stemmed from configuration drift over time, with no single person maintaining an overview of the entire system. Automated fixes were implemented with safeguards to prevent fleet-wide lockouts.
Why Distributed Mesh Architectures Resist IP Blocking Better Than Centralized Servers
The article explains the fundamental limitations of single-server or small-server setups when facing IP-based censorship and DPI systems. A centralized infrastructure relies on a finite, relatively static list of addresses that can be discovered, tracked, and blocked over time. In contrast, a client-side mesh turns user devices into active transport nodes that relay traffic peer-to-peer, creating a constantly changing set of endpoints. This architectural shift transforms address blocking from a one-time list-maintenance task into an ongoing discovery problem. The design still requires an auxiliary trust and coordination layer called the backbone network, while anti-DPI techniques such as ClientHello rotation and decoy traffic protect individual connections. The approach carries real costs in battery life, bandwidth, and operational complexity on client devices.
Chrome Adds On-Device Gemini Nano While Ask Gemini Sends Page Content to Google Cloud
Google has introduced an 'AI on device' toggle in Chrome settings that enables local execution of the Gemini Nano model directly on the user's computer. Several gigabytes of Gemini Nano weights are now stored in the browser profile directory and can run on CPU or GPU for tasks such as initial analysis of suspicious pages. Despite the local model being present, the user-facing 'Ask Gemini' feature does not use it and instead routes page content, URLs, and up to ten additional tabs to Google's cloud infrastructure. The company uses two distinct systems under the Gemini name: the cloud-based Ask Gemini / Gemini in Chrome service and the on-device Gemini Nano accessed only through internal APIs or by websites and extensions. When Enhanced Protection is enabled, results from the local Safe Browsing analysis may still be transmitted to Google Safe Browsing servers. The naming and interface choices have created confusion, as users cannot directly invoke the downloaded Gemini Nano model for tasks like summarizing open pages.
Yandex Details Alice Voice Assistant Audio Buffering and Data Handling in Android Apps
Yandex has issued a detailed technical response to an analysis of its Android applications that raised concerns over potential collection of audio, contacts, bank card data, and other sensitive information. The company acknowledged the existence of a cyclic audio buffer that retains approximately 1.5 seconds of sound before an activation phrase and 0.5 seconds after it, with some pre-command audio possibly transmitted to servers for speech recognition quality checks. Yandex clarified that the Alice assistant only listens locally for the wake word when the app is open and does not continuously record conversations. Access to contacts was explained as necessary for voice commands such as calling entries from the address book, with the full book sent on first sync and only changes thereafter, without hashing to support accurate speech processing. The firm rejected claims of reading messaging app conversations and stated that bank card details are routed directly to an isolated PCI DSS-compliant environment rather than standard application servers.