Compare commits

...

5 Commits

Author SHA1 Message Date
0420f4026b add docs 2026-03-19 08:39:54 -05:00
98c64f6efb git ignore stuff 2026-03-18 21:21:55 +02:00
54b10ec46d OMG More warnings 2026-03-18 21:14:26 +02:00
5fd69861c4 quick update 2026-03-18 15:23:30 +02:00
a8dbcb1645 fix git ignore 2026-03-18 14:50:44 +02:00
31 changed files with 1484 additions and 104 deletions

3
.gitignore vendored Normal file
View File

@@ -0,0 +1,3 @@
.obsidian/workspace.json
.obsidian/workspace.json

View File

@@ -13,26 +13,12 @@
"state": {
"type": "markdown",
"state": {
"file": "Getting Started/Welcome to the Jibo Revival Project.md",
"file": "Documentation/Useful Items List.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Welcome to the Jibo Revival Project"
}
},
{
"id": "c3f7d6e3edde93cc",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "Jibo Reval Project/Attack Vectors/Hardware and Tegra Exploitation.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Hardware and Tegra Exploitation"
"title": "Useful Items List"
}
},
{
@@ -41,42 +27,16 @@
"state": {
"type": "markdown",
"state": {
"file": "Jibo Reval Project/Getting Started/Modifying the Firmware/1. Get your environment ready!.md",
"file": "Jibo Tools & Mod Installer/08 - Troubleshooting.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "1. Get your environment ready!"
}
},
{
"id": "8f09013cb382a9eb",
"type": "leaf",
"state": {
"type": "release-notes",
"state": {
"currentVersion": "1.12.4"
},
"icon": "lucide-book-up",
"title": "Release Notes 1.12.4"
}
},
{
"id": "bca83b8556c51cdb",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "index.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "index"
"title": "08 - Troubleshooting"
}
}
],
"currentTab": 4
"currentTab": 1
}
],
"direction": "vertical"
@@ -235,7 +195,8 @@
}
],
"direction": "horizontal",
"width": 300
"width": 200,
"collapsed": true
},
"left-ribbon": {
"hiddenItems": {
@@ -251,35 +212,49 @@
"quartz-syncer:Quartz Syncer publication center": false
}
},
"active": "1895b61c1551dd83",
"active": "0806f039bf8a940e",
"lastOpenFiles": [
"Getting Started/Developing for Jibo/Introduction to the New Jibo SDK.md",
"Getting Started/Welcome to the Jibo Revival Project.md",
"index.md",
"README.md",
"Getting Started/Developing for Jibo/About - Jibo SDK V2!.md",
"Getting Started/Modifying the Firmware/Using the install script.md",
"Getting Started/Developing for Jibo",
"obsidian/08 - Troubleshooting.md",
"obsidian/07 - Working Directory + State Files.md",
"obsidian/06 - Updater (How It Works).md",
"obsidian/05 - Windows Support.md",
"obsidian/04 - GUI (How It Works).md",
"obsidian/03 - CLI Arguments.md",
"obsidian/02 - Mapping to guide.md",
"obsidian/01 - Installer (How It Works).md",
"obsidian/00 - Index.md",
"obsidian",
"Documentation/Menu Buttons/ButtonSetup.png",
"Documentation/Menu Buttons/ButtonSetup.kra",
"Documentation/Menu Buttons",
"Jibo Tools & Mod Installer/07 - Working Directory + State Files.md",
"Jibo Tools & Mod Installer/06 - Updater (How It Works).md",
"Jibo Tools & Mod Installer/05 - Windows Support.md",
"Jibo Tools & Mod Installer/04 - GUI (How It Works).md",
"Assets/JiboToolsScreen.png",
"Assets/Screenshot_20260317_235807.png",
"Jibo Tools & Mod Installer/03 - CLI Arguments.md",
"Jibo Tools & Mod Installer/01 - Installer (How It Works).md",
"Getting Started/Modifying the Firmware/1. Get your environment ready!.md",
"Dictionary/Robot Os.md",
"Dictionary/ESML.md",
"Jibo Workshop HRI 2024.md",
"Dictionary/NVIDIA Tegra K1 (T124) Soc.md",
"Dictionary/ShofEL2 - Fusée Gelée Exploit.md",
"Attack Vectors/Hardware and Tegra Exploitation.md",
"Discoveries/Network Profiling & Traffic Analysis.md",
"Documentation/Validated memory adresses.md",
"Jibo Tools & Mod Installer/00 - Index.md",
"Documentation/Useful Items List.md",
"Jibo Tools & Mod Installer/02 - Mapping to guide.md",
"Getting Started/Welcome to the Jibo Revival Project.md",
"Documentation/AtDev - New Firewall script.md",
"Documentation/Networking/Network Profiling & Traffic Analysis.md",
"Documentation/Networking",
"Documentation/The be skill/Assets/The audio directory.md",
"Documentation/The be skill/Assets/The assets directory.md",
"Documentation/The be skill/Assets",
"Documentation/The be skill/The Splash screen image!.md",
"Documentation/The be skill",
"Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.png",
"Assets/Jibo RCM.jpg",
"Getting Started/Modifying the Firmware",
"Getting Started",
"Jibo Reval Project/Uncategorized/The \"MIT Application\" Mystery saga.md",
"Attack Vectors",
"ESML/Jibo-Animations.pdf",
"ESML/ESML-SDK.pdf",
"Jibo Reval Project",
"Untitled.base",
"Assets/JiboChatGPT.png",
"Assets",
"ESML"
"About UART Connection",
"Jibo Tools & Mod Installer",
"Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.kra",
"Documentation/The be skill/Assets/Menu Buttons",
"Assets/JiboChatGPT.png"
]
}

BIN
Assets/JiboToolsScreen.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 301 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

View File

