virtualabs / btlejack

Bluetooth Low Energy Swiss-army knife
MIT License
1.87k stars 196 forks source link

Sending Link Layer PDUs to the server when hijacked #57

Closed JuliaChelysheva closed 1 year ago

JuliaChelysheva commented 4 years ago

Hello all,

I am using btlejack to inspect the security in Bluetooth Low Energy and it helped me a lot so far. I am working with two RaspberryPis which are connected via BLE as a client and a server (using BlueZ protocol stack), and the third RaspberryPi with three Microbits is my btlejack-device.

Now I would like to send the Link Layer PDUs to the server when the connection was hijacked. The connection was not encrypted and I can discover all the services and characteristics and write new values to it. (When the connection is encrypted and was hijacked, I can not interact with the server because I am getting the MIC Authentication Error and the btlejack device disconnects immediately -"Error: CONNECTION TERMINATED DUE TO MIC FAILURE", but I think it is normal because the connection was encrypted and we cannot guess the MIC so easily).

In the description https://github.com/virtualabs/btlejack#ll-command it says that the Core Specification is needed as reference in case we want to use this command. I was trying to create some Link Layer PDU (LL Data PDU, LL Control PDU) as described in Vol.6 Part B Section 2.4. and 2.4.1. in hex format, and it did not work yet. Sometimes I see the output of btmon on my BLE-server which is saying that some received packet has an unexpected continuation error, and I think that there is a problem in a payload. Or I don't see any output at all. Do we need to put the header of the packet with LLID, NESN, SN, MD, RFU and Length as well? I tried to send it only with Payload (Opcode + CtrData), since I don't know most of the Header parameters.

Maybe someone could provide some practical example how we could send a simple link layer PDU? I would really appreciate it!

Thank you

virtualabs commented 3 years ago

Hello,

When sending LL PDUs, btlejack fixes the NESN and SN bits before sending the packets so no worry (just set them to 0). But yes, you need to provide the complete Data Channel PDU with its 2-byte header (you must set LLID,MD and length) and the payload (data pdu or control pdu). This is not user friendly, this feature was a proof of concept and I usually use a set of already prepared PDUS when testing a device.