When hacking becomes a protest (and a massive loss) 😈🚲📱

Summer 2023, Bologna. More than 1,600 bikes disappeared in just a few months.

The cause? A pirate app: Ride’n Godi.

Someone cracked the BLE authentication, created a new app, and published code + unlocking credentials. Everything accessible. Everything replicable.

A textbook case of reverse engineering, but also a reflection on the fine line between hacktivism and illegality.

🔒 Security is never an extra.
🔁 Every connected object can become a risk vector.

What do you think? Is it just digital vandalism or a (wrong) way to make themselves heard? 💬

#hacking #ble #bikesharing #security #vulnerability #IoT #cybercrime #technology #privacy #bluetooth

Technical analysis of the “Ride’n Godi” attack on the RideMovi bike sharing service

Introduction

During 2023, a particularly sophisticated and well-documented attack was carried out against the RideMovi bike sharing system, with a real-world impact: more than 1,600 bicycles stolen in the city of Bologna. This document reviews, from a security analyst’s perspective, the technical phases of the attack, the vulnerabilities exploited, the tools used, and the systemic implications. The goal is not just to describe what happened, but above all to explain how it happened, step by step.

Public sources supporting this analysis include:

• Code repository: 0xacab.org/Hen/ridegodi
• Announcements and communications: mastodon.bida.im/@RideGodi
• Ideological context and technical guide: honey.noblogs.org

---

1. Understanding the system architecture

The RideMovi system is based on a classic architecture for shared vehicles:

BIKE <—— BLE ——> APP (smartphone) <—— HTTPS ——> SERVER

In some more advanced cases:

BIKE <—— BLE ——> APP
  \———— HTTP ————/

The bicycles are equipped with BLE (Bluetooth Low Energy) modules to receive commands from the app. The mobile application acts as a bridge between the user and the central servers, but it is also the most vulnerable point of the system.

---

2. Initial phase: information gathering

The first step was to gain access to critical data: bike IDs, MAC addresses, and unlock keys. This was likely achieved through:

• Reverse engineering the official Android app
• Accessing API calls via HTTPS proxy (e.g., mitmproxy)
• Exfiltration of configuration files or databases containing credentials

The format of the collected data was:

bike_ID MAC_address key

Real example:

IE12H12508 E6D03CAEB73F 6e036ccfddea27384e939283b9fc405c

The key is a 32-character hexadecimal string (128 bits), unprotected and presumably used directly in the BLE protocol.

---

3. Decoding and analysis of the BLE protocol

Using tools like bleak (Python) and Android HCI snoop logs (analyzable with Wireshark), the attackers tracked the BLE communication between the original app and the bikes.

Observed elements:

• BLE commands sent in plaintext
• No mutual authentication
• Possibility of replay attacks

The BLE protocol was so simple that it allowed for the complete reconstruction of the unlocking mechanism.

---

4. Building an alternative app: Ride’n Godi

The attackers then created a custom app:

• Developed in Python/Kivy
• Uses bleak for BLE interaction
• Includes Java code (via JNI) for BLE management on Android

The app loads a text file with the list of vehicles and their respective keys, then allows selecting and unlocking a bike with a click.

The interface is minimal but extremely effective. No server-side verification is required: the operation occurs entirely between the smartphone and the bicycle.

---

5. Systemic weaknesses

BLE:

• Static keys: no rotation, regeneration, or challenge
• Blind acceptance: the bike accepts valid commands from any BLE device
• Absence of BLE-level encryption

API:

The server side also showed weaknesses:

• Possibility to sniff and manipulate HTTPS requests (post-patching with Frida/Apktool)
• Techniques mentioned in the blog include:
  • Immediate lock after unlock to minimize the fare
  • Location spoofing
  • Sending fake errors to declare the bike broken
  • Hijacking active sessions

---

6. Concrete impact

• Bikes stolen: over 1,600 in Bologna in summer 2023
• Direct economic damages: non-recoverable
• High risk of replicability: code publicly available

This was not a simple proof-of-concept. It was a widespread operation with real, traceable impact.

---

7. Final considerations

This attack demonstrates the importance of considering the entire security stack: it is not enough to protect the server if the BLE is completely exposed. Smart mobility systems, if not adequately protected, can be deactivated, manipulated, or replicated by actors with intermediate technical skills.

Recommendations for providers:

• Use of BLE with mutual authentication (e.g., ECDH)
• Dynamic key generation
• Server-side verification of BLE commands
• App hardening: obfuscation, integrity verification, TLS pinning

This case study should be considered an emblematic example of “insecurity by design.” The transparency of the attack, combined with the political motivation explicitly stated by the authors, makes it both a technical and social document.

---

Analysis prepared by cybersecurity experts for study, audit, and training purposes.