Can't establish connection after advertise.js shows INITIALIZED

Question

Can't establish connection after advertise.js shows INITIALIZED

TheClownDE opened this issue 8 years ago · 1 comments

Hi,
I'm having problems using GATTacker.
Starting the ws-slave works, as well as scanning, but the advertise.js causes some problems.
It connects to the victim-device and shows INITIALIZED and the clones device shows up (on my phone).
But when I want to connect it wont work (console shows "client connected" and "client disconnected" at the same time).
I'm using Linux Mint 17.2 with 4.4.0 kernel and BlueZ 5.41.

ws-slave log:

GATTacker ws-slave
ws -> connection
ws -> send: {"type":"stateChange","state":"poweredOn"}
ws -> message: {"action":"macAddress"}
ws -> send: {"type":"macAddress","macAddress":"01:23:45:67:89:ab"}
ws -> message: {"action":"initialize","peripheralId":"001a7dda7110","servicesJsonData":[{"uuid":"1800","name":"Generic Access","type":"org.bluetooth.service.generic_access","startHandle":1,"endHandle":5,"characteristics":[{"uuid":"2a00","name":"Device Name","properties":["read"],"value":"42616420454e495341204c6f636b","descriptors":[],"startHandle":2,"valueHandle":3,"asciiValue":"Bad ENISA Lock"},{"uuid":"2a01","name":"Appearance","properties":["read"],"value":"8000","descriptors":[],"startHandle":4,"valueHandle":5,"asciiValue":"  "}]},{"uuid":"1801","name":"Generic Attribute","type":"org.bluetooth.service.generic_attribute","startHandle":6,"endHandle":9,"characteristics":[{"uuid":"2a05","name":"Service Changed","properties":["indicate"],"value":"","descriptors":[{"handle":9,"uuid":"2902","value":""}],"startHandle":7,"valueHandle":8}]},{"uuid":"e015","name":null,"type":null,"startHandle":10,"endHandle":16,"characteristics":[{"uuid":"e016","name":null,"properties":["read","write","notify"],"value":"4c6f636b206973206e6f7720436c6f736564","descriptors":[{"handle":13,"uuid":"2902","value":""},{"handle":14,"uuid":"e026","value":""}],"startHandle":11,"valueHandle":12,"asciiValue":"Lock is now Closed"},{"uuid":"e017","name":null,"properties":["write"],"value":"","descriptors":[],"startHandle":15,"valueHandle":16}]}],"keepConnected":true}
ws -> send: {"type":"initializeStatus","peripheralId":"001a7dda7110","status":"JSON services received"}
ws -> send: {"type":"initializeStatus","peripheralId":"001a7dda7110","status":"start scanning for target peripheral"}
ws -> message: {"action":"macAddress"}
ws -> send: {"type":"macAddress","macAddress":"01:23:45:67:89:ab"}
ws -> send: {"type":"startScanning"}
ws -> send: {"type":"discover","peripheralId":"a0edcdedd8fd","address":"a0:ed:cd:ed:d8:fd","addressType":"public","connectable":true,"advertisement":{"serviceUuids":[],"manufacturerData":"4c0009060301c0a802dd","serviceData":"","eir":"02011a0bff4c0009060301c0a802dd","scanResponse":""},"rssi":-54}
ws -> send: {"type":"discover","peripheralId":"80e650ea4699","address":"80:e6:50:ea:46:99","addressType":"public","connectable":true,"advertisement":{"serviceUuids":[],"manufacturerData":"4c0009060301c0a802fa","serviceData":"","eir":"02011a0bff4c0009060301c0a802fa","scanResponse":""},"rssi":-78}
ws -> send: {"type":"discover","peripheralId":"a0edcde70487","address":"a0:ed:cd:e7:04:87","addressType":"public","connectable":true,"advertisement":{"serviceUuids":[],"manufacturerData":"4c0009060301c0a802b7","serviceData":"","eir":"02011a0bff4c0009060301c0a802b7","scanResponse":""},"rssi":-58}
ws -> send: {"type":"discover","peripheralId":"c80f10276814","address":"c8:0f:10:27:68:14","addressType":"public","connectable":true,"advertisement":{"localName":"MI1S","serviceUuids":["fee0","fee7"],"manufacturerData":"57010055d8807af55e8e433301eada7cf4d5de01c80f10276814","serviceData":"[object Object]","eir":"0201061bff57010055d8807af55e8e433301eada7cf4d5de01c80f10276814","scanResponse":"05094d4931530502e0fee7fe0716e0fe00000000"},"rssi":-72}
ws -> send: {"type":"initializeStatus","peripheralId":"001a7dda7110","status":"target peripheral discovered, trying to connect..."}
ws -> send: {"type":"discover","peripheralId":"001a7dda7110","address":"00:1a:7d:da:71:10","addressType":"public","connectable":true,"advertisement":{"localName":"Bad ENISA Lock","serviceUuids":["e015"],"manufacturerData":null,"serviceData":"","eir":"020106030315e0","scanResponse":"0f0842616420454e495341204c6f636b"},"rssi":-27}
ws -> send: {"type":"stopScanning"}
ws -> send: {"type":"initialized","peripheralId":"001a7dda7110"}
ws -> send: {"type":"connect","peripheralId":"001a7dda7110"}
ws -> send: {"type":"startScanning"}
ws -> message: {"action":"clientConnection","clientAddress":"2c:8a:72:61:91:98","state":true}
client connected : 2c:8a:72:61:91:98
ws -> message: {"action":"clientConnection","clientAddress":"2c:8a:72:61:91:98","state":false}
client disconnected : 2c:8a:72:61:91:98

