[gelöst] Nach dem flashen von Freetz auf einer 7430 blinkt nur noch die rote Info LED

Ich versuche dann vielleicht einfach mal, die passenden Links (nur für Dich und um Deine Zweifel, daß es sich tatsächlich um Dein eigenes Such- und Leseversagen handelt, auszuräumen) zusammenzusuchen:

Vielen herzlichen Dank für die Hilfe beim Such- und Leseversagen! :cool:

Ein kurzes Überfliegen des verlinkten Materials zeigt mir das meine Lösung der Abstellung des mystischen -d beim nc deutlich einfacher gewesen ist als die Durcharbeitung des gesamten Materials, welches notwendig ist um zu einer "sauberen Lösung" zu kommen.

Der Link auf die Erläuterungen zu den EVA-Tools ist in jedem Fall erneut sehr hilfreich um zu verstehen, warum alles so fürchertlich kompliziert ist. Dies taugt halt als eigenständiges Hobby ...

damit sollte diese "Präambel" auch kaum noch Mißverständnisse zulassen

In der Tat - sofern man zuerst einmal alle ReadMe's liest und beherzigt, bevor man ein HowTo abarbeitet.
Leider ist die Verschachtelungstiefe in der Ausführung der notwendigen Schritte für ein Hochladen der Firmware nicht wirklich gering. Hoffentlich ist dies zu verzeihen.

Sorry ... mehr geht nun mal nicht und für die Frage, welche Suchmaschine welche Ergebnisse in welcher Reihenfolge ausspuckt, bin ich garantiert nicht zuständig, zumal das eben auch immer von den "Qualitäten" des Benutzers abhängt, denn unterschiedlich formulierte Suchanfragen liefern dann auch unterschiedlich Qualität in den Ergebnissen.

Da stimme ich Dir zu - vielen Dank für die ausführlichen Erläuterungen und den zuvor unsichtbaren roten Faden!

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Ebenso ist im oben stehenden Zitat von der Notwendigkeit die Rede, für die Benutzung von eva_discover das Paket mit socat zu installieren und zu guter Letzt steht dann sogar noch drin (im letzten Punkt vor dem roten Text), welches netcat-Paket man UNTER DEBIAN installieren sollte.

Ich wollte noch einmal die Mystik des -d von netcat für mich aufklären.
Dabei ist mir aufgefallen, daß dieses Alternative OpenBSD-netcat in Debian einen eigenen Namen als Binary hat, damit es mit dem "normalen" nc nicht kollidiert:

Liste der Dateien in Paket netcat-openbsd in bullseye für Architektur amd64

/bin/nc.openbsd

Hoffentlich bist Du mir nicht böse wenn ich nun vermute, daß die Installation des Pakets netcat-openbsd das Problem nicht gelöst hätte, da nämlich noch immer das falsche "normale" netcat mit nc aufgerufen worden wäre.


The options are as follows:
-D Enable debugging on the socket.
-d Do not attempt to read from stdin.

Die Option -d scheint nicht von gewaltiger Natur zu sein.
 
Zuletzt bearbeitet von einem Moderator:
Die Option -d scheint nicht von gewaltiger Natur zu sein.
Vielleicht hast Du sie auch einfach nur nicht verstanden ... ob ein Programm sich nach dem (vergeblichen) Lesen von der Standardeingabe dann sofort wieder beendet oder nicht, sollte schon eine entscheidende Rolle spielen.

da nämlich noch immer das falsche "normale" netcat mit nc aufgerufen worden wäre.
Selbstverständlich bin ich Dir nicht böse ... aber vielleicht VERMUTEST Du das besser nicht nur, sondern überprüfst es einfach mal, indem Du die Installation ausführst.

