diff --git a/INTERCEPTING-HTTPS.md b/INTERCEPTING-HTTPS.md deleted file mode 100644 index c394709..0000000 --- a/INTERCEPTING-HTTPS.md +++ /dev/null @@ -1,420 +0,0 @@ -# Intercepting and Decrypting Your Own HTTPS Traffic - -## Important Legal and Technical Notice - -**What this document covers:** -- ✅ Inspecting YOUR OWN traffic from YOUR OWN software on YOUR OWN computer -- ✅ Legally and technically sound methods using SSL/TLS interception -- ✅ Educational purposes for privacy research -- ✅ Complementing the master investigation in [[Foudry-Nuke-Monitoring#Executive Summary]] - -**What this does NOT do:** -- ❌ Brute-force decrypt HTTPS (not possible with modern encryption) -- ❌ Intercept other people's traffic (illegal) -- ❌ Break into Foundry's servers (illegal) - -**Legal basis:** You have the right to inspect data YOUR software sends from YOUR computer. - ---- - -## Why You Can't Brute Force HTTPS - -**Technical reality:** -- Modern TLS uses 2048-4096 bit RSA or 256-bit ECC keys -- Brute-forcing would take **billions of years** with current hardware -- Even nation-states with supercomputers cannot brute-force TLS -- Quantum computers (not yet practical) would still take months/years - -**The only way to decrypt HTTPS is:** -1. **Intercept during handshake** (before encryption) - This is what we'll do -2. **Compromise the server** (illegal and we're not doing this) -3. **Extract keys from memory** (requires root access to Nuke process - possible but advanced) - ---- - -## Method 1: SSL/TLS Interception Proxy (Recommended) - -For master timeline context see [[Foudry-Nuke-Monitoring#Phase-4-Gap-Analysis-and-Troubleshooting]]. - -### How It Works - -``` -Nuke → Your Proxy → Foundry Servers - ↓ - Decrypted logs -``` - -Your proxy acts as a "man-in-the-middle" between Nuke and Foundry: -1. Nuke connects to proxy (encrypted) -2. Proxy decrypts, logs the data -3. Proxy re-encrypts and forwards to Foundry -4. You get plaintext logs of what Nuke sent - -**This works because:** -- You control both endpoints (Nuke and the proxy) -- Nuke is configured to trust your proxy's certificate -- It's YOUR traffic on YOUR machine - -### Tool: mitmproxy - -See [[Foudry-Nuke-Monitoring#Monitoring-Infrastructure-Setup]] for complementary automation scripts. - -**Install mitmproxy:** -```bash -sudo pacman -S mitmproxy -``` - -**Step 1: Start mitmproxy** -```bash -# Start in transparent mode -sudo mitmproxy --mode transparent --showhost -w nuke_traffic.mitm -``` - -Or use the web interface: -```bash -sudo mitmweb --mode transparent --showhost -# Opens browser at http://127.0.0.1:8081 -``` - -**Step 2: Configure iptables to redirect traffic** - -Create a script to redirect Foundry traffic through the proxy: - -```bash -#!/bin/bash -# redirect_to_proxy.sh - -# Redirect traffic to Honeycomb through mitmproxy -sudo iptables -t nat -A OUTPUT -p tcp -d 52.205.16.9 --dport 443 -j REDIRECT --to-port 8080 - -# Redirect traffic to learn.foundry.com -sudo iptables -t nat -A OUTPUT -p tcp -d 52.50.232.31 --dport 443 -j REDIRECT --to-port 8080 - -# Redirect any other foundry.com traffic -sudo iptables -t nat -A OUTPUT -p tcp -d foundry.com --dport 443 -j REDIRECT --to-port 8080 - -echo "Traffic redirected to mitmproxy on port 8080" -echo "To undo: sudo iptables -t nat -F" -``` - -**Step 3: Install mitmproxy certificate in Nuke** - -Nuke needs to trust the mitmproxy certificate: - -```bash -# Start mitmproxy to generate certificate -mitmproxy & -sleep 2 -killall mitmproxy - -# Certificate is at ~/.mitmproxy/mitmproxy-ca-cert.pem -# Copy to system trust store -sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /etc/ca-certificates/trust-source/anchors/mitmproxy.crt -sudo trust extract-compat -``` - -**Step 4: Launch Nuke and capture traffic** - -```bash -# Start mitmproxy with logging -mitmweb --mode transparent --showhost -w ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).mitm - -# In another terminal: redirect traffic -./redirect_to_proxy.sh - -# Launch Nuke and use normally - -# When done, restore iptables -sudo iptables -t nat -F -``` - -**Step 5: View captured traffic** - -```bash -# Replay captured session -mitmproxy -r nuke_decrypted_*.mitm - -# Export to JSON for analysis -mitmdump -r nuke_decrypted_*.mitm -w nuke_traffic.json - -# Or use the web interface to browse requests/responses -``` - -**What you'll see:** -- Full HTTP headers (User-Agent, API keys if any) -- Complete request/response bodies (JSON telemetry data) -- Timing information -- All the data Nuke sends to Honeycomb/Sentry - ---- - -## Method 2: Extract TLS Keys from Nuke Process - -Background on why this matters: [[Foudry-Nuke-Monitoring#Data-We-Cannot-See-Encrypted]]. - -### How It Works - -When Nuke establishes TLS connections, the encryption keys exist briefly in memory. We can extract them and use them to decrypt packet captures. - -**This is ADVANCED and may not work if Nuke uses certificate pinning.** - -### Tool: sslkeylog - -**Step 1: Install sslkeylog** - -```bash -# Install from AUR -yay -S sslkeylog-git -# or build from source: https://github.com/adulau/sslkeylog -``` - -**Step 2: Use LD_PRELOAD to capture keys** - -```bash -# Set environment variable to log keys -export SSLKEYLOGFILE=~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log - -# Launch Nuke with LD_PRELOAD -LD_PRELOAD=/usr/lib/libsslkeylog.so /path/to/Nuke15.2v6/Nuke - -# Or if Nuke is already running, inject into process (requires root): -sudo gdb -p $(pgrep -f Nuke) -batch -ex "call setenv(\"SSLKEYLOGFILE\", \"$SSLKEYLOGFILE\", 1)" -``` - -**Step 3: Capture traffic while Nuke runs** - -```bash -sudo tcpdump -i any -w nuke_for_decrypt.pcap 'host honeycomb.io or host foundry.com' -``` - -**Step 4: Decrypt with Wireshark** - -```bash -# Open in Wireshark -wireshark nuke_for_decrypt.pcap - -# Configure to use key log: -# Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename -# Browse to ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log - -# Wireshark will now decrypt all TLS traffic! -``` - -**What you'll see:** -- Decrypted HTTP/2 or HTTP/1.1 requests -- Full JSON payloads sent to Honeycomb -- API calls to Sentry -- All telemetry data in plaintext - ---- - -## Method 3: HTTP Library Hooking (Most Reliable) - -See also [[Foudry-Nuke-Monitoring#Technical-Architecture]] for service overview. - -### How It Works - -Hook into the SSL/HTTP libraries Nuke uses to log traffic BEFORE encryption. - -**This intercepts at the application layer, so it works even with certificate pinning.** - -### Tool: frida (Dynamic instrumentation) - -**Step 1: Install frida** - -```bash -sudo pacman -S frida frida-tools -``` - -**Step 2: Create hooking script** - -Create `hook_nuke_ssl.js`: - -```javascript -// Hook OpenSSL SSL_write to log data BEFORE encryption -Interceptor.attach(Module.findExportByName(null, "SSL_write"), { - onEnter: function(args) { - var ssl = args[0]; - var buf = args[1]; - var len = args[2].toInt32(); - - // Read the buffer contents - var data = Memory.readByteArray(buf, len); - - // Try to parse as UTF-8 - try { - var str = Memory.readUtf8String(buf, len); - console.log("\n[SSL_write] Sending " + len + " bytes:"); - console.log(str); - } catch(e) { - console.log("\n[SSL_write] Sending " + len + " bytes (binary data)"); - console.log(hexdump(data, { ansi: true })); - } - - // Log to file - var file = new File("/tmp/nuke_ssl_log.txt", "a"); - file.write(str + "\n---\n"); - file.close(); - } -}); - -// Hook SSL_read to log received data AFTER decryption -Interceptor.attach(Module.findExportByName(null, "SSL_read"), { - onLeave: function(retval) { - if(retval.toInt32() > 0) { - var len = retval.toInt32(); - var buf = this.context.rsi; // Second argument (buffer) - - try { - var str = Memory.readUtf8String(ptr(buf), len); - console.log("\n[SSL_read] Received " + len + " bytes:"); - console.log(str); - } catch(e) { - console.log("\n[SSL_read] Received " + len + " bytes (binary)"); - } - } - } -}); - -console.log("[*] SSL hooks installed. Monitoring Nuke SSL traffic..."); -``` - -**Step 3: Attach to Nuke process** - -```bash -# Find Nuke PID -NUKE_PID=$(pgrep -f Nuke) - -# Attach frida -frida -p $NUKE_PID -l hook_nuke_ssl.js -o nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).log -``` - -**Step 4: Use Nuke normally** - -All SSL/TLS traffic will be logged in plaintext to: -- Console output -- `/tmp/nuke_ssl_log.txt` -- `nuke_decrypted_*.log` - -**What you'll see:** -- Exact JSON payloads sent to Honeycomb -- HTTP headers (User-Agent, Authorization, API keys) -- Sentry crash report contents -- ALL telemetry data before encryption - ---- - -## Method 4: Patch Nuke Binary (ADVANCED - NOT RECOMMENDED) - -**This involves modifying Nuke's executable to disable certificate pinning or add logging. This is complex, may violate EULA, and can break Nuke.** - -**Only mention for completeness - NOT recommended.** - ---- - -## Recommended Approach - -Cross-reference: [[Foudry-Nuke-Monitoring#Recommendations]]. - -**I recommend Method 1 (mitmproxy) or Method 3 (frida) depending on your technical comfort:** - -| Method | Difficulty | Reliability | Notes | -|--------|-----------|-------------|-------| -| mitmproxy | Medium | Good | May fail if Nuke uses certificate pinning | -| sslkeylog | Hard | Medium | Requires LD_PRELOAD or GDB injection | -| frida | Medium-Hard | Excellent | Works even with certificate pinning | - -**Start with mitmproxy.** If Nuke rejects the certificate (connection errors), fall back to frida. - ---- - -## What You'll Discover - -Once you decrypt the traffic, you'll see the **exact contents** of the 17KB Honeycomb payload, including: - -**Likely contents (based on EULA and typical telemetry):** -```json -{ - "telemetry_version": "1.0", - "timestamp": "2025-10-25T12:34:56Z", - "session_id": "abc123...", - - "user": { - "license_id": "...", - "license_type": "commercial", - "email_domain": "example.com", - "user_id": "hashed_id" - }, - - "system": { - "os": "Linux", - "os_version": "6.17.4-arch2-1", - "cpu": "AMD Ryzen ...", - "gpu": "NVIDIA RTX ...", - "ram_gb": 64, - "disk_space_gb": 2048, - "locale": "en_US", - "timezone": "America/Los_Angeles" - }, - - "location": { - "country": "US", - "region": "California", - "city": "Los Angeles", - "ip_hash": "hashed_ip" - }, - - "software": { - "nuke_version": "15.2v6", - "plugins": ["Cryptomatte", "OpticalFlares", ...], - "python_version": "3.9.2" - }, - - "usage": { - "session_start": "2025-10-25T12:00:00Z", - "session_duration_seconds": 7200, - "nodes_created": { - "Read": 45, - "Write": 12, - "Merge": 23, - "Grade": 15, - ... - }, - "tools_used": ["Viewer", "Curve Editor", "Node Graph"], - "render_count": 5, - "render_frames_total": 240, - "scripts_executed": 12 - }, - - "performance": { - "average_fps": 24.5, - "peak_memory_mb": 8192, - "crash_count": 0, - "error_count": 3 - }, - - "errors": [ - { - "type": "FileNotFound", - "message": "Could not load /path/to/missing_file.exr", - "timestamp": "2025-10-25T13:45:12Z" - } - ] -} -``` - -**This will definitively answer:** -- ✅ Is email domain transmitted? (Yes/No + exact field) -- ✅ Is geographic location sent? (Yes/No + granularity) -- ✅ What system info is collected? (Exact fields) -- ✅ What usage data is tracked? (Which features, how often) -- ✅ Are file paths included? (Privacy concern if yes) - -For broader context on unanswered questions, see [[Foudry-Nuke-Monitoring#Gap-Analysis-and-Troubleshooting]]. - ---- - -## Automated Decryption Script - -I'll create a wrapper script that tries mitmproxy first, falls back to frida if needed: -} need ensure anchor correct; actual section \ No newline at end of file diff --git a/Advanced-Blocking-Methods.md b/docs/analysis/Advanced-Blocking-Methods.md similarity index 100% rename from Advanced-Blocking-Methods.md rename to docs/analysis/Advanced-Blocking-Methods.md diff --git a/Foudry-Nuke-Monitoring.md b/docs/analysis/Foudry-Nuke-Monitoring.md similarity index 100% rename from Foudry-Nuke-Monitoring.md rename to docs/analysis/Foudry-Nuke-Monitoring.md diff --git a/TROUBLESHOOTING.md b/docs/analysis/TROUBLESHOOTING.md similarity index 100% rename from TROUBLESHOOTING.md rename to docs/analysis/TROUBLESHOOTING.md diff --git a/monitoring-gaps-analysis.md b/docs/analysis/monitoring-gaps-analysis.md similarity index 100% rename from monitoring-gaps-analysis.md rename to docs/analysis/monitoring-gaps-analysis.md diff --git a/nuke_foundry_analysis.md b/docs/analysis/nuke_foundry_analysis.md similarity index 100% rename from nuke_foundry_analysis.md rename to docs/analysis/nuke_foundry_analysis.md diff --git a/Application_Behavior_Analysis.md b/docs/help/Application_Behavior_Analysis.md similarity index 100% rename from Application_Behavior_Analysis.md rename to docs/help/Application_Behavior_Analysis.md diff --git a/EULA-Analysis.md b/docs/legal/EULA-Analysis.md similarity index 100% rename from EULA-Analysis.md rename to docs/legal/EULA-Analysis.md diff --git a/FOUNDRY-EULA.md b/docs/legal/FOUNDRY-EULA.md similarity index 100% rename from FOUNDRY-EULA.md rename to docs/legal/FOUNDRY-EULA.md diff --git a/docs/quick-start.md b/docs/quick-start.md new file mode 100644 index 0000000..9779980 --- /dev/null +++ b/docs/quick-start.md @@ -0,0 +1,132 @@ +# Quick Start Guide for Nuke Telemetry Blocking + +> This guide walks a beginner through installing the required tools, running the monitoring scripts, and blocking telemetry from The Foundry’s **Nuke** compositor. All commands are written for an Arch‑Linux system. + +--- + +## 1. Prerequisites + +| Package | Purpose | +|---------|---------| +| `tcpdump` | Capture packets for analysis | +| `iptables` / `nftables` | Firewall rules used by the scripts | +| `notify-send` (optional) | Desktop notifications from the monitor script | +| `curl`, `nslookup` | Verify that blocks are working | + +Install them with pacman: + +```bash +sudo pacman -S --needed tcpdump iptables nftables libnotify curl nslookup +``` + +> The scripts ship with a **--help** flag – run any script with `-h` to see its options. + +--- + +## 2. Quick Reference Table + +| Script | What it does | Typical command | +|--------|--------------|----------------| +| `scripts/firewall_block_nuke.sh` | Adds kernel‑level rules that reject outbound connections to Foundry telemetry IPs. | `sudo bash scripts/firewall_block_nuke.sh` +| `block_nuke_telemetry.sh` | Modifies `/etc/hosts` so the domains resolve to 127.0.0.1. | `bash block_nuke_telemetry.sh` +| `scripts/monitor_nuke_network.sh` | Continuously watches Nuke processes and logs any external connections. | `bash scripts/monitor_nuke_network.sh --continuous` +| `scripts/dns_sinkhole_config.sh` | Generates configuration snippets for Pi‑Hole / dnsmasq that block Foundry domains. | `bash scripts/dns_sinkhole_config.sh` + +--- + +## 3. Installation & Setup + +1. **Clone the repository** (if you haven’t already): + ```bash + git clone https://github.com/your-org/block-nuke-telemetry.git + cd block-nuke-telemetry + ``` +2. **Make scripts executable** – they should already be, but just in case: + ```bash + chmod +x *.sh scripts/*.sh + ``` +3. **Run the firewall blocker (recommended first step)**: + ```bash + sudo bash scripts/firewall_block_nuke.sh + ``` + > This writes rules to `/etc/iptables/iptables.rules` or `/etc/nftables.conf`. Use `--status` to verify. +4. **Apply the hosts‑file block** (optional but adds a second layer): + ```bash + bash block_nuke_telemetry.sh + ``` +5. **(Optional) Generate DNS sinkhole configs** if you run Pi‑Hole or dnsmasq: + ```bash + bash scripts/dns_sinkhole_config.sh > ~/pi-hole-dns.conf + ``` + Then add the generated lines to your DNS server. + +--- + +## 4. Basic Usage + +### 4.1 Monitoring Nuke in Real Time + +```bash +# Run in a terminal; press Ctrl+C to stop +bash scripts/monitor_nuke_network.sh --continuous +``` +The script prints lines like: + +``` +[2025-11-27 14:32:10] ALERT: Nuke process (PID 867114) connected to api.honeycomb.io:443 +``` +It also writes a log file `nuke_telemetry_alerts.log` that can be tail‑viewed. + +### 4.2 Capturing Packets for Investigation + +If you want to capture traffic yourself, use the following command (you may need sudo): + +```bash +sudo tcpdump -i any -w nuke_foundry_capture.pcap 'host api.honeycomb.io or host learn.foundry.com' +``` +Stop with `Ctrl+C` and analyze later. + +### 4.3 Verifying the Blocks + +After applying firewall/hosts rules, confirm that DNS resolves to localhost and that connections fail: + +```bash +# DNS resolution should return 127.0.0.1 +nslookup api.honeycomb.io +# Connection attempt should timeout or be refused +curl -I https://api.honeycomb.io --max-time 5 +``` +You should see `Connection timed out` or a refusal. + +--- + +## 5. Troubleshooting Common Issues + +| Symptom | Likely Cause | Fix | +|---------|--------------|-----| +| Help menu in Nuke doesn’t load | `learn.foundry.com` is blocked | Temporarily comment out the hosts‑file entry or use a VPN that bypasses DNS filtering | +| Crash reports are not sent | Sentry domain blocked | Keep the hosts block but allow `sentry.foundry.com` if you need support | +| Nuke fails to start | Firewall rule accidentally blocks localhost | Ensure rules only target external IPs. Check with `sudo iptables -L OUTPUT -v -n`. | +| +--- + +## 6. Further Reading + +* **Advanced Blocking Methods** – detailed explanation of each technique: [Advanced‑Blocking‑Methods.md](../analysis/Advanced-Blocking-Methods.md) +* **Packet Capture Analysis** – the raw 20‑minute capture and findings: [nuke_foundry_analysis.md](../analysis/nuke_foundry_analysis.md) +* **Full Investigation Report** – legal, privacy, and mitigation summary: [Foudry-Nuke-Monitoring.md](../analysis/Foudry-Nuke-Monitoring.md) + +--- + +## 7. Appendix – Quick‑Start Script Flags + +| Flag | Meaning | +|------|---------| +| `--continuous` | Keep the monitor running until stopped with Ctrl+C | +| `--status` | Show current firewall rule status | +| `--restore` | Remove firewall rules added by `firewall_block_nuke.sh` | +| `-h`, `--help` | Display usage information | + +--- + +**Enjoy a privacy‑respectful Nuke workflow!** \ No newline at end of file