advertise log:

Ws-slave address: 127.0.0.1
peripheralid: 001a7dda7110
advertisement file: devices/001a7dda7110_Bad-ENISA-Lock.adv.json
EIR: 020106030315e0
scanResponse: 0f0842616420454e495341204c6f636b
on open
poweredOn
Noble MAC address : 01:23:45:67:89:ab
BLENO - on -> stateChange: poweredOn
initialized !
Static - start advertising
      target device connected
on -> advertisingStart: success
setServices: success
 <<<<<<<<<<<<<<<< INITIALIZED >>>>>>>>>>>>>>>>>>>> 
Client connected: 2c:8a:72:61:91:98
Client disconnected: 2c:8a:72:61:91:98

hcidump (on the peripheral/bleno device):

HCI sniffer - Bluetooth packet analyzer ver 5.41
device: hci1 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x00 handle 69, role slave
      bdaddr 2C:8A:72:61:91:98 (Public)
< ACL data: handle 69 flags 0x00 dlen 16
    L2CAP(d): cid 0x0005 len 12 [psm 0]
> ACL data: handle 69 flags 0x02 dlen 11
    ATT: Read By Group req (0x10)
      start 0x0001, end 0xffff
      type-uuid 0x2800
> ACL data: handle 69 flags 0x02 dlen 10
    L2CAP(d): cid 0x0005 len 6 [psm 0]
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 69 packets 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 69 reason 0x13
    Reason: Remote User Terminated Connection
< HCI Command: Read RSSI (0x05|0x0005) plen 2
    handle 69
> HCI Event: Command Complete (0x0e) plen 7
    Read RSSI (0x05|0x0005) ncmd 1
    status 0x02 handle 69 rssi 0
    Error: Unknown Connection Identifier
< ACL data: handle 69 flags 0x00 dlen 24
    ATT: Read By Group resp (0x11)
      attr handle 0x0001, end group handle 0x0005
      value 0x00 0x18
      attr handle 0x0006, end group handle 0x0009
      value 0x01 0x18
      attr handle 0x000a, end group handle 0x0010
      value 0x15 0xe0
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Advertise Enable (0x08|0x000a) ncmd 1
    status 0x00

Thanks for any help!
TheClown

Answer 1 · 2016-09-08T19:13:57.000Z

Hi,
it looks like the mobile app connects to bleno and disconnects at once, and does not even wait for services discovery to finish. Similar situation may happen because of mobile OS GATT cache. In order to speed-up things Android/iOS store services map of a given device (based on its MAC address), sometimes even for quite a few reboots. If you have previously advertised a different services using the same bleno MAC address, and connected to it with the same phone, this may be the issue as GATT cache may not match.

Some ideas:

If you have enough hardware, try connecting to the bleno simulated using a different device. E.g. yet another Linux with Bluez (hcitool, gatttool...). Or another phone with nRF or other BLE scanning app. If that works, it means the problem is not with bleno setup but your client app.
Try changing MAC address of bleno.
Does your attack scenario require cloning of original device MAC?
If not, you can change the adapter's MAC. That should solve a problem if it the GATT cache is a culprit.
If you need to stay with the MAC - you can try rebooting your phone to reset the cache. If you have root-ed Android phone the cache is stored in /data/misc/bluedroid.
Next - it would be helpful to see what is actually happening on the mobile phone, as from the above logs I suspect the phone is the one that disconnects.
Does the problem happen while using the specific target mobile application, or just a generic BLE scanner? The Android system hcidump would be helpful too. You can grab it in Settings->Developer options->Enable Bluetooth HCI snoop log. It saves the log in /sdcard/btsnoop_hci.log. Turn it on and off for new file. It is just a pcap format, you can inspect it in Wireshark, or use https://github.com/nccgroup/BLE-Replay.
If you are able to e.g. connect using generic BLE scanner but not your mobile app compari the hci logs may clear up something.
Mobile app debug logs.
If we're talking about a specific mobile app, you can also try to grab mobile app logs. It often logs by default (try adb logcat, android monitor from sdk). But if not - just switch it to debug in Manifest and repack using apktool.
An example Android app log snippet with mismatched GATT cache:

E/XXX (15944): (SourceFile:31)@Binder_1 | 'Discovery failed: No XXX Service found

Hope that helps, if not - send more info + logs :)