What an odd question. First, I'm far too lazy to go that much effort. I also suppose this is trying to evade what, a casual inspection? Or are we dodging forensic analysis? The latter is just a...
What an odd question.
First, I'm far too lazy to go that much effort. I also suppose this is trying to evade what, a casual inspection? Or are we dodging forensic analysis? The latter is just a bit harder, you'd need hidden encrypted ghost volumes for that - and even then, don't count your chickens.
For just basic hiding, though, it's pretty easy. I can even do two operating systems.
First - unixes. Have more than one hard drive or partition, get your spankbank at /opt/media/ on drive one, then mount drive two to /opt/media. Unless someone uses the unmount command, all they will see there is the content of drive two - but drive one's data is still happily sitting there, blocked from all forms of access. Literally nobody in the history of forever looks under a mount point. This probably also works on Apple and any/all linux derivatives, possibly even including android. It's just how mounting works, and has always worked.
Windows, well, we have to exploit flaws in NTFS for this one. Windows, as it turns out, doesn't do well with big things in general - like a chain of 50 nested directories, especially if you apply the 'hidden' attribute to it at every. single. level. All windows programs will simply give up and return nothing, that directory tree is like a cloaking device to all the windows programs and services - search, even explorer won't see it. Of course, you're on windows, so every time you open a file, it's being logged somewhere...
I am not very experienced with some Windows things, would NTFS alternate data streams work for hiding your files? Most programs seem to ignore them, including explorer.exe even if you configure it...
I am not very experienced with some Windows things, would NTFS alternate data streams work for hiding your files? Most programs seem to ignore them, including explorer.exe even if you configure it to display hidden files.
Is there any reading I can do about how mounts work without delving into man pages? I've done some basic stuff before, but never really felt like I understood it, and I had no idea something like...
Is there any reading I can do about how mounts work without delving into man pages? I've done some basic stuff before, but never really felt like I understood it, and I had no idea something like this was possible!
Imagine a hard drive as a room, and your filesystem as a long hallway with lots of doors that lead to no where. "mounting" is simply picking up a room, and adding it to a door that you can...
Imagine a hard drive as a room, and your filesystem as a long hallway with lots of doors that lead to no where. "mounting" is simply picking up a room, and adding it to a door that you can specify. Now you can walk through the door to get in to the room.
Now, imagine you have mounted one room, but then mount another room on to the same door. The new room will be behind the door, the other room will also still be there, but you can't get through it, as the space is occupied by the last mounted room.
Obligatory disclaimer that I don't actually know that much about these things, anyone with more knowledge please feel free to chime in.
Heh, that's not far off! If you're having trouble imagining putting a room behind a door when there's already a room there, you could also imagine it like this: Your filesystem is a large piece of...
Heh, that's not far off!
If you're having trouble imagining putting a room behind a door when there's already a room there, you could also imagine it like this: Your filesystem is a large piece of paper, divided into a square for each directory. "Mounting" another filesystem at a mount point is just like putting a sticky note over one of those squares; the stuff that was on that square is still there, but you can't see it right now, and if you read from or write to that square, you'll end up writing on the sticky note instead. If you want to unmount the filesystem, you just take the sticky note off, and then you can read and write the stuff that it was hiding.
(This also extends nicely to stuff like UnionFS, where the sticky note has transparent parts that let you see what's underneath. If you write on the transparent bits, then you're still writing on the sticky note, not on the original piece of paper, so if you take the sticky note off, your original filesystem is unmodified.)
Well, there are a lot of ways you can go about this. Depending on how intense you want to be, the strongest approach would probably be steganographically hidden encrypted content, although that...
Well, there are a lot of ways you can go about this. Depending on how intense you want to be, the strongest approach would probably be steganographically hidden encrypted content, although that would be... pretty crazy computationally.
As an example, you could encrypt it and then hide it in the low bits of uncompressed photos in your photo collection.
Replace the icon of the folder with a transparent PNG so the system doesn't render it. Name it to ". " (that has a space after the dot) so no gui manager will show it in an inspection and all it...
Replace the icon of the folder with a transparent PNG so the system doesn't render it. Name it to ". " (that has a space after the dot) so no gui manager will show it in an inspection and all it will do is print another period when ls calls it (and the space will be impossible to see so they'll try to access "." directly most likely, which doesn't work). Hide that inside an encrypted container with plausible deniability, like in truecrypt, and use full disk encryption on the rest of your hard drive, then set both a bios password and a hard drive password, all passwords unique by the way. To use your computer, you will need to know a bios password to unlock the bios, then the hdd password to unlock the hard drive for reading, then the full disk encryption password to unlock the OS, then the logon password to log into your user account, then the encrypted container's password to open it, then to know there is an invisible folder with no name or icon inside (among some junk like tax returns or a diary or something to give an excuse). All to protect a little porn that everyone thinks you have anyways...
It's encryption all the way down! and actually something I just thought of would be to pack all of the files into an encrypted zip file at the end of it. Just to have that one last password since...
It's encryption all the way down!
and actually something I just thought of would be to pack all of the files into an encrypted zip file at the end of it. Just to have that one last password since the previous 5 weren't enough... :D
Would they? All the shells I've ever used (which tbf is really just bash and tcsh) only complete until they encounter a conflict. Since . and .\ both share the ., it'll complete that, but it won't...
Would they? All the shells I've ever used (which tbf is really just bash and tcsh) only complete until they encounter a conflict. Since . and .\ both share the ., it'll complete that, but it won't add the space. if they keep pressing tab, it'll show both entries, but it won't auto insert the space.
tar cf backup.tar.gz porn && shred porn && gpg -c backup.tar.gz && shred backup.tar.gz Not the most exciting thing, but it works. I might even argue that it's overkill.
Well what I currently do is use a VeraCrypt encrypted hidden partition and a password with 130 bits of entropy (25 random characters). I don't really have a reason to go so overkill but I think...
Well what I currently do is use a VeraCrypt encrypted hidden partition and a password with 130 bits of entropy (25 random characters). I don't really have a reason to go so overkill but I think it's fun.
This LTT video is applicable to this topic My personal method currently is a VM. Easy, simple to use, not out of the way, and you could easily put it on an encrypted hard drive or something.
What an odd question.
First, I'm far too lazy to go that much effort. I also suppose this is trying to evade what, a casual inspection? Or are we dodging forensic analysis? The latter is just a bit harder, you'd need hidden encrypted ghost volumes for that - and even then, don't count your chickens.
For just basic hiding, though, it's pretty easy. I can even do two operating systems.
First - unixes. Have more than one hard drive or partition, get your spankbank at /opt/media/ on drive one, then mount drive two to /opt/media. Unless someone uses the unmount command, all they will see there is the content of drive two - but drive one's data is still happily sitting there, blocked from all forms of access. Literally nobody in the history of forever looks under a mount point. This probably also works on Apple and any/all linux derivatives, possibly even including android. It's just how mounting works, and has always worked.
Windows, well, we have to exploit flaws in NTFS for this one. Windows, as it turns out, doesn't do well with big things in general - like a chain of 50 nested directories, especially if you apply the 'hidden' attribute to it at every. single. level. All windows programs will simply give up and return nothing, that directory tree is like a cloaking device to all the windows programs and services - search, even explorer won't see it. Of course, you're on windows, so every time you open a file, it's being logged somewhere...
I am not very experienced with some Windows things, would NTFS alternate data streams work for hiding your files? Most programs seem to ignore them, including explorer.exe even if you configure it to display hidden files.
Is there any reading I can do about how mounts work without delving into man pages? I've done some basic stuff before, but never really felt like I understood it, and I had no idea something like this was possible!
Imagine a hard drive as a room, and your filesystem as a long hallway with lots of doors that lead to no where. "mounting" is simply picking up a room, and adding it to a door that you can specify. Now you can walk through the door to get in to the room.
Now, imagine you have mounted one room, but then mount another room on to the same door. The new room will be behind the door, the other room will also still be there, but you can't get through it, as the space is occupied by the last mounted room.
Obligatory disclaimer that I don't actually know that much about these things, anyone with more knowledge please feel free to chime in.
Heh, that's not far off!
If you're having trouble imagining putting a room behind a door when there's already a room there, you could also imagine it like this: Your filesystem is a large piece of paper, divided into a square for each directory. "Mounting" another filesystem at a mount point is just like putting a sticky note over one of those squares; the stuff that was on that square is still there, but you can't see it right now, and if you read from or write to that square, you'll end up writing on the sticky note instead. If you want to unmount the filesystem, you just take the sticky note off, and then you can read and write the stuff that it was hiding.
(This also extends nicely to stuff like UnionFS, where the sticky note has transparent parts that let you see what's underneath. If you write on the transparent bits, then you're still writing on the sticky note, not on the original piece of paper, so if you take the sticky note off, your original filesystem is unmodified.)
Well, there are a lot of ways you can go about this. Depending on how intense you want to be, the strongest approach would probably be steganographically hidden encrypted content, although that would be... pretty crazy computationally.
As an example, you could encrypt it and then hide it in the low bits of uncompressed photos in your photo collection.
I just had flashbacks to a CS project I had to do early on.
Replace the icon of the folder with a transparent PNG so the system doesn't render it. Name it to ". " (that has a space after the dot) so no gui manager will show it in an inspection and all it will do is print another period when ls calls it (and the space will be impossible to see so they'll try to access "." directly most likely, which doesn't work). Hide that inside an encrypted container with plausible deniability, like in truecrypt, and use full disk encryption on the rest of your hard drive, then set both a bios password and a hard drive password, all passwords unique by the way. To use your computer, you will need to know a bios password to unlock the bios, then the hdd password to unlock the hard drive for reading, then the full disk encryption password to unlock the OS, then the logon password to log into your user account, then the encrypted container's password to open it, then to know there is an invisible folder with no name or icon inside (among some junk like tax returns or a diary or something to give an excuse). All to protect a little porn that everyone thinks you have anyways...
It's encryption all the way down!
and actually something I just thought of would be to pack all of the files into an encrypted zip file at the end of it. Just to have that one last password since the previous 5 weren't enough... :D
alt+0160 I think makes it an empty name. Try searching for that!
many shell autocompletions would autocomplete to it rather than
.thoughWould they? All the shells I've ever used (which tbf is really just bash and tcsh) only complete until they encounter a conflict. Since
.and.\both share the., it'll complete that, but it won't add the space. if they keep pressing tab, it'll show both entries, but it won't auto insert the space.I should have tried others, I was expecting them to be as good as my trusted zsh to find porn but apparently not :D
My pr0nz are hidden deep in the decimal representation of π.
tar cf backup.tar.gz porn && shred porn && gpg -c backup.tar.gz && shred backup.tar.gzNot the most exciting thing, but it works. I might even argue that it's overkill.
13 mile deep vacuum tube retrieval based storage system guarded by roombas with machine guns.
The Hidden Cache folder in the appdata
Even you don't look there, thats how safe it is.
Fast
Accessible
Protected
Device
Well what I currently do is use a VeraCrypt encrypted hidden partition and a password with 130 bits of entropy (25 random characters). I don't really have a reason to go so overkill but I think it's fun.
This LTT video is applicable to this topic
My personal method currently is a VM. Easy, simple to use, not out of the way, and you could easily put it on an encrypted hard drive or something.