new sensitive vm tutorial

This commit is contained in:
nihilist 2025-04-02 21:03:24 +02:00
parent 187e4b27f8
commit 20e60ff5c9
27 changed files with 1380 additions and 557 deletions

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View file

@ -61,7 +61,7 @@
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/user.png" width="50px" height="50px"> <ba>nihilist - 01 / 04 / 2025</ba></p>
<h1>Using the Host-OS in live-mode to enable Sensitive Use (April 2024 Update) </h1>
<h1>Using the Host-OS in live-mode to enable Sensitive Use (April 2025 Update) </h1>
<img src="0.png" class="imgRz">
<p>In this tutorial we're going to cover how to use livemode and ram-wipe from inside Kicksecure to enable long-term Sensitive use.</p>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 161 KiB

After

Width:  |  Height:  |  Size: 413 KiB

Before After
Before After

BIN
opsec/sensitivevm/100.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 263 KiB

BIN
opsec/sensitivevm/101.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

BIN
opsec/sensitivevm/102.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 311 KiB

BIN
opsec/sensitivevm/103.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 175 KiB

BIN
opsec/sensitivevm/104.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 285 KiB

BIN
opsec/sensitivevm/105.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 185 KiB

BIN
opsec/sensitivevm/106.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 364 KiB

BIN
opsec/sensitivevm/107.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 138 KiB

BIN
opsec/sensitivevm/108.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 118 KiB

BIN
opsec/sensitivevm/109.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 282 KiB

BIN
opsec/sensitivevm/110.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 264 KiB

BIN
opsec/sensitivevm/111.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 219 KiB

BIN
opsec/sensitivevm/112.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 362 KiB

BIN
opsec/sensitivevm/113.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 329 KiB

BIN
opsec/sensitivevm/114.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 336 KiB

BIN
opsec/sensitivevm/115.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 833 KiB

BIN
opsec/sensitivevm/116.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 182 KiB

BIN
opsec/sensitivevm/117.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 483 KiB

BIN
opsec/sensitivevm/118.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 204 KiB

BIN
opsec/sensitivevm/119.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 458 KiB

BIN
opsec/sensitivevm/120.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 546 KiB

View file

