diff --git a/graphs/.$lantern.drawio.bkp b/graphs/.$lantern.drawio.bkp new file mode 100644 index 0000000..ddafe10 --- /dev/null +++ b/graphs/.$lantern.drawio.bkp @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/graphs/lantern.drawio b/graphs/lantern.drawio new file mode 100644 index 0000000..ddafe10 --- /dev/null +++ b/graphs/lantern.drawio @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/opsec/cloud_provider/index.html b/opsec/cloud_provider/index.html new file mode 100644 index 0000000..1b0ef80 --- /dev/null +++ b/opsec/cloud_provider/index.html @@ -0,0 +1,320 @@ + + + + + + + + + + + What can an hostile cloud provider see and do? + + + + + + + + + + + + + + + + + + + +
+
+
+ + The Nihilism Blog +
+
+ +
+ +
+
+ + + +
+
+
+
+ Previous Page

Mulligan Security - 21 / 01 / 2025

+

+

How safe am I from my cloud provider?

+ +Since the 2010's VPS have become cheaper and widely available. From your local mom and pop datacenter where you can rent a baremetal Pi equivalent to highly secured Amazon datacenters and on-demand cpu/bandwidth allocation you can now find a broad range of options for your operational and security needs. + +
+
+If clandestinity is a requirement, there also are cryptocurrency-based options in jurisdictions without LEO cooperation treatises with your own. + +

+ +But, what if the adversary is already inside?
+ +in this post we are going to do a threat modelling exercise:

+ +
    +
  1. Context and assumptions: what are the capabilities of our adversary? what about our own OPSEC requirments?
    2. +
  2. Threats: what the adversary might want to acomplish (their goal)
    3. +
  3. Attack Scenarii: a quick list of possible attacks
    4. +
  4. Mitigation measures: what we can do to make those attack uneconomical, harder
    5. +
+ +

+ Let's start with an image to visualize exactly what the trust and security boundaries are in such a setup +
+
+ + + +
+
+
+
+ + +
+
+
+
+

Context and assumptions

+ +

Setting up the scene

+ + Alice wishes to start hosting a coordination platform for her activist group, but she doesn't want to host the platform herself for the following reasons: + +
    +
  • Shes does not want to have incriminating data in her house
    • +
  • She is unable to provide the required level if high availability for her group's safety and operational standards
    • +
  • She has limited bandwidth/electricity to devote to her cause
    • +
+
+
+ + She gets in touch with Bob, owner and operator of Bob's friendly datacenter, and orders from him a VPS (Virtual Private Server). Bob's pretty open-minded so Alice is free to use whatever OS she wants, gets a public IP. +

+

Enters Leo

+ + One day Bob's phone rings, it's Leo calling! Leo asks Bob to confirm that he indeed has Alice as a customer. Without further ado, Leo pays Bob a visit! After entering the premises and showing a government agency badge, Leo asks for complete access to Bob's infrastructure and binds him with a gag order to make sure no one hears about his investigation. Even if Bob is sympathetic to Alice or wishes to protect his customers he would now run afoul of his country's laws if he were to warn them. Leo might have been nice to him but he is not to be trifled with... + +

Leo sets up shop

+ Commandeering an office in Bob's datacenter, Leo gets to work. He has plenty of options: + +
    +
  1. Network sniffing: Leo can capture and log ALL trafic related to Alice's activity inside Bob's datacenter, so he will know the IP of everyone interacting with her platform
    2. +
  2. Firmware/hardware attacks: during maintenance windows, Leo could tamper with the BIOS/UEFI of Alice's server (if she had chosen a bare-metal option), or with her server's storage devices in order to deactivate encryption or exfiltrate data unnoticed
    3. +
  3. Memory attacks: Leo is able to take snapshots of Alice's VPS RAM to gather information about her activities. If she had chosen a bare-metal server he could cut the power, extract and refrigerate the RAM sticks in order to retrieve the data, but such an attack would be very conspicuous
    4. +
+ + +
+
+
+
+ + +
+
+
+#
+

Alice's threat model

+ Alice is very happy with her new deployment. The platform runs great and her team has started using it in earnest. Still, the bond of implicit trust that now exists between her and Bob bothers here. She decides to do a quick threat modelling exercise to calm her mind: instead of wondering about whatifs, she is going to identify the risks associated with her current setup and find ways to mitigate them. + +

Threats to Confidentiality