Vielleicht ist Dir ja auch der alternatives-Mechanismus im Debian (und nicht nur da) bekannt (https://wiki.debian.org/DebianAlternatives) und wenn die Installation des Pakets nicht AUTOMATISCH einen Eintrag dort vornimmt oder einen bereits bestehenden aktualisiert, dann kann/sollte man das immer noch über update-alternatives selbst machen können. Dabei dürfte - bei korrekter Konfiguration des verwendeten Debian-Systems - am Ende auch der Aufruf von nc zur Ausführung von nc.openbsd führen.

Insofern würde ich auch diese "Beschwerde" - bis zum Beweis des Gegenteils, wobei da für mich die (manuelle) Festlegung über update-alternatives durchaus dazu gehört oder zumindest die Deinstallation eines "falschen" netcat-Pakets - ablehnen wollen ...

Du bist auch durchaus nicht der Erste, der sich auf diese Art und Weise "beschwert", nur gelingt es auch anderen "Newbies" auf wundersame Weise immer wieder, die vorhandenen Informationen alleine zu finden. Vermutlich auch deshalb, weil DIE dann dazu bereit sind, auch etwas eigene Zeit in das Lesen zu investieren und nicht auf dem Standpunkt stehen, sie müßten nun irgendwie "gepampert" werden (inkl. des Beseitigens von Verdauungsprodukten von der Haut am südlichen Rücken, was mit dem Produktnamen eines bekannten Windelherstellers korreliert), weil sie einer Software-Lösung die Gnade erweisen, ein - für sie - bestehendes Problem zu lösen zu dürfen.
 
Zuletzt bearbeitet:
Hoffentlich bist Du mir nicht böse wenn ich nun vermute, daß die Installation des Pakets netcat-openbsd das Problem nicht gelöst hätte, da nämlich noch immer das falsche "normale" netcat mit nc aufgerufen worden wäre.
Die Installation des richtigen netcat per Paketmanager hätte geholfen, dabei wird das andere netcat (traditional/GNU) automatisch entfernt. Und der Befehl "nc" bleibt.

Edit, siehe auch:
Code:
Replaces: netcat (<< 1.10-35)
Provides: netcat
Depends: libc6 (>= 2.7-1), libglib2.0-0 (>= 2.12.0)
Conflicts: netcat (<< 1.10-35)
Quelle: https://qa.debian.org/cgi-bin/dcontrol?package=netcat-openbsd
 
Vielleicht hast Du sie auch einfach nur nicht verstanden ... ob ein Programm sich nach dem (vergeblichen) Lesen von der Standardeingabe dann sofort wieder beendet oder nicht, sollte schon eine entscheidende Rolle spielen.

Sicherlich wurde die Option nicht ohne Grund hinzugefügt.

Die Installation des richtigen netcat per Paketmanager hätte geholfen, dabei wird das andere netcat (traditional/GNU) automatisch entfernt. Und der Befehl "nc" bleibt.

Das mag so sein, aber ist meinerseits auf einem Desktop-System zum arbeiten nicht erwünscht.
In einer extra für diesen Zweck geschaffenen Entwicklungs-Umgebung natürlich kein Problem.

Selbstverständlich bin ich Dir nicht böse ... aber vielleicht VERMUTEST Du das besser nicht nur, sondern überprüfst es einfach mal, indem Du die Installation ausführst.

Ich hoffe das ich so ein Flash in absehbarer Zeit nicht noch einmal durchführen muß.
Die Fritzbox 7430 hat nun ein funktionierendes Freetz und so Gott will, läßt sich über dieses bei Bedarf ein weiterer Flash ausführen.

Insofern würde ich auch diese "Beschwerde" - bis zum Beweis des Gegenteils, wobei da für mich die (manuelle) Festlegung über update-alternatives durchaus dazu gehört oder zumindest die Deinstallation eines "falschen" netcat-Pakets - ablehnen wollen ...

Du solltest das alles bitte nicht als "Beschwerde" auffassen, deshalb wurde die Dankbarkeit für Deine Unterstützung immer wieder ausgedrückt.
Wenn ein "beschweren" erfolgte, dann nur über die Komplexität der Materie Freetz und die eigene Unfähigkeit diese zu meistern.
Für diese bist Du jedoch nicht verantwortlich, sondern der Erschaffer AVM.

In diesem Sinne wünsche ich noch einen restlichen besinnlichen Adventstag.
 
Zuletzt bearbeitet:
Du solltest das alles bitte nicht als "Beschwerde" auffassen, deshalb wurde die Dankbarkeit für Deine Unterstützung immer wieder ausgedrückt.
Na ja ... immerhin stellst Du von Deiner Seite aus nachdrücklich fest:
Nun zu den Hürden (ausgeführt unter Debian 9 auf einem separatem Laptop):
und listest da dann auch die Punkte auf, die für Dich zum Problem wurden. Ich habe dann meinerseits nur dagegengesetzt, daß es sich da bei allem um bereits bekannte Hürden handelt und das alles "thematisch" bereits hier behandelt wurde - mithin auch keine neuen Erkenntnisse daraus erwachsen und keine weiteren Änderungen (weder an den Dateien, noch an den vorhandenen Beschreibungen) erforderlich sind.

Danach habe ich eigentlich nur noch Deine Frage:
Bitte wo ist diese Weisheit zu finden?
[...]}
Bis jetzt ist leider nicht klar welche wundervolle Wirkung diese Option entfaltet?
zum Anlaß genommen, Dir das genauer aufzudröseln (schon deshalb, damit der NÄCHSTE Leser dann nicht auf Deine Darstellung vertraut und in die Irre geleitet wird) und irgendwie verdichtete sich (bis zu #25) bei mir immer mehr ein Verdacht, daß Du UM JEDEN PREIS Recht behalten wolltest und nach allen möglichen "Ausreden" gesucht hast, warum das eben NICHT Dein eigenes Such- und Leseversagen sein könne.

Wenn man sich bei derartigem Versagen (und dem nachdrücklichen Ansprechen desselben) aber nicht auf den Schlips getreten fühlt und sich vornimmt, es bei nächsten Mal einfach besser zu machen, dann haben alle etwas davon ... nur wird das vermutlich nicht passieren, wenn die Einsicht dazu fehlt und dafür spricht es ja schon, wenn immer wieder eine "Schuld" bei anderen gesucht wird und daran ändert es auch nicht wirklich etwas, wenn man sich für erhaltene Hilfe bedankt ... es SOLLTE dann auch tatsächlich so gemeint sein und nicht ständig die Form: "Ja, aber ..." annehmen.

In diesem Sinne wünsche ich noch einen restlichen besinnlichen Adventstag.
Gleichfalls.
 
und listest da dann auch die Punkte auf, die für Dich zum Problem wurden.

Würden noch Fragen in diesem Forum gestellt werden, wenn keine Probleme in der Ausführung auftreten würden?

Wenn man sich bei derartigem Versagen (und dem nachdrücklichen Ansprechen desselben) aber nicht auf den Schlips getreten fühlt und sich vornimmt, es bei nächsten Mal einfach besser zu machen, dann haben alle etwas davon ... nur wird das vermutlich nicht passieren

Aus diesen Gründen habe ich versucht meine Schritte zur Lösung des Problems zu dokumentieren.

Die Abhängigkeiten sind insgesamt so komplex, das es noch nicht einmal helfen würde ein Abbild von Freetz-NG und MyFritz zu kombinieren und in github hochzuladen, da zusätzlich noch Eigenarten der verwendeten Linux-Distribution mit hineinspielen.
Also müßte es eine komplette VM mit Kubuntu und allen anderen benötigten eingerichteten Komponenten sein.

Selbst dann wäre bei mir immer noch das Problem des korrekten Hochladens abhängig vom Flash-Speicher aufgetreten.

Das Gesamtgebilde der Entwicklungsumgebung von Freetz, als auch der Flash-Vorgang sind insgesamt sehr kompliziert und anspruchsvoll. Da findet man sehr schnell seine Grenzen und Meister wie PeterPawn.
 
insgesamt sehr kompliziert und anspruchsvoll. Da findet man sehr schnell seine Grenzen und Meister
Ich habe auch nichts Gegenteiliges behauptet ... wer das alles WIRKLICH verstehen will, der muß eben auch die Zeit/Geduld aufbringen, sich (anhand der RICHTIGEN Quellen) schlau zu machen. Es ist nämlich für den NORMALEN Gebrauch einer FRITZ!Box gar nicht erforderlich, da eine eigene Firmware zu installieren. Daher ist es (für mich zumindest) auch zulässig, wenn AVM die Geräte gegen die unbefugte Installation einer modifizierten Firmware (deren Autor/Ersteller muß ja auch nicht immer nur "nette" Absichten haben) - so gut es geht - absichert und wenn sich daraus für diejenigen, die unbedingt die Firmware "modifizieren" wollen, ein etwas höheres Niveau bei den erforderlichen Kenntnissen ableitet, dann ist das eben so ...

Man denke nur mal an die ganzen Smartphones, die auch erst einmal "gerootet" werden müssen oder für die ein passender "jail-break" veröffentlicht werden muß - Firmware-Modifikationen sind nun mal kein Ponyhof.

Aber es ist eben auch eine Frage des grundsätzlichen Herangehens, ob man selbst mit "halbgaren" Behauptungen an die Öffentlichkeit geht oder ob man sich ZUERST einmal vergewissert, daß ob es nicht doch EIGENE Fehler sind: https://tty1.net/smart-questions_de.html#dontclaimbug



Aber nun ist es auch gut ... ich habe meinen Standpunkt dazu (m.E.) ausreichend erläutert (und das auch nicht zum ersten Mal, denn das Thema ploppt ja immer wieder mal neu auf) und solange es jetzt keine WIRKLICH neuen Erkenntnisse zu weiteren Problemen gibt, ist von meiner Seite aus diese Diskussion beendet.
 
... wer das alles WIRKLICH verstehen will, der muß eben auch die Zeit/Geduld aufbringen, sich (anhand der RICHTIGEN Quellen) schlau zu machen. Es ist nämlich für den NORMALEN Gebrauch einer FRITZ!Box gar nicht erforderlich, da eine eigene Firmware zu installieren. Daher ist es (für mich zumindest) auch zulässig, wenn AVM die Geräte gegen die unbefugte Installation einer modifizierten Firmware (deren Autor/Ersteller muß ja auch nicht immer nur "nette" Absichten haben) - so gut es geht - absichert und wenn sich daraus für diejenigen, die unbedingt die Firmware "modifizieren" wollen, ein etwas höheres Niveau bei den erforderlichen Kenntnissen ableitet, dann ist das eben so ...

Die Bemerkung über das eigenständige Hobby zielte genau darauf ab.
Es ist nämlich ein eigenständiges Hobby die "Geheimnisse von AVM" zu lüften und sich in das komplexe Build-System einzuarbeiten.
Beides hat im Grunde genommen nichts mit der eigentlichen Benutzung einer Fritzbox zu tun.

Mein Interesse ist es lediglich den Funktionsumfang zu erweitern und tatsächlich Eigentümer des Gerätes zu werden, was ohne Root-Rechte streng genommen nicht der Fall ist.

Das Thema "nette Absichten" führt mit Sicherheit zu einer längeren Diskussion, vor allem da es sich sowohl auf die Interessen der Benutzer als auch der von AVM und weiterer Interessensgruppen bezieht.

Man denke nur mal an die ganzen Smartphones, die auch erst einmal "gerootet" werden müssen oder für die ein passender "jail-break" veröffentlicht werden muß - Firmware-Modifikationen sind nun mal kein Ponyhof.

Dies ist ein hervorragendes Beispiel für einen Vergleich.
Für die Android-Geräte werden meistens fertige Images angeboten und der "Jail-break" ist die einzige Aufgabe die gemeistert werden muß. Wenn die Quellen zur Verfügung gestellt werden, weil es sich nicht nur um einen "Mod" handelt, dann ist es eine losgelöste und getrennte "Herausforderung" aus diesen selber ein Image zu erstellen oder die Zusammenstellung zu modifizieren.

Eigentlich sagt das Wort "Jail-Break" doch bereits alles worum es hier wirklich geht.

Wenn für eine Fritzbox fertige Freetz-Images existieren würden, wäre meinerseits kein großes Interesse gegeben ein eigenes Image zusammenzustellen. Dies liegt in erster Linie daran, daß noch ein "regulärer" Server existiert, auf dem alle gewünschte Software einfach als Linux-Pakete installiert und frei konfiguriert werden können.

Dies ist auch der wahre Grund warum das Thema Freetz meinerseits mit "zu wenig" Elan und zu viel Ungeduld angegangen worden ist. Es besteht in erster Linie Interesse am Ergebnis und nicht an dem Weg dorthin.
Allerdings muß ich zugeben das ich dabei dennoch eine Menge gelernt habe, was eindeutig positiv ist!
Dies ist vor allem Deiner freundlichen Unterstützung zu verdanken!

Ich hoffe das der ehrliche Kommentar kein Fettnäpfchen in der Größe einer Badewanne darstellt? :)
Es geht weder darum Dein großes Interesse an dem Thema zu verachten, noch Deine profunde Kompetenz anzuzweifeln.
Hier geht es einfach nur um unterschiedliche Interessens-Schwerpunkte.


