NUSPTF-RFC-02: The Bluetooth Profile (Detailed)
|New Unified Systems Protocol Task Force | Reporting Facultative Commission (RFC-02) |
|SUBMMITER: The Prosecutor for Critical Infrastructure and Telecommunications.|
|Revision Author: Raymond Newman, Reporting for the NUSPTF (New Unified Systems Protocol Task Force)|
| Reasoning: Investigation into the “Broadband storm” phenomenon, providing background.|
Bluetooth is a remote, bandwidth technology, whose default features are seemingly limited in its ordinaryintended implementation.
By design of the protocol [See “Profile”], it allows access to the entire OSI framework as part of its basic features. This is required as to allow for its intended use of supporting seamless connectivity.
It is capable of transfersing the four [see “High and Low Bluetooth”] application designs gained throughout its development.
Furthermore, by handcrafted hardware expansions, coupled with exploiting unregulated or outdated software data transmissions, it is highly modular, for its non-intended use-cases.
First we will demonstrate the list of exploits [see List of Exploits] and how they relate to the functionality Bluetooth offers. We will proceed by showcasing “High” and “Low” Power modes of the Stack, or its development phase. Finally, we will use the UML or visuals [see “Profile once again”] for better approachability.
List of exploits
Seamless connectivity allows for its use-cases by the various features it depends on. We will now present a list. It is recommended to read them chronologically, as the end might seem senseless. Like always, if you do not know what some of these terms mean, you may always search them. We have provided a minimal explanation needed for this context.
- Audio transmission
- It necessities ISM radio bandwidth of 2.4-2.48 GHz, or that of residential WiFi.
- Adaptive differential pulse-code modulation, specifically of the G.711, G.726, G.77 standard codec. These are 64 kbits/s, 16 kbits/s, and 56 kbits/s encoding-decoding. Remember those numbers.
- Wireless device control communication
- Such as the control of mouse, keyboard, printers and other. These make Bluetooth have necessary access to USB port connectivity.
- Real-time location and discovery
- It is not required of the controlled device to be enabled for discovery to happen, as had been demonstrated on the Stream social website by an anonymous user.
- Serial communications and RS-232 Emulation
- Serial communication is used in GPS, medical equipment, bar code scanning, and control of traffic through flow of light signals.
- For all of these functionalities, remember that RS-232 is emulated, and that Bluetooth devices or the controller must have simple serial addressing, which will be covered later.
- Expansion of its Personal Area Network or Piconet into a clustered WAN or WPA
- Piconet relies on what is called a "Special frame" authorisation in a master-slave cycle. It can quickly transmit small bits of data only to 7 nodes from the controller. These 7 nodes do not receive the necessary frame all at the same time. Rather, each passes the special frame token. The special frame or token is what transmits data. The slaves are all in an area like a circle. If one node does not pass the token, the entire connection drops.
- Scatternets occur when the master controller is simultaneously also a slave node of another master node. The circles can exist interconnected to each other through this node. This is also called "Bluetooth clustering", which brings us to another exploit.
- File transfer which can be high, low, or cross-changed bandwidth
- Consequently, it has unauthorised access to FTP and can transmit byte data (recall the codecs) through OBEX
- Access to cellular telephony
- Which also allows for: Dial-up internet emulation, VoIP hypervisor simulation, teletext on CRT televisions, and TTY terminals.
- Wireless data streaming and networking for computer devices
- Combine this with all of the above mentioned and let's move forward
- Remote display and access to screens, monitors, and terminals displays.
- An intuitive example is in game consoles. However, it goes further than that, as we have seen.
- Bridging two synchronous Ethernet cables
- Must be able of penetrating both the hardware cable access and software privilege protections.
High and Low Bluetooth
A wireless bridging of two ethernet networks is extensively used in “PROFINET”. Recalling Audio transmission of 64, 16 and 56 bits, coupled with FTP, Scatternets, Remote control and display, Data streaming, Telephony, Serial communication, and real-time connectivity — Packets can be sent to any link, which are limited in size.
These packets arrive in low profile or band, with LC3 Codec. However, while high band Bluetooth supports LC3 Codec implementation as intended; low band Bluetooth uses CRC encryption.
|Specification|High|Low|
|-----------------------|
|Ramge|100m+|-100m|
|--------------------------------|
|Data rate|1-3 Mbits/s|Up to 1 Mbits/s|
|--------------------------------|
|Throughput|0.7-21 Mbits/s|0.3-1.4 Mbits/s|
|--------------------------------|
|Active slaves|7|Unregulated|
|--------------------------------|
|Security|56-bit modifiable through the Application layer|128-bit AES modifiable through the Application layer|
|--------------------------------|
|Control Access|Adaptive hopping, FEC, then ACK|Adaptive hopping, 24-bit CRC, 32-bit or header check|
|--------------------------------|
|Network topology|Scatternet to Cellular|Scatternet to Ethernet|
|----------------------------------------------------------------------|
Those packets arrive in low profile with CRC encryption. Serialisation of a Bluetooth controller is shorter than any other connectivity UID profile. Furthermore, it can merely be a mask if used in PPP transfers of data. This may further be obfuscated if the PPP inbound is connected through a switch, thus disallowing traceability.
The Profile, Stack, or Protocol Visuals
We will first cover some basic things such as Byte Frame formats, specifically focusing on PPP then Ethernet and Wireless; Finally showcasing how the Bluetooth Profile design looks. If We do not address these by order, it will not be comprehensive, why the Bluetooth Profile or Stack or Protocol design is VERY insecure.
Bit vs Byte oriented framing:
In bit oriented framing, data is a sequence of bits, transferred to upper OSI layers. There exist two implementations of access control. HDLC and SDLC. We are interested in the HDLC here.
In byte oriented framing, data is a sequence of bytes ( ! sequenced bits). There exist numerous access control implementations. We are interested in BISYNC also called BSC, and PPP.
HDLC Frame Format:
|BEGIN|Header|Body-Network layer|CRC|END|
|---------------------------------------|
|8 bits|16 bits|UNKNOWN|16 bits|8 bits|
|01111110|Address Control Dependent|UNKNOWN|Error Detection|01111110|
Address Control Dependent determines the type of frame. I-Frames of 0, S-Frames of 10, or U-Frames of 11 bits.
BISYNC Frame Format:
|SYN|SYN|SOH|Header-Network|STX|Body-Network|ETX|CRC| |---------------------------------------------------| |8 bits|8 bits|8 bits|UNKNOWN|8 bits|UNKNOWN|8 bits|16 bits|
To be clear, “STX” stands for “Start of Text”; while "ETC stands for “End of Text”. This means that the body, which is in the network (upper) layer, is in plain text. Likewise, “SOH” is “START OF HEADER”.
This is a very insecure frame format and its main vulnerability is how prone it is to DLE, which refers to exactly what it says when hovered over it. It escapes the Data Link Layer.
PPP (WAN/LAN, Broadband, P2P)
|Flag|Address|Control|Protocol|Payload-Network|Checksum|Flag|
|---------------------------------------------|
|8 bits|8 bits|8 bits|16 bits|UNKNOWN|16 bits|8 bits|
|01111110|11111111|11000000|1 or 2 bytes|UNKNOWN|HIDDEN|01111110|
|---------------------------------------------------------------|
Address (11111111)
: It is the broadcast address.
CONTROL (11000000)
: IT IS ALWAYS this.
Protocol:
: It can be 1 or 2 bytes. This defines the type of data, WITHIN THE PAYLOAD.
Ethernet and Wi-FI Frames:
We will refer to “bits” as “bits” and to “bytes” as “B” from hereon.
LEN and PAD
: LEN is the length of the frame payload. It is of 2B in size. It serves to tell the PAD how much data is being received. Minimum is 512bits which is 64B. Maximum frame length is 12 144 bits which is 1518B.
: PAD then adjusts accordingly. The reason why is, when you receive an internet connection, your own device likely cannot receive as much data as the ISP is sending. For this reason, the Minimum is 46B, while the maximum is 1500B.
If you are counting and paying attention to this RFC as you should, you will notice consistency of what we mentioned in exploits.
|Desination Address|Source Adress|LEN|PAD|CRC|
|--------------------------------------------|
|6B|6B|2B|46-1500B|CRC|
|----------------------------------------------|
An “Ethernet Address” has the BOM of the most significant byte being the first. For instance;
06:01:02:01:2C:4B <=> 6B <=> 12HEX <=> 48bits.
WI-FI:
As observable in the above image, Wi-Fi’s frame format has its most significant byte as “Frame Control”. This allows for exploits.
|Frame Control|Duration|Add1|Add2|Add3|SEQ|Add4|Data|Checksum|
|------------------------------------------------------------|
|-----------------------------------------------------------|
|2B|2B|6B|6B|6B|2B|6B|23x2 standard|4B|
|------------------------------------------------------------|
Bluetooth Protocol Stack:
|-------------------------| {(->down
|-|--Application Layer--|-| )"Application Layers"}
|A|---------------------|C| -
|U|LLC|RFCOMM|TELE|SerDi|O| {()"Middleware"}
|D|******Logical********|N| -
|I|******Link***********|T| {(->down
|O|******Layer**********|R| (->down
|-----------------------|O| )->down
|********BASEBAND*******|L| )->down
|-------------------------| ->"Data Link Layer"}
|*******Physical (RADIO)**| {())"Physical Layer"}