My Concept for the Cisco Internet of Things Innovation Grand Challenge

Here is the concept I just submitted for the Cisco's IoT Challenge:

Deploy a network of fixed Bluetooth scanners throughout an urban area and/or transportation corridor to enable a region-wide alert/notification system for things: Bluetooth enabled devices that transmit a Bluetooth signal. Currently this includes: mobile phones, medical devices, consumer electronics, vehicles, smart watches, FitBits and other activity trackers, and a myriad of sensors and trackers.

This essentially addresses the last mile problem for things, using a well understood and widely adopted RF protocol (30 Billion Bluetooth devices estimated to be deployed by 2016). I have created a mobile app-based prototype of this system which supports both Bluetooth Classic and Bluetooth Low Energy (with data available at earthping.com) in which the scanning is crowdsourced (a mobile app rather than fixed scanners). Fixed scanners would be available through an API to enable subscribers to access the data. Only devices registered to be tracked (with Bluetooth Address) would be allowed, except for public safety use cases. 

Use cases for this would include:

• An Amber Alert add-on in which kids with a Bluetooth radio (they cost less that $20) or their abductors cars or mobile phones would be able to be tracked.
• Stolen cars (most will be Bluetooth enabled according to industry research) would be identified when passing by a scanner.
• Cities deploying this type of technology could license the data for market research as a revenue source (following appropriate guidelines for security and privacy).
• App developers and other commercial entities could license specific scanners (beacons) to implement iBeacon functionality in which an app (only those apps that users install on their phones and approve) would wake up in the proximity of a beacon.
• Public alert systems could leverage the beacon capability of the Bluetooth network to provide fine grain alerts based on proximity to an event.

Features that could be implemented with such a system are extensive and include any use case that might leverage alerts, triggers, geo-fencing, inventory, tracking and sensors. This type of system could save lives, provide revenue and also perhaps impact city-wide insurance premiums. The system could be deployed in increments such as a major transportation corridor, malls, or borders for specific requirements.

Bluetooth LE Captures from an item tracker

Item Tracker Bluetooth Device Captures

Below shows another advertising strategy. This shows an advertising sequence between an item tracker from Phone Halo and the Bluescan app running on an Android device with BD_ADDR of AC:22:0B:45:87:55. The second capture is between another tracking device (I got a second one of their devices via their Indiegogo campaign) and their proprietary app.

Device 1

This is the advertisement and scan request from the BlueScan app:

Advertisement

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=1287.768 ms  
 40 23 ac 91 89 1c f3 c7 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7 40 22 c7   
 Advertising / AA 8e89bed6 / 35 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: c7:f3:1c:89:91:ac (random)  
   AdvData: 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7  
     Type 09 (Complete Local Name)  
       tkr  
     Type 19  
       40 02  
     Type 01 (Flags)  
       00000110  
     Type 0a (Tx Power Level)  
       4 dBm  
     Type 03  
       3e 0f  
     Type ff  
       00 00 ac 91 89 1c f3 c7  
   
   Data: ac 91 89 1c f3 c7 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7  
   CRC:  40 22 c7  

Scan Request

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=0.352 ms  
 83 0c 55 87 45 0b 22 ac ac 91 89 1c f3 c7 a7 21 48   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: c7:f3:1c:89:91:ac (random)  
   
   Data: 55 87 45 0b 22 ac ac 91 89 1c f3 c7  
   CRC:  a7 21 48  

Scan Response

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=0.263 ms  
 44 06 ac 91 89 1c f3 c7 1a 59 6e   
 Advertising / AA 8e89bed6 / 6 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: c7:f3:1c:89:91:ac (random)  
   ScanRspData:  
   
   Data: ac 91 89 1c f3 c7  
   CRC:  1a 59 6e  

Device 2:

This is another one of their devices in which the capture was between their device and their proprietary Android app. In this case, there is an advertisement and a connection request.

Advertisement

 systime=1402002717 freq=2402 addr=8e89bed6 delta_t=27.500 ms  
 40 15 ca b3 9b 87 c2 c7 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff d8 85 00   
 Advertising / AA 8e89bed6 / 21 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: c7:c2:87:9b:b3:ca (random)  
   AdvData: 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff  
     Type 01 (Flags)  
       00000101  
     Type 09 (Complete Local Name)  
       inSite  
     Type 19  
       ff ff  
   
   Data: ca b3 9b 87 c2 c7 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff  
   CRC:  d8 85 00  

