Nicht entzifferbare Daten auf dem seriellen Monitor

Ich habe ein fertiges, funktionierendes elektronisches Produkt. Ich wende Reverse Engineering darauf an. Das WiFi-Modul ist über UART (RX & TX) mit dem Mikrocontroller verbunden. Die Android-App sendet Befehle an WLAN und der Mikrocontroller arbeitet gemäß dem Befehl. Ich habe ein USB-zu-TTL-Kabel an RX und TX angeschlossen, auch Befehlserde sowie das WiFi-Modul. Das Kabel ist mit dem seriellen Monitor am PC verbunden. Wenn die App Daten an WLAN sendet, zeigt der serielle Monitor einen nicht entzifferbaren Wert an. Ich habe jede mögliche Baudrate überprüft. Anstelle des USB-zu-TTL-Kabels habe ich auch das HC05-Bluetooth-Modul verwendet. Aber es zeigt nicht entzifferbare Daten. Wie bekomme ich die lesbaren Werte auf meinem seriellen Monitor. Muss ich den Mikrocontroller vom WLAN trennen?

Im gesamten Design wird kein RS232 verwendet.

Die ersten beiden Bilder haben ähnliche Daten, aber mit unterschiedlicher Baudrate. Die ersten Bilddaten werden auf 4800 und die zweiten auf 9600 ohne Parität, 8-Bit-Daten, Stoppbit 1 gesetzt. "0D" ist nur ein Eingabebefehl (zur Lesbarkeit).

Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

Der "Müll" könnte binär kodierte Daten sein. Es gibt keinen besonderen Grund zu der Annahme, dass das Protokoll direkt für Menschen lesbar sein könnte. In der Tat übernehmen viele "App + Gadget"-Anwendungen den größten Teil der Softwarelast (einschließlich der gesamten Benutzeroberfläche) in der App und senden sehr einfache Befehle an das Gadget.
Sie erwarten, dass seine Designer Ihnen das Reverse Engineering leicht gemacht haben?
Meinst du mit Garbage Value, dass der gleiche Stimulus nicht den gleichen Wert ergibt? Andernfalls, wenn die Werte vorhersehbar sind, inwiefern sind sie Müll?
@DaveTweed Gibt es dafür eine mögliche Lösung? Welche Faktoren muss ich überprüfen?
Verwenden Sie ein Oszilloskop, um die tatsächliche Bitrate zu bestimmen, speichern Sie die Daten dann in einer Datei und versuchen Sie, die Daten mit einem Hex-Editor auf Muster zu analysieren. Prüfen Sie, ob die Daten in irgendeiner Weise mit Ihren Aktionen in der Benutzeroberfläche korrelieren.
@Jacob Die gleiche Funktion in der App sendet den gleichen Wert, aber wenn ich ihn nicht verstehen oder nicht lesen kann, ist es für mich ein Müllwert.
@DaveTweed Sicher, wird das auch tun.
@AnujMattóõ In diesem Fall würde ich mir das Datenblatt oder eine andere Dokumentation für das WiFi-Modul ansehen. Ich würde vermuten, dass Sie ein Datenpaket sehen und dass es möglich sein sollte, Anfang und Ende und damit die Daten zu identifizieren (was für Sie wahrscheinlich immer noch keinen Sinn ergibt). Vielleicht können Sie einige Standardmeldungen des WiFi-Moduls identifizieren. Was genau versuchst du zu erreichen?
Maschinen sprechen binär, Menschen können es nicht lesen. Dies bedeutet nicht, dass alle Binärdateien Müll sind. Sie müssen die Pakete sorgfältig analysieren. Da Sie wiederholte Werte für eine bestimmte Aktion erhalten können, versuchen Sie, zwei Aktionen miteinander zu vergleichen. Was ändert sich und was bleibt gleich. Es liegt an Ihnen, das sinnvolle Muster zu finden.
@Jacob Dies ist der Link zur WiFi-Modulseite [link] ( hi-flying.com/products_detail/… ).
@AnujMattóõ Was ich meinte, war, dass ich es an deiner Stelle studieren würde, nicht, dass ich es für dich tun würde 😊
@ Jacob Ja, natürlich. Ich muss das tun. Helfen Sie mir einfach. Ich konnte das Datenblatt nicht anhängen. Musste also den Link anhängen. Ich muss nur wissen, welche Befehle oder Daten die Anwendung an den Mikrocontroller sendet. Das ist es. Es hilft bei der Gestaltung des Produkts.
Veröffentlichen Sie Proben des "Mülls" und kennzeichnen Sie sie mit den Befehlen, die sie darstellen. Ein Diagramm Ihres Setups wäre viel hilfreicher als der ganze Text. Es gibt eine Schaltplan-Schaltfläche in der Editor-Symbolleiste. Veröffentlichen Sie Links zu Datenblättern in Ihrer Frage und nicht in den Kommentaren. Ändern Sie das Wort "Müll" im Titel und posten Sie es in "nicht entschlüsselbar", wenn Sie das meinen.
Klicken Sie jetzt auf die Schaltfläche „Show Hex“ und kopieren Sie die Ergebnisse und fügen Sie sie in Ihren Beitrag ein, damit wir sehen können, was das „.“ Charaktere sind. Dieser Code sieht ziemlich trivial aus.
@transistor Kann nicht entschlüsseln, was "." bedeutet. Es kommt in jedem Befehl vor. Ich habe auch den HEX-Code eingefügt.
@Jacob Hast du etwas über das WiFi-Modul gefunden?
@DaveTweed Ich habe den Screenshot der Daten angehängt, die ich auf Serial Monitor erhalten habe. Bitte guck dir das an.
Die Standard-Baudrate für das WiFi-Modul ist 115200. Haben Sie das versucht?
@TomCarpenter Ja, das habe ich auch versucht. Der serielle Monitor zeigt nur "." Zeichen wiederholt hintereinander.

