<p>The main usecase of using your Host OS in live mode, is that you want to use it for long term sensitive activities (meaning, you want to save sensitive files on a harddrive). <b>As you're going to see, using the Host OS in live mode is effectively a hard requirement for deniability</b>.</p>
<p>When we are talking sensitive use, we are talking about our need of Deniability. Which means that we need to use deniable encryption using <ahref="../veracrypt/index.html">Veracrypt's hidden volumes</a>:</p>
<imgsrc="../deniability/5.png"class="imgRz">
<p>In theory it is impossible to prove the existence of the hidden volume by itself once it is closed, <b>and if there is no proof of it's existence our deniability is maintained.</b></p>
<p>But the issue is that we have more variables that we also need to keep under control, on the Host OS side you have <b>system logs, kernel logs</b>, the various other <b>non-standard log files</b> that software is writing on the disk, and even <b>the content of the RAM itself</b> can be used to prove the existence of a hidden volume.</p>
<imgsrc="3.png"class="imgRz">
<p>Now when you are using your computer for regular public, private and anonymous activities, normally you don't need to care about those things. But the Host OS is a potential goldmine of forensic evidence to be used against you, <b>so for sensitive use specifically we need to take care of it.</b></p>
<p>Now you could start to manually erase all logs, all kernel logs, all non-standard system logs, manually overwrite the RAM contents, but this is going to be way too tedious and you're likely to miss something. So we have one simple solution: <b>use the Host OS in live mode</b>.</p>
<imgsrc="4.png"class="imgRz">
<p>Thanks to live mode, <b>we are able to load the entire Host OS in RAM directly</b>, allowing us to avoid writing anything on the system disk (no system logs, no kernel logs, no non-standard logs, <b>only ram contents to worry about</b>)</p>
<p>And since everything is loaded inside the RAM, <b>all we need is to reboot the computer to wipe all of the RAM contents</b>, effectively <b>erase all forensic evidence (and all potential forensic evidence) of the existence of the hidden volume in one simple action.</b></p>
<p>Then we install the grub-live package, and the ram-wipe package <b>(warning, the ram-wipe package may cause your system to fail to boot in case if you encrypted the system drive using LUKS, click <ahref="https://www.kicksecure.com/wiki/Ram-wipe">here</a> for more details on this)</b>. Therefore i recommend having the <ahref="../linux/index.html">Host OS</a> system drive not encrypted until dracut supports LUKS encryption, but it shouldn't matter though, as the actual VMs that we'll be running will be on a non-system drive, which will be manually kept in <ahref="../veracrypt/index.html">deniable encryption</a>.</p>
<p>As you can see here, we are not yet in live mode, so you can see the vda1 system drive mounted in the root directory, meaning that by default everything that is written on the disk by the Host OS is actually being written into the disk, rather than the RAM. So let's reboot to get into live mode:</p>
<p>Here you can see that we have the <b>/dev/vda1 system drive</b> mounted under the <b>/run/live</b> and <b>/usr/lib/live</b> directories, so basically now everything that is normally being written into the system disk (like system logs, kernel logs, non-standard logs, and every other file) <b>is instead being written into the RAM, and not writing on the system disk at all.</b></p>
<p>To test this, we'll create a file in the system drive:</p>
<p>Then we simply reboot the host OS into regular non-live mode to check if our first test file on the system drive is gone, and if the second test file on the non-system drive has been effectively saved:</p>
<imgsrc="2.png"class="imgRz">
<p>And then we check that the first test file we created in the system drive is effectively not there anymore:</p>
this is a test file written from live mode, into a non-system drive!
</code></pre>
<p>And that's it ! we have now validated that running the Host OS in live mode could protect our veracrypt hidden volume's existence from being proven, protecting our deniability. </p>
<p>Now in order to make sure we can shutdown the Host OS quickly, we need to have an emergency shutdown script, that can be ran by a non-root user in order to immediately shutdown the Host OS whenever we need it.</p>
<p>First we need to make sure the user is able to run the shutdown command:</p>
<pre><codeclass="nim">
nothing@debian:~$ su -
Password:
root@debian:~# visudo
[...]
nothing ALL=NOPASSWD:/sbin/shutdown
nothing ALL=NOPASSWD:/sbin/reboot
[...]
</pre></code>
<p>Then we create a simple shutdown.sh script:</p>
<pre><codeclass="nim">
nothing@debian:~$ vim shutdown.sh
nothing@debian:~$ cat shutdown.sh
#!/bin/bash
/sbin/shutdown -h now
nothing@debian:~$ chmod +x shutdown.sh
</pre></code>
<p>Then, you need to hook it up to a shortcut, such as <b>Super+R</b>, i'm going to do it in Cinnamon as this is the Desktop Environment i use:</p>
<imgsrc="5.png"class="imgRz">
<imgsrc="6.png"class="imgRz">
<p>And thats it! you now you have a shortcut that you can use to immediately shutdown the Host OS.</p>
Until there is Nothing left.</p></br></br><p>Creative Commons Zero: <ahref="../../../../opsec/runtheblog/index.html">No Rights Reserved</a></br><imgsrc="\CC0.png">
