quick update
This commit is contained in:
49
Discoveries/Jibo Workshop HRI 2024.md
Normal file
49
Discoveries/Jibo Workshop HRI 2024.md
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
### Resources:
|
||||
https://github.com/jibodev/ShofEL2-for-T124-Jibo/tree/t124 - Github Repo
|
||||
https://hri2024.jibo.media.mit.edu/Setting-Up-Your-Codespace - Guide to setup a repo
|
||||
|
||||
- - -
|
||||
### About:
|
||||
From the jibo workshop i have discovered that they have actually included a lot of info on how jibo expects the server to give it data, and by that i dont mean that it uses [[ESML]], but what is available to use in every response!. Furthermore we also have access to some "examples" through the git repo on how to setup a [[Robot Os|ROS]] container, and I was able to extract the source code from the scratch extension over at [Scratch Playground](https://playground.raise.mit.edu/firebase-scratch/).
|
||||
|
||||
- - -
|
||||
|
||||
|
||||
Were gonna have to analyse the stuff to go further one , and as i was looking at the files i discovered a file named `jibo_chatGPT.ipynb` which sparked some attention, and it appears that they have made a honest attempt at trying to hook it up to chat gpt
|
||||
|
||||
![[JiboChatGPT.png]]
|
||||
|
||||
And there is a section where they clearly tried to make it act like jibo
|
||||
|
||||
```python
|
||||
|
||||
def main(args=None):
|
||||
|
||||
teleop_connection = JiboTeleop()
|
||||
|
||||
time.sleep(2)
|
||||
|
||||
|
||||
|
||||
system_message = "You are Jibo, a friendly social robot who likes to chat about different topics." \
|
||||
|
||||
"Pick a random topic to discuss and use personalized stories." \
|
||||
|
||||
"Always respond in one short fun and exciting sentence, " \
|
||||
|
||||
"and use language that is easy to understand for all ages." \
|
||||
|
||||
" Give turns to user to respond."
|
||||
|
||||
# Spin in a separate thread
|
||||
|
||||
thread = threading.Thread(target=rclpy.spin, args=(teleop_connection, ), daemon=True)
|
||||
|
||||
thread.start()
|
||||
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
|
||||
@@ -1,74 +0,0 @@
|
||||
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.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user