I recently had to play with BlackBerry devices during a penetration testing engagement. It’s quite difficult to find reliable information online about legacy devices (running BBOS < 7.x) so I though it would be a nice idea to share this here.
I’ll start this article by explaining how to observe your BlackBerry device communications then I’ll move onto data at rest (internal and external storage), how to get device’s logs and I’ll finish with a note about reverse engineering BlackBerry applications.
Observing BlackBerry Communications
BlackBerry devices do not provide a way to define a proxy in the device’s configuration. If you want to observe the packets going in and out of a device you have two possibilities:
- use the BlackBerry simulator software and redirect the traffic with another software like Proxifier
- use a physical device that you connect to a wireless access point bridged to your machine
Of course, if you want to observe HTTPS communications you’ll have to add your own certificate to the device trust store. My example involve Burp Suite but you should be ok with any intercepting proxy.
Install a self-signed certificate
- Export Burp certificate in DER format
- Go to the directory where you stored the certificate and run
python -m SimpleHTTPServer - From the device, access your host on port 8000 to retrieve the certificate
- Blackberry OS will detect it as a certificate and ask you if you want to add it in the trust store.
BlackBerry Simulator
- Install Proxifier.
- Setup proxy servers and proxification rules
- In Proxifier, go to Profile -> Proxy Servers and create the profile for your Burp proxy
- Profile -> Proxification Rules
- Remove all rules except the default one.
- Set the default one to “Direct”
- Create a new one that targets fledge.exe (the Blackberry simulator) and proxy its traffic to your newly created proxy profile. fledge.exe is located at C:\Program Files (x86)\Research In Motion
BlackBerry Smartphone Simulators 6.0.0\6.0.0.313 (9800)\fledge.exe
Profit!
Physical device
The best and only way to observe a physical device communications is to bridge a wireless access point to one of your machine interface. You can either do it by using a physical access point or with a soft access point like hostapd.
If your drivers allows you to create soft access point take a look at the create_ap script. Really good stuff there !
Once the device is associated with your access point you’ll be able to observe traffic with wireshark or redirect it wherever you want with iptables. I usually redirect HTTP and HTTPS traffic to Burp like this:
$ iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 $ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080
Note that in that case you’ll need to configure Burp as an invisible proxy.
SRP Traffic
If the device use an enterprise account with a RIM enabled sim card you’ll see that the device encapsulate traffic into a proprietary protocol designed by RIM called Server Routing Protocol.
The BlackBerry Server Routing Protocol (SRP) is a proprietary protocol used by BlackBerry smartphones, and the BlackBerry Enterprise Server to communicate with BlackBerry Routers, and the wider BlackBerry Infrastructure for electronic mail delivery, SMS-style messaging (“PIN” messaging), calendar synchronisation, and handset security policy/connectivity settings delivery, among other things.
It typically operates on TCP ports 3101 (BlackBerry Router), and 4101 (BlackBerry Desktop Client) - neither of which have been registered officially with IANA for this purpose.
Unfortunately, RIM/BlackBerry have not provided full protocol documentation for SRP; although a rough glimpse at its structure, and (inaccurate) payload type IDs have been published as a result of reverse-engineering; and a work-in-progress dissector is being developed as part of Bug #8225.
Wireshark Wiki - https://wiki.wireshark.org/BlackBerrySRP
Accessing Storage
External Storage
Almost all BlackBerry devices have an SD card slot where users can plug their own card. By default, the device will create those directories on the device:
qtn@localhost:/media/qtn/BLACKBERRY$ tree . ├── BlackBerry │ ├── audiobooks │ ├── documents │ ├── music │ ├── pictures │ ├── podcasts │ │ └── cache │ ├── ringtones │ ├── system │ │ └── media │ │ ├── musicart.dat │ │ ├── podcastart.dat │ │ └── videoart.dat │ ├── videos │ └── voicenotes └── tmp 13 directories, 3 files
Internal Storage
qtn@localhost:/media/qtn/BLACKBERRY1$ tree . ├── appdata │ └── rim │ ├── bbm │ │ └── platform │ │ └── profileboxes │ │ └── profilebox.dat │ ├── homescreen │ └── media ├── applications ├── dev ├── home │ └── user │ ├── appworld │ │ └── logs │ │ ├── 20150303-111127-288_00.txt │ │ ├── 20150303-111132-683_00.txt │ │ ├── 20150303-111147-595_00.txt │ │ ├── 20150303-111151-475_00.txt │ │ ├── 20150303-111200-741_00.txt │ │ ├── 20150303-160243-688_00.txt │ │ ├── 20150303-160435-181_00.txt │ │ ├── 20150303-160441-000_00.txt │ │ └── 20150303-160450-643_00.txt │ ├── audiobooks │ ├── documents │ ├── im │ │ └── BlackBerry Messenger │ │ ├── DEADBEAF │ │ │ ├── backup │ │ │ ├── bbm.db │ │ │ └── history │ │ │ └── Group Chats │ │ └── temp │ ├── music │ ├── pictures │ ├── podcasts │ │ └── media │ │ └── config.dat │ ├── ringtones │ │ ├── BBM_Voice_Chat.m4a.rem │ │ └── BBThumbs.dat │ ├── videos │ └── voicenotes ├── system │ ├── drm │ │ └── __drm │ ├── fonts │ ├── info.mkf │ └── media │ ├── musicart.dat │ ├── podcastart.dat │ └── videoart.dat └── tmp 35 directories, 18 files
Packages
bjavaloader provide a way to get the complete list of installed packages. I usually pipe this command to obtain a cleaner output.
$ bjavaloader dir | cut -d" " -f3 | grep -v "^$"`
Logs
You can access device logs in BlackBerry Simulator by clicking on “View” -> “Output Log” which opens a window with device logs. You can save these logs to a file if needed via the provided menu.
Please note that developers use EventLogger to log information and that it’s only available through USB debugging. There is no mechanism that allows applications to access the device logs in a programmatic way.
With a physical device, you can use barry to dump the event log and stack traces if the application crashed.
$ bjavaloader eventlog $ bjavaloader logstacktraces
Backups
RIM provide a mechanism to backup all data stored on a BlackBery device. This mechanism allow a user to backup specific data (contacts, sms, call logs, …) or all of them. The backup file is saved as a .bbb file which can then be use to do a recovery onto another device.
You can use barrybackup to execute this process. Backup functionality is password protected if the user has set one.
A note about memory acquisition
Three memory acquisitions options exists with blackberry devices:
- Logical must know device password, backup encryption is not enforced, limited amount of info
- Physical must know device password, can get all information from the device
- Chip-off don’t need device password, destructive
BlackBerry users can define a device password to prevent unauthorized access to the their device. By default, the device will allow the user 10 tries before wiping the device. Once the device is wiped and if the user set sdcard encryption, there is no way for an attacker to retrieve the sdcard content.
No reliable ways to recover device password but there is two special cases when it can be recovered:
- sdcard encryption is enabled with the encryption option set to “device password” or “security password”.
- sdcard encryption is enabled with the encryption option set to “device password and device key” and device dump available.
Encryption options
- device key (per-card, stored in NVRAM)
- device password
- device password & device key
Decryption
- device dump (for device key option)
- device password (for device password option)
- both (for device key and device password option)
Available tools
- Cellebrite (Physical, targeted to law enforcement)
- ElcomSoft Phone Password Breaker (Logical, recover password, decrypt sdcard files).
The possibility of acquiring the device data highly depends on the security settings of the device:
- is there a device password ? What’s the strength of this password ?
- Is Sdcard encryption enabled ? With which options ?
- Is device encryption enabled ? With which options ?
- How many failed attempts are allowed ? What’s the policy when it’s done ?
The best policy to protect against data acquisition through physical access is to disable SD card encryption and to enforce the use of device key + device password as an encryption option for the device storage. The device user must be aware of this policy so it do not store sensitive informations on the SD card in use with his device. If this policy is deployed, only software available to law enforcement officers will be able to recover data assuming the device’s user has given his password.
Dissassembling BlackBerry Applications
COD file is a proprietary file format developed by RIM. Generally speaking it is some kind of modified Java .class file. For those interested in COD format, a patent publication from RIM revealing some ideas behind its creation is available here
coddec
coddec is a tool developed by Dr. Bolsen that disassemble BlackBerry applications back to BlackBerry JVM assembly code (think of Smali code for Android). The tool was somewhat buggy and s7ephen from don’t stuff beans up your nose released a patch for it, making it more reliable with COD files built with the latest JDE version.
Problem is, this tool was creating path Windows style which was a real mess so I fixed it to run on Linux and included in my repository.
Cheat Sheet
Get device information
$ bidentify
$ btool -tList installed packages
$ bjavaloader dir | cut -d" " -f3 | grep -v "^$"Display device logs
$ bjavaloader eventlogDisplay device crash logs (stack trace)
$ bjavaloader logstacktracesI wrote a small script, packaged with the necessary dependencies to automate all these commands (think adb for Android). It currently runs on Linux but Windows support will be available soon. The tool is available on Github