75 lines
3.3 KiB
Markdown
75 lines
3.3 KiB
Markdown
|
Since Jibo’s 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 robot’s 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 `80`and `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.
|
|||
|
|
|
|||
|
|
---
|