Nihilism
- Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
+ Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
💻 Steganography - Hiding secrets in plain sight
-
diff --git a/opsec/legal.html b/opsec/legal.html
index 4297462..46b8e9f 100644
--- a/opsec/legal.html
+++ b/opsec/legal.html
@@ -45,7 +45,7 @@
Across the entirety of the blog, in all articles that have been, and will ever be made, we ONLY advocate for the legal use of technologies - even when we are talking about Privacy-enhancing, or Anonymity-enabling, or Deniability-enabling technologies. We are NOT advocating for illegal use of the technology showcased in any article on the blog, as the goal of this blog is to remain strictly informative and educative.
-
+
Sensitive Critical Data Backup Procedure + http://blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/opsec/plausiblydeniabledataprotection/index.html +2025040601 +In this tutorial we're going to cover how to backup the critical data that you would normally store inside of your Sensitive use VM, in order to make sure that your critical data (meaning your keepass .kdbx file, your SSH keys, your PGP keys, your Monero seed files) can still be accessed and reused, even if the adversary were to seize and destroy your devices in multiple takedowns. +
+
-
Why is Metadata detrimental to Anonymity? @@ -937,6 +945,7 @@ +
-We decline any and all responsibility for any mis-use of any of the technology that we showcase throughout the blog. We also decline responsibility for any physical, digital and psychological damage caused by the mis-use of showcased technology, as the responsibility of such acts remains with the perpetrating third-party. By reading this blog, you permanently, irrevocably, and world-widely agree that the blog writers are in no way responsible for any illegal actions done by you or anyone that uses the technology showcased in blog articles. +We decline any and all responsibility for any mis-use of any of the technology that we showcase throughout the blog. We also decline any and all responsibility for any physical, digital and psychological damage caused by the mis-use of showcased technology, as the responsibility of such acts remains with the perpetrating third-party. By reading this blog, you permanently, irrevocably, and world-widely agree that the blog writers are in no way responsible for any illegal actions done by you or anyone that uses the technology showcased in blog articles.
diff --git a/opsec/plausiblydeniabledataprotection/30.png b/opsec/plausiblydeniabledataprotection/30.png new file mode 100644 index 0000000..d44ab7a Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/30.png differ diff --git a/opsec/plausiblydeniabledataprotection/31.png b/opsec/plausiblydeniabledataprotection/31.png new file mode 100644 index 0000000..14b0651 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/31.png differ diff --git a/opsec/plausiblydeniabledataprotection/32.png b/opsec/plausiblydeniabledataprotection/32.png new file mode 100644 index 0000000..3911a19 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/32.png differ diff --git a/opsec/plausiblydeniabledataprotection/33.png b/opsec/plausiblydeniabledataprotection/33.png new file mode 100644 index 0000000..aaa1ff5 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/33.png differ diff --git a/opsec/plausiblydeniabledataprotection/34.png b/opsec/plausiblydeniabledataprotection/34.png new file mode 100644 index 0000000..c5b05c3 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/34.png differ diff --git a/opsec/plausiblydeniabledataprotection/35.png b/opsec/plausiblydeniabledataprotection/35.png new file mode 100644 index 0000000..8a37ed8 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/35.png differ diff --git a/opsec/plausiblydeniabledataprotection/36.png b/opsec/plausiblydeniabledataprotection/36.png new file mode 100644 index 0000000..d1c962a Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/36.png differ diff --git a/opsec/plausiblydeniabledataprotection/37.png b/opsec/plausiblydeniabledataprotection/37.png new file mode 100644 index 0000000..2d24963 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/37.png differ diff --git a/opsec/plausiblydeniabledataprotection/38.png b/opsec/plausiblydeniabledataprotection/38.png new file mode 100644 index 0000000..68317a4 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/38.png differ diff --git a/opsec/plausiblydeniabledataprotection/39.png b/opsec/plausiblydeniabledataprotection/39.png new file mode 100644 index 0000000..3a42abd Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/39.png differ diff --git a/opsec/plausiblydeniabledataprotection/40.png b/opsec/plausiblydeniabledataprotection/40.png new file mode 100644 index 0000000..0c72170 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/40.png differ diff --git a/opsec/plausiblydeniabledataprotection/41.png b/opsec/plausiblydeniabledataprotection/41.png new file mode 100644 index 0000000..4713ea0 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/41.png differ diff --git a/opsec/plausiblydeniabledataprotection/42.png b/opsec/plausiblydeniabledataprotection/42.png new file mode 100644 index 0000000..9edef41 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/42.png differ diff --git a/opsec/plausiblydeniabledataprotection/43.png b/opsec/plausiblydeniabledataprotection/43.png new file mode 100644 index 0000000..a600164 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/43.png differ diff --git a/opsec/plausiblydeniabledataprotection/44.png b/opsec/plausiblydeniabledataprotection/44.png new file mode 100644 index 0000000..02f51f9 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/44.png differ diff --git a/opsec/plausiblydeniabledataprotection/45.png b/opsec/plausiblydeniabledataprotection/45.png new file mode 100644 index 0000000..689127e Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/45.png differ diff --git a/opsec/plausiblydeniabledataprotection/46.png b/opsec/plausiblydeniabledataprotection/46.png new file mode 100644 index 0000000..9452b0a Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/46.png differ diff --git a/opsec/plausiblydeniabledataprotection/47.png b/opsec/plausiblydeniabledataprotection/47.png new file mode 100644 index 0000000..d0e8531 Binary files /dev/null and b/opsec/plausiblydeniabledataprotection/47.png differ diff --git a/opsec/plausiblydeniabledataprotection/index.html b/opsec/plausiblydeniabledataprotection/index.html index 727d796..c485b33 100644 --- a/opsec/plausiblydeniabledataprotection/index.html +++ b/opsec/plausiblydeniabledataprotection/index.html @@ -8,7 +8,7 @@ -
Plausibly Deniable Data Backups Setup
-
-In this tutorial we're going to look at how you can backup your critical data (Keepass accesses, pgp key, ssh key, etc) while still maintaining the plausible deniability.
-DISCLAIMER: we're using only harddrives (HDDs) here, because using SSDs are not a secure way to have Plausible Deniability, that is due to hidden Volumes being detectable on devices that utilize wear-leveling -
-source: https://anonymousplanet.org/guide.html#understanding-hdd-vs-ssd
-
-regarding wear leveling:
-"Also as mentioned earlier, disabling Trim will reduce the lifetime of your SSD drive and will significantly impact its performance over time (your laptop will become slower and slower over several months of use until it becomes almost unusable, you will then have to clean the drive and re-install everything). But you must do it to prevent data leaks that could allow forensics to defeat your plausible deniability. The only way around this at the moment is to have a laptop with a classic HDD drive instead."
-
-
Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!
Sensitive Critical Data Backup Procedure
+
+In this tutorial we're going to cover how to backup the critical data that you would normally store inside of your Sensitive use VM, in order to make sure that your critical data (meaning your keepass .kdbx file, your SSH keys, your PGP keys, your Monero seed files) can still be accessed and reused, even if the adversary were to seize and destroy your devices in multiple takedowns.
+ Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!
Initial Setup
-Before starting, make sure that your Whonix VM you need to make sure the USB controller is set to USB 2:
-
-
-First install veracrypt in the plausibly deniable whonix VM (for more details on how to set that environment up in this previous tutorial), go there to download the latest .deb package:
-
-wget https://launchpad.net/veracrypt/trunk/1.26.7/+download/veracrypt-1.26.7-Debian-12-amd64.deb
-
-dpkg -i veracrypt-1.26.7-Debian-12-amd64.deb
-apt install -f
-dpkg -i veracrypt-1.26.7-Debian-12-amd64.deb
-
-Once veracrypt is setup, we're going to create a small volume with a hidden partition, which will contain all of your critical data, and the decoy partition will contain a weekly diary.
-So let's create the volume, we want to keep the size to be low so that it will contain only the critical information.
- -
-
-
-
-
-
-
-
-
-
-
-
-
-Note: It is important to make sure that the decoy partition is changed everytime the hidden partition is changed, because as it is detailed here it is not advised to backup veracrypt drives online because cloud services almost always retain history of files, meaning if you give your decoy password to all of the previous veracrypt file versions, it must justify that the entire container is different. If the entire container is different while the decoy partition is the same, it means that an adversary can prove that there is a hidden partition. Hence there needs to be a procedure as to how you backup your veracrypt volume online.
-
-Weekly procedure to backup your critical data:
--open the hidden volume of the veracrypt volume diary.vc
--backup all of your critical data (ssh config, ssh keys, pgp keys, keepass .kdbx files, etc.) (max size= 10Mb)
--close the hidden volume
--open the decoy volume of the veracrypt volume diary.vc
--recap your week in a small text file, name it with today's date. (don't reveal the presence of a hidden file in the text content)
--close the decoy volume
-
-ONLY THEN the veracrypt volume is completed, and can be backed up somewhere else:
--copy it to your mainpc, laptop, homeserver and phone
--copy it to a usb key, which is to be hidden somewhere
--hide it in plain sight using steghide inside of a very large image.
-
-Now let's take a look at how this looks like once it's applied:
- +Why is this setup important ?
+As we have covered previously, we need a specific setup in order to be able to maintain deniability regarding the sensitive activies that are conducted from inside the Sensitive VM. Due to the nature of those activities, you need to be ready for the worst, including having your main computer being seized and destroyed by the adversaries.
+
+The problem here is that if the adversary were to seize and destroy your laptop, including the non-system harddrive, you'd permanently loose your critical sensitive data (which includes your PGP key, your SSH key, your monero wallet seed phrase, and your accesses that were stored in your Keepass .KDBX file)
+
+Therefore we need a way to backup the critical data from your sensitive VM, while still maintaining deniability about what it contains if ever found by the adversary.
Backup Procedure
-First we open the hidden volume:
-
-
-Backup all of your critical data (ssh config, ssh keys, pgp keys, keepass .kdbx files, etc.) (max size= 10Mb)
-
-Then close the hidden volume:
-
-Open the decoy volume of the veracrypt volume diary.vc
-
-write something in there such as your week in a small text file, name it with today's date. (don't reveal the presence of a hidden file in the text content). This is just an example as to what content you could put there. Goal is that the content must make sense in case if you're forced to type in your password there. Second goal is that for each veracrypt hidden volume changes that occur, the content of the decoy partition must also change because otherwise it will reveal the existance of the hidden volume if the remote server keeps the previous versions of each file.
-
-Once you have closed the decoy volume, the Veracrypt volume is ready to be backed up, there you need to add the USB keys to the Whonix Workstation VM like so:
-
-And you need to copy the "diary" file to a server (wherever you want online), and then copy the file on your mainpc, your laptop and then you can also put it on a usb key to be hidden somewhere.
-
-If you want to automate the backup process, place the following backup.sh bashscript inside the whonix VM:
+What is the Critical Data backup procedure ?
+From inside the Sensitive Use Whonix Workstation VM, we'll need a small veracrypt volume (which is 10Mb big) to simultaneously store a decoy volume containing some textfiles, and to store a small hidden volume (which is 5Mb big) which will contain your critical data:
+
+This small veracrypt volume will be called "diary" and it's decoy partition will simply contain a text-based diary of yours. However we need to be careful as we're going to save that file in places that the adversary may access, We need to make sure that the decoy volume data changes, every time the hidden volume changes. This is because otherwise we wouldn't have a way to justify why the overall veracrypt volume changed while the decoy volume didn't change (which would then prove the existance of the hidden volume).
+
+Therefore, to meet the deniability requirements, we have the following backup procedure:
-[ Whonix ] [ /dev/pts/2 ] [~]
-→ cat backup.sh
+1) open the diary Veracrypt hidden volume to save the critical data in it
+2) after saving the critical data in it, close the hidden volume
+3) open the diary veracrypt decoy volume to write a new diary text file in it. (as otherwise you wouldnt be able to justify why the overall VC volume changed)
+4) close the decoy volume (ONLY NOW the overall veracrypt volume is ready to be backed up elsewhere)
+5) backup the veracrypt diary volume on a cheap remote VPS that was rented anonymously (accessed via SSH, via the .onion domain only)
+6) backup the VC volume in USB keys that are scattered in physical locations that you can access easily, and that can hide USB keys.
+
+So let's see how this looks like in action:
+ +How to perform the Backup Procedure
+First, boot the Host OS in live mode:
+
+Then open up the non-system veracrypt hidden volume:
+
+
+
+Then run script.sh (using the Super+S shortcut) to setup your sensitive whonix VMs:
+
+Before starting the Workstation however, make sure that the VM's USB controller is set to "USB 2" mode by editing the settings like so in the XML directly:
+
+[user ~]% cd /run/media/private/user/sda
+[user /run/media/private/user/sda]% vim Whonix-Workstation.xml
+[user /run/media/private/user/sda]% cat Whonix-Workstation.xml
+
+[...]
+
+<controller type="usb" index="0" model="ich9-ehci1">
+
+[...]
+
+Once done, you can create the "diary" veracrypt volume inside the sensitive VM, (we'll use it to backup our critical data into it's hidden volume):
+
+
+
+
+Now that the diary veracrypt volume has been created we can start to use it to backup our important data into it:
+How to perform the Backup Procedure
+First, plug in your 3 usb keys into your computer and then make sure that they are attached to the Whonix Workstation VM:
+
+
+
+Then once you verified that the USB sticks are detected from the VM, you can start to backup your critical data inside the veracrypt volumes:
+
+And then after backing up your critical data, you can unmount the hidden volume, to mount the decoy volume instead, where you'll write a diary entry (that way you'll be able to justify why the overall veracrypt volume changed):
+
+Now that's done, unmount the decoy volume, and use the following backup.sh script to backup your diary veracrypt volume to the 3 usb sticks:
+
+[user ~]% vim backup.sh
+[user ~]% cat backup.sh
#!/bin/bash
-#QEMU setting:
-#whonix workstation configuration > Controller USB 0 > USB 2
-# add each USB as host usb passthrough
-
-#mount all 3 usb sticks:
+echo 'creating all 3 usb mount directories...'
sudo mkdir /mnt/usb1
sudo mkdir /mnt/usb2
sudo mkdir /mnt/usb3
+echo 'mounting all 3 usb sticks...'
sudo mount /dev/sda1 /mnt/usb1
sudo mount /dev/sdb1 /mnt/usb2
sudo mount /dev/sdc1 /mnt/usb3
-#mount the veracrypt volume to add new diary:
-echo "[+] Mount DECOY volume, to add new diary:"
-veracrypt --mount /home/user/diary
-vim /media/veracrypt1/$(date --iso-8601).txt
-echo '[+] DIARY COMPLETE:'
-ls -lash /media/veracrypt1
-
-#mount the veracrypt volume to add new diary:
-echo "Mount remounting volume, to backup critical data:"
-veracrypt --dismount /home/user/diary
-veracrypt --mount /home/user/diary
-
-#backup whats critical in the veracrypt volume:
-cp -r /home/user/.gnupg /media/veracrypt1/
-cp -r /home/user/.ssh /media/veracrypt1/
-cp -r /home/user/backup.sh /media/veracrypt1/
-cp -r /home/user/Passwords.kdbx /media/veracrypt1/
-
-ls -lash /media/veracrypt1
-echo '[+] CRITICAL DATA ADDED TO VERACRYPT, BACKING IT UP TO USB STICKS:'
-veracrypt --dismount /home/user/diary
-
+echo 'copying the diary file on all 3 usb sticks...'
sudo cp -r /home/user/diary /mnt/usb1/diary
sudo cp -r /home/user/diary /mnt/usb2/diary
+sudo cp -r /home/user/diary /mnt/usb3/diary
-ls -lash /mnt/usb*
-
-echo '[+] CRITICAL DATA BACKUP ON the 3 USB STICKS COMPLETE, UNMOUNTING...'
+echo 'copying completed, hence unmounting all 3 usb sticks...'
sudo umount /mnt/usb1
sudo umount /mnt/usb2
-#sudo umount /mnt/usb3
+sudo umount /mnt/usb3
-echo '[+] REMOTE BACKUP'
-rsync /home/user/diary remoteserver:/root/diary -razP
+echo 'remote backup to a VPS rented anonymously...'
+torsocks scp /home/user/diary user@yourremotevpsaddress.onion:/root/diary:
-echo '[+] REMOVING LOGS'
-echo '' > ~/.histfile
-sudo rm /var/log/*.log /var/log/*/*.log
-sudo dmesg -c
-
-echo '[+] SENSITIVE BACKUP COMPLETED, NOW HIDE ALL 3 IN HIDDEN LOCATIONS, UNMOUNTING...'
+[user ~]% chmod +x backup.sh
+[user ~]% ./backup.sh
For instance, you can backup your critical files in places that you own (your apartment, your car, on your keyring), but these places can be found easily. If you want to actually hide (and be able to claim that there are no more copies of your USB keys), get the USB keys in places totally unrelated to you, get creative such as burying the usb key somewhere you can remember, far away from your home, or hiding the file in a remote server, in a location that you remember.
-Like so you're covered in case if you are forced to give away your password, and in case if an adversary takes your harddrives, USB keys (minus the ones you managed to hide elsewhere), and if the adversary fills the decoy partitions of your veracrypt volumes in an attempt to destroy the hidden partitions, even in that case, you can still recover your data from the remaining places you successfully managed to hide your data to.
-Get creative as to how you choose to hide the veracrypt volume aswell, such as replacing a random linux binary in the /bin/ folder, or a library in /lib, or a file in /etc/, burying the usb key somewhere underground, etc
+Run the script, and you'll now have your critical data backed up on your Remote VPS, and it's on the 3 usb keys.
+And now you can unplug the 3 usb keys, and scatter them in 3 different places that you can easily access. You can hide them in your bag, in your car, and bury one in your garden for example. Get creative, but make sure that you can easily retrieve those usb keys back for next week's backup.
+
+
+
+However be careful if you intend to hide those usb keys in that are not yours (where you normally never go to either), you need to make sure that you are going there without a cellphone on you. As otherwise the adversary would see that your phone has gone to a novel place that you have never been to before, And that gives them hints regarding where you might've hidden the usb keys.
+
+Here for instance, the adversary wouldn't see your movements in pink, the only clues they'd have are the movements in red that they can anyway see from their dashboards.
+Emergency Scenario
+So now let's suppose the following emergency scenario: You made an opsec mistake somewhere along the way, and the chinese authorities are now aware that you've been playing video games after 7 PM, and they are now raiding your appartment again:
+
+You manage to hit the correct key combination (right Alt to focus out of the VM, and right CTRL to trigger the emergency reboot script) Which closes the sensitive VM and reboots your computer just in time.
+
+Then they seize your devices, keep you in custody for just 1 month, and due to not having any further incriminating evidence on you, you avoid the concentration camp life sentence, and thus they release you. But they're not giving back your devices because they destroyed them.
+ +
+So your primary data source has been destroyed (including the sensitive VMs and the main diary VC volume), you also realize that they seized and destroyed the usb key you had in your backpack, and in your car. However upon checking further you realize that they didn't get the USB key that you hid in your garden.
+
+Too bad for them, because they didn't find that one usb key you had buried in your garden, so you dig it up, retrieve it, you purchase a new laptop, you set up your sensitive VMs once again, and then you simply plug the usb back in the sensitive VM, and with it you can restore your critical sensitive data (which includes your Keepass accesses, your pgp keys, your ssh keys and monero wallet seed) by copying the files back into your new sensitive use VM.
+And once restored you can resume your sensitive activities as usual, minus the opsec mistakes you made that led up to your arrest obviously.
Plausibly Deniable Data Backups Setup
+
+In this tutorial we're going to look at how you can backup your critical data (Keepass accesses, pgp key, ssh key, etc) while still maintaining the plausible deniability.
+DISCLAIMER: we're using only harddrives (HDDs) here, because using SSDs are not a secure way to have Plausible Deniability, that is due to hidden Volumes being detectable on devices that utilize wear-leveling +
+source: https://anonymousplanet.org/guide.html#understanding-hdd-vs-ssd
+
+regarding wear leveling:
+"Also as mentioned earlier, disabling Trim will reduce the lifetime of your SSD drive and will significantly impact its performance over time (your laptop will become slower and slower over several months of use until it becomes almost unusable, you will then have to clean the drive and re-install everything). But you must do it to prevent data leaks that could allow forensics to defeat your plausible deniability. The only way around this at the moment is to have a laptop with a classic HDD drive instead."
+
+ Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!
Initial Setup
+Before starting, make sure that your Whonix VM you need to make sure the USB controller is set to USB 2:
+
+
+First install veracrypt in the plausibly deniable whonix VM (for more details on how to set that environment up in this previous tutorial), go there to download the latest .deb package:
+
+wget https://launchpad.net/veracrypt/trunk/1.26.7/+download/veracrypt-1.26.7-Debian-12-amd64.deb
+
+dpkg -i veracrypt-1.26.7-Debian-12-amd64.deb
+apt install -f
+dpkg -i veracrypt-1.26.7-Debian-12-amd64.deb
+
+Once veracrypt is setup, we're going to create a small volume with a hidden partition, which will contain all of your critical data, and the decoy partition will contain a weekly diary.
+So let's create the volume, we want to keep the size to be low so that it will contain only the critical information.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+Note: It is important to make sure that the decoy partition is changed everytime the hidden partition is changed, because as it is detailed here it is not advised to backup veracrypt drives online because cloud services almost always retain history of files, meaning if you give your decoy password to all of the previous veracrypt file versions, it must justify that the entire container is different. If the entire container is different while the decoy partition is the same, it means that an adversary can prove that there is a hidden partition. Hence there needs to be a procedure as to how you backup your veracrypt volume online.
+
+Weekly procedure to backup your critical data:
+-open the hidden volume of the veracrypt volume diary.vc
+-backup all of your critical data (ssh config, ssh keys, pgp keys, keepass .kdbx files, etc.) (max size= 10Mb)
+-close the hidden volume
+-open the decoy volume of the veracrypt volume diary.vc
+-recap your week in a small text file, name it with today's date. (don't reveal the presence of a hidden file in the text content)
+-close the decoy volume
+
+ONLY THEN the veracrypt volume is completed, and can be backed up somewhere else:
+-copy it to your mainpc, laptop, homeserver and phone
+-copy it to a usb key, which is to be hidden somewhere
+-hide it in plain sight using steghide inside of a very large image.
+
+Now let's take a look at how this looks like once it's applied:
+ + +Backup Procedure
+First we open the hidden volume:
+
+
+Backup all of your critical data (ssh config, ssh keys, pgp keys, keepass .kdbx files, etc.) (max size= 10Mb)
+
+Then close the hidden volume:
+
+Open the decoy volume of the veracrypt volume diary.vc
+
+write something in there such as your week in a small text file, name it with today's date. (don't reveal the presence of a hidden file in the text content). This is just an example as to what content you could put there. Goal is that the content must make sense in case if you're forced to type in your password there. Second goal is that for each veracrypt hidden volume changes that occur, the content of the decoy partition must also change because otherwise it will reveal the existance of the hidden volume if the remote server keeps the previous versions of each file.
+
+Once you have closed the decoy volume, the Veracrypt volume is ready to be backed up, there you need to add the USB keys to the Whonix Workstation VM like so:
+
+And you need to copy the "diary" file to a server (wherever you want online), and then copy the file on your mainpc, your laptop and then you can also put it on a usb key to be hidden somewhere.
+
+If you want to automate the backup process, place the following backup.sh bashscript inside the whonix VM:
+
+[ Whonix ] [ /dev/pts/2 ] [~]
+→ cat backup.sh
+
+#!/bin/bash
+
+#QEMU setting:
+#whonix workstation configuration > Controller USB 0 > USB 2
+# add each USB as host usb passthrough
+
+#mount all 3 usb sticks:
+sudo mkdir /mnt/usb1
+sudo mkdir /mnt/usb2
+sudo mkdir /mnt/usb3
+
+sudo mount /dev/sda1 /mnt/usb1
+sudo mount /dev/sdb1 /mnt/usb2
+sudo mount /dev/sdc1 /mnt/usb3
+
+#mount the veracrypt volume to add new diary:
+echo "[+] Mount DECOY volume, to add new diary:"
+veracrypt --mount /home/user/diary
+vim /media/veracrypt1/$(date --iso-8601).txt
+echo '[+] DIARY COMPLETE:'
+ls -lash /media/veracrypt1
+
+#mount the veracrypt volume to add new diary:
+echo "Mount remounting volume, to backup critical data:"
+veracrypt --dismount /home/user/diary
+veracrypt --mount /home/user/diary
+
+#backup whats critical in the veracrypt volume:
+cp -r /home/user/.gnupg /media/veracrypt1/
+cp -r /home/user/.ssh /media/veracrypt1/
+cp -r /home/user/backup.sh /media/veracrypt1/
+cp -r /home/user/Passwords.kdbx /media/veracrypt1/
+
+ls -lash /media/veracrypt1
+echo '[+] CRITICAL DATA ADDED TO VERACRYPT, BACKING IT UP TO USB STICKS:'
+veracrypt --dismount /home/user/diary
+
+sudo cp -r /home/user/diary /mnt/usb1/diary
+sudo cp -r /home/user/diary /mnt/usb2/diary
+
+ls -lash /mnt/usb*
+
+echo '[+] CRITICAL DATA BACKUP ON the 3 USB STICKS COMPLETE, UNMOUNTING...'
+sudo umount /mnt/usb1
+sudo umount /mnt/usb2
+#sudo umount /mnt/usb3
+
+echo '[+] REMOTE BACKUP'
+rsync /home/user/diary remoteserver:/root/diary -razP
+
+echo '[+] REMOVING LOGS'
+echo '' > ~/.histfile
+sudo rm /var/log/*.log /var/log/*/*.log
+sudo dmesg -c
+
+echo '[+] SENSITIVE BACKUP COMPLETED, NOW HIDE ALL 3 IN HIDDEN LOCATIONS, UNMOUNTING...'
+
+For instance, you can backup your critical files in places that you own (your apartment, your car, on your keyring), but these places can be found easily. If you want to actually hide (and be able to claim that there are no more copies of your USB keys), get the USB keys in places totally unrelated to you, get creative such as burying the usb key somewhere you can remember, far away from your home, or hiding the file in a remote server, in a location that you remember.
+Like so you're covered in case if you are forced to give away your password, and in case if an adversary takes your harddrives, USB keys (minus the ones you managed to hide elsewhere), and if the adversary fills the decoy partitions of your veracrypt volumes in an attempt to destroy the hidden partitions, even in that case, you can still recover your data from the remaining places you successfully managed to hide your data to.
+Get creative as to how you choose to hide the veracrypt volume aswell, such as replacing a random linux binary in the /bin/ folder, or a library in /lib, or a file in /etc/, burying the usb key somewhere underground, etc
+ +My Links
+
+
+ RSS Feed
SimpleX Chatrooms
+
+
About nihilist
+Donate XMR: 8AUYjhQeG3D5aodJDtqG499N5jXXM71gYKD8LgSsFB9BUV1o7muLv3DXHoydRTK4SZaaUBq4EAUqpZHLrX2VZLH71Jrd9k8
+
Sensitive use VMs Setup (Whonix VMs in a Veracrypt Hidden Volume) (April 2025 Update)
+Sensitive VMs Setup (Whonix VMs in a Veracrypt Hidden Volume) (April 2025 Update)
In this tutorial we're going to cover how to setup Whonix VMs for Sensitive use. This means that our OPSEC requirement is that we need to be able to deny the existance of the Sensitive Whonix VM if the adversary ever gets access to our laptop.
Now the advantage of this setup, is that it is not going to actually destroy the computer, nor any sensitive data, you can keep using it even after triggering an emergency shutdown.
@@ -106,7 +106,7 @@I also recommend making a simple shortcut to trigger the script.sh bashscript to avoid having to open up a terminal and run it every time you want to open up the sensitive VMs after booting in live mode:
-[user ~]% xfconf-query -c xfce4-keyboard-shortcuts -n -t 'string' -p '/commands/custom/s' -s /run/media/private/user/sda/script.sh
+[user ~]% xfconf-query -c xfce4-keyboard-shortcuts -n -t 'string' -p '/commands/custom/<Super>s' -s /run/media/private/user/sda/script.sh
In this example, i set the Super+S shortcut to run script.sh more easily.
diff --git a/rss/feed.xml b/rss/feed.xml index a0c3fdc..96d3718 100644 --- a/rss/feed.xml +++ b/rss/feed.xml @@ -1,13 +1,21 @@