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.
11 KiB
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:
- Intercept during handshake (before encryption) - This is what we'll do
- Compromise the server (illegal and we're not doing this)
- 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:
- Nuke connects to proxy (encrypted)
- Proxy decrypts, logs the data
- Proxy re-encrypts and forwards to Foundry
- 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.txtnuke_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):
{
"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