Nifty. I couldn’t see a practical use for myself but, it’s cool none the less.

Very useful for getting any sort of private data through an airport that does not respect privacy. For example any US airport…

No it isn’t. It will be treated like any other drive where encryption is nothing new. In fact, to look for a text file and then make something accessible means it is likely much easier to detect that something is off about it than regular encryption that just looks like random data. Whether it tries to hide it’s true storage capacity or boots its own internal OS to present storage, people often think they’re being clever when really they’re just making themselves stand out.

How would it be detected? It seems like the password detection and decryption is happening at the hardware level, and they take steps to have it show up as nothing more than a standard drive. I’m not an expert on this stuff though.

Do you think TSA/CBP is going to check the flash data lines to see if the MCU is scanning the flash internally?

This isn’t a standard USB flash controller… You would need to break the casing and physically probe it to figure out that something was off as far as I can tell. It’s not like the MCU broadcasts that it is scanning to the USB port.

You would have to be hitting the stick pretty hard, not just a normal file scan to notice the timing being slightly too long in a small portion of the scans. The bigger problem would be that the flash drive would be brand-recognizable if it ends up being mass produced that they might auto-confiscate it, and of course the default file that it searches for being known.

If I got it right, you could easily detect this drive by just creating password.txt. as the article says it creation is intercepted and skipped. Hence if there is no password.txt afterwards, you know what you’re dealing with. Still, you have to know this AND care.

It’s only skipping if your password matches. Otherwise it’ll just be a normal file.

Ah okay, so then I retract my statement and better my reading-skills 😁

It looks for a string “password:xyz” bring written to any file, where xyz is the password. If you get the password wrong it’ll just write the file normally

Ah okay, so then I retract my statement and better my reading-skills 😁

No worries, I had to read stuff outside of the articles to get that information

Do you think TSA/CBP is going to check the flash data lines to see if the MCU is scanning the flash internally?

This isn’t a standard USB flash controller… You would need to break the casing and physically probe it to figure out that something was off as far as I can tell. It’s not like the MCU broadcasts that it is scanning to the USB port.

You would have to be hitting the stick pretty hard, not just a normal file scan to notice the timing being slightly too long in a small portion of the scans. The bigger problem would be that the flash drive would be brand-recognizable if it ends up being mass produced that they might auto-confiscate it, and of course the default file that it searches for being known.

You’re proving my point. The device actually fails both ends of the threat model.

If it’s a casual check, custom hardware is total overkill. You take a standard 1 TB off-the-shelf drive formatted to its full 1 TB capacity as a single partition. You put normal files on it and hide the encrypted header—plus a lightweight host-side decryption utility/bootloader—inside a single JPEG using steganography. To any border agent, OS, or disk tool, the drive is just a healthy 1 TB partition containing readable files and residual random data from a quick format. There are no custom drivers installed, no modified media file sizes, and no missing drive space to trigger software or system flags. Once at your destination, you simply extract the utility from the JPEG on a trusted machine to mount the hidden sectors.

If it’s a high-scrutiny check, this custom hardware actively guarantees you stand out. CBP doesn’t need software checks—non-destructive X-ray imaging is standard screening. Under a scan, a mass-produced thumb drive shows a single integrated ASIC on NAND. The Phantom Drive immediately reveals a generic CH569 microcontroller, buck regulators, UART test points, etc.

It visually stands out like a neon sign under basic physical imaging. It doesn’t defeat the threat model—it actively creates the physical hardware anomaly.

It would have to be distinctly from any thumb drive over the last decades. My older ones definitely weren’t just a single chip, I recon you’d need some immense training specifically on drive designs to know this isn’t just a normal one from like 2010 or 2015.

Or some old cheap/free one. A nearby university open day recently had a stack of free 8 GB USB sticks they were giving out.

You know, you can just write stuff yourself. You don’t need ChatGPT to write the em-dashes for you

Airport forensic team can’t flag an encrypted drive it can’t detect.

The article talks about this.

You are yapping your ass off. This is a hardware mod, not a software package. Its literally using a custom storage controller chip that only physically unlocks the connection to the secret storage once it detects a certain key file on the decoy storage. They would have to xray the drive individually at close range with high resolution and know a lot about electronics to even come close to figuring out that something is different. There is no way to detect a fake USB HID so unless they open it they wont be noticing shit.

You’re completely confusing device classes and how forensic acquisition works.

First, it’s a USB Mass Storage device, not a USB HID (Human Interface Device). Mass Storage operates via SCSI block commands wrapped in USB packets.

Second, even if the custom firmware successfully fakes the LBA table to report 8 GB, it fails at the protocol level. Forensic tools don’t just read files—they issue low-level SCSI INQUIRY and MODE SENSE commands. Commercial flash controllers (Phison, Silicon Motion) have hardcoded ASIC signatures and proprietary descriptors. A generic CH569 MCU running C code trying to fake these descriptors or pass off software-bridged microSD reads introduces packet latency, timing jitter, and missing SCSI pages that log protocol anomalies during raw acquisition.

Finally, software doesn’t matter if they look at the hardware. Modern 3D CT/X-ray baggage scanners visually isolate silicon footprints instantly without opening the casing. A standard commercial drive is a single integrated ASIC on NAND. A board with a generic CH569 MCU, voltage regulators, UART test points, and a physical microSD socket stands out.

You are so close to being right, and yet, so far away.

You misunderstood what is seen or how it works.

When the drive is checked, you can see files and whatever on what appears to be an 8GB flash drive.

You have to add the specifically worded txt file into that drive before the hidden drive shows up.

Saving important documents as an emergency backup without worrying about it getting stolen. I guess the hidden partition adds another layer against someone who might want to try and brute force it

Why not just use veracrypt?