Connect Request

 systime=1402002717 freq=2402 addr=8e89bed6 delta_t=0.495 ms  
 85 22 55 87 45 0b 22 ac ca b3 9b 87 c2 c7 76 f6 7c c7 a4 66 90 02 12 00 27 00 00 00 d0 07 ff ff 7f 00 1c a5 23 dd c1   
 Advertising / AA 8e89bed6 / 34 bytes  
   Channel Index: 37  
   Type: CONNECT_REQ  
   InitA: ac:22:0b:45:87:55 (public)  
   AdvA: c7:c2:87:9b:b3:ca (random)  
   AA:  c77cf676  
   CRCInit: 0066a4  
   WinSize: 02 (2)  
   WinOffset: 0012 (18)  
   Interval: 0027 (39)  
   Latency: 0000 (0)  
   Timeout: 07d0 (2000)  
   ChM: ff ff 7f 00 1c  
   Hop: 5  
   SCA: 5, 31 ppm to 50 ppm  
   
   Data: 55 87 45 0b 22 ac ca b3 9b 87 c2 c7 76 f6 7c c7 a4 66 90 02 12 00 27 00 00 00 d0 07 ff ff 7f 00 1c a5  
   CRC:  23 dd c1  

Gimbal Bluetooth iBeacon Advertising

Gimbal iBeacons

Below are some packet captures from the Gimbal Proxmity Beacon Series 10. These are advertisements from two devices.

First 5 seconds

For the first five seconds the devices appear to broadcast their Bluetooth addresses. Notice the AdvA for each of the following two captures:

Device 1 (a4:d8:56:01:75:ce)

 size 16  
 systime=1401996656 freq=2402 addr=8e89bed6 delta_t=22295.843 ms  
 00 1b ce 75 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96 24 40 b3   
 Advertising / AA 8e89bed6 / 27 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: a4:d8:56:01:75:ce (public)  
   AdvData: 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
     Type 01 (Flags)  
       00000110  
     Type 07 (128-bit Service UUIDs)  
       960c4f00-244c-11e2-b299-00a0c60077ad  
   
   Data: ce 75 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
   CRC:  24 40 b3  
   

Device 2 (a4:d8:56:01:a5:cc)

 size 16  
 systime=1401997031 freq=2402 addr=8e89bed6 delta_t=100.627 ms  
 00 1b cc a5 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96 3b 3e 4b   
 Advertising / AA 8e89bed6 / 27 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: a4:d8:56:01:a5:cc (public)  
   AdvData: 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
     Type 01 (Flags)  
       00000110  
     Type 07 (128-bit Service UUIDs)  
       960c4f00-244c-11e2-b299-00a0c60077ad  
   
   Data: cc a5 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
   CRC:  3b 3e 4b  

The BlueScan Android app shows these as:

• Vendor: Qualcomm Labs Inc.
• Desc: FyxBoot

Then after 5 seconds...

Each device starts the following broadcasts.

Device 1 (a4:d8:56:01:75:ce)

 systime=1401999056 freq=2402 addr=8e89bed6 delta_t=417.941 ms  
 42 25 48 36 14 0f c5 10 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 93 4a 0c 96 0c ff 8c 00 4e 12 7d 0c 5c 42 59 c1 a2 3a 5f 15   
 Advertising / AA 8e89bed6 / 37 bytes  
   Channel Index: 37  
   Type: ADV_NONCONN_IND  
   Data: 48 36 14 0f c5 10 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 93 4a 0c 96 0c ff 8c 00 4e 12 7d 0c 5c 42 59 c1 a2  
   CRC:  3a 5f 15  

Device 2 (a4:d8:56:01:a5:cc)

 systime=1401999005 freq=2402 addr=8e89bed6 delta_t=650.694 ms  
 42 25 d5 1c c9 d5 5c 39 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 97 4b 0c 96 0c ff 8c 00 d1 82 94 2c 57 52 4a 6f bc 5a 62 06   
 Advertising / AA 8e89bed6 / 37 bytes  
   Channel Index: 37  
   Type: ADV_NONCONN_IND  
   Data: d5 1c c9 d5 5c 39 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 97 4b 0c 96 0c ff 8c 00 d1 82 94 2c 57 52 4a 6f bc  
   CRC:  5a 62 06  

