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. (Beispiel: https://www.ebay.de/itm/234987342646 uvm - kein afilliate link!) Ö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...
:
Bearbeitet durch User
Tim . schrieb: > 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.
Mal probieren, ob der VLC-Player da rankommt...
Peter N. schrieb: > Mal probieren, ob der VLC-Player da rankommt... Das ist der Plan. ;-) Allerdings vermute ich, es fehlt noch eine Initialisierung. Wenn nicht, wäre es um so einfacher. Mit Wireshark beobachten, Adresse abschreiben und VLC damit füttern.
hm... 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. 0000 45 00 00 20 cf 68 40 00 40 11 49 e2 0a d7 ad 01 0010 c0 a8 a9 01 bf fe 22 60 00 0c 08 f4 ef 00 04 00 Per RTP oder RTSP mit VLC auf Port 8800 zuzugreifen funktioniert leider auch nicht.
:
Bearbeitet durch User
Angehängte Dateien:
-
1692699557223.jpg
33 KB
Hier übrigens ein Beispielbild. Die Handyapp scheint nur 640x360 zu speichern, der Sensor wird aber vermutlich VGA können.
Tim . schrieb: > Dieses sind auch erstaunlich gut zur Inspektion von > PCBs geeignet. Tim . schrieb: > Hier übrigens ein Beispielbild. Naja gut – da macht ’n durchschnittliches Telephon mindestens gleichwertige, wenn nicht bessere Bilder ;)
Jack V. schrieb: > Naja gut – da macht ’n durchschnittliches Telephon mindestens > gleichwertige, wenn nicht bessere Bilder ;) Das kostet aber mehr als 8 EUR und deutlich ungeegneiter in der Handhabung.
So etwas gibt es doch schon lange mit USB Anschluss: https://www.amazon.de/USB-Endoskop-OTG-Telefon-Boreskop-wasserdichte-Inspektion-Snake-Kamera/dp/B09TP7SC5Z (12,48€) https://www.aliexpress.com/item/1005005904994274.html (4,70€) Ich habe so eins, damit komme ich sehr gut zurecht (zum SMD Platinen kontrollieren): https://de.aliexpress.com/item/4000965179949.html
Tim . schrieb: > 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.
Stefan F. schrieb: > Ich habe so eins, damit komme ich sehr gut zurecht (zum SMD Platinen > kontrollieren): > https://de.aliexpress.com/item/4000965179949.html 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. Vanye
Tim . schrieb: > aber interessanterweise > habe ich ein FCC tear down gefunden (Anhang). Wär natürlich fein gewesen nicht einfach den FCC Report anzuhängen sondern einfach einen Link zur FCCID zu posten. Aber gut...
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.
Mein Google-fu hat das hier zutage gefördert: https://github.com/SeanPesce/Suear-Web-Viewer Nix mit FFmpeg patchen. 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.
Beitrag #7484419 wurde vom Autor gelöscht.
Daniel G. schrieb: > 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.
Chris S. schrieb: > 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. Daniel G. schrieb: > Mein Google-fu hat das hier zutage gefördert: > https://github.com/SeanPesce/Suear-Web-Viewer > Nix mit FFmpeg patchen. 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.
1 | echo -n -e \\xef\\x00\\x04\\x00 >/dev/udp/192.168.169.1/8800 |
Danach sendet die Kamera einige Frames. Das Format ist noch nicht ganz offensichtlich. Hier der Anfang der Payload des ersten Packets:
1 | 0000 00 00 00 00 01 00 00 00 09 00 00 00 73 23 00 00 ········ ····s#·· |
2 | 0010 80 02 68 01 19 00 02 00 00 00 00 00 33 40 0b 40 ··h····· ····3@·@ |
3 | 0020 0a 05 17 01 40 a4 31 c2 81 85 21 05 31 8b 48 02 ····@·1· ··!·1·H· |
4 | 0030 80 0a 00 4a 00 28 10 50 30 a0 41 40 09 40 c2 80 ···J·(·P 0·A@·@·· |
5 | 0040 12 80 10 d0 02 50 02 1a 04 44 e3 83 4d 12 ca ed ·····P·· ·D··M··· |
6 | 0050 d6 b5 44 34 25 31 12 46 d8 6a 68 19 a7 6b 2e 70 ··D4%1·F ·jh··k.p |
7 | 0060 2a d1 26 94 6d 91 53 24 04 95 03 0a 00 28 00 a0 *·&·m·S$ ·····(·· |
8 | 0070 02 80 0a 00 28 00 a0 02 80 0a 00 28 00 a0 02 80 ····(··· ···(···· |
9 | 0080 0a 00 28 00 a0 02 80 0a 00 28 00 a0 02 80 0a 00 ··(····· ·(······ |
10 | 0090 28 00 a0 02 80 0a 00 28 00 a0 02 80 0a 00 28 00 (······( ······(· |
11 | 00A0 a0 02 80 0a 00 28 00 a0 02 80 0a 00 28 11 97 74 ·····(·· ····(··t |
12 | 00B0 31 3b 55 c8 68 ae e3 22 a0 b2 a4 83 0d 4d 10 c8 1;U·h··" ·····M·· |
13 | 00C0 cd 02 12 98 05 00 28 a4 04 8b 48 b4 3c 0a 92 85 ······(· ··H·<··· |
Ich werde mal schauen, ob sich die Python-Scripte aus dem Github oben anpassen lassen.
:
Bearbeitet durch User
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.
Daniel G. schrieb: > 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...
:
Bearbeitet durch User
Angehängte Dateien:
-
header_huessing.gif
140 KB
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.