# Nuke Telemetry Monitoring - Troubleshooting Guide

**Tags:** #note-type/research #domain/technical #status/in-progress #priority/medium

## Issues Encountered

### Issue 1: Test 2 Can't Detect Running Nuke Process
**Symptom:** Script says "Nuke is not running" when it actually is.

**Cause:** The `pgrep -f Nuke` command isn't matching Nuke's actual process name.

### Issue 2: Test 3 Found No Startup Telemetry
**Symptom:** Packet capture during Nuke startup shows no Foundry connections.

**Possible causes:**
- Telemetry only happens on FIRST launch (cached credentials)
- Telemetry is delayed beyond capture window
- Telemetry happens during session, not at startup
- Using node-locked license (minimal phone-home)

---

## Troubleshooting Steps

### Step 1: Find Nuke's Actual Process Name

**Run this script with Nuke OPEN:**
```bash
./debug_nuke_process.sh
```

**What to look for:**
Look through the output and identify which line shows Nuke. The process name might be:
- `Nuke15.2` (version in name)
- `nuke` (lowercase)
- `/home/nicholai/Nuke15.2v6/Nuke` (full path)
- Something completely different

**Example output to look for:**
```
2. Searching all processes for 'nuke' (case-insensitive):
nicholai  867114  ... /home/nicholai/Nuke15.2v6/Nuke15.2
```

In this example, the process name would be `Nuke15.2` or the full path `/home/nicholai/Nuke15.2v6/Nuke15.2`.

**Once you find it, note the:**
- Process name (e.g., `Nuke15.2`)
- PID (e.g., `867114`)

---

### Step 2: Wide-Net Startup Capture

This captures **ALL external network traffic**, not just Foundry domains, so we can see everything Nuke connects to.

**Close Nuke completely, then run:**
```bash
./capture_startup_wide.sh
```

**Follow the prompts:**
1. Script will start packet capture
2. When prompted, launch Nuke
3. Wait for Nuke to fully load
4. Press Enter to stop capture
5. Review the analysis

**What the script shows:**
- All unique destination IPs
- All DNS lookups during startup
- Any Foundry/Honeycomb/Sentry connections
- TLS server names (HTTPS destinations)

**Interpreting results:**

**If NO Foundry traffic found:**
This is normal! It likely means:
- Telemetry already happened on first-ever launch
- Subsequent launches are silent until periodic check-in
- Explains why your 20-min capture found data (periodic heartbeat) but startup didn't

**If Foundry traffic found:**
You'll see which Foundry domains Nuke contacts at startup.

---

### Step 3: Full Session Cycle Capture

Since startup might be silent, capture an entire Nuke session from launch to close.

**Close Nuke, then run these commands:**

```bash
# Create output directory
OUTPUT_DIR="$HOME/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/full-cycle"
mkdir -p "$OUTPUT_DIR"

# Start capture (captures all external traffic)
sudo tcpdump -i any -w "$OUTPUT_DIR/full-cycle.pcap" 'not net 10.0.0.0/8 and not net 127.0.0.0/8' &

# Note the PID
TCPDUMP_PID=$!
echo "Capture running with PID: $TCPDUMP_PID"
```

**Now perform this sequence:**
1. Launch Nuke (from closed state)
2. Use Nuke normally for 5-10 minutes (open files, use tools, etc.)
3. Close Nuke completely
4. Wait 2 minutes (captures any shutdown telemetry)
5. Stop the capture:

```bash
# Stop capture
sudo kill $TCPDUMP_PID
```

**Analyze the capture:**

```bash
# If you have tshark installed:
cd "$OUTPUT_DIR"

# Show when Foundry connections happened
tshark -r full-cycle.pcap -Y "dns.qry.name contains \"foundry\" or dns.qry.name contains \"honeycomb\" or dns.qry.name contains \"sentry\"" -T fields -e frame.time -e dns.qry.name

# Show all DNS lookups with timestamps
tshark -r full-cycle.pcap -Y "dns.flags.response == 1" -T fields -e frame.time -e dns.qry.name | sort

# Count packets to Honeycomb
tshark -r full-cycle.pcap -Y "ip.dst == 52.205.16.9" | wc -l

# Count packets to learn.foundry.com
tshark -r full-cycle.pcap -Y "ip.dst == 52.50.232.31" | wc -l
```

**This tells you:**
- **When** telemetry happens (startup, during use, or shutdown)
- **How much** data is sent at each stage
- **Which services** are contacted at which times

---

### Step 4: Fix the run_gap_tests.sh Script

Once you know Nuke's actual process name from Step 1, we can fix the script.

**Example:** If the process name is `Nuke15.2`, change line in `run_gap_tests.sh`:

**From:**
```bash
NUKE_PID=$(pgrep -f Nuke)
```

**To:**
```bash
NUKE_PID=$(pgrep -f Nuke15.2)
```

Or use the full path if that's what worked:
```bash
NUKE_PID=$(pgrep -f "/home/nicholai/Nuke15.2v6/Nuke")
```

---

## Alternative: Manual strace (If Script Still Fails)

If the scripts keep failing, run strace manually:

**With Nuke running:**

```bash
# Find Nuke's PID manually
ps aux | grep -i nuke | grep -v grep

# Use the PID in strace (replace 867114 with your actual PID)
sudo strace -e trace=open,openat,read -p 867114 -o nuke_strace.log 2>&1 &
STRACE_PID=$!

# Let it run for 60 seconds while you use Nuke
sleep 60

# Stop strace
sudo kill $STRACE_PID

# Filter for system file access (use /bin/grep to avoid ripgrep alias)
/bin/grep -E '/proc|/sys|/etc' nuke_strace.log > nuke_system_access.log

# View results
less nuke_system_access.log
```

