Files
JiboDocs/Discoveries/Network Profiling & Traffic Analysis.md

3.3 KiB
Executable File
Raw Blame History

Since Jibos official servers were decommissioned, the robot hangs during the "Checking for Updates" phase, and of course. By sniffing its network traffic, (Community member : Jaked) has identified several hardcoded endpoints. Our goal is to redirect this traffic to a local server to simulate a "Success" response and unlock the robots full functionality.


Initial scans show that Jibo uses a standard network stack but maintains a strict internal firewall.

  • Primary DNS: Hardcoded to 8.8.8.8 (Google DNS).
  • Web Config: Ports 80and 443 are closed/filtered by default.
  • ROS Bridge: Port 9090 (used for MIT Workspace/SDK) is blocked. It appears to require a specific "Skill" (likely the be-skill) to be running before the port opens.

Known Target Endpoints

The following table lists the IPs Jibo attempts to contact immediately after connecting to WiFi.

Time Synchronization (NTP)

Jibo hits these IPs repeatedly to sync its internal clock. Without a successful time sync, SSL handshakes for other services will fail.

-45.115.225.48
216.229.4.66
93.57.144.50
66.231.64.28
194.195.253.58

Persistent AWS Infrastructure

These are the most critical targets. Jibo hits these over and over, likely checking for signals or update manifests.

  • IP 1: 35.172.208.31
  • IP 2: 44.198.39.206

Hypothesis: These were likely the primary API endpoints for jibo.com. I am investigating the packet payload to see if they are expecting JSON or XML responses.

Legacy & Third-Party Hits

These appear less frequently, possibly for analytics or legacy newsletter/resource loading.

IP Address Ownership (potential) Purpose
66.118.231.14 Constant Contact Maybe email or newsletter?
172.232.15.202 Akamai Content Delivery?
72.30.35.89 Yahoo Weather / News API
67.210.96.32 Host Papa Domain hosting

Current Observations

The Update Loop

When Jibo reaches the "Checking for Updates" screen, it isn't "dead." Even while the screen is stuck loading , the background :

  1. Audio Processing stays active: Saying "Hey Jibo" causes the robot to turn toward the sound source.
  2. Network Persistence: It continues to attempt connections to the AWS IPs listed above.
  3. Timeout Behavior: It is unclear if the timeout is extremely long or if it is failing a specific SSL handshake.

Domain Discrepancy

  • jibo.com: Officially shut down; no longer resolves to an active site.
  • jibo.net: Currently active with a "Coming Soon" page. I am monitoring this to see if any hardcoded traffic redirects here.

Next Steps for Contributors

  1. SSL Decryption: We need to perform a Man-in-the-Middle (MITM) attack using a tool like mitmproxy to see the actual content of the HTTPS requests.
  2. DNS Poisoning: Set up a local DNS server (like Pi-hole or a custom BIND server) to redirect 8.8.8.8 calls to a local gateway.
  3. Endpoint Mocking: Create a Python or Flask server to return dummy 200 OK responses to the AWS IPs to see if Jibo bypasses the update screen.