Vault is visible and therefore obvious. If you need to be discreet, this sounds useful.

veracrypt.io/en/Hidden Volume.html

Ah yes, certainly easier and more convenient to boot into a live OS or hidden OS every time you need to mount a hidden volume (per VeraCrypt’s recommended guideline), instead of just using the hardware from OPs post.

Those recommendations are for protecting data you want to stay a secret; it would also apply to unlocking this fancy USB drive, as a best practice.

The USB still has advantage in that no one will compel you to unencrypt a drive that they don’t realize is encrypted, which can be a pretty significant advantage depending on who you’re hiding the information from, or why.

you don’t have to boot into some special live OS to mount the hidden volume. It can be mounted just like a normal encrypted volume.

That hides another volume inside another VeraCrypt volume, so it’s obvious it’s not a normal drive

That’s what I would go with if I was inclined. Create a volume the size of the drive and add a hidden volume with a different password within like we’ve been doing for years (decades at this point maybe almost).

I would upload encrypt file somewhere and download it when needed. If you’re worried someone will actually access your USB stick looking for encrypted data, why carry it at all? It’s cool if you want to pretend you’re a spy or something but it’s not very practical.

That’s assuming that wherever you are going to or coming from has an internet connection. It’s likely that there will be a connection, but it’s still not a guarantee. And if there is a connection, the size of the files you’re carrying may make using that connection impractical.

Yes, but you can just carry encrypted hard drive with you. Hiding encrypted data is useful pretty much only for legal reasons. You want to take it across border and are worried TSA agent will force you to decrypt it or something. What is safer in that case? Carrying a USB stick with hidden encrypted partition or not carrying anything at all and downloading the data later? I would say the latter. Smuggling encrypted data through custom checks into a war zone with limited internet access is the cool but unlikely spy games scenario I was talking about. Encrypted microSD card would be even more secure in that case.

to a war zone? such inspections are done not only in unlikely scenarious like when going to “a war zone”

The “war zone” was referring to difficult internet access. Iran recently cut off entire country from internet. If you’re going to USA you may be inspected but you will most likely get internet access once you crossed the border.

I guess you might just want to carry all your passwords in there, but then generally the password file itself is encrypted so I don’t see the point.

that’s like saying “password managers require a password so I don’t see the point”

That is pretty much what I said yeah

I mainly carry thumbdrives for larger files or things I don’t want hosted online.

Ima mention shufflecake again b/c I want it to become popular and successful.

Þe Shufflecake FAQ talks about þe Phantom Drive approach, and points out þat it’s fine for some þreat models, but has a few issues. First, it’s easy to detect þe hidden partition, and þen XKCD 538. Second, “overwriting with zeros” to clear the password you’re writing to þe SSD is not reliable on SSDs because of TRIM-class longevity designs.

Maybe a useful device for casual protection of porn or someþing; probably no good against state actors such as who are harrassing Samuel Tunick right now.

If pointless noise on forums is one of the biggest downsides of LLMs, isn’t your whole spamming thorn game self defeating?

I knew someone on Reddit who did it. Be thankful that Lemmy renders the thorn.

its a þ in my side tbh

Does it actually do anything if i ‘dd’ entire disk? id be curious how compatible this is with linux

I mean, presumably this is all device-side on the stick.

It mounts the two partitions separately, and presents them separately. It doesn’t need to pass through the actual SD card to the host system at all.

If you dd the decoy partition you only ever see the decoy partition. Because the decoy partition is presented as a complete device, not just a partition, to the host system.

Why would this be incompatible with linux? If this is done the way it seems it is done, it’s not a filesystem trick.

It’s two partitions on one SD card being presented as two separate devices by the microcontroller that has actual direct access.

The real vulnerability would be that you could just crack it open to find the SD card.

you could just crack it open to find the SD card.

Funny enough, had the same thing once in an aliexpress usb.

If he had only spent an extra $0.50 and added a Microchip 608c (www.microchip.com/en-us/product/atecc608c) to the design, then you wouldn’t have to deal with cleartext passwords in files. Instead, you could have elliptic-curve, asymmetric public-key encryption.

So you make a competitor then and I’ll buy it

I’ll stick to a Veracrypt full disk encryption with a hidden partition. All the benefits of a duress password, none of the data deletion that gets you V&

PSA: Veracrypt recommends against using hidden volumes on USB flash drives (source)

They don’t recommend against it… It’s a detailed guideline on doing it successfully.

A VeraCrypt volume resides on a device/filesystem that utilizes a wear-leveling mechanism (e.g. a flash-memory SSD or USB flash drive). A copy of (a fragment of) the VeraCrypt volume may remain on the device. Therefore, do not store hidden volumes on such devices/filesystems.

I understand that page is a bit dense, so I’m quoting the relevant text from the above source.

They make a very poor job of highlighting something so important in a dense page detailing how to do what they recommend you don’t.

How is this better than a Veracrypt hidden partition on a standard thumb drive?

IIRC Veracrypt is easier to detect since it does some trickery with the filesystem and software while this has 2 memory chips and one is phisically disconnected then it scan for a string that looks like “password:1234” inside a file called “password.txt” at every write and if the password is correct it will connect the chip again, so it’s virtually undetectable unless you crack open the USB stick and know what you are looking at (which is an highly unrealistic scenario for an airport unless you are in a country that’s in a war period)

Not true. Veracrypt’s hidden file system is random data on a preexisting partition that uses no software. You can only detect it if you install Veracrypt and guess the password.

veracrypt.io/en/Hidden Volume.html

Even pre-tech there was lots of bad shit you could do (sugar in the gas tank), but we didn’t (for the most part). Now bad shit is the norm and if you don’t buy into my product I will fuck you up, motherfucker!! Def not Marketing 101.