Aber nun ist es auch gut ... ich habe meinen Standpunkt dazu (m.E.) ausreichend erläutert (und das auch nicht zum ersten Mal, denn das Thema ploppt ja immer wieder mal neu auf) und solange es jetzt keine WIRKLICH neuen Erkenntnisse zu weiteren Problemen gibt, ist von meiner Seite aus diese Diskussion beendet.

Das kann ich ebenfalls gut verstehen. Diese Diskussion hat mit dem Thema Freetz auch nur indirekt zu tun (Thema Jail-Break).
 
Zuletzt bearbeitet:
Das Thema "nette Absichten" führt mit Sicherheit zu einer längeren Diskussion, vor allem da es sich sowohl auf die Interessen der Benutzer als auch der von AVM und weiterer Interessensgruppen bezieht.
Eben, auch die (potentieller) Angreifer. Eingeführt wurden ja die entspr. Änderungen (nur signierte Images) um primär die Sicherheit zu erhöhen. Zuvor war es keine große Hürde eine modifizierte (ggf. eine im Sinne des Angreifers modifizierte) Firmware zu installieren. Von daher ist diese Änderung durchaus zu begrüßen, auch aus Sicht der meisten Endanwender.

Wenn für eine Fritzbox fertige Freetz-Images existieren würden, wäre meinerseits kein großes Interesse gegeben ein eigenes Image zusammenzustellen.
Vergessen wird in dem Zusammenhang gerne, das FRITZ!OS im Gegensatz zu Android kein OpenSource-Betriebssystem ist. Lediglich der darin verwendete Linux-Kernel und ein paar weitere (kleinere) Programme darin sind OpenSource aber elementare Bestandteile von FRITZ!OS sind eben proprietär. Fertige Images (inkl. der proprietären Bestandteile) können daher eben nicht legal angeboten werden.

