Files
JiboDocs/Jibo Reval Project/Attack Vectors/Hardware and Tegra Exploitation.md
2026-03-14 19:13:29 +02:00

2.0 KiB
Executable File
Raw Blame History

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