fritzcap: Tool für Etherreal Trace und Audiodaten-Extraktion v2.0

[FrankBMC]

Bei mir nicht, auch kein RTP.

 

[PeterPawn]

Was sagt denn denn das GUI der FRITZ!Box zu den Parametern der aufgezeichneten Streams? Unter "Telefonie -> Eigene Rufnummern -> Sprachübertragung" sollten sich ja - sofern die detaillierte Protokollierung aktiviert wurde - die Angaben zu den verwendeten Codecs und auch die Anzahl der im Rahmen des Telefonats ausgetauschten RTP-Pakete für jede Richtung ablesen lassen.

Ein Typ 24 für den RTP-Payload ist "unassigned" laut IANA-Registrierung - ich vermute mal, daß da am Ende die Pakete verschlüsselt sind und die Annahme, die 24 wäre der "echte" Payload-Typ (0 ist G.711 mit µLaw, 8 ist G.711 mit aLaw und 13 ist "comfort noise" - mehr erkennt der G.711-Decoder in diesem Projekt gar nicht), daher falsch ist. Das würde zumindest auch erklären, wieso der WireShark-Dissector im Mitschnitt nichts finden kann.

Außerdem kann man ja auch mal eine manuelle Aufzeichnung in der FRITZ!Box starten und dann ein Telefonat führen. Die dabei aufgezeichnete Datei kann man dann auch gezielter untersuchen und für weitere Analysen verwenden. Erst wenn sich darin dann die gesuchten Daten finden lassen, macht es ja überhaupt Sinn, die (doch etwas "gewöhnungsbedürftige") Herangehensweise des hier verwendeten Parsers genauer zu betrachten.

 

[K.Mauser]

Also die Parameter zum Start und Stopp der Aufzeichnung sehen bei mir im Debug-Log exakt genauso aus, wie bei @voipjunkie. Wichtig ist, dass die HD-Telefonie bei allen angeschlossenen Telefonen deaktiviert ist. Aber bei mir sind in jeder bisher erzeugten cap-Datei auch immer zwei RTP-Streams vorhanden, die man auch mit WireShark abspielen kann.

Dem Hinweis von @PeterPawn gehe ich in der kommenden Woche mal nach.

 

[FrankBMC]

HD Telefonie ist bei mir aktiviert, dann wird das wohl der Unterschied sein. Die Option macht ja eigentlich auch Sinn. Den Rest schaue ich mir die Tage mal an, gestern hatte ich gerade etwas Zeit.

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Jetzt nochmal ein neuer Test mit deaktivierter HD Telefonie für das verwendete DECT Telefon:

Die Capture-Datei enthält weiterhin keine Audio-Streams, gar keine, nur normale Protokolle wie TCP, UDP, TLS...auch nicht nach Aktivieren der unsicheren Verbindungen in den DECT-Eigenschaften. Die Installation von fritzcap ist jetzt komplett Standard mit nur den beiden Anpassungen wie vorher beschrieben. Erzeugt wird die Capture-Datei und zwei .wav Dateien, die 58 Bytes groß sind und wohl nur den Header enthalten (RIFF...). Fehlermeldungen kommen soweit gar keine mehr.

Wenn ich den Internetpaketschnitt der Box starte und eine .eth-Datei erzeuge, dann habe ich dort zwei Streams, die aber nur Rauschen wiedergeben. Die Streams werden als "g711A, rtpevent" ausgehend bzw. "g711A" eingehend dargestellt. Das sind ja auch die Payloads, die der Decoder im Debug-Log als "Unsupported payload type" bemängelt.

Das heißt, in Sachen Audio geht in meiner Konfiguration so noch gar nichts, nicht einmal über die Schnittstelle der Box selbst. Falls das eine Rolle spielt: ich nutze einen IP-basierten Anschluß der Telekom mit 50/10 MBit, also keine klassische Telefonie mehr.

