[Hackrf-dev] A BTLE (Bluetooth Low energy) packet sniffer/scanner sender

Mon Nov 9 07:18:05 EST 2015

"I can reproduce this" -- TYPO
"I can't reproduce this"

On Mon, Nov 9, 2015 at 7:54 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> See comments in line.
>
> On Mon, Nov 9, 2015 at 5:18 PM, Iluta V <iluta2009 at gmail.com> wrote:
>
>> Hi, Xianjun,
>>
>> Thank you for your response and suggestions. Here are command lines both
>> for RX and TX and outputs. BTLE discovery mode works the best. For othr
>> commands there are interesting questions. :)
>>
>> *RX:*
>>
>> 1. *btle_rx -c 37 -g 6 -a 89ABCDEF -k 555555 -v -r*, and also  *btle_rx
>> -c 37 -g 6 -a 89ABCDEF -k 0000acce -v -r*
>>
>> I tried with different channels, different gains, it gives out seg fault
>> message: Segmentation fault (core dumped)
>>
>> I can reproduce this. Maybe you can try to step-by-step debug. I use
> hackrf release "hackrf-2015.07.2". You can also try this. AND REMEMBER:
> CHANGE:
>
> lib_device->transfer_count to 4
> lib_device->buffer_size to 4096
>
> in hackrf driver: hackrf.c. You should do that change to your HACKRF
> source code and re-compile, re-install hackrf software. Then build my tools.
> <https://github.com/mossmann/hackrf>
>
>
>>
>> 2. I got a readable message with just default descriptions in command
>> line, and I got RX working on my HackRF now:
>>
>> *btle_rx -c chan -g gain -a access_addr -k crc_init -v -r*
>>
>> Cmd line input: chan 0, freq 2404MHz, access addr 00000000, crc init
>> 00acce raw 12 verbose 1 rx 1dB ((null))
>>
>> 406us Pkt1 Ch0 AA:0000acce
>> Raw:4d0001002093d408e03311503281c0502242028ae4e04858241002c0041c922c0c11b207049405821c08
>> 6487874us Pkt2 Ch0 AA:0000acce
>> Raw:02918600b0880000491345804580300283800008a8584400005044a00e0c814140102b10008040100014
>>
>> *TX:*
>>
>> 1. As non root:
>>
>> * btle_tx packets.txt*
>> num_repeat 1
>> num_packet 3
>>
>> packet 0
>> channel_number 37
>> pkt_type ADV_IND
>> payload_len 17
>> num_info_bit 192
>> after crc24
>> aad6be898e00119992b1ebd7900201050702031802180418a85def
>> after scramble 216 0
>> aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> num_phy_bit 216
>> num_phy_sample 880
>> space 1000
>> INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
>>  PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>> save_phy_sample: fopen failed!
>> save_phy_sample: fopen failed!
>> save_phy_sample_for_matlab: fopen failed!
>> save_phy_sample_for_matlab: fopen failed!
>>
>> packet 1
>> channel_number 37
>> pkt_type CONNECT_REQ
>> payload_len 34
>> num_info_bit 328
>> after crc24
>>
>> aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
>> after scramble 352 0
>>
>> aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> num_phy_bit 352
>> num_phy_sample 1424
>> space 1000
>> INFO
>> bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
>>  PHY
>> bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>> save_phy_sample: fopen failed!
>> save_phy_sample: fopen failed!
>> save_phy_sample_for_matlab: fopen failed!
>> save_phy_sample_for_matlab: fopen failed!
>>
>> 2. As root:
>>
>> *btle_tx packets.txt*
>>
>> packet 0
>> channel_number 37
>> pkt_type ADV_IND
>> payload_len 17
>> num_info_bit 192
>> after crc24
>> aad6be898e00119992b1ebd7900201050702031802180418a85def
>> after scramble 216 0
>> aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> num_phy_bit 216
>> num_phy_sample 880
>> space 1000
>> INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
>>  PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>>
>> packet 1
>> channel_number 37
>> pkt_type CONNECT_REQ
>> payload_len 34
>> num_info_bit 328
>> after crc24
>>
>> aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
>> after scramble 352 0
>>
>> aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> num_phy_bit 352
>> num_phy_sample 1424
>> space 1000
>> INFO
>> bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
>>  PHY
>> bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>>
>> See the difference of outputs when as non root and as root.
>>
>> This should be due to your linux file system access rights setting. You
> may check by yourself.
>
>
>> 3.  *btle_tx packets_discovery.txt*
>> num_repeat 40
>> num_packet 1
>>
>> packet 0
>> channel_number 37
>> pkt_type DISCOVERY
>> AA 8
>> 0101-0101
>> 0101-0101
>> D6BE898E 32
>> 0110-1011 0111-1101 1001-0001 0111-0001
>> 0110-1011 0111-1101 1001-0001 0111-0001
>> ADVA buffer begin from 7
>> 010203040506 48
>> 0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000
>> 0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000
>> display buffer begin from 15
>> CA1308 11950 22.626 113.823 8 232
>> 1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100
>> 1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100
>> 0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100
>> 1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100
>> 0001-1100
>> 1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100
>> 1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100
>> 0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100
>> 1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100
>> 0001-1100
>> length and AD_TYPE 16
>> 0111-1000 1001-0000
>> 0111-1000 1001-0000
>> payload_len 37
>> num_info_bit 352
>> num_info_byte 44
>> before crc24
>>
>> aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
>>
>> aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
>> after crc24
>>
>> aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121
>>
>> aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121
>> after scramble 376 47
>>
>> aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
>>
>> aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
>> num_phy_bit 376
>> num_phy_sample 1520
>> space 200
>> INFO
>> bit:aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
>>  PHY
>> bit:aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>>
>> r0 p0 at 0us
>> r1 p0 at 299024us
>> r2 p0 at 298557us
>> r3 p0 at 300177us
>> r4 p0 at 298612us
>> r5 p0 at 298388us
>> r6 p0 at 298671us
>> etc....
>>
>> 4.
>> *btle_tx packet1 packet2 ... packetX ...  r-1*num_repeat -1
>> num_packet 5
>>
>> packet 0
>> Getting channel number failed! It should be 0~39.
>> failed!
>>
> You should replace packetX with valid description. Maybe you should read
> readme carefully.
>
>
>>
>> What you think?
>>
>> Sincerely,
>>
>> Iluta
>>
>> On Mon, Nov 9, 2015 at 2:33 AM, Jiao Xianjun <putaoshu at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Very glad to see my first "customer ". Two suggestions:
>>> 1. Can you paste me the exact btle_tx parameters/command-line? Let me
>>> check if this is a bug.
>>>
>>> 2. For btle_rx and btle_rx, not recommend you use like 00000000/11111111
>>> as access address. Because in my program, this sequence acts as a unique
>>> word/preamble to do packet detection. It needs to be some "random".
>>>
>>> On Mon, Nov 9, 2015 at 00:39 Iluta V <iluta2009 at gmail.com> wrote:
>>>
>>>> Dear Xianjun,
>>>>
>>>> Thank you very much for the great work you did!
>>>>
>>>> I already tried out your packet sniffer. Just installed it. Could you
>>>> please have a look at my output. Did I get the packet 0 and packet 1 the
>>>> right way, and did packet 2 failed or because of something else.
>>>>
>>>> Maybe you could tell why it is so, and what else I could do to improve.
>>>> Here is the output for BTLE packets:
>>>>
>>>> *packet 0*
>>>> channel_number 37
>>>> pkt_type ADV_IND
>>>> payload_len 17
>>>> num_info_bit 192
>>>> after crc24
>>>> aad6be898e00119992b1ebd7900201050702031802180418a85def
>>>> after scramble 216 0
>>>> aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>>>> num_phy_bit 216
>>>> num_phy_sample 880
>>>> space 1000
>>>> INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
>>>>  PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>>>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>>>> IQ_sample_byte.txt
>>>>
>>>> *packet 1*
>>>> channel_number 37
>>>> pkt_type CONNECT_REQ
>>>> payload_len 34
>>>> num_info_bit 328
>>>> after crc24
>>>>
>>>> aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
>>>> after scramble 352 0
>>>>
>>>> aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>>>> num_phy_bit 352
>>>> num_phy_sample 1424
>>>> space 1000
>>>> INFO
>>>> bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
>>>>  PHY
>>>> bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>>>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>>>> IQ_sample_byte.txt
>>>>
>>>> *packet 2*
>>>> channel_number 9
>>>> pkt_type LL_DATA
>>>> get_next_field_bit: Half octet is encountered! num_hex 1
>>>> X
>>>> Invalid packet content for specific packet type!
>>>> failed!
>>>>
>>>> Please let me know what you think! Thank you again,
>>>>
>>>> Sincerely,
>>>>
>>>> Iluta
>>>>
>>>>
>>>> On Sat, Nov 7, 2015 at 6:16 PM, Jiao Xianjun <putaoshu at gmail.com>
>>>> wrote:
>>>>
>>>>> BTLE packet sniffer/scanner/sender. Some updates:
>>>>> http://sdr-x.github.io/BTLE-SNIFFER/
>>>>>
>>>>> Now all BTLE channels (0~39, bothe ADV and DATA channels) are
>>>>> supported. You can use btle_tx and btle_rx to send or sniff on any BTLE
>>>>> channel.
>>>>>
>>>>> Raw mode are now supported on both btle_tx and btle_rx. Under this
>>>>> mode of btle_rx, after access address is detected, following raw 42 bytes
>>>>> (without descrambling, parsing) are printed out. By this way, you can do
>>>>> other experiments or communication between HACKRF boards easily.
>>>>> Have fun.
>>>>>
>>>>>
>>>>> On Wed, Nov 4, 2015 at 1:27 AM, Jiao Xianjun <putaoshu at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Based on my previously released BTLE packet sender, now I have done a
>>>>>> initial version of BTLE packet sniffer/scanner (Just like TI's packet
>>>>>> sniffer). See here: http://sdr-x.github.io/BTLE-SNIFFER/
>>>>>>
>>>>>> Regarding the latency/real-time processing, I did some experiments
>>>>>> and tries, and believe that even implementation via USB (instead of on
>>>>>> board MCU), we still have chance to follow those "slow" frequency hopping
>>>>>> link. I did see many BTLE link was setup as hopping interval
>>>>>> >15ms/20ms/30ms by packet sniffer.
>>>>>>
>>>>>> Main efforts are:
>>>>>> 1. Algorithm optimization for real-time processing, such as fixed
>>>>>> point, CRC table, scrambling table, etc.
>>>>>> 2. change lib_device->transfer_count to 4 and lib_device->buffer_size
>>>>>> to 4096 in hackrf driver: hackrf.c. Original buffer size and buffer count
>>>>>> is very big so that latency is pretty big. By this modified driver,
>>>>>> according to my experiment, seems that tx and rx can be done in less than
>>>>>> 10ms: processing latency is about 3~4ms, and worst case buffer delay is
>>>>>> around 4ms.
>>>>>>
>>>>>> Snapshots of HACKRF BTLE packet sniffer VS TI's packet sniffer under
>>>>>> fastest flow of continuous/non-gap BTLE packets sequence to demonstrate
>>>>>> full real-time processing ability. They capture the same amount of packets
>>>>>> and contents:
>>>>>>
>>>>>> http://sdr-x.github.io/media/mine-btle-sniffer2.png
>>>>>> http://sdr-x.github.io/media/TI3.png
>>>>>>
>>>>>> youtube: https://youtu.be/9LDPhOF2yyw
>>>>>>
>>>>>> Besides,
>>>>>> A new packet type "Discovery" is added, which can display any names
>>>>>> and services via btle_tx to your App like LightBlue. ( I use this packet
>>>>>> type in the "ADS-B BTLE Air Relay" http://sdr-x.github.io/abar/ to
>>>>>> display flight information)
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 22, 2014 at 9:07 PM, Michael Ossmann <mike at ossmann.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I agree that some code on the ARM would be required.  Additionally,
>>>>>>> there are probably ways to improve the tuning and rx/tx switch timing
>>>>>>> even from the ARM.  We haven't done much to optimize those things.
>>>>>>> There may be a lot of time that could be saved by speeding up SPI or
>>>>>>> I2C
>>>>>>> communication or by eliminating unnecessary commands being issued by
>>>>>>> the
>>>>>>> ARM to the other chips.  It may even be possible to parallelize some
>>>>>>> things that are now done in sequence.
>>>>>>>
>>>>>>> Overall, I'm pretty sure that the timing required for LE operation is
>>>>>>> achievable, but I'm not sure how close our current code is to being
>>>>>>> fast
>>>>>>> enough.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 06, 2014 at 09:55:13AM +0800, Jiao Xianjun wrote:
>>>>>>> >
>>>>>>> > Hi Ryan,
>>>>>>> >
>>>>>>> > Thanks a lot for your offering the information. You are mastery on
>>>>>>> BTLE
>>>>>>> > protocol! I should learn more.
>>>>>>> > 150us seems too fast for computer, and should consider on-board
>>>>>>> processing.
>>>>>>> >
>>>>>>> > BR
>>>>>>> >
>>>>>>> > Jiao Xianjun
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Aug 6, 2014 at 9:46 AM, Mike Ryan <mikeryan at lacklustre.net>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > > It is possible to hop at such a low rate, but the timing of the
>>>>>>> > > beginning of each connection event (where the master and slave
>>>>>>> transmit
>>>>>>> > > on each channel) has to be very precise. Additionally, a master
>>>>>>> and
>>>>>>> > > slave must have a TX-to-RX and RX-to-TX turnaround time of 150
>>>>>>> +/- 2 us.
>>>>>>> > >
>>>>>>> > > In other words, after a master transmits, it must be able to
>>>>>>> receive the
>>>>>>> > > slave's reply within 150 us. A slave must be able to switch from
>>>>>>> > > receiving the master's packet to transmitting its reply within
>>>>>>> 150 us.
>>>>>>> > >
>>>>>>> > > On Wed, Aug 06, 2014 at 09:30:19AM +0800, Jiao Xianjun wrote:
>>>>>>> > > > You are correct on that USB latency. I did a quick experiment
>>>>>>> just now to
>>>>>>> > > > test fastest switching speed of my BTLE packet sender via
>>>>>>> hackrf (Set
>>>>>>> > > Space
>>>>>>> > > > field to 1, means that I want it be 1ms). It is around 60ms.
>>>>>>> (See the
>>>>>>> > > > snapshot attached, time stamp of the last three packets).
>>>>>>> > > >
>>>>>>> > > > 60ms maybe not so bad for real BTLE frequency hopping? I just
>>>>>>> do a quick
>>>>>>> > > > search for this to verify that (see attached two .pdf, and
>>>>>>> search hopping
>>>>>>> > > > in them). Seems that hopping speed requirement is not so high,
>>>>>>> and 60ms
>>>>>>> > > is
>>>>>>> > > > OK. Just paste some related words here:
>>>>>>> > > >
>>>>>>> > > > "For a new connection event, master and slave use a new data
>>>>>>> channel
>>>>>>> > > > frequency, which is computed
>>>>>>> > > > by using the frequency hopping algorithm. The time between the
>>>>>>> start of
>>>>>>> > > two
>>>>>>> > > > consecutive connection
>>>>>>> > > > events is specified by the connInterval parameter, which is a
>>>>>>> multiple of
>>>>>>> > > > 1.25 ms in the range between
>>>>>>> > > > 7.5 ms and 4 s. Another important parameter is
>>>>>>> connSlaveLatency, which
>>>>>>> > > > defines the number of
>>>>>>> > > > consecutive connection events during which the slave is not
>>>>>>> required to
>>>>>>> > > > listen to the master and thus
>>>>>>> > > > can keep the radio turned off. This parameter is an integer
>>>>>>> between 0 and
>>>>>>> > > > 499 and should not cause a
>>>>>>> > > > supervision timeout. A supervision timeout happens when the
>>>>>>> time since
>>>>>>> > > the
>>>>>>> > > > last received packet
>>>>>>> > > > exceeds the connSupervisionTimeout parameter, which is in the
>>>>>>> range
>>>>>>> > > between
>>>>>>> > > > 100 ms and 32 s. The
>>>>>>> > > > purpose of this mechanism is to detect the loss of a
>>>>>>> connection due to
>>>>>>> > > > severe interference or the
>>>>>>> > > > movement of a device outside the range of its peer.
>>>>>>> > > > "
>>>>>>> > > >
>>>>>>> > > > "The frequency retention time in the frequency hopping method
>>>>>>> shall be
>>>>>>> > > 0.4
>>>>>>> > > > second or less. For
>>>>>>> > > > the radio equipment that uses the frequency hopping method
>>>>>>> excluding a
>>>>>>> > > > combination of the
>>>>>>> > > > spread spectrum method and OFDM, the total sum of the
>>>>>>> frequency retention
>>>>>>> > > > time in any frequency
>>>>>>> > > > within the time obtained by multiplying the diffusion rate by
>>>>>>> 0.4 second
>>>>>>> > > > shall be 0.4 second or
>>>>>>> > > > shorter.
>>>>>>> > > > "
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > 
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > On Wed, Aug 6, 2014 at 8:54 AM, Mike Ryan <
>>>>>>> mikeryan at lacklustre.net>
>>>>>>> > > wrote:
>>>>>>> > > >
>>>>>>> > > > > I suspect the radio hardware is capable of retuning very
>>>>>>> quickly, but
>>>>>>> > > > > the USB latency is too high for real-time channel hopping.
>>>>>>> It would be
>>>>>>> > > > > necessary to enqueue packets on the HackRF and have the ARM
>>>>>>> MCU control
>>>>>>> > > > > the timing of channel hops.
>>>>>>> > > > >
>>>>>>> > > > > I didn't mean to sound too negative. Your development is very
>>>>>>> > > > > interesting, and I definitely think it could be used as the
>>>>>>> basis of a
>>>>>>> > > > > more robust BLE device emulator.
>>>>>>> > > > >
>>>>>>> > > > > On Wed, Aug 06, 2014 at 08:50:09AM +0800, Jiao Xianjun wrote:
>>>>>>> > > > > > Exactly.
>>>>>>> > > > > >
>>>>>>> > > > > > What I do is just offering  a tool. Those example is just
>>>>>>> a simple
>>>>>>> > > > > > verification.
>>>>>>> > > > > >
>>>>>>> > > > > > I think the tool and hackrf do have the full ability,
>>>>>>> because hackrf
>>>>>>> > > can
>>>>>>> > > > > > switch from channel to channel very quickly (less than
>>>>>>> several us?
>>>>>>> > > Maybe
>>>>>>> > > > > > Ossmann can give some number?).
>>>>>>> > > > > >
>>>>>>> > > > > > You may define a packet sequence with each packet starting
>>>>>>> with
>>>>>>> > > different
>>>>>>> > > > > > channel number as you want, then hackrf will transmit a
>>>>>>> hopping
>>>>>>> > > channel
>>>>>>> > > > > > packet sequence.
>>>>>>> > > > > >
>>>>>>> > > > > >
>>>>>>> > > > > >
>>>>>>> > > > > > On Wed, Aug 6, 2014 at 12:02 AM, Mike Ryan <
>>>>>>> mikeryan at lacklustre.net>
>>>>>>> > > > > wrote:
>>>>>>> > > > > >
>>>>>>> > > > > > > Crackle will crack the pairing that is found in *any*
>>>>>>> PCAP file, it
>>>>>>> > > > > just
>>>>>>> > > > > > > so happens that Ubertooth is the best tools for
>>>>>>> producing these.
>>>>>>> > > > > > >
>>>>>>> > > > > > > The sample packets provided by Jiao Xianjun do not
>>>>>>> include a
>>>>>>> > > pairing
>>>>>>> > > > > > > sequence, just the encryption start sequence. Lacking
>>>>>>> the pairing,
>>>>>>> > > > > > > Crackle can't do anything here.
>>>>>>> > > > > > >
>>>>>>> > > > > > > Also, the sample packets are not part of a legal BLE
>>>>>>> connection.
>>>>>>> > > The
>>>>>>> > > > > > > HackRF sits on a single channel (physical channel 9) and
>>>>>>> sends them
>>>>>>> > > > > out.
>>>>>>> > > > > > > A real BLE connection hops among the data channels as it
>>>>>>> transmits,
>>>>>>> > > > > only
>>>>>>> > > > > > > sending a single packet per channel.
>>>>>>> > > > > > >
>>>>>>> > > > > > > On Tue, Aug 05, 2014 at 08:26:10AM -0400, Luke Berndt
>>>>>>> wrote:
>>>>>>> > > > > > > > Nicely done! Does anyone know if it would be possible
>>>>>>> to get
>>>>>>> > > CrackLE
>>>>>>> > > > > > > running against this? It was designed for UberTooth so I
>>>>>>> am not
>>>>>>> > > sure
>>>>>>> > > > > if it
>>>>>>> > > > > > > needs some HW.
>>>>>>> > > > > > > > https://github.com/mikeryan/crackle/
>>>>>>> > > > > > > >
>>>>>>> > > > > > > >
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > Sent from my iPhone
>>>>>>> > > > > > > >
>>>>>>> > > > > > > > > On Aug 5, 2014, at 2:15 AM, Jiao Xianjun <
>>>>>>> putaoshu at gmail.com>
>>>>>>> > > > > wrote:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > A BTLE (Bluetooth Low energy)/BT4.0 radio packet
>>>>>>> sender ( build
>>>>>>> > > > > based
>>>>>>> > > > > > > on hackrf_transfer: https://github.com/mossmann/hackrf
>>>>>>> )
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > See project here: https://github.com/JiaoXianjun/
>>>>>>>  repo BTLE
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > All link layer packet formats are supported.
>>>>>>> (Chapter 2&3,
>>>>>>> > > PartB,
>>>>>>> > > > > > > Volume 6, Core_V4.0.pdf :
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> https://www.google.fi/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCAQFjAA&url=https%3A%2F%2Fwww.bluetooth.org%2Fdocman%2Fhandlers%2Fdownloaddoc.ashx%3Fdoc_id%3D229737&ei=ui3gU4GkC-up0AW4q4GwBw&usg=AFQjCNFY1IFeFAAWwimnoaWMsIRZQvPDSw&sig2=wTgMMxNPJ52NHclpsQ4XhQ&bvm=bv.72197243,d.d2k
>>>>>>> > > > > > >  )
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > It can be used to transmit arbitrary pre-defined BTLE
>>>>>>> > > signal/packet
>>>>>>> > > > > > > sequence, such as raw bits to GFSK modulator, iBeacon
>>>>>>> packet,
>>>>>>> > > > > Connection
>>>>>>> > > > > > > establishment procedure packet in TI's website:
>>>>>>> > > > > > >
>>>>>>> http://processors.wiki.ti.com/index.php/BLE_sniffer_guide , or any
>>>>>>> > > > > other
>>>>>>> > > > > > > packets you want. Together with TI's packet sniffer, you
>>>>>>> will have
>>>>>>> > > > > full TX
>>>>>>> > > > > > > and RX abilities. See video demo 1
>>>>>>> http://youtu.be/Y8ttV5AEb-g
>>>>>>> > > > > (outside
>>>>>>> > > > > > > China) or video demo 2
>>>>>>> > > http://v.youku.com/v_show/id_XNzUxMDIzNzAw.html
>>>>>>> > > > > > > (inside China)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Build:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >     cd host
>>>>>>> > > > > > > > >     mkdir build
>>>>>>> > > > > > > > >     cd build
>>>>>>> > > > > > > > >     cmake ../
>>>>>>> > > > > > > > >     make
>>>>>>> > > > > > > > >     sudo make install  (or not install, just use
>>>>>>> btle_tx in
>>>>>>> > > > > > > hackrf-tools/src)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Usage method 1:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >     btle_tx packet1 packet2 ... packetX ...  rN
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Usage method 2:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >     btle_tx packets.txt
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > In method 2, just those command line parameters
>>>>>>> (packet1 ...
>>>>>>> > > rN) in
>>>>>>> > > > > > > method 1 are written/grouped in a .txt file as input of
>>>>>>> btle_tx
>>>>>>> > > tool.
>>>>>>> > > > > One
>>>>>>> > > > > > > parameter one line. A line start with "#" is regarded as
>>>>>>> comment.
>>>>>>> > > See
>>>>>>> > > > > > > packets.txt example in hackrf-tools/src.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > "packetX" is one string which describes one packet.
>>>>>>> All packets
>>>>>>> > > > > > > compose a packets sequence.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > "rN" means the sequence will be repeated for N
>>>>>>> times. If it is
>>>>>>> > > not
>>>>>>> > > > > > > specified, the sequence will only be sent once.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Format of packet descriptor "packetX"
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >
>>>>>>> > > > >
>>>>>>> channel_number-packet_type-field-value-field-value-...-Space-value
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Each descriptor string starts with BTLE channel
>>>>>>> number (0~39),
>>>>>>> > > then
>>>>>>> > > > > > > followed by packet_type
>>>>>>> (RAW/iBeacon/ADV_IND/ADV_DIRECT_IND/etc.
>>>>>>> > > See
>>>>>>> > > > > all
>>>>>>> > > > > > > format examples at the end), then followed by
>>>>>>> field-value pair
>>>>>>> > > which is
>>>>>>> > > > > > > packet_type specific, at last there is Space-value pair
>>>>>>> (optional)
>>>>>>> > > > > where
>>>>>>> > > > > > > the value specifies how many millisecond will be waited
>>>>>>> after this
>>>>>>> > > > > packet
>>>>>>> > > > > > > sent.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----iBeacon example: (iBeacon principle:
>>>>>>> > > > > > > http://www.warski.org/blog/2014/01/how-ibeacons-work/ )
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >     ./btle_tx
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
>>>>>>> > > > > > >     r100
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Above command sends iBeacon packet and repeats it
>>>>>>> 100 times
>>>>>>> > > with
>>>>>>> > > > > 100ms
>>>>>>> > > > > > > time space (If you have "Locate" app in your
>>>>>>> iPhone/iPad, it will
>>>>>>> > > > > detect
>>>>>>> > > > > > > the packet and show the iBeacon info.). The packet
>>>>>>> descriptor
>>>>>>> > > string:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > 37 -- channel 37 (one of BTLE Advertising channel 37
>>>>>>> 38 39)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > iBeacon -- packet format key word which means
>>>>>>> iBeacon format.
>>>>>>> > > > > > > (Actually it is ADV_IND format in Core_V4.0.pdf)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > AdvA -- Advertising address (MAC address) which is
>>>>>>> set as
>>>>>>> > > > > 010203040506
>>>>>>> > > > > > > (See Core_V4.0.pdf)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > UUID -- here we specify it as Estimote’s fixed UUID:
>>>>>>> > > > > > > B9407F30F5F8466EAFF925556B57FE6D
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Major -- major number of iBeacon format. (Here it is
>>>>>>> 0008)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Minor -- minor number of iBeacon format. (Here it is
>>>>>>> 0009)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Txpower -- transmit power parameter of iBeacon
>>>>>>> format (Here it
>>>>>>> > > is
>>>>>>> > > > > C5)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Space -- How many millisecond will be waited after
>>>>>>> this packet
>>>>>>> > > > > sent.
>>>>>>> > > > > > > (Here it is 100ms)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Connection establishment example: (See
>>>>>>> "Connection
>>>>>>> > > > > establishment"
>>>>>>> > > > > > > part of
>>>>>>> http://processors.wiki.ti.com/index.php/BLE_sniffer_guide
>>>>>>> > > )
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >     ./btle_tx
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-ADV_IND-TxAdd-0-RxAdd-0-AdvA-90D7EBB19299-AdvData-0201050702031802180418-Space-1000
>>>>>>> > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-CONNECT_REQ-TxAdd-0-RxAdd-0-InitA-001830EA965F-AdvA-90D7EBB19299-AA-60850A1B-CRCInit-A77B22-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-ChM-1FFFFFFFFF-Hop-9-SCA-5-Space-1000
>>>>>>> > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22-Space-1000
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Above simualtes a Connection establishment procedure
>>>>>>> between
>>>>>>> > > > > device 1
>>>>>>> > > > > > > and device 2.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > The 1st packet -- device 1 sends ADV_IND packet in
>>>>>>> channel 37.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > The 2nd packet -- After device 2 (in scanning state)
>>>>>>> receives
>>>>>>> > > the
>>>>>>> > > > > ADV
>>>>>>> > > > > > > packet from device 1, device 2 sends CONNECT_REQ packet
>>>>>>> to request
>>>>>>> > > > > > > connection setup with device 1. In this request packet,
>>>>>>> there are
>>>>>>> > > > > device 2
>>>>>>> > > > > > > MAC address (InitA), target MAC address (device 1 MAC
>>>>>>> address
>>>>>>> > > AdvA),
>>>>>>> > > > > Access
>>>>>>> > > > > > > address (AA) which will be used by device 1 in following
>>>>>>> packet
>>>>>>> > > > > sending in
>>>>>>> > > > > > > data channel, CRC initilization value for following
>>>>>>> device 1
>>>>>>> > > sending
>>>>>>> > > > > > > packet, Hopping channel information (ChM and Hop) for
>>>>>>> data channel
>>>>>>> > > > > used by
>>>>>>> > > > > > > device 1, etc.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > The 3rd packet -- device 1 send an empty Link layer
>>>>>>> data PDU in
>>>>>>> > > > > > > channel 9 (decided by hopping scheme) according to those
>>>>>>> connection
>>>>>>> > > > > request
>>>>>>> > > > > > > information received from device 2. (One "X" after field
>>>>>>> "DATA"
>>>>>>> > > means
>>>>>>> > > > > there
>>>>>>> > > > > > > is no data for this field )
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > Time space between packets are 1s (1000ms). Tune
>>>>>>> TI's packet
>>>>>>> > > > > sniffer
>>>>>>> > > > > > > to channel 37, then above establishment procedure will
>>>>>>> be captured.
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ----Packet descriptor examples for all formats:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > RAW packets: (All bits will be sent to GFSK
>>>>>>> modulator directly)
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 13-RAW-AAD6BE898E5F134B5D86F2999CC3D7DF5EDF15DEE39AA2E5D0728EB68B0E449B07C547B80EAA8DD257A0E5EACB0B
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > ADVERTISING CHANNEL packets:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-IBEACON-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-ADV_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > >
>>>>>>> 37-ADV_DIRECT_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-InitA-0708090A0B0C
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-ADV_NONCONN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-ADV_SCAN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
>>>>>>> > > > > > > > >
>>>>>>> > > > >
>>>>>>> 37-SCAN_REQ-TxAdd-1-RxAdd-0-ScanA-010203040506-AdvA-0708090A0B0C
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-SCAN_RSP-TxAdd-1-RxAdd-0-AdvA-010203040506-ScanRspData-00112233445566778899AABBCCDDEEFF
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 37-CONNECT_REQ-TxAdd-1-RxAdd-0-InitA-010203040506-AdvA-0708090A0B0C-AA-01020304-CRCInit-050607-WinSize-08-WinOffset-090A-Interval-0B0C-Latency-0D0E-Timeout-0F00-ChM-0102030405-Hop-3-SCA-4
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > DATA CHANNEL packets:
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > >
>>>>>>> > > > >
>>>>>>> 9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_CONNECTION_UPDATE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-Instant-0000-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_CHANNEL_MAP_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ChM-1FFFFFFFFF-Instant-0001-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_TERMINATE_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-Rand-0102030405060708-EDIV-090A-SKDm-0102030405060708-IVm-090A0B0C-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-SKDs-0102030405060708-IVs-01020304-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > >
>>>>>>> 9-LL_START_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > >
>>>>>>> 9-LL_START_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_UNKNOWN_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-UnknownType-01-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_FEATURE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_FEATURE_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > >
>>>>>>> 9-LL_PAUSE_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > >
>>>>>>> 9-LL_PAUSE_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_VERSION_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-VersNr-01-CompId-0203-SubVersNr-0405-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> 9-LL_REJECT_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
>>>>>>> > > > > > > > >
>>>>>>> > > > > > > > > _______________________________________________
>>>>>>> > > > > > > > > HackRF-dev mailing list
>>>>>>> > > > > > > > > HackRF-dev at greatscottgadgets.com
>>>>>>> > > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
>>>>>>> > > > > > >
>>>>>>> > > > > > > > _______________________________________________
>>>>>>> > > > > > > > HackRF-dev mailing list
>>>>>>> > > > > > > > HackRF-dev at greatscottgadgets.com
>>>>>>> > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
>>>>>>> > > > > > >
>>>>>>> > > > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>>
>>>>>>> > _______________________________________________
>>>>>>> > HackRF-dev mailing list
>>>>>>> > HackRF-dev at greatscottgadgets.com
>>>>>>> > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> HackRF-dev mailing list
>>>>> HackRF-dev at greatscottgadgets.com
>>>>>
>>>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20151109/f38f4eaf/attachment.html>