Double/false bottom encryption

Sup lainons. Dunno if this topic has been raised before, boards are impossible to search, so creating it anyway. By "double/false bottom encryption," I mean the setup where you have two file systems on a drive with different OSes that aren't visible until the drive is decrypted. When you boot from this drive, you are prompted for a password, and depending on which password you enter, one of the file systems loads while the other remains completely invisible. Ideally, you could also have an emergency password that wipes the entire thing. I am asking how to set up this system on a: 1) PC; 2) Generic Android smartphone. With PCs, I know that VeraCrypt has this feature, but it's clunky and I'd love to know if the same can be done with LUKS. With smartphones, I don't even know where to start. By a "generic Android phone" I mean any phone except Pinephone/Librem that can have the bootloader unlocked.

>>19496 I've considered this before. I wasn't aware of it existing, but it ought to be fairly simple to setup.

by PC I assume you mean windows ? I think I could do it with linux relatively easy, in order to make it not discoverable by looking at the initramfs you might have to setup a second setup system that interprets the password/command and is encrypted to begin with. Of course they can always beat youre deletion by cloning the drive, and they'll likely be able to detect some logic that figures out what to do with the password if they very carefully check everything. But you can obscure what's going on with compiled bins and stuff so its very hard to see.

>With PCs, I know that VeraCrypt has this feature, but it's clunky and I'd love to know if the same can be done with LUKS. You would need to modify the LUKS module, I think. One thing is that it would be very obvious that there is extra encrypted data on the drive if you inspected it thoroughly. Huge blocks of pseudorandom data don't just pop into existence on a hard drive. The idea of filesystem-level steganography is interesting though. You could hide encrypted data in deallocated sectors and track it with a 'ghost filesystem'. It would be slow, but nearly impossible to detect.

>>19501 >it would be very obvious that there is extra encrypted data on the drive Not really. It's pretty natural for free space on a drive to look random, for example many secure erase utilities will write random data. On the topic of fs/block device level steganography, I think VeraCrypt has the capability, but I don't think it's very easily deniable. There's also something called StegFS, but if you install that, deniability of course goes out the window. By far the most interesting idea I saw was from a Black Hat talk where he created a shadow filesystem setup that, from the outside, was indistinguishable from a basic LUKS-encrypted Ubuntu install. See the presentation: https://yewtu.be/watch?v=f01t7OQjF4E . It had two components, one to create the hidden block device using the cover filesystem's free space, and another to bootstrap the loading of the system, requiring the user to manually enter certain commands during early boot to decrypt and run it. Unfortunately, while he said he planned to make the source code available, it seems he never did. Glowie influence, maybe, or plenty of other reasons. There is a similar project publically available, called Artifice, but if I understand correctly it only has the hidden block device itself, not the bootstrapping feature shown in the Black Hat talk, so you would still need to store an incriminating usb drive or something with the kernel module binary. It might be interesting anyways, see: https://github.com/atbarker/Artifice . If someone knows how to implement the full system I would love to hear it.

>>19504 And of course, I forgot to mention, but this sort of system can only work if you only ever get the drive imaged by an adversary once. If it gets imaged twice at different times, they will see that supposedly free space has changed and your deniability will disappear.

OK anons, it seems that I have not provided enough information about the use case for which I actually need this system. So let me clarify. The situation goes like this: I am being detained by the state security service. They demand that I unlock my phone and show them the contents before they let me go. And I've been using this phone to consult a resistance movement just a couple of minutes ago. However, when I do unlock my phone, all that my captors see are a "Z" wallpaper and a fake Telegram account subscribed to every government propaganda channel there is. Of course, if they get suspicious and try fishing information out of the phone's storage, they shouldn't see a different partition, but that's about it - no need to be overly paranoid like hiding stuff in the unallocated space etc. It seems like everyone has completely ignored the smartphone part of the question, which is probably much more important. Also, please do not ignore the usability factor.