Da ist anscheinend noch viel zu tun bis das (wieder?) funktionieren könnte. Ich teste das mit der 7.50 zum ersten Mal, kann also nicht sagen, ob es mit vorigen Versionen funktioniert hätte.

Code:

2023-04-21 22:25:53,611 - Call (ID:1, ActiveCalls.:1, Caller:02211234, DialedNumber:08001, LinePort:SIP0)
2023-04-21 22:25:54,223 - Connect (ID:1, ActiveCalls.:1, Caller:02211234, DialedNumber:08001, LinePort:SIP0)
2023-04-21 22:25:54,675 - Start capture (capture_file:'captures/2023-04-21/222554/capture_20230421222554.cap').
2023-04-21 22:26:06,780 - Disconnect (ID:1, ActiveCalls.:0, Caller:02211234, DialedNumber:08001, LinePort:SIP0)
2023-04-21 22:26:18,730 - Capture finished (capture_file:'captures/2023-04-21/222554/capture_20230421222554.cap').
2023-04-21 22:26:18,731 - Decode process started (worker_id:1, file:'captures/2023-04-21/222554/capture_20230421222554.cap')
2023-04-21 22:26:18,740 - Decode process finished (worker_id:1, file:'captures/2023-04-21/222554/capture_20230421222554.cap')

2023-04-21 22:18:45,021 [ Thread-3::140117864588864] [DEBUG ] [ capture_monitor::sub_stop_capture ] Add captured file 'captures/2023-04-21/221818/capture_20230421221818.cap' to the decoding work queue.
2023-04-21 22:18:45,021 [ Thread-3::140117864588864] [DEBUG ] [ capture_monitor::run_logic ] pre_capture acquire lock.
2023-04-21 22:18:45,022 [ Thread-3::140117864588864] [DEBUG ] [ capture_monitor::run_logic ] pre_capture acquire lock finished.
2023-04-21 22:18:45,022 [ Thread-3::140117864588864] [DEBUG ] [ capture_monitor::run_logic ] pre_capture wait().
2023-04-21 22:18:45,022 [ Thread-1::140117847803456] [INFO ] [ capfile_worker: process ] Decode process started (worker_id:0, file:'captures/2023-04-21/221818/capture_20230421221818.cap')
2023-04-21 22:18:45,023 [ Thread-1::140117847803456] [DEBUG ] [ g711_decoder::decode ] Unsupported payload type 202
2023-04-21 22:18:45,023 [ Thread-1::140117847803456] [DEBUG ] [ g711_decoder::decode ] Unsupported payload type 2
2023-04-21 22:18:45,023 [ Thread-1::140117847803456] [DEBUG ] [ g711_decoder::decode ] Unsupported payload type 202

 

[K.Mauser]

@voipjunkie
hat das bei dir denn vor der FW 7.50 schon mal funktioniert?

 

[FrankBMC]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Das kann ich nicht sagen, ob es funktioniert hätte, da ich das jetzt zum ersten Mal direkt mit der aktuellen Version teste. Ein Firmware-Downgrade kommt für mich definitiv nicht in Betracht.

 

[PeterPawn]

War da nicht etwas, daß die Telekom bei passender FRITZ!OS-Version AUTOMATISCH mit TLS-Verschlüsselung bei den RTP-Paketen arbeitet? Ich bin kein Telekom-Kunde, meine mich aber zu erinnern, etwas in dieser Richtung hier irgendwo und auch im Change-Log von AVM gelesen zu haben.

Wenn das so sein sollte und sich nicht (mehr) abstellen läßt, kann man das an einem Telekom-(VoIP-)Anschluß ohnehin knicken.

 

[FrankBMC]

Ja, wenn man danach sucht, ist das wohl die zwangsweise Verschlüsselung der RTP-Pakete. Da ich in diesem Bereich nie spezielle Einstellungen vorgenommen habe, hatte ich das nicht im Detail verfolgt. Aber wenn das bei der Telekom eben so ist, dann ist es so. Grundsätzlich spricht es ja für die Sicherheit, wenn man selbst mit hohem Aufwand nicht an die Rohdaten kommt, für solche Projekte ist es dann aber eben das Ende.

