Aktuell gibt es, als "Ohrwachsentferner" getarnt, sehr günstige und einigermassen brauchbare Mikroskope, die das Bild per Wifi auf eine Handapp übertragen. Dieses sind auch erstaunlich gut zur Inspektion von PCBs geeignet.
Öffnen lässt sich das Device nicht so leicht, aber interessanterweise habe ich ein FCC tear down gefunden (Anhang). Neben einem Camera/Wifi SOC und Charger gibt es auch noch einen 3-Achsen Beschleunigungssensor, mit dem Das Bild automatisch ausgerichtet wird.
So nun, zu meiner Frage:
Ich würde das Bild gerne auf meinen PC übertragen. Das Device stellt einen lokalen Wifi AP zur verfügung, über den sich das Smartphone verbindet. Mit diesem kann auch mich auch mit meinem PC verbinden.
Es wird eine TCP-Addresse vergeben, allerdings kann ich keinerlei offene Ports finden.
Hat jemand eine Idee, wie man hier weiter vorgehen könnte? Ich finde im Netzt leider kaum Beispiele, solche devices zu "hacken". Direct-Wifi cameras gibt es ja eigentlich zuhauf...
Hat jemand eine Idee, wie man hier weiter vorgehen könnte?
Mit wireshark analysieren.
Ich gehe davon aus das die App das Gerät "aufweckt" und von dort aus einen Videostream bekommt.
Also kann es auch nötig sein einen MITM zu installieren und die Anfrage der App an die Kamera mit zu schneiden.
Die app greift per UDP auf port 8800 zu. Leider Antwortet die Kamera nicht, während der Datenlogger aktiv ist. Die Datenpakete sind alle gleich und werden von Wireshark nicht als existierendes Protokoll erkannt.
Das kostet aber mehr als 8 EUR und deutlich ungeegneiter in der
Handhabung.
Die Kosten relativieren sich, da einerseits ja sowieso die meisten so ein Gerät haben, und andererseits, weil das von dir gezeigte Gerät ebenfalls ein Telephon oder Tablet benötigt.
Was die Handhabung angeht, hängt’s wohl von den Umständen ab. Wenn ich häufiger unzugängliche Ecken photographisch aufnehmen wollte, würde ich mir ein „richtiges“ Endoskop holen.
Ja, so eins habe ich auch. Das Kabel stört aber schon und es ist deutlich größer.
Generell fände ich es interessant, außerhalb von den mitgelieferten Apps auf die Kamerastreams dieser Wifi-cams zugreifen zu können. Die sind mir schon an vielen Stellen begegnet: Drohnen, CCTV, usw...
Wie lange haelt denn da der Akku? Das Teil ist ja relativ
klein und ein kontinuierlicher Videostream ueber Wlan wird
schon einiges an Leistung brauchen.
Man muss ffmpeg patchen damit es geht, da der. Stream nicht Normgerecht ist. Es lassen sich 4 Auflösungen einstellen, die mentionierte ist die kleinste und Default. Einfach nach dem Patch g00glen.
Man beachte, dass die README ein zweites Projekt für Kameras eines anderen Herstellers nennt.
Die Kamera mit Kabel habe ich in der Variante mit 5,5mm Durchmesser. Für meinen Geschmack ist der Fokus dieser Kamera ungünstig gewählt. Am schärfsten ist sie auf 2cm Entfernung.
Ist bei meiner auch so. Deswegen habe ich mit Tesafilm ein Streichholz als Abstandshalter dran geklebt. Es ragt ungefähr 2 Zentimeter nach vorne heraus.
Das Streichholz hilft mir, die Kamera im richtigen Abstand ruhig zu halten. Dennoch kann ich sie seitlich hin und her schwenken, um Lötstellen aus unterschiedlichen Blickwinkeln zu betrachten.
Man muss ffmpeg patchen damit es geht, da der. Stream nicht Normgerecht
ist. Es lassen sich 4 Auflösungen einstellen, die mentionierte ist die
kleinste und Default. Einfach nach dem Patch g00glen.
Hast Du den link zufällig so einfach lässt sich das nicht finden.
Super, sehr interessant. Leider scheint es sich bei meiner Kamera um ein Modell zu handeln, welches dort nicht aufgelistet ist (sieht auch nächster post).
Inzwischen ist es mir gelungen, die Kommunikation mit Hilfe von airodump-ng mitzuschneiden. (Hat ewig gedauert, da die Software auf einem RPI400 nicht funktioniert hat, dafür aber auf einem RPI3 mit dem gleichen USB WLAN-Adapter?!?)
Das Kommunikationsprotokoll ist ähnlich zu denen aus dem github repo oben, leider aber trotzdem nicht ganz kompatibel.
Der Stream wird durch ein UDP-Paket mit dem Inhalt 0xef000400 an den Port 8800 initiert.
Hm, die Strings in der libbl_vii_jni.so der Android App lassen mich vermuten, dass die NE3 Kamera headerlose JPEGs schickt. JPEG in RTP spart sich auch die Quantisierungstabellen zu übertragen, wenn ein Quantisierer von 1 bis 99 ausgewählt wird.
Es gibt in der Datei 6 dynamische Symbole der Form jpeg_header_640x360_Q<Zahl> mit <Zahl> = 5, 10, 25, 50, 75 und 100. Und ja, bei jedem dieser Symbole liegen die ersten 605 Bytes eines 640x360 JPEG Bilds.
Hm, die Strings in der libbl_vii_jni.so der Android App lassen mich
vermuten, dass die NE3 Kamera headerlose JPEGs schickt. JPEG in RTP
spart sich auch die Quantisierungstabellen zu übertragen, wenn ein
Quantisierer von 1 bis 99 ausgewählt wird.
Das ist allerdings sehr interessant. Ich hatte die App schon decompiliert und war ziemlich verwundert, keinerlei Referenzen zu Port 8800 zu finden. In der App gibt es auch noch Hinweise auf mehrere Streaming-Bibiliotheken, die mich ziemlich verwirrt haben.
Die von Dir gefundete library scheint aber genaue die richtige zu sein. Es gibt auch einen String mit "8800" - der Portnummer... Time for Ghidra...
Ich bin ein wenig weiter gekommen. Es scheint sich tatsächlich um einen MJPEG RTP Stream zu handeln, leider in einem etwas anderen Format als die "Suaer" devices oben. Ein paar Felder lassen sich in den Headern indentifizieren (siehe Bild).
Die von Daniel gefundenen JPG-Header passen in das Gesamtbild. Leider ist noch nicht klar, welches Feld in den Headers die Qualität auswählt. Ich werde mal versuchen, ein komplettes JPEG Bild zusammen zu setzen.
Ghidra decompiliert auch die Bereiche mit den Headern. Eine Funktion, die die JPEG-Bilder wieder assembliert habe ich noch nicht identifizieren können. Leider sind nicht sehr viele Symbole in der Library (libbl_vii_jni.so) vorhanden.