@@ -0,0 +1,254 @@
- - -
# #AtDev , work in progress
- - -
Under /etc/init.d/ we have
```shell
# cd /etc/init.d/
# ls
S00fix-os S15crond S33dbus S48avahi-daemon S63body-board-power S78jibo-system-manager
S01logging S18udev S36sshd S51upload-logs S66ntp S81named
S06coredumps S21firewall S39audio-enable S54modules S69start-X11 S84identity-syslog
S09wifi-enable S24cpufreq S42avahi-setup.sh S57alsa-volume S72jibo-apply-update rcK
S12dns-prime S30urandom S45network S60alsaloopback S75jibo-service-registry rcS
```
currently interested in `/etc/init.d/S21firewall`
```log
# cat /etc/init.d/S21firewall
#!/bin/sh
#
# Jibo Firewall init script
#
set -e
IPTABLES_CMDS="/usr/sbin/iptables /usr/sbin/ip6tables"
flush_rules() {
for iptables in $IPTABLES_CMDS; do
$iptables -t filter -F
$iptables -t filter -P INPUT ACCEPT
$iptables -t filter -P FORWARD ACCEPT
$iptables -t filter -P OUTPUT ACCEPT
# add the DYNAMIC_ACCESS chain unconditionally
$iptables -t filter -X
$iptables -t filter -N DYNAMIC_ACCESS
done
}
normal_rules() {
for iptables in $IPTABLES_CMDS; do
$iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -t filter -A INPUT -p icmp -j ACCEPT
$iptables -t filter -A INPUT -i lo -j ACCEPT
# allow dynamic access rules from system-manager
$iptables -t filter -A INPUT -j DYNAMIC_ACCESS
$iptables -t filter -A INPUT -j REJECT
$iptables -t filter -A FORWARD -j REJECT
done
}
developer_rules() {
for iptables in $IPTABLES_CMDS; do
# jibo-dev-shell
$iptables -t filter -A INPUT -p tcp --syn --dport 8686 -j ACCEPT
# jibo-skills-service
$iptables -t filter -A INPUT -p tcp --syn --dport 8779 -j ACCEPT
# jibo-sync
$iptables -t filter -A INPUT -p tcp --syn --dport 8989 -j ACCEPT
# jibo-debug-proxy
$iptables -t filter -A INPUT -p tcp --syn --dport 9191 -j ACCEPT
# avahi
$iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
done
normal_rules
}
certification_rules() {
for iptables in $IPTABLES_CMDS; do
# jibo-certification-service
$iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
done
normal_rules
}
service_rules() {
for iptables in $IPTABLES_CMDS; do
# jibo-certification-service
$iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
# jibo-service-center-service
$iptables -t filter -A INPUT -p tcp --syn --dport 9797 -j ACCEPT
# avahi
$iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
done
normal_rules
}
start() {
echo -n "Configuring firewall: "
flush_rules
my_mode=$(/usr/bin/jibo-getmode)
if [ $? -ne 0 ]; then
echo "Unspecified mode. SKIP"
elif [ "$my_mode" == "identified" ]; then
echo "IDENTIFIED"
elif [ "$my_mode" == "int-developer" ]; then
echo "INT-DEVELOPER"
elif [ "$my_mode" == "developer" ]; then
developer_rules
test $? -eq 0 && echo "DEVELOPER" || echo "ERROR"
elif [ "$my_mode" == "certification" ]; then
certification_rules
test $? -eq 0 && echo "CERTIFICATION" || echo "ERROR"
elif [ "$my_mode" == "service" ]; then
service_rules
test $? -eq 0 && echo "SERVICE" || echo "ERROR"
else
normal_rules
test $? -eq 0 && echo "OK" || echo "ERROR"
fi
}
stop() {
echo -n "Unconfiguring firewall: "
flush_rules
test $? -eq 0 && echo "OK" || echo "ERROR"
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo "Usage: $0 {start|stop|restart}" >&2
exit 1
;;
esac
```
and in `S78jibo-system-manager`
```log
# cat S78jibo-system-manager
#!/bin/sh
#
# Jibo System Manager init script
#
set -e
PROCESS=jibo-system-manager
BIN_DIR=/usr/local/bin
CFG_DIR=/usr/local/etc
check_mode() {
my_mode=$(/usr/bin/jibo-getmode)
if [ $? -ne 0 ]; then
echo "Unspecified mode. SKIP"
exit 0;
fi
if [ "$my_mode" != "oobe" \
-a "$my_mode" != "int-developer" \
-a "$my_mode" != "developer" \
-a "$my_mode" != "normal" \
-a "$my_mode" != "certification" \
-a "$my_mode" != "service" ]; then
echo "Mode is $my_mode. SKIP"
exit 0;
fi
# only configure coredump generation for internal development modes
# for all other modes, don't configure as they cannot be used
if [ "$my_mode" == "int-developer" ]; then
echo "Configuring coredumps"
# all subprocesses should generate core dumps
ulimit -c unlimited
fi
}
check_running() {
pgrep -x jibo-system-man >& /dev/null
return $?
}
wait_for_stopped() {
while check_running; do
echo -n "waiting... "
sleep 2
done
}
start() {
echo -n "Starting $PROCESS: "
check_mode
$BIN_DIR/$PROCESS -c $CFG_DIR/$PROCESS.json --daemon
test $? -eq 0 && echo "OK" || echo "ERROR"
}
stop() {
echo -n "Stopping $PROCESS: "
killall $PROCESS
wait_for_stopped
test $? -eq 0 && echo "OK" || echo "ERROR"
}
case "$1" in
start)
start
;;
stop)
stop
;;
*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac
```
to bypass the lockout in normal mode we can add like a filter under the normal rules function
first ima remount with write permissions :
```shell
mount -o remount,rw /
# vi and append :
normal_rules() {
for iptables in $IPTABLES_CMDS; do
$iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -t filter -A INPUT -p icmp -j ACCEPT
$iptables -t filter -A INPUT -i lo -j ACCEPT
# allow dynamic access rules from system-manager
>>> $iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT <<<
$iptables -t filter -A INPUT -j DYNAMIC_ACCESS
$iptables -t filter -A INPUT -j REJECT
$iptables -t filter -A FORWARD -j REJECT
done
}
```
i was gonna use telnetd but its not installed
anyway using`jibo-getmode` i will revert back to the `normal` mode
and it works! saving diff for the installer
now that we have normal mode with ssh we have more capabilities, i will re screw the head back!... i broke my face ring