>>19496 i've had similar idea before you can make hdparm trigger bad sectors at the end of the wipe procedure although the thing you could wipe is probably just the heaeder (unless it's small like a 20gb partition). maybe something more effective is better like it triggers a booby trap that sends voltage that destroys the drive or nand chip directly. the thing is they may already have a copy/image of the drive when they find you. the best encryption for you is just anonymity (no backtrace) and not being stupid. pc is a no go. if you're doing something risky, make it easily disposable as possible. >>19507 >phone that's a good idea, i've had this border problem. i still think my phone got tampered with (or looked at) when i passed the airport x-ray (usually phones and metal stuffs like belts shouldn't go with the body scanner and be handed to the tray on conveyor belt). my phone was also on the pegasus list of known devices exploited so it got me thinking. if the border is not hostile and they can't attempt to make a scene or they may discreetly attempt to tamper or look into your phones contents via usb/cellebrite, you can just destroy the usb data port and rewire it into the trrs jack of your phone (4 pins for usb) then make the usb port only work with power pins. don't forget your trrs jack to usb port, maybe don't carry that with you to not arouse suspicion. if the border is truly hostile you can probably do the software thing to prove your allegiance to the whatever. you can attempt on using multiple profiles but it is risky (create android user) and use it in combination with twrp backup and restore. I remember work profiles and multiple users make the twrp/restoration process cause boot loops after though. it maybe a problem with android user permissions with may users so I don't recommend it. I recommend just making a readily flashable twrp backups of your "fake" and "resistance" stuff, put them into a secure usb drive, luks encrypted (and more), then just restore the "fake" and "resistance" where it is most relevant. you can even use a firmware image but it's slow. if your phone has lesser storage, the better, more easier to wipe https://gitlab.com/divested-mobile/extirpater the free space and flash the stuffs. put the usb drive with encrypted "fake" and "resistance" in the usb box and mix it with other newly bought electronics, wipe the usb drive or destroy the partition table and use testdisk later to recover it, use your imagination, use giftwrap, or maybe use the cloud (only if anonymous sim or accessible internet is possible). if they're checking your phone they may as well copy your soykaf in front of you. Iirc it takes about 12-20 minutes to fully copy my phone's 16gb internal storage via twrp and it's fairly shorter if you're only copying /system and /data although it may take a while for them to figure out what they copied so at best they will be checking your telegram or something (unless they've completely uncovered you then you're fuarrrked either way) other methods for "panic wipe" https://search.f-droid.org/?q=wipe&lang=en

>>19504 >Not really. It's pretty natural for free space on a drive to look random, for example many secure erase utilities will write random data. The problem is more: why would someone leave a huge chunk of the hard drive unpartitioned and/or without a filesystem?

>>19514 >The problem is more: why would someone leave a huge chunk of the hard drive unpartitioned and/or without a filesystem? that's a great idea. i've seen plenty of phones and flash drives with fake storage. if there's a way to modify the firmware so easily, like these storage devices that report themselves as larger than they are, it would be great, you can make a 64gb flash drive report itself as 64 but its actually 32gb. the funny thing is they show up as 64gb despite only having been copied about 32gb in. like it doubles the bits?

>>19514 The systems I discussed put data in the random-looking free space of the cover filesystem. Data is spread throughout the drive and heavily error-corrected such that the host system can safely write to the drive with an extremely low chance of loss of the secret data unless its storage use goes beyond a certain threshold. >>19507 The best idea might just be to keep it off of your phone. Is it possible to boot from an SD card or something, or otherwise keep all incriminating data on external (ideally separately encrypted) storage? Then if your are afraid of being searched at a border crossing or something you can upload the data to the internet, destroy the SD, and redownload it later.

Exactly the stuff OP attached happened to one Ukraine super hacker, when captured by Russians. It is like kicking dead whales down the beach, but it also works. Ukraine IT Army 4 ever!