You may know that privacy laws aren’t respected everywhere. In some places you can be forced to decrypt your files, or worse, get accused of a violation just for having encryption. A VeraCrypt hidden volume helps with the first problem but not the second. That’s why the project developer built Phantomdrive.
Phantomdrive is a fully open source USB drive that shows up as an 8GB disk when you plug it in. The OS has no way to detect the rest of the storage. To unlock the hidden partition, you open a text file on the visible part of the drive, type password: YOURPASSWORDHERE and save it. The drive disconnects, remounts the hidden partition, and AES-256 handles the encryption and decryption on the fly.
Design
The hardware, firmware, and mechanical design are all open source. The developer built it around a small chip called the CH569, from the same company behind the CH340 USB-to-Serial chip you’ll find on most Arduino clones. It has USB3, SD/eMMC support, and a hardware AES block built in.
eMMC was too expensive due to AI-driven demand, so the developer went with an SD card instead. If someone tears the device apart they’ll find it, but everything on it is encrypted. The enclosure is sealed with epoxy, so any attempt to get inside means destroying it first. Once eMMC prices drop, a version using it will follow.
The board itself is simple. It’s a CH569 chip, a USB port, two buck converters, a firmware update button, an SD card, and some supporting components.
Cryptography
The developer verified encryption works through functional tests and ran it against OpenSSL’s AES implementation. Most of the GitHub issues that surfaced were AI-generated noise or already fixed bugs, with one real exception around AES-XTS covered below.
Key Derivation
A Key Derivation Function (KDF) turns your password into an encryption key. The naive approach is padding the password to 32 bytes and using it directly.
That’s weak. A precomputed table could crack it without even brute forcing. To fix that, Phantomdrive adds a unique salt per device.
With different salts, an attacker has to compute keys for each device separately, and you can’t swap the SD card between devices. You can read your salt like this:
udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7
So, 34FC1FA7145467F7 is the salt for this device, which you will need to recover the data if it ever fails. Save that value. You can also change the Phantomdrive name and the USB PID/VID in firmware if you want more stealth. On top of the salt, the KDF runs 100,000 rounds of SHA-256.
That adds about 3 seconds to unlock time, which is already at the limit of what the chip can handle. Argon2 isn’t an option since it needs too much memory. If you need stronger security, you can increase the round count, use a software encryption layer on top, or look for a different device.
AES Modes
AES is a block cipher that works on 16-byte chunks. Different modes turn it into a stream cipher.
AES-ECB is the naive approach, encrypting each block directly. The problem is that identical plaintext blocks produce identical ciphertext blocks, which leaks patterns. Attackers can also manipulate the ciphertext in predictable ways. Not good.
AES-CTR solves this by encrypting a counter and XORing the output with plaintext.
The main risk with CTR is nonce reuse. If an attacker copies your ciphertext twice and can guess one version, they can recover the other. The developer gets around 9 MB/s write and 20 MB/s read with AES-CTR.
AES-XTS is the disk encryption standard and uses two keys. K1 protects the data, K2 generates a tweak per sector.
Each 16-byte block gets its own adjustment (T0, T1… Tn), then blocks are encrypted one by one to produce the final ciphertext.
It’s more secure but slower, around 6 MB/s write and 10 MB/s read on this hardware.
Firmware
The firmware is built on two open source libraries:
BSP: https://github.com/hydrausb3/wch-ch56x-lib
ISP: https://github.com/hydrausb3/wch-ch56x-isp
Password Snooping
The device doesn’t understand file systems. It just handles raw USB WRITE10/READ10 commands and passes them to the SD card. To detect the unlock password, the firmware scans every write for the string password: before passing data through.
void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
const char *prefix = "password:";
const size_t prefix_len = 9;
uint32_t i;
for (i = 0; i + prefix_len <= len; i++) {
if (buf[i] != 'p')
continue;
if (memcmp(buf + i, prefix, prefix_len) != 0)
continue;
size_t pw_start = i + prefix_len;
size_t pw_end = pw_start;
while (pw_end < len && (pw_end - pw_start) < sizeof(pending_pw) &&
buf[pw_end] != '\n' && buf[pw_end] != '\r' && buf[pw_end] != '\0')
pw_end++;
size_t pw_len = pw_end - pw_start;
memcpy(pending_pw, buf + pw_start, pw_len);
pending_pw_len = pw_len;
memset(buf + i, 0, pw_end - i);
return;
}
}
Once the password is found, it gets copied into RAM and the buffer gets zeroed out so the password never touches the disk. Keep in mind, if you store a lot of data on the unencrypted partition and any of it contains the string password:, you could get a false match. If that’s a concern, you can change the trigger string in firmware or look for a different approach.
Video
The developer has also published a video, if you want to get into details of this project.
Summary
Phantomdrive is an open source USB drive that shows up as a plain 8GB disk while hiding the rest of its storage. You unlock the hidden partition by saving a password in a text file on the visible disk. The firmware catches it in the raw write traffic, keeps it in RAM, and never writes it to disk. Encryption is AES-256 on a CH569 chip, with a per-device salt and 100,000 SHA-256 rounds for key derivation. It’s limited by the hardware, so it’s weaker than memory-hard options like Argon2.
If you want to go deeper into how privacy can be preserved on real systems and how forensic traces are created and analyzed, our Anti-Forensics training is your next step. We covered advanced techniques for preserving your privacy and understanding what investigators can still see even when you think you have covered your tracks.
October 2026 brought a clear demonstration that hardware wallets, while far safer than software alternatives, are not immune to sophisticated physical attacks.
Beginning on 9 October, hundreds of users who had purchased Ledger devices through the Southeast Asian reseller CryptoBilis saw their funds drained across Bitcoin, Ethereum, TRON and other chains. On-chain researchers estimated losses between roughly $86 million and more than $100 million. Ledger confirmed that at least one affected device contained an unauthorized hardware implant and stated that every confirmed loss in the incident was linked to a device sold by CryptoBilis. The company has emphasized that its own infrastructure, firmware and direct sales channels were not compromised.
The Supply-Chain Attack
The attack was physical. Someone in the distribution chain opened genuine Ledger Nano X devices, installed a small circuit board and resealed them. The implant sits inside the enclosure under or behind the screen where foam padding normally rests, and taps the SPI bus that carries data from the Secure Element to the display. When the owner sets up the device and the screen shows the 24-word recovery phrase, the implant’s microcontroller recognizes those screens, reconstructs the words and sends them out over LTE using a provisioned eSIM and a small antenna. Because the original Secure Element remains untouched, the device continues to pass Ledger’s Genuine Check. Mark Karpelès and Tibane Labs have documented multiple generations of the implant, progressing from early versions with visible wires and a smaller battery to later flex-circuit designs that are harder to notice and sometimes keep the original battery.
Source: Mark Karpelès
Mark Karpelès publicly posted a photo of a unit that arrived from Malaysia with flawless packaging. The extra hardware only became visible when he opened the case.
Source: Mark Karpelès
Similar implants have been reported in devices obtained through other channels, including Japanese marketplaces and at least one European store, although Ledger has so far tied every confirmed fund loss specifically to CryptoBilis purchases.
It was confirmed that the Ledger supply chain is compromised in Europe as well. Source: @0xJohannes_
The company has asked the reseller to halt sales and has advised recent buyers not to initialize unused devices. Those who already completed setup are told to move their assets to a new signer purchased directly from Ledger and initialized with a fresh seed phrase.
How to Buy a Hardware Wallet Safely
The single most effective protection is to purchase directly from the manufacturer’s own online store.
Authorized resellers are listed on the manufacturer’s website, yet CryptoBilis was also a partner that introduced modified units into the channel. Marketplace listings of third-party shops carry a much higher risk of both counterfeits and implants.
Once the package arrives, you should confirm that a new device requires you to generate a recovery phrase yourself on first use. Any recovery phrase that’s already written on a card or printed in documentation belongs to someone else and should never be used. The phrase must appear only on the device’s own screen and you must write it down yourself on paper or metal. Never type it into a computer or phone, don’t use websites or applications with it.
Below you can see a photo of the hardwallet owner signing a transaction inside the faraday cage to avoid any interference and possible theft.
Source: @oren_z0
Check Your Wallet
The first question is the source of the device. Anyone who bought a Ledger from CryptoBilis or another untrusted reseller in recent months should treat the unit as unsafe. Genuine Check is still worth running because it confirms that the Secure Element is original and the firmware is approved, yet it can’t detect added circuitry that merely listens to the screen.
You can also visually inspect the case for extra wires or antennas that can reveal tampering, but modern implants are designed to be inconspicuous and reliable detection usually requires opening the device. After a wallet is set up, compare receiving addresses shown on the device screen against those displayed in the companion application and review transaction history on block explorers for unexpected outgoing transfers. The recovery phrase must be generated by the device under your direct observation and written down only by you.
Mark Karpelès also has a few videos on opening and closing Ledger wallets that you might find helpful.
What to Do If You Suspect Compromise
If a device was purchased from CryptoBilis or any other questionable source and has already been initialized, the existing recovery phrase should be treated as compromised. Move your assets to a new wallet whose seed was generated on a trusted device bought directly from the manufacturer. Never reuse the old seed for any purpose.
More Recommendations
A BIP-39 passphrase adds a meaningful layer of protection because it isn’t displayed during ordinary setup and must be known in addition to the seed. It’s also known as passphrase (the extra “25th word”). It’s optional and you may choose it later. It is not generated or displayed by the device during ordinary setup. Adding it creates a hidden wallet, which means you have completely different keys and addresses.
For larger holdings use a multisignature arrangement to reduce reliance on any single device. Always check the address where you send your money to, as it can often be replaced by malware or bots making small transactions with similar addresses to mislead you into sending money to this similar address.
Hardware wallets still provide strong protection against the majority of remote thefts precisely because private keys never leave the Secure Element and every transaction requires physical confirmation on the device itself.
Summary
Hardware wallets can pass authenticity tests and still contain an implant capable of capturing the recovery phrase the moment it appears on screen. The best thing you can do is to buy devices only from the manufacturer, generate the seed yourself on the device and write it down offline. For anyone who recently purchased a device from a third party, the cost of generating a new seed and moving funds is far lower than the cost of discovering the compromise after the fact.
Let’s talk about something most people never think about. When the news reports on a cyberattack against a big retail chain, the story usually sounds the same. A database got leaked or ransomware locked up the company’s files. These are real threats, and they deserve attention. But what happens if a hacker skips all of that and simply walks into a physical store with a laptop tucked in a backpack? No malware sent through email and no phishing link, just being there physically.
In this article, we are going to build a picture, drawn from several real walkthroughs of ordinary retail stores, all pointed toward one goal. We want to see the store the way a pentester sees it.
A Hacker in the Supermarket
Imagine someone stepping through the front doors with that mindset. Within a few minutes of walking the floor, a handful of things stand out.
There are the transformer checkout terminals and the self service kiosks, the modern face of retail, and also a possible weak point. There are staff call buttons mounted near the aisles, small radio transmitters that broadcast a fixed code each time someone presses them, a code that could potentially be captured and played back later. There are wireless DECT handsets still in use on some sales floors, the same cordless phone technology many offices have relied on for years. There are data collection terminals, plain Android devices that sometimes carry no password protection at all, with access to the store’s Wi-Fi settings. And running along the floor and behind the counters, there are network cables, which in the wrong circumstances could let anyone plug in and reach the store’s internal network.
Day 1 – Becoming an Insider
Many corporations believe their internal network is sealed off from the outside world, safe behind firewalls and passwords. That sense of safety can end at the first unlabeled cable lying loose on the floor.
Someone can walk up to a transformer checkout terminal, unplug its network cable, plug in a laptop instead (or better yet, one of those devices we showed in previous articles), and type a simple command.
kali > sudo dhclient
That laptop could be handed an IP address from the store’s own internal network. If the network uses a /27 mask, that means an entire segment of the corporate infrastructure could open up right there.
Scanning the network might take only a couple more minutes, and inside, a hacker could find exactly what you would expect from a typical store. There could be the store manager’s workstation, with an open RDP port for remote access. There could be a Wi-Fi router still running its factory default settings. There could be a DECT base station handling internal telephony. There could be surveillance cameras, other registers and terminals, and tucked away in shared folders and configuration files, credentials and passwords saved in plaintext.
From there, someone could try connecting to the manager’s computer. If the RDP client offers a choice of accounts, and one of those accounts, say one named operator, needs no password at all, that should raise a flag. Normally Windows blocks RDP logins for accounts with blank passwords, so a setup like that means someone deliberately switched that protection off, likely to keep an easy access route open for themselves. Sysadmins often do it. But that’s a backdoor. We often see the same issue with VNC. That route could lead to the remote desktop of an employee with access to corporate email, internal messenger conversations, financial documents, work schedules, and delivery data.
And since Chrome is installed on nearly every computer in sight, opening Passwords could show saved logins for internal services, everything from the CRM system to the warehouse management software, sitting there in plain view.
How to Fix It
Passwordless accounts feel almost like a relic from an earlier era, yet they still turn up in retail environments from time to time. Alongside them, flat, unsegmented networks are common, where cameras, workstations, and Wi-Fi routers all sit together on the same segment. Add to that the simple physical accessibility of the equipment. Network cables, ports, and switches are often placed exactly where any employee, or any visitor, could reach them without much trouble.
Segment the network properly, giving separate VLANs to registers, service equipment, and employee workstations, so a breach in one area does not open a door to everything else. Restrict which devices are even allowed to connect through RDP in the first place. Turn on MAC address whitelisting along with Port Security, so an unknown device cannot simply be plugged into an open port and join the network. Require real passwords on every local account, without exception. Disable browser based password storage for anything tied to internal systems.
And finally, ask security staff to keep a closer eye on the registers themselves.
Day 2 – Telephone Game
Consider a small, easy to overlook detail, a staff call button tucked into a corner near an aisle. Pressed once, it sends a chime ringing across the store, and a salesperson comes over a moment later. Simple enough, on the surface.
Except with a HackRF One someone could intercept and record the exact signal the button sends the moment it is pressed. If that button broadcasts the same static signal every time, with no protection against replay, then anyone who plays that recorded signal back over the air could trigger the same chime, without ever touching the actual button. This is what we call a replay attack, and it remains a real possibility even now.
Once that chime lives on someone’s laptop, a single click could ring it out across the entire store. Employees might rush toward the sound, leaving a register briefly unattended, while someone else nearby has a short window to act.
The same HackRF One, paired with an open source tool called gr dect2, could also be used to listen to the surrounding airwaves. If a store still relies on wireless DECT handsets for internal communication, a call placed from one handset to another could, in principle, be intercepted and decrypted in real time as it travels through the air. From that point, anyone listening could pick up delivery schedules, work rosters, and conversations about register problems, all carried over employees’ DECT handsets.
Older pentest reports sometimes describe this kind of attack as only medium risk, mostly because of the cost of the equipment and the technical skill it supposedly requires. It’s different now. An original HackRF One costs somewhere around three hundred dollars, and less expensive clones can be found on online marketplaces for a fraction of that price. And gr dect2 makes the whole process more accessible, since it is an openly documented, freely available project.
How to Fix It
The fixes here lean more organizational than technical. It makes sense to retire primitive call buttons in favor of systems that use dynamic, constantly changing codes instead of a single static signal. Alongside that, replacing outdated DECT telephony with modern VoIP or straightforward wired communication removes much of this risk entirely.
Day 3 – Corporate Wi-Fi
What about the Wi-Fi? On paper, it can look genuinely solid, not a simple router with a shared password, but full WPA-Enterprise authentication requiring a proper login and password from each user. That sounds like a real obstacle, and in many ways it is. But it does not fully close the door. Someone could set up a rogue access point using the exact same network name as the legitimate one. If an employee’s device, whether a work tablet or a personal smartphone, tries to reconnect automatically, it might see two access points broadcasting the identical name and simply pick whichever one offers the stronger signal and the faster response. A rogue access point built for this purpose could easily be tuned to answer faster than the real one. Once a device connects to that convincing twin, it attempts to authenticate as usual, and in doing so, it sends its credentials straight into someone else’s logs.
How to Fix It
Setting up EAP TLS with proper certificate validation on every client device helps ensure a fake network cannot simply mimic its way into a successful login. Monitoring the surrounding radio spectrum regularly is also worthwhile. Even simple, freely available tools can detect unauthorized access points broadcasting names that match or closely resemble the real corporate network. And training staff matters. If a Wi-Fi password is unexpectedly requested a second time, or a connection seems to take suspiciously long, employees should feel comfortable reporting it to security or the IT security team right away.
Day 4 – Transformer Register and Cash Drawer
A transformer register is really a combined hardware and software unit, built around a metal cash drawer, both stationary and handheld barcode scanners, and a receipt printer. Along its bottom panel often sits a row of unprotected USB ports. Plugging in an ordinary keyboard there opens the door to some experimentation.
Pressing Ctrl Alt and one of the function keys from F1 through F5 can switch the screen to a text console, prompting for a login and password. Full system access could sit right there within reach. Even if the Alt F2 shortcut for quickly launching commands has been disabled, the multi user Linux console underneath may remain fully accessible regardless.
Power cycling the device and pressing Delete could open the BIOS. Without a boot password protecting it, the machine could be booted from an outside USB drive, handing over full control of the system, along with the ability to change settings or install unwanted software.
The most interesting risk, though, waits underneath the register itself. The metal cash drawer typically has a mechanical emergency release button on its underside. If the drawer has not been locked with a physical key, which happens more often than store staff would like to admit, then any customer could simply lean down, press that button, and slide the cash right out.
No discussion of registers is complete without mentioning their close relatives, the self checkout kiosks. These are essentially the same transformer registers, just packaged in a form factor that happens to be even more exposed. USB ports, network ports, and power ports often sit within easy reach. The real difference is that a transformer register might occasionally be watched by a nearby salesperson, while a self checkout kiosk usually sits alone in a corner, without much oversight at all.
Standing casually near a kiosk for just a few minutes could be enough to observe an employee entering their access code. From there, that access could open up the kiosk’s full functionality, including the ability to ring up items, process returns, and open that same metal cash drawer hiding underneath.
How to Fix It
The solution here is fairly clear once the problem is understood. Restricting physical access to the register hardware itself, through USB port blockers, closed enclosures, and sealed covers, prevents outside devices from being connected in the first place. A BIOS password combined with disabling boot from removable media protects against attempts to seize control of the system through a flash drive.
Employee authorization deserves attention too. Since the register already comes equipped with a barcode scanner, a smart approach is issuing personal ID badges with the employee’s password encoded directly into the barcode. The employee scans their badge, the system authenticates them instantly, and the actual password stays hidden from anyone watching nearby. Leaving the alphanumeric combination off the badge entirely prevents it from being typed in manually as a way to bypass the scanner.
And of course, the lock on the cash drawer matters. If it is even possible to leave that drawer unlocked, sooner or later it probably will be. Drawers that lock automatically, without relying on a person remembering to do it, offer a much more reliable solution.
Day 5 – Refund
Consider someone playing the role of an ordinary, everyday customer. They buy a small item in the store, pay with a card, and walk away with a receipt like anyone else. Once a self checkout kiosk sits idle for a moment, tapping the top left corner of the screen could open a hidden staff menu.
An example of what such menus might look like
The system would ask for authorization. If someone types in a password they had observed a cashier enter earlier, often a simple employee ID number, that alone could be enough to land inside the cashier menu.
From there, selecting a refund by sales receipt option could display a list of recent transactions, including the very purchase just made. A further step worth testing is whether the refund could be redirected, not back to the same card used to pay, but to a completely different one, belonging to someone else entirely. You might expect the terminal to block an operation like that, or at least demand confirmation from a senior employee before proceeding. In some systems, neither of those things happens, and an ordinary cashier’s password turns out to be enough to redirect the funds elsewhere.
To its credit, a system like this may honestly display a warning that the money will be sent to a different card than the one used for payment. But it can carry out the operation anyway, without further checks.
The item would stay with the customer, the original purchase would turn into a refund on paper, and the store’s money would end up in someone else’s account. One more detail worth checking is whether the refund function has any built in time limits. Many places only allow refunds within a set window, say fourteen days, in line with consumer protection law. But in some systems, attempting to process a refund for a purchase made several months earlier goes through without any resistance at all.
This points to a deeper gap in business logic and access control. The authorization threshold can sit far too low, since a rank and file salesperson’s password may be enough to trigger a real financial operation, and that password is often easy to observe over someone’s shoulder. There may be no check to confirm the refund card actually matches the original payment card. A refund landing on a different card is not automatically suspicious on its own, since many banks and retail chains support this for customer convenience. But operations like that should require sign off from the store manager, a financially liable employee, or someone else holding proper authority. And finally, there may be no meaningful time or amount limits at all, meaning refunds could remain possible over an unlimited stretch of time, and theoretically for an unlimited amount, up to whatever balance the register happens to hold.
How to Fix It
Two tier authorization is genuinely useful here, paired with a strict time window governing refunds. Automatic refunds could be limited to the last fourteen days, with anything older switching over to manual processing, complete with multi level review and documented sign off.
Tying the refund card to the original payment card by default, as a standing rule, closes much of this gap. Cash refunds, or refunds sent to a different card, should remain the exception rather than the norm, strictly regulated and logged separately from everything else.
A dedicated audit log for every refund operation, tied clearly to the cashier’s ID, the receipt number, and the recipient card, makes it possible to review the whole trail later if something looks off.
Summary
Nothing here requires exotic tools or rare expertise. The overall picture is worth taking seriously, because a store is never just a building full of shelves and registers. It functions as a branch of the corporate infrastructure itself, a set of trusted interfaces placed out into public space, right in front of every customer who walks through the door.
But these small, easy to overlook pieces can chain together. Network access can lead to credentials, credentials can lead to internal systems, internal systems can lead to operational data, and operational data can eventually lead to real financial consequences. A useful security assessment in an environment like this does not simply end with a recommendation to close a port and set a stronger password. It ends with a more useful question worth asking. Who decided, at some point along the way, that all of these things should sit within the customer’s reach in the first place?
If you enjoy hacking and would like to get started in cybersecurity, we have created the Cybersecurity Starter Bundle II to equip you with the knowledge and skills needed to begin your journey. If you want to advance your skills even further, our Cyberwarrior Path is made to help you delve deeply into the technology and show you how to break it
Login
