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.
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.
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.
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
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.
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.
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.
Airport forensic team can’t flag an encrypted drive it can’t detect.
The article talks about this.
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