This is an old revision of the document!

Reverse engineering Blackberry Q5 setup "calls to home"

Blackberry disabled it's servers on January 4 2022 (Business Insider), making their phones basically bricks, if they were not “activated” before that date. I just bought a used BB Q5 with BBOS 10, that would not allow to use “autoloader” (to flash new OS), or really any other exploit method I could find online. So I took it's fate into my own hands and started investigation.

The setup

My setup for this investigation looks like this:

Dell Latitude 5290 with Ubuntu 24.04
Blackberry Q5 with BBOS 10.2.1.3247

…and that's it.

Steps

Getting my feet wet

First I created a WiFi hotspot on my Ubuntu machine, and with Wireshark in background I connected my Q5 on “Network setup” screen to said hotspot. It showed me that after connecting to WiFi, Q5 asks DNS for such domains (in correct order):

www.blackberry.com
cse.doc.blackberry.com
xtra.gpsonextra.com
inet.registration.blackberry.com
pki.services.blackberry.com
clients3.google.com
cs.sl.blackberry.com (only after DNS response for inet.registration.blackberry.com)

Setting up local DNS server

For my WiFi hotspot, I used builtin thingy in Ubuntu settings that allows me to create a hotspot in two clicks. Turns out, it also runs dnsmasq as a DHCP server and DNS-cache. Good thing, that after looking in htop, it uses a flag that loads config from /etc/NetworkManager/dnsmasq-shared.d/. So I created a new file in that directory, and added such configuration:

address=/www.blackberry.com/10.42.0.1
address=/pki.services.blackberry.com/10.42.0.1
address=/inet.registration.blackberry.com/10.42.0.1
address=/cse.doc.blackberry.com/10.42.0.1

Restart the hotspot device, and Blackberry now thinks my laptop is blackberry.com.

Setting up local HTTP server

Just quick and simple Nginx configuration, to check what URL's are being requested:

server {
  listen 80;
  root /var/www/html;
  server_name inet.registration.blackberry.com;
  access_log /var/log/nginx/inet.registration.blackberry.com.access.log;
  error_log /var/log/nginx/inet.registration.blackberry.com.error.log;
  location / {
    try_files $uri $uri/ =404;
  }
}

First requests

For now I've only setup the inet.registration.blackberry.com domain in Nginx, but after looking in access log, we can see some interesting stuff:

10.42.0.61 - - [26/May/2025:23:10:57 +0200] "GET /select/wifiloginsuccess/EN/ HTTP/1.1" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:10:59 +0200] "POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:00 +0200] "POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:01 +0200] "POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:03 +0200] "POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:04 +0200] "POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:17 +0200] "GET /select/wifiloginsuccess/EN/ HTTP/1.1" 404 162 "-" "-"
10.42.0.61 - - [26/May/2025:23:11:18 +0200] "GET /select/wifiloginsuccess/ HTTP/1.1" 404 134 "-" "Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.2.1.3247 Mobile Safari/537.35+"
10.42.0.61 - - [26/May/2025:23:11:57 +0200] "GET /select/wifiloginsuccess/EN/ HTTP/1.1" 404 162 "-" "-"

What we can see here, is that:

Blackberry first checks if there is internet by GET'ting inet.registration.blackberry.com/select/wifiloginsuccess/EN/
Then it wants to do a PKIOperation which I would believe to be a Public key request
And after pressing the “Hotspot login” button on BB, it asks about wifiloginsuccess again

What we can do with this information:

Crash the browser using some webkit exploit in hopes it exits to home screen?
Check what this PKI Operation sends to server and try to make our own?

Checking out PKI Operation request

Let's check that PKI Operation request. Quick fix in nginx configuration to forward requests to port 5000 which we will use later:

location /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1 {
	proxy_pass http://localhost:5000;
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
}

Restart nginx, run netcat to listen at port 5000, tee output to some file (nc -l -p 5000 | tee test.bin), and we get…

POST /ra/scep/rimbbcp-ica-1/rimbbcp-ira-1/rimbbcp-dev-p1?operation=PKIOperation HTTP/1.0
Host: pki.services.blackberry.com
X-Real-IP: 10.42.0.61
X-Forwarded-For: 10.42.0.61
X-Forwarded-Proto: http
Connection: close
Content-Length: 2013
Accept: */*

0�0�1	*�H��
��0�1�0�`�He0�	*�H��
[...]

After removing the header from file, let's check what we're working with…

mdukat@mdukat-Latitude-5290:~$ file Downloads/test.bin 
Downloads/test.bin: DER Encoded PKCS#7 Signed Data
mdukat@mdukat-Latitude-5290:~$ openssl pkcs7 -inform der -in Downloads/test.bin -print_certs -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9020257421968243025 (0x7d2e64557aff7951)
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: C=CA, O=Research In Motion Limited, OU=BlackBerry, CN=2BD06E17
        Validity
            Not Before: May 26 23:06:27 2025 GMT
            Not After : May 26 23:06:27 2026 GMT
        Subject: C=CA, O=Research In Motion Limited, OU=BlackBerry, CN=2BD06E17
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:36:d2:a1:09:92:39:e2:3d:22:3a:f7:26:61:6d:
                    b8:2a:da:d9:d5:ac:16:61:34:59:c1:41:22:c7:40:
                    ae:48:9b:8d:87:cc:6c:df:a5:7c:6e:93:83:9d:4f:
                    90:3b:cb:16:b2:a0:3c:4e:4d:d4:ba:3a:4b:d0:9d:
                    2d:14:b3:e7:c8
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication, TLS Web Client Authentication
    Signature Algorithm: ecdsa-with-SHA512
    Signature Value:
        30:46:02:21:00:be:df:fe:bf:46:a6:ff:5e:79:2c:39:d3:f6:
        d0:8b:f2:01:e0:3b:6c:40:22:ae:3f:d8:28:40:cf:9c:3f:af:
        a4:02:21:00:e8:31:5b:b9:ae:24:5e:b7:7e:54:88:d1:cf:3e:
        c1:55:84:43:aa:00:fb:e1:ee:19:b4:db:a3:60:da:1d:b7:48
-----BEGIN CERTIFICATE-----
MIIB3zCCAYSgAwIBAgIIfS5kVXr/eVEwCgYIKoZIzj0EAwQwWjELMAkGA1UEBhMC
Q0ExIzAhBgNVBAoMGlJlc2VhcmNoIEluIE1vdGlvbiBMaW1pdGVkMRMwEQYDVQQL
DApCbGFja0JlcnJ5MREwDwYDVQQDDAgyQkQwNkUxNzAeFw0yNTA1MjYyMzA2Mjda
Fw0yNjA1MjYyMzA2MjdaMFoxCzAJBgNVBAYTAkNBMSMwIQYDVQQKDBpSZXNlYXJj
aCBJbiBNb3Rpb24gTGltaXRlZDETMBEGA1UECwwKQmxhY2tCZXJyeTERMA8GA1UE
AwwIMkJEMDZFMTcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ20qEJkjniPSI6
9yZhbbgq2tnVrBZhNFnBQSLHQK5Im42HzGzfpXxuk4OdT5A7yxayoDxOTdS6OkvQ
nS0Us+fIozQwMjAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMAoGCCqGSM49BAMEA0kAMEYCIQC+3/6/Rqb/XnksOdP20Ivy
AeA7bEAirj/YKEDPnD+vpAIhAOgxW7muJF63flSI0c8+wVWEQ6oA++HuGbTbo2Da
HbdI
-----END CERTIFICATE-----

Table of Contents