The ADV_NONCONN_IND advertisement is an undirected broadcast that is not connectable, nor is it scanable (i.e. it won't respond to a SCAN_REQ in response to an advertisement).

Analyzing Bluetooth Advertising with Ubertooth

Bluetooth Active Scanning Example

in my last post, Understanding Bluetooth Advertising Packets, I reviewed and consolidated some key elements of advertising packet format and data structure from the Bluetooth Core 4.1 Specification. In this post, I'll review some packets, a relate the specific fields to the spec.

The following packet sequence is between a Fitbit Flex (advertiser) and Bluescan (scanner), on channel 37, using and Ubertooth Bluetooth packet sniffer per this command:

 ubertooth-btle -f  

The three packets below show a complete active scan cycle. The advertiser (Fitbit) send out a ADV_IND advertisement, and the BlueScan Android app responds with a SCAN_REQ packet requesting additional data and the Fitbit responds with a SCAN_RESP.

Fitbit advertisement (ADV_IND):

Below is the first packet captured with Ubertooth:

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=673.874 ms   
  40 21 eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04 69 6e 34    
  Advertising / AA 8e89bed6 / 33 bytes   
   Channel Index: 37   
   Type: ADV_IND   
   AdvA: f5:bb:2d:e6:12:eb (random)   
   AdvData: 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04   
    Type 01 (Flags)   
     00000110   
    Type 06 (128-bit Service UUIDs, more available)   
     adab36ca-6e7d-4601-bda2-bffaa68956ba   
    Type 16 (Service Data)   
     UUID: 180a, Additional: 07 04   
   Data: eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04   
   CRC: 69 6e 34   

Some items of note:

1. The Access Address (AA) is 0x8e89bed6 (this number is used to manage Link Layer connections and is a random number, other this this, for non advertising packets).
2. It's on channel 37, which is one of three dedicated advertising channels (37, 38 & 39) of the 40 channels in the Bluetooth spectrum.
3. The packet's PDU type is ADV_IND, which indicates a connectable undirected advertising event with the following properties:
• connectable: a scanner can initiate a connection upon seeing this event.
• scannable: a scanner can issue a scan request up seeing one of these
• undirected: this is broadcast, no Bluetooth address is specified
• payload: can contain user data in payload, whereas a directed packet cannot.
4. AdvA is f5:bb:2d:e6:12:eb, which is the device address of the advertiser. This is a random address, based on...
5. The Type '01' is a flag in the TxAddr field indicating that the AdvA address is random.
6. Type '06' is a GAP profile indicating 'Incomplete List of 128-bit Service Class UUID' defined here, with a UUID provided: adab36ca-6e7d-4601-bda2-bffaa68956ba.
7. Type '16' is also a GAP service type (here) as 'Service Data'. Additional information on this type is defined in the Core Specification Supplement, Part A, section 1.11. For this packet the value is 0x180a which is the UUID for device information.

BlueScan response (SCAN_REQ):

In response the the previous packet, BlueScan responded with this message.

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.336 ms  
 83 0c 55 87 45 0b 22 ac eb 12 e6 2d bb f5 cc 1c fd   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   Data: 55 87 45 0b 22 ac eb 12 e6 2d bb f5  
   CRC:  cc 1c fd  

Some items to note:

1. This packet again uses the advertising channel (37) and Access Address (0x8e89bed6).
2. Scan type is SCAN_REQ.
3. ScanA is the BT_ADDR (Bluetooth Address) of the scanner (BlueScan Android App) and AdvA is the same random IP of the advertiser.

Fitbit response (SCAN_RSP):

Finally, the Fitbit responds with this:

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.326 ms  
 44 0f eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa b6 c4 52   
 Advertising / AA 8e89bed6 / 15 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   ScanRspData: 05 09 46 6c 65 78 02 0a fa  
     Type 09 (Complete Local Name)  
       Flex  
     Type 0a (Tx Power Level)  
       -6 dBm  
   Data: eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa  
   CRC:  b6 c4 52  

Note:

• Type '0a'  and '09' flags are assigned numbers designated by the Bluetooth SIG Generic Access Profile, indicating what the Ubertooth output shows: 'Complete Local Name' and 'Tx Power Level' respectively.

Analyzing Gimbal Advertisements

Next, I'll have a look at Gimbals iBeacon advertisements. These use random address as a privacy mechanism, so it's worth having a look at those.

Understanding Bluetooth Advertising Packets

Bluetooth Advertising

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.

This post looks at Bluetooth Low Energy (BLE) advertising packet format and then shows some sample packets captured using an Ubertooth Bluetooth packet sniffer. First we'll look at the packet format and then look at some packets. In a future post I'll compare the captured packets to the format shown here.

Bluetooth Link Layer Packet Format

Packets in BLE are defined in the Link Layer. There is only one packet format for BLE as shown below.

BLE Packet Structure

Attributes

A packet can be 80 to 376 bits in length, and has the following components.

• Preamble: used for internal protocol management. Advertising packets have 10101010b as the preamble.

• Access Address: This is always 0x8E89BED6 (10001110100010011011111011010110b)for advertising packets.

• PDU: There are two PDU formats, one for advertising packets and one for data packets.

• CRC: 3 byte value calculated over PDU.

Bluetooth LE Advertising Channel PDU

There are only two PDU formats in BLE, one for data packets and one for advertising - shown below. Here is the GitHub Gist for the blockdiag diagram. The type of packet is determined by the channel on which the packet is transmitted. Advertising channels are 37, 38, and 39.

Advertising Channel PDU

Attributes

• PDU Type: See more info below.
• RFU: Reserved for future use
• TxAdd, RxAdd: These are defined for each individual advertising channel, but their purpose is not clear to me.
• Length: Payload length in bytes. Valid range is 6 to 37 bytes.

PDU Types

These are the PDU types; the first four are advertising channel types:

• ADV_IND (0000): Connectable undirected advertising, has the following payload:
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_DIRECT_IND (0001): Connectable directed advertising. Directed advertising is used when a device needs to quickly connect to another device. An initiating device immediately sends a connection request upon receiving this. This PDU has the following payload.
• AdvA (6 bytes): Advertisers address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• InitA (6 bytes): Initiator address. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• ADV_NONCONN_IND (0010): Non connectable undirected advertising. Used by devices that want to broadcast and don't want to be connected to or scannable. This is the only option for a device that is only a transmitter.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_SCAN_IDN (0110): (formerly called ADV_DISCOVER_IND) Scannable undirected advertising.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser

While not specifically an advertising PDU type, active scanning will involve the following additional types:

• SCAN_REQ (0011): Upon receiving and advertising packet and active scanner will issue this scan request packet, with the following payload.
• ScanA (6 bytes): Scanner address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvA (6 bytes): Device to which this PDU is addressed. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• SCAN_RSP (0100): Upon receiving a scan request (SCAN_REQ) packet and advertiser can respond with this.
• AdvA (6 bytes): Advertiser address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• ScanResponseData (0-31 bytes): Optional advertising data from advertiser
• Length: Length of response data
• CONNECT_REQ (0101): Connection request

Sample packets

Now lets look at some packet captures.

Using Ubertooth to capture Bluetooth packets, I was finally able to really visualize what was happening in my BlueScan Android scanner.  Below shows a dump from Ubertooth using the device connected to a Mac laptop as with the -f option to follow a connection:

 ubertooth-btle -f  

To capture data from another channel, the -A flag is used. On my installation, I had to take the Ubertooth out of  the USB slot for this to have an affect. Then this worked.

 ubertooth-btle -f -A 39

The following packet sequence is between a Fitbit Flex (advertiser) and Bluescan (scanner), on channel 37.

Fitbit advertisement (ADV_IND):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=673.874 ms  
 40 21 eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04 69 6e 34   
 Advertising / AA 8e89bed6 / 33 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   AdvData: 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
     Type 01 (Flags)  
       00000110  
     Type 06 (128-bit Service UUIDs, more available)  
       adab36ca-6e7d-4601-bda2-bffaa68956ba  
     Type 16 (Service Data)  
       UUID: 180a, Additional: 07 04  
   Data: eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
   CRC:  69 6e 34  

In this captures, we are listening on Channel 37 which is the default.

BlueScan response (SCAN_REQ):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.336 ms  
 83 0c 55 87 45 0b 22 ac eb 12 e6 2d bb f5 cc 1c fd   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   Data: 55 87 45 0b 22 ac eb 12 e6 2d bb f5  
   CRC:  cc 1c fd  

Fitbit response (SCAN_RSP):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.326 ms  
 44 0f eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa b6 c4 52   
 Advertising / AA 8e89bed6 / 15 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   ScanRspData: 05 09 46 6c 65 78 02 0a fa  
     Type 09 (Complete Local Name)  
       Flex  
     Type 0a (Tx Power Level)  
       -6 dBm  
   Data: eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa  
   CRC:  b6 c4 52  

For more info, I suggest to Core spec:

Bluetooth Specification Version 4.1, [Volume 6] Link Layer Specification.
(Page 2,506 of the specification, is a start)

Analyzing Packets

Next, we'll analyze some packets and compare them to the documented format.

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.

Genymotion - Setting up for Android Studio & Titanium Appcelerator

I needed to test a new Android device today and decided it was time to give Genymotion a try. So far a great experience that has greatly simplified the installation and running of new emulators. Below are steps involved to get Genymotion running for both Android Studio and Titanium Appcelerator on a Mac (OS X 10.9.3)

Get Genymotion and dependencies

Get and install Virtual Box if you don't have it already, as this is a dependency:

https://www.virtualbox.org/wiki/Downloads


Get Genymotion:

https://shop.genymotion.com/index.php?controller=order-opc

Configure Development Environments

Configure for Android Studio

Android Studio --> Preferences --> Plugins

Click the button: "Install JetBrains Plugin..."

Select "Genymotion" from the link

Restart Android Studio



Run Genymotion

Install & run an emulator.


Go to Android Studio and the emulator should be available as an option as you build and launch your app.

Configure Titanium Appcelerator (Version 3.2)

Add config to Titanium from your shell.
ti config genymotion.enabled true

View config to verify you have a section for "Genymotion Emulators"

ti info -t android

Run Genymotion
Install & run an emulator.

Then you should be able to run the app in the emulator you ran in Genymotion from Titanium Studio.

Ubertooth Mac Installation Notes

Installation notes for the Ubertooth Bluetooth test tool on Mac OS X 10.9.3.

Installation was strait forward with a glitch or two from the description described on the Ubertooth site, so I've documented the process here for my own notes.

Project site: http://ubertooth.sourceforge.net/

Note the wiki: https://github.com/greatscottgadgets/ubertooth/wiki

Getting started URL: https://github.com/greatscottgadgets/ubertooth/wiki/Build-Guide

With some help from the troubleshooting guide, here: https://github.com/Homebrew/homebrew/wiki/troubleshooting.


Get PySide & QT if you want to run the spectrum analyzer demo:
http://qt-project.org/wiki/PySide_Binaries_MacOSX

Install Brew the Mac package manager if you don't yet have it:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

Brew installation failed, so I (hesitatingly) changed /usr/local permissions:

sudo chowbn -R j2:admin /usr/local

Install prerequisites:

brew install libusb wget cmake

...including PyUSB:

wget https://github.com/walac/pyusb/archive/1.0.0b1.tar.gz -O pyusb-1.0.0b1.tar.gz
tar xvf pyusb-1.0.0b1.tar.gz
cd pyusb-1.0.0b1
sudo python setup.py install

The next step of installing libbtbb failed because a missing package:

brew install pkg-config

then libbtbb still couldn't install correctly, because of the failed partial installation. Uninstalling, didn't work, but manually removing the files from /usr/local/lib and the header file btbb.h in /usr/local/include. worked.

I was then able to install libbtbb:

wget https://github.com/greatscottgadgets/libbtbb/archive/2014-02-R2.tar.gz -O libbtbb-2014-02-R2.tar.gz
tar xf libbtbb-2014-02-R2.tar.gz
cd libbtbb-2014-02-R2
mkdir build
cd build
cmake ..
make
sudo make install

Then, I was able to continue with the installation as described on Ubertooth site:

wget https://github.com/greatscottgadgets/ubertooth/archive/2014-02-R2.tar.gz -O ubertooth-2014-02-R2.tar.gz
tar xf ubertooth-2014-02-R2.tar.gz
cd ubertooth-2014-02-R2/host
mkdir build
cd build
cmake ..
make
sudo make install

Then upgrade firmware of device. Mine shipped with a previous version of the firmware. So using the firmware provided in the source tree, and following these directions, this worked for me.

$ubertooth-util -v
    Firmware revision: 2012-10-R1

$cd ubertooth-2014-02-R2/ubertooth-one-firmware-bin

$ ubertooth-dfu --write bluetooth_rxtx.dfu
    Checking firmware signature
    No DFU devices found - attempting to find Ubertooth devices

    1) Found 'Ubertooth One' with USB ID: 1d50:6002

    Select a device to flash (default:1, exit:0):
             .............................................................................................................................................
    Write complete