Da ich meinen Internetzugang beruflich mit Einwahl in spezielle Systeme nutze, bin ich arbeitsrechtlich sogar verpflichtet, alles auf dem aktuellen Stand zu halten, daher sind Firmware-Downgrades und andere Hacks wie Freetz für mich keine weitere Option. Aber die Erkenntnis, dass mit einem Telekom-Anschluß generell nichts mehr geht, ist ja auch etwas wert.

Zitat:

AVM hat mit der Version 7.25 die TLS Schnittstelle für die verschlüsselte Kommunikation verwendet. Der Medienstrom RTP wird jedoch unverschlüsselt übertragen und dies ist gemäß Sicherheitsstandards nicht zulässig

 

[Fritzchen9]

Hallo,
meine Erfahrungen sind die gleichen wie bei K.Mauser.
Ich betreibe 2 FRITZ!Boxen 7590 an 2 Standorten, die über ein VPN verbunden sind. Bislang liefen beide Boxen unter 07.29. Nachdem ich eine Box auf 07.50
aktualisiert habe, funktioniert auf dieser Box fritzcap nicht mehr. Nach Beendigung des Paketmitschnitts ist die Datei 0 Bytes groß. Vielleicht funktioniert
aber auch einfach das Beenden des Paketmitschnitts nicht, weil ja erst dann die Daten geschrieben werden. Deshalb habe ich auf beiden Boxen mehrere Tests durchgeführt, die ich im Folgenden näher beschreiben
möchte.

Beschreibung der durchgeführten Tests:

1. Den ersten Test habe ich mit den Standardeinstellungen von Fritzcap durchgeführt.
Startstring:
http://192...1/cgi-bin/capture_notimeout?&start=1&start1=Start&ifaceorminor=&sid=...
Stopstring:
http://192...1/cgi-bin/capture_notimeout?&stop=1&stop1=Stop&ifaceorminor=&sid=...

2. Auch den zweiten Test habe ich mit den Standardeinstellungen des Tools durchgeführt. Aufgrund von Tipps in diesem Forum habe ich das Interface geändert.
Ab hier gebe ich bei Start- und Stopstring nur noch die Parameter ab dem "?" an.
Startstring: ?start=1&start1=Start&ifaceorminor=2-1&sid=...
Stopstring: ?stop=1&stop1=Stop&ifaceorminor=2-1&sid=...

Dann habe ich mit einem Browser ermittelt, welche Strings beim Starten bzw. Stoppen des Paketmitschnitts übertragen werden. Die Parameter, wie unter 1. beschrieben,
kamen dabei nicht vor. Dennoch ist die Box unter 07.29 damit offenbar irgendwie zurecht gekommen. Bei den folgenden Tests habe ich dann die Start- und
Stopstrings verwendet, die auch beim Browser übermittelt wurden.

3.
Startstring: ?capture=Start&snaplen=1600&ifaceorminor=2-1&sid=...
Stopstring: ?iface=internet,voip&minor=1&type=2&capture=Stop&ifaceorminor=2-1&sid=...
Im Aufruf habe ich --cap_interface=2-1 angegeben.

Von der Box unter 07.29 entsteht in allen 3 Fällen eine Datei von rund 250 KB und eine Wave-Datei in einwandfreier Qualität.
Von der Box unter 07.50 entsteht in den ersten beiden Fällen eine Datei von 0 KB, was nach dem bisher geschriebenen ja auch nicht verwundert. Im dritten Fall eine Datei von 10.620 KB. Das Tool erstellt aber keine Wave-Datei. Wenn man sich die Datei mit Wireshark anschaut, sind
aber RTP-Pakete vorhanden. Es sind aber viele Pakete mit Stille eingefügt, was bei der Box unter 07.29 nicht der Fall ist. Man kann die Pakete zwar mit
dem RTP-Player abspielen, aber die Sprache ist sehr abgehackt. Das dürfte an der eingefügten Stille liegen. Warum auch immer das so ist. Warum ist die
Datei um den Faktor 50 größer als bei der anderen Box. Die große Datei entsteht auf der fernen Box. Die einzigen Aktivitäten auf dieser Box ist das VPN
zur lokalen Box und der eingehende Anruf, der vom Anrufbeantworter entgegengenommen wird.

