Wednesday, December 17, 2014

Sony Breach: Will Visualizing Sony Implosion Lead to Improved IT Governance

So I've been watching breaches for many years and the latest Sony breach is awe inspiring in terms of the scale of the breach and maliciousness in intent; the breach seems to transcend the typical profiteering objectives and feels more like economic espionage. The scale and intent of this breach seems to have intersected with a company which lacks both value in security management as well as IT governance. They clearly have not learned from past mistakes and now they seem to now be faced with the biggest security spectacle in a decade.

Only time will tell, but at this point this breach may have lasting impact in the minds of executive management worldwide. IT governance could rank higher, much higher, in the minds of corporate leadership. From a governance standpoint the impact of many breaches is reduced mainly to quantifiable dollars, perhaps the cumulative cost of the breach and impact to stock price with a little brand damage thrown in. Even 100 million dollars of breach cost is not nearly catastrophic for a business unit that can generate multiples of that in profit in a single quarter.  However, whatever the future holds for Sony, it's not inconceivable to see a scenario where the entire Sony Pictures Entertainment crumbles and significantly impacts the greater Sony conglomerate. It's not so much that that will happen as much as that scenario seems plausible. Corporate boards will be able to visualize that in their own organizations. With that potential impact I feel that we could be ushering in a new era of IT governance.

A couple of thoughts come to mind for corporate boards and IT stewardship in terms of their ability to provide effective IT oversight.

1. Every board should be able to answer the following questions as part of a competency test for their ability to manage security risk and IT governance:
  • What are the risks associated with having the security department report directly into the IT organization? and, 
  • Who is reporting to the board about security risk and IT controls and what might their bias be?
Hint 1: One key unstated objective of a corporate CIO or IT director is to keep their job, put food on the table and otherwise keep a paycheck; a good way to achieve that is to demonstrate what a great job they are doing, which in fact can be said about most jobs. 
Hint 2: A key objective of a security assessment of an outside auditor is to identify weaknesses in the IT environment.
Hint 3: Hint 2 is in direct conflict with Hint 1.
2. Does the board have a technical member that can help facilitate meaningful discussion around security and technology infrastructure.

Clearly the Sony breach demonstrates a new avenue and motivation for security breaches. From a governance perspective, the risk should be perceived as much more open-ended. Perhaps the day of classifying data disclosure purely in terms of monetary impact that can be insured against or hedged with huge profits is over. Corporate risk management will begin so imagine breach impacts so significant that it could change the course of an entire company.



Tuesday, December 16, 2014

iOS Anti-Phishing Functionality: Marginal

Anti-Phishing Features in iOS are of Limited Value

The anti-phishing functionality in iOS is functional, but there is a significant lag in updating the phishing site database, According to Apple, when turned on the functionality should alert you if you click on a link to a known phishing site.



Enabling this feature on my iPhone (5s running iOS version 8.1.2) seemed to work, but only if I go back to phishing sites that were reported the previous day. I used sites reported by phishtank.com for the test. 

The following sites were tested. These included sites identified within the last 24 with the most recent reports first.  (Note these are documented phishing sites. Visit at your own risk.). The first few sites were not detected as phishing sites when clicked on in my iPhone Safari browser. Only the last two. However, on desktop chrome browser, all of the following links presented a warning.


  1. http://www.89jzlm.com/c.htm
  2. http://smartstayzzzinns.com/
  3. http://yengeec.com/scar/sure/
  4. http://www.accedi.esy.es/
  5. http://zenhair4arab.com/p3yp3l.org/paypal/
When successfully identified as phishing sites with my iPhone (sites 4 & 5, above) the following message was displayed.




Conclusion

Be wary. According to the Anti-Phishing Working Group  (APWG) "Apple became the world’s most-phished brand" this year. Phishing sites tend to be somewhat temporary anyway, with an average uptime of less than 33 hours according to APWG in its report from June of 2014. As such Apple's delay in updating its phishing database makes it of very limited value given that phisher's are adept at acting fast using new phishing sites for active campaigns.