$ ubertooth-dfu --detach
    Detached$ ubertooth-util -v
    Firmware revision: 2014-02-R2
$ ubertooth-util -V
    ubertooth 2014-02-R2 (dominicgs@mercury) Thu Feb 20 13:28:01 GMT 2014

Is your iPhone broadcasting your name via Bluetooth?

Very likely!

I developed BlueScan, an Android Bluetooth scanner, as a research project to better understand Bluetooth usage in the wild. The app scans for Bluetooth devices (Low Energy and Classic) and stores the results in a database on the phone which can then be downloaded for analysis.  As a mobile app, it allows me to identify nearby Bluetooth signals as I'm driving around town - essentially war driving for Bluetooth except that it's scanning passively - it just listens for broadcasts but does not initiate any connections.

Initial Observations: 

After a couple of days of on-again off-again scanning as I tested the app, I had a look at the data I had collected. The most obvious observation based a small dataset of 152 devices was that one quarter of the Apple users (mostly iPhones, iPads and Macbooks) were broadcasting their full names via Bluetooth. 

Here is the breakdown based on the 152 devices in the dataset:

• 36 of the 152 devices were Apple devices
• 9 of the Apple devices included both first name and last name identifier, as in "John Abraham's iPhone"
• 19 of the Apple devices had just a first name identifier such as "John's MacBook Pro"
• Only 8 of the 36 Apple devices were broadcasting but not including some sort of personal or device naming in their broadcasts

