block-nuke-telemetry/docs/analysis/monitoring-gaps-analysis.md

Monitoring Gaps Analysis

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

What We Captured

• Duration: ~20 minutes
• Nuke state: Already running, normal use
• Connections observed:
  • api.honeycomb.io (17KB HTTPS - encrypted)
  • learn.foundry.com (HEAD requests HTTP - unencrypted)
  • crashpad_handler process (found but not active)

What We Likely Missed

1. Startup Telemetry (HIGH PRIORITY)

What could be sent:

• Initial system scan (registry, hardware, OS)
• License validation and user identification
• Geographic location determination (IP geolocation)
• Email domain from license credentials
• Software environment enumeration

Why we missed it:

• Nuke was already running when we started monitoring
• Startup telemetry likely happens during Nuke launch

How to capture:

# Start monitoring BEFORE launching Nuke
sudo tcpdump -i any -w nuke_startup.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
sleep 2
# NOW launch Nuke
# Wait for it to fully load
# Stop capture

2. Shutdown Telemetry (HIGH PRIORITY)

What could be sent:

• Session summary (duration, tools used, errors)
• Final usage statistics
• Cached telemetry that wasn't sent during session
• License check-out confirmation

Why we missed it:

• We didn't capture Nuke closing
• Shutdown often triggers "flush" of cached data

How to capture:

# While Nuke is running, start capture
sudo tcpdump -i any -w nuke_shutdown.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Close Nuke normally
# Wait 30 seconds after Nuke closes
# Stop capture

3. Crash Reporting (MEDIUM PRIORITY)

What could be sent:

• Memory dumps (could include project data!)
• Stack traces
• System state at crash time
• User information
• Active projects/files

Why we missed it:

• No crashes occurred during monitoring
• crashpad_handler was idle

How to capture:

# Start capture
sudo tcpdump -i any -w nuke_crash.pcap 'host sentry.foundry.com' &
# Force kill Nuke to simulate crash
kill -9 $(pgrep -f Nuke)
# Wait 60 seconds (crash report upload)
# Stop capture

4. Periodic Check-ins (MEDIUM PRIORITY)

What could be sent:

• Heartbeat signals
• License validation pings
• Usage statistics batched from previous sessions
• Update checks

Why we missed it:

• 20 minutes might not cover the full interval
• Common intervals: 15min, 30min, 1hr, 4hr, 24hr

How to capture:

# Run monitoring for extended period
./monitor_nuke_telemetry.sh
# Leave Nuke idle for 4+ hours
# Check logs for periodic patterns

5. Specific Event Triggers (LOW-MEDIUM PRIORITY)

Events that might trigger telemetry:

Help Menu Usage:

• Accessing online documentation
• Checking for updates
• Viewing learning resources

Rendering:

• Large render jobs might report performance metrics
• Could include project complexity data

Plugin/Script Usage:

• Third-party plugin loads
• Python script execution
• Gizmo usage

License Events:

• License checkout/checkin (floating licenses)
• Seat availability checks
• License server connections

Project Operations:

• Opening certain project types
• Using specific nodes/features
• Render farm submissions

How to capture:

# Monitor while performing specific actions
sudo tcpdump -i any -w nuke_events.pcap 'host foundry.com or host honeycomb.io' &
# In Nuke:
# - Check for updates (Help menu)
# - Access online help
# - Render a complex scene
# - Use various nodes/tools
# Stop capture

3. Methodology Gaps

Gap A: Local Data Collection

The problem:

• System registry access happens LOCALLY
• Data collection ≠ data transmission
• Could be cached and sent later

Evidence of local caching: From earlier investigation:

~/Documents/nuke/15.2.375648/sentry-db/

How to investigate:

# Check what's in those Sentry database files
ls -lah ~/Documents/nuke/15.2.375648/sentry-db/
file ~/Documents/nuke/15.2.375648/sentry-db/*

# Monitor file changes during Nuke use
inotifywait -m ~/Documents/nuke/15.2.375648/sentry-db/

# Check for other telemetry databases
find ~/Documents/nuke ~/.nuke ~/.cache -name "*.db" -o -name "*.sqlite" -o -name "*telemetry*" -o -name "*analytics*"

Gap B: DNS-Based Identification

The problem:

• Geographic location can be determined from DNS queries
• Doesn't require sending location data explicitly
• Foundry sees your IP address in connection logs

What Foundry already knows from network metadata:

• Your public IP address (from all connections)
• Geographic location (IP geolocation databases)
• ISP information
• Approximate physical location

This is unavoidable unless you use VPN/proxy

Gap C: Different Protocols/Ports

What we monitored:

• TCP connections to known Foundry domains
• Ports 80, 443 (HTTP/HTTPS)

What we might have missed:

• UDP traffic (less common but possible)
• Different ports (custom license servers, etc.)
• DNS queries themselves (can leak info)
• IPv6 connections (if using dual-stack)

How to capture everything:

# Capture ALL external traffic (not filtered)
sudo tcpdump -i any -w nuke_full.pcap 'not net 10.0.0.0/8 and not net 127.0.0.0/8'
# Much larger file, but catches everything

Gap D: System Registry Access

The problem:

• On Linux, "registry" means different things
• Could be checking:
  • /proc/ - Process and system info
  • /sys/ - Hardware information
  • Environment variables
  • Config files in ~/.config/, ~/.local/share/
  • /etc/ system files

This happens in-process - no network traffic!

How to monitor:

# Use strace to see what files Nuke accesses
sudo strace -f -e trace=open,openat,read,stat -p $(pgrep -f Nuke) 2>&1 | tee nuke_file_access.log

# Look for suspicious reads
grep -E '/proc|/sys|/etc|\.config' nuke_file_access.log

Gap E: Email Domain Collection

How they could get it:

1. From license credentials (most likely)

   • You logged in with email to activate license
   • Email domain already known to Foundry

2. From system username

   • If username is email format: user@domain.com

3. From hostname/network

   • SMTP server domain
   • Email client configuration files

This might not require transmission - they already have it from license registration

Gap F: Third-Party Services (Honeycomb, Sentry)

The problem:

• Even if we block Foundry domains, third-party services collect metadata:
  • Honeycomb sees: IP address, timing, data volume
  • Sentry sees: IP address, user-agent, system info
  • Both can geolocate your IP

Honeycomb/Sentry also have access to:

• All data Foundry sends them (obviously)
• Their own usage analytics
• Cross-customer correlation

4. How to Fill the Gaps

Comprehensive Monitoring Plan

Phase 1: Startup/Shutdown Capture (1 day)

# Morning: Capture startup
sudo tcpdump -i any -w startup.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Launch Nuke, wait for full load, stop capture

# Evening: Capture shutdown
sudo tcpdump -i any -w shutdown.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Close Nuke, wait 60 seconds, stop capture

# Analyze differences
tshark -r startup.pcap -q -z io,stat,0
tshark -r shutdown.pcap -q -z io,stat,0

Phase 2: Local File Monitoring (ongoing)

# Install inotify-tools
sudo pacman -S inotify-tools

# Monitor Nuke directories for file changes
inotifywait -m -r ~/Documents/nuke ~/.nuke ~/.cache/nuke 2>&1 | tee nuke_file_changes.log

Phase 3: System Call Tracing (1 session)

# Trace file access during Nuke session
sudo strace -f -e trace=open,openat,read,readv,connect -p $(pgrep -f Nuke) -o nuke_strace.log

# After session, analyze
grep -E 'open|connect' nuke_strace.log | grep -vE '(ENOENT|EAGAIN)' > nuke_access_summary.txt

Phase 4: Long-Duration Monitoring (1 week)

# Start ongoing monitoring
./monitor_nuke_telemetry.sh

# Leave running during normal Nuke usage
# Check logs daily for patterns
ls -lh telemetry-logs/
grep "NEW CONNECTION" telemetry-logs/*.log

Phase 5: Event-Triggered Capture (as needed)

# While monitoring is running:
# - Check for updates (Help menu)
# - Trigger an error/warning
# - Access online help
# - Large render job
# - Use various plugins
# Note timing in log

Ultimate Test: Compare with Block Enabled

# 1. Capture baseline (telemetry allowed)
sudo tcpdump -i any -w baseline.pcap 'host honeycomb.io or host foundry.com' &
# Use Nuke normally for 30 min
# Stop capture

# 2. Block telemetry
./block_nuke_telemetry.sh

# 3. Capture with blocking
sudo tcpdump -i any -w blocked.pcap 'host honeycomb.io or host foundry.com' &
# Use Nuke normally for 30 min
# Stop capture

# 4. Compare
tshark -r baseline.pcap | wc -l   # Should have packets
tshark -r blocked.pcap | wc -l    # Should be zero or connection failures

# 5. Check if Nuke still functions
# If features break, that tells us what relied on telemetry

Summary: What We're Probably Missing

Definitely Missing:

1. Startup telemetry - System scan, initial check-in
2. Shutdown telemetry - Session summary, cached data flush
3. Content of encrypted payloads - Everything in that 17KB to Honeycomb

Probably Missing:

4. Crash reports - No crashes occurred
5. Periodic check-ins - 20 min might not cover the interval
6. Local data collection - Registry/system scans happen locally first

Possibly Missing:

7. Event-triggered telemetry - Help menu, updates, specific features
8. Alternative protocols - UDP, different ports, IPv6
9. License server traffic - If using floating licenses
10. Cached/batched data - Stored locally, transmitted later

Already Captured (But Can't Decrypt):

11. Email domain - Likely in Honeycomb payload or already known from license
12. Geographic location - Determined from IP address (unavoidable)
13. Usage profiling - Likely in Honeycomb payload
14. System information - Likely in Honeycomb payload

Next Steps

Immediate (to fill critical gaps):

1. Capture Nuke startup telemetry
2. Capture Nuke shutdown telemetry
3. Check local Sentry database contents
4. Run strace to see file/registry access

Short-term (deeper investigation):

1. Monitor for 24+ hours to catch periodic check-ins
2. Force a crash and capture Sentry traffic
3. Test specific events (Help menu, updates, etc.)
4. Compare traffic with telemetry blocked

Long-term (ongoing):

1. Run monitoring service continuously
2. Build timeline of telemetry patterns
3. Correlate with Nuke usage events
4. File GDPR/CCPA request to see what Foundry actually has

---

Bottom Line: We're definitely missing startup/shutdown telemetry and can't see inside encrypted payloads. The EULA-permitted data (email, location, registry, usage) is almost certainly being transmitted - we just can't see it because it's encrypted inside the Honeycomb connection.