**This shows what system files/directories Nuke is reading** (the "registry" equivalent on Linux).

---

## Understanding the Results

### If Startup Capture Shows No Traffic

**This is NORMAL and EXPECTED** for subsequent launches. Here's why:

1. **First launch ever:** Nuke sends:
   - License activation
   - System information
   - User identification
   - Initial telemetry

2. **Subsequent launches:** Silent!
   - Credentials cached locally
   - No immediate phone-home needed
   - Telemetry batched for periodic transmission

3. **During session:** Periodic heartbeats
   - Your original 20-minute capture found 32KB
   - This was likely a periodic check-in, not startup telemetry

4. **Shutdown:** May send session summary
   - Duration, tools used, errors
   - Depends on implementation

### What This Means

**Your original investigation was correct:**
- Nuke DOES send telemetry (confirmed by EULA and 20-min capture)
- But it's not constant/aggressive
- Startup is silent (after first activation)
- Periodic check-ins happen during use

**The 17KB to Honeycomb likely contains:**
- Usage statistics (batched from recent sessions)
- Performance metrics
- Error reports (if any)
- License validation
- System information (encrypted)

---

## Next Steps Based on Results

### If You Want to Block Telemetry

```bash
./block_nuke_telemetry.sh
```

This blocks at the hosts file level:
- api.honeycomb.io → 127.0.0.1
- learn.foundry.com → 127.0.0.1
- sentry.foundry.com → 127.0.0.1

**Test if Nuke still works after blocking.**

### If You Want Ongoing Monitoring

**Option 1: Manual monitoring session**
```bash
./monitor_nuke_telemetry.sh
# Leave running during typical Nuke usage
# Press Ctrl+C when done
# Review logs in telemetry-logs/
```

**Option 2: Install as background service**
```bash
./monitor_nuke_telemetry_service.sh
# Runs automatically in background
# View logs: sudo journalctl -u nuke-telemetry-monitor -f
```

### If You Want to Request Your Data

**Under GDPR (EU/UK) or CCPA (California):**

Email: privacy@foundry.com

```
Subject: Data Subject Access Request - GDPR Article 15

Dear Foundry Privacy Team,

Under GDPR Article 15 (or CCPA Section 1798.100), I request:

1. All personal data you hold about me collected via Nuke telemetry
2. Categories of data collected (system info, location, usage, etc.)
3. Third parties with whom my data has been shared (Honeycomb, Sentry, resellers, etc.)
4. Purpose and legal basis for processing
5. Retention period for telemetry data

License email: [your email]
Approximate first use date: [date]

Please provide this information within 30 days as required by GDPR.

Regards,
[Your name]
```

---

## Summary of Scripts

| Script | Purpose | When to Use |
|--------|---------|-------------|
| `debug_nuke_process.sh` | Find Nuke's actual process name | When scripts can't detect Nuke running |
| `capture_startup_wide.sh` | Capture all traffic during startup | To see if startup is truly silent |
| `run_gap_tests.sh` | Automated testing suite | After fixing process detection |
| `inspect_local_data.sh` | Check local Nuke databases | To see what's cached locally |
| `monitor_nuke_telemetry.sh` | Real-time monitoring session | For ongoing observation |
| `block_nuke_telemetry.sh` | Block telemetry at hosts file | To stop all telemetry |

---

## Expected Findings

Based on investigation so far:

**✓ Confirmed:**
- Nuke sends telemetry (EULA clauses 19.2-19.3)
- api.honeycomb.io receives encrypted data (~17KB/session)
- learn.foundry.com receives unencrypted HTTP requests
- sentry.foundry.com used for crash reporting
- Periodic check-ins during use (~32KB over 20 minutes)

**✓ Likely (but can't prove without decryption):**
- Email domain transmitted
- Geographic location (from IP or explicit data)
- System/hardware information
- Usage profiling (which tools, how long)
- All data permitted by EULA is probably in encrypted payload

**✓ Observed behavior:**
- Startup is silent (after initial activation)
- Telemetry happens during session use
- Modest data volume (not excessive)
- Not constant transmission

**? Unknown:**
- Exact contents of encrypted Honeycomb payload
- Shutdown telemetry (not yet captured)
- Crash report contents (no crashes triggered)
- Full periodic check-in schedule

---

## Questions?

If you hit issues:
1. Check that scripts are executable: `ls -l *.sh`
2. Run scripts with `bash -x script.sh` to see debug output
3. Check that you have required tools: `which tcpdump tshark sqlite3`
4. Make sure sudo/root access is available for packet capture

## Files in This Project

- `CLAUDE.md` - Main project documentation
- `FOUNDRY-EULA.md` - Full EULA text with telemetry clauses
- `EULA-Analysis.md` - Detailed privacy analysis of EULA
- `nuke_foundry_analysis.md` - Original 20-minute capture analysis
- `monitoring-gaps-analysis.md` - What we're missing and why
- `TROUBLESHOOTING.md` - This file
- `block_nuke_telemetry.sh` - Block telemetry script
- `monitor_nuke_telemetry.sh` - Real-time monitoring
- `run_gap_tests.sh` - Automated test suite
- `debug_nuke_process.sh` - Process detection debugging
- `capture_startup_wide.sh` - Wide-net startup capture
- `inspect_local_data.sh` - Local database inspection