block-nuke-telemetry/INTERCEPTING-HTTPS.md
Nicholai 6fada7889a Initial public release - Nuke telemetry monitoring toolkit
This toolkit provides comprehensive monitoring, analysis, and blocking capabilities
for network telemetry sent by The Foundry's Nuke compositor on Linux.

Key features:
- Network monitoring scripts with automated alerts
- Multi-tier blocking methods (hosts, firewall, namespace, AppArmor)
- Detailed packet capture analysis and documentation
- EULA legal analysis and privacy assessment
- Sanitized example captures and comprehensive guides

All sensitive data (personal IPs, usernames, packet captures) removed.
Ready for public sharing on Gitea.
2025-11-26 15:28:21 -07:00

11 KiB

Intercepting and Decrypting Your Own HTTPS Traffic

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)

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:

sudo pacman -S mitmproxy

Step 1: Start mitmproxy

# Start in transparent mode
sudo mitmproxy --mode transparent --showhost -w nuke_traffic.mitm

Or use the web interface:

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:

#!/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:

# 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

# 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

# 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

# Install from AUR
yay -S sslkeylog-git
# or build from source: https://github.com/adulau/sslkeylog

Step 2: Use LD_PRELOAD to capture keys

# 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

sudo tcpdump -i any -w nuke_for_decrypt.pcap 'host honeycomb.io or host foundry.com'

Step 4: Decrypt with Wireshark

# 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

sudo pacman -S frida frida-tools

Step 2: Create hooking script

Create hook_nuke_ssl.js:

// 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

# 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

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.


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):

{
  "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