Architecture, Security, and the Simulator

The BlackBerry Legacy platform is based on a lightweight, custom, real-time operating system (the BlackBerry operating system, or BBOS) and Java Virtual Machine (JVM), which itself is custom although deemed SUN/Oracle compatible. The BBOS runs on the application processor (AP) and provides the abstraction layer between the JVM and the hardware.

The BlackBerry Legacy simulator is actually very close in terms of architecture and code to the JVM and BBOS that run on the device. That is, the JVM is nearly identical and there are stubs for the BBOS APIs used by the JVM, which instead of translating to real hardware are instead translated to either simulator-specific or functionality corresponding to Microsoft Windows.

The notable differences between device and simulator are that although the device code is compiled for the ARM CPU architecture, the simulator is compiled for the X86 CPU architecture. The simulator by virtue of its purpose also provides a number of simulated hardware devices (GPS, cellular network, and so on) and the ability to do certain operations such as not enforcing certain security controls found on the device. This flexibility with these controls is very useful during development. However, these security controls cannot be subverted on a real device, so verifying any vulnerability you discover in an app on a real device and not solely the simulator is always worthwhile.

The security model of BlackBerry Legacy is entirely implemented within the JVM. All the high-level security concepts such as app controls, encryption, private application storage mechanisms, code signing, and so on are implemented there.

Apps and COD Files

BlackBerry Legacy apps are at their core Java based; however, unlike its desktop cousin, its apps are not stored in JAR files but instead in COD files. These COD files are generated by a custom BlackBerry generator that takes the compiled Java class files and converts them. The reason for this custom storage mechanism is not to obfuscate or otherwise frustrate but for performance and space optimization. BlackBerry discusses why it uses a custom file structure in the patent behind the COD format:

---

Java .class files may be archived (and optionally compressed) into a .jar file. However, .jar files are not directly interpretable by the Java VM, and the .class files must be extracted (and decompressed, if applicable) from the .jar file (and read into memory) in order for them to be linked, resolved, and interpreted by the Java VM. Although .jar files comprising archived and compressed .class files are smaller than the .class files themselves (and are therefore more suitable for transmission between communication devices), storage space for the extracted (and decompressed, if applicable) .class files needs to be available in the environment where the application is to be executed, so that the Java VM may access the .class files. Consequently, a solution involving .jar files may not represent a savings in storage space.

−https://www.google.com/patents/WO2004051468A1

---

The benefit of the COD format is that files produced using it can be linked without the need to decompress them. Also, optimization (with the exception of Just-In-Time compilation) is done on the comparably cheap PC side during compilation and production of the COD files.

However, note that not all CODs are optimized and converted Java classes. Confusingly, some may actually be zip files. This is why when analyzing BlackBerry Legacy apps that verifying the actual contents prior to starting the analysis is important.

Aside from pure Java apps, BlackBerry also introduced WebWorks (HTML5 and JavaScript)–based apps. WebWorks apps have a COD name but are standard zip files.

So when you see a COD, remember it might be

• An optimized Java class, which requires custom tooling to reverse engineer as discussed later in this chapter
• A zip file, which you can extract with common unzip utilities

Reverse Engineering COD Files

In this section we will review how to reverse-engineer the files that contain BlackBerry legacy apps. We will walk through the process looking at the container types and the tools used to extract their contents.

Java Development Environment and JVM Interface

