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
New Obfuscation Method Dissolves Personal Data Records in Layer of Plausible Variants
A Russian information security researcher has proposed a data protection technique that renders stolen personal records unusable even after full compromise. The approach mixes real data such as phone numbers, emails, passports, addresses, INN and SNILS with vast numbers of semantically valid alternatives. Attackers receive nearly complete information including a 361-character message containing PIN codes and word order, yet lack the secret vector space and reconstruction algorithm required to identify the correct record. Without these components, brute-force attempts produce millions of plausible results with no architectural method to verify accuracy. The method is presented as an alternative to traditional encryption when data must remain accessible yet protected against extraction. A public sandbox is available for testing the approach.
Hydrat Project Builds Automated WireGuard Gateway for Resilient VLESS and Tor Routing
A developer has released Hydrat, a self-hosted gateway that connects devices via WireGuard while automatically managing VLESS and Tor backends to survive server blocks and quality degradation. The system maintains a pool of tested proxies, performs continuous health checks, and switches routes without requiring client-side profile changes. Two Go processes handle control logic and network enforcement separately, using SQLite for state and nftables plus Xray for traffic routing. TCP and UDP can be assigned independent exits, with geoip.dat support and custom rules to keep marketplace apps functional. The project emphasizes stability over direct connections and is designed for deployment on servers in Russian jurisdiction.
OpenAI Contractors Manually Review Real User Chats in Project Lily
OpenAI has engaged hundreds of external contractors to analyze actual user conversations with ChatGPT as part of its model improvement efforts. The reviewers, working under project Lily, examine real queries that may contain personal, medical, or other sensitive information despite the use of a Privacy Filter. Contractors summarize prompts, compare four model responses, and assign ratings from one to seven while flagging behaviors such as excessive sycophancy or inappropriate emojis. User identities are hidden and some data is filtered, yet OpenAI acknowledged that not all personal information is reliably removed. The same human review process is also employed by Anthropic for its Claude model. Users can opt out of future training use through account settings, although prior data remains unaffected.
UDP Proxies and QUIC Protocol: How Real IP Addresses Leak Through Anti-Detect Browsers
Anti-detect browser users relying on UDP-capable proxies face a hidden risk of real IP leakage when the browser fails to properly route UDP traffic. The QUIC protocol, which powers HTTP/3, runs over UDP and enables features like 0-RTT handshakes, independent streams, and connection migration that can bypass proxy routes. WebRTC connections using ICE, STUN, and TURN further increase exposure because they often attempt direct UDP paths outside the configured SOCKS5 proxy. Without deep network stack control such as TUN interfaces or socket interception, browsers may send WebRTC and QUIC packets through the host's real network interface. Aurorium Browser claims to solve this by natively supporting UDP proxying so that both QUIC and WebRTC traffic stays inside the tunnel. The article stresses that simply disabling WebRTC or forcing HTTP/2 fallback is insufficient and can itself create detectable anomalies for anti-fraud systems.