Ich habe noch einen vierten Test mit dem Interface 3-17 durchgeführt. Das Ergebnis war wie im dritten Test.

Inzwischen hat mein Internetanbieter ein Update meiner lokalen Box auf 07.50 veranlasst, obwohl die Box gar nicht von meinem Internetanbieter stammt. Dummerweise hatte ich diese Funktion nicht deaktiviert.
Und jetzt kommt der Witz an der Sache: Nachdem ich auf meiner lokalen Box ein Downgrade auf 07.29 durchgeführt habe, verhält sich der Paketmitschnitt trotzdem so wie unter 07.50.
Übrigens: In der log_debug-Datei tauchen haufenweise Einträge "Unsupported payload type" auf.
Ich habe eben gerade noch einen Anruf durchgeführt, der kurz von einem AB beantwortet wurde. In der log_debug-Datei tauchen folgende Einträge auf:
12mal payload 40, 4mal 54, 1mal 169 und 2mal 255.
Ich habe allerdings auch schon andere payloads gesehen.

Schönen Tag noch
Fritzchen9

 

[NDiIPP]

Grundsätzlich spricht es ja für die Sicherheit, wenn man selbst mit hohem Aufwand nicht an die Rohdaten kommt, für solche Projekte ist es dann aber eben das Ende.

Na ja, "einfach" die Verschlüsselung deaktivieren, geht auch bei aktuellem FRITZ!OS noch:
https://www.ip-phone-forum.de/threads/telekom-anrufe-verschlüsselt.313909/post-2491122

 

[JohnDoe42]

Hallo zusammen,

nach dem was hier auf der letzten Seite steht ["Der payload type wird im Verbindungsaufbau ausgehandelt, es werden Werte zwischen 96 und 126 verwendet."], würde ich in der g711_decoder.py damit mal in der Klasse G711Decoder experimentieren. Und zwar, bezogen auf Post 509 so, dass ich lediglich den Payload 169 in den Focus nehmen würde.
Also sowas wie

 {'len': 169, 'chunk': 160, 'offs': 9, 'encap' : 'VDSL' },        # VDSL

Falls das nicht klappt, würde ich ein wenig weiter mit chunk und offset experimentieren (chunk+offset=len). Mögliche chunks scheinen 0, 160 und 240 zu sein.

Beste Grüße

JD.

Edit: Nach diesem Post vielleicht auch

 {'len': 24, 'chunk': 0, 'offs': 23, 'encap' : 'VDSL' },        # VDSL

Was dann allerdings auf ComfortNoise hinweisen würde ...

 

[FrankBMC]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Dieser Artikel ist von letztem Jahr und bezieht sich auf die alte Version 7.29, wenn man wie ich einen IP-basierten Anschluss der Telekom hat, geht da nach meinem Verständnis nichts mehr unverschlüsselt. Mag sein, dass Vodafone-Kunden etc. das über Umwege noch können. Für mich ist es aber definitiv niemals eine Option, Downgrades von Systemkomponenten durchzuführen oder bewusst Schwachstellen zu öffnen, um dann solche Bastellösungen einzusetzen. Entweder die Lösung ist "safe" oder sie wird produktiv nicht eingesetzt.

 

[NDiIPP]

[…] wenn man wie ich einen IP-basierten Anschluss der Telekom hat, geht da nach meinem Verständnis nichts mehr unverschlüsselt.