Android ist dagegen komplett OpenSource (zumindest das AOSP). Klar gibt es auch da proprietäre Bestandteile, neben den GAPPS bspw. auch die (je nach Modell) verwendeten Treiber oder insb. die Firmware für das Mobilfunkmodem aber letztendlich nicht direkt vergleichbar mit FRITZ!OS.

Was aber nicht bedeutet (um hier mal den Vergleich wieder mit Android-Geräten zu führen), dass es keine fertigen legalen Firmware-Images für Fritzboxen gäbe, die gibt es nämlich, bspw. OpenWRT basierte. Es ist also möglich… Allerdings gibt es nicht für alle Fritzbox-Modelle fertige OpenWRT Images (was neben dem Interesse entspr. Entwickler primär auch an der verbauten Hardware liegt für die es tw. eben keine freien Treiber gibt) und es funktionieren ggf. auch nicht alle Hardware-Komponenten.

Letztlich ist es nicht viel anders als bei Android-Geräten, nicht alle Android-Geräte können mit einer "Community-Firmware" o.ä. betrieben werden bzw. funktionieren dann ggf. nicht alle Komponenten. Und eigene/modifizierte Firmware kann bei Android-Geräten eben auch nicht so ohne weiteres vom laufenden (originalen) BS aus installiert werden (auch hier können i.d.R. nur signierte Images verwendet werden), auch da muss häufig die Installation über den Bootloader durchgeführt werden (der dazu ggf. auch noch entsperrt werden muss was je nach Modell/Hersteller auch noch weitere Nachteile mit sich bringen kann, solche Einschränkungen/Nachteile hat man bei Fritzboxen bisher nicht).

