feat: add be and skill vocab words

.vitepress/cache/deps/_metadata.json

@@ -1,25 +1,25 @@
 {
-  "hash": "88a47dfe",
-  "configHash": "a8dc593e",
+  "hash": "3aa292d4",
+  "configHash": "703c54b0",
   "lockfileHash": "a4491b5f",
-  "browserHash": "46f34afb",
+  "browserHash": "63173ae2",
   "optimized": {
     "vue": {
       "src": "../../../node_modules/vue/dist/vue.runtime.esm-bundler.js",
       "file": "vue.js",
-      "fileHash": "fee14db9",
+      "fileHash": "1b86ce01",
       "needsInterop": false
     },
     "vitepress > @vue/devtools-api": {
       "src": "../../../node_modules/@vue/devtools-api/dist/index.js",
       "file": "vitepress___@vue_devtools-api.js",
-      "fileHash": "0775ba1f",
+      "fileHash": "03d0fb89",
       "needsInterop": false
     },
     "vitepress > @vueuse/core": {
       "src": "../../../node_modules/@vueuse/core/dist/index.js",
       "file": "vitepress___@vueuse_core.js",
-      "fileHash": "59ed147d",
+      "fileHash": "b5805c48",
       "needsInterop": false
     }
   },

.vitepress/config.mts

@@ -10,27 +10,88 @@ 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: 'Discoveries',
+        items: [
+          { text: 'Jibo Workshop HRI 2024', link: '/Discoveries/jibohri' },
+          { text: 'jibo-app.js', link: '/Discoveries/jibo-app' }
+        ]
+      },
+      {
+        text: 'Be Skill',
+        items: [
+          { text: 'About @Be/Be', link: '/be/about' },
+          { text: 'The Splash Screen', link: '/be/splash' },
+          { text: 'The Assets Directory', link: '/be/Assets/assets' }
+        ]
+      },
+      {
+        text: 'Dictionary',
+        items: [
+          { text: 'ESML', link: '/Dictionary/ESML' },
+          { text: 'NVIDIA Tegra K1 (T124) Soc', link: '/Dictionary/tegrasoc' },
+          { text: 'Robot Operating System', link: '/Dictionary/ROS' },
+          { text: 'ShofEL2 - Fusée Gelée Exploit', link: '/Dictionary/Shofel' },
+          { text: 'Be (@be/be)', link: '/Dictionary/be' },
+          { text: 'Skills', link: '/Dictionary/skill' },
+        ]
+      },
+      {
+        text: 'Networking',
+        items: [
+          { text: 'Network Profiling & Traffic Analysis', link: '/Networking/network-pt' },
+          { text: 'Networking & ports & Error codes', link: '/Networking/ports' }
+        ]
+      },
+      {
+        text: 'Documentation',
+        items: [
+          { text: 'First Voice Interactions (before GTA 6)', link: '/documenting/voice' }
+        ]
+      },
+      {
+        text: 'Jibo Tools & Mod Installer',
+        items: [
+          { text: 'Index', link: '/jtools-minst/00 - Index' },
+          { text: 'Installer (How It Works)', link: '/jtools-minst/01 - Installer (How It Works)' },
+          { text: 'Mapping to guide', link: '/jtools-minst/02 - Mapping to guide' },
+          { text: 'CLI Arguments', link: '/jtools-minst/03 - CLI Arguments' },
+          { text: 'GUI (How It Works)', link: '/jtools-minst/04 - GUI (How It Works)' },
+          { text: 'Windows Support', link: '/jtools-minst/05 - Windows Support' },
+          { text: 'Updater (How It Works)', link: '/jtools-minst/06 - Updater (How It Works)' },
+          { text: 'Working Directory + State Files', link: '/jtools-minst/07 - Working Directory + State Files' },
+          { text: 'Troubleshooting', link: '/jtools-minst/08 - Troubleshooting' }
+        ]
+      },
+      {
+        text: 'UART',
+        items: [
+          { text: 'Validated memory adresses', link: '/uart/vectors/validatedmem' },
+          { text: 'Hardware and Tegra Exploitation', link: '/uart/vectors/hardexp' }
         ]
       },
       {
         text: 'Other',
         items: [
           { text: 'Connecting to WiFi', link: '/connect-to-wifi' },
+          { text: 'AtDev Firewall', link: '/atdev' },
           { text: 'FAQ', link: '/faq' }
         ]
       }

README.md

@@ -1,2 +1,2 @@
-# Jibo Hacks Guide
-This is a guide in VitePress on how to hack Jibo, enabling functions that were disabled in the 2.0 update.
+# Jibo (Vite) Docs
+This is a guide in VitePress on how to hack Jibo, enabling functions that were disabled in the 2.0 update. Also added the original documentation to it.

docs/Dictionary/ESML.md

@@ -0,0 +1,23 @@
+# ESML
+**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 [here](/Dictionary/ESML-SDK.pdf)

docs/Dictionary/ROS.md

@@ -0,0 +1,22 @@
+# ROS
+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/Shofel.md

@@ -0,0 +1,27 @@
+# ShofEL2 - Fusée Gelée Exploit
+**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/Dictionary/be.md

@@ -0,0 +1,4 @@
+# Be
+<small> also known as @be/be</small>
+## What is Be?
+Be is the main [skill](/Dictionary/skill). It is responsible for the eye, menu, conversation (might be handled by another skill but the flow starts at Be), etc. More details in the [about be article](/be/about)

docs/Dictionary/skill.md

@@ -0,0 +1,26 @@
+# Skills
+## What are Skills?
+Skills are basically applications. There are multiple types of skills. Each skill falls into one of or multiple of these categories:
+- Vocal Skills
+- Menu Activated Skills
+- (Not made yet, potential feature) Home Assistant Skills
+Each type of skill is triggered in its own way and interacts with the user uniquely. Because of this, I will be covering each skill in it's own section in this article.
+## Vocal Skills
+These are the types of skills triggered by voice. Some examples include:
+- **"Hey Jibo, play pop music"** -> Starts the radio skill.
+- **"Hey Jibo, what's my personal report?"** -> Opens personal report.
+
+Skills of this type are typically also Menu Activated Skills. The sad thing about this is that due to Jibo's *severe* lack of native servers the Vocal Skills no longer work. Luckily all the logic for these types of skills are built into Jibo (I think) so recreating the logic should be easyish.
+## Menu Activated Skills
+These are the little applications you open via the menu on Jibo. These get activated by you clicking on it's button on the main menu. Examples include:
+- **Click on radio button on main menu** -> Radio skill starts
+- **Click on personal report button** -> Personal Report starts
+
+Because these use the menu instead of voice, the skills worked after shutdown.
+## Home Assistant Skills
+::: info
+This isn't real!! It is something I came up with as I was writing this article. These docs surround what it would look like if it were to be implemented. - Zane V
+:::
+This type of skill gets triggered in Home Assistant. The Jibo Home Assistant intergration will create an entity for each skill. Examples include:
+- **Entity for weather, click button for Jibo to read out weather report.** ![Jibo in Home Assistant concept](/Assets/concept-for-weather-haos.png)
+The only issue: This type of skill doesn't exist *just yet!*. Excited for when it does though.

docs/Dictionary/tegrasoc.md

@@ -0,0 +1,83 @@
+# NVIDIA Tegra K1 (T124) Soc
+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/Discoveries/jibo-app.md

@@ -0,0 +1,264 @@
+# jibo-app
+::: warning
+This was written by AI. This is for a script that is private.
+:::
+
+A Node.js command-line interface for interacting with the Jibo robot's cloud services. It wraps the `@jibo/jibo-server-client` SDK and exposes every API endpoint — account management, loop (family group) management, media, messaging (Jot), robot provisioning, encryption keys, OTA updates, and more — as individual sub-commands.
+
+
+
+## Prerequisites
+
+- **Node.js** v6 or later
+- npm dependencies installed (`npm install` in the parent project)
+
+
+
+## Credentials Setup
+
+Every command requires three credentials:
+
+| Field | Description |
+|---|---|
+| `region` | Server region slug, e.g. `alpha-entrypoint` or `stg1-entrypoint` |
+| `accessKeyId` | AWS-style access key ID |
+| `secretAccessKey` | AWS-style secret access key |
+
+Credentials are resolved in the following priority order (highest wins):
+
+### 1. Command-line flags
+```
+-s, --serverRegion <region>
+-i, --accessKeyId <id>        (must be paired with -k)
+-k, --secretAccessKey <key>   (must be paired with -i)
+```
+
+### 2. Environment variables
+```bash
+export JIBO_SERVER_REGION=alpha-entrypoint
+export JIBO_ACCESS_KEY_ID=YOUR_ACCESS_KEY_ID
+export JIBO_SECRET_ACCESS_KEY=YOUR_SECRET_ACCESS_KEY
+```
+
+### 3. Credentials file (default)
+
+By default the script reads `~/.jibo/credentials.json`. Create it like so:
+
+```bash
+mkdir -p ~/.jibo
+cat > ~/.jibo/credentials.json <<'EOF'
+{
+    "region": "alpha-entrypoint",
+    "accessKeyId": "YOUR_ACCESS_KEY_ID",
+    "secretAccessKey": "YOUR_SECRET_ACCESS_KEY"
+}
+EOF
+chmod 600 ~/.jibo/credentials.json
+```
+
+You can point to a different file with `-f <path>`, or disable file loading entirely with `-f ""` (then rely on env vars or flags).
+
+> **Tip:** After running `AccountLogin` or `LoopGetRobot` you can capture the credentials output and write them directly to a file with the `-w <file>` flag.
+
+
+
+## Running the script
+
+```bash
+node jibo-app.js [global options] <Command> [command args...]
+```
+
+Print the help/command list:
+
+```bash
+node jibo-app.js help
+```
+
+
+
+## Global Options
+
+| Flag | Description |
+|---|---|
+| `-f, --credentialsFile <path>` | Path to credentials JSON file (default: `~/.jibo/credentials.json`) |
+| `-s, --serverRegion <region>` | Override server region |
+| `-k, --secretAccessKey <key>` | Secret access key (pair with `-i`) |
+| `-i, --accessKeyId <id>` | Access key ID (pair with `-k`) |
+| `-e, --env` | Suppress informational logs; print output as `export VAR=value` shell lines |
+| `-w, --credentialsFile <path>` | Write returned credentials to a JSON file (`AccountLogin` / `LoopGetRobot` only) |
+
+
+
+## Commands
+
+### Account
+
+| Command | Arguments | Description |
+|---|---|---|
+| `SyncCredentials` | `<email> <password> [robotId]` | Log in and push credentials directly to a robot over the local network (WiFi or hard-wired at `172.24.84.101`) |
+| `AccountCreate` | `<email> <password> [firstName] [lastName] [gender] [birthday]` | Create a new Jibo account |
+| `AccountLogin` | `<email> <password>` | Log in and print credentials (use `-e -w` to capture them) |
+| `AccountCreateAccessToken` | `<loopId>` | Create an access token scoped to a loop |
+| `AccountActivateByCode` | `<code>` | Activate an account with an email verification code |
+| `AccountAdminActivateById` | `<id>` | Admin: activate an account by ID |
+| `AccountRemove` | | Delete the authenticated account |
+| `AccountUpdate` | `[firstName] [lastName] [email] [gender] [birthday] [messagingAllowed] [password]` | Update account profile fields |
+| `AccountUpdatePhoto` | `<filename>` | Upload a new profile photo |
+| `AccountRemovePhoto` | | Remove the profile photo |
+| `AccountGet` | `[ids...]` | Fetch one or more accounts by ID |
+| `AccountGetAccountByAccessToken` | `<token>` | Look up an account by access token |
+| `AccountSearch` | `<query>` | Search for accounts |
+
+### Loop
+
+A *Loop* is a family/household group that links an owner account to a Jibo robot.
+
+| Command | Arguments | Description |
+|---|---|---|
+| `LoopList` | `[loopId]` | List loops (or a specific loop); with `-e` prints `export JIBO_LOOP_ID=...` |
+| `LoopCreate` | `<name> <robotId>` | Create a new loop |
+| `LoopUpdate` | `<loopId> <name>` | Rename a loop |
+| `LoopRemove` | `<loopId>` | Delete a loop |
+| `LoopListMembers` | `[statusList] [typeList]` | List members of the authenticated account's loop |
+| `LoopInviteMember` | `<email> <loopId>` | Invite someone to a loop by email |
+| `LoopAcceptInvitation` | `<loopId>` | Accept a pending loop invitation |
+| `LoopDeclineInvitation` | `<loopId>` | Decline a pending loop invitation |
+| `LoopRemoveMember` | `<loopId> <memberId>` | Remove a member from a loop |
+| `LoopFindOwner` | `<accountId>` | Find the loop owned by an account |
+| `LoopGetRobot` | `<loopId>` | Get robot credentials for a loop; use `-e -w` to capture |
+| `LoopListOwnerRobots` | `<accountId>` | List all robots owned by an account |
+| `LoopClearRobot` | `<robotId>` | Disassociate a robot from its loop |
+| `LoopUpdateNickname` | `<loopId> <memberId> <nickname>` | Set a member's nickname in a loop |
+| `LoopUpdatePhoneticName` | `<loopId> <memberId> [phoneticName]` | Set a member's phonetic name in a loop |
+| `LoopSuspendLoop` | `<loopId>` | Suspend a loop |
+
+### Media
+
+| Command | Arguments | Description |
+|---|---|---|
+| `MediaCreate` | `<loopId> [filename] [path] [type] [reference] [isEncrypted]` | Upload a media file to a loop |
+| `MediaGet` | `<paths...>` | Fetch metadata for one or more media items by path |
+| `MediaList` | `<loopIds...>` | List all media items across one or more loops |
+| `MediaRemove` | `<paths...>` | Delete one or more media items |
+
+### Jot (Messaging)
+
+| Command | Arguments | Description |
+|---|---|---|
+| `JotCreateMessage` | `<loopId> [content] [path] [type] [reference] [url] [tags...]` | Post a message to a loop |
+| `JotListMessages` | `<loopId> [after] [before]` | List messages in a loop (supports date-range filtering) |
+| `JotMarkLoopRead` | `<loopId>` | Mark all messages in a loop as read |
+| `JotMarkRead` | `<ids...>` | Mark specific messages as read |
+| `JotNumberOfUnreadMessagesInLoops` | `<loopIds...>` | Get unread message counts for loops |
+
+### Robot
+
+| Command | Arguments | Description |
+|---|---|---|
+| `RobotGetRobot` | `<robotId> [serialNumber]` | Fetch robot details |
+| `RobotGetRobotHistory` | `<robotId> [serialNumber]` | Fetch robot history |
+| `RobotUpdateRobot` | `<robotId> <key> <value>` | Update a robot property |
+| `RobotUpdateLocationOverride` | `<robotId> <city> <state> <stateAbbr> <country> <lat> <lng>` | Override robot location |
+| `RobotUpdateLocationOverrideClear` | `<robotId>` | Clear robot location override |
+| `RobotAdminCreateRobot` | `<robotId> <serialNumber>` | Admin: register a new robot |
+
+### OOBE (Out-of-Box Experience)
+
+| Command | Arguments | Description |
+|---|---|---|
+| `OOBEPrepareRobot` | `<loopId>` | Prepare a robot for first-time setup |
+| `OOBESetupRobot` | `<robotId> <token>` | Complete robot first-time setup |
+
+### Key Management
+
+| Command | Arguments | Description |
+|---|---|---|
+| `KeyShouldCreate` | `<loopId>` | Check whether an encryption key should be created |
+| `KeyRequestSymmetricKey` | `<loopId>` | Request a symmetric encryption key |
+| `KeyRestore` | `<loopId> [passwordHash]` | Restore an encryption key using a password (SHA-1 hashed internally) |
+| `KeyListIncomingRequests` | `<loopId>` | List incoming key requests |
+| `KeyListBinaryRequests` | `<loopId>` | List binary key requests |
+
+### Backup
+
+| Command | Arguments | Description |
+|---|---|---|
+| `BackupList` | `<loopId>` | List backups for a loop |
+
+### Person
+
+| Command | Arguments | Description |
+|---|---|---|
+| `PersonListHolidays` | `<loopId>` | List holidays for loop members |
+
+### Log Admin
+
+| Command | Arguments | Description |
+|---|---|---|
+| `LogAdminSetLevel` | `<level> <friendlyIds...>` | Set log level for specific robot services. Level: `error\|warn\|info\|verbose\|debug\|silly` |
+| `LogAdminSetLevelFromFile` | `<level> <filename>` | Same as above but reads `friendlyIds` from a file (one per line, `#` for comments) |
+
+### ROM (Remote Operations Manager)
+
+| Command | Arguments | Description |
+|---|---|---|
+| `ROMCreate` | `<friendlyId>` | Create a ROM entry for a robot |
+| `ROMSetupClient` | `<friendlyId>` | Set up a ROM client |
+| `ROMSetupServer` | `<ipAddress>` | Set up a ROM server |
+
+### OTA (Over-the-Air Updates)
+
+| Command | Arguments | Description |
+|---|---|---|
+| `SetOTATarget` | `<serial> <target>` | Assign an OTA update target filter to a robot (alphanumeric only) |
+| `ClearOTATarget` | `<serial>` | Clear the OTA update target filter for a robot |
+| `UpdateGetUpdateFrom` | `<subsystem> <fromVersion> [filter]` | Query available update for a subsystem/version |
+
+### OAuth Clients Admin
+
+| Command | Arguments | Description |
+|---|---|---|
+| `OauthClientsAdminListClients` | | List all OAuth clients |
+| `OauthClientsAdminCreate` | `<clientId> <redirectUri> <responseType> <scope> <secret> ...` | *(Not yet implemented)* |
+| `OauthClientsAdminRemove` | `<id>` | *(Not yet implemented)* |
+| `OauthClientsAdminUpdate` | `[clientId] [aco] ...` | *(Not yet implemented)* |
+
+
+
+## Examples
+
+```bash
+# Log in and save credentials to file
+node jibo-app.js -s alpha-entrypoint -i MY_KEY_ID -k MY_SECRET \
+    AccountLogin user@example.com mypassword -w ~/.jibo/credentials.json
+
+# List loops, printing loop ID as an env var
+node jibo-app.js -e LoopList
+
+# Sync credentials to a robot named "jibo-abc123" on the local network
+node jibo-app.js SyncCredentials user@example.com mypassword jibo-abc123
+
+# Upload a photo to a loop
+node jibo-app.js MediaCreate LOOP_ID photo.jpg /photos/photo.jpg image/jpeg
+
+# Post a text message to a loop
+node jibo-app.js JotCreateMessage LOOP_ID "Hello from CLI"
+
+# Set log level on specific robot services
+node jibo-app.js LogAdminSetLevel debug my-service-id another-service-id
+
+# Set OTA target for a robot
+node jibo-app.js SetOTATarget ABC123456 release
+```
+
+
+
+## Credentials file format
+
+```json
+{
+    "region": "alpha-entrypoint",
+    "accessKeyId": "YOUR_ACCESS_KEY_ID",
+    "secretAccessKey": "YOUR_SECRET_ACCESS_KEY"
+}
+```

docs/Discoveries/jibohri.md

@@ -0,0 +1,50 @@
+# Jibo Workshop HRI 2024
+
+### 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
+
+![Jibo ChatGPT file stuff](/Assets/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/Installing/entering-rcm.md

@@ -16,5 +16,5 @@ Make sure Jibo is plugged in. Follow the previous steps to get to the settings m
 On the back of Jibo, open his access panel. To open the access panel you just twist the circle on the back of Jibo's head and it should pivot to reveal the panel. Connect your micro USB cable to Jibo.
 
 Now is the fun part! Double check that your micro usb cable is plugged in and that Jibo is connected to power. Then, as seen in the image below, hold down the buttom right button, and click the big button. 1 second after clicking the big button, release the bottom right button.
-![Jibo Button Press Combo Diagram](/button_diagram.png)
+![Jibo Button Press Combo Diagram](/Assets/button_diagram.png)
 If done correctly, Jibo won't boot like normal. Instead of the typical boot up he should just have his red LED left on.

docs/Networking/network-pt.md

@@ -0,0 +1,70 @@
+# Network Profiling & Traffic
+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 [Useful Ports](/Networking/ports) by ZaneDev from discord
+

docs/Networking/ports.md

@@ -0,0 +1,20 @@
+# 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.
+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/atdev.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/be/Assets/assets.md

@@ -0,0 +1,5 @@
+# Assets
+
+Located in `/opt/jibo/Jibo/Skills/@be/be/node_modules/jibo-anim-db-animations/`
+
+Contains many assets relating to Jibo and his overall GUI. Contains animation files too which might be useful in the future for learning best practice.

docs/be/about.md

@@ -0,0 +1,5 @@
+# About
+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/be/splash.md

@@ -0,0 +1,7 @@
+# Splash Screen
+
+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/documenting/voice.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/faq.md

@@ -5,4 +5,11 @@
 - **When will they be public?** Once they work completely and are completely compatable we will begin work on publishing.
 - **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.
+- **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/jtools-minst/00 - Index.md

@@ -0,0 +1,2 @@
+# JiboAutoModv2 
+This folder contains internal documentation for how this repo works.

docs/jtools-minst/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/jtools-minst/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/jtools-minst/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/jtools-minst/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/jtools-minst/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/jtools-minst/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/jtools-minst/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/jtools-minst/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/servers/experimentserver.md

@@ -0,0 +1,2 @@
+surprised nobody has written here yet.
+fyi this is not one of the closed source servers mentioned in 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
+    }
+}
+```