Bluetooth Communication

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Ich hab mir jetzt den Bluetooth Teil der Widefield Software näher angeschaut, und einige Probleme und Sicherheitslücken gefunden:

Beim Empfangen von Bluetooth Control Packages wird nicht kontrolliert, wieviele Bytes empfangen wurden,
dadurch ist das ein logischer Buffer-Overflow. (Physisch ist es ein fixer mit 0 befüllter Puffer, also nicht ganz so schlimm)
Die Checksummen sind nur simple ungesalzene XORs die nicht kryptographisch abgesichert sind.
Wenn der ganze Puffer nur mit 0 gefüllt ist, ist die Checksumme gültig.
Das verwendete Bluetooth Protokoll hat keinerlei Start-Bytes, Stop-Bytes oder sonstige identifizierbare Header,
und wird über serielle Leitungen Byte für Byte übertragen. Daher ist eine korrekte Identifizierung wann ein Kontroll- oder Datenpaket anfängt
und wann es aufhört nur durch große FIFOs (die meisten FIFOs die ich kenne haben nur 14 oder 16 Bytes, dieses Protokoll hat 19 Bytes)
und genügend lange Zeitabstände zwischen den Paketen (die schlecht für die Latenz sind) erreicht werden.
Im Falle einer falschen Start/Stop Erkennung der Pakete wirft die Widefield Software einen Checksummen oder Kommunikationsfehler,
der dann in der Steuerungs-software die Motoren ausschaltet! Sollte es nur ein kaputtes Paket gewesen sind, werden die Motoren dann beim nächsten erfolgreichen Paket
vielleicht gleich wieder eingeschaltet.
Aus meiner Sicht sollten einzelne kaputte Pakete ignoriert werden und die Motoren erst beim Timeout abgedreht werden.

Rafael meinte, daß schon jemand an der Bluetooth Kommunikation arbeitet.
Ich würde mich auf Pull-Requests für https://github.com/thesourcerer8/Flying-PCB freuen.
0 Likes
7 Replies
Not applicable
Der Header ist nicht ausreichend, weil da jedes beliebige Byte darin vorkommen kann (entweder 0 oder eine andere Zahl => jede beliebige Zahl), und jedes andere Datenbyte auch als Header interpretiert werden kann.
Nehmen wir an die ersten paar Bytes werden nicht empfangen, weil die CPU gerade noch am starten war, dann wird mitten im Paket zu lesen begonnen, und dann vielleicht noch ein paar Bytes aus dem nächsten Paket, und das dann als Paket genommen.
Header brauchen eine eindeutige Signatur, mit denen sie klar von normalen Daten in den Paketen unterschieden werden können, und Header sollten auch in den Daten nicht wieder vorkommen können.
Dazu kann man zum Beispiel Startbytes verwenden (0x02) und am Schluß dann ein Endbyte (0x03) wenn die Daten nur Text sind und keine Sonderzeichen enthalten.
Oder wenn man binäre Daten transportieren muß kann man mehrere Bytes mit einer selten vorkommenden Kombination (0xaa 0x55 0xB3 0x3B) nehmen, bei denen das Risiko dann 1:4 Milliarden ist, daß das der Header-Identifier dann auch in den Daten mal vorkommt.

Die Integritätssicherung von Bluetooth besteht nur zwischen dem Bluetooth Sender und dem Bluetooth Empfänger, die UART Leitungen zwischen Bluetooth Empfänger und CPU sind nicht damit geschützt, und es hängt daher auch stark von der Qualität der verwendeten Kabel ab, dort können dann auch Bits kippen.
Daher finde ich ein Checksumme in den Daten trotzdem eine sehr gute Idee, und würde ich nur wegen Bluetooth nicht weglassen, solange es sich Performance-mässig ausgeht.

Ein weiteres Problem auf das ich vor kurzem erst gestossen bin ist daß die Flying PCB Software wenn sie mit zuvielen Daten per Bluetooth oder USB gefüttert wird aufhört die Motorregelung zu machen, und nurmehr mit dem Lesen und Verarbeiten der Kommunikation beschäftigt ist.
Die Software würde dann nicht mehr reagieren und während dem Flug dann wahrscheinlich vom Himmel fallen. Aus meiner Sicht hat ein Flight-Controller harte Echtzeitanforderungen, und muß in jedem Fall weiterrechnen und reagieren, die Kommunikation darf da nicht stören, und verletzt die Echtzeitanforderungen.
Darauf gekommen bin ich, weil ich bei meinem Simulator der Steuersoftware jedesmal ein einzelnes Byte in den virtuellen FIFO gestellt habe, und den FIFO nicht mehr leer werden habe lassen.
Aus meiner Sicht sollte sich das lösen lassen, indem die Software maximal z.B. 100 Bytes (oder 190 um ein vielfaches von 19 zu haben) liest, den Rest dann im FIFO belässt ignoriert und dann auf jeden Fall weitermacht mit der Motor-Regelung, und erst beim nächsten Zyklus dann versucht wieder weiter einliest.

Hat schon jemand Echtzeit-Tests gemacht, bzw. vielleicht auch andere Zeit-Analysen, welche Teile der Software wieviel Zeit in Anspruch nehmen, Profiling, ...?
0 Likes
Not applicable
this is great, BUT
pin security is a joke in Bluetooth world.
Is there anything dangerous exposed over this link? can you break engine by just programming megasquirt wrong way?
0 Likes
Not applicable
I cant understand that how it is possible with pin scurity. yes its joke in bluetooth world
0 Likes
Not applicable
GiffordHladek wrote:
I cant understand that how it is possible with pin scurity. yes its joke in bluetooth world


how can you say this is joke? anything is possible..
0 Likes
Not applicable
Cabeceira wrote:
how can you say this is joke? anything is possible..

No its not possible yet. there is no tech. yet
0 Likes
Not applicable
James Howard wrote:
this is great, BUT
pin security is a joke in Bluetooth world.
Is there anything dangerous exposed over this link? can you break engine by just programming megasquirt wrong way?

what do you mean by " break engine by just programming megasquirt wrong way"
0 Likes
Not applicable
Beth641 wrote:
what do you mean by " break engine by just programming megasquirt wrong way"


The question meant whether it is possible to break the quadcopter by breaking into the bluetooth communication and sending commands or data into the quadcopter which could crash it.

The answer is that it depends on the application of the bluetooth communication, what the copter firmware does with the data it receives over Bluetooth.

The downstream (copter->bluetooth) is unproblematic, since there is not DTS/RTS signalling which could block the copter in any way. (The bluetooth module is only connected with GND+VCC+RX+TX pins)
0 Likes