The Eclipse-based Java Development Environment (JDE) (http://developer .blackberry.com/bbos/java/download/JDE/) is used to develop Java apps for BlackBerry Legacy. The JDE communicates with the simulator and real device over the same JVM software interface. The simulator uses a technique to make itself appear connected to BlackBerry Desktop Manager so it doesn't need to implement a full USB stack.

The JVM interface utilized by the JDE provides all the functionality that the JDE needs, including loading and executing CODs, reflection, and similar functionality.

The javaloader.exe utility, which ships with the JDE (http://btsc .webapps.blackberry.com/btsc/viewdocument.do?externalId=KB25526), also communicates with this same JVM interface. The javaloader.exe utility provides functionality for listing those COD files that are installed and copies them from the device to the PC, among other things. This and other functionality will be of interest to those looking to analyze apps, as shown here:

JavaLoader [-u] [-p[port]|[pin]] [-b[baud]] [-d0|-d1] [-w[password]] [-q] 
[command] 
 
-u Connect to USB handheld (default is serial) 
-p[port] Specifies the serial port (serial handhelds only) 
-p[pin] Specifies the handheld PIN (USB handhelds only; hex pin prefix '0x' 
) 
-b[baud] Specifies the baud rate (serial handhelds only) 
-d0 Disables VM debug mode 
-d1 Enables VM debug mode 
-w[password] Connects using the specified password 
-q Quiet mode 
 
[command] is one of 
 
dir [-d] [-s] [-1] 
Lists modules on the handheld 
-d Display dependency information 
-s Display siblings 
-1 Single column output 
 
deviceinfo 
Provides information on the handheld 
 
load [.cod file] ... 
Loads modules onto the handheld 
 
load [.jad file] 
Load modules described by JAD onto the handheld 
 
load @[manifest] ... 
Loads all modules named in [manifest] onto the handheld 
 
save { [module] ... | -g [group] } 
Retrieves modules from the handheld 
-g Retrieves all modules in a specified group 
 
info [-d] [-s] [-v] [.cod file] ... 
Provides information on the specified modules 
-d Display dependency information 
-s Display sibling information 
-v Display verbose module information

javaloader.exe functionality to save the CODs is useful when an over-the-air (OTA) installation occurs, and you want to obtain a copy to reverse engineer or load it into the simulator.

App Code Signing

App code signing on BlackBerry is not for identifying publishers by a human- distinguishable name but instead for identifying the publisher to the JVM. Yes, it is true that there are a number of internal signing keys, which RIM uses to distinguish its own code and certain apps from third-party developers; however, third-party developers use code signing to enforce certain platform security features only.

For example, when you use Protected Storage, access is based on code signing rather than anything else. It is no more complex than that. If you are used to Microsoft Windows code-signing that includes details about the originating organization, then keep in mind that, especially if you are analyzing malicious code, there won't be a clear indicator as to the originating organization.

BlackBerry Mobile Data System

BlackBerry Mobile Data System (MDS) is how a BlackBerry gets a connection to the Internet. It acts as a proxy between the device and the device's primary UDP transport and Internet services, which use UDP or TCP, respectively.

An MDS acts as a proxy for higher-level protocols such as HTTP (and HTTPS when configured). When acting as a proxy for these protocols, MDS also provides bandwidth-conserving functionality, including image compression. Aside from higher-level protocols, MDS can also act as a UDP-to-TCP proxy.

Why is this architecture detail important? Most apps on BlackBerry interact with remote services via HTTP or HTTPS. BlackBerry doesn't have the concept of native HTTP or HTTPS proxies as we understand them on the desktop i.e., a configuration option that apps will obey will doing HTTP or HTTPS requests. Thus, to intercept and observe or modify the traffic from these apps with tools such as BurpSuite, you chain a new HTTP proxy off of the MDS or MDS simulator.

In the MDS configuration you include something similar to the following to have the requests that come from the device sent to localhost on port 1234:

application.handler.http.proxyEnabled=true 
application.handler.http.proxyHost=localhost 
application.handler.http.proxyPort=1234

The MDS Simulator comes into play when you use the device simulator because it is required to provide the connectivity. You should configure and start the MDS simulator on your PC prior to launching the device simulator.

Device Event Log

The BlackBerry device has a non-persistent rolling log that developers and the system may make use of. This log is worth checking during app analysis to see whether anything sensitive is revealed. To access the log, hold down the ALT key and type lglg.

The BlackBerry 10 Platform

BlackBerry 10 is based on the QNX POSIX (UNIX-like) –compatible micro kernel and associated OS-forming userland components. Userland is a term which is used to describe the components of an operating system which exist outside of the kernel.

We won't provide a detailed primer to the QNX architecture. Numerous resources can provide a fundamental overview of QNX's design and implementation. If you are interested in these base concepts read the following:

• QNX Neutrino System Architecture—(http://support7.qnx.com/download/download/26183/QNX_Neutrino_RTOS_System_Architecture.pdf)
• System Architecture—(http://www.qnx.com/developers/docs/6.5.0SP1/neutrino/sys_arch/about.html)
• A Roadmap to QNX Software Development—(http://www.qnx.com/developers/docs/6.5.0SP1/momentics/bookset.html)
• QNX PPS Service (Persistent Publish/Subscribe)—(http://www.qnx .co.uk/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc .neutrino_pps%2Fpps.html)

Going beyond the core operating system and platform concepts, we will discuss some apps and higher-level concepts:

• Apps are packaged in BAR files and can be written using a variety of programming languages and associated frameworks. These are discussed in later sections.
• Authman and Launcher are responsible for launching and enforcing capabilities when instructed to do so by the graphical navigator.
• PPS Objects (implemented via the PPS service) are used to provide a range of data sources and access to peripherals such as Bluetooth and similar configurations.

The sections that follow dig into these concepts in more detail. But before doing so I want to acknowledge the work of others who unlike me didn't get to spend years with QNX, PlayBook, and BlackBerry 10 and who instead conducted their own research that has contributed so much to the public understanding of the platform from a security perspective:

• Andy Davis and Daniel Martin Gomez for their paper “BlackBerry PlayBook Security: Part One” — https://www.nccgroup.com/media/18436/blackberry_playbook_security._part_one.pdf
• Alex Plaskett for his presentation “An Introduction to Blackberry 10 Security (BB10 - QNX)” — https://labs.mwrinfosecurity.com/system/assets/410/original/mwri_blackberry-10-security_2013-06-03.pdf
• Tim Brown for his general QNX research — http://seclists.org/fulldisclosure/2014/Mar/98
• Ralf-Philipp Weinmann for his Blackhat presentation “BlackBerryOS 10 from a security perspective” — http://www.youtube.com/watch?v=z5qXhgqw5Gc
• Zach Lanier and Ben Nell for their CanSecWest presentation “Deconstructing BB10” — https://cansecwest.com/slides/2014/NoApologyRequired-BB10-CanSecWest2014.pdf
• Shivang Desa for his post “Get Started with Pentesting BlackBerry Apps” — http://blog.attify.com/attifys-guide-to-get-started-with- pentesting-blackberry-apps/
• The BerryLeaks Wikia — http://berryleaks.wikia.com/wiki/BerryLeaks_Wiki

Authman and Launcher

Authman and Launcher were originally two software components developed for the BlackBerry PlayBook. Launcher is what actually executes the apps and authman is consulted as to the permissions they should be assigned. They were then used in BlackBerry 10 and have subsequently been used in the QNX CAR platform. Their being used in the QNX CAR platform provides a handy public reference as to their purpose and functionality (http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.qnxcar2.hmi%2Ftopic%2Fhmi_authman.html).

---

Authman and Launcher are processes responsible for determining whether an app has permission to use a set of requested capabilities and for launching the app if it has sufficient permissions

…

To launch an app, Navigator makes a request to Launcher. Launcher reads the app's manifest (MANIFEST.MF) file and requests Authman to confirm that the app has permission to use the requested capabilities. Authman checks these against the /etc/authman/sys.res file which lists the available system capabilities and the apps that are entitled to use them.

---

This process is nearly identical on BlackBerry 10. The only real difference between BlackBerry 10 and QNX CAR in the context of Navigator, Launcher, and Authman is an awareness of BlackBerry Balance. As a result you can think of these software components (Authman, Launcher and Navigator) as core security components to the app security framework, ensuring apps run as the correct user with the correct capabilities and permissions.

Apps Packages and BAR Files

BAR (BlackBerry Archive) format is simply a zip file with a well-defined structure. This well-defined structure depends on the type of application whether native, Cascades, HTML5, JavaScript, or Android.

For native, Cascades, HTML5, and JavaScript this structure is:

+ 
| 
+-- META-INF 
| 
+-- native 

For Android the structure is:

+ 
| 
+-- META-INF 
| 
+-- android

The META-INF directory contains a number of files containing metadata. This metadata varies but the common files are:

• MANIFEST.MF—Main manifest for the application
• AUTHOR.SF—Signature file for the developer's signing key containing SHA-512 hashes for the assets and parts of the manifest, which are protected
• AUTHOR.EC—Signature for AUTHOR.SF
• RDK.SF—Signature file for the BlackBerry signing key containing SHA-512 hashes for the assets and parts of the manifest, which are protected
• RDF.EC—Signature for RDK.SF
• MANIFEST_[Language Code].BBR—Localization entry points

The MANIFEST.MF file is of the most interest and although BlackBerry doesn't publish a specification, the key attributes contained in the file are

• Entry-Point-User-Actions—The application's requested or required capabilities (http://www.qnx.com/developers/docs/qnxcar2/index .jsp?topic=%2Fcom.qnx.doc.qnxcar2.hmi%2Ftopic%2Fhmi_authman.html)
• Entry-Point-System-Actions—The actions that the system will perform when launching the app; that is, that it will run native
• Entry-Point-Type—The type of app the values here include Qnx/Elf, Qnx/Cascades, Qnx/WebKit (for HTML5 and JavaScript or WebWorks apps), Qnx/Uri (for URL shortcuts), and Qnx/Android
• Entry-Point — What the system will run when executing the program

The Entry-Point parameter can include a variety of possible values depending on the type of app. For example a native app may look like this:

Entry-Point: [timeout=10 flags=a path=(p600)boot]

Whereas an Android app may look like this:

Entry-Point: android://com.nccgroup?activity-name=com.nccgroup.activity.Hi

Finally, an HTML5 and JavaScript app might look like this:

Entry-Point: WEBWORKS_VERSION=1.0.4.11 app/native/wwe

Recognizing that the ability to run arbitrary binaries or have libraries loaded by crafting your own manifest is not considered a security issue is important. This is because all you would achieve is execution within the context of the user and groups that the app would be assigned anyway. Numerous other ways exist to get arbitrary code execution on a device or simulator within a contained sandbox, including Developer mode; therefore, the ability to run code or navigate the filesystem is not considered a security issue.

What would be considered a security issue is if you are able to get code execution within the context of another app, gain access to the private data directory for another app, or modify its BAR contents, and still satisfy signature checks.

Native Applications

Native applications (http://developer.blackberry.com/native/documentation/ core/) are those typically written in C or C++ via the Momentics IDE. The application code is compiled and linked to an ELF (Executable and Linkable Format; see http://en.wikipedia.org/wiki/Executable_and_Linkable_Format) file that is run by Launcher.

The resultant binaries are produced using the GCC tool chain, and due to the use of C and C++ are potentially vulnerable to a range of memory corruption vulnerability classes. However, BlackBerry by default enables a number of mitigations to try to complicate the exploitation of these vulnerability classes.

To mitigate or complicate the exploitation of any memory corruption vulnerabilities that may be present in an app, BlackBerry provides a number of compiler- and linker-implemented or -enabling defenses. BlackBerry provides an overview of these features in its development documentation (http://developer .blackberry.com/native/documentation/core/com.qnx.doc.native_sdk .security/topic/using_compiler_linker_defenses.html#dho1384790657335).

These defenses are enabled by default in the Momentics IDE for new projects to ensure protections are enabled. However, they are not mandatory and as such you should understand what is available versus what is actually enabled on a per-binary basis and audit for their presence. We cover how to audit for their presence later in this chapter.

Cascades Applications

Cascades applications (http://developer.blackberry.com/native/ documentation/cascades/dev/fundamentals/) are also native applications; however, they utilize the Qt framework to create the user interface (UI). Due to this use of Qt, a number of specific security considerations exist over and above those for standard C/C++ apps. These considerations are due to the underlying QML technology and the attack surface it introduces.

BlackBerry discusses some of these specific security considerations in a document titled “Security considerations.” The most striking of these considerations is the possibility of UI spoofing due to HTML injection, and more importantly the risk of script injection (a la JavaScript) into an app:

---

If a Cascades application executes QScript or JavaScript that's controlled by an attacker, it can allow the attacker to access application data or control the behavior of the application. For this reason, it is important that applications avoid executing untrusted data as a part of scripts.

When the QScriptEngine class is used to execute scripts, it is important that untrusted values are never appended to the string of the script that's being executed. All scripts that are executed by a QScriptEngine should be predefined when developing the application and should never be altered dynamically when the application is running.

−http://developer.blackberry.com/native/documentation/cascades/best_practices/security/index.html

---

The Qt project itself also provides some advice around QML security; it helpfully provides a list of ways you can shoot yourself in the foot.

---

Using import to import QML or JavaScript you do not control. BAD

Using Loader to import QML you do not control. BAD

Using XMLHttpRequest to load data you do not control and executing it. BAD

−http://qt-project.org/doc/qt-4.8/qdeclarativesecurity.html

---

This nonexhaustive list is important to keep in mind as we look at how to assess such apps later in this chapter. Suffice it to say that although the use of Cascades will accelerate the development of UI aspects, it provides the opportunity for extra security vulnerabilities to sneak in.

HTML5 and JavaScript Applications

HTML5 and JavaScript apps, also known as WebWorks (https://developer .blackberry.com/html5/documentation/v2_1/), are locally run HTML5/JavaScript apps that use the Apache Cordova framework to expose native device features such as the camera, GPS, and so on to apps. The HTML5/JavaScript engine is provided by WebKit combined with some default restrictions around network requests and the ability to access files or paths not inside the applications package.

From an app hacker's perspective, several interesting considerations exist with regard to WebWorks apps. The first consideration is that BlackBerry doesn't provide anywhere near the same level of proactive security guidance to developers that it does for other languages. The second is the possibility exists for developers to write custom extensions and expose them to their HTML5/JavaScript app, which opens the opportunity for security issues to arise. Details on how developers can write custom Cordova plug-ins are provided on the BlackBerry developer site (https://developer.blackberry.com/html5/documentation/v2_1/using_custom_plugins.html). These extensions are comprised of a JavaScript interface and a native implementation. The ability to extend apps in this way brings with it a wide range of possibilities from creating exploitable memory corruption conditions from seemingly innocuous web technologies to a raft of potential logic vulnerabilities.

Android Applications

Android applications on BlackBerry 10 are simply repackaged. That is, the original APK (Android Package) is retained and wrapped in a BAR structure.

The accomplishment for the Android run time on BlackBerry is pretty impressive when you consider that BlackBerry ported the binder Linux kernel driver used on traditional Android devices to a QNX Resource Manager. The Dalvik VM and Zygote concept were also ported across. As a result, the ability to run native Android apps is indeed that—native. A vast majority of the Android run time is present, allowing near-seamless compatibility with a wide variety of apps.

Android app security is covered extensively in other parts of this book and as a result won't be covered here. However, you should understand that the same inter-app attack paths (that is, those that occur via Android IPC mechanisms) translate due to the wholesale porting of the run time and framework.

Distributing Applications

Applications for BlackBerry 10 are solely distributed via BlackBerry World (formerly AppWorld), which is the BlackBerry storefront. BlackBerry 10 does not provide the ability to sideload applications, unlike BlackBerry Legacy. This restriction has in some cases been worked around via a variety of different methods, namely:

• Developer mode—Using the mode intended for developers (http://developer.blackberry.com/playbook/native/documentation/com .qnx.doc.native_sdk.devguide/com.qnx.doc.native_sdk.devguide/topic/t_setup_enable_devmode_device.html)
• Sachesi—Originally DingleBerry, but dramatically enhanced to allow sideloading within Developer mode (https://github.com/xsacha/Sachesi/releases)
• SideSwype—A commercial service that uses a VPN (https://sideswype.me/)

Another tool of note, the Chrome ExtensionBB10/PlayBook App Manager, provides a convenient method of sideloading apps and generally controlling what is installed (https://chrome.google.com/webstore/detail/bb10-playbook-app-manager/kmbaalodpmjjhpobkgljnelbpblnikkp?hl=en).

In enterprises, BlackBerry World introduces a concept of a work channel:

---

…application can be deployed over-the-air by administrators as an optional application or as a required application, where the user cannot remove it.

−http://developer.blackberry.com/distribute/enterprise_application_distribution.html

---

This feature allows administrators to control and mandate which apps are installed or installable on enterprise-managed devices using the core AppWorld technologies and distribution mechanisms.

PPS Objects

PPS is a long-standing QNX concept that has been used extensively in the context of BlackBerry 10. QNX describes PPS as follows:

---

The QNX Persistent Publish/Subscribe (PPS) service is a small, extensible publish/subscribe service that offers persistence across reboots. It is designed to provide a simple and easy-to-use solution for both publish/subscribe and persistence in embedded systems, answering a need for building loosely connected systems using asynchronous publications and notifications.

With PPS, publishing is asynchronous: the subscriber need not be waiting for the publisher. In fact, the publisher and subscriber rarely know each other; their only connection is an object which has a meaning and purpose for both publisher and subscriber.

−http://www.qnx.co.uk/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_pps%2Fpps.html

---

As with Authman and Launcher, PPS has been reused for certain high-level purposes in other QNX-derived platforms, thus the PPS Object Reference for QNX CAR translates in a majority of cases to BlackBerry 10 (http://support7 .qnx.com/download/download/26319/PPS_Objects_Reference.pdf).

Generally, these PPS objects are not accessed directly; instead they are abstracted by higher level APIs that BlackBerry makes available to developers via libraries. An example of this abstraction is when using the Bluetooth API published by BlackBerry (http://developer.blackberry.com/native/documentation/core/com.qnx.doc.bluetooth/topic/t_bluetooth_use_spp.html) and actually uses PPS under the hood.

This knowledge can be useful when you're researching the platform for exposed, yet undocumented features in devices and service endpoints.

Process Sandboxing

For BlackBerry 10 process sandboxing is described in some detail in the “BlackBerry Enterprise Server 10 Technical Overview” (http://docs.blackberry .com/en/admin/deliverables/66547/BES10_v10.2.4_BDS_Security_Technical_Overview_en.pdf). It also discusses in detail app sandboxing:

---

The BlackBerry 10 OS uses a security mechanism called sandboxing to separate and restrict the capabilities and permissions of apps that run on the BlackBerry 10 device. Each application process runs in its own sandbox, which is a virtual container that consists of the memory and the part of the filesystem that the application process has access to at a specific time.

Each sandbox is associated with both the app and the space that it is used in. For example, an app on a BlackBerry Balance device can have one sandbox in the personal space and another sandbox in the work space; each sandbox is isolated from the other sandbox.

The BlackBerry 10 OS evaluates the requests that an application's process makes for memory outside of its sandbox. If a process tries to access memory outside of its sandbox without approval from the BlackBerry 10 OS, the BlackBerry 10 OS ends the process, reclaims all of the memory that the process is using, and restarts the process without negatively affecting other processes.

When the BlackBerry 10 OS is installed, it assigns a unique group ID to each app. Two apps cannot share the same group ID, and the BlackBerry 10 OS does not reuse group IDs after apps are removed. An app's group ID remains the same when the app is upgraded.

−http://docs.blackberry.com/en/admin/deliverables/66547/BES10_v10.2.4_BDS_Security_Technical_Overview_en.pdf

---

Application Capabilities

Within BlackBerry 10 a core security foundation is the per-process capabilities model. The existence of this high-level capability context is detailed in the “Security Technical Overview for BlackBerry Device Service 6.0 and BlackBerry PlayBook Tablet 2.0” document (http://docs.blackberry.com/en/admin/ deliverables/40478/BlackBerry_Device_Service_6.0_and_BlackBerry_PlayBook_Tablet_2.0.1-Security_Technical_Overview-1329934562720-6.0-en.pdf). PlayBook OS was the precursor to BlackBerry 10, and many fundamental concepts were devised during its design.

---

The PlayBook OS uses sandboxing to separate and restrict the capabilities and permissions of applications that run on the tablet. Each application process runs in its own sandbox.

…

The BlackBerry PlayBook tablet is designed to minimize the number of processes running as root. Only the most essential first-party processes and no third-party processes can run as root. A subset of root capabilities is available to first-party processes that do not need full root capabilities.…

The kernel validates requests for resources and an authorization manager controls how applications access the capabilities of the tablet.

---

BlackBerry publishes a list of permissions that are allowed in third party–developed apps (http://developer.blackberry.com/native/documentation/core/com.qnx.doc.native_sdk.devguide/topic/c_appfund_accessing_restricted_functionality.html). These are as of September 2014 (article last updated July 2014):

• bbm_connect—Connect to BlackBerry Messenger (BBM). You can use this permission to access contact lists and user profiles, invite BBM contacts to download your app, initiate BBM chats, share content from within your app, and stream data between apps.
• access_pimdomain_calendars—Access the calendar on the device. This access includes viewing, adding, and deleting calendar appointments.
• use_camera—Access data that's received from the cameras on the device. With this permission, your app can take pictures, record videos, and use the flash.
• use_camera_desktop—Take a screenshot or video of any information visible on the screen of the device. This permission also allows the app to share the user's screen.
• access_pimdomain_contacts—Access the contacts that are stored on the device. This access includes viewing, creating, and deleting contacts.
• read_device_identifying_ information—Access unique device identifiers, such as the PIN or the serial number. This permission also allows you to access SIM card information on the device.
• access_pimdomain_messages—Access the email and PIN messages that are stored on the device. This access includes viewing, creating, sending, and deleting messages.
• use_gamepad—Access gamepad functionality. This permission also indicates that the app has official gamepad support in the BlackBerry World storefront.
• read_geolocation—Read the current GPS location of the device (deprecated).
• _sys__manage_pimdomain_ external_accounts *—Create a custom account that's accessible in the BlackBerry Hub. This capability requires special permissions from BlackBerry.
• _sys_access_pim_unified *—Integrate with the BlackBerry Hub. With this permission, your app can create and manage data in the BlackBerry Hub. This capability requires special permissions from BlackBerry.
• access_internet—Use the Internet connection from a Wi-Fi, wired, or other type of connection to access locations that are not local on the device.
• access_location_services—Access the current location of the device, as well as locations that the user has saved.
• record_audio—Access the audio stream from the microphone on the device.
• read_personally_identifiable_information—Access user information on the device, such as the first name, last name, and BlackBerry ID username of the user currently associated with this device.
• narrow_landscape_exit—Reduce the width of the region along the bottom bezel of the device that accepts swipe-up gestures. When you use this permission, swipe-up gestures are recognized in a more narrow area along the bottom bezel.
• access_pimdomain_notebooks—Access the content that's stored in notebooks on the device. This access includes adding entries to, and deleting entries from, the notebooks.
• access_notify_settings_control—Change global notification settings. Apps have permission to read their own notification settings.
• access_phone—Determine when a user is on a phone call. This access also allows an app to access the phone number assigned to the device and send DTMF (Dual Tone Multi-Frequency) tones.
• _sys_inject_voice—Add audio to a phone call.
• read_phonecall_details—View the status of phone calls that are in progress and the phone number of the remote party.
• access_pimdomain_calllogs—View the logs of previous incoming or outgoing phone calls.
• control_phone—Control the current phone call. This access includes ending a phone call and sending DTMF tones to the phone.
• post_notification—Post notifications to the notification area of the device screen. This permission does not require the user to grant your app access.
• _sys_use_consumer_push—Access the Push service to receive and request push messages.
• run_when_backgrounded—Perform background processing. Without this permission, your app stops all processing when the user changes focus to another app.
• _sys_run_headless—Perform certain tasks in the background, without opening the app, for a short period of time.
• _sys_headless_nostop—Run in the background always. You must request access before your app can run as a long-running headless app.
• access_shared—Read and write files that are shared between all apps on the device. With this permission, your app can access pictures, music, documents, and other files that are stored on the user's device, at a remote storage provider, or on a media card.
• _sys_access_smartcard_api*—Encrypt, decrypt, sign, and verify data using a smartcard. This capability requires special permissions from BlackBerry.
• _sys_smart_card_driver*—Allow third-party smartcard drivers and smartcard reader drivers to integrate with the Smartcard service. This capability requires special permissions from BlackBerry.
• _sys_access_extended_smart_card_functionality *—Use APDU (Application Protocol Data Unit) for custom commands. This permission is restricted. This capability requires special permissions from BlackBerry.
• access_sms_mms—Access the text messages that are stored on the device. This access includes viewing, creating, sending, and deleting text messages.
• access_wifi_public—Receive Wi-Fi event notifications such as Wi-Fi scan results or changes in the Wi-Fi connection state.

Code Signing

As you would expect there is code signing on BlackBerry 10. This is done to ensure integrity of the BARs as well as to authorize the use of capabilities within your app:

---

Each app must be signed to allow BlackBerry to validate the application's capabilities and issue unique identifiers for it.

---

However, in recent SDKs you don't actually have to back up and look after the keys yourself. These are taken care of by being stored under your BlackBerry ID (yes, this does mean BlackBerry has a copy (http://devblog.blackberry .com/2013/08/code-signing-keys-be-gone-welcome-blackberry-id/). The signing process itself is simple to do:

blackberry-signer -proxyhost 192.168.1.1 -proxyport 80 -register -csjpin 
 <csj pin>  -storepass <KeystorePassword> <client-RDK-xxxxxx.csj file>

<client-PBDT-xxxxx.csj file>BlackBerry Balance

BlackBerry Balance (mentioned in a quotation earlier in this chapter) is a technology that allows two digital worlds to exist—one for corporate data and one for personal. BlackBerry provides extensive documentation on the architecture of this technology in the document “How BlackBerry Balance Works at a Platform Level” (http://uk.blackberry.com/content/dam/blackBerry/pdf/business/english/Separating-Work-and-Personal-How-BlackBerry-Balance-Works-at-the-Platform-Level.pdf) and in the already-mentioned “BlackBerry Enterprise Server 10 Technical Overview.”

However, in the context of BlackBerry Balance, recognizing that the separation is only as robust as the kernel and the associated integrity mechanisms is important. BlackBerry Balance is not implemented as a hypervisor (virtualization) with two separate kernels. Instead it is implemented within the same kernel using a mixture of filesystem, object controls, higher-level capabilities, and logical separation to provide the dual world. BlackBerry Balance can be thought of as akin to Samsung's KNOX for Android, and it is useful to understand the limitations of this architecture.

BlackBerry Balance offers the following at its core:

• Process separation—Enforced by the QNX kernel
• Process capabilities—To control what level of access a process has
• Process users—To facilitate separation and restrict what resources a process can access
• Process groups—To facilitate separation and restrict what resources a process can access
• Access control lists—On file object
• Firewall rules—Restricts network traffic including traffic destined for local host

Network Traffic Analysis and Interception

Depending on the approach, employed to perform network traffic analysis and interception you can perform traffic analysis in a variety of ways with varying degrees of insight and success.

The most comprehensive traffic analysis methods are

• Sniffing traffic from the simulator to analyze all unencrypted traffic
• Sniffing the local Wi-Fi network to analyze the unencrypted traffic from a real device
• Using Mallory in-line to intercept and modify traffic (https://github .com/intrepidusgroup/Mallory)

The somewhat comprehensive traffic methods include

• Manually configuring a Wi-Fi proxy setting to force proxy-aware apps via BurpProxy or similar
• Using an enterprise configuration to configure a proxy server
• Use a proxifier and the simulator to force traffic via an intermediary proxy

Note that on real devices (at least in 10.2), configuring a new arbitrary Certificate Authority for a non-enterprise–enabled device that is trusted device-wide seems impossible. This inability to trust a new root CA device-wide results in the inability to succeed at certain SSL/TLS man-in-the-middle attacks where certificate validation is enforced. However, some apps may still prompt the user to authorize the connection although the server's certificate can't be trusted, and thus allow analysis. This same limitation with regard to man-in-the-middle attacks does not exist in the simulator, though.

BAR Archives

In this section you will look at how to extract the relevant parts of the BAR archives.

1. Take the original BAR file, make a copy, and rename it to .zip as shown in Figure 14.7.
2. Extract the zip, and two directories appear, as shown in Figure 14.8.

3. Go into META-INF and open the MANIFEST.MF file, as shown in Figure 14.9.

   In this highlighted example you can see:

   • Architecture target
   • Development mode
   • Entry point type
   • Capabilities (permissions)
   • Entry point actions

   • Invocation filter URIs

     The invocation filter URIs mechanism is documented extensively within the SDK but in short, it details the methods via which the app can be invoked and the URIs (http://developer.blackberry.com/native/documentation/cascades/device_platform/invocation/receiving_invocation.html).

4. Go up the directory again to the structure shown in Figure 14.10.

   You can then go into the native subdirectory, as shown in Figure 14.11.

5. In the native directory notice the bar-descriptor.xml (http://developer .blackberry.com/native/documentation/core/com.qnx.doc.native_sdk .devguide/topic/c_about_bar_app_descriptor_file.html) file, which in this example is fully commented and used to generate the MANIFEST .MF, as shown in Figure 14.12.

6. libClock.so is a native ELF binary and the entry point for the application. Going into the assets subdirectory reveals several .QML files because this is a Cascades-based application, as shown in Figure 14.13.

   These QML files contain human-readable code that you can easily review, as shown in Figure 14.14.

The assets subdirectory will likely be where you spend most of your time investigating. Other types of things you may find in this directory include (previously observed in Figure 14.13):

• SSL certificate databases—Databases that contain SSL certificates
• Custom configuration files—For the application that can contain sensitive information or influence program execution

ELF Binaries

For analyzing the ELF binaries themselves, you basically use three tools:

• IDA Pro—Use this for reverse engineering the native application components.
• readelfandobjdumpetc—Cross-compiled; that is, it can run on X86 yet parse ARM7 ELF binaries.
• checksec.sh—This is a shell script that uses readelf to verify a number of protection mechanisms and other possible weaknesses.

The specifics of reversing ELF binaries are beyond this book. Many good references are available that show how to approach this problem. Suffice it to say these references all generally translate to QNX ELF binaries.

HTML5 and JavaScript

Looking at the MANIFEST.MF for a WebWorks app reveals some useful information, as shown in Figure 14.15.

Looking at the file referenced as the entry point (app/native/wwe) you see the information shown in Figure 14.16.

You can see the file is just a shell script. The QNX documentation on HTML5 Developer's Guide (http://support7.qnx.com/download/download/26199/s_Guide.pdf) explains that it causes index.html to be loaded. This index.html is contained in the BAR's native subdirectory (as shown in Figure 14.17).

In this particular case if you go into the plugins directory and then the jnext directory, you see the file shown in Figure 14.18.

What is JNEXT? It stands for JavaScript Native EXTensions, this is a way of adding JavaScript bridges to native C libraries; the purpose of auth.txt is described as follows:

---

The set of URLs that are authorized to access JNEXT libraries for a specific browser is defined in a file named auth.txt.

−http:// www.jnext.org/using.html

---

In this particular example, these URIs are very lax and would be a security concern.

Beyond what we've just covered it is then a process of auditing the JavaScript, plug-ins, and so on for vulnerabilities.