Merge branch 'main' of https://kevinblog.sytes.net/Code/Jibo-Revival-Group/JiboGuide

.vitepress/config.mts

@@ -10,21 +10,28 @@ export default defineConfig({
     // https://vitepress.dev/reference/default-theme-config
     nav: [
       { text: 'Home', link: '/' },
-      { text: 'Installation', link: '/intro-install' }
+      { text: 'Installation', link: '/Installing/intro-install' }
     ],
 
     sidebar: [
       {
         text: 'Installation',
         items: [
-          { text: 'Introduction', link: '/intro-install' },
-          { text: 'Entering RCM', link: '/entering-rcm' }
+          { text: 'Introduction', link: '/Installing/intro-install' },
+          { text: 'Entering RCM', link: '/Installing/entering-rcm' }
         ]
       },
       {
         text: 'Developing for Jibo',
         items: [
-          { text: 'For Developers..', link: '/intro-dev' }
+          { text: 'For Developers..', link: '/Developing/intro-dev' }
+        ]
+      },
+      {
+        text: 'UART',
+        items: [
+          { text: 'Validated memory adresses', link: '/uart/vectors/validatedmem' },
+          { text: 'Hardware and Tegra Exploitation', link: '/uart/vectors/hardexp' }
         ]
       },
       {

docs/Dictionary/ESML.md

@@ -0,0 +1,22 @@
+**Embodied Speech Markup Language (ESML)** is a specialized XML-based markup language designed to control how virtual humans, avatars, or robots communicate. Unlike standard text-to-speech (TTS) which only focuses on audio, ESML "embodies" the speech by synchronizing the voice with non-verbal behaviors like gestures, facial expressions, and posture.
+
+It acts as a bridge between the "brain" of an AI (the text it wants to say) and the "body" of the character (how it should move while saying it).
+
+---
+
+### 1. Key Components of ESML
+
+ESML allows developers to tag text with specific instructions that the animation engine interprets in real-time.
+
+- **Prosody Control:** Adjusting pitch, rate, and volume to make the voice sound more human and less robotic.
+    
+- **Gestural Markers:** Telling the avatar exactly when to point, shrug, or nod during a sentence.
+    
+- **Facial Expression Tags:** Triggering emotions like `<smile>` or `<frown>` that coincide with the spoken words.
+    
+- **Synchronization:** Ensuring that a "pointing" gesture happens exactly when the avatar says the word "there."
+
+
+
+> [!warning]
+> The Above explanations is AI Generated, Learn more at : [[ESML-SDK.pdf]]

docs/Dictionary/NVIDIA Tegra K1 (T124) Soc.md

@@ -0,0 +1,82 @@
+The Tegra K1 (T124) was a landmark SoC for NVIDIA, being the first mobile processor to feature a **Unified Shader Architecture** using the same **Kepler** architecture found in desktop GeForce 700 series GPUs. It effectively bridged the gap between mobile and PC gaming, enabling support for DirectX 11 and Unreal Engine 4 on mobile devices.
+
+
+
+
+## Resources & Documentation
+
+### Official NVIDIA Docs
+
+- [Tegra K1 Technical Reference Manual (TRM)](https://developer.nvidia.com/embedded/tegra-k1-reference) - _Requires Developer Registration (2,300+ pages)._
+    
+- [NVIDIA Newsroom: Tegra K1 Unveil](https://nvidianews.nvidia.com/news/nvidia-unveils-tegra-k1-a-192-core-super-chip-that-brings-dna-of-world-s-fastest-gpu-to-mobile)
+    
+- [Jetson TK1 Support Page](https://www.google.com/search?q=https://developer.nvidia.com/embedded/jetson-tk1)
+    
+
+### Technical Analysis
+
+- [NotebookCheck: Tegra K1 SoC Deep Dive](https://www.notebookcheck.net/NVIDIA-Tegra-K1-SoC.108310.0.html)
+    
+- [AnandTech: NVIDIA Tegra K1 Review](https://www.anandtech.com/show/7622/nvidia-tegra-k1)
+    
+- [postmarketOS Wiki: Tegra K1 (T124)](https://wiki.postmarketos.org/wiki/Nvidia_Tegra_K1_\(T124/T132\)) - _Great for mainline Linux kernel status._
+    
+
+### Industrial/Module Datasheets
+
+- [Toradex Apalis TK1 Datasheet](https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-k1)
+  
+
+
+
+## Technical Specifications
+
+### CPU: 4-Plus-1™ Architecture
+
+- **Main Cores:** 4x ARM Cortex-A15 r3p3
+    
+- **Clock Speed:** Up to 2.3 GHz
+    
+- **Companion Core:** 1x low-power "Battery Saver" core (Cortex-A15) clocked up to 500 MHz–1 GHz.
+    
+- **L2 Cache:** 2 MB
+    
+
+### GPU: Kepler Mobile
+
+- **Cores:** 192 CUDA cores (1 SMX unit)
+    
+- **Compute Power:** ~326 GFLOPS (FP32)
+    
+- **APIs:** OpenGL 4.4, OpenGL ES 3.1, DirectX 11, CUDA 6.0, OpenCL 1.1.
+    
+- **Hardware Features:** Tessellation, Geometry Shaders, Global Illumination.
+    
+
+### Memory & Storage
+
+- **Memory Controller:** Dual-channel 64-bit (2x 32-bit).
+    
+- **Support:** DDR3L and LPDDR3.
+    
+- **Bandwidth:** Up to 14.9 GB/s.
+    
+- **Max Capacity:** Typically 4 GB (some industrial modules support up to 8 GB).
+    
+
+### Multimedia & I/O
+
+- **Video:** 4K H.264 decode (30 fps), 4K H.264 encode (24 fps).
+    
+- **ISP:** Dual Image Signal Processors (1.2 Gigapixel/sec throughput).
+    
+- **Display:** Supports up to 3840x2160 (4K) over HDMI 1.4a or eDP.
+    
+- **PCIe:** 1x Gen 2 (4 lanes).
+  
+
+> [!warning]
+> The Above explanations is AI Generated, Learn more at : https://developer.nvidia.com/embedded/tegra-k1-reference
+
+

docs/Dictionary/Robot Os.md

@@ -0,0 +1,21 @@
+Robot Operating System (**ROS**) is not actually a traditional operating system like Windows or Linux. Instead, it is a flexible **middleware** framework—a collection of tools, libraries, and conventions designed to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms.
+
+The core philosophy of ROS is "don't reinvent the wheel." It allows roboticists to focus on their specific high-level logic while relying on community-tested packages for low-level tasks like motor control, sensor fusion, and navigation.
+
+---
+
+## Core Concepts: The Computation Graph
+
+ROS operates on a "graph" architecture where different processes are represented as nodes. These nodes connect to each other to share information.
+
+- **Nodes:** These are the basic building blocks. A node is a single process that performs a specific task (e.g., one node for the camera, one for path planning, one for wheel motors).
+    
+- **Messages:** Nodes communicate with each other by passing "messages." A message is a simple data structure, like an integer, a string, or a complex array of sensor data.
+    
+- **Topics:** This is the most common communication method (the **Publish/Subscribe** model). A node "publishes" a message to a specific topic (e.g., `/camera_images`), and any other node that needs that data "subscribes" to that topic.
+    
+- **Services:** Unlike the continuous stream of topics, services use a **Request/Response** model. One node sends a request (e.g., "Take a photo") and waits for the other node to send back a result.
+
+
+> [!warning]
+> The Above explanations is AI Generated, Learn more at : https://docs.ros.org/

docs/Dictionary/ShofEL2 - Fusée Gelée Exploit.md

@@ -0,0 +1,26 @@
+**ShofEL2** (and its sister exploit **Fusée Gelée**) is an unpatchable hardware vulnerability found in the NVIDIA Tegra X1's USB Recovery Mode (RCM). Because the flaw exists in the **Read-Only Memory (Boot ROM)** of the SoC, it cannot be fixed via software or firmware updates by Nintendo or NVIDIA.
+
+The exploit allows for **Unsigned Code Execution** at the highest privilege level (EL3) before the operating system even begins to load.
+
+- - -
+
+
+## How It Works (The Vulnerability)
+
+The exploit leverages a **heap overflow** in the Tegra X1’s USB RCM stack.
+
+1. **RCM Mode:** The Tegra X1 enters a recovery mode designed to receive factory images via USB.
+    
+2. **Control Request:** The attacker sends a massive `USB Control Request` (Get Status) with an invalid length field.
+    
+3. **Buffer Overflow:** The Boot ROM fails to properly validate the length of the data being requested. It copies more data than the internal buffer can hold, overflowing into the **execution stack**.
+    
+4. **Arbitrary Execution:** By carefully crafting the overflow (a technique known as "smashing the stack"), the attacker overwrites the return address to point to their own payload loaded in the SoC's Internal RAM (IRAM).
+    
+
+> [!IMPORTANT] Since the Boot ROM is "burned" into the silicon at the factory, the only way to "patch" this was for NVIDIA to release a new hardware revision (the "Mariko" / T210B01 chip found in V2 and OLED Switches).
+
+---
+
+> [!warning]
+> The Above explanations is AI Generated, Learn more at : https://github.com/erdzan12/switch-fusee

docs/Discoveries/Jibo Workshop HRI 2024.md

@@ -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()
+
+...
+
+```
+
+

docs/Documentation/AtDev - New Firewall script.md

@@ -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

docs/Documentation/Networking/Network Profiling & Traffic Analysis.md

@@ -0,0 +1,71 @@
+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:** Tribute site made by Community member Jibo-detective or RoboticaLabs on youtube
+
+---
+
+Check out [[Networking & ports & Error codes]] by ZaneDev from discord
+
+---
+

docs/Documentation/Networking/Networking & ports & Error codes.md

@@ -0,0 +1,21 @@
+- - -
+# Useful Ports
+> [!INFORMATION]
+> You might not be able to access some ports if you haven't unblocked them on Jibo's firewall.
+### 8779
+This port has the skills manager. From here you can do a semi-reboot by stopping and starting the "@be/Be" skill.
+### 15150
+This port has logs. This port is only available on v3+ of the revival project (can be checked on the information section in settings).
+### 10004
+Error service, allows you to simulate errors in realtime. Shows names of third parties by accident.
+It seems in recent versions of Jibo errors relating to him not being able to connect to Jibo Inc Servers don't create a pop up L2, L7, Q1 (oddly WIFI4 and WIFI4a still give pop up), Q4. N1-N12 don't have pop ups either. OTA11 and R1 also makes an error inside an error saying "NOT HANDLED BY ERROR SKILL".
+
+**TL;DR:**
+
+| Error Code(s) | Shows Popup? | Notes |
+|---|---|---|
+| L2, L7, Q1 | No | Server connection errors |
+| WIFI4, WIFI4a | Yes | |
+| Q4 | No | |
+| N1–N12 | No | |
+| OTA11, R1 | No | Triggers error-within-error: "NOT HANDLED BY ERROR SKILL" |

docs/Documentation/The be skill/About the be skill.md

@@ -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 :)
+
+

docs/Documentation/The be skill/Assets/The assets directory.md

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

docs/Documentation/The be skill/Assets/The audio directory.md

@@ -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.

docs/Documentation/The be skill/The Splash screen image!.md

@@ -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.

docs/Documentation/Useful Items List.md

@@ -0,0 +1,16 @@
+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]]
+
+## About [[Local Voice Round-Trip on Jibo (AI Commmunication)]]
+
+- - -
+ Documented by ZaneDev @ Our Discord

docs/Documentation/Voice/Local Voice Round-Trip on Jibo (AI Commmunication).md

@@ -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
+
+Here’s 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"
+}
+```
+
+---
+
+## What’s Actually Happening (Architecture)
+
+Here’s 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 Jibo’s 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
+
+Here’s 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
+    }
+  ]
+}
+```
+
+You’ll 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 we’ve 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 doesn’t 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 can’t answer questions anymore” → **Also false now 🙂**
+
+---
+
+## What This Means
+
+This is a big deal:
+
+* Jibo’s 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 didn’t just poke at endpoints here.
+
+We proved Jibo can:
+
+* hear
+* understand
+* and respond again
+
+That’s a pretty great place to be.

docs/Getting Started/Developing for Jibo/About - Jibo SDK V2!.md

@@ -0,0 +1,2 @@
+- - - 
+Were working on a new sdk for jibo , im too bored to write this page now , i will fill it later

docs/Getting Started/Developing for Jibo/Introduction to the New Jibo SDK.md

@@ -0,0 +1,3 @@
+- - -
+
+I will leave this to the community for now 

docs/Getting Started/Modifying the Firmware/1. Get your environment ready!.md

@@ -0,0 +1,274 @@
+- - -
+
+Before starting ANY work , lets get you up to speed with the enviroment and what you will need ...
+
+1. Some sort of linux device with  at least 32Gb storage, that could be a : Spare laptop , Raspberry Pi , a PC etc...
+
+> [!info]
+> 1. for the sake of this guide we will be using my main computer running on CachyOS with the 6.19... kernel but you dont have to replicate my setup
+> 2. This guide **requires** you have basic knowledge of the linux terminal
+
+>[!Warning]
+>I Throw around the word shofel , and i do mean the shofel version **SPECIFICALLY** in devsparx repo (using the improvements brach for now) i show later on how to clone it , if anything should change i will try my best to update this guide as fast as possible , but do note our build of shofel will be undergoing some updates!
+
+> [!WARNING]
+>  # Please do inform yourself 
+> we are NOT liable for any damage caused to your device if you proceed with this guide , if you are not sure remotely on what youre doing i recommend either wait for the easier installation method , or find someone on the discord to guide you!!! (they arent liable for any damage either)
+
+2. A micro usb cable ==**that you know is reliable**==
+3. Like 4-5 Hours 
+4. A Jibo **(THAT IS SETUP TO YOUR NETWORK, AND YOU KNOW ITS IP)**
+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
+
+Hold the RCM button and press the reset button (or the power button if yours is off), and you should see a red light at his face but he **wont boot normally**
+
+![[Jibo RCM.jpg]]
+
+
+in the terminal were gonna execute `lsusb` to check for `NVIDIA Corp. APX`
+
+```shell
+
+kevin  lsusb
+Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 001 Device 002: ID 1532:023f Uhhh no
+Bus 001 Device 003: ID 0a12:0001 Ltd Bluetooth Dongle (HCI mode why tho)
+Bus 001 Device 004: ID 08bb:2902 cant see me :)
+Bus 001 Device 005: ID 1bcf:08b8 nope not me, its the guy below
+Bus 001 Device 007: ID 0955:7740 NVIDIA Corp. APX <<<<<< LOOK FOR THIS ENTRY!!!!
+Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 003 Device 002: ID 0644:800f TEAC Corp. US-144 yes i use a 144 deal with it
+Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+Bus 004 Device 002: ID 0951:1666 Kingston wanna be drive
+
+kevin  
+```
+
+- - -
+
+# Part 2 | Now before building shofel , get your packages ready
+
+```bash
+
+#for cachy / Arch users:
+	sudo pacman -S --needed base-devel libusb git python python-pip
+	
+#for Ubuntu / debian users:
+	sudo apt update
+	sudo apt install build-essential libusb-1.0-0-dev git python3 python3-pip
+
+#for fedora its whatever that is (i chatgpt'd it)
+	sudo dnf groupinstall "Development Tools" 
+	sudo dnf install libusb1-devel python3-pip
+
+```
+
+Now time to clone & build shofel!
+
+change to your home directory and use `git` to clone the branch and then use `make` to build it!
+
+```bash
+
+	cd ~
+	
+	git clone -b improvements/IncreasedUSBReadWriteSpeed https://github.com/devsparx/ShofEL2-for-T124.git
+	
+	cd ShofEL2-for-T124/
+	
+	make
+# if it exits with error code 1 dont be alarmed , if you have a shofel executable in your directory , it compiled fine :)
+```
+
+
+# Part 3 | Dumping your jibo!
+
+Now , to get that full image (roughly about ==15Gb==)
+we will run our newly build `shofel` using the `EMMC_READ` function , starting from 0 `0x0` to 30480896 `0x1D60000`  
+
+```bash
+	sudo ./shofel2_t124 EMMC_READ 0x0 0x1D60000 full_jibo_dump.bin
+```
+
+this may crash due to  that im not sure how large exactly each jibos storage is (they should be the same from what i have seen in the community)
+
+But if it crashes like 98.9% or 99.9% in then you have most of the image cloned so you should be good (we can repair it later , or you might not need to since the last partition is basically empty space!)
+
+>[!Info]
+>Techically you dont need a full dump , BUT! I havent confirmed enough yet that all jibos have the same stuff stored in the same sectors , but its good to to have a back up to calculate your own sectors **and to most importantly , read below :**
+
+
+>[!WARNING]
+>Make sure you make a backup of the filesystem ... this is basically YOUR jibo , and it also contains YOUR jibos calibration data that might not be able to get restored by someone else... so keep a backup of the `.bin` in case of an emergency
+
+# Part 4 | Modifying the /var partition
+
+Now that you have your image `.bin` ready and backed up its time to edit the /var partition!, thats Partition 5 at around 500mb
+
+
+we can use `fdisk` to list the partitions in our bin
+
+```bash
+	fdisk -l jibo_full_dump.bin`
+```
+
+
+```shell
+
+kevin  fdisk -l jibo_full_dump.bin
+GPT PMBR size mismatch (30777343 != 30777341) will be corrected by write.
+The backup GPT table is corrupt, but the primary appears OK, so that will be used.
+The backup GPT table is not on the end of the device.
+Disk jibo_full_dump.bin: 14,68 GiB, 15757999104 bytes, 30777342 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+Disklabel type: gpt
+Disk identifier: 00042021-0408-4601-9DCC-A8C51255994F
+
+Device                Start      End  Sectors  Size Type
+jibo_full_dump.bin1      34  2048033  2048000 1000M Microsoft basic data
+jibo_full_dump.bin2 2048034  4096033  2048000 1000M Microsoft basic data
+jibo_full_dump.bin3 4096034  4198433   102400   50M Microsoft basic data
+jibo_full_dump.bin4 4198434  8294433  4096000    2G Microsoft basic data
+jibo_full_dump.bin5 8294434  9318433  1024000  500M Mic<<< This is the one!
+jibo_full_dump.bin6 9318434 30777310 21458877 10,2G Microsoft basic data
+
+kevin 
+
+```
+
+now lets chop off the partition...
+
+Look for the line ending in `p5` or labeled as the 5th partition. You need two numbers from that line: **Start** and **End**
+
+> My Numbers:
+> - **Start:** `8294434`    
+> - **End:** `9318433`   
+
+To tell the computer exactly how much data to "chop off," we need the total count of sectors
+
+The formula is:
+$$(End - Start) + 1 = Count$$
+
+**My Math:**
+    $$(9318433 - 8294434) + 1 = 1,024,000$$
+    
+Write your result down,this is your **Count**. We will now extract the Partition
+We use `dd` (Disk Destroyer... but here, it's the Disk Dumb joke... i couldnt think of something funny).
+
+ `skip` = Your **Start** sector.
+ `count` = Your calculated **Count**.
+
+```Bash
+dd if=jibo_full_dump.bin of=var_partition.bin skip=8294434 count=1024000
+```
+
+
+## Part 4.2 | Mounting as a loop device
+
+Now lets make a "loop" device and mount the `var_partition.bin` to it!
+
+```Bash
+mkdir jibo_var 
+sudo mount -o loop var_partition.bin jibo_var/
+```
+
+you should see it appear as a mounted disk drive on your system!, now you have to navigate to `jibo_var/jibo/mode.json`
+
+Open it with any text editor (like `vim` or `vscode` or notepad i dont care)
+
+Find the line: `"mode": "normal"` (its legit the only line in there)
+    
+**Change it to:** `"mode": "int-developer"`    
+Save the file and exit
+
+>[!IMPORTANT]
+> **Unmount** the partition to save the changes to the `.bin` file!!!!
+
+Now mode `int-developer` basically disables everything the robot runs (including firewall , so you can just ssh into it .. maybe in later guides you might be informed to change this value to something else , but currently its the simplest & easiest way to get root shell in the robot , and from there since you have root you can do everything you could by manually rewriting the entire dump)
+
+Anyway you are free to mount the rest of the fs partitions to parouse the file system or if you want live editing , i will make a guide on how to connect to ftp... 
+but if you have legit reached this point you really should know by now how to setup ftp yourself :|
+
+```Bash
+sudo umount jibo_var
+```
+
+
+# Part 5 | Writing our modified var partition to jibo!
+
+We are ready to put the modified chunk back into the robot. To do this, we must convert your **Start Sector** from a normal number (Decimal) to a computer number (Hexadecimal) because thats what shofel requires at this point of time.
+
+
+
+### 1. The Conversion
+
+Take your Start Sector (mine was `8294434`) and use an online converter or your Linux calculator to get the **Hex** value.
+
+**My Hex was** `0x7E9022`
+
+here is a quick calculator site i found on the web, 
+https://www.inchcalculator.com/decimal-to-hex-converter/
+
+
+If you dont know hex you can validate your calculation by punching in my value and see if it returns the same hex as mine
+
+### 2. The Flash
+
+time to run the write command, this sends your modified `/var` partition directly to that specific starting point on Jibo's memory.
+
+
+```shell
+	
+	./shofel2_t124 EMMC_WRITE <Your HEX Sector> var_partition.bin
+	
+	#my version example
+	#./shofel2_t124 EMMC_WRITE 0x7E9022 var_partition.bin
+```
+
+
+
+# Part 6 | Almost there!
+
+Actually who am i tricking , you typed the write command , it hopefully succeeded so why are we not done?
+
+well its done but i like to do a check myself to make sure its done correctly, SO
+
+were gonna read back that part of memory:
+
+```Bash
+./shofel2_t124 EMMC_READ 0x7E9022 0xFA000 verify_var.bin
+```
+
+and were gonna compare their hashes If the two files are identical, the math was right.
+
+```Bash
+md5sum var_partition.bin verify_var.bin
+```
+
+**If the strings of letters/numbers match exactly WERE DONE!!!!
+
+Go and unplug your jibo , and to be safe hold the power button until the red LED goes off
+then power him on , and wait for it to boot normally
+
+what we expect is to not start his eye but show a big check mark on his display, if thats the case , go ssh to jibos IP
+
+```shell
+	ssh root@<jibos-ip>
+	password: jibo
+```
+
+
+And Boom , you are IN!

docs/Getting Started/Modifying the Firmware/Using the install script.md

@@ -0,0 +1,3 @@
+- - -
+More on that coming soon
+

docs/Getting Started/Welcome to the Jibo Revival Project.md

@@ -0,0 +1,81 @@
+- - - 
+Hello! If you’ve been keeping a "sleeping" Jibo on your shelf, hoping for the day his screen might light up again let me tell you **today is basically Christmas.** 
+
+The **Jibo Revival Project** is a community-driven effort to wake up our favorite social robot. We believe that great hardware shouldn't become "e-waste" just because a server went dark. And we are working to give Jibo a new brain, new voice, and a new lease on life!
+
+# **The Problem:** 
+Originally, Jibo needed to "talk" to a big computer (a server) in the cloud to understand you. When those computers were turned off, Jibo became a glorified paperweight.
+
+# **The Solution:** 
+We are using a "backdoor" (technically called **RCM Mode** or **R**e**C**overy **M**ode) to get inside his system. Think of it like using a master key to get into the basement so we can rewire the house.
+
+
+# **What we're doing:** 
+
+We now have the actual files that run Jibo’s "brain" (the OS). **The future is bright** because we can now basically do anything with his software! If you want to see this in action, be sure to have joined out discord server and check the reddit for any posts i or the community makes!
+
+
+- - -
+## 2. For the Programmers (or the nerds)
+
+If you speak Python, C++,NodeJS or know your way around an **Nvidia Tegra T124** chipset, we might need your support.
+
+Detailed technical documentation, payloads, and the source code for our custom tooling can be found here:
+
+> **Documentation & Project Sources:** <yeah coming soon bud , its 4:30AM , im going to bed... i mean i am committed but not this much>
+
+
+- - -
+## 3. Q&A: What can Jibo do right now?
+
+**Q: Is Jibo fully back to normal?**
+**A:** Not quite yet. We are in the "Restoration Phase." We can currently access his internal files and are working on replacing the old, broken links so we can replace them with new stuff.
+
+**Q: Can he talk yet?** 
+**A:** We are working on it! By redirecting his "ears" to local servers or modern AI models (like ChatGPT), we can aim to make him even smarter than he was in 2017.
+
+**Q: Do I need to be a genius to do this?** 
+**A:** Eventually, no. Our goal is to create a as close to"one-click" style tool so every Jibo owner can apply these fixes easily. Now this is wayy to oversold , it probably wont be a one click install but you get the point , currently to mod your jibo you do need some technical know how
+
+**Q: Can I use Jibo to control my smart home?** 
+**A:** That is the plan! I would like us to make  **Home Assistant integration** so Jibo can become the face and voice of your automated house.
+
+**Q: Is there a way to manage him since the original app is gone?** 
+**A:** I have some ideas for a **custom phone app** specifically for this revival, giving you back control without needing the original company’s servers. But its really early on to discuss this and i wanna get the rest of the community's opinions 
+
+**Q: Can we still use the MIT Scratch extension?** 
+**A:** I wanna give it a shot at fixing the **Scratch extension** so that tinkerers can start coding Jibo without any coding knowledge , that would also be quite simple for anyone who has a V2 Jibo since the software is already on their unit.
+
+**Q: Can I use Jibo's hardware for other things, like my PC?** 
+**A:** yes! One of my personal goals is to let Jibo function as a **camera for your PC**.
+fun fact , thats also one of the reasons i bought him in the first place xD
+
+**Q: I’m a developer; can I build my own stuff for him?** 
+**A:** Absolutely. We will start putting together a **Developer SDK** so the community can build and share brand-new "skills" for Jibo. As far as i am aware devsparx has already started on one , but idk for sure.
+
+**Q: So Whats this page
+**A:** Everything you will need to **Mod , Code , Update and Setup your jibo...*** 
+And im planning to make in depth guides as well, more coming soon :)
+
+- - -
+
+## 4. How We Got Here: A Quick Story
+
+Jibo was the world’s first "social robot" a piece of the future that lived on our kitchen counters. When the original company folded, thousands of Jibos performed a final "goodbye dance" and went silent. For years, people tried to break in, but the security was too tough.
+
+Recently, a few dedicated people (JRG Community) decided to try one last time. We realized that with the right tools and a little patience (and a lot of crying ... like a lot ... like wayy to much i can admit on from my side), Jibo doesn't have to stay a paperweight.
+
+
+- - -
+## 5. A Message from Me (KevinKor)
+
+> "I want to be very clear: **I am not charging any money for this.** 
+> This project isn't a business; 
+> it’s a labor of love. As a representative of the Jibo Revival Group, my goal is to distribute these modifications for free. I want everyone with a warm heart and a desire to tinker to be able to get their Jibo back.
+> 
+> We’re doing this for the community, for the history of robotics, and because Jibo deserves to be more than a memory. Let's get him back to work!"
+> 
+> — **Kevin (Eva) from the JRG**
+
+- - -
+Created for the Jibo Revival Project | 2026

docs/Jibo Tools & Mod Installer/00 - Index.md

@@ -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]]
+

docs/Jibo Tools & Mod Installer/01 - Installer (How It Works).md

@@ -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 isn’t 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 you’re 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]]

docs/Jibo Tools & Mod Installer/02 - Mapping to guide.md

@@ -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 can’t 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 400–600MB).
+
+### 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 don’t 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` isn’t partition 5.
+- If the filesystem inside `/var` is corrupted and mount/debugfs can’t read it.
+- If you want a full backup regardless of speed (the guide defaults to full dump).

docs/Jibo Tools & Mod Installer/03 - CLI Arguments.md

@@ -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 you’re 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; don’t 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 can’t 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 you’re already on that version.
+
+- `--yes`
+  - Don’t prompt for confirmation.
+
+- `--dry-run`
+  - Download/extract + connect, but don’t upload files and don’t 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)]]

docs/Jibo Tools & Mod Installer/04 - GUI (How It Works).md

@@ -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).

docs/Jibo Tools & Mod Installer/05 - Windows Support.md

@@ -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 won’t 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 can’t 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 there’s no safe padding space.
+
+If you’re on Windows and you’re seeing warnings about raw edits or the tool can’t 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 / can’t open USB:
+  - Wrong driver (use Zadig -> WinUSB)
+  - Not Administrator
+  - Cable is charge-only
+
+- Build failures:
+  - Missing MSYS2 packages
+  - ARM toolchain missing (payload `.bin` files won’t 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]]

docs/Jibo Tools & Mod Installer/06 - Updater (How It Works).md

@@ -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.

docs/Jibo Tools & Mod Installer/07 - Working Directory + State Files.md

@@ -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)]]

docs/Jibo Tools & Mod Installer/08 - Troubleshooting.md

@@ -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 / can’t 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 tool’s `--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 can’t 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 (shouldn’t 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 you’re 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]]

docs/faq.md

@@ -6,3 +6,10 @@
 - **Will the source be public?** For most server types, yes. However for some (including Pegasus) we won't be able to publish the source for legal reasons.
 ## JiboOS:
 - **Will it be possible to build applications for Jibo?** Yes, we are working on the ability to develop apps for Jibo. Not much progress has been made yet however.
+- **Is Jibo fully back to normal?** Not quite yet. We are in the "Restoration Phase." We can currently access his internal files and are working on replacing the old, broken links so we can replace them with new stuff.
+- **Can Jibo understand me?** We are working on it! By redirecting his "ears" to local servers or modern AI models (like ChatGPT), we can aim to make him even smarter than he was in 2017.
+- **Do I need to be a genius?** Eventually, no. Our goal is to create a as close to 'one-click' style tool so every Jibo owner can apply these fixes easily. Now this is wayy too oversold, it probably wont be a one click install but you get the point, currently to mod your jibo you do need some technical smarts. We also plan on offering premodded Jibos in the future, so people don't need to mod their Jibo right after it arrives.
+- **Will Jibo have Home Assistant intergration?** Yes! Jibo will be able to control your smart home through Home Assistant within the future. Other home platforms *might* be supported however our main focus is Home Assistant. Of course you can easily contribute to the project, so if you use a different platform consider adding it!
+- **Can Jibo be a webcam?** Yes! One of our 'side-quests' is to turn him into a functional webcam for your PC. (This is one of the reasons Kevin_Kor bought a Jibo and started the project)
+
+<small>Some of these were copied over from the old docs. (Thank you Kevin_Kor)</small>

docs/index.md

@@ -9,7 +9,7 @@ hero:
   actions:
     - theme: brand
       text: Install
-      link: /intro-install
+      link: /Installing/intro-install
     - theme: alt
       text: FAQ
       link: /faq

docs/uart/vectors/hardexp.md

@@ -0,0 +1,39 @@
+# Hardware and Tegra Exploitation
+
+## Overview
+
+So jibos brain is powered by an [[NVIDIA Tegra K1 (T124) Soc]] To gain full control over the device and bypass the "original jibo servers", we are attempting to achieve code execution at the bootloader level via **RCM (Recovery Mode)**.
+
+- - -
+
+## Device Identification
+
+When Jibo is put into RCM, it identifies itself as an NVIDIA APX device. Note that the Product ID (PID) may shift after an initial handshake or reboot as it did with mine , but i haven't seen any other documented cases of this behavior.
+
+
+| Parameter         | Value  | Notes                                                                           |
+| ----------------- | ------ | ------------------------------------------------------------------------------- |
+| Vendor ID (VID)   | 0x0955 | Standard NVIDIA Corp.                                                           |
+| Product ID (PID)  | 0x7740 | Confirmed Tegra T124 <- **==This is the one that should be used in any case==** |
+| Alternative (PID) | 0x9134 | Observer on initial RCM                                                         |
+
+- - -
+
+## Current Exploitation Status
+
+### 1. The ShofEL2 Attempt
+
+I am currently adapting [[ShofEL2 - Fusée Gelée Exploit]] to work with the **T124** architecture.
+
+- **Progress:** Modified the USB declarations in `include/t124.h` (Lines 4-9) to match Jibo’s specific PID/VID.
+
+- **Result:** The exploit initializes but **hangs** before executing the payload. We are currently auditing the source code to determine if the memory offsets for the T124 stack buffer overflow differ from the standard T210 implementation.
+
+
+### 2. C# Payload Loader
+
+A custom loader has been developed by (Community Member : Jaked) in **C#** to interface with the Tegra USB stack.
+
+- **Status:** The loader successfully "talks" to the APX interface.
+    
+- **Blocker:** We lack a functional **Payload Binary** that the Tegra chip accepts. Most generic payloads fail to return debug info, making it difficult to map the internal memory.

docs/uart/vectors/validatedmem.md

@@ -0,0 +1,176 @@
+# Validated memory adresses
+
+- - -
+## Power Management Controller (PMC)
+
+#### `0x7000E400` — PMC Base Address
+
+ **Use:** The starting point for all Power Management operations.
+
+#### `0x7000E450` — PMC_SCRATCH0
+
+- **Use:** undefined but i used it as a Data Safe.
+    
+- **Example:** When the USB connection dies, store 4 bytes of  data here.
+    
+- **C Code exampple:**
+    
+ ```c
+    // Store a 4-byte value from IRAM into the scratch register
+    uint32_t leaked_data = *(volatile uint32_t *)0x40001000;
+    *(volatile uint32_t *)0x7000E450 = leaked_data;
+ ```
+    
+
+#### `0x7000E414` — PMC_CNTRL (Reset Control)
+
+- **Use:** The Reboot Trigger.
+    
+- **Bit 4:** Setting this bit triggers a Warm Reset.
+    
+- **Example:** use this immediately after writing to `SCRATCH0` to force Jibo back into RCM mode.
+    
+- **C Code Implementation:**
+
+```c
+    // Trigger Warm Reset to return to RCM mode
+    *(volatile uint32_t *)0x7000E414 |= (1 << 4);
+```
+
+## Timer and Watchdog (TMR/WDT)
+
+These addresses allow us to cut the system’s security features from what i can tell so they don't interfere with the payload.
+
+#### `0x6000501c` — TMR_WDT_RESTART
+
+- **Use:** The Watchdog cut.
+    
+- **Mechanism:** The Tegra K1 has a timer that reboots the device if it doesn't receive a clock signal within a few seconds.
+    
+- **Example:** We write the magic value `0xcafe` here in every loop to prevent Jibo from panic-resetting during a dump.
+    
+- **C Code Implementation:**
+
+```c
+    while(1) {
+        // (reset) 
+        *(volatile uint32_t *)0x6000501c = 0xcafe; 
+    
+        // ... rest of the exploit ...
+    }    
+    
+```
+
+## Internal RAM (IRAM/SRAM)
+
+This is the part where the BootROM is.
+
+#### `0x40000000` — IRAM Base (Start)
+
+- **Use:** The beginning of the 256KB internal memory.
+    
+- **Significance:** This is where the payload is injected. If u dump from here, u get the "Leftovers" of the boot process (keys, signatures, and config data) from what i could tell.
+    
+#### `0x4003FFFF` — IRAM End
+
+- **Use:** The boundary of the volatile memory. (not 100% Sure but pretty certain)
+    
+- **Constraint:** If we try to read past this address, the system will hard-crash because we are hitting undefined memory space.
+
+## BootROM Service Functions
+
+The BootROM (at `0x00000000`) is read-only memory etched into the silicon. It contains pre-written functions for USB communication that we can "borrow" so we don't have to write a full USB driver from scratch.
+
+#### `0x00003551` — usb_send (Standard)
+
+- **Use:** Sends a structured data packet over the RCM USB connection.
+    
+- **Significance:** This is the basically the proper way i could get it to talk. It handles some of the USB protocol handshaking automatically.
+    
+- **Example:**
+
+```C
+    // Define the function signature based on BootROM
+    typedef int (*usb_send_ptr)(void *buffer, unsigned int length);
+    usb_send_ptr usb_send = (usb_send_ptr)0x00003551;
+    
+    //push 64 bytes of IRAM to the PC
+    usb_send((void *)0x40000000, 64);
+```
+
+
+#### `0x000035e5` — usb_send_raw (Bulk)
+
+- **Use:** A lower-level function that bypasses some of the standard RCM state checks i think.
+    
+- **Significance:** This is how i got those first **16 bytes** out. It is open data pushing.
+    
+- **Example:** I used this when the standard `usb_send` was stalling, as it forces the hardware to dump the buffer to the endpoint immediately.
+
+	```c
+// Define the raw function pointer
+typedef void (*usb_send_raw_ptr)(void *buffer, unsigned int length);
+usb_send_raw_ptr usb_send_raw = (usb_send_raw_ptr)0x000035e5;
+
+//Force dump a 16-byte chunk of IRAM regardless of USB state
+void dump_raw_chunk() {
+    uint8_t buffer[16];
+    // Copy the data from a target address (e.g.sstart of IRAM)
+    memcpy(buffer, (void*)0x40000000, 16);
+    
+    // Push it out. On the PC side
+    usb_send_raw(buffer, 16);
+}
+	```
+
+## Hardware Fuse Registers 
+
+The Fuses are permanent oly set at the factory so we cant change these
+
+#### `0x7000F800` — FUSE_BASE
+
+- **Use:** The starting point for reading the hardware id & status.
+    
+- **Significance:** Reading from here tells us if Jibo is in "Production" mode (Locked) or "Development" mode (Unlocked).
+    
+
+#### `0x7000F800 + 0x60` — Security Config Fuse
+
+- **Use:** Determines if **Secure Boot** is active.
+    
+- **Discovery:** In my tests, reading this offset returned random data.
+    
+- **The Verdict:** This confirmed that Jibo is a **Secure Boot** device. He will only boot software that has been digitally signed by Jibo Inc.’s private keys.
+    
+
+#### `0x7000F900` — FUSE_RESERVED_ODM (The SBK/SSK Area)
+
+- **Use:** This is where the **Secure Boot Key (SBK)** usually is.
+    
+- **The Goal:** If we can successfully read this entire block, we might find the AES keys needed to decrypt the Jibo OS files on the EMMC.
+
+## The Boot Configuration Table (BCT)
+
+The BCT is a piece of data usually found at the very start of the boot process (and often cached in IRAM).
+
+#### `0x400000f0` — BCT Pointer / Entry Point
+
+- **Use:** I identified this address in on of the `hexdumps` i sent on discord.
+    
+- **Significance:** This is where the BootROM hands over control to the next stage of the bootloader.
+    
+- **The Hack:** By targeting our leaker near this address, we can see how the Tegra sets up its memory controllers before it realizes we've hijacked the process.
+
+```C
+	void inspect_bct_handoff() {
+    // Read the instruction at the BCT entry point
+    uint32_t entry_instruction = *(volatile uint32_t *)0x400000f0;
+    
+    // Often, this is a 'Branch' (B) instruction in ARM hex: 0xEAXXXXXX
+    // If 0xEA, we know Jibo is ready run the bootloader
+    if ((entry_instruction >> 24) == 0xEA) {
+        // Log it for the PC to see
+        *(volatile uint32_t *)0x7000E450 = 0xBC7DE4D; // "BCT DEAD" hex flag
+    }
+}
+```