This project masterfully integrates open-source transparency with plausible deniability, offering a sophisticated alternative to the "black box" security of proprietary drives. It is a high-level engineering solution that empowers users through verifiable privacy rather than blind trust.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
The Open Source USB Drive Built for Privacy
Added:We feel like now more than ever people should have access to tools required to reclaim their privacy.
But not everyone and everywhere respects that right.
There are some cases where having an encrypted device appears suspicious.
We're trying to solve this problem.
Phantom Drive is a completely open source obfuscation device. It's designed to hide in plain sight. When first inserted, you're presented with a normal unencrypted drive, but there's a stealthy way to access the encrypted content.
>> [music] >> Hi, I'm Ryan, the creator of Rookit Labs. Rookit Labs is a company that makes 100% open source security hardware, pen testing hardware, privacy hardware, etc. Today I'm here to talk to you about Phantom Drive, something I've been working on for the past 6 months.
Phantom Drive is a completely open source obfuscation device.
When you plug it in normally, it'll present you with 8 GB or however much data you like of unencrypted regular disk.
There's only one way to make it reveal its second encrypted partition. To do that, you need to create a special file called unlock.txt.
Inside of here, you enter the string password, colon, and then your special password. The drive will then unmount itself and remount the remainder of the disk. Everything will then be encrypted and decrypted in place.
The purpose of this video is I'm doing a pre-order. Rather than me ordering a crushable amount of devices and then selling out, I rather gather interest and then place a large order so everyone can get a device.
This device isn't in the beta stage or testing or anything. I already have the PCB done, the enclosure is finished.
I've completely written all the firmware and I've run various security tests on it.
Okay, so if you stuck around for this long, you are are interested in some of the details of the device and that's exactly what I'm going to talk about right now.
So, it is potentially a little bit simpler than you would assume.
So, the main chip is the CH569.
So, this is the block diagram for the main sock. So, there's a USB 3 host and device controller and USB 2.
Right now, USB 3 has been connected, but I'm using USB 2 for the device.
Maybe in the future there will be firmware updates enabling USB 3. The reason why it's just using USB 2 is because I got it working really stably and after some profiling I realized that USB is not the bottleneck for this device.
There is an Ethernet MAC which of course I'm not using. There's an SD eMMC controller which I very much am using.
And the encryption engine contains a AES and SM4.
AES is probably quite well known.
Whilst SM4 I believe it's a Chinese Yeah, standardized commercial cryptography in China. I don't know if it's secure or not.
I just didn't end up using it. That's obviously something you can implement um if you would like that.
So, yeah, that's the chip.
The There's a USB USB 3 male port on the board with the USB 3 SuperSpeed lines connected.
And of course the standard USB 2 data lines.
This is the SD card holder.
So, we I used these uh resistor arrays for the mandatory pull-ups for SD cards.
There's two small switch mode PMICs, one to go to 1.2 V, one to go to 3.3 V.
Uh this is a TI part, I believe.
Yeah.
Uh 2 amp high efficiency, blah blah blah, buck mode supply, pretty standard stuff.
And as far as the squantlets go, that is actually it. There is a crystal uh for the thing. For the for the sock, there's a reset button. So, that's what we're that's what you need to press if you want to flash the firmware yourself. You basically press that button, insert the SD card, or sorry, insert the Phantom drive, and you can use a DFU flashing utility.
I will quickly go over the board again.
I don't think this is going to take very much time cuz it's quite simple.
So, it's a four-layer board.
Let's actually go ahead and turn off the silk screen.
Uh turn off all this bottom stuff as well.
I don't need this. Let's turn on the front silk screen.
So, here's the here's the sock.
This is the the USB uh pads are mounted on the other side.
And these are impedance controlled 90 ohm traces to the the sock.
Uh the two switch mode Oh my goodness.
Apologize.
The two switching power supplies are here.
You have the output with their inductors here.
These are the resistor arrays, the the pull-ups for the SD card.
Let's take a look at the 3D view.
So, this is the whole device here. You can see obviously this is the our um our ISP button.
We can push that to enable the not ISP, DFU.
The go to the bootloader and receive instructions when you want to upgrade firmware. And that's a really nice part of this project. So, you don't need any special programmers to program this part. I will just uh be distributing new firmware uh for this device. Right now there's a 1.0 release.
And with that, you will have um potentially a 1.1 or 1.2. I can't really see any major there's definitely no major changes in the future.
Um but once you receive that image, you can just um update the device yourself.
Which is nice.
The other side here is the SD card.
So, I think a lot of people in the comments were asking why I use an SD card versus a soldered down memory chip.
And the answer is super simple. So, the current situation with AI has made eMMC chips um extremely expensive. So, if we if you actually go to look at the cost of them on whatever website for a 32 GB eMMC you're looking at over $100.
Um I can't I can't really justify doing that right now.
So, in the future there will be a eMMC version, but um not right now. So, this using an SD card is nice because it gets um you can choose whatever size you like.
So, if you want 32, 64, 128, 512, whatever GB you just um choose an SD card you like and and pop it in.
The speed of the SD card and quality of the SD card will greatly affect the performance uh read and write speeds of the device.
And to actually go from this to eMMC is very easy. If you don't know, eMMC, loosely speaking, eMMC is basically just a soldered down SD card with a few extra Well, it's an eight lane instead of four lane as far as data, so it should be uh in theory a little bit faster uh depending on the eMMC controller itself and timing specifications.
This is the entire device.
I can go out and take the board so you can see it.
I find them the most the cleanest way to open it up is by just sliding a very small blade under, and that should loosen it off, and then slide the blade around.
And if you buy one of these, you'll be shipped with two extra pieces for the enclosure cuz I have had I've noticed that um they it seems to hold up quite well, but if you do open and close it like more than 10 times, you do run the risk of breaking these pins, so I just decided I would ship some.
You'll basically you will receive uh this and then a fully assembled device as well.
So, here's the device here.
Um yeah, again, there's a I mean, you can see the DFU switch.
So, I'll walk into flashing the device quickly.
I'm going to go into the Phantom Drive repository.
So, there's some different You're not going to be able to read that.
Uh there's some different targets here or different options that you can set.
So, you can build this with UART support and USB debugging support. You might be interested in UART support if you want to do some uh software hacking on your own. Uh there are on this board, you probably can't see them, but there's some solder points there, so you can fly a wire down and have access to UART TX and RX. I only really use transmission from this board, uh but there's no reason why you couldn't use reception, and that's really nice for some simple debugging and some profiling that I've done before.
But, the standard Oh my goodness.
The standard command is just make.
And this is going to build the production image. It's not an environment variable. It's make UART equals one.
And that will build with UART will be turned on, and you can I'm sure many people care about that.
Uh and for this, you can use make and then make flash.
So, I'm going to go ahead uh and insert the device whilst pushing the button.
And the make flash will go ahead and flash your device for you.
Now, if you don't know much about this and you're worried about uh not being able to do this, uh there will be binary images that are distributed uh that you can just flash to the device using a uh simpler tool than this, but this is what's available right now.
I apologize.
So, the this is the main Here's where we set the USB uh uh vendor IDs and product IDs. So, if I do a um lsusb Sorry, lsusb we should see generic Phantom Drive there.
Now, depending on so, I have to ship it with these vendor IDs and product IDs according to the law.
Uh okay, you didn't hear it from me, but you can actually change these to mimic a existing um company's device.
Uh which of course will be a little bit more stealthy. If you want, you can also change this from generic Phantom Drive to tables.
And this is where the vendor information is and the product ID and this has a hard hardware version.
Or sorry, yeah, yeah, it is firmware version written in it as well.
Of course, you can change this to whatever your heart desires. And depending on your opsec needs, that may or may not be required. I'm not going to go into the code because you can read most of that yourself if you're someone that's interested in the code.
But basically, it's all standard stuff.
So, the BSP, the board support package for this chip. So, yeah, I should mention I'm using So, this WCH 56XISP is the in-system programmer. So, this is what is used to flash the device. These are Sorry, my submodules uh dependencies rather. Or well, submodules and dependencies. Whilst the BSP, the board support package is where I get a lot of source code from, too.
And if we jump to this, we can see uh, the descriptions and and whatnot.
Um, again, this is what the that UART thing will set. So, if we want UART, we can enable it through that thing.
And all of this logging is going to happen, um, yeah, if we if we enable UART. And if we don't enable UART, it's not going to happen. Something that people might be interested in is the USB descriptor.
Uh, sorry, no, not the USB descriptor, the serial number. So, if you might notice that we're going to grab a UID from the chip.
And each chip is going to have its own unique ID.
And this is set, uh, in the USB serial number, which we can actually read.
I just forget the command to do that.
Yeah, so, um, so, this is going to give us our unique serial number for our Phantom Drive. Now, the reason why I'm telling you this is cuz you're probably not interested in a serial number, but the serial number is your unique salt for, uh, the KDF that we use. So, I'm going to explain how that works right now.
So, I'm going to open the crypto module.
And the function that you are probably interested in is this derive key function. So, this is how we're actually going to derive our encryption key, and I uh, challenge you, or not challenge you, but, uh, encourage you to read through this yourself, and make sure that you're convinced that it's secure. I'm con- I've convinced myself that it's secure, but So, you see one of these arguments is KDF salt. So, this is uh an 8-bit number of length KDF salt size, which I can't even remember. It's eight.
So, what is that? Eight to eight eight 8-bit numbers or that is yeah, 64 a 64-bit long number.
And if we check the call to derive key, uh this is the the key is derived when we unlock the device.
So, we have a derive key function here. And if we actually look at the function call to derive key is inside of Phantom Drive unlock, which is called when we receive the text string with our password inside of it.
So, and then the salt here is passed from this uh static page variable uh called salt bytes.
And salt bytes is set in Phantom Drive init, which we call from main.
And our salt is going to be the unique ID of the drive.
So, that's very important. So, you need to understand that when we derive the key, we basically are going to take your password. We're going to salt it with that number.
Uh we are going to Yeah.
Um salt our password with our unique key. So, each device is going to have its unique salt.
Uh and then we're going to do a certain amount of KDF rounds from I to number of KDF rounds. So, then we're going to SHA-256 hash it 100,000 times.
Now, the reason why this is important is because you can't take one Phantom Drive, use an SD card on it, and then move it to another Phantom Drive, and then do that again and get your data because the salt is going to be different, the key derivation is going to be different, and your final key will be different. So, if you want to uh if you want to get your data off, like say you take the SD card out, and you want to extract the data, that's completely reasonable because you might have a device that's been infected or damaged by water or something, not infected, damaged by water or something, then do I have the stuff for you. You want to look at kdf.c.
I don't know why it's called that. You want to take a look at the readme. And this readme, so this inside this test folder here is going to have all the the tests where I verified that everything is working as it should be. So, what I did is I I took the device, I went through the normal path of unlocking it, I used f3 write to write a bunch of known data to it, I then extracted the SD card, and then used kdf.c.
This file here, you basically build it, and then you point it to that should be the SD card mounted, you create a loop device, you mount the loop device, and then you should be able to read your data. Now, of course, uh kdf.c is going to need some stuff. So, you need to put in your salt here.
Uh and this is surprise, surprise.
Not the same because I changed some I changed some of the changed some stuff around. So, but your salt needs to go into here, your password needs to go into here, and then you should be able to take your This is the key for the salt and that password, and then you can unencrypt your USB or sorry, your SD card.
Thank you for watching. That was quite a bit of technical jargon. I want people to understand that this device is not only for technical individuals that get into the code and want to flash their device themselves. It is literally for everybody. And I built it in a way that is accommodating to all skill levels and abilities, and I just wanted My whole goal was to make this something that increases everyone's level of privacy because whether or not you need it, I personally am of the belief that everyone should have access to it.
Yeah, that's it. If like and subscribe if you want to support the project, the link is down below to the crowdfunding campaign.
I'm not using Kickstarter or CrowdFire or anything like that because they just take an extra 10% or whatever, and that means it's more it's 10% more expensive for you. I'm so excited to finally launch this product after all my hard work. So, thank you very much. Thank you for watching. Thank you for supporting.
Related Videos
LBF101 Creating an XML Changelog
liquibase7511
3K views•2026-06-15
Alta Labs Cloud Dashboard Real time Network & Xnet Insights!
ShinyTechThings
158 views•2026-06-17
Wait... Group Policy Not Applying? Check This First!
keeplearning_iT
144 views•2026-06-15
Leetcode Weekly Contest 506 | Life's boring these days
Pudeesht
2K views•2026-06-14
microJAM: MAKING A MICRO GAME FOR A GAME JAM IN CLOJURESCRIPT AND TOTALLY NOT C
janetacarr
156 views•2026-06-18
Partitioning vs Bucketing vs Clustering: How to Make Queries 100x Faster
thedataandaiguy
194 views•2026-06-16
Design Claude Code Like a Senior Engineer
hayk.simonyan
344 views•2026-06-19
Linus Torvalds: AI Won’t Replace Understanding Code
SavvyNik
140 views•2026-06-19