Antworten (2)

Es sieht so aus, als ob 4800 bps die richtige Geschwindigkeit sind. Die 9600-Daten sind offensichtlich (!) dieselben Daten, die doppelt so oft abgetastet werden. So führen Sie diese Analyse durch:

Hier sind die 9600-Baud-Daten, wie sie als Bitfolge erscheinen würden. Die Daten werden zuerst in LSB geschrieben, und ich habe die Start- und Stoppbits als Kleinbuchstaben o(Null) bzw. i(Eins) dargestellt.

|06      ||3F      ||60      ||0C      ||FE      ||80      ||60      ||CC      |
o01100000io11111100io00000110io00110000io01111111io00000001io00000110io00110011i

Hier sind die 4800-Baud-Daten, gestreckt auf die gleiche Zeitskala:

| 71               | | 24              || 0F              | | A4               |
o 1 0 0 0  1 1 1 0 io 0 0 1 0  0 1 0 0 io 1 1 1 1 0 0 0 0 i o 0 0 1 0  0 1 0 1 i

Beachten Sie, dass jedes Bit im unteren Strom zwei Bits mit demselben Wert im oberen Strom entspricht. Denken Sie daran, dass Ihr Abhörgerät bei 9600 bei einem High-to-Low-Übergang neu synchronisiert wird, sodass bei dieser Geschwindigkeit ein wenig "Slop" um die Byte-Grenzen herum vorhanden ist.

Es ist auch klar, dass eine noch langsamere Geschwindigkeit NICHT richtig wäre – es gibt einzelne isolierte Einsen und Nullen in den Daten bei 4800, was bedeutet, dass dies die minimale Abtastrate für diese Daten ist.

Der erste Hex-Screengrab (bei 4800 Baud) sieht vielversprechend aus:

Was Sie sehen, ist eine 4-Byte-Nachricht. Die Nachricht ist nicht in ASCII und daher nicht für Menschen lesbar. Die Nachricht ist binär (oder hexadezimal, wenn Sie es vorziehen) codiert, und wir müssen sie daher so anzeigen und interpretieren. Binär führt normalerweise zu kürzeren Nachrichten als ASCII.

Geben Sie hier die Bildbeschreibung ein

Abbildung 1. Die ASCII-Tabelle kann in manchen Fällen hilfreich sein. „OD“, das in Ihren Screenshots erscheint, ist das „CR“-Zeichen (Wagenrücklauf).

  • Jede Zeile beginnt mit dem ASCII-Zeichen 'q' (0h71). Es ist wahrscheinlich eine Präambel.
  • Das zweite Zeichen in den von Ihnen geposteten Antworten ist ASCII '$' (0h23) oder '#' (0h24).
  • Das dritte Zeichen ist auf 0h0F festgelegt.
  • Das vierte Zeichen scheint eine Prüfsumme zu sein. Sie können dies mit dem Taschenrechner Ihres Computers im Programmiermodus überprüfen . Wählen Sie den Datentyp „Byte“ (um auf 8 Bit zu kürzen):
    • 0h71 + 0h24 + 0h0F = 0hA4.
    • 0h71 + 0h23 + 0h0F = 0hA3.

Sie haben keine Informationen darüber gegeben, was Sie getan haben, um die Symbole $ und # zu generieren , daher kann ich zu diesem Zeitpunkt nicht weiter helfen.

Nicht entzifferbare Daten auf dem seriellen Monitor
AntwortenHierDatenschutz-Bestimmungen1y, 0v