infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 10 of 10

Thread: Bluetooth Communication

  1. #1
    Beginner Beginner PhilippGuehring is on a distinguished road
    Join Date
    May 2016
    Posts
    16
    Points
    78.75

    Bluetooth Communication

    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.

  2. #2
    Beginner Beginner
    Infineon Employee
    Infineon Employee
    SteurerE is on a distinguished road
    Join Date
    Jul 2016
    Posts
    2
    Points
    50

    Bluetooth Communication

    Hallo,

    in der Widefield-Software befindet sich nicht die aktuelle Version des Bluetooth-Protokolls, die Core-Larix Version beinhaltet die aktuelle Implementierung.
    (https://github.com/thesourcerer8/Fly...Larix_V1.0.zip)

    Das Protokoll beinhaltet einen Header und zwar ist dies das erste empfangene Byte. Es teilt der Empfangsseite mit ob es sich um ein Control oder Data-Packet handelt. Hat das
    Byte den Wert 0x00 ist es ein Control-Packet(19bytes) mit folgendem Aufbau:

    |header(1byte)|heightcontrol(1byte)|speed(1byte)|y aw(4bytes)|pitch(4bytes)|roll(4bytes)|checksum(4by tes)|

    Im Prinzip sind dies die zur Steuerung nötigen Daten. HeightControl aktiviert die in Zukunft geplante Höhenregelung, wenn der Wert 0xFF beträgt. 4 bytes sind jeweils
    roll, pitch, yaw (float=4bytes). Der Rest müsste selbsterklärend sein.

    Hat das Byte einen Wert > 0x00 dann ist es eine Data-Packet mit der entsprechenden Anzahl an Bytes. Gedacht ist das Data-Packet als
    Möglichkeit Custom-Messages zu implementieren.(Einstellungen über die Android Applikation vorzunehmen, etc.). Übersteigt der Wert im Header-Byte
    die Anzahl, der pro Packet(19byte-5byte) sendbaren Bytes, so werden automatisch mehrere Packete gesendet bis die gesamte Message angekommen ist.

    Zur Checksumme: Sie ist eigentlich nicht unbedingt notwendig, da das SPP-Protokoll auf unterer Ebene meines Wissens nach selbstständig Checksummen rechnet
    und Fehler erkennt. Ich denke es ist eine gute Idee, die XOR-Checksumme im Laufe weiterer Entwicklung ganz einzusparen, da es doch ausschlaggebend für die
    Größe des Protokols ist. Das verwendete Bluetooth-To-Uart-Modul unterstützt auch verschlüsselte Verbindungen zum Smartphone, daher könnte man das Modul auch entsprechend konfigurieren,
    wenn man um Sicherheit besorgt ist.

    Zum vermeintlichen Buffer-Overflow: Dieser ist nicht möglich, da der hardwareseitige FIFO-Buffer genau bei 19 empfangenen Bytes triggert und diese Bytes werden
    anschließend in einen ausreichend großen Buffer geschrieben.

    Zum Ausschalten der Motoren bei Fehlern: Hier müsste man noch eine Routine zum sicheren Landen hinzufügen, die jetzige Lösung ist sicher nicht ideal.

    Ich hoffe ich konnte einige Unklarheiten beseitigen.

    Beste Grüße,

    Steurer Elias
    Last edited by SteurerE; Jul 7th, 2016 at 12:23 AM.
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  3. #3
    Beginner Beginner PhilippGuehring is on a distinguished road
    Join Date
    May 2016
    Posts
    16
    Points
    78.75
    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, ...?

  4. #4
    Beginner Beginner
    Infineon Employee
    Infineon Employee
    SteurerE is on a distinguished road
    Join Date
    Jul 2016
    Posts
    2
    Points
    50

    Bluetooth Communication

    Der Header in Kombination mit der am Ende angehängten Checksumme ergibt eigentlich ein in sich abgeschlossenes Packet. Die Wahrscheinlichkeit für das
    falsch Interpretieren des ersten Bytes aber einer zufällig richtigen Checksumme am Ende ist wohl auch nicht hoch. Das Packet wird ja nur angenommen, wenn die
    Checksummen übereinstimmen. Wie schon im vorigen Post erwähnt ist es noch notwendig einen sicheren Landemechanismus im Falle einer Störung(Overflow an Daten, Verbindungsverlust, etc.) zu implementieren.
    Dass die Motorregelung beim Senden von zu vielen Daten aufhört kann ich mir nicht vorstellen, da die NVI-Priorität des Timers für die Lageregelung höher ist. Die Motoren werden deswegen abgedreht, weil es dann zu Checksummenfehler kommt. Diese Fehler müsste man abfangen und die sichere Landung einleiten.

    Generell gilt die gesamte Software als Basis für eigene Entwicklung. Fühl dich also frei dein eigenes Protokoll zu implementieren. Die Software der Sendeseite(Android-Applikation)
    geht auch bald auf GitHub online. Somit ist es dann möglich Neues auszuprobieren und weiterzuentwickeln. Ich würde dir aber empfehlen weitere Tests direkt
    mit der Zielhardware zu machen. Es ist sicher schwer möglich von einer Computersimulation auf alle möglichen Fehler zu schließen. Ein guter Punkt zum Starten wäre das Importieren einer
    RTOS-Umgebung für das FlyingPCB. Somit könnte mit prioritätengesteuertem Scheduling sauber und sicher gearbeitet
    werden.

    P.S: Profiling und Zeitmessung wurden nicht durchgeführt, da es in erster Linie darum ging einen flugfähigen Demonstrator zu bauen und keine Performance-Analyse dafür notwendig war.

    Grüße,

    Elias
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  5. #5
    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?

  6. #6
    I cant understand that how it is possible with pin scurity. yes its joke in bluetooth world

  7. #7
    Quote Originally Posted by GiffordHladek View Post
    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..

  8. #8
    Quote Originally Posted by Cabeceira View Post
    how can you say this is joke? anything is possible..
    No its not possible yet. there is no tech. yet

  9. #9
    Quote Originally Posted by James Howard View Post
    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"

  10. #10
    Beginner Beginner PhilippGuehring is on a distinguished road
    Join Date
    May 2016
    Posts
    16
    Points
    78.75
    Quote Originally Posted by Beth641 View Post
    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)

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.