In infosec, we'd characterize this as unnecessary information disclosure. While information disclosure by itself is not always a high risk security issue in the enterprise information security realm, it's best practice to avoid doing so. In the consumer realm this is a privacy issue and you never how or when this kind of information can be used or aggregated with some other data. Given the number of Bluetooth scanners in public places thanks to the adoption of Bluetooth Low Energy and the boost from iBeacon, Apple users should be aware of this. 

Considerations for Cross Platform App Development - Direct iOS/Androd SDK vs. Titanium Appcelerator

After having developed a number of apps on both iOS and Android, using both native SKDs as well as a cross platform development toolkit (Titanium Appcelerator) , I thought I'd reflect on some of the benefits and drawbacks that I experienced using Titanium as opposed to doing development directly in the native development environments. With more experience developing on Android with Java than on iOS with Objective-C, this comparison is based more on my specific Android/Java experience, though it's applicable to both.

• Documentation: I found the Titanium Appcelerator documentation somewhat lacking in detail and incomplete. This issue is somewhat mitigated by the fact that the developer community Q&A site is active enough that answers to most questions can readily be found. However, I'm a big fan of Google's developer documentation in general and along with the over-abundance of StackOverflow activity, it's always a pleasure to develop in a Google environment.

• Cross Platform Compilation. For the McRun Running Calculator of which we have an iOS version and an Android version, we developed first for iOS and released a couple of versions using Titanium Appcelerator getting the app stable on iOS before moving to Android. Development time for initial release was perhaps an 8-10 week project. This included working through UX considerations, directing graphic design, and also working thorough the process of implementing and testing the algorithm that is the core of the McRun app. Other than having to do additional graphic work (see below) to support android, much of this effort translated to Android with zero additional effort. However, while much of the backend code was easily ported to Android, most of the UI components had to be completely redone on Android. Appcelerator calls their cross platform framework as a "write once, adapt everywhere" platform, in which perhaps 80% to 100% of the code can be re-used. My experience is that now that we have revised the code to support both Android and iOS with conditional branching in the code (if (platform=="iOS" { // do iOS stuff } else { //do Android stuff }) and some conditional includes per platform, the code is now perhaps 90% compatible across both platforms. Eventually, we might strive to release updates on both platforms concurrently. Right now, we're one code base, and we release on one platform, then later do a release on another, and things get broken across platforms in the process. On our first Android build when the UI was so broken that app was in no way usable - complete jumbled spaghetti - fixing this and getting release ready was about a 3 week project. So from an effort perspective,  it required an additional 1/3 of the iOS development effort to release on Android.

• Graphic Assets: Beyond the actual porting to Android, it's important to understand that the screen size and density permutations on Android is really extensive as compared to iOS which owns the entire hardware and software stack. Android development required multiple versions of graphics to support the various device configurations. This effort was wrapped into our porting effort mentioned above, but would have been required even if our app was purely an Android only app. iOS is easy in this respect - though I suspect this will change in the future.

• Performance: I have found that Titanium performance on iOS to be very crispy. The load time is fast and the UI is very responsive. While the same app built on Titanium for Android suffers from extremely slow startup time. I suspect (and hope) this is an issue we'll be able to debug (more on this below) and resolve, but as of now, this remains an open issue and - for me - remains a big negative factor with Titanium Appcelerator.

• Debugging: One challenge with Titanium Appcelerator is debugging on-device Android debugging. Developing directly in Java provides easy access to debug, error message, stack traces, etc. This is something I am still working through, so I may have more to say, but for now, I am still unclear on where my issue is on my app load performance issue on startup and on-device debugging capabilities aren't helping.

• File size: An app built on the Titanium Appcelerator platform might be a 6MB Android APK file, whereas the same app built directly on Android with Java, would likely be less than 1MB; this is similar with iOS. While mobile devices are resource constrained on many levels, I don't believe that file storage is the biggest constraint. So, while this is definitely something to be aware of, this is not necessarily a deal breaker.

• Hardware support: One benefit of using Titanium Appcelerator as compared to an HTML5 cross platform solution (at least the last time I checked) is that you get access (albeit indirectly) to the device APIs that control the hardware; so in theory as a developer you get full access to cameras, audio and sensors, such as the accelerometer.  Where this breaks down however, is where Appcelerator opts not to support an element of the API. For example, with BlueScan, my Android Bluetooth 4.0 scanner app research project, direct development in Java worked best as Titanium chose not to support Bluetooth. I have contacted Appcelerator directly and submitted an Issue that has been unresolved for months. Furthermore there are quite a few comments on the developer message boards that have gone unanswered by the Appcelerator team, so Bluetooth support doesn't appear to be on the horizon. There is a 3rd party module available but I didn't want to entrust my core code to a module that seemed to have limited usage and unproven support. Furthermore, as a research project, I needed to be tinkering at a lower level with Bluetooth capabilities, so I did not want to be abstracted from the API. Not all apps are appropriate for Titanium.

• API Updates: One risk of using a framework like Appcelerator's Titanium is that their team needs to react and revise their platform as the underlying Android and iOS APIs evolve. I have seen a number of API updates (including the update to support the iPhone5) during my Appcelerator development cycles and was always surprised how quickly the Appcelerator team reacts to updates. This has never been an issue for me.

• App store submittal: I haven't noticed any difference in my experience submitting to the app stores based on my development platform. As a security guy I like the Apple closed system, but as a developer Android is refreshingly simple and fast.

These are just my un-scientific observations. What's the best approach for cross platform development? I guess as with most anything, that really depends on the specific requirements, but there are merits to either approach.

Android: Java Adapters & Loaders

After porting the McRun iOS app to Android, I realized that using a cross platform framework was not going to work for my Bluetooth scanning data collection project as I needed better access to the radio hardware interfaces.  So I developed BlueScan directly on the Android SDK. While I am always a fan of Google's developer documentation, I found that the Java frameworks for adapters and loaders a bit abstract. As such I documented the framework for a very common development scenario: accessing a database and providing the results to a ListView with favorable UI performance.

The following diagram provides the overview of my class implementation to implement this in the BlueScan Bluetooth 4.0 scanner.

I leveraged a number of resources for getting my arms around the framework:

• The Android Programming book by the Big Nerd Ranch team had descriptive examples as well as a good reusable SQLiteCursorLoader class, which I used here.
• Android's android.widget.Adapter.
• The API guide for List View.