View File

@@ -61,14 +61,11 @@ When Jibo reaches the "Checking for Updates" screen, it isn't "dead." Even while
### **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.
- **jibo.net:** Tribute site made by Community member Jibo-detective or RoboticaLabs on youtube
---
## 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.
Check out [[Networking & ports & Error codes]] by ZaneDev from discord
---

View File

@@ -1,4 +1,4 @@
Jibo was built a little weird, so it's easy to forget things. This document contains things that are nice to know for tinkering or developing for Jibo Revival.
- - -
# Useful Ports
> [!INFORMATION]
> You might not be able to access some ports if you haven't unblocked them on Jibo's firewall.
@@ -19,11 +19,3 @@ It seems in recent versions of Jibo errors relating to him not being able to con
| Q4 | No | |
| N1N12 | No | |
| OTA11, R1 | No | Triggers error-within-error: "NOT HANDLED BY ERROR SKILL" |
# Useful Files
### /opt/jibo/Jibo/Skills/@be/be/resources/JiboSplash.png
This file allows you to edit the splash screen. This is the image that shows at the start of the Be skill (normally the Jibo logo, Jibo Revival logo, OpenJiboOS logo, or some variation). Note: This is only the splash screen for the Be skill. It will only edit the splash seen when you restart "@be/Be", or in the 'second boot stage' when Jibo spins and shows the splash a second time.
### /usr/local/bin/
Has a lot of random assets, potentially has assets useful for restoration.
### /opt/jibo/Jibo/Skills/@be/be/node_modules/jibo-anim-db-animations/audio/
Lots of audio assets, the surrounding folders also contain other assets.

View File

@@ -0,0 +1,5 @@
- - -
The Be skill really is just jibos main menu including his eye and well... menu...
anyway i will write about this later but for now here are some references to check out :)

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

View File

@@ -0,0 +1,5 @@
- - -
Located in `/usr/local/bin/`
Has a lot of random assets, potentially has assets useful for restoration.

View File

@@ -0,0 +1,5 @@
- - -
Located in `/opt/jibo/Jibo/Skills/@be/be/node_modules/jibo-anim-db-animations/audio/`
Lots of audio assets, the surrounding folders also contain other assets.

View File

@@ -0,0 +1,7 @@
- - -
it is located in:
`/opt/jibo/Jibo/Skills/@be/be/resources/JiboSplash.png`
This file allows you to edit the splash screen. This is the image that shows at the start of the Be skill (normally the Jibo logo, Jibo Revival logo, OpenJiboOS logo, or some variation). Note: This is only the splash screen for the Be skill. It will only edit the splash seen when you restart "@be/Be", or in the **'second boot stage'** when Jibo spins and shows the splash a second time.

View File

@@ -0,0 +1,13 @@
Jibo was built a little weird, so it's easy to forget things. This document contains things that are nice to know for tinkering or developing for Jibo Revival.
- - -
## About [[The Splash screen image!]]
## About [[The assets directory]]
## About [[The audio directory]]
## About [[Networking & ports & Error codes]]
## About [[Network Profiling & Traffic Analysis]]
- - -
Documented by ZaneDev @ Our Discord

View File

@@ -0,0 +1,264 @@
# Local ASR, TTS, and Voice Round-Trip on Jibo (Post-Cloud)
> This document describes the first confirmed working voice interaction on a Jibo robot after official cloud services were discontinued.
---
## Summary
Short version: Jibo can still have a full conversation loop locally.
We now have:
* Speech → text (STT) working locally
* Text → speech (TTS) working locally
* A working loop where Jibo hears something and responds
This is all happening without the original cloud services.
---
## Key Findings
Heres what we now know for sure:
* Wake word detection (`hey jibo`) still works locally
* Speaker ID is still running locally (even if it rejects us 😄)
* `jibo-asr-service` can be started and controlled manually
* ASR (speech recognition) is exposed over HTTP on port `8088`
* TTS (speech output) is exposed over HTTP on port `8089`
### ASR Endpoints
Confirmed working endpoints:
* `/asr_simple_interface`
* `/audio_source`
* `/asr_control`
* `/status`
### WebSocket Outputs
ASR results are streamed over WebSockets:
* `ws://<jibo-ip>:8088/port`
* `ws://<jibo-ip>:8088/simple_port`
### Example STT Start Payload
```json
{
"command": "start",
"task_id": "DEBUG:task3",
"audio_source_id": "alsa1",
"hotphrase": "none",
"speech_to_text": true,
"request_id": "stt_start3"
}
```
---
## Whats Actually Happening (Architecture)
Heres the real flow in plain English:
1. We send a request to Jibo to start listening
2. Jibo captures audio from its mic (ALSA)
3. The ASR engine processes it
4. Results come back over WebSocket
5. Our app reads the transcript
6. Our app decides what to say
7. We send that to Jibos TTS
8. Jibo speaks
Visual version:
```
HTTP POST (/asr_simple_interface)
ASR service captures audio
Speech recognition runs locally
WebSocket emits events
External app receives transcript
External logic decides response
HTTP POST (/tts_speak)
Jibo talks
```
---
## Example WebSocket Output
Heres a trimmed real example of a final result:
```json
{
"event_type": "speech_to_text_final",
"task_id": "DEBUG:task3",
"utterances": [
{
"utterance": "what time is it",
"score": 975.9
}
]
}
```
Youll also see:
* `speech_to_text_incremental` (partial results)
* `end_of_speech`
* `hotphrase` (for "hey jibo")
---
## Demo Flow (How to Reproduce)
This is the important part.
### 1. Make sure you are in `int-developer` mode and ASR service is running
From ssh:
```
/usr/local/bin/jibo-asr-service -c /usr/local/etc/jibo-asr-service.json
```
---
### 2. Connect to WebSocket
```
ws://<jibo-ip>:8088/simple_port
```
---
### 3. Start an STT task
POST to:
```
http://<jibo-ip>:8088/asr_simple_interface
```
With:
```json
{
"command": "start",
"task_id": "DEBUG:task3",
"audio_source_id": "alsa1",
"hotphrase": "none",
"speech_to_text": true
}
```
---
### 4. Speak to Jibo
Say something like:
> “what time is it”
---
### 5. Wait for final transcript
Watch for:
```
event_type: speech_to_text_final
```
---
### 6. Send response to TTS
POST to:
```
http://<jibo-ip>:8089/tts_speak
```
With something like:
```json
{
"text": "It is demo time."
}
```
---
### 7. Jibo speaks 🎉
---
## Known Behaviors / Quirks
Some things weve seen so far:
* WebSocket connections can drop → reconnect logic helps
* Incremental results can be messy or duplicated
* Multiple transcript guesses can show up
* Wake word (`task0`) runs alongside your custom task
* Saying “hey jibo” during a manual STT session can interfere
* Speaker ID often rejects (but doesnt block STT)
---
## Corrections to Previous Assumptions
Some things we (and others) thought before that are now clearly wrong or incomplete:
* “ASR is dead without cloud” → **Not true in developer mode**
* “Only wake word works locally” → **Incomplete**
* “No way to get transcripts” → **False (WebSocket output exists)**
* “Jibo cant answer questions anymore” → **Also false now 🙂**
---
## What This Means
This is a big deal:
* Jibos core voice pipeline is still there
* The cloud was orchestration, not the whole system
* We can now rebuild the “brain” externally
---
## Next Steps
Where this naturally goes next:
* Hook wake word → automatically trigger STT
* Figure out how this behaves in “normal mode”
* See if Jibo tries to initiate outbound connections (old cloud flow)
* Intercept or replace those endpoints locally
* Build a simple always-on bridge service:
* Wake word → STT → AI → TTS
---
## Final Thought
We didnt just poke at endpoints here.
We proved Jibo can:
* hear
* understand
* and respond again
Thats a pretty great place to be.

View File

@@ -21,6 +21,12 @@ Before starting ANY work , lets get you up to speed with the enviroment and what
5. An the mindset of (everything will be fine!)
- - -
>[!DANGER]
> # Part 0 | Note your jibos IP Down
> Make sure you have your jibos IP adress , so you wont have to redo 4 hours of flashing just because you forgot your ip
- - -
# Part 1 | Connecting your jibo
So first , go ahead and plug jibo in to your host device that you are going to dump the firmware into using your usb cable

View File

@@ -0,0 +1,14 @@
# JiboAutoModv2
This folder contains internal documentation for how this repo works.
## Start here
- [[01 - Installer (How It Works)]]
- [[02 - Mapping to guide]]
- [[03 - CLI Arguments]]
- [[04 - GUI (How It Works)]]
- [[05 - Windows Support]]
- [[06 - Updater (How It Works)]]
- [[07 - Working Directory + State Files]]
- [[08 - Troubleshooting]]

View File

@@ -0,0 +1,88 @@
# Installer (How It Works)
The repo has a “CLI installer” and an optional GUI wrapper that launches the same Python tools.
The basic mod logic lives in `../jibo_automod.py`
## What the installer actually does
The tool is automating the exact same high-level steps you do manually in [[1. Get your environment ready!]]
1. Build ShofEL (`shofel2_t124`) if it isnt built yet.
2. Put the Jibo into NVIDIA Tegra RCM mode (USB device `0955:7740`).
3. Read eMMC contents using `EMMC_READ`.
4. Find the `/var` partition (usually GPT partition #5, ~500MB).
5. Modify `/var/jibo/mode.json` from `normal` to `int-developer`.
6. Write the modified `/var` partition back using `EMMC_WRITE`.
7. Optionally verify by reading back and comparing hashes.
After that, Jibo boots to a checkmark and SSH should work:
- `ssh root@<jibo-ip>`
- password: `jibo`
## Launchers (what runs what)
### Linux launcher
- `../jibo_automod.sh` is a Bash launcher
- It does a light dependency check, then prompts:
- CLI installer (recommended)
- GUI installer (experimental)
In CLI mode it runs:
- `python3 ../jibo_automod.py <args>`
In GUI mode it:
- creates `../.venv/` if missing
- installs GUI deps from `../JiboTools/JiboTools/requirements.txt`
- launches `../JiboTools/JiboTools/main_panel.py`
### Windows launcher
- `../jibo_automod.bat` just runs `python ../jibo_automod.py <args>`
- It warns if youre not running as Administrator.
## How it edits mode.json (important detail)
`../jibo_automod.py` tries multiple strategies to edit `mode.json` inside the `/var` filesystem image:
1. **Linux mount (preferred on Linux)**
- Mounts `var_partition.bin` as a loop device.
- Edits `jibo/mode.json` (or a couple fallback paths).
- Unmounts.
2. **debugfs (preferred for Windows if available)**
- Uses `debugfs` from `e2fsprogs` to read and rewrite the file inside the ext filesystem image without mounting.
- This is the safest option on Windows if you can install it (see [[05 - Windows Support]]).
3. **Raw in-place patch (last resort)**
- Searches the binary image for known JSON string patterns like `{"mode": "normal"}`.
- Overwrites bytes in-place without changing file size.
- **If the replacement would require growing the data and there is no safe padding, it refuses.**
>[!note]
Because this is a real filesystem image, the mount/debugfs approaches are more reliable than raw patching.
## Installer modes
The CLI tool supports three main workflows:
- **Full mod** (default): full eMMC dump, then extract/modify/write `/var`.
- **Dump-only**: only dumps eMMC (no modifications).
- **Mode-json-only** (“fast mode”): reads only GPT + `/var` and patch-writes only changed sectors.
Details and flags: [[03 - CLI Arguments]]
## Where output goes
By default, the tool uses `../jibo_work/` for working files:
- `jibo_full_dump.bin` (full mode)
- `gpt_dump.bin` (fast mode)
- `var_partition_original.bin` / `var_partition.bin`
- backups, verification reads, and patch chunks
More: [[07 - Working Directory + State Files]]

View File

@@ -0,0 +1,104 @@
# Mapping to guide.md
This page explains how the automated installer in `../jibo_automod.py` relates to the manual steps in `../guide.md`.
## Big picture
`../guide.md` is the “do it by hand” method.
`../jibo_automod.py` is the “do the same steps, but scripted” method.
If something goes wrong in automation, the guide is still valuable because it explains:
- how to confirm RCM mode
- how to interpret partition layouts
- what `/var/jibo/mode.json` does conceptually
## Step-by-step mapping
### Part 1 (Connecting / RCM)
Guide:
- Enter RCM mode and confirm with `lsusb` showing NVIDIA APX (`0955:7740`).
Tool:
- `detect_jibo_rcm()` tries `lsusb` on Linux.
- Falls back to scanning `/sys/bus/usb/devices` if `lsusb` is missing.
- On Windows it cant reliably detect in the same way, so it prints guidance and proceeds.
Related: [[05 - Windows Support]]
### Part 2 (Build ShofEL)
Guide:
- Clone/build ShofEL manually with `make`.
Tool:
- `build_shofel()` runs `make` inside `../Shofel/`.
- If payload `.bin` files are missing, it requires the ARM toolchain (`arm-none-eabi-gcc`).
### Part 3 (Dump eMMC)
Guide:
- Run: `shofel2_t124 EMMC_READ 0x0 0x1D60000 full_jibo_dump.bin`
Tool:
- Default full workflow calls `dump_emmc()` which runs the same command.
- Fast workflow (`--mode-json-only`) does *not* dump full eMMC; it only reads GPT + `/var`.
### Part 4 (Identify and extract /var)
Guide:
- Run `fdisk -l dump.bin`
- Find partition 5, compute start/count, then `dd` out `var_partition.bin`.
Tool:
- Parses GPT directly (`parse_gpt_partitions()`), with an `fdisk` fallback on Linux.
- Then extracts bytes by seeking directly inside the dump (no `dd` needed).
- Uses heuristics to identify `/var` (partition #5 and roughly 400600MB).
### Part 4.2 (Edit mode.json)
Guide:
- Mount loop device and edit `jibo/mode.json`.
Tool:
- On Linux: prefers a loop mount and edits `mode.json`.
- On Windows: prefers `debugfs` if installed.
- Raw in-place patch is last resort.
Related: [[01 - Installer (How It Works)]]
### Part 5 (Write /var back)
Guide:
- Convert start sector to hex and run `EMMC_WRITE <start> var_partition.bin`.
Tool:
- Always uses the GPT-derived start sector (so you dont manually convert it).
- In fast mode, it can patch-write only changed sectors instead of writing the full 500MB.
### Part 6 (Verify)
Guide:
- Read back and compare hashes.
Tool:
- Optional verify step reads back the written range and compares MD5.
## Why the automated tool differs from the guide
The guide is intentionally explicit and teaches the mental model.
The tool tries to reduce “math + manual disk ops” by:
- parsing GPT automatically
- extracting partitions programmatically
- handling mount/debugfs edits
- optionally patch-writing only changed sectors
## When to fall back to the guide
- If your partition layout differs enough that `/var` isnt partition 5.
- If the filesystem inside `/var` is corrupted and mount/debugfs cant read it.
- If you want a full backup regardless of speed (the guide defaults to full dump).

View File

@@ -0,0 +1,147 @@
# CLI Arguments
This page documents the CLI flags for the two main tools:
- `../jibo_automod.py` (installer/mod tool)
- `../jibo_updater.py` (OS updater)
If youre using launchers (`.sh`/`.bat`), they forward all arguments through.
## jibo_automod.py
### Modes (mutually exclusive)
- (no mode flag)
- Full mod workflow (full eMMC dump, extract/modify/write `/var`).
- `--dump-only`
- Only dump eMMC; dont modify anything.
- `--write-partition FILE`
- Write an already-prepared partition image to eMMC.
- You must tell it where to write using `--start-sector`.
- `--mode-json-only`
- Fast path:
1) read GPT (small)
2) read `/var` only (~500MB)
3) modify `/var/jibo/mode.json`
4) write back either a patch (default) or full `/var`
### Common options
- `--dump-path FILE`
- Use an existing dump file instead of reading from the device.
- `--output FILE` / `-o FILE`
- Output file for dumps.
- `--start-sector HEX`
- Start sector for `--write-partition`.
- Parsed with base autodetect (`0x...` works).
- Default is `0x7E9022` (but the full/fast workflows usually compute the start sector from GPT).
- `--force-dump`
- Re-dump even if a dump exists.
- `--rebuild-shofel`
- Force rebuilding ShofEL (`make clean` then `make`).
- `--skip-detection`
- Skip USB “is Jibo connected” checks.
- `--no-verify`
- Skip verification read-back.
### Fast mode options
- `--full-var-write`
- Only meaningful with `--mode-json-only`.
- If set: write the full `/var` partition back (slower).
- If not set: compute sector diffs and only write changed ranges (faster).
### Examples
- Full mod:
- `python3 jibo_automod.py`
- Dump only:
- `python3 jibo_automod.py --dump-only -o my_dump.bin`
- Use existing dump:
- `python3 jibo_automod.py --dump-path jibo_work/jibo_full_dump.bin`
- Fast mode:
- `python3 jibo_automod.py --mode-json-only`
- Write a prepared partition:
- `python3 jibo_automod.py --write-partition var_partition.bin --start-sector 0x7E9022`
## jibo_updater.py
The updater assumes you already have SSH access to the robot.
### Required
- `--ip <host>` (alias: `--host`)
- IP or hostname of your Jibo.
### Connection
- `--user <name>` (default `root`)
- `--password <pass>` (default `jibo`)
- `--ssh-timeout <seconds>` (default `15`)
### Release selection
- `--releases-api <url>`
- API endpoint for Gitea releases.
- `--stable`
- Ignore prereleases.
- `--tag <tag>`
- Install a specific tag instead of “latest”.
### Archive layout
- `--build-path <relative/path>`
- If the updater cant find the `build/` folder automatically, specify where it is inside the extracted archive.
### Safety / UX
- `--state-file <path>`
- Where it remembers the last applied version per host.
- `--force`
- Re-download and re-install even if the local state says youre already on that version.
- `--yes`
- Dont prompt for confirmation.
- `--dry-run`
- Download/extract + connect, but dont upload files and dont touch mode.json.
### Returning to normal mode
- `--return-normal`
- After update, set `/var/jibo/mode.json` back to `normal` (no prompt).
- `--no-return-normal`
- Never prompt and never change mode back.
### Examples
- Update to latest:
- `python3 jibo_updater.py --ip 192.168.1.50`
- Stable only:
- `python3 jibo_updater.py --ip 192.168.1.50 --stable`
- Specific tag:
- `python3 jibo_updater.py --ip 192.168.1.50 --tag v3.3.0`
- Dry run:
- `python3 jibo_updater.py --ip 192.168.1.50 --dry-run`
More detail: [[06 - Updater (How It Works)]]

View File

@@ -0,0 +1,100 @@
# GUI (How It Works)
The GUI is an optional Qt (PySide6) front-end.
>[!Important]
the GUI does **not** re-implement the mod/updater logic; it mostly launches the same Python scripts and shows their logs.
- - -
![[JiboToolsScreen.png]]
- - -
## Entry points
- Linux launcher: `../jibo_gui.sh`
- Windows launcher: `../jibo_gui.bat`
The GUI module it runs is:
- `python -m gui.main_panel`
The implementation is in:
- `../JiboTools/JiboTools/gui/main_panel.py`
## Main Panel overview
The main panel UI (`form.ui`) is loaded at runtime (Qt Widgets, not QML):
- `../JiboTools/JiboTools/form.ui`
`MainWindowController` wires up widgets and behavior:
- “Connect” button opens an SSH session to the robot using Paramiko.
- It reads `/var/jibo/identity.json` to display the robot name.
- The panel includes toggles/fields for Home Assistant and AI settings (currently UI-only wiring; the panel mainly focuses on connection + launching tools).
### Connection behavior
- Host/IP comes from the UI field.
- Credentials are currently fixed to `root` / `jibo` in the panel code.
- UI shows a status dot and swaps images based on connection state.
## Tool runner windows (Installer / Updater)
When you click installer/updater from the panel, it spawns a separate “Tool Runner” window:
- Installer: runs `jibo_automod.py`
- Updater: runs `jibo_updater.py`
The common implementation is:
- `../JiboTools/JiboTools/gui/tool_runner_window.py`
### How the tool runner executes scripts
- Uses `QProcess` (see `ProcessRunner`) to run a Python process.
- Captures merged stdout/stderr and appends it into a log view.
- Has a Start/Stop button (Stop terminates then kills if needed).
It resolves which Python to use with:
- `resolve_python_invocation()` in `../JiboTools/JiboTools/gui/process_runner.py`
Resolution order (simplified):
1. Use repo-local `../.venv/` Python if present.
2. Otherwise use the current interpreter (useful if launched from Qt Creator).
3. Windows fallback: `py -3`.
4. Linux fallback: `python3`, then `python`.
### Passing arguments
- The tool runner has an “Extra args” textbox.
- For the updater runner specifically, it also has a host field that becomes `--ip <host>`.
This means the GUI is effectively a thin wrapper over the CLI flags described in [[03 - CLI Arguments]].
### “Open in terminal”
The tool runner can try to spawn an external terminal window with the exact command line it would run.
- Linux: tries `x-terminal-emulator`, `gnome-terminal`, `konsole`, etc.
- Windows: uses `cmd.exe`.
## Dependencies
GUI deps live in:
- `../requirements-gui.txt` (PySide6)
- `../JiboTools/JiboTools/requirements.txt` (PySide6 + Paramiko)
The CLI installer launcher `../jibo_automod.sh` also auto-creates `../.venv/` and installs `../JiboTools/JiboTools/requirements.txt` if you pick GUI mode.
## Practical notes / limitations
- The GUI is great for convenience, but debugging is often easier from CLI because you can see exactly what flags are being passed.
- The installer still requires RCM mode + USB access; the GUI does not remove that requirement.
- The updater requires SSH access (meaning: you must already be in developer mode / checkmark boot).

View File

@@ -0,0 +1,83 @@
# Windows Support
This repo supports Windows, but there are two separate “Windows” stories:
1. **Running the Python scripts on Windows** (launchers: `.bat`)
2. **Actually talking to the Jibo over USB in RCM mode** (drivers + build tools)
The USB/RCM part is the trickiest.
## Launchers
- Installer: `../jibo_automod.bat`
- Runs `python ../jibo_automod.py %*`
- Warns if not Administrator.
- Updater: `../jibo_updater.bat`
- Prefers `../.venv/` Python if present.
- Else prefers `py -3`.
- GUI: `../jibo_gui.bat`
- Same Python resolution approach.
## Environment setup helper
- `../windows_setup.bat` helps install dependencies via MSYS2 and explains Zadig.
It installs (via MSYS2):
- MinGW gcc/make
- libusb
- ARM toolchain (`arm-none-eabi-gcc`) for payload builds
## USB driver requirement (RCM mode)
When Jibo is in RCM mode it enumerates as NVIDIA APX (`0955:7740`).
On Windows you typically need to replace its driver with WinUSB:
- Use Zadig and install WinUSB for the “APX” device.
Without this, ShofEL wont be able to talk to the device.
## Editing mode.json on Windows
Linux can mount the ext filesystem image and edit `/var/jibo/mode.json` normally.
Windows usually cant mount the ext image easily, so `../jibo_automod.py` tries alternative methods:
1. **debugfs (recommended)**
- If `debugfs.exe` is available on PATH, the tool can edit the file inside the ext filesystem image safely.
- Install via MSYS2:
- `pacman -S --needed e2fsprogs`
2. **Raw in-place patch (last resort)**
- The tool searches the partition image bytes for JSON patterns and overwrites them without changing length.
- This can fail if the on-disk JSON format differs or if theres no safe padding space.
If youre on Windows and youre seeing warnings about raw edits or the tool cant find patterns, installing `debugfs` is the best fix.
## WSL option
Another workable approach is to use WSL2 and follow the Linux path.
Caveat: you still need USB passthrough into WSL (which can be non-trivial depending on your setup).
## Common Windows failure modes
- Device not detected / cant open USB:
- Wrong driver (use Zadig -> WinUSB)
- Not Administrator
- Cable is charge-only
- Build failures:
- Missing MSYS2 packages
- ARM toolchain missing (payload `.bin` files wont build)
- mode.json edit failures:
- Install `e2fsprogs` and ensure `debugfs` is on PATH
## Related docs
- Installer workflow: [[01 - Installer (How It Works)]]
- CLI flags: [[03 - CLI Arguments]]

View File

@@ -0,0 +1,79 @@
# Updater (How It Works)
The updater is a separate tool from the installer.
- Installer: puts Jibo into developer mode by editing `/var/jibo/mode.json` via RCM + eMMC writes.
- Updater: once you have SSH access, it downloads a JiboOs release and uploads a rootfs overlay to the robot over SFTP.
Implementation: `../jibo_updater.py`
## High-level flow
1. Query the releases API (Gitea JSON) and pick a release:
- latest (default)
- stable-only (`--stable`)
- specific tag (`--tag`)
2. Download the chosen release archive.
3. Extract it safely (checks for path traversal in archives).
4. Find the `build/` folder inside the extracted tree.
- You can override with `--build-path`.
5. SSH into the Jibo using Paramiko.
6. Ensure `/` is writable:
- tests with a `touch` on `/.jibo_rw_test`
- if needed, runs `mount -o remount,rw /`
7. Upload the contents of `build/` into `/` using SFTP.
- Directories are created as needed.
- Files are uploaded and chmod is best-effort preserved.
- Symlinks are uploaded as symlinks if possible; otherwise it uploads dereferenced content.
8. Optionally return Jibo to normal mode by changing `/var/jibo/mode.json` back to `normal`.
9. Record the applied tag in a local state file so repeated runs can short-circuit.
## What “build/” means
Releases are expected to contain a “rootfs overlay” folder named `build/`.
That directory typically includes paths like:
- `etc/`
- `opt/`
- `usr/`
- `var/`
The updater essentially copies those files to the same locations on the robot.
## State file
By default, the updater stores last-applied tag per host in:
- `../jibo_work/update_state.json`
If the state file says the host already has the latest tag, it exits unless you pass `--force`.
More: [[07 - Working Directory + State Files]]
## Safety knobs
- It prompts before upload unless `--yes` is passed.
- `--dry-run` downloads/extracts and connects, but does not upload or edit mode.json.
## Returning to normal mode
At the end, the updater can switch the robot back to normal mode:
- `--return-normal` (force it)
- `--no-return-normal` (never prompt / never change)
- otherwise it prompts (unless `--yes` is passed)
Note: returning to normal mode can disable the “checkmark/dev” behavior depending on how JiboOs uses `mode.json`.
## CLI reference
See [[03 - CLI Arguments]] for the complete list and examples.

View File

@@ -0,0 +1,65 @@
# Working Directory + State Files
Both the installer and updater use `../jibo_work/` as their “scratch + cache” directory.
This is helpful for:
- keeping your large dumps out of the repo root
- making it obvious what can be deleted vs what is precious
## jibo_automod.py outputs
Depending on mode, you may see:
- `jibo_full_dump.bin`
- The full eMMC dump (~15GB). Created by full workflow.
- `gpt_dump.bin`
- Small dump (default 4096 sectors / ~2MB) used by `--mode-json-only`.
- `var_partition_original.bin`
- Original `/var` read from the robot (fast mode).
- `var_partition.bin`
- Working copy that gets modified.
- `var_partition_backup.bin`
- Backup copy made before modifications.
- `verify_partition.bin`
- Read-back buffer used during verification.
- `var_patch_###.bin`
- Patch chunks produced by sector-diff patch-writing in fast mode.
- `mode.json.original` / `mode.json.modified`
- Best-effort debug copies of the JSON before/after editing.
### What you should keep
- Keep `var_partition_backup.bin` somewhere safe.
- If you made a full dump, consider archiving `jibo_full_dump.bin` (space permitting).
## jibo_updater.py outputs
The updater uses:
- `../jibo_work/updates/`
- `downloads/` cached archives
- `extracted/` extracted trees
And it tracks state in:
- `../jibo_work/update_state.json`
That file maps host -> last applied tag.
## Cleaning up
- Safe-ish to delete: extracted archives and patch chunks (you can always re-download / re-create).
- Be careful deleting: backups and any full dump you still care about.
## Related docs
- Installer overview: [[01 - Installer (How It Works)]]
- Updater overview: [[06 - Updater (How It Works)]]

View File

@@ -0,0 +1,184 @@
# Troubleshooting
This page is a practical checklist for common failure points.
If something fails, also see:
- Installer internals: [[01 - Installer (How It Works)]]
- Windows specifics: [[05 - Windows Support]]
- CLI flags: [[03 - CLI Arguments]]
- Updater internals: [[06 - Updater (How It Works)]]
---
## 1) Jibo not found / cant talk to APX (RCM)
### Symptoms
- Tool prints “Jibo not found in RCM mode”
- `EMMC_READ` / `EMMC_WRITE` fails immediately
- On Linux, `lsusb` does not show `0955:7740`
### Checklist
- Use a known-good **data** micro-USB cable (charge-only cables are common).
- Ensure the robot is actually in RCM:
- hold RCM button
- press reset/power
- release when you get red LED and no normal boot
- Try a different USB port (avoid hubs).
### Linux permissions
- If it works only with `sudo`, consider installing the udev rule:
- see `../99-jibo-rcm.rules`
### Windows driver
- Install WinUSB for the “APX” device using Zadig.
- Run the tool as Administrator.
---
## 2) ShofEL build issues
### Symptoms
- `make` fails in `../Shofel/`
- Tool complains about missing payload binaries (like `emmc_server.bin`)
### Checklist
- You need normal build tools: `gcc`, `make`, libusb dev headers.
- If payload `.bin` files are missing you also need the ARM toolchain:
- `arm-none-eabi-gcc`
Notes:
- The tools `--rebuild-shofel` forces a rebuild.
---
## 3) Dump is slow / crashes near the end
### Full dump mode
- Full dump reads ~15GB; multi-hour runtime is normal.
- If it fails at ~99%, you often still have most of the content.
### Use fast mode instead
If your only goal is enabling SSH/dev mode, you can usually skip the full dump:
- `--mode-json-only`
This reads only GPT + `/var` (~500MB) and writes back only what changed.
---
## 4) mode.json edit fails
### Why this happens
`/var` is an ext filesystem image. Editing a file *inside* it is easiest on Linux (mount) and harder on Windows.
### What the installer tries (in order)
- Linux: mount loop device and edit `/var/jibo/mode.json`
- Any OS: try `debugfs` if installed
- Fallback: raw byte-pattern overwrite
### Fixes
- On Windows, install `debugfs` via MSYS2:
- package: `e2fsprogs`
- If raw patching fails:
- it likely cant find the exact JSON string pattern, or it would need to grow the data region.
- installing `debugfs` is usually the right fix.
---
## 5) Fast mode patch-write writes too much (or falls back)
### What patch-write is
In `--mode-json-only` the tool tries to compute which 512-byte sectors changed between:
- `var_partition_original.bin`
- `var_partition.bin`
Then it writes only those sector ranges.
### When it falls back to full `/var` write
It will write the entire partition if:
- the images differ in size (shouldnt happen in normal flows)
- too many sectors changed
- too many disjoint ranges were detected
If your edit method rewrites a lot of blocks (filesystem reallocation), you may see a full write anyway.
To force full write explicitly:
- `--full-var-write`
---
## 6) Verify step fails (hash mismatch)
### Meaning
- The read-back does not match the local file.
### Common causes
- Unstable USB connection/cable
- Jibo dropped out of RCM mid-process
- Write succeeded but read-back got corrupted
### What to do
- Re-enter RCM and re-run with `--mode-json-only --full-var-write` (simplest “make it match” path).
- Consider disabling verify to proceed if youre confident the write worked:
- `--no-verify`
---
## 7) SSH works but updater fails
### Connection failures
- Check Jibo is booted to the checkmark and reachable:
- port 22 open
- `root` / `jibo`
### “Rootfs is read-only” issues
Updater tries to remount `/` read-write:
- `mount -o remount,rw /`
If that fails, the updater will refuse to upload.
### Archive layout issues
If the updater cannot find `build/` automatically:
- pass `--build-path` to point at it inside the extracted tree
### Dry-run
To debug without uploading files:
- `--dry-run`
---
## 8) Where to look for logs / outputs
- Installer work files: `../jibo_work/`
- Updater cached downloads/extraction: `../jibo_work/updates/`
- Updater state tracking: `../jibo_work/update_state.json`
See: [[07 - Working Directory + State Files]]

View File

@@ -5,28 +5,18 @@ This is a vault base around the jibo revival project, everything we have discove
### Table Of Contents
[[Hardware and Tegra Exploitation]]
To check a mod guide , go to [[1. Get your environment ready!]]
[[Network Profiling & Traffic Analysis]]
To read about the project go to : [[Welcome to the Jibo Revival Project]]
To learn about the os , check out [[Useful Items List]]
>[!info]
 Files under uncategorized or Documentation with the #AtDev tag are files i use to keep track of the steps to make or recreate something , eventually they will get compiled to a guide or proper documentation
- - -
Uncategorized:
[[Jibo Workshop HRI 2024]]
[[Useful Items]]
Documentation:
ESML:
[[ESML-SDK.pdf]]
[[Jibo-Animations.pdf]]
Dictionary:
[[ESML]]
[[Robot Os]]
More stuff will be coming soon :)