Dies ist auch der wahre Grund warum das Thema Freetz meinerseits mit "zu wenig" Elan und zu viel Ungeduld angegangen worden ist. Es besteht in erster Linie Interesse am Ergebnis und nicht an dem Weg dorthin.
Nicht das ich keine Kritik am Freetz bzw. Freetz-NG Projekt bzw. des jeweiligen Maintainer hätte aber ich sehe keinen grundsätzlichen Unterschied zwischen Fritzboxen und Android-Geräten.
Ich hatte mal aus bestimmten Gründen für mein Smartphone auch schon ein LineageOS Image gebaut (und eben keines dieser fertigen Images verwendet), also u.a. auschecken des LineageOS Repository (per git) usw. usf. (siehe bspw.: >klick<). Vom Grundprinzip her also nicht anders als bei Freetz (wobei die Anforderungen bei LOS sogar noch höher sind als bei Freetz). Auch da musste ich erst eine Weile recherchieren, bis das klappte. Also einfacher ist es im Android-Bereich meiner Meinung nach nicht.
 
Eben, auch die (potentieller) Angreifer.

Gibt es belegte Wellen von Übernahmen von Fritzboxen für Hacker-Cluster?

Android ist dagegen komplett OpenSource (zumindest das AOSP). Klar gibt es auch da proprietäre Bestandteile, neben den GAPPS bspw. auch die (je nach Modell) verwendeten Treiber oder insb. die Firmware für das Mobilfunkmodem aber letztendlich nicht direkt vergleichbar mit FRITZ!OS.