How to configure anti-phishing

You'll still need to be aware of websites you visit (difficult on a mobile browser) and be wary of submitting your credentials, but it still makes sense to ensure that you have the anti-phishing settings turned on. Here's how:


Go to Settings-->Safari and turn on "Fraudulent Website Warning".







Tuesday, December 9, 2014

Sony Breach - How A Hack Will Add Transparency To Your IT Practices (AKA I've Seen This Movie Before)

Having spent 15 years in security and building a security assessment company, which helps companies identify and mitigate security risk, I've been at ground-zero for many data breaches. I've seen the fallout. I've watched as companies that couldn't even a fund realistic budget to help address security risk, make outsized expenditures after a security incident. I've seen companies that couldn't even get an internal risk management meeting together with key stakeholders, involve many lawyers, executive management, IT and compliance personal and even the board of directors, after an incident.

As it turns out IT gets a lot of attention after a breach.

So while there may not be much visibility into the inner-workings of your IT function before a breach, you can bet there will be after. Corporate IT is becoming very, and it's difficult to gauge the overall robustness of many IT environments at a glance. In effect, IT is not inherently transparent. However, what you will find is that after a breach, there is significant scrutiny to IT practices. Few people really know what's happening in your IT environment before a breach, but everyone will be looking at your IT practices after.

And this increased visibility creates two phases of impact. The first phase is the data disclosure impact such as the compromised credit card numbers, account numbers, passwords, social security numbers, confidential data, etc., and the associated liability. The second phase is the impact associated with how your IT environment is viewed once it comes under scrutiny.

The poster child of this was CardSystems Solutions a credit card processor. They had 40 million credit cards compromised from their systems. However, it wasn't the incident itself, but their security practices exposed after the breach that led their downfall. When it was discovered that they had been storing unencrypted card numbers on their network their biggest customers, Visa and American Express, dropped them, and they eventually shuttered.

And more recently you can see the dissection of Sony's security practices, such as:


Interviews with former employees:
“Sony’s ‘information security’ team is a complete joke,” one former employee said. “We’d report security violations to them and our repeated reports were ignored.” on Time's website.
Similar tweets:



And a Mashable post with the headline:
"Sony Pictures' security chief once thought data breaches weren't a big deal"

Of course you might be able to say this about any organization or perhaps you could argue that these quotes have been taken out of context. There is certainly plenty of monday-morning-quarterbacking happening here, but these comments, along with some of apparent lax security controls reinforce the idea that Sony's culture didn't foster robust security processes. 

And I've experienced this attitude first hand. I once drove 90 miles to meet a potential client to deliver a proposal for a web application security assessment when I was building Redspin. When I got to the meeting, the CIO not only failed to show for our confirmed meeting but had no excuse, apology, or any reasoning whatsoever; not even a comment or message.  You can imagine my surprise when, a month or so later, I got a call from that same CIO. The company had been hacked, in fact, the very web application we would have evaluated got compromised in a very public way. So while I couldn't get the attention of the CIO for a meeting in his own conference room a month before, at this point the CIO was calling from the board room, with a room full of attorney's, top management and board members. It was real fire drill; lots of people were looking at IT. 

So I counsel executives to do this exercise: 

  • Pretend you just got hacked. Now, imagine how your security practices and decisions will be viewed.
Ask yourself these questions:

If we have a breach, and if my IT process is exposed, will it look like:


  • our organization value's security?
  • I care about generally accepted best-practices?
  • we respect the security process?
  • I value our employees input? 
What we do know is that your environment won't look perfect. No environment will look anywhere near perfect. IT is too complex and too dynamic. But will it look like you are even trying? Will it look like you care and even respect the process? Will it look like you care about your employee and customer data?


Thursday, June 19, 2014

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.

Thursday, June 5, 2014

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.

Wednesday, June 4, 2014

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.

Thursday, May 22, 2014

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.


Wednesday, May 21, 2014

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