Es geht auch weiterhin unverschlüsselt denn auch andere/ältere IADs wie bspw. der W921V, Fritzbox 7412 oder 7272 funktionieren weiterhin mit den IP-basierten Anschlüssen der Telekom.

 

[FrankBMC]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Von mir aus. Das ändert trotzdem nichts an meiner o.g. Aussage. Zumal ICH keine alte Hardware einsetze und das somit keine Option darstellt, selbst wenn ich diese Sicherheitslücke akzeptieren würde (was ich, wie gesagt, nicht tue).

 

[NDiIPP]

Das ändert trotzdem nichts an meiner o.g. Aussage.

Deine Aussage war doch es geht nicht mehr unverschlüsselt. Aber das ist nicht korrekt, es geht weiterhin unverschlüsselt.

Zumal ICH keine alte Hardware einsetze und das somit keine Option darstellt,

Ich kenne noch etliche Telekom IP-Anschlüsse wo andere Hardware oder ältere Fritzboxen betrieben werden, welche keine Verschlüsselung bei SIP unterstützen.

 

[FrankBMC]

Deine Aussage war doch es geht nicht mehr unverschlüsselt.

Das ist schön für dich, ich nutze trotzdem keine veraltete Hardware. Und außerdem ist meine Aussage weiterhin korrekt, dass es in meiner Konfiguration NICHT möglich ist, die Verschlüsselung zu deaktivieren.

 

[NDiIPP]

Das ist schön für dich,

Was hat das mit mir zu tun?

ich nutze trotzdem keine veraltete Hardware.

1. Ist das hier ein Internet-Forum, da geht es nicht nur um dich, und 2. hat dir hier keiner nahegelegt, dass du veraltete Hardware verwenden sollst. Das diente nur zur Darlegung, dass die Telekom weiterhin unverschlüsselte Telefonie unterstützt.

Und außerdem ist meine Aussage weiterhin korrekt, dass es in meiner Konfiguration NICHT möglich ist, die Verschlüsselung zu deaktivieren.

Weil du es ausprobiert hast, so wie beschrieben? Ein definitives Nein war hier bisher nicht zu vernehmen sondern lediglich ein "nach meinem Verständnis" ohne Erläuterung ob es bereits mit den erwähnten/verlinkten Einstellungen probiert wurde. Und grundsätzlich, von den Einstellmöglichkeiten bei FRITZ!OS 7.5x mal abgesehen, ist unverschlüsselt nun mal weiterhin möglich beim Telekom IP-Anschluss.

 

[FrankBMC]

Bei Telekom IP-basierten Anschlüssen ist die unverschlüsselte Kommunikation für die interne Telefonie (ich rede hier nicht von externen VoIP-Accounts) NICHT mehr möglich, das ist schon lange bekannt und dokumentiert. Und ob und wie lange die Telekom Kunden mit Uralthardware noch mitschleift, ist nicht das Thema und interessiert mich auch nicht. Heißt im Klartext, für meine zugewiesenen MSN der Telekom funktioniert diese Lösung nicht und wird sie auch in Zukunft nicht mehr. Und was ich von "dirty hacks" zum Preis von Sicherheitslücken halte, habe ich nun auch oft genug wiederholt. Für mich ist das Thema hier damit auch durch (und auch diese Diskussion hier).

 

[NDiIPP]

[…] und interessiert mich auch nicht.

Das mag ja sein. Aber das was du behauptest

Bei Telekom IP-basierten Anschlüssen ist die unverschlüsselte Kommunikation für die interne Telefonie (ich rede hier nicht von externen VoIP-Accounts) NICHT mehr möglich, […]

entspricht nun mal nicht den Tatsachen! Bisher hat die Telekom auch keine Anstalten gemacht die dazugehörige Schnittstellenbeschreibung (1TR114) dahingehend zu ändern (siehe dort Punkt 7.4 bzw. Seite 48), Verschlüsselung ist nach wie vor nur optional.