@ -61,20 +61,11 @@
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/user.png" width="50px" height="50px"> <ba>nihilist@mainpc - 2024-10-29</ba></p>
<h1>Sensitive use VMs Setup (Whonix VMs in a Veracrypt Hidden Volume) </h1>
<h1>Sensitive use VMs Setup (Whonix VMs in a Veracrypt Hidden Volume) (April 2025 Update) </h1>
<img src="0.png" class="imgRz">
<p>In this tutorial we're going to cover how to setup Whonix VMs for Sensitive use. This means that our <a href="../opsec4levels/index.html">OPSEC requirement</a> is that <b>we need to be able to deny the existance of the Sensitive Whonix VM if the adversary ever gets access to our laptop.</b> </p>
<p>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. </p>
<p><u>CONTEXT WARNING:</u> this setup is only suitable <b>if you are not going to be thrown in jail for just using Veracrypt.</b>, and if an adversary were to bust down your front door, <b>you need to have at least 5 seconds before he can see your laptop screen.</b></p>
<p><h2><u>OPSEC Recommendations:</u></h2></p>
<ol>
<li><p>Hardware : (Personal Computer / Laptop)</p></li>
<li><p>Host OS: <a href="../linux/index.html">Linux</a>, but in <a href="../livemode/index.html">live mode</a></p></li>
<li><p>Hypervisor: <a href="../hypervisorsetup/index.html">libvirtd QEMU/KVM</a></p></li>
<li><p>Harddrive (HDD): 500GB and encrypted with <a href="../veracrypt/index.html">Veracrypt (with a 250Gb Hidden Volume)</a></p></li>
<li><p>Virtual Machine:<a href="../whonixqemuvms/index.html">Whonix</a></p></li>
</ol>
<p><img src="../logos/daturagit.png" style="width:100px"> <u>Sidenote:</u> Help us improve this tutorial by letting us know if there's anything missing or incorrect on this <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/256">git issue</a> directly!</p>
</div>
</div><!-- /row -->
@ -90,7 +81,7 @@
<p>First of all as you have seen, the requirement is that we do this setup from the Host OS, in <a href="../livemode/index.html">live mode</a>. That is because we want to make sure that there is no forensic evidence to be saved on the system drive as we have explained <a href="../livemode/index.html">previously.</a> </p>
<img src="../livemode/4.png" class="imgRz">
<p>While in Live mode we can't write anything new on the system disk (such as the system logs, kernel logs, non-standard logs) <b>which can all be potential forensic evidence that the hidden volume exists</b>. Instead, everything is written into RAM, and we can easily erase all of those contents with a simple reboot. While in live mode however, we can write to non-system drives, which is where we will setup a big enough veracrypt volume to store the Whonix VMs that we will use for long-term sensitive use.</p>
<p>While in Live mode we can't write anything new on the system disk (such as the system logs, kernel logs, non-standard logs) <b>which can all be potential forensic evidence that the hidden volume exists</b>. Instead, everything is written into RAM, and we can easily erase all of those contents with a simple reboot. <b>While in live mode however, we can ONLY write to non-system drives</b>, which is where we will setup a big enough veracrypt volume (500GB in total, with a 250Gb hidden volume) to store the Whonix VMs (which are 200Gb big) that we will use for long-term Sensitive use.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
@ -101,175 +92,175 @@
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>How to setup the VMs inside the Hidden Volume</b></h2> </br> </br>
<p>So before we start, make sure you reboot the Host OS to go into live mode</p>
<img src="../deniability/7.png" class="imgRz">
<p> <b>or boot from a usb stick that has a debian live image if you are in the usecase where the adversary can't be told you are using kicksecure packages</b>:</p>
<img src="../livemode/9.png" class="imgRz">
<p>Then, once in live mode <b>if you are in the usecase where you cannot reveal to the adversary that there is veracrypt installed on the host OS, make sure you install it everytime you boot into live mode.</b> To do speed up the installation process we're going to use the VPS we showcased <a href="../veracrypt/index.html">previously</a> to install both veracrypt and the emergency shutdown script:</p>
<h2><b>Preparing the Host OS: Live Mode and the Reboot Shortcut</b></h2> </br> </br>
<p>As we have showcased <a href="../livemode/index.html">previously</a>, we have a <b>reboot.sh bashscript</b> on the Host OS, that is hooked up to the <b>Right Ctrl</b> key to make sure we can quickly shutdown the computer in case if an adversary were to bust down our door. So we're going to make use of it:</p>
<pre><code class="nim">
nothing@debian:~$ scp root@65.109.30.253:/root/sensitive_scripts/vc.deb .
root@65.109.30.253's password:
vc.deb 100% 8995KB 1.9MB/s 00:04
[user ~]% cat reboot.sh
#!/bin/bash
nothing@debian:~$ sudo dpkg -i vc.deb
/usr/bin/sudo /usr/sbin/reboot now
nothing@debian:~$ sudo apt install -f
nothing@debian:~$ sudo dpkg -i vc.deb
nothing@debian:~$ which veracrypt
/usr/bin/veracrypt
nothing@debian:~$ scp root@65.109.30.253:/root/sensitive_scripts/shutdown.sh .
nothing@debian:~$ chmod +x shutdown.sh
nothing@debian:~$ veracrypt
[user ~]% xfconf-query -c xfce4-keyboard-shortcuts -n -t 'string' -p '/commands/custom/Control_R' -s /home/user/reboot.sh
</pre></code>
<p>We briefly make sure that the shutdown.sh script is hooked up to the <b>SUPER+R</b> key to make sure we can quickly shutdown the computer in case if an adversary were to bust down our door:</p>
<img src="../livemode/5.png" class="imgRz">
<img src="../livemode/6.png" class="imgRz">
<p>Definitely make sure that it works and that it keeps working by pressing the right ctrl key at least once in a while, <b>because you definitely don't want this to fail you when there's going to be an actual emergency.</b> </p>
<p>And now that we did the post-live-boot initial setup, we can start to setup our veracrypt volumes on our 500Gb harddrive:</p>
<img src="2.png" class="imgRz">
<img src="3.png" class="imgRz">
<p>Here we're using a non-system drive, as we want to be able to store our veracrypt hidden volume contents in a persistent manner, accross reboots. (if we were to have the veracrypt volume on the system drive, it would be wiped off upon rebooting since the Host OS is in live mode.)</p>
<img src="4.png" class="imgRz">
<img src="5.png" class="imgRz">
<img src="6.png" class="imgRz">
<img src="7.png" class="imgRz">
<img src="8.png" class="imgRz">
<img src="9.png" class="imgRz">
<img src="10.png" class="imgRz">
<img src="11.png" class="imgRz">
<p>And in our veracrypt outer (decoy) volume, we're going to setup the veracrypt inner (hidden) volume, and set it to be 250Gb big:</p>
<img src="12.png" class="imgRz">
<img src="13.png" class="imgRz">
<img src="14.png" class="imgRz">
<img src="15.png" class="imgRz">
<img src="16.png" class="imgRz">
<img src="17.png" class="imgRz">
<img src="18.png" class="imgRz">
<img src="19.png" class="imgRz">
<img src="20.png" class="imgRz">
<p>Now that the vercarypt volume has been setup, to highlight the mechanism, for the same harddrive, you have 2 passwords. Password A opens up the decoy volume, and Password B (which must remains secret, only to be known by you) opens up the hidden volume:</p>
<img src="21.png" class="imgRz">
<img src="22.png" class="imgRz">
<img src="23.png" class="imgRz">
<p>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:</p>
<pre><code class="nim">
[user ~]% xfconf-query -c xfce4-keyboard-shortcuts -n -t 'string' -p '/commands/custom/<Super>s' -s /run/media/private/user/sda/script.sh
</div>
</pre></code>
<p>In this example, i set the <b>Super+S</b> shortcut to run script.sh more easily.</p>
<p>And lastly, (since running right ctrl while focused inside of a VM doesnt trigger the shortcut on the Host OS), we make sure that we can focus out of the QEMU VMs easily by making sure that pressing the <b>Right ALT</b> focuses out of the VMs:</p>
<pre><code class="nim">
[user ~]% gsettings set org.virt-manager.virt-manager.console grab-keys '65514'
</pre></code>
<p><b>In conclusion: The correct key combination to reboot the computer is first Right Alt to focus out of the QEMU VM, and then Right CTRL to trigger the reboot script.</b></p>
<p>So Now that's done, let's reboot the Host OS to go back in live mode before we start to create the veracrypt volume.</p>
<img src="../livemode/12.png" class="imgRz">
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
</div><!-- /grey -->
<div id="anon3">
<!-- +++++ Second Post +++++ -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Setting up the Hidden Volume</b></h2> </br> </br>
<p>So now let's setup the hidden volume, where we will put the Sensitive Whonix QEMU VMs:</p>
<img src="24.png" class="imgRz">
<p>Then, we're going to download the Whonix VMs and configure them to be used from inside the hidden veracrypt volume: </p>
<img src="25.png" class="imgRz">
<h2><b>Preparing the non-system drive</b></h2> </br> </br>
<p>This tutorial is going to require you to have the following setup:</p>
<ul>
<li><p>Host OS: <a href="../linux/index.html">Kicksecure</a> (in live mode ONLY!)</p></li>
<li><p>Host OS Preparation: <a href="../livemode/index.html">Reboot.sh script hooked up to the right CTRL key + ram-wipe installed</a></p></li>
<li><p>Hypervisor: <a href="../hypervisorsetup/index.html">libvirtd QEMU/KVM</a></p></li>
<li><p>Non-System Harddrive: 500Gb at least</p></li>
</ul>
<img src="100.png" class="imgRz">
<p>With this setup, you are ready to proceed. The non-system harddrive needs to be 500GB big because in it the veracrypt decoy (outer) volume will span the entire drive (500Gb), and the hidden (inner) volume will span half of that entire drive (250Gb), <b>in order to be able to contain the Whonix QEMU VMs which are 200Gb big.</b></p>
<img src="101.png" class="imgRz">
<p>So make <b>sure that you have a non-system that is 500GB big (a Harddrive, NOT AN SSD)</b>, then you can proceed with setting up the veracrypt volume on the entire drive: </p>
<img src="102.png" class="imgRz">
<img src="103.png" class="imgRz">
<img src="104.png" class="imgRz">
<img src="105.png" class="imgRz">
<p>Here is the important part: you mention both passwords: the top one is Password A: to unlock the decoy volume, and the bottom one is the secret password, you must be the only one that knows it <b>because it is the key to unlock (and reveal) the hidden volume NEVER WRITE IT DOWN, ALWAYS REMEMBER IT!</b></p>
<img src="106.png" class="imgRz">
<img src="107.png" class="imgRz">
<img src="108.png" class="imgRz">
<img src="108.png" class="imgRz">
<p>And now that the veracrypt volume is created, we are ready to setup both the hidden and decoy volumes</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Installing the Whonix VMs inside the Hidden Volume</b></h2> </br> </br>
<p>First we unlock the Veracrypt Hidden volume:</p>
<img src="109.png" class="imgRz">
<img src="110.png" class="imgRz">
<img src="111.png" class="imgRz">
<p>As you can see the mount point path is in <b>/run/media/private/user/sda</b>, that's where we're going to store the whonix VMs. So let's download the latest whonix VMs from <a href="https://www.whonix.org/wiki/KVM">here</a>:</p>
<img src="112.png" class="imgRz">
<p>once downloaded directly into the hidden volume, unpack it (the archive may only be 3Gb big but once inflated it will weigh 200Gb in total.) </p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/23 ] [VAULT/ISOs/whonix]
→ mv ~/Downloads/Whonix-Xfce-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz /mnt/veracrypt1/
[user ~]% cd /run/media/private/user/sda
[ nowhere ] [ /dev/pts/23 ] []
→ tar -xvf Whonix-Xfce-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz
[user /run/media/private/user/sda]% ls -l
total 549M
drwx------ 2 root root 16K 1 sept. 2024 lost+found
drwxr-xr-x 2 user user 4,0K 2 avril 11:45 old
-rw-r--r-- 1 user user 0 2 avril 11:47 Whonix-Xfce-17.2.8.5.Intel_AMD64.qcow2.libvirt.xz
[user /run/media/private/user/sda]% tar -xvf Whonix*.libvirt.xz
WHONIX_BINARY_LICENSE_AGREEMENT
WHONIX_DISCLAIMER
Whonix-Gateway-Xfce-17.2.3.7.xml
Whonix-Workstation-Xfce-17.2.3.7.xml
Whonix_external_network-17.2.3.7.xml
Whonix_internal_network-17.2.3.7.xml
Whonix-Gateway-Xfce-17.2.3.7.Intel_AMD64.qcow2
Whonix-Workstation-Xfce-17.2.3.7.Intel_AMD64.qcow2
Whonix-Gateway-Xfce-17.2.8.5.xml
Whonix-Workstation-Xfce-17.2.8.5.xml
Whonix_external_network-17.2.8.5.xml
Whonix_internal_network-17.2.8.5.xml
Whonix-Gateway-Xfce-17.2.8.5.Intel_AMD64.qcow2
Whonix-Workstation-Xfce-17.2.8.5.Intel_AMD64.qcow2
[ nowhere ] [ /dev/pts/23 ] [VAULT/ISOs/whonix]
→ touch WHONIX_BINARY_LICENSE_AGREEMENT_accepted
[user /run/media/private/user/sda]% touch WHONIX_BINARY_LICENSE_AGREEMENT_accepted
</pre></code>
<p>Here to make it easier to handle, i recommend to first edit the file names to remove the version and the the window manager name:</p>
<pre><code class="nim">
[user /run/media/private/user/sda]% mv Whonix-Gateway-Xfce-17.2.8.5.xml Whonix-Gateway.xml
[user /run/media/private/user/sda]% mv Whonix-Workstation-Xfce-17.2.8.5.xml Whonix-Workstation.xml
[user /run/media/private/user/sda]% mv Whonix_external_network-17.2.8.5.xml Whonix-External.xml
[user /run/media/private/user/sda]% mv Whonix_internal_network-17.2.8.5.xml Whonix-Internal.xml
[user /run/media/private/user/sda]% mv Whonix-Gateway-Xfce-17.2.8.5.Intel_AMD64.qcow2 Whonix-Gateway.qcow2
[user /run/media/private/user/sda]% mv Whonix-Workstation-Xfce-17.2.8.5.Intel_AMD64.qcow2 Whonix-Workstation.qcow2
</pre></code>
<p>next, we simplify the files names:</p>
<p>Then we're going to need to edit the Whonix-Gateway.xml and Whonix-Workstation.xml to match the system path, have the correct resources, and use the correct qcow2 image filenames:</p>
<p>So here we first make sure that the whonix gateway has 1GB memory, and that it has the correct source file path (to the .qcow2 vm image):</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Gateway-Xfce-17.2.3.7.xml Whonix-Gateway.xml
[user /run/media/private/user/sda]% vim Whonix-Gateway.xml
[user /run/media/private/user/sda]% cat Whonix-Gateway.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Gateway-Xfce-17.2.3.7.Intel_AMD64.qcow2 Whonix-Gateway.qcow2
[...]
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Workstation-Xfce-17.2.3.7.xml Whonix-Workstation.xml
<<i></i>memory dumpCore="off" unit="GiB">1<<i></i>/memory>
<<i></i>currentMemory unit="GiB">1<<i></i>/currentMemory>
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Workstation-Xfce-17.2.3.7.Intel_AMD64.qcow2 Whonix-Workstation.qcow2
[...]
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix_external_network-17.2.3.7.xml Whonix-external.xml
<<i></i>disk type="file" device="disk">
<<i></i>driver name="qemu" type="qcow2"/>
<<i></i>source file="/run/media/private/user/sda/Whonix-Gateway.qcow2"/>
<<i></i>target dev="vda" bus="virtio"/>
<<i></i>address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/>
<<i></i>/disk>
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix_internal_network-17.2.3.7.xml Whonix-internal.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ls -l
total 209745392
drwx------ 2 root root 16384 Sep 1 21:24 lost+found
-rwxrwx--x 1 nihilist libvirt 1202 Jan 2 2024 refreshvms.sh
-rwxrwx--- 1 nihilist libvirt 39649 Oct 21 2015 WHONIX_BINARY_LICENSE_AGREEMENT
-rwxrwx--- 1 nihilist libvirt 4185 Oct 21 2015 WHONIX_DISCLAIMER
-rwxrwx--- 1 nihilist libvirt 172 Oct 21 2015 Whonix_external_network-17.2.3.7.xml
-rwxrwx--- 1 nihilist libvirt 107389386752 Nov 1 14:13 Whonix-Gateway.qcow2
-rwxrwx--- 1 nihilist libvirt 3577 Sep 1 22:31 Whonix-Gateway.xml
-rwxrwx--- 1 nihilist libvirt 97 Oct 21 2015 Whonix_internal_network-17.2.3.7.xml
-rwxrwx--- 1 nihilist libvirt 107389386752 Nov 1 14:13 Whonix-Workstation.qcow2
-rwxrwx--- 1 nihilist libvirt 3466 Sep 1 22:30 Whonix-Workstation.xml
[...]
</pre></code>
<p>And then we edit the .xml file of the gateway VM to give it 1GB of RAM and mentionning the correct .qcow2 path:</p>
<p>So here we do the same for the whonix workstation to give it 8GB of memory, with 4vcpus, and we also make sure that it has the correct source file path (to the .qcow2 vm image):</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim Whonix-Gateway.xml
[user /run/media/private/user/sda]% vim Whonix-Workstation.xml
[user /run/media/private/user/sda]% cat Whonix-Workstation.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Gateway.xml | grep emory
<<b></b>memory dumpCore="off" unit="GiB">1<<b></b>/memory>
<<b></b>currentMemory unit="GiB">1<<b></b>/currentMemory>
[...]
<<i></i>memory dumpCore="off" unit="GiB">8<<i></i>/memory>
<<i></i>currentMemory unit="GiB">8<<i></i>/currentMemory>
[...]
<<i></i>vcpu placement="static" cpuset="1">4<<i></i>/vcpu>
[...]
<<i></i>disk type="file" device="disk">
<<i></i>driver name="qemu" type="qcow2"/>
<<i></i>source file="/run/media/private/user/sda/Whonix-Gateway.qcow2"/>
<<i></i>target dev="vda" bus="virtio"/>
<<i></i>address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/>
<<i></i>/disk>
[...]
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Gateway.xml | grep qcow2
<<b></b>driver name="qemu" type="qcow2"/>
<<b></b>source file="/mnt/veracrypt1/Whonix-Gateway.qcow2"/>
</pre></code>
<p>And then we do the same for the .xml file of the workstation VM to give it 8GB of RAM and mentionning the correct .qcow2 path aswell:</p>
<p>Now that the XML files are correctly setup, we can write script.sh to make sure they are quickly setup if not already, and quickly removed if they are:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim Whonix-Workstation.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Workstation.xml | grep emory
<<b></b>memory dumpCore="off" unit="GiB">8<<b></b>/memory>
<<b></b>currentMemory unit="GiB">8<<b></b>/currentMemory>
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Workstation.xml | grep qcow2
<<b></b>driver name="qemu" type="qcow2"/>
<<b></b>source file="/mnt/veracrypt1/Whonix-Workstation.qcow2"/>
</pre></code>
<p>and from here we create <b>script.sh</b> that we put inside the veracrypt hidden volume, we will use it to automatically either import or remove both VMs into virt-manager depending on wether they are already imported or not.</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim script.sh
[ nowhere ] [ /dev/pts/0 ] [~]
→ cat /mnt/veracrypt1/script.sh
[user /run/media/private/user/sda]% cat script.sh
#!/bin/bash
if [ $(virsh -c qemu:///system list --all | grep Whonix | wc -l) -ne 0 ];
@ -290,29 +281,27 @@ else
# if the VMs are not imported, import them:
virsh -c qemu:///system net-define /mnt/veracrypt1/Whonix-external.xml
virsh -c qemu:///system net-define /mnt/veracrypt1/Whonix-internal.xml
virsh -c qemu:///system net-define /run/media/private/user/sda/Whonix-External.xml
virsh -c qemu:///system net-define /run/media/private/user/sda/Whonix-Internal.xml
virsh -c qemu:///system net-autostart Whonix-External
virsh -c qemu:///system net-start Whonix-External
virsh -c qemu:///system net-autostart Whonix-Internal
virsh -c qemu:///system net-start Whonix-Internal
virsh -c qemu:///system define /mnt/veracrypt1/Whonix-Gateway.xml
virsh -c qemu:///system define /mnt/veracrypt1/Whonix-Workstation.xml
virsh -c qemu:///system define /run/media/private/user/sda/Whonix-Gateway.xml
virsh -c qemu:///system define /run/media/private/user/sda/Whonix-Workstation.xml
# then exit because we dont want to run the rest of wipe.sh
exit $?
fi
</pre></code>
<p>So by default you have your QEMU VMs like so:</p>
<img src="26.png" class="imgRz">
<p>And to run the script to import the VMs you do as follows:</p>
<p>Then we make the script executable and run it to setup the whonix VMs:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ chmod +x script.sh
[user /run/media/private/user/sda]% chmod +x ./script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ./script.sh
Network Whonix-External defined from Whonix-external.xml
[user /run/media/private/user/sda]% ./script.sh
Network Whonix-External defined from /run/media/private/user/sda/Whonix-External.xml
Network Whonix-Internal defined from Whonix-internal.xml
Network Whonix-Internal defined from /run/media/private/user/sda/Whonix-Internal.xml
Network Whonix-External marked as autostarted
@ -322,17 +311,16 @@ Network Whonix-Internal marked as autostarted
Network Whonix-Internal started
Domain 'Whonix-Gateway' defined from Whonix-Gateway.xml
Domain 'Whonix-Gateway' defined from /run/media/private/user/sda/Whonix-Gateway.xml
Domain 'Whonix-Workstation' defined from Whonix-Workstation.xml
Domain 'Whonix-Workstation' defined from /run/media/private/user/sda/Whonix-Workstation.xml
</pre></code>
<p>From there you'll see that the Whonix VMs are imported:</p>
<img src="27.png" class="imgRz">
<p>And now to remove them you can just run the same script again:</p>
<p>As you can see it successfully mounted the whonix VMs:</p>
<img src="113.png" class="imgRz">
<p>And then if you run it again you'll see that it removes the VMs: </p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ./script.sh
[user /run/media/private/user/sda]% ./script.sh
error: Failed to destroy domain 'Whonix-Gateway'
error: Requested operation is not valid: domain is not running
@ -352,336 +340,232 @@ Network Whonix-External has been undefined
Network Whonix-Internal has been undefined
</pre></code>
<p>And you'll see that the VMs are no longer there:</p>
<img src="26.png" class="imgRz">
<img src="114.png" class="imgRz">
<p>Next, run the script again to setup the VMs once again:</p>
<pre><code class="nim">
[user /run/media/private/user/sda]% ./script.sh
</div>
</pre></code>
<p>And then upon starting the VMs we see that they work as intended:</p>
<img src="115.png" class="imgRz">
<p>Inside this one whonix workstation is the only context where i consider sensitive use to be suitable, <b>so make sure you don't do any other long-term sensitive activities (meaning you are storing sensitive data somewhere) outside of this VM, because you wouldn't be able to maintain deniability about it otherwise!</b></p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<div id="anon2">
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Setting up the Decoy volume</b></h2> </br> </br>
<p>If you are in the usecase where you cannot reveal to the adversary that you have veracrypt installed (meaning veracrypt will only be installed in live mode) you can skip this entire section. As the adversary won't even be aware that the non-system drive is encrypted using veracrypt.</p>
<p>Now that we have setup the hidden volume, let's close it so that we can setup the decoy volume (dont forget to exit the drive from the commandline, otherwise veracrypt will complain that the drive is busy):</p>
<h2><b>Setting up the Decoy Volume</b></h2> </br> </br>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cd ..
[ nowhere ] [ /dev/pts/1 ] [/mnt]
-in the decoy volume we download files that make sense to be stored in an encrypted volume (adult content / pirated movies, etc) but it needs to NOT be sensitive.
-then we write script.sh
</pre></code>
<p>Now first dismount the hidden volume:</p>
<img src="28.png" class="imgRz">
<p>And then mount the decoy volume:</p>
<img src="21.png" class="imgRz">
<p>In the decoy volume, we want content that makes sense to be kept hidden in an encrypted volume while still not being considered as sensitive (meaning nothing that can get you into trouble like adult content, or movies that you pirated):</p>
<p>Now that we setup the hidden volume, we setup what we need in the decoy volume:</p>
<img src="101.png" class="imgRz">
<p>The decoy volume must contain files that meet the following criterias:</p>
<ol>
<li><p>The files must make sense to be kept hidden in an encrypted volume</p></li>
<li><p>The files are not sensitive in nature (you're not going to be thrown in jail for it)</p></li>
<li><p>The files must be less than 200Gb</p></li>
</ol>
<p><b>Keep in mind that this is the content that you would show the adversary if they were to seize your devices and force you to type a password.</b> Therefore what you store in it absolutely needs to make sense to be stored in an encrypted volume.</p>
<img src="116.png" class="imgRz">
<p>And obviously, the total diskspace consumed by the decoy files need to be less than 250Gb, as otherwise you'd overwrite (and destroy) the veracrypt hidden volume in the process.</p>
<p>As we have covered previously, the usual content that makes sense to be kept in an encrypted volume can be something along the lines of adult content, downloaded movies, or similar:</p>
<img src="117.png" class="imgRz">
<p>So in here we put some decoy files that would make sense for an adversary to find in an encrypted container:</p>
<img src="118.png" class="imgRz">
<p>Then we write the following script.sh in there:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ cd /mnt/veracrypt1
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ls
lost+found
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ sudo apt install yt-dlp vlc -y
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ yt-dlp https://www.youtube.com/watch\?v\=16efRG5H_Vc
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ yt-dlp https://www.youtube.com/watch\?v\=HmZm8vNHBSU
</code></pre>
<img src="29.png" class="imgRz">
<p>So in this example we're going to pretend we have pirated some movies and got some adult content, that way we have an excuse as to why we have an encrypted veracrypt volume if ever forced by an adversary. We then create the script.sh which will basically be used to kill the media player window:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ chmod +x script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat script.sh
[user /run/media/private/user/sda]% vim script.sh
[user /run/media/private/user/sda]% cat script.sh
#!/bin/bash
kill -9 $(pidof vlc)
[user /run/media/private/user/sda]% chmod +x script.sh
</pre></code>
<p>If ever asked to by an adversary, we'll basically pretend that this script is there to quickly kill the media player window in case if someone were to enter the room while you were watching that not-sensitive-but-private content.</p>
<p>And that's it ! We have now setup both the Hidden Volume with the whonix VMs in it for sensitive use, and the Decoy Volume containing the data we'd show the adversary if ever forced to.</p>
</div>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Emergency shutdown shortcut</b></h2> </br> </br>
<!--<p>Now that we're done setting up both the hidden and the decoy volumes, we're going to setup the script that will launch either of the 2 script.sh scripts we just wrote, on top of also erasing all potential proof that the sensitive VM exists (meaning we erase all logs, all kernel logs, we fill the ram with random content 3 times, and we erase the command history): </p>
<p>First we need to make sure we can run veracrypt commands without requiring to be a sudo user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ ls -lash /usr/bin/veracrypt
4.3M -rwxr-xr-x 1 root root 4.3M Sep 8 22:37 /usr/bin/veracrypt
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo chown root:nihilist /usr/bin/veracrypt
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo groupadd veracrypt
[sudo] password for nihilist:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo usermod -aG veracrypt $(whoami)
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ zsh
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo visudo -f /etc/sudoers.d/veracrypt
%veracrypt ALL=(root) NOPASSWD:/usr/bin/veracrypt, /usr/bin/mount, /usr/bin/umount, /usr/bin/uptime
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ whoami
nihilist
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ veracrypt -d -f
</pre></code>
<p>Now from there (after a reboot) you wont require sudo passwords to use veracrypt anymore. Next we need to be able to remove all logs without being the root user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo setfacl -Rm u:$(whoami):rwX /var/log
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ rm /var/log/*.log /var/log/*/*.log /var/log/*/*/*.log -rf
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo setfacl -Rm u:$(whoami):rwX /dev/shm
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ rm /dev/shm/*.log /dev/shm/*/*.log /dev/shm/*/*/*.log -rf
</pre></code>
<p>Then we need to do the same but to remove all kernel logs:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo sysctl -w kernel.dmesg_restrict=0
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo vim /etc/sysctl.d/01-dmesg.conf.txt
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ cat /etc/sysctl.d/01-dmesg.conf.txt
kernel.dmesg_restrict = 0
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo chown root:nihilist /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo chmod 750 /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo setcap cap_syslog=ep /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ dmesg -c
</pre></code>
<p>then we kill veracrypt's process to avoid having the veracrypt window display which drive/volume was selected:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ kill $(pidof veracrypt)
</pre></code>
<p>and then we overwrite the ram contents like so:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo apt install stress -y
#find how many GBs of ram you have:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1
125
#do a stress test to fill those 125GBs of ram:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress: info: [2659012] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: info: [2659012] successful run completed in 11s
</pre></code>
<p>so now we write the wipe.sh script, that we place at the home directory of our user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [~]
→ cd
[ nowhere ] [ /dev/pts/1 ] [~]
→ vim wipe.sh
[ nowhere ] [ /dev/pts/1 ] [~]
→ cat wipe.sh
#!/bin/bash
# run script.sh from inside the veracrypt volume:
/mnt/veracrypt1/script.sh
# close down the veracrypt volume:
/usr/bin/veracrypt -d -f
# remove all system logs:
rm /var/log/*.log /var/log/*/*.log /var/log/*/*/*.log -rf
rm /dev/shm/*.log /dev/shm/*/*.log /dev/shm/*/*/*.log -rf
# remove all kernel logs:
/usr/bin/dmesg -c >/dev/null 2>/dev/null
# kill the veracrypt process:
kill $(pidof veracrypt)
# erase the commandline history:
echo '' > ~/.zsh_history
echo '' > ~/.bash_history
# overwrite the ram contents 3 times:
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
[ nowhere ] [ /dev/pts/1 ] [~]
→ chmod +x wipe.sh
</pre></code>-->
<p>Now that we're setup, we need to be able to run that script using a shortcut to be ran from our desktop environment, I am currently using Cinnamon, therefore to create a shortcut for cinnamon you do as follows:</p>
<img src="30.png" class="imgRz">
<!--<img src="31.png" class="imgRz">
<img src="32.png" class="imgRz">
<p>So basically from here, if you are not in a QEMU VM, you simply need to hit the shortcut <b>"SUPER+R"</b>.</p>
<p>If you are focused in a QEMU VM, you need to do <b>"Ctrl+Alt"</b> (to focus out of the QEMU VM), and then <b>"SUPER+R"</b> to run the wipe.sh script from the Host OS.</p>-->
<img src="37.png" class="imgRz">
<p>Now we're setting up the shortcut <b>"Super+V"</b> to run the <b>/mnt/veracrypt1/script.sh</b> script just so it is quicker to setup the whonix VMs when inside the veracrypt hidden volume.</p>
<img src="36.png" class="imgRz">
<p> Now in order to shut down the Host OS, as we have explained <a href="../livemode/index.html">previously</a>, we need to have the emergency shutdown bashscript script:</p>
<pre><code class="nim">
nihilist@mainpc:~$ su -
Password:
root@mainpc:~# visudo
[...]
nihilist ALL=NOPASSWD:/sbin/shutdown
[...]
nihilist@mainpc:~$ vim shutdown.sh
nihilist@mainpc:~$ cat shutdown.sh
#!/bin/bash
/sbin/shutdown -h now
nihilist@mainpc:~$ chmod +x shutdown.sh
</pre></code>
<p>However we're going to edit it a bit to run the script.sh, along with closing down the veracrypt volumes before shutting down the Host OS, so we need to edit the shutdown.sh script as follows:</p>
<pre><code class="nim">
nihilist@mainpc:~$ cat shutdown.sh
#!/bin/bash
# run script.sh
/mnt/veracrypt1/script.sh
# unmount veracrypt volumes
/usr/bin/veracrypt -d -f
# kill veracrypt after unmounting
kill $(pidof veracrypt)
# shutdown the host OS
/sbin/shutdown -h now
</pre></code>
<p>before we continue, dont forget to update it on your VPS, so you can reuse it next time:</p>
<pre><code class="nim">
nihilist@mainpc:~$ scp shutdown.sh root@65.109.30.253:/root/sensitive_scripts/shutdown.sh
</pre></code>
<p>Then, we need to make sure that the shutdown.sh script can be ran with the <b>"Super+R"</b> shortcut:</p>
<img src="41.png" class="imgRz">
<p>And we're now all setup! So let's try it out in both scenarios (from the decoy volume, and from the hidden volume):</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<!-- +++++ Second Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Decoy Volume Scenario (watching non-sensitive content)</b></h2>
<p>As stated before, this part is relevant only if you are in the usecase where veracrypt remains installed on the host OS outside of live mode. You can skip that part if you are keeping veracrypt installed only in live mode.</p>
<p>So first we open the veracrypt, and open the decoy volume:</p>
<img src="21.png" class="imgRz">
<img src="22.png" class="imgRz">
<p>Then we open VLC, and we hit "Open file" and browse to our non-sensitive files:</p>
<img src="33.png" class="imgRz">
<img src="34.png" class="imgRz">
<p>Then suddenly someone busts your front door, and you quickly press <b>"Super+R"</b> the VLC window immediately closes, followed by the closure of the veracrypt volume, and in a few seconds you have the Host OS shutting down. And as the Host OS shuts down, all the RAM contents are erased (even though there was nothing sensitive in it this time).</p>
<img src="" class="imgRz">
<p>And that's it ! if the adversary didnt get to your desk by the time you pressed the shortcut, he didnt get to see the content you were playing on your monitor. </p>
<h2><b>Hidden Volume Scenario (using the sensitive VM)</b></h2>
<p>Now to test emergency shutdown on the hidden volume side, we first open the hidden volume:</p>
<img src="23.png" class="imgRz">
<img src="24.png" class="imgRz">
<p>Once the hidden volume is mounted, we hit <b>"Super+V"</b> to quickly setup the whonix VMs:</p>
<img src="38.png" class="imgRz">
<p>And after a while of doing some actual sensitive stuff on the whonix VM you hear your front door being busted down, so you quickly hit <b>"Ctrl+Alt"</b> to focus out of the VM, and then you hit <b>"Super+R"</b> to trigger the emergency shutdown:</p>
<img src="42.png" class="imgRz">
<p>Here it also only takes approximately 4 seconds after pressing <b>"Super+R"</b> to have the VMs removed, the veracrypt volume closed, and your Host OS shutdown, erasing all the forensic evidence regarding the existence of the veracrypt hidden volume and the Sensitive Whonix VM that it contains.</p>
<p>And that's it ! You now have a Sensitive VM ready to be used, and you have implemented the necessary measures to protect the deniability of it's existance, from an adversary.</p>
</div>
<h2><b>Fine-tuning the emergency reboot script</b></h2> </br> </br>
<p>For this next part, we're going to reuse the emergency reboot.sh bashscript that we showcased <a href="../livemode/index.html">previously</a>, so let's reboot the Host OS to be able to edit it outside of live mode since we want it to be a persistant change:</p>
<img src="../livemode/15.png" class="imgRz">
<p><img src="../logos/de2.png"><b>Reminder: once again, if you are outside of live mode like we are right now, DO NOT OPEN THE HIDDEN VOLUME, as otherwise you're leaving forensic evidence regarding it's existance on the system drive!</b></p>
<pre><code class="nim">
[user ~]% cat reboot.sh
#!/bin/bash
/usr/bin/sudo /usr/sbin/reboot now
</pre></code>
<p>But we're going to refine it so that it does the following:</p>
<ol>
<li><p>Turn off the screen display output (to prevent the adversary from seeing what is happening on the monitor)</p></li>
<li><p>Run the script.sh (that is either in the decoy or the hidden volume, depending on which one is currently opened)</p></li>
<li><p>Close the veracrypt volume (and anything that could block the closing of the volume, such as closing thunar)</p></li>
<li><p>Trigger the host OS reboot, (wiping the RAM in the process) </p></li>
</ol>
<p>Which after tweaking it accordingly we end up with the following reboot script:</p>
<pre><code class="nim">
[user ~]% vim reboot.sh
[user ~]% cat reboot.sh
#!/bin/bash
# turn off display
xset dpms force off &
<b># run script.sh to kill vlc
/run/media/private/user/sda/script.sh</b>
# kill all processes that could block veracrypt from closing
killall thunar
killall xfce4-terminal
# close the veracrypt volume using zulucrypt
sudo zuluCrypt-cli -q -d /dev/sda
# kill zuluCrypt after unmounting to make sure it doesnt block the reboot
killall zuluCrypt-gui
# reboot the host OS
/usr/bin/sudo /usr/sbin/reboot now
</pre></code>
<p>Even in a deniability setting, having this script sit in your home directory doesn't incriminate you either, <b>because you can tell the adversary that this script is used to prevent someone else from seeing that you're watching the non-sensitive content (such as adult content) that is sitting in the encrypted volume.</b> Still this is a plausible explanation that makes it look like you are cooperating to the adversary when you are being asked about that script in particular.</p>
<p>And as we showcased previously, we want this script to be executable with a single keystroke (using the right control key) so to make sure the shortcut is set, run this command:</p>
<pre><code class="nim">
xfconf-query -c xfce4-keyboard-shortcuts -n -t 'string' -p '/commands/custom/Control_R' -s /home/user/reboot.sh
</pre></code>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon1">
<!-- +++++ Second Post +++++ -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>In what context is there Deniability ?</b></h2>
<p>With this setup, you have deniability the moment that the Host OS finishes shutting down, regarding the existance of the veracrypt hidden volume, and the whonix sensitive VMs that are in it. <b>Meaning that it is impossible for an adversary that seizes your computer to prove the existance of the Whonix Sensitive VMs after the Host OS finished shutting down.</b></p>
<p>If you leave veracrypt and shutdown.sh on the host OS, below is all an adversary will be able to see , if he were to seize your laptop after you manage to shut it down:</p>
<img src="40.png" class="imgRz">
<p>Of course, if you are ever forced to, <b>ONLY give your decoy password to the adversary.</b> The existance of the hidden volume, and of the secret password thats used to reveal it must remain a secret at all costs, it must remain known only by you.</p>
<p>If you are ever dragged into court, <b>the judge will appreciate much more if you actually hand over your laptop, and show that you are willing to cooperate with the authorities by providing your password to unlock it</b>, rather than starting to pretend you forgot your password (which can end badly like in <a href="https://lawblog.legalmatch.com/2018/07/23/florida-man-jailed-allegedly-forgetting-password-on-cell-phones/">this court case</a>, where the defendant was found to be in contempt of court, and thrown in jail for 6 months for it). </p>
<p>If ever asked by the authorities on why you used veracrypt in your laptop, you can simply claim that it was to put your stash of adult content in it. Nothing incriminating about it, and it is plausible given that you dont want that laying around on your desktop, due to being of a private matter.</p>
<p>Now in the usecase where you are not leaving veracrypt and shutdown.sh on the host OS, below is what the adversary can see:</p>
<img src="43.png" class="imgRz">
<p>Since there is no emergency shutdown script, nor any Veracrypt to be found. The adversary can't figure out that the non-system drive has been encrypted with Veracrypt, nor that you are hiding anything in it, all that the adversary can see is that the drive is filled with random meaningless data.</p>
<h2><b>Emergency Reboot Scenario</b></h2> </br> </br>
<pre><code class="nim">
-the authorities are busting down your door, you see them coming
-you immediately press the right control key
-the computer immediately wipes all the ram contents and reboots
-as the computer is restarting, all forensic traces relating to the existance of the veracrypt hidden volume have been erased.
</div>
-the adversary pins you down and handcuffs you
-the adversary opens up the computer, dumps liquid nitrogen on the ramsticks, then takes them out to store them safely and takes out the harddrives (the system drive and the non-system harddrive)
</pre></code>
<p>As explained higher up in this tutorial, you're going to have to test your emergency reboot procedure a few times to make sure it works but also to get used to it, <b>because when there's going to be a real emergency, you're going to need perform that emergency reboot procedure in a split second.</b></p>
<p>So let's showcase how to do it. First setup the context, booting from the Host OS in live mode:
<img src="../livemode/12.png" class="imgRz">
<p><img src="../logos/de0.png"><b>Reminder: Now that we are back in live mode, you can open the veracrypt hidden volume once again!</b></p>
<p>Then open the veracrypt hidden volume:</p>
<img src="109.png" class="imgRz">
<img src="110.png" class="imgRz">
<img src="111.png" class="imgRz">
<p>and then run script.sh to setup the sensitive VMs:</p>
<pre><code class="nim">
[user /run/media/private/user/sda]% chmod +x ./script.sh
[user /run/media/private/user/sda]% ./script.sh
Network Whonix-External defined from /run/media/private/user/sda/Whonix-External.xml
Network Whonix-Internal defined from /run/media/private/user/sda/Whonix-Internal.xml
Network Whonix-External marked as autostarted
Network Whonix-External started
Network Whonix-Internal marked as autostarted
Network Whonix-Internal started
Domain 'Whonix-Gateway' defined from /run/media/private/user/sda/Whonix-Gateway.xml
Domain 'Whonix-Workstation' defined from /run/media/private/user/sda/Whonix-Workstation.xml
</pre></code>
<img src="113.png" class="imgRz">
<p>And now that the sensitive VMs are listed in virt-manager, we open them:</p>
<img src="115.png" class="imgRz">
<p>This is your normal booting up routine when you want to do sensitive activities. Only from the host OS being in live mode, and from that VM alone.</p>
<p><u>Sidenote:</u> if you never make a single opsec mistake, you won't ever have the cops busting down your front door, but you never know when you might slip up in the future. <b>So you must always be ready for the worst when you are actually risking jailtime.</b> Test yourself at random every few days. What if someone was busting down your door Right now ? Would you be able to reboot your computer in time ? Aim for a 100% success rate, because when the real time comes, it will all depend on your reactivity.</p>
<p>So now you have been doing your regular sensitive activities from that VM for the last 4 hours, <b>and suddenly you hear your front door getting busted down,</b> suppose the door is right next to you like in <a href="https://www.youtube.com/watch?v=jEhprcgv3Pg">this video</a>, you only have 5 seconds to correctly react and press the right ctrl key to be able to shut down the sensitive VM on time.</p>
<img src="119.png" class="imgRz">
<p>So your door is getting busted down, and before the 5 second limit you manage to correctly <b>press that right ALT key to focus out of the sensitive VM, and then the right control key to trigger the reboot.sh script</b>.</p>
<p>And then upon pressing it, it immediately turns off the monitor and as you are getting pinned down by the adversary, the script is automatically unmounting the veracrypt volume, and rebooting the computer as intended.</p>
<p>If the adversary is skilled enough, they'd attempt to open up the PC, put some liquid nitrogen on the RAM sticks, to try and freeze the content of the memory, but by the time they try to do that, the contents of the RAM would be long gone already if you managed to press the emergency reboot key in time. </p>
<img src="../cloud_provider_adversary/7.png" class="imgRz">
<p>Next, they seize the empty ramsticks, and the encrypted drives, they put you in handcuffs, put you in custody, while they inspect what they seized for incriminating evidence.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Emergency reboot Scenario: the Aftermath</b></h2> </br> </br>
<pre><code class="nim">
Aftermath:
-the forensic team inspects the RAM contents and the disk contents:
-the RAM contents are empty: it only shows the typical contents of kicksecure booting and waiting for a password to unlock the system drive (since it rebooted successfully)
-the disk contents are encrypted: the adversary is forced to get the password from you to be able to unlock it
-the authorities get approval from the judge: you are now forced to give them the password to unlock your computer
from custody:
-the cops tell you the following: Either you give us your passwords to unlock your computer drives, or you're going to prison for a long time!
</pre></code>
<p><u>In this situation here are your options:</u></p>
<ol>
<li><p>either you admit everything you did and get thrown in jail for however long the punishment is supposed to be. (if were playing late in china for example) : life sentence in concentration camps</p></li>
<li><p>either you refuse to give them the passwords and get thrown in jail for contempt of court (their reasoning: you lied that you forgot your password) : 6 months jailtime</p></li>
<li><p><b>Or you accept to give the password (which is the decoy password) to unlock the decoy volume (where there's nothing sensitive in there): you look good for the court, it looks like you have cooperated: 0 months jailtime</b></p></li>
</ol>
<p>Of course you select the last option (since this is the point of implementing such a setup), <b>you give them the decoy password, they find nothing in it, and now they are left with no evidence to incriminate you with.</b></p>
<p>If the adversary is not stupid, they should already have something to incriminate you with before actually busting down your door (because you slipped up somewhere along the way while you were doing sensitive activities), meaning that you are anyway going away for some time. It would be stupid to bust down people's doors without having any actual evidence, it would be like playing the lottery hoping to find gold while ruining someone's appartment.</p>
<p> It may seem far-fetched but <b>you can't discard that eventuality since there have been <a href="https://www.youtube.com/watch?v=coa7tP54kDY">many innocent streamers got swatted</a> in the past</b> (because of assholes that were falsely reporting bomb threats or gun shots just because they didn't like a streamer):</p>
<img src="120.png" class="imgRz">
<p>In those cases in particular, <b>the authorities believe that they'll find a criminal behind the door that they're busting down, so they bust it down despite not having any evidence.</b> And afterward they realize that the guy is innocent, and they release him.</p>
<p>Obviously here the context is different as you may actually have something to hide, but with that setup it remains impossible for the adversary to prove the existance of the hidden volume and the sensitive VM it contains. <b>The strategy here is that you are limiting the bleeding as much as possible</b>. The authorities may have evidence to put you in jail for 1 month, but if you don't properly stop the bleeding on time, they may find enough evidence for them to convict you for 20 years depending on the nature of the sensitive activity that you have been doing.</p>
<p>In the case of our showcased setup above, The authorities cannot incriminate you further because there's nothing more for them to find on your seized drives and ramsticks.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /grey -->
<!-- +++++ Footer Section +++++ -->

721
opsec/sensitivevm/old.html Normal file
View file

@ -0,0 +1,721 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="">
<meta name="author" content="">
<link rel="shortcut icon" href="../../../../../../assets/img/favicon.png">
<title>Sensitive use VMs Setup (Whonix VMs in a Veracrypt Hidden Volume)</title>
<!-- Bootstrap core CSS -->
<link href="../../assets/css/bootstrap.css" rel="stylesheet">
<link href="../../assets/css/xt256.css" rel="stylesheet">
<!-- Custom styles for this template -->
<link href="../../assets/css/main.css" rel="stylesheet">
<!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
<![endif]-->
</head>
<body>
<!-- Static navbar -->
<div class="navbar navbar-inverse-anon navbar-static-top">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand-anon" href="\index.html">The Nihilism Opsec Blog</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav navbar-right">
<li><a href="/about.html">About</a></li>
<li><a href="/blog.html">Categories</a></li>
<li><a href="/contact.html">Contact</a></li>
</ul>
</div><!--/.nav-collapse -->
</div>
</div>
<!-- +++++ Posts Lists +++++ -->
<!-- +++++ First Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<a href="../index.html">Previous Page</a></br></br><p><img src="../../assets/img/user.png" width="50px" height="50px"> <ba>nihilist@mainpc - 2024-10-29</ba></p>
<h1>Sensitive use VMs Setup (Whonix VMs in a Veracrypt Hidden Volume) </h1>
<img src="0.png" class="imgRz">
<p>In this tutorial we're going to cover how to setup Whonix VMs for Sensitive use. This means that our <a href="../opsec4levels/index.html">OPSEC requirement</a> is that <b>we need to be able to deny the existance of the Sensitive Whonix VM if the adversary ever gets access to our laptop.</b> </p>
<p>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. </p>
<p><u>CONTEXT WARNING:</u> this setup is only suitable <b>if you are not going to be thrown in jail for just using Veracrypt.</b>, and if an adversary were to bust down your front door, <b>you need to have at least 5 seconds before he can see your laptop screen.</b></p>
<p><h2><u>OPSEC Recommendations:</u></h2></p>
<ol>
<li><p>Hardware : (Personal Computer / Laptop)</p></li>
<li><p>Host OS: <a href="../linux/index.html">Linux</a>, but in <a href="../livemode/index.html">live mode</a></p></li>
<li><p>Hypervisor: <a href="../hypervisorsetup/index.html">libvirtd QEMU/KVM</a></p></li>
<li><p>Harddrive (HDD): 500GB and encrypted with <a href="../veracrypt/index.html">Veracrypt (with a 250Gb Hidden Volume)</a></p></li>
<li><p>Virtual Machine:<a href="../whonixqemuvms/index.html">Whonix</a></p></li>
</ol>
<p><img src="../logos/daturagit.png" style="width:100px"> <u>Sidenote:</u> Help us improve this tutorial by letting us know if there's anything missing or incorrect on this <a href="http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/issues/256">git issue</a> directly!</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Deniability Requirements</b></h2> </br> </br>
<p>First of all as you have seen, the requirement is that we do this setup from the Host OS, in <a href="../livemode/index.html">live mode</a>. That is because we want to make sure that there is no forensic evidence to be saved on the system drive as we have explained <a href="../livemode/index.html">previously.</a> </p>
<img src="../livemode/4.png" class="imgRz">
<p>While in Live mode we can't write anything new on the system disk (such as the system logs, kernel logs, non-standard logs) <b>which can all be potential forensic evidence that the hidden volume exists</b>. Instead, everything is written into RAM, and we can easily erase all of those contents with a simple reboot. While in live mode however, we can write to non-system drives, which is where we will setup a big enough veracrypt volume to store the Whonix VMs that we will use for long-term sensitive use.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>How to setup the VMs inside the Hidden Volume</b></h2> </br> </br>
<p>So before we start, make sure you reboot the Host OS to go into live mode</p>
<img src="../livemode/12.png" class="imgRz">
<p>Then, once in live mode <b>if you are in the usecase where you cannot reveal to the adversary that there is veracrypt installed on the host OS, make sure you install it everytime you boot into live mode.</b> To do speed up the installation process we're going to use the VPS we showcased <a href="../veracrypt/index.html">previously</a> to install both veracrypt and the emergency shutdown script:</p>
<pre><code class="nim">
nothing@debian:~$ scp root@65.109.30.253:/root/sensitive_scripts/vc.deb .
root@65.109.30.253's password:
vc.deb 100% 8995KB 1.9MB/s 00:04
nothing@debian:~$ sudo dpkg -i vc.deb
nothing@debian:~$ sudo apt install -f
nothing@debian:~$ sudo dpkg -i vc.deb
nothing@debian:~$ which veracrypt
/usr/bin/veracrypt
nothing@debian:~$ scp root@65.109.30.253:/root/sensitive_scripts/shutdown.sh .
nothing@debian:~$ chmod +x shutdown.sh
nothing@debian:~$ veracrypt
</pre></code>
<p>We briefly make sure that the shutdown.sh script is hooked up to the <b>SUPER+R</b> key to make sure we can quickly shutdown the computer in case if an adversary were to bust down our door:</p>
<img src="../livemode/5.png" class="imgRz">
<img src="../livemode/6.png" class="imgRz">
<p>And now that we did the post-live-boot initial setup, we can start to setup our veracrypt volumes on our 500Gb harddrive:</p>
<img src="2.png" class="imgRz">
<img src="3.png" class="imgRz">
<p>Here we're using a non-system drive, as we want to be able to store our veracrypt hidden volume contents in a persistent manner, accross reboots. (if we were to have the veracrypt volume on the system drive, it would be wiped off upon rebooting since the Host OS is in live mode.)</p>
<img src="4.png" class="imgRz">
<img src="5.png" class="imgRz">
<img src="6.png" class="imgRz">
<img src="7.png" class="imgRz">
<img src="8.png" class="imgRz">
<img src="9.png" class="imgRz">
<img src="10.png" class="imgRz">
<img src="11.png" class="imgRz">
<p>And in our veracrypt outer (decoy) volume, we're going to setup the veracrypt inner (hidden) volume, and set it to be 250Gb big:</p>
<img src="12.png" class="imgRz">
<img src="13.png" class="imgRz">
<img src="14.png" class="imgRz">
<img src="15.png" class="imgRz">
<img src="16.png" class="imgRz">
<img src="17.png" class="imgRz">
<img src="18.png" class="imgRz">
<img src="19.png" class="imgRz">
<img src="20.png" class="imgRz">
<p>Now that the vercarypt volume has been setup, to highlight the mechanism, for the same harddrive, you have 2 passwords. Password A opens up the decoy volume, and Password B (which must remains secret, only to be known by you) opens up the hidden volume:</p>
<img src="21.png" class="imgRz">
<img src="22.png" class="imgRz">
<img src="23.png" class="imgRz">
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Setting up the Hidden Volume</b></h2> </br> </br>
<p>So now let's setup the hidden volume, where we will put the Sensitive Whonix QEMU VMs:</p>
<img src="24.png" class="imgRz">
<p>Then, we're going to download the Whonix VMs and configure them to be used from inside the hidden veracrypt volume: </p>
<img src="25.png" class="imgRz">
<pre><code class="nim">
[ nowhere ] [ /dev/pts/23 ] [VAULT/ISOs/whonix]
→ mv ~/Downloads/Whonix-Xfce-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz /mnt/veracrypt1/
[ nowhere ] [ /dev/pts/23 ] []
→ tar -xvf Whonix-Xfce-17.2.3.7.Intel_AMD64.qcow2.libvirt.xz
WHONIX_BINARY_LICENSE_AGREEMENT
WHONIX_DISCLAIMER
Whonix-Gateway-Xfce-17.2.3.7.xml
Whonix-Workstation-Xfce-17.2.3.7.xml
Whonix_external_network-17.2.3.7.xml
Whonix_internal_network-17.2.3.7.xml
Whonix-Gateway-Xfce-17.2.3.7.Intel_AMD64.qcow2
Whonix-Workstation-Xfce-17.2.3.7.Intel_AMD64.qcow2
[ nowhere ] [ /dev/pts/23 ] [VAULT/ISOs/whonix]
→ touch WHONIX_BINARY_LICENSE_AGREEMENT_accepted
</pre></code>
<p>next, we simplify the files names:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Gateway-Xfce-17.2.3.7.xml Whonix-Gateway.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Gateway-Xfce-17.2.3.7.Intel_AMD64.qcow2 Whonix-Gateway.qcow2
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Workstation-Xfce-17.2.3.7.xml Whonix-Workstation.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix-Workstation-Xfce-17.2.3.7.Intel_AMD64.qcow2 Whonix-Workstation.qcow2
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix_external_network-17.2.3.7.xml Whonix-external.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ mv Whonix_internal_network-17.2.3.7.xml Whonix-internal.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ls -l
total 209745392
drwx------ 2 root root 16384 Sep 1 21:24 lost+found
-rwxrwx--x 1 nihilist libvirt 1202 Jan 2 2024 refreshvms.sh
-rwxrwx--- 1 nihilist libvirt 39649 Oct 21 2015 WHONIX_BINARY_LICENSE_AGREEMENT
-rwxrwx--- 1 nihilist libvirt 4185 Oct 21 2015 WHONIX_DISCLAIMER
-rwxrwx--- 1 nihilist libvirt 172 Oct 21 2015 Whonix_external_network-17.2.3.7.xml
-rwxrwx--- 1 nihilist libvirt 107389386752 Nov 1 14:13 Whonix-Gateway.qcow2
-rwxrwx--- 1 nihilist libvirt 3577 Sep 1 22:31 Whonix-Gateway.xml
-rwxrwx--- 1 nihilist libvirt 97 Oct 21 2015 Whonix_internal_network-17.2.3.7.xml
-rwxrwx--- 1 nihilist libvirt 107389386752 Nov 1 14:13 Whonix-Workstation.qcow2
-rwxrwx--- 1 nihilist libvirt 3466 Sep 1 22:30 Whonix-Workstation.xml
</pre></code>
<p>And then we edit the .xml file of the gateway VM to give it 1GB of RAM and mentionning the correct .qcow2 path:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim Whonix-Gateway.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Gateway.xml | grep emory
<<b></b>memory dumpCore="off" unit="GiB">1<<b></b>/memory>
<<b></b>currentMemory unit="GiB">1<<b></b>/currentMemory>
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Gateway.xml | grep qcow2
<<b></b>driver name="qemu" type="qcow2"/>
<<b></b>source file="/mnt/veracrypt1/Whonix-Gateway.qcow2"/>
</pre></code>
<p>And then we do the same for the .xml file of the workstation VM to give it 8GB of RAM and mentionning the correct .qcow2 path aswell:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim Whonix-Workstation.xml
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Workstation.xml | grep emory
<<b></b>memory dumpCore="off" unit="GiB">8<<b></b>/memory>
<<b></b>currentMemory unit="GiB">8<<b></b>/currentMemory>
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat Whonix-Workstation.xml | grep qcow2
<<b></b>driver name="qemu" type="qcow2"/>
<<b></b>source file="/mnt/veracrypt1/Whonix-Workstation.qcow2"/>
</pre></code>
<p>and from here we create <b>script.sh</b> that we put inside the veracrypt hidden volume, we will use it to automatically either import or remove both VMs into virt-manager depending on wether they are already imported or not.</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim script.sh
[ nowhere ] [ /dev/pts/0 ] [~]
→ cat /mnt/veracrypt1/script.sh
#!/bin/bash
if [ $(virsh -c qemu:///system list --all | grep Whonix | wc -l) -ne 0 ];
then
# if the VMs are imported, remove them:
virsh -c qemu:///system destroy Whonix-Gateway
virsh -c qemu:///system destroy Whonix-Workstation
virsh -c qemu:///system undefine Whonix-Gateway
virsh -c qemu:///system undefine Whonix-Workstation
virsh -c qemu:///system net-destroy Whonix-External
virsh -c qemu:///system net-destroy Whonix-Internal
virsh -c qemu:///system net-undefine Whonix-External
virsh -c qemu:///system net-undefine Whonix-Internal
else
# if the VMs are not imported, import them:
virsh -c qemu:///system net-define /mnt/veracrypt1/Whonix-external.xml
virsh -c qemu:///system net-define /mnt/veracrypt1/Whonix-internal.xml
virsh -c qemu:///system net-autostart Whonix-External
virsh -c qemu:///system net-start Whonix-External
virsh -c qemu:///system net-autostart Whonix-Internal
virsh -c qemu:///system net-start Whonix-Internal
virsh -c qemu:///system define /mnt/veracrypt1/Whonix-Gateway.xml
virsh -c qemu:///system define /mnt/veracrypt1/Whonix-Workstation.xml
fi
</pre></code>
<p>So by default you have your QEMU VMs like so:</p>
<img src="26.png" class="imgRz">
<p>And to run the script to import the VMs you do as follows:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ chmod +x script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ./script.sh
Network Whonix-External defined from Whonix-external.xml
Network Whonix-Internal defined from Whonix-internal.xml
Network Whonix-External marked as autostarted
Network Whonix-External started
Network Whonix-Internal marked as autostarted
Network Whonix-Internal started
Domain 'Whonix-Gateway' defined from Whonix-Gateway.xml
Domain 'Whonix-Workstation' defined from Whonix-Workstation.xml
</pre></code>
<p>From there you'll see that the Whonix VMs are imported:</p>
<img src="27.png" class="imgRz">
<p>And now to remove them you can just run the same script again:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ./script.sh
error: Failed to destroy domain 'Whonix-Gateway'
error: Requested operation is not valid: domain is not running
error: Failed to destroy domain 'Whonix-Workstation'
error: Requested operation is not valid: domain is not running
Domain 'Whonix-Gateway' has been undefined
Domain 'Whonix-Workstation' has been undefined
Network Whonix-External destroyed
Network Whonix-Internal destroyed
Network Whonix-External has been undefined
Network Whonix-Internal has been undefined
</pre></code>
<p>And you'll see that the VMs are no longer there:</p>
<img src="26.png" class="imgRz">
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Setting up the Decoy volume</b></h2> </br> </br>
<p>If you are in the usecase where you cannot reveal to the adversary that you have veracrypt installed (meaning veracrypt will only be installed in live mode) you can skip this entire section. As the adversary won't even be aware that the non-system drive is encrypted using veracrypt.</p>
<p>Now that we have setup the hidden volume, let's close it so that we can setup the decoy volume (dont forget to exit the drive from the commandline, otherwise veracrypt will complain that the drive is busy):</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cd ..
[ nowhere ] [ /dev/pts/1 ] [/mnt]
</pre></code>
<p>Now first dismount the hidden volume:</p>
<img src="28.png" class="imgRz">
<p>And then mount the decoy volume:</p>
<img src="21.png" class="imgRz">
<p>In the decoy volume, we want content that makes sense to be kept hidden in an encrypted volume while still not being considered as sensitive (meaning nothing that can get you into trouble like adult content, or movies that you pirated):</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ cd /mnt/veracrypt1
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ ls
lost+found
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ sudo apt install yt-dlp vlc -y
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ yt-dlp https://www.youtube.com/watch\?v\=16efRG5H_Vc
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ yt-dlp https://www.youtube.com/watch\?v\=HmZm8vNHBSU
</code></pre>
<img src="29.png" class="imgRz">
<p>So in this example we're going to pretend we have pirated some movies and got some adult content, that way we have an excuse as to why we have an encrypted veracrypt volume if ever forced by an adversary. We then create the script.sh which will basically be used to kill the media player window:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ vim script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ chmod +x script.sh
[ nowhere ] [ /dev/pts/1 ] [/mnt/veracrypt1]
→ cat script.sh
#!/bin/bash
kill -9 $(pidof vlc)
</pre></code>
<p>If ever asked to by an adversary, we'll basically pretend that this script is there to quickly kill the media player window in case if someone were to enter the room while you were watching that not-sensitive-but-private content.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<div id="anon3">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Emergency shutdown shortcut</b></h2> </br> </br>
<!--<p>Now that we're done setting up both the hidden and the decoy volumes, we're going to setup the script that will launch either of the 2 script.sh scripts we just wrote, on top of also erasing all potential proof that the sensitive VM exists (meaning we erase all logs, all kernel logs, we fill the ram with random content 3 times, and we erase the command history): </p>
<p>First we need to make sure we can run veracrypt commands without requiring to be a sudo user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ ls -lash /usr/bin/veracrypt
4.3M -rwxr-xr-x 1 root root 4.3M Sep 8 22:37 /usr/bin/veracrypt
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo chown root:nihilist /usr/bin/veracrypt
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo groupadd veracrypt
[sudo] password for nihilist:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo usermod -aG veracrypt $(whoami)
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ zsh
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo visudo -f /etc/sudoers.d/veracrypt
%veracrypt ALL=(root) NOPASSWD:/usr/bin/veracrypt, /usr/bin/mount, /usr/bin/umount, /usr/bin/uptime
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ whoami
nihilist
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ veracrypt -d -f
</pre></code>
<p>Now from there (after a reboot) you wont require sudo passwords to use veracrypt anymore. Next we need to be able to remove all logs without being the root user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo setfacl -Rm u:$(whoami):rwX /var/log
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ rm /var/log/*.log /var/log/*/*.log /var/log/*/*/*.log -rf
[ nowhere ] [ /dev/pts/1 ] [~]
→ sudo setfacl -Rm u:$(whoami):rwX /dev/shm
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ rm /dev/shm/*.log /dev/shm/*/*.log /dev/shm/*/*/*.log -rf
</pre></code>
<p>Then we need to do the same but to remove all kernel logs:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo sysctl -w kernel.dmesg_restrict=0
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo vim /etc/sysctl.d/01-dmesg.conf.txt
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ cat /etc/sysctl.d/01-dmesg.conf.txt
kernel.dmesg_restrict = 0
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo chown root:nihilist /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo chmod 750 /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo setcap cap_syslog=ep /usr/bin/dmesg
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ dmesg -c
</pre></code>
<p>then we kill veracrypt's process to avoid having the veracrypt window display which drive/volume was selected:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ kill $(pidof veracrypt)
</pre></code>
<p>and then we overwrite the ram contents like so:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ sudo apt install stress -y
#find how many GBs of ram you have:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1
125
#do a stress test to fill those 125GBs of ram:
[ nowhere ] [ /dev/pts/1 ] [/mnt]
→ stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress: info: [2659012] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: info: [2659012] successful run completed in 11s
</pre></code>
<p>so now we write the wipe.sh script, that we place at the home directory of our user:</p>
<pre><code class="nim">
[ nowhere ] [ /dev/pts/1 ] [~]
→ cd
[ nowhere ] [ /dev/pts/1 ] [~]
→ vim wipe.sh
[ nowhere ] [ /dev/pts/1 ] [~]
→ cat wipe.sh
#!/bin/bash
# run script.sh from inside the veracrypt volume:
/mnt/veracrypt1/script.sh
# close down the veracrypt volume:
/usr/bin/veracrypt -d -f
# remove all system logs:
rm /var/log/*.log /var/log/*/*.log /var/log/*/*/*.log -rf
rm /dev/shm/*.log /dev/shm/*/*.log /dev/shm/*/*/*.log -rf
# remove all kernel logs:
/usr/bin/dmesg -c >/dev/null 2>/dev/null
# kill the veracrypt process:
kill $(pidof veracrypt)
# erase the commandline history:
echo '' > ~/.zsh_history
echo '' > ~/.bash_history
# overwrite the ram contents 3 times:
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
stress -m 1 --vm-bytes $(free -ght | grep Mem | cut -d ' ' -f 12 | cut -d 'G' -f 1)G -t 10
[ nowhere ] [ /dev/pts/1 ] [~]
→ chmod +x wipe.sh
</pre></code>-->
<p>Now that we're setup, we need to be able to run that script using a shortcut to be ran from our desktop environment, I am currently using Cinnamon, therefore to create a shortcut for cinnamon you do as follows:</p>
<img src="30.png" class="imgRz">
<!--<img src="31.png" class="imgRz">
<img src="32.png" class="imgRz">
<p>So basically from here, if you are not in a QEMU VM, you simply need to hit the shortcut <b>"SUPER+R"</b>.</p>
<p>If you are focused in a QEMU VM, you need to do <b>"Ctrl+Alt"</b> (to focus out of the QEMU VM), and then <b>"SUPER+R"</b> to run the wipe.sh script from the Host OS.</p>-->
<img src="37.png" class="imgRz">
<p>Now we're setting up the shortcut <b>"Super+V"</b> to run the <b>/mnt/veracrypt1/script.sh</b> script just so it is quicker to setup the whonix VMs when inside the veracrypt hidden volume.</p>
<img src="36.png" class="imgRz">
<p> Now in order to shut down the Host OS, as we have explained <a href="../livemode/index.html">previously</a>, we need to have the emergency shutdown bashscript script:</p>
<pre><code class="nim">
nihilist@mainpc:~$ su -
Password:
root@mainpc:~# visudo
[...]
nihilist ALL=NOPASSWD:/sbin/shutdown
[...]
nihilist@mainpc:~$ vim shutdown.sh
nihilist@mainpc:~$ cat shutdown.sh
#!/bin/bash
/sbin/shutdown -h now
nihilist@mainpc:~$ chmod +x shutdown.sh
</pre></code>
<p>However we're going to edit it a bit to run the script.sh, along with closing down the veracrypt volumes before shutting down the Host OS, so we need to edit the shutdown.sh script as follows:</p>
<pre><code class="nim">
nihilist@mainpc:~$ cat shutdown.sh
#!/bin/bash
# run script.sh
/mnt/veracrypt1/script.sh
# unmount veracrypt volumes
/usr/bin/veracrypt -d -f
# kill veracrypt after unmounting
kill $(pidof veracrypt)
# shutdown the host OS
/sbin/shutdown -h now
</pre></code>
<p>before we continue, dont forget to update it on your VPS, so you can reuse it next time:</p>
<pre><code class="nim">
nihilist@mainpc:~$ scp shutdown.sh root@65.109.30.253:/root/sensitive_scripts/shutdown.sh
</pre></code>
<p>Then, we need to make sure that the shutdown.sh script can be ran with the <b>"Super+R"</b> shortcut:</p>
<img src="41.png" class="imgRz">
<p>And we're now all setup! So let's try it out in both scenarios (from the decoy volume, and from the hidden volume):</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<!-- +++++ Second Post +++++ -->
<div id="anon2">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>Decoy Volume Scenario (watching non-sensitive content)</b></h2>
<p>As stated before, this part is relevant only if you are in the usecase where veracrypt remains installed on the host OS outside of live mode. You can skip that part if you are keeping veracrypt installed only in live mode.</p>
<p>So first we open the veracrypt, and open the decoy volume:</p>
<img src="21.png" class="imgRz">
<img src="22.png" class="imgRz">
<p>Then we open VLC, and we hit "Open file" and browse to our non-sensitive files:</p>
<img src="33.png" class="imgRz">
<img src="34.png" class="imgRz">
<p>Then suddenly someone busts your front door, and you quickly press <b>"Super+R"</b> the VLC window immediately closes, followed by the closure of the veracrypt volume, and in a few seconds you have the Host OS shutting down. And as the Host OS shuts down, all the RAM contents are erased (even though there was nothing sensitive in it this time).</p>
<img src="" class="imgRz">
<p>And that's it ! if the adversary didnt get to your desk by the time you pressed the shortcut, he didnt get to see the content you were playing on your monitor. </p>
<h2><b>Hidden Volume Scenario (using the sensitive VM)</b></h2>
<p>Now to test emergency shutdown on the hidden volume side, we first open the hidden volume:</p>
<img src="23.png" class="imgRz">
<img src="24.png" class="imgRz">
<p>Once the hidden volume is mounted, we hit <b>"Super+V"</b> to quickly setup the whonix VMs:</p>
<img src="38.png" class="imgRz">
<p>And after a while of doing some actual sensitive stuff on the whonix VM you hear your front door being busted down, so you quickly hit <b>"Ctrl+Alt"</b> to focus out of the VM, and then you hit <b>"Super+R"</b> to trigger the emergency shutdown:</p>
<img src="42.png" class="imgRz">
<p>Here it also only takes approximately 4 seconds after pressing <b>"Super+R"</b> to have the VMs removed, the veracrypt volume closed, and your Host OS shutdown, erasing all the forensic evidence regarding the existence of the veracrypt hidden volume and the Sensitive Whonix VM that it contains.</p>
<p>And that's it ! You now have a Sensitive VM ready to be used, and you have implemented the necessary measures to protect the deniability of it's existance, from an adversary.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<!-- +++++ Second Post +++++ -->
<div id="anon1">
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h2><b>In what context is there Deniability ?</b></h2>
<p>With this setup, you have deniability the moment that the Host OS finishes shutting down, regarding the existance of the veracrypt hidden volume, and the whonix sensitive VMs that are in it. <b>Meaning that it is impossible for an adversary that seizes your computer to prove the existance of the Whonix Sensitive VMs after the Host OS finished shutting down.</b></p>
<p>If you leave veracrypt and shutdown.sh on the host OS, below is all an adversary will be able to see , if he were to seize your laptop after you manage to shut it down:</p>
<img src="40.png" class="imgRz">
<p>Of course, if you are ever forced to, <b>ONLY give your decoy password to the adversary.</b> The existance of the hidden volume, and of the secret password thats used to reveal it must remain a secret at all costs, it must remain known only by you.</p>
<p>If you are ever dragged into court, <b>the judge will appreciate much more if you actually hand over your laptop, and show that you are willing to cooperate with the authorities by providing your password to unlock it</b>, rather than starting to pretend you forgot your password (which can end badly like in <a href="https://lawblog.legalmatch.com/2018/07/23/florida-man-jailed-allegedly-forgetting-password-on-cell-phones/">this court case</a>, where the defendant was found to be in contempt of court, and thrown in jail for 6 months for it). </p>
<p>If ever asked by the authorities on why you used veracrypt in your laptop, you can simply claim that it was to put your stash of adult content in it. Nothing incriminating about it, and it is plausible given that you dont want that laying around on your desktop, due to being of a private matter.</p>
<p>Now in the usecase where you are not leaving veracrypt and shutdown.sh on the host OS, below is what the adversary can see:</p>
<img src="43.png" class="imgRz">
<p>Since there is no emergency shutdown script, nor any Veracrypt to be found. The adversary can't figure out that the non-system drive has been encrypted with Veracrypt, nor that you are hiding anything in it, all that the adversary can see is that the drive is filled with random meaningless data.</p>
</div>
</div><!-- /row -->
</div> <!-- /container -->
</div><!-- /white -->
<!-- +++++ Footer Section +++++ -->
<div id="anonb">
<div class="container">
<div class="row">
<div class="col-lg-4">
<h4>Nihilism</h4>
<p>
Until there is Nothing left.</p></br></br><p>Creative Commons Zero: <a href="../../../../opsec/runtheblog/index.html">No Rights Reserved</a></br><img src="\CC0.png">
</p>
</div><!-- /col-lg-4 -->
<div class="col-lg-4">
<h4>My Links</h4>
<p>
<a target="_blank" rel="noopener noreferrer" href="http://blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/rss/feed.xml">RSS Feed</a><br/><a target="_blank" rel="noopener noreferrer" href="http://nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/simplex.html">SimpleX Chatrooms</a><br/>
</p>
</div><!-- /col-lg-4 -->
<div class="col-lg-4">
<h4>About nihilist</h4>
<p style="word-wrap: break-word;"><u>Donate XMR:</u> 8AUYjhQeG3D5aodJDtqG499N5jXXM71gYKD8LgSsFB9BUV1o7muLv3DXHoydRTK4SZaaUBq4EAUqpZHLrX2VZLH71Jrd9k8</p></br>
</div><!-- /col-lg-4 -->
</div>
</div>
</div>
<!-- Bootstrap core JavaScript
================================================== -->
<!-- Placed at the end of the document so the pages load faster -->
</body>
</html>