Warum ist das nicht vergleichbar?

Eigentlich müßte die Frage lauten warum für bestimmte Teile die Sourcen von AVM zur Verfügung gestellt werden?
Liegt es vielleicht daran das AVM selber Opensource-Quellen benutzt und je nach Opensource-Lizenz das Ergebnis wieder veröffentlicht werden muß?

Was aber nicht bedeutet (um hier mal den Vergleich wieder mit Android-Geräten zu führen), dass es keine fertigen legalen Firmware-Images für Fritzboxen gäbe, die gibt es nämlich, bspw. OpenWRT basierte.

Danke für den Hinweis!
Die Auswahl ist gar nicht so gering: https://openwrt.org/toh/avm/start

In diesem Fall: https://openwrt.org/toh/avm/avm_fritz_box_7430
Es gibt leider scheinbar keine besonderen Hinweise was von der Hardware alles unterstützt wird.
Insbesondere VDSL und Telefonie. Für DSL findet man Hinweise.

Ein weiteres Beispiel wäre Gluon für Freifunk: https://gluon.readthedocs.io/en/v2020.1/releases/v2020.1.html
Das ist ein Fork von OpenWrt so weit ich weiß.

Nicht das ich keine Kritik am Freetz bzw. Freetz-NG Projekt bzw. des jeweiligen Maintainer hätte aber ich sehe keinen grundsätzlichen Unterschied zwischen Fritzboxen und Android-Geräten.

Grundsätzlich ist das Jail-Break in der Tat vergleichbar.

Vom Grundprinzip her also nicht anders als bei Freetz (wobei die Anforderungen bei LOS sogar noch höher sind als bei Freetz). Auch da musste ich erst eine Weile recherchieren, bis das klappte. Also einfacher ist es im Android-Bereich meiner Meinung nach nicht.

Das findet meine absolute Zustimmung.
Alleine schon wie sehr der Kernel von Google verbastelt wurde - von der Android Oberfläche mit dem Java ganz zu schweigen.
Selbst mit Root-Rechten findet man in einem "modernen" Android auf der Linux-Ebene irgendwie die Hölle vor.
Es ist mir bislang nur einmal gelungen ein Debian parallel dazu zu etablieren und das war bei einem älteren Gerät.
 
Zuletzt bearbeitet:
Gibt es belegte Wellen von Übernahmen von Fritzboxen für Hacker-Cluster?
Ich erinnere an den webcm-Gau 2014. In dessen Folge hat AVM nicht nur die webcm-Schwachstelle beseitigt (über die man auch manipulierte Firmware hätte installieren können) sondern auch einige andere (potentielle) Schwachstellen in FRITZ!OS. U.a. eben die nicht zwingend erforderliche korrekte Image-Signatur (die war nach Bestätigung eben nur optional). Auch bei anderen Herstellern ist es mittlerweile üblich, dass eine (zwingende) Überprüfung der Signatur stattfindet. Siehe dazu übrigens auch folgendes Dokument vom BSI:
https://www.bsi.bund.de/DE/Themen/U...nach-Thema-sortiert/tr03148/tr03148_node.html

