Applications Details

The Bluetooth application we developed focuses on gathering basic information about the local Bluetooth adapter on a physical device, as well as basic information on any bonded (paired) devices. To accomplish this, two Android permissions must be added to the manifest file in addition to those required for the application’s network connectivity, namely android.permission.BLUETOOTH and android. permission.BLUETOOTH_ADMIN. We also declare a new Broadcast Receiver within

87 _{Guidance regarding Android support for Bluetooth capabilities can be found at:} http://developer.android.com/guide/topics/connectivity/bluetooth.html.

88 _{Additional details regarding the BluetoothAdapter API can be found at:} http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html.

89 _{Additional details regarding the BluetoothDevice API can be found at:} http://developer.android.com/reference/android/bluetooth/BluetoothDevice.html.

our application’s manifest, which we use to capture system broadcasts of any Bluetooth state changes (i.e., an intent filter for this receiver is set up on the action android.bluetooth.adapter.action.STATE_CHANGED). This effectively creates two different entry points for our application once installed.

Within the onCreate method of our main Activity, a BluetoothAdapter is instantiated using the getDefaultAdapter method of its corresponding API. After verifying that the adapter object is not null (i.e., that the system executing the application does indeed support Bluetooth hardware capabilities), we capture initial information from various attributes of the BluetoothAdapter. These are displayed on the device’s screen as well as logged to our EC2 server. Afterwards, we test whether the device’s Bluetooth adapter is enabled (turned on) by inspecting its current state value. If the adapter is off, we call its enable method and are forced to restart the current Activity. These programming details are shown in Figure 18.

Figure 18. Code snippet for onCreate in the Bluetooth app.

The restart of the main Activity is required because we are attempting to programmatically turn on Bluetooth hardware capability without requesting user interaction, which goes against the Android developer’s best practices [51]. Typically, when an application requests Bluetooth capabilities to be turned on, or to start discovery mode, the user should be prompted with some type of enabling dialog, similar to what is shown in Figure 19.

Figure 19. The enabling Bluetooth dialog, from [51].

The action of enabling the Bluetooth adapter on the device should generate a system broadcast indicating the Bluetooth state is changing, which is received by our BluetoothBroadcastReceiver. For each state change, the receiver checks whether the adapter is enabled, and if so captures the newly changed adapter information, logs it to the Android system, and sends it to our EC2 server. If the adapter is not enabled yet, the receiver logs a simple message indicating the current state and sends this to our EC2 server. A typical state change while a Bluetooth adapter is being enabled would go from STATE_OFF (integer value of 10), to STATE_TURNING_ON (integer value of 11), to finally STATE_ON (integer value of 12). The receiver’s onReceive method performing these actions is shown in Figure 20.

Figure 20. Code snippet for onReceive in the Bluetooth app.

The Bluetooth adapter information we capture and log includes the hardware address, the adapter name (which usually defaults to the device’s manufacturer and model if a user has not changed this through Android preferences or settings), its current scan mode (e.g., whether its discoverable by other remote devices or able to be connected to by other remote devices), and its current state. We also capture how many Bluetooth devices are currently bonded (paired) to the phone and gather basic details about those devices if any are present. These details are shown in Figure 21. MD5 hash values for each APK file submitted and additional source code are provided in Appendix A.

Figure 21. Code snippet for setBluetoothData in the Bluetooth app. 3. Results

Results for the various Bluetooth attributes obtained during runtime execution of the Bluetooth application are provided in Table 16. We performed testing on the physical devices by initially pairing them with a Plantronics M165 Wireless Bluetooth Headset and then turning the Bluetooth adapter off on each device.

Table 16. Bluetooth application results

Attribute Tested

Devices Malware Analysis Services

G ala xy S 4 G ala xy S 5 G ala xy No te 4 Nexus 5 An d ro id S and b o x An d ru b is AP K S ca n Co p p er Droid Joe S and b o x Mob ile -S and b o x S and Droid T rac e Droid V isua lTh rea t

Bluetooth adapter present? ✔ ✔ ✔ ✔ * ✗ ✗ ✗ ✗ ✗ ✗ ✗

Adapter address OUI90 52:2e:59 44:6d:6c 64:b8:53 88:c9:d0

Adapter name Samsung _S4 SM-G900H Samsung Galaxy

Note4 Nexus 5

Scan modes during execution91 20,21 20,21 20,21 20,21

States during execution92 10,11,12 10,11,12 10,11,12 10,11,12

Number of paired devices 1 1 1 1

* Android Sandbox continued its trend of making HTTP requests to our EC2 server, but without any POST variable data for logging.

90 _{Organizational Unique Identifiers correspond to the first 24 bits of a 48-bit hardware or physical address on a network-capable adapter. The IEEE assigns} OUIs to specific vendors, and therefore these can be useful when trying to determine whether an environment is executing on a physical device or in an emulated environment. The Wireshark foundation provides an online tool for looking up known OUI addresses at: https://www.wireshark.org/tools/oui-lookup.html.

91 _{Bluetooth adapter scan modes correspond to the following constant integers defined in the BluetoothAdapter API: SCAN_MODE_NONE (20),} SCAN_MODE_CONNECTABLE (21), and SCAN_MODE_CONNECTABLE_DISCOVERABLE (23).

92 _{Bluetooth adapter states correspond to the following constant integers defined in the BluetoothAdapter API: STATE_DISCONNECTED (0),} STATE_CONNECTING (1), STATE_CONNECTED (2), STATE_DISCONNECTING (3), STATE_OFF (10), STATE_TURNING_ON (11), STATE_ON (12), and STATE_TURNING_OFF (13). Note that states 0 through 3 were not added until Android API level 11.

4. Discussion

A large number of smart devices come with Bluetooth readily available as a hardware capability nowadays, as evidenced by the enormous product listing on the Bluetooth® website.93 _{Based on this assertion then, the absence of a Bluetooth adapter on} a smart device (specifically on a phone or tablet), which is capable of installing an Android application, would likely indicate the presence of an emulated runtime environment. Each service that responded with Bluetooth data to our EC2 server indicated it was unable to instantiate a BluetoothAdapter object by calling its getDefaultAdapter method, thereby indicating no adapter was present.

Based on this initial result, the additional attributes of adapter address, name, scan mode, state, and number of paired devices are inconsequential for our testing purposes. They do, however, provide additional data points of interest to explore should any malware analysis service begin implementing (or simulating) a Bluetooth adapter in the future.

Although we did not perform Bluetooth device discovery or connection testing with available paired devices, these too could serve as additional validation checks for execution of an application on a physical device. Obviously the results for this would heavily depend upon the proximity of other Bluetooth capable devices; however, it would be interesting to test what changes are registered by a device’s magnetic field sensor while its Bluetooth adapter is transmitting during device discovery. We leave this to be explored in future work.