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, so for sensitive use specifically we need to take care of it.
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: use the Host OS in live mode.
-
Thanks to live mode, we are able to load the entire Host OS in RAM directly, allowing us to avoid writing anything on the system disk (no system logs, no kernel logs, no non-standard logs, only ram contents to worry about)
And since everything is loaded inside the RAM, all we need is to reboot the computer to wipe all of the RAM contents, effectively erase all forensic evidence (and all potential forensic evidence) of the existence of the hidden volume in one simple action.
Setting up Live Mode
-To do so, we need to install Kickstart's apt repository to have the grub-live package:
+Using Live Mode from the System Drive
+β οΈ Deniability Disclaimer: This setup is only suitable if the adversary can be told that you are using Kicksecure, with the ram-wipe and grub-live packages, without it being a reason to throw you in jail. Do not proceed if that's the case. β οΈ
+
+If the adversary won't put you in jail for having Kicksecure on the system drive, you can proceed to install Kickstart's apt repository to have the grub-live and ram-wipe packages:
nothing@debian-tests:~$ su -
Password:
@@ -171,6 +172,49 @@ root@debian-tests:~# reboot now
Using Live Mode from a USB Stick
+β οΈ Deniability Disclaimer: This setup is suitable if the adversary cannot be told that you are using Kicksecure, with the ram-wipe and grub-live packages, without it being a reason to throw you in jail. β οΈ
+If you are in the usecase where the adversary cannot be told that you are using kicksecure, there is an innocent way of using live mode, by using a usb stick with the debian iso flashed on it:
+
+In order to have a USB stick with a debian iso flashed on it, we're going to copy the "how to install linux" tutorial i wrote here, except that we're not going to use the netinstall debian iso file, but rather we'll use one of the "debian-live" ISOs :
+
+Then you can use dd to flash the iso on your usb stick:
+
+nihilist@mainpc:~$ lsblk
+NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
+[...]
+sdc 8:32 1 14.6G 0 disk
+ββsdc1 8:33 1 14.6G 0 part /media/nihilist/024F-D7E6
+[...]
+
+nihilist@mainpc:~$ umount /media/nihilist/024F-D7E6
+
+nihilist@mainpc:~$ sudo dd bs=4M if=debian-live-12.8.0-amd64-cinnamon.iso of=/dev/sdc status=progress oflag=sync
+3384803328 bytes (3.4 GB, 3.2 GiB) copied, 165 s, 20.5 MB/s
+810+1 records in
+810+1 records out
+3399122944 bytes (3.4 GB, 3.2 GiB) copied, 165.953 s, 20.5 MB/s
+
+
+once you have the USB stick with debian on it, simply plug it in your computer, reboot your computer, and then boot on the usb stick after entering the BIOS/UEFI:
+
+
+
+
+Next, select the usb key and then you can boot on it by choosing the "Live system" option:
+
+
+And here as you can see we successfully entered livemode by booting into debian from the usb key directly, and we are able to see the other drives that are on the computer, without writing any data on them.
+and then we will create a file in the non-system drive /dev/vdb (which contains a veracrypt hidden volume):
+and then we will create a file in the non-system drive /dev/vdb (which contains a veracrypt hidden volume):
nothing@debian-tests:~$ lsblk
@@ -226,7 +270,7 @@ this is a test file written from live mode, into a non-system drive!
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:
+Then we simply reboot into the system-drive host OS in 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:
And then we check that the first test file we created in the system drive is effectively not there anymore:
@@ -261,7 +305,8 @@ this is a test file written from live mode, into a non-system drive!
Emergency Shutdown Script
-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.
+Now in order to make sure we can shutdown the Host OS quickly and fine-tune the shutdown sequence later depending on our needs, we can setup 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.
+β οΈ Deniability Disclaimer: Proceed with the following part in the system-drive outside of live mode, only if you can afford the adversary to see that you have an emergency shutdown script. If that is not an option, you're going to have to do this part manually every time you boot into live mode. (meaning that upon rebooting, there won't be any emergency shutdown script to be found) β οΈ
First we need to make sure the user is able to run the shutdown command:
@@ -293,7 +338,66 @@ nothing@debian:~$ chmod +x shutdown.sh
And thats it! you now you have a shortcut that you can use to immediately shutdown the Host OS.
+
+
+ Emergency Shutdown Script for live USB users
+β οΈ Deniability Disclaimer: Proceed with the following part if you can't afford the adversary to find out that you have an emergency shutdown script. β οΈ
+If you are in this usecase, since you're going to have to do this setup at every bootup, you want to speed up the initial setup as much as you can, to help with that i recommend storing your sensitive use scripts on a non-KYC VPS, because that way, you only have to remember the IP of the VPS, and how to login there:
+
+nothing@debian:~$ ssh root@65.109.30.253
+root@65.109.30.253's password:
+Linux Datura 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
+
+The programs included with the Debian GNU/Linux system are free software;
+the exact distribution terms for each program are described in the
+individual files in /usr/share/doc/*/copyright.
+
+Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
+permitted by applicable law.
+Web console: https://localhost.localdomain:9090/ or https://65.109.30.253:9090/
+
+You have mail.
+Last login: Sat Nov 30 14:42:04 2024 from 91.90.40.175
+
+[ Datura ] [ /dev/pts/0 ] [~]
+β mkdir sensitive_scripts
+
+[ Datura ] [ /dev/pts/0 ] [~]
+β cd sensitive_scripts
+
+[ Datura ] [ /dev/pts/0 ] [~/sensitive_scripts]
+β vim shutdown.sh
+
+[ Datura ] [ /dev/pts/0 ] [~/sensitive_scripts]
+β cat shutdown.sh
+#!/bin/bash
+
+/sbin/shutdown -h now
+
+The idea being that you manually get your scripts from the VPS upon each boot into live mode, that way you don't need to rewrite them from scratch every time, and especially you are not storing them anywhere locally, where the adversary could find them
+To download the script you can simply run a scp command to download your scripts via SSH directly:
+
+nothing@debian:~$ scp root@65.109.30.253:/root/sensitive_scripts/shutdown.sh .
+root@65.109.30.253's password:
+shutdown.sh 100% 35 0.3KB/s 00:00
+
+nothing@debian:~$ cat shutdown.sh
+#!/bin/bash
+
+/sbin/shutdown -h now
+
+nothing@debian:~$ chmod +x shutdown.sh
+
+Now from here onwards, the setup is the as described above, you need to manually configure the shortcut to be able to use the shutdown script.
Tails OS for Temporary Sensitive Use
+Tails OS for Easy Temporary Sensitive Use
In this tutorial we're going to look at how you can run Tails OS (The Amnesic Incognito Linux System) on a USB Stick, and also on a QEMU VM, following the official documentation here.
- +β οΈ Deniability Disclaimer: This setup is only suitable if the adversary can be told that you are using Tails OS, without it being a reason to throw you in jail. Do not proceed if that's the case. β οΈ
Tails OS is suitable for Short Term Sensitive Use due to it's default live-mode feature, where upon shutting down the OS, every forensic trace of what you were doing is completely erased from memory, where the entire OS is loaded into. There are no disk-writes at all by default. (Unless if you use the persistent storage, which is not suitable for sensitive use, due to not being deniable encryption like Veracrypt ).
While it is similar to Whonix, it is specificially intended for temporary sensitive use. Whonix on the other hand can be used for long-term sensitive use. Click here for more details on the differences between Whonix and Tails.
diff --git a/opsec/tor/bridge/12.png b/opsec/tor/bridge/12.png new file mode 100644 index 0000000..35073dd Binary files /dev/null and b/opsec/tor/bridge/12.png differ diff --git a/opsec/tor/bridge/13.png b/opsec/tor/bridge/13.png new file mode 100644 index 0000000..086d90f Binary files /dev/null and b/opsec/tor/bridge/13.png differ diff --git a/opsec/tor/bridge/14.png b/opsec/tor/bridge/14.png new file mode 100644 index 0000000..ec4597e Binary files /dev/null and b/opsec/tor/bridge/14.png differ diff --git a/opsec/tor/bridge/15.png b/opsec/tor/bridge/15.png new file mode 100644 index 0000000..3ae566c Binary files /dev/null and b/opsec/tor/bridge/15.png differ diff --git a/opsec/tor/bridge/16.png b/opsec/tor/bridge/16.png new file mode 100644 index 0000000..0af0341 Binary files /dev/null and b/opsec/tor/bridge/16.png differ diff --git a/opsec/tor/bridge/17.png b/opsec/tor/bridge/17.png new file mode 100644 index 0000000..702d95a Binary files /dev/null and b/opsec/tor/bridge/17.png differ diff --git a/opsec/tor/bridge/18.png b/opsec/tor/bridge/18.png new file mode 100644 index 0000000..1a49021 Binary files /dev/null and b/opsec/tor/bridge/18.png differ diff --git a/opsec/tor/bridge/19.png b/opsec/tor/bridge/19.png new file mode 100644 index 0000000..4eee6f7 Binary files /dev/null and b/opsec/tor/bridge/19.png differ diff --git a/opsec/tor/bridge/index.html b/opsec/tor/bridge/index.html index 1110be2..72cf1ea 100644 --- a/opsec/tor/bridge/index.html +++ b/opsec/tor/bridge/index.html @@ -61,14 +61,10 @@
TOR Bridge (June 2023 update)
+TOR Bridge (November 2024 update)
Before we start, you will need a Debian VPS (you can get one on digitalocean for example), if you prefer to use your own self hosted server, make sure that port 80 and 443 are correctly port forwarded so that the public ip points to the server and not the router. Once that's done, go and ssh into your Debian server.
-Now regarding the choice of location for the server, in order to make sure that Tor remains decentralised, make sure that you are picking a country that doesn't have many tor nodes (see the bubbles graph):
-
-Disclaimer: Do not host your Tor node in Germany, Netherlands or in the US, as there are already too many nodes in those countries. Try to run your own Tor nodes in countries that have the least nodes preferably, as this will help keeping the Tor network decentralized.
- - +Then we check if it is working on check.torproject.org:
And that's it! we have been able to use our own VPS-hosted tor bridge!
+If you want to use the bridge from torrc you can do as follows:
+
+nihilist@mainpc: ~$ vim /etc/tor/torrc
+nihilist@mainpc: ~$ cat /etc/tor/torrc
+
+UseBridges 1
+ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
+Bridge obfs4 134.209.26.190:8042 829165B21621041E7A9CDF7192AFFC51CA640B0E cert=L04rcSpDJb9xdGUy/LgAlxbNgtQUWPJFsdF3q2i8lKRmzffiVFJU5ARjr4RYXRZSrsNYXg iat-mode=0
+
+nihilist@mainpc: ~$ systemctl restart tor@default
+
+Now keep in mind that obfs4 traffic simply looks like random data on the outside, it doesn't look like legit https traffic when doing deep-packet inspection. Therefore for heavily-censored countries, we recommend you use snowflake bridges:
Snowflake bridge theory
+As time goes to 2024 censorship becomes more advanced, and sometimes snowflake protocol works better than obfs4. We will go through theories and setup about snowflake bridge
+For a normal tor connection without bridge, you will:
+1.Talk to central directory
+2.Get network information
+3.Connect to your gurad nodes, and form tor circuits
+
+If tor network is blocked, you cannot talk to central directory or any tor node ip, then you need a bridge
+All of your communication goes through the bridge, including your initial talk to central directory, and your bridge automatically becomes your first tor node
+
+Bridges are usually not publicly announced for censorship resistance, since once a bridge ip get known by censoring firewall it can simply drop all the packets to that ip
+This is the weakness for traditional tor bridges, not matter how hard you try to obfuscate your traffic, the bridge ip always have to be semi-public because you want people to use it, but this means people who work for censorship can also find bridge ip
+To end this cat and mouse game, snowflake is introduced
+ +
+This is a picture of how snowflake works from tor official
+First you have volunteers over the world who install snowflake plugin in their browsers, they act as bridges for you to connect to tor network. Because this is mostly run by amateurs, and people turn on and off their devices all the time, which makes many ephemeral bridges, and this is why it is called snowflake
+There is also a server called broker that knows all the information about snowflakes
+
+Then you will use a technique called domain fronting, which makes you seems connecting to a legit service like azure cloud or google cloud, but your actual connection goes to the broker.
+
+Then the broker server introduce you to the snowflake proxy, then you establish a webrtc connection, which is a connection allows two app to have direct connection for video call or file transmission. Then your traffic goes to the snowflake proxy, and connects to the rest of tor network
+
+Then you connect to tor network!
+ +Snowflake bridge in practice
+Now in practice, all you need to do to run a snowflake bridge is to have a webpage that runs the following HTML code:
+ +Whoever wants to run a snowflake bridge simply has to click the "enabled" slider to run a snowflake bridge. Or you can also run the snowflake firefox extension to run a snowflake bridge whenever you are starting a webpage:
+
+
+
+
+
+and then you can simply wait for someone to use it. Someone that needs to evade censorship somewhere in the world will start to use it when torproject will give them the snowflake bridgelike so:
+
+
+
+If you want to use the snowflake bridge from torrc you can do as follows:
+
+nihilist@mainpc: ~$ vim /etc/tor/torrc
+nihilist@mainpc: ~$ cat /etc/tor/torrc
+
+UseBridges 1
+ClientTransportPlugin snowflake exec ./client -log snowflake.log
+
+Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ fronts=foursquare.com,github.githubassets.com ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn
+
+Bridge snowflake 192.0.2.4:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://1098762253.rsc.cdn77.org/ fronts=www.cdn77.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.net:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn
+
+Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://1098762253.rsc.cdn77.org/ fronts=www.cdn77.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn
+
+nihilist@mainpc: ~$ systemctl restart tor@default
+
+Nihilism
- Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
+ Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
How to get the Tor Browser when you are in a Heavily-censored country
+There are situations when you cannot simply download tor browser from their official site because of censorship. There are alternative methods for you to get the tor browser
+Tor browser official offers an email address called gettor@torproject.org, which you can send email to them, and they will offer you a download link
+First prepare an email, for me I am using protonmail, you can also use outlook or apple email if protonmail is blocked. Any service provider allows you to email tor project will work.
+
+Next simply send an empty email to tor project
+
+Soon you will receive a reply from tor project, simply reply them with your OS name(select one from the list)
+
+For me during this demo is linux64
+
+After the reply they will send you a download link, very ironically the download link is a google drive link, many countries that block tor also block google, they actually are supposed to send the brower bundle in attachment
+
+If you find out google drive does not work for you, try to check whether if github is accessible. Tor browser also provides download on github officially, check the releases on Tor browser github repository
+
+
+ Nihilism
- Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
+ Until there is Nothing left.
Creative Commons Zero: No Rights Reserved
First comes the clientside context: Does your country allow anonymity ?
Check if your country allows Tor traffic or not. If it's not illegal, you can use tor traffic as is. (you -> tor)
If you are in a country where tor traffic is illegal, you need to hide tor use behind a vpn (you -> vpn -> tor)
-If you are in a country where both Tor and VPNs are illegal, know that this is too risky to try and be anonymous online personally i wouldn't even try to be anonymous online in that context, because you risk being persecuted for just using the technology. If you still want to have anonymity anyway, you'll have to use censorship evasion techniques like using tor bridges. (you -> tor bridge -> tor)
+If you are in a country where both Tor and VPNs are illegal, know that this is too risky to try and be anonymous online personally i wouldn't even try to be anonymous online in that context, because you risk being persecuted for just using the technology. If you still want to have anonymity anyway, you'll have to use censorship evasion techniques like using v2ray
Second comes serverside context: Does the service allow anonymity?
Check if you can use the service using tor only,(tor -> website)
diff --git a/opsec/veracrypt/index.html b/opsec/veracrypt/index.html index bacfbbb..054110e 100644 --- a/opsec/veracrypt/index.html +++ b/opsec/veracrypt/index.html @@ -97,12 +97,61 @@ regarding wear leveling:Deniability Context
+ +β οΈ Deniability Disclaimer: If the adversary cannot be told that you are using veracrypt, do not install Veracrypt on the host OS outside of live mode, but rather install it manually each time you boot into live mode That way everytime you reboot, there is no veracrypt program to be found at all. β οΈ
Let's install the .deb package for veracrypt (you can install it safely from non-live mode), so that the software is available whenever you want to use it while the host OS is in live mode:
[ mainpc ] [ /dev/pts/1 ] [~/Downloads]
β wget https://launchpad.net/veracrypt/trunk/1.26.7/+download/veracrypt-1.26.7-Debian-12-amd64.deb
+If you are using a VPS to help speed up the initial setup everytime you boot into live mode like we have showcased previously, you can also use it to store the veracrypt .deb file for you, to make it easier to retrieve each time:
+
+[ mainpc ] [ /dev/pts/4 ] [/tmp]
+β ssh root@65.109.30.253
+root@65.109.30.253's password:
+Linux Datura 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
+
+The programs included with the Debian GNU/Linux system are free software;
+the exact distribution terms for each program are described in the
+individual files in /usr/share/doc/*/copyright.
+
+Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
+permitted by applicable law.
+Web console: https://localhost.localdomain:9090/ or https://65.109.30.253:9090/
+
+You have mail.
+Last login: Sat Nov 30 14:42:15 2024 from 91.90.40.175
+
+[ Datura ] [ /dev/pts/0 ] [~]
+β cd sensitive_scripts
+
+[ Datura ] [ /dev/pts/0 ] [~/sensitive_scripts]
+β wget https://launchpad.net/veracrypt/trunk/1.26.7/+download/veracrypt-1.26.7-Debian-12-amd64.deb -O vc.deb
+
+2024-11-30 16:43:58 (20.1 MB/s) - βvc.debβ saved [9211094/9211094]
+
+[ Datura ] [ /dev/pts/0 ] [~/sensitive_scripts]
+β exit
+Connection to 65.109.30.253 closed.
+
+That way, everytime you boot into live mode, all you need is to download the vc.deb file from the VPS:
+ +
+[ mainpc ] [ /dev/pts/4 ] [/tmp]
+β 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
+
+[ mainpc ] [ /dev/pts/4 ] [/tmp]
+β file vc.deb
+vc.deb: Debian binary package (format 2.0), with control.tar.gz, data compression gz
+
+And then to install it you can do it like so:
+
[ mainpc ] [ /dev/pts/1 ] [~/Downloads]
β sudo dpkg -i veracrypt-1.26.7-Debian-12-amd64.deb
@@ -119,10 +168,12 @@ regarding wear leveling:
[ mainpc ] [ /dev/pts/1 ] [~/Downloads]
β veracrypt
-So now that you have veracrypt installed, before you start to use it, you need to be aware of the lack of deniability you have when using the Host OS in regular mode:
-By default, your host OS directly writes into the system drive all sorts of potential forensic evidence that an adversary may use against you, such as system logs, kernel logs, non-standard logs, etc, and unless if you remove each of those manually, you're never sure of wether or not the Host OS saved proof of the existence of the hidden volume onto the system drive. That's why you need to use the Host OS in live mode, to be able to use veracrypt.
+By default, your host OS directly writes into the system drive all sorts of potential forensic evidence that an adversary may use against you, such as system logs, kernel logs, non-standard logs, etc, and unless if you remove each of those manually, you're never sure of wether or not the Host OS saved proof of the existence of the hidden volume onto the system drive. That's why you need to use the Host OS in live mode, to be able to use veracrypt, and to install it aswell if you cannot tell the adversary that you are using veracrypt.
That way, as you're loading the entire host OS in the RAM due to being in live mode, you are not writing anything on the system drive anymore, but rather only writing all that potential forensic evidence of the veracrypt hidden volume in RAM alone, which can be easily erased with a simple shutdown.
So now that we have installed veracrypt, let's reboot the Host OS into live mode: