Autoroot V4

Release Notes & Technical Documentation

🚀 Key Changes & Improvements

  • New System Integration Method: Utilizes the Dynamic Library Hijacking vulnerability in BlackBerry 10 (technical write-up).

    • Benefit: Ensures persistence across reboots—rebooting the device before obtaining root access will no longer break the process.
    • Important Note: Integration works via AppWorld. Do not add sys.appworld to the removeapp command, or the mechanism will break.

  • Stability & Code Optimization:

    • Completely eliminated the use of switchzone as a trigger for launching root-privileged code.
    • Rewrote btool entirely in C, resolving previous issues related to Android Runtime crashes and unexpected device reboots.

  • Expanded btool Capabilities: The C-based btool utility now natively integrates:

    • pathtrust patcher
    • launcher patcher
    • NVRAM backup tool

  • Security & System Tweaks:

    • Removed most unnecessary suid/sgid helpers, retaining only the bare minimum required for privilege escalation.
    • Unsigned BAR applications can now be installed immediately upon receiving the root confirmation notification.

🛠 System Patch Installer (Active Development)

Introduced a system patch installer capable of modifying read-only system files, binaries, and dynamic libraries.

Major Achievement(not released yet): Enabled the revival of legacy services—including BBID, Weather, AppWorld, and BBM—by redirecting them to custom community-driven servers instead of the defunct RIM/BlackBerry infrastructure. (Special thanks to @He11kern for these contributions).

Add Authorized SSH Keys

Default private key stored in id_rsa4x

If you want to use own ssh key(s), place your public SSH key(s) in:

patchdata/var/etc/ssh/authorized_keys2

Then uncomment the following line in patch.txt:

push "patchdata/var/etc/ssh/authorized_keys2" "/var/etc/ssh/authorized_keys2"
chmod 644 "/var/etc/ssh/authorized_keys2"
chown 0:0 "/var/etc/ssh/authorized_keys2"

This allows the configured SSH keys to be used for authentication.

Persist SSH Host Keys

By default, SSH host keys may change after reflashing, causing clients to display a new host fingerprint warning.

To persist the host keys across firmware flashes, uncomment:

push "patchdata/var/etc/ssh/ssh_host_rsa_key" "/var/etc/ssh/ssh_host_rsa_key"
push "patchdata/var/etc/ssh/ssh_host_rsa_key.pub" "/var/etc/ssh/ssh_host_rsa_key.pub"
chmod 600 "/var/etc/ssh/ssh_host_rsa_key"
chown 0:0 "/var/etc/ssh/ssh_host_rsa_key"
chmod 644 "/var/etc/ssh/ssh_host_rsa_key.pub"
chown 0:0 "/var/etc/ssh/ssh_host_rsa_key.pub"

You can also replace these files with your existing SSH host key pair if you want to preserve the same fingerprint.

📦 Single-Step Custom Firmware Builder (bb10mt)

Added the batch parameter to bb10mt, allowing users to patch and root an autoloader firmware image in a single automated step without manual scripting.

Usage Examples

Windows:

bb10mt.exe batch -i Z30_10.3.03.3216_STA100-1-2-3-4-5-6.exe -s patch.txt -o \tmp\z30root

Linux / macOS:

./bb10mt batch -i Z30_10.3.03.3216_STA100-1-2-3-4-5-6.exe -s patch.txt -o /tmp/z30root

After running bb10mt in the directory specified in the -o parameter, you’ll find, among other files, those with names ending in _os.exe and _radio.exe. If you’re not a developer, you can safely delete all the other files—they’re just intermediate results. To install, first run _os.exe (it will display an error at the end of the process—this is normal; please ignore it), then run _radio.exe

🛠️ User Partition Patch Configuration (patch.txt)

The patch.txt file passed via the -s argument in bb10mt contains flags and configuration directives used to modify the user partition during image assembly or system boot.

Available Directives

  • touch /var/rootdata/use.root -- Enables base root capability helpers. -- Adds __root and u_root SUID/SGID binaries to pathtrust, granting elevated privileges when executed.

  • touch /var/rootdata/use.sshd -- Configures automatic execution of the sshd daemon with root privileges upon system boot.

  • #touch /var/rootdata/use.berrycore -- Adds the root directory (/) to pathtrust to allow applications dependent on BerryCore to execute as root.

    Note: In future releases, this directive will be refined to selectively add only explicit BerryCore-related binaries rather than trusting the entire filesystem root.

Example patch.txt File Structure

# Enable base root helpers (__root, u_root)
touch /var/rootdata/use.root

# Auto-start SSH daemon as root
touch /var/rootdata/use.sshd

# BerryCore application execution (disabled by default)
#touch /var/rootdata/use.berrycore

Download here: autoroot_v4.zip

Upgrade Without Reflashing

Supporters and contributors can request an upgrade script that allows upgrading an existing AutoRoot installation to v4 without reflashing the firmware.

To update, copy the v2tov4.sh or v3tov4.sh file to your device and run it using sh /path/to/file/v2tov4.sh or sh /path/to/file/v3tov4.sh

During the upgrade process, you may be asked whether root access is required and whether sshd is needed. After the script has run successfully, reboot the device to apply the changes.

Important Note for SSH/Root Users: If you are connected via SSH with root access, do not run the script directly as the root user. Instead, run it via the __devuser shell wrapper or add the script to pathtrust:

/proc/boot/pathtrust !/path/to/script/v2tov4.sh

or

/proc/boot/pathtrust !/path/to/script/v3tov4.sh

📂 System Package Specification

Directory Structure

A package contains configuration files, scripts, and target resources structured into execution stages:

pkg.bar             # Original BAR package (optional)
MANIFEST            # Package manifest file

├── data/           # Main installation payload
│   ├── file1..fileN# Payload files
│   ├── perms       # File permissions configuration for data/
│   ├── links       # Symlinks, copies, PPS objects, and folder creation
│   ├── patch       # Binary byte-patching instructions
│   └── trusted     # Paths to be added to trustpath
│
└── init/           # Initialization stage (root startup)
    ├── file1..fileN# Required startup files
    ├── start.sh    # Executable shell script triggered on root start
    ├── perms       # File permissions configuration for init/
    ├── links       # Symlinks/copies for the init stage
    ├── patch       # Binary patches applied during init
    └── trusted     # Trustpath rules for the init stage

Configuration File Formats

1. links — File System Operations

Defines operations to execute on target paths:

  • ln:src:dst — Create a symbolic link pointing dst to src
  • cp:src:dst — Copy file from src to dst
  • pps:src:dst — Create or update a PPS (Persistent Publish/Subscribe) object
  • md:dst — Create a directory at dst

2. perms — Permission Attributes

Specifies ownership and file access mode (equivalent to chmod/chown):

/path/to/target:UID:GID:MODE
  • Example:/accounts/1000/appdata/test:0:0:0755

3. patch — Binary Byte Modification

Specifies exact byte-level substitutions for target binary files:

/path/to/target_file1
0xADDR1: 0xOLD1 0xNEW1
0xADDR2: 0xOLD2 0xNEW2
/path/to/target_file2
0xADDR1: 0xOLD1 0xNEW1
  • Syntax:Address: OldByte NewByte
  • Example:0x0001A2F0: 0x89 0x90 (Replaces byte 89 with 90 at offset 0x0001A2F0).

4. trusted — Trusted Path Whitelist

A plain text file where each newline contains an absolute file path to a binary or library to be added to the system trustpath.