Nicholai/block-nuke-telemetry
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
block-nuke-telemetry/docs/analysis/TROUBLESHOOTING.md

10 KiB
Raw Blame History

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:

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

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

# 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:
# Stop capture
sudo kill $TCPDUMP_PID

Analyze the capture:

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

NUKE_PID=$(pgrep -f Nuke)

To:

NUKE_PID=$(pgrep -f Nuke15.2)

Or use the full path if that's what worked:

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:

# 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

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

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

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