moved random shit to documentation folder
This commit is contained in:
parent
11c6849d4a
commit
1ba71a2a14
@ -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
|
||||
132
docs/quick-start.md
Normal file
132
docs/quick-start.md
Normal file
@ -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!**
|
||||
Loading…
x
Reference in New Issue
Block a user