Zitat daraus:
In both scenarios (manual and automated update) the firmware update function of the router MUST check the authenticity of the firmware package (file) before it is installed on the router. This SHOULD be done by a digital signature that is applied to the firmware package by the manufacturer and checked by the router itself […]

AVM setzt da also "nur" die quasi bzgl. "Stand der Technik" erforderlichen Basics bzgl. Sicherheit um. Das Argument "bisher ist da doch gar nichts im größeren Stil passiert oder bekannt geworden" kann doch nicht ernsthaft ein Argument sein, bekannte Lücken oder Angriffsmöglichkeiten weiterhin offen zu lassen!

Warum ist das nicht vergleichbar?
Warum hatte ich geschrieben.

Eigentlich müßte die Frage lauten warum für bestimmte Teile die Sourcen von AVM zur Verfügung gestellt werden?
Weil sie es müssen, das erfordern die jeweiligen Lizenzbedingungen der verwendeten Software-Bestandteile (bspw. Linux-Kernel).

Ein weiteres Beispiel wäre Gluon für Freifunk:
Es hat einen Grund weshalb ich u.a. die 4040 oder den Repeater 1200 "mag"…
 
Ich erinnere an den webcm-Gau 2014. In dessen Folge hat AVM nicht nur die webcm-Schwachstelle beseitigt (über die man auch manipulierte Firmware hätte installieren können) sondern auch einige andere (potentielle) Schwachstellen in FRITZ!OS. U.a. eben die nicht zwingend erforderliche korrekte Image-Signatur (die war nach Bestätigung eben nur optional). Auch bei anderen Herstellern ist es mittlerweile üblich, dass eine (zwingende) Überprüfung der Signatur stattfindet. Siehe dazu übrigens auch folgendes Dokument vom BSI:
https://www.bsi.bund.de/DE/Themen/U...nach-Thema-sortiert/tr03148/tr03148_node.html

Basierte der Webcam-Hack nicht auf einer Kernel-Schwachstelle?

Wenn jemand zum Beispiel über eine Kernel-Schwachstelle eindringen kann, dann braucht er eigentlich keine neue Firmware oder kann dann ebenso den Inhalt so weit manipulieren, bis ein Update einspielbar ist.


Wenn eine Fernkonfiguration eingebaut und mißbraucht wird, dann wurde diese doch in ihrem Sinne benutzt. :cool:

Warum ist das nicht vergleichbar?
Warum hatte ich geschrieben.

Die proprietären Teile werden aus genau den gleichen Gründen wie bei einem Android nicht offen gelegt.
 
Basierte der Webcam-Hack nicht auf einer Kernel-Schwachstelle?
Nein. Die Schwachstelle war webcm selbst. Ein proprietärer Bestandteil der Firmware der von AVM stammt.

Wenn eine Fernkonfiguration eingebaut und mißbraucht wird, dann wurde diese doch in ihrem Sinne benutzt. :cool:
Man kann bzw. konnte diese Schwachstelle auch mit komplett deaktivierter Fernkonfiguration ausnutzen. Also bspw. auch bei einem Speedport W920V der mit tcom-Firmware gar keine Fernkonfiguration für den Endnutzer anbietet (wenn man jetzt von TR069 absieht aber selbst das entfernen von TR069 hätte nicht geholfen).
 
Man kann bzw. konnte diese Schwachstelle auch mit komplett deaktivierter Fernkonfiguration ausnutzen. Also bspw. auch bei einem Speedport W920V der mit tcom-Firmware gar keine Fernkonfiguration für den Endnutzer anbietet (wenn man jetzt von TR069 absieht aber selbst das entfernen von TR069 hätte nicht geholfen).

Tja - manchmal geht der Schuß halt nach hinten los.
 

Neueste Beiträge

Statistik des Forums

Themen
244,880
Beiträge
2,220,049
Mitglieder
371,605
Neuestes Mitglied
michaelwarwel
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.