+ If Bob was dishonest (or compelled into acting dishonestly), he would be able to harvest information directly from her server's memory! (She doesn't know Leo is already hard at work)

+ Impacted assets
+
    +
  • decryption keys (eg: her https private key, allowing for complete decryption of her team's traffic)
    • +
  • sensitive data (ephemeral private messages on her forum that arer only kepy in RAM in an unencrypted form)
    • +
  • software state (session cookies, metadata)
    • +
+ +

+ Bob could also use side-channel attacks by monitoring the underlying server's power usage or run cache timing attack to find the value of her cryptographic secret keys even if Bob's hardware allows her to store them in a dedicated secure chip! + +

Threats to integrity

+ Someone with Bob's level of access (he is the administrator of the hypervisor - the software that runs Alice's virtual server) could also: + +
    +
  • Run an evil maid attack: inject thir own code in the bootloader, in Alice's OS image or inside the hypervisor which Alice can't monitor
    • +
  • Through the hypervisor, tamper with Alice's virtual machine to compromise it
    • +
+ +

Threats to availability

+ + Having access to the physical layer of the network as well as the power grid feeding the servers, Bob could disrupt Alice's operations in the following way: +
    +
  • Disconnect Alice's VM from the network
    • +
  • Throttle Alice's network traffic
    • +
  • Cut the power off to Alice's host server to perform a cold boot attack
    • +
+ + +
+
+
+
+ +
+
+
+
+ +

VPS Attack scenarios

+ +

Live RAM extraction

+ +

Attack

+ Bob makes a RAM snapshot of the virtual machine. on a VPS it is very easy and can be done without notice. + +

Countermeasures

+ This one is very tricky and can't be addressed without renting a bare-metal server instead. Alice would need hardware that supports RAM encryption (such as AMD SEV and SME). + +

Malicious Libvirt or Xen Interception

+ +

Attack

+ Bob modifies the hypervisor's behavior to manipulate network, disk, or console input/output in real time. + Can inject fake SSH authentication prompts or steal plaintext database queries before they reach encrypted storage. +

Countermeasures

+ None, this would be undetectable from within the VPS. + +

Covert Persistent Backdoor via VMState Injection

+ +

Attack

+ Bob can embed custom logic in the hypervisor to modify the VPS state after every reboot, reinfecting it persistently. + Similar to NSA’s DEITYBOUNCE attack, where malware implants are injected into firmware or hypervisor layers to reinfect systems post-wipe. +

Countermeasures

+ + Hardly any, if the modification has been done directly in the kernel and in such a way that disables rootkit-detection or other security systems then it can't be detected or mitigated + +

Conclusion

+ A VPS provides no privacy from a malicious cloud provider. If used, only encrypted data should transit/be stored in it and the decryption keys should never be present anywhere accessible by it. + +
+
+
+
+ +
+
+
+
+ +

Bare Metal Attack scenarios

+ +

Live RAM extraction

+ +

Attack

+ Bob powers down the serve hosting the vps and extracts its RAM, refrigerate it to analyze its contents + +

Countermeasures

+ Alice would need hardware that supports RAM encryption (such as AMD SEV and SME). +

+ This attack is both costly and obvious as it requires the server to go offline. Alice's decides to accept the risk for now and reevaluate based on the evolving sensitivity of the data stored on her server. + +

BMC Exploitation

+

Attack

+ A malicious firmware update is deployed to the Baseboard Management Controller (BMC), providing stealthy persistent access and enabling future compromise of the OS or hypervisor. +

Countermeasures

+ This attack has the same issue as the previous one and could be deployed during a schedule maintenance at Bob's datacenter. Ensuring a TPM is present on the motheboard and only signed firmware updates are accepted is a first step. This wouldn't protect her from a malicious update signed with a legitimate key as some government agency could deploy. Another, better option is to opt for a physical enclosure only she can access in the datacenter and be present during maintenance. Such enclosure would need to be monitored and trigger a server poweroff in case of breach. + +

Evil Maid Attack

+

Attack

+ With physical access to the server, a rogue technician could inject a rootkit into the UEFI to mainain persistance, running their code before the OS loads. +

Countermeasures

+ A physically locked enclosure such as ones used by payment processors in their datacenters would greatly reduce the likelihood of this attack. + + +
+
+
+
+ + + +
+
+
+
+ +

Conclusion

+ Following her analysis, Alice understands that having a VPS gives her no privacy from her cloud provider. That all of her traffic and data can easily be seen, copied or moved. She updates her risk analysis and changes her organization's SOPS so her team can have an appropriate behavior when using the services she hosts on this platform.

+ +

Organizational mitigations

+ +
    +
  • Use of codewords when discussing operations and people
    • +
  • Use of onion services to protect the anonymity of her teammates when accessing her services
    • +
  • Use of a separate server with higher security requirements for critical data
    • +
+ + +
+
+
+
+ + + +
+
+
+
+

Nihilism

+

+ Until there is Nothing left.



Creative Commons Zero: No Rights Reserved
+ +

+
+ +
+

My Links

+

+ + RSS Feed
SimpleX Chat
+ +

+
+ +
+

About Mulligan Security

+

Donate XMR:
86NCojqYmjwim4NGZzaoLS2ozbLkMaQTnd3VVa9MdW1jVpQbseigSfiCqYGrM1c5rmZ173mrp8RmvPsvspG8jGr99yK3PSs


Contact: mulligansecurity@riseup.net
website
SimpleX

+ +
+ +
+ +
+
+ + + + + + + + diff --git a/opsec/darknetlantern/1.png b/opsec/darknetlantern/1.png index 4ed1b28..4fbb1f0 100644 Binary files a/opsec/darknetlantern/1.png and b/opsec/darknetlantern/1.png differ diff --git a/opsec/darknetlantern/13.png b/opsec/darknetlantern/13.png index b00a117..ef482e4 100644 Binary files a/opsec/darknetlantern/13.png and b/opsec/darknetlantern/13.png differ diff --git a/opsec/darknetlantern/15.png b/opsec/darknetlantern/15.png new file mode 100644 index 0000000..5afe414 Binary files /dev/null and b/opsec/darknetlantern/15.png differ diff --git a/opsec/darknetlantern/16.png b/opsec/darknetlantern/16.png new file mode 100644 index 0000000..bfc64f7 Binary files /dev/null and b/opsec/darknetlantern/16.png differ diff --git a/opsec/darknetlantern/17.png b/opsec/darknetlantern/17.png new file mode 100644 index 0000000..5f66d04 Binary files /dev/null and b/opsec/darknetlantern/17.png differ diff --git a/opsec/darknetlantern/index.html b/opsec/darknetlantern/index.html index 4a927e2..52e251b 100644 --- a/opsec/darknetlantern/index.html +++ b/opsec/darknetlantern/index.html @@ -8,7 +8,7 @@ - How to join the Darknet Lantern Webring ? + How to run your own Darknet Lantern for Visibility and Discoverability @@ -61,7 +61,7 @@
Previous Page

nihilist@Mainpc-PrivateVM-Debian12 - 2025-01-26

-

How to join the Darknet Lantern Webring ?

+

How to run your own Darknet Lantern for Visibility and Discoverability

In this tutorial we're going to first explain why the Darknet Lantern is important in the current Darknet context, we'll cover what it is made of, and then we'll cover how to spin up a Darknet Lantern instance, how to maintain one's list of onion links, and lastly we'll cover how to join the Darknet Webring.

@@ -98,16 +98,20 @@

What is the Darknet Lantern Project ?



+

The Darknet Lantern project aims to provide 3 core functionnalities:

  1. Allow you to run and maintain your own list of onion links, and make it accessible for whoever wants to access it,

  2. Allow you to automatically check the uptime of the onion links that you list, so that you can track which links are no longer active easily,

  3. Allow you to participate in a Darknet Webring so that your community may benefit from the visibility coming from the other communities that are participating in the same Webring.

-

The sourcecode for the project is available here. At first I wrote it mainly because i was largely dissatisfied with how the uptimekuma project required javascript and how Database-corruptive the upgrades were. After i nailed down the basic "uptime checker" part, it dawned on me that the webring part was also equally essential for the Darknet ecosystem, as explained above. So that's what i have been focusing on for the last 4 weeks, and now i can proudly say that the project is reaching maturity.

+

The sourcecode for the project is available here. At first I wrote it mainly because i was largely dissatisfied with how the uptimekuma project required javascript and how Database-corruptive the upgrades were. After i nailed down the basic "uptime checker" part, it dawned on me that the webring part was also equally essential for the Darknet ecosystem, as explained above. So that's what i have been focusing on for the last 4 weeks, and now i can proudly say that the project is reaching maturity.

+

The Darknet Lantern project is built using PHP, Python, and CSV files. You have the CSV files containing the onion links and their attributes, you have python scripts in the backend to automatically update the uptime of those links, including one main python script called lantern.py to manually maintain and edit your instance's csv files.

-

And lastly you have php files to search through those CSV files, and filter the results like a regular search engine. All in all, it has been built with minimalism in mind, i tried to keep it as simple as i could to meet the needs. To make it work you need a debian stable release (currently debian 12 bookworm), nginx, php8.2-fpm (currently), Tor, python3 and a few other python3 dependencies that you can install via the apt package manager.

+

And lastly you have the index.php and static.php files to search through those CSV files, and filter the results like a regular search engine. All in all, it has been built with minimalism in mind, i tried to keep it as simple as i could to meet the needs. To make it work you need a debian stable release (currently debian 12 bookworm), nginx, php8.2-fpm (currently), Tor, python3 and a few other python3 dependencies that you can install via the apt package manager.

+

This project has been built with anonymity in mind, by default, for the serverside. when you are checking the uptimes for both clearnet and darknet websites, the requests all go through Tor to prevent the website's location from being discovered.

+

This project also takes into account that malicious webring participants may show up, and therefore lantern comes with safeguards and checks in place to prevent any malicious inputs (meaning php, python or bash commands) from being ran from the csv values that may be received from other instances. The PHP files are also preventing any php code from being ran from the CSV files even if there was one to slip through the cracks.

@@ -585,6 +589,16 @@ server { index static.php; } +

You can also edit the default banner.png image for your instance if you want to customize your instance:

+ +

If you want to change it you can upload your custom banner.png image in your instance folder in /srv/darknet-lantern/www/participants/lantern.nowherejezblahblah.onion/banner.png but be careful, the python scripts are going to check if your banner has the 240x60 resolution, if it does not it won't be accepted by the other webring participants, and it will simply be replaced by the default banner image (coming from the templates folder)

+