Die Verschlüsselung (SIP over TLS + SRTP) bei Telekom VoIP ist nur bei den Telekom SIP-Trunks eine Voraussetzung wenn nomadisch über einen nicht Telekom-Anschluss genutzt (bei den PK- und GK-Tarifen ohne SIP-Trunk, also MagentaZuhause oder DeutschlandLAN IP Voice/Data, ist diese nomadische Nutzung über andere Provider jedoch gar nicht erst möglich, weshalb da dieser Fall gar nicht erst eintreten kann). Vielleicht hast du das damit verwechselt.

Siehe auch:

Sicherheitsaspekte für Sprachdaten
Bei Nutzung eines Telekom DSL Internetzugangs können SIP und RTP Pakete sowohl unverschlüsselt als auch verschlüsselt zur CompanyFlex (SIP-Trunk) Plattform gesendet werden.
Bei Nutzung eines nicht von der Telekom bereitgestellten Internetzugangs, ist ausschließlich verschlüsselte SIP und RTP Kommunikation möglich.

Quelle: https://hilfe.companyflex.de/de/grundlagen/systemvoraussetzungen

Oder du hast vielleicht das folgende falsch verstanden:
https://telekomhilft.telekom.de/t5/Alles-andere/VoSIP-MediaSec-obligatorisch/td-p/5636512
Das heißt aber nicht, dass die Verschlüsselung nun obligatorisch ist sondern nur, dass man nicht nur eines von beiden (MediaSec oder SRTP) aktivieren darf.

Oder folgendes:
https://telekomhilft.telekom.de/t5/...t-die-Aktualitaet-eurer-Firmware/ba-p/5612545
Das es mit FRITZ!OS 7.25 nicht mehr funktioniert bedeutet nicht, dass es mit älteren FRITZ!OS-Versionen auch nicht mehr funktioniert. Hier hatte AVM einen Fehler ab FRITZ!OS 7.25 eingebaut (TLS ohne SRTP) der erst mit FRITZ!OS 7.29 behoben wurde aber auch Fritzboxen mit älteren FRITZ!OS-Versionen <7.25 nicht betrifft.

[…] das ist schon lange bekannt und dokumentiert.

Wo?

Heißt im Klartext, für meine zugewiesenen MSN der Telekom funktioniert diese Lösung nicht und wird sie auch in Zukunft nicht mehr.

Weil du es probiert hast oder doch nur weil du es von vornherein ausschließt?

Fakt ist jedenfalls, die Telefonie seitens der Telekom wird weiterhin offiziell unverschlüsselt unterstützt (SIP without TLS bzw. over UDP). Das hat nichts mit "dirty hacks" zu tun.

BTW:

Und ob und wie lange die Telekom Kunden mit Uralthardware noch mitschleift, […]

Eine bspw. Fritzbox 7362 SL, 7412, 7582 usw. oder einen Speedport W724V, W925V usw. kann man vielleicht als ältere Modelle bezeichnen aber imo nicht als "Uralthardware". Einige von diesem Geräten bekommen auch immer noch Sicherheitsupdates und können regulär (ohne Verschlüsselung bei SIP, auch bzw. gerade direkt mit der Telekom) verwendet werden.

Und bei den Modellen Speedport Smart 1-3 würde ich ggf. noch nicht einmal "ältere Modelle" gelten lassen. Imo erst mit dem aktuellen Smart 4 (Edit: Offensichtlich wohl auch schon beim Smart 3) wird verschlüsselte Telefonie unterstützt (man möge mich korrigieren falls ich falsch liege) und da auch nur optional bzw. lässt es sich dort deaktivieren. Von "mitschleifen" kann also bisher keine Rede sein.

 

[FrankBMC]

Da du es anscheinend nicht gelesen hast: nochmal der Hinweis, dass die Diskussion für mich hier beendet war und ist. Ich verfolge das Thema nicht weiter.