tutorials

Some tools support delegation of services to a remote address, but sometimes they try to resolve DNS themselves using the local DNS resolver. The resolver would get an onion address and issue a DNS error because it doesn’t know how to resolve .onion, even if the machine itself is torified. You can use socat to create a local interface that binds a local port to an onion address, so that the tool won’t try to resolve the domain.

Services like Tailscale and reverse shells won’t work until you relax the firewall to allow them… …

This guide will help you create an authenticated service for managing Qubes OS remotely

By design it will be:

• Encrypted
• Authenticated (with a key)
• Over Tor
• Works behind NAT/CGNAT
• No open ports required
• Accessible from any computer with a Tor Browser / Tails / Whonix

I found a way to use GPU in your QubesOS VMs. Now cracking/rendering on Qubes might be more realistic than ever.

This is a repost of a beautiful parulin’s post with minor additions. Helpful if your phone doesn’t mount to the VMs using standard options

Here’s how to make helix-gpt work

This is how to automate and sync your backups across devices.

By using tunnels, you can forward only requests, without installing applications on the target machine

QubesOS is amazing for security, and equally amazing at making CTFs 10x harder than they need to be. It’s the firewall’s fault.

When you try to run FreeRDP 3, you will likely get the BadAtom error.

Nix is great for keeping your system clean and your sanity slightly intact. But thanks to how QubesOS handles templates and persistence, it’s not plug-and-play.

After this guide, you will be able to:

• replace apt or pacman with the nixpkgs package repository, even if you don’t care about declarativity
• use home-manager to set up all your configs and apps declaratively with just one config file and use it on any machine
• use any nixpkgs package one time only and without bloat, fix dependency hell and weird dependencies