+[ laptop-privateVM ] [ /dev/pts/8 ] [blog/opsec/darknetlantern]
+→ scp banner.png yourserver:/srv/darknet-lantern/www/participants/yourinstancename.onion/banner.png
+
+
+ +
@@ -597,19 +611,9 @@ server {

How to participate in the webring ? (WIP)



In order to participate in the webring that i am running, the only requirements i have is that your webring instance should have the core functionnalities (you list links you didn't verify yet, you also list the ones you verified, and you list the other webring participants), you should bring some new onion links i don't already have, and you shouldn't list porn links.

-

Sidenote: you are free to fork the project, and change how the front-end looks to customize it, but the CSV format (especially the columns order and their titles, and the values format) and the paths(ex: http://URL.onion/participants/URL.onion/verified.csv) need to remain the same

+

Sidenote: you are free to fork the project, and change how the front-end looks to customize it, but the CSV format (especially the columns order and their titles, and the values format) and the paths(ex: http://URL.onion/participants/URL.onion/verified.csv) those NEED to remain the same to be able to remain compatible with the other lantern instances.

-

So if you are running a functionnal lantern instance all you need is to do is show up in the Darknet Exploration simplex chatroom i'm running, and let me know that you are running a darknet lantern instance:

-

After that i'll go over your darknet lantern instance to check for the new links you are bringing to the table, and if there are no porn links in there:

-

Also one thing that you may want to edit, this is your default banner.png:

- -

If you want to change it you can upload your custom banner.png image in your instance folder in /srv/darknet-lantern/www/participants/lantern.nowherejezblahblah.onion/banner.png but be careful, the python scripts are going to check if your banner has the 240x60 resolution, if it does not it won't be accepted by the other webring participants, and it will simply be replaced by the default banner image (coming from the templates folder)

-

-[ laptop-privateVM ] [ /dev/pts/8 ] [blog/opsec/darknetlantern]
-→ scp banner.png yourserver:/srv/darknet-lantern/www/participants/yourinstancename.onion/banner.png
-
-
-

If that's OK for me, i'll add it to my darknet lantern instance by doing the following:

+

So if you are running a functionnal lantern instance, you can either send me a private message on SimpleX, or you can show up in the Darknet Lantern Simplex chatroom i'm running, and let me know that you are running a darknet lantern instance. After that i'll go and check your darknet lantern instance to check for the new links you are bringing to the table, and if there are no porn links there, i'll add it to my darknet lantern instance by doing the following:


 Select Option? (0-11): 5
 5
@@ -670,7 +674,7 @@ Name,URL,Description,Trusted,Status,Score
 → torsocks git push
-

And that's it! you are now an official member of the darknet webring :)

+

And that's it! you are now an official member of the darknet lantern webring, your community may now benefit from the visibility coming from the other webring participants' communities, while at the same time making sure that your community gets to know that those other communities exist.

diff --git a/opsec/index.html b/opsec/index.html index 64e6caf..682380d 100644 --- a/opsec/index.html +++ b/opsec/index.html @@ -175,6 +175,7 @@
  • ✅ How to use Tor Safely: (Tor + VPN combinations)
  • ✅ Why is the Darknet superior to the Clearnet ?
  • ✅ How to explore the Darknet? (Visibility and Discoverability)
    • +
  • ✅ How to run your own Darknet Lantern for Visibility and Discoverability
  • ❌ When should I use I2P instead of Tor ?

    • diff --git a/opsec/logos/dnlantern.png b/opsec/logos/dnlantern.png new file mode 100644 index 0000000..cd11f63 Binary files /dev/null and b/opsec/logos/dnlantern.png differ diff --git a/opsec/moneroinheritance/index.html b/opsec/moneroinheritance/index.html index 8e70f78..4541b27 100644 --- a/opsec/moneroinheritance/index.html +++ b/opsec/moneroinheritance/index.html @@ -95,7 +95,7 @@ Uncle Rich has worked hard his entire life and has managed to save a large amoun In order to avoid relying on third parties, we need a sovereign solution that is FOSS, self-hostable, end-to-end encrypted and that stores data in a zero-knowledge environment. Vaultwarden is the ideal candidate for this task as it is an alternative server implementation of Bitwarden that is written in Rust and is memory-safe. It is more light-weight than the full Bitwarden stack and can be easily deployed on a VPS for less than €5 per month.

    - +

    Nephew Nick will start by setting up a self-hosted instance where both Uncle Rich and him will create an account. After setting up a reliable notification system, Uncle Rich will grant Nephew Nick Emergency Access to his account, where he has his seedphrase stored. After Nephew Nick accepts Emergency Access, everything will be set in place. In the future, when Nephew Nick requests access to Uncle Rich's vault, Uncle Rich will receive a notification and have a predetermined amount of time to reject the Emergency Access request. If Uncle Rich is still alive at this point, that is trivially easy to do. If Uncle Rich is no longer with us, he will not be able to reject the Emergency Access request. As a result, after the allotted time has expired, Nephew Nick will be notified his request has been granted and will be able to access Uncle Rich's vault where the seedphrase lies. @@ -124,12 +124,12 @@ Starting from Nephew Nick's perspective:

    Prerequisites:
    -- A domain name - Nephew Nick purchased one anonymously using Monero on Njalla using their onion link. +- A domain name - Nephew Nick purchased one anonymously using Monero on Njalla using their onion link.
    -- A VPS - Nephew Nick purchased one anonymously using Monero on Kyun using their onion link. Specs consisting of 1 core and 2 GB of memory are more than enough to self-host everything needed for the setup. +- A VPS - Nephew Nick purchased one anonymously using Monero on Kyun using their onion link. Specs consisting of 1 core and 2 GB of memory are more than enough to self-host everything needed for the setup.

    - +
    Nephew Nick knows that Uncle Rich is getting quite old. Uncle Rich is still capable of using a computer but in order for this setup to work it must provide as little friction as possible. As such, we will keep things simple and use email notifications from a self-hosted server. While not overtly private, email is a suitable option in this case given its ease of use and because it is being used strictly for notifications with no sensitive information is being transmitted. Setting up a self-hosted mail server has been covered before, however, in this article we will do things a little different in line with running all of our services independently as docker containers. All publicly accessible services will be protected by SSL and we will use Traefik reverse proxy both to automatically procure wildcard SSL certificates and renew them, and also to route traffic to each respective subdomain. Let's get started.

    @@ -148,13 +148,13 @@ Nephew Nick knows that Uncle Rich is getting quite old. Uncle Rich is still capa Nephew Nick will start by setting up DNS records on Njalla (note: no trailing dot is needed). Required are A records pointing to the VPS IP address for xmronly.com, *.xmronly.com, and mail.xmronly.com. An MX record for mail.xmronly.com is also required as shown.

    - +

    Over on Kyun, Nephew Nick will set a reverse DNS to point to mail.xmronly.com.

    - +

    With this complete, Nephew Nick can test the DNS records to make sure they are set up correctly and have propagated. With the expected outputs as shown below, we're ready to move on. @@ -297,7 +297,7 @@ networks: Start the containers with docker compose -f traefik.yml up -d then navigate to https://mail.xmronly.com and verify the SSL certificate is present.

    - +

    Next we'll set up a docker-compose file (mailserver.yml) in /docker/mailserver. @@ -387,7 +387,7 @@ Content: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkifHSvSJUf3... With everything complete, your DNS should look like this:

    - +

    @@ -404,10 +404,8 @@ docker compose -f mailserver.yml up -d You can confirm everything is working correctly by configuring Thunderbird to use your mail server and sending out a test email on https://mail-tester.com.

    -

    - - -

    + +

    The last step is to set up a docker-compose file (vaultwarden.yml) in /docker/vaultwarden. @@ -463,25 +461,21 @@ Start the container with docker compose -f vaultwarden.yml up -d. With th Continuing with the same perspective, Nephew Nick will head to https://vaultwarden.xmronly.com and start by creating an account then using it to sign in.

    -

    - - -

    + +

    When prompted, Nephew Nick will verify his email address.

    -

    - - -

    + +

    With verification complete, Nephew Nick will confirm his account fingerprint phrase as this information will be needed for a future step. This is located on the sidebar under Settings -> My account.

    - +

    @@ -506,36 +500,28 @@ Switching over to Uncle Rich's perspective now: Uncle Rich will start by creating an account and then using it to sign in.

    -

    - - -

    + +

    When prompted, Uncle Rich will verify his email address.

    -

    - - -

    + +

    With verification complete, Uncle Rich can proceed to set up an entry containing his seedphrase.

    -

    - - -

    + +

    Next, Uncle Rich will add Nephew Nick as an Emergency Contact. This is found on the sidebar under Settings -> Emergency access.

    -

    - - -

    + + @@ -560,19 +546,15 @@ Switching back to Nephew Nick's perspective now: Nephew Nick receives an email notification that Uncle Rich has invited him to be an Emergency Contact. Clicking the link prompts a log in, automatically accepting the request.

    -

    - - -

    + +

    Upon signing in, there is a notification indicating that the invitation has been accepted and that Nephew Nick's identity must be confirmed (by Uncle Rich). Nephew Nick can see the status of his designation as an Emergency Contact under Settings -> Emergency access on the sidebar.

    -

    - - -

    + + @@ -597,7 +579,7 @@ Uncle Rich receives an email notification that Nephew Nick has accepted the invi

    - +

    @@ -605,8 +587,8 @@ Uncle Rich logs in and navigates to Settings -> Emergency access on the sidebar.

    - - + +

    @@ -632,7 +614,7 @@ Nephew Nick receives an email notification that he has been confirmed as an Emer

    - +

    @@ -643,9 +625,9 @@ With that, the setup is fully complete. Nephew Nick is able to request Emergency

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ --------------------------------------------------------------------------------------------------------------- Some times passes ---------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ + + [Some times passes...] +



    @@ -655,10 +637,8 @@ With that, the setup is fully complete. Nephew Nick is able to request Emergency Nephew Nick has not heard from Uncle Rich in a long time and fears the worst has happened. After signing in, he navigates to Settings -> Emergency access on the sidebar and requests Emergency Access to Uncle Rich's vault.

    -

    - - -

    + + @@ -686,7 +666,7 @@ Uncle Rich receives an email notification that Nephew Nick has requested Emergen

    - +

    @@ -694,7 +674,7 @@ After logging into his account, Uncle Rich navigates to Settings -> Emergency ac

    - +

    @@ -706,7 +686,7 @@ From Nephew Nick's perspective, he will receive an email notification saying his

    - +

    @@ -733,24 +713,22 @@ From Nephew Nick's perspective, there is nothing to do but wait for the 30 day i

    - +

    Nephew Nick signs into his account and navigates to Settings -> Emergency access. He is now able to view Uncle Rich's vault.

    -

    - - -

    + +

    And just like that Nephew Nick has received Uncle Rich's seedphrase!

    - +

    @@ -768,7 +746,7 @@ Nephew Nick opens up his Monero Wallet GUI and navigates to "Restore wallet from

    - +

    @@ -776,7 +754,7 @@ He gives the wallet a name and chooses a location to save it. Finally Nephew Nic

    - +

    @@ -784,7 +762,7 @@ Proceeding to the next screen, Nephew Nick inputs a strong password and saves it

    - +

    @@ -792,7 +770,7 @@ Finally, he selects a node for the connection. Connecting to your own node is re

    - +

    @@ -800,7 +778,7 @@ With the connection established, all that is left to do is to wait synchronizati

    - +

    @@ -808,7 +786,7 @@ Nephew Nick has successfully restored Uncle Rich's wallet using the seedphrase!

    - +

    diff --git a/opsec/qubesos/Screenshot From 2024-12-05 11-20-03.png b/opsec/qubesos/Screenshot From 2024-12-05 11-20-03.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-26-38.png b/opsec/qubesos/Screenshot From 2024-12-05 16-26-38.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-28-18.png b/opsec/qubesos/Screenshot From 2024-12-05 16-28-18.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-28-40.png b/opsec/qubesos/Screenshot From 2024-12-05 16-28-40.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-28-51.png b/opsec/qubesos/Screenshot From 2024-12-05 16-28-51.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-00.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-00.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-12.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-12.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-23.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-23.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-33.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-33.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-47.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-47.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-29-57.png b/opsec/qubesos/Screenshot From 2024-12-05 16-29-57.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-39-09.png b/opsec/qubesos/Screenshot From 2024-12-05 16-39-09.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-39-27.png b/opsec/qubesos/Screenshot From 2024-12-05 16-39-27.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-40-07.png b/opsec/qubesos/Screenshot From 2024-12-05 16-40-07.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-40-34.png b/opsec/qubesos/Screenshot From 2024-12-05 16-40-34.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 16-40-42.png b/opsec/qubesos/Screenshot From 2024-12-05 16-40-42.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 17-40-25.png b/opsec/qubesos/Screenshot From 2024-12-05 17-40-25.png old mode 100755 new mode 100644 diff --git a/opsec/qubesos/Screenshot From 2024-12-05 17-40-39.png b/opsec/qubesos/Screenshot From 2024-12-05 17-40-39.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/QubesManager.png b/opsec/qubesosnetwork/QubesManager.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/banking.png b/opsec/qubesosnetwork/banking.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/copy_destination.png b/opsec/qubesosnetwork/copy_destination.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/copy_in_vm.png b/opsec/qubesosnetwork/copy_in_vm.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/create.png b/opsec/qubesosnetwork/create.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/destination_paste.png b/opsec/qubesosnetwork/destination_paste.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/disp_whonix.png b/opsec/qubesosnetwork/disp_whonix.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/dom0_exec.png b/opsec/qubesosnetwork/dom0_exec.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/file_arrived.png b/opsec/qubesosnetwork/file_arrived.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/file_await_transfer.png b/opsec/qubesosnetwork/file_await_transfer.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/firewall-net.png b/opsec/qubesosnetwork/firewall-net.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/firewall-service.png b/opsec/qubesosnetwork/firewall-service.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/manager.png b/opsec/qubesosnetwork/manager.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/master_pasteboard.png b/opsec/qubesosnetwork/master_pasteboard.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/master_pasteboard_wiped.png b/opsec/qubesosnetwork/master_pasteboard_wiped.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/template_install.png b/opsec/qubesosnetwork/template_install.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/template_shutdown.png b/opsec/qubesosnetwork/template_shutdown.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/terminal.png b/opsec/qubesosnetwork/terminal.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/text_arrived.png b/opsec/qubesosnetwork/text_arrived.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/torrent_transmission.png b/opsec/qubesosnetwork/torrent_transmission.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/torrent_vm.png b/opsec/qubesosnetwork/torrent_vm.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/transmission_on.png b/opsec/qubesosnetwork/transmission_on.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/whonix-usage.png b/opsec/qubesosnetwork/whonix-usage.png old mode 100755 new mode 100644 diff --git a/opsec/qubesosnetwork/whonix_dread.png b/opsec/qubesosnetwork/whonix_dread.png old mode 100755 new mode 100644 diff --git a/pull.sh b/pull.sh old mode 100755 new mode 100644 diff --git a/push.sh b/push.sh old mode 100755 new mode 100644 diff --git a/pushtoprod.sh b/pushtoprod.sh old mode 100755 new mode 100644