Wie die Fritz!Box Manipulationen erkennt

knox schrieb:
ich hab einen patch erstellt, der einen netten button ins ds-mod webinterface einfügt: "Attribute bereinigen" ;)

Habe mir den Patch kurz im Editor angeschaut, sieht gut aus. Herzlichen Dank! :D

Vielleicht wäre es auch praktisch, direkt aus der Oberfläche die Lösung Aufräumen direkt nach dem Login (transiente Variante) in die debug.cfg eintragen lassen zu können. Auch die Deinstallation wäre auf diese Weise sicher machbar, denn der EOF-Marker kann ja sehr individuell und unverwechselbar gewählt werden, um ihn leicht lokalisieren und entfernen zu können.
 
Technisch interessant!

Zum Button im dsmod oder fest eingebauten patch, der die Meldung löscht. Ich frage mich, ob es nicht die bessere Alternative wäre, das schulmeisterliche Rot (...nicht unterstützte Änderungen) durch ein Logo zu ersetzen, (z.B. mit alternative text tag: tuned firmware), das gut aussieht aber zugleich auf einen Blick klar macht, dass diese firmware Zusätze/Änderungen gegenüber der avm firmware hat.

Alles andere ist dem avm support gegenüber nicht wirklich fair. (Wenn es fest im dsmod drin ist, die fritzbox einem Benutzer zur Verfügung gestellt wird der den dsmod nicht selber aufgespielt hat und dieser Benutzer sich dann beim avm support meldet...).

Privat für sich kann man das problemlos machen, aber ob die "Tarnkappe für Änderungen" fest in den dsmod eingebaut werden soll, frage ich mich schon.

spblinux
 
spblinux schrieb:
auf einen Blick klar macht, dass diese firmware Zusätze/Änderungen gegenüber der avm firmware hat.
da steht doch klar zu lesen die firmware version, zb 29.04.29ds-0.2.9_26-13, die auf der statusseite ganz oben angezeigt wird.

spblinux schrieb:
ob die "Tarnkappe für Änderungen" fest in den dsmod eingebaut werden soll, frage ich mich schon.
der doofe patch, der die meldung einfach nur ausblendet, wurde doch auch von oli aufgenommen, wieso dann nicht der button?
 
knox schrieb:
da steht doch klar zu lesen die firmware version, zb 29.04.29ds-0.2.9_26-13, die auf der statusseite ganz oben angezeigt wird.
Einverstanden (habe derzeit keinen dsmod auf der box). Trotzdem könnte man es vielleicht etwas augenfälliger markieren.
knox schrieb:
der doofe patch, der die meldung einfach nur ausblendet, wurde doch auch von oli aufgenommen, wieso dann nicht der button?
Da ist schon ein Unterschied. Wenn man nach dem dsmod wieder eine avm Firmware flasht und vorher nicht dafür sorgt, dass im flash die device gelöscht wird, wo der dsmod seine Daten ablegt, dann ist die fritzbox eben modifiziert und genau das soll der rote Text ja anzeigen. (Und soweit ich das überblicke, würde der neue patch bzw. button dafür sorgen, dass nach dem flashen keine rote Meldung erscheint).

Deshalb meine ich: wer weiss, was er tut, der kann natürlich den patch verwenden. Aber per Knopfdruck oder per make menuconfig bei der dsmod-Erstellung finde ich diesen patch nicht so gut.

spblinux
 
Ich habe auch schon mit Daniel geredet, und selbstverständlich lassen wir die Versionsmeldung drin. Wir wollen nicht dem AVM-Support das Leben schwer machen. Er soll sich nicht um gemoddete Boxen kümmern müssen und das leicht erkennen können. Nur die Dirty Flags stören mich tendenziell dann, wenn zu befürchten steht, daß sie irgendwann mal für eine Blockade sorgen würden bei dem Versuch, alternative Firmware zu flashen und zu nutzen. Das müßte ja nicht einmal von AVM selbst kommen, ein OEM könnte die Idee haben.

Der Button, der die Flags manuell löscht, ist für mich auch nicht der Weisheit letzter Schluß, wie geschrieben. Beim nächsten Telnet-Login ist das Flag wieder da. Eine meiner anderen Lösungen wäre da besser. Aber halten wir uns nicht an solchen Kleinigkeiten auf. Ich finde es gut, daß Knox das gebaut und damit gezeigt hat, wie einfach der interessierte Modder es einbauen kann. Im Idealfall wäre jede mögliche Modifikation über make menuconfig ein-/ausschaltbar, aber dafür ist der Aufwand dann ein wenig höher (Freiwillige vor!).

Vergessen wir auch nicht, daß Daniels DS-Mod-NG (Next Generation - das ist kein offizieller Name, aber es klingt gut) in den Startlöchern steht und einen ganz anderen technischen Unterbau haben wird. Irrsinnig viel Aufwand in die Erweiterung des aktuell von Oliver & Co. gepflegten Mod *_26-*zu stecken, macht wohl wenig Sinn. Ziel sollte es sein, alles zwar handhabar und einfach zu haben, aber nicht superkomfortabel. Die Portierbarkeit auf die neue Struktur sollte gewährleistet sein, aber ich stecke da echt zu wenig drin. ipkg sagt mir kaum etwas, und ich kann auch nicht richtig C. Ich habe mich halt ein bißchen 'reingewurschtelt, weil mich diese Dirty Flags interessiert haben.

Zum Problem, daß jemand mit einer gebrauchten Box auch einen "bösen" Mod einkaufen könnte: Ja, das ist denkbar. Dafür reicht es aber auch, einfach die Meldung auf der Webseite auszublenden, meine Tricks braucht man dazu nicht. Davon abgesehen, steht es jedem Käufer frei, erst mal nach dem Kauf bei AVM das Recover-Tool zu ziehen und die Box zu säubern, um dann auf die neueste AVM-FW zu aktualisieren. Natürlich macht das nur einer, der ein entsprechendes Problembewußtsein hat. Von unserer Seite aus (z.B. Daniel, Oliver) ist es jedenfalls so, daß wir nichts Kriminelles vorhaben und nicht geheim halten wollen, daß eine FW modifiziert ist. Man sollte es leicht erkennen können. Das ist bisher immer der Fall gewesen, es wird auch weiter so sein.

Edit: Nicht vergessen: Vieles, was mal als Mod begann, ist jetzt in offiziellen oder Labor-FWs von AVM drin. Ich betrachte das als fruchtbare Zusammenarbeit (auf indirekter, inoffizieller Ebene). Wir beeinflussen uns gegenseitig. Bisher sind die Mods ja auch so gehalten, daß der Original-Umfang von AVM erhalten bleibt und nur Features dazu kommen, mal abgesehen von Kleinigkeiten wie gestrippten Hilfetexten zum Platzsparen. Doch selbst, wenn das nicht so wäre, werden die Boxen ja weiterhin ihrem Zweck entsprechend genutzt, nämlich als DSL-, LAN- und WLAN-Router sowie als Telephon- und VoIP-Anlagen.

Edit: im Eifer des Gefechts 2x Oliver statt Daniel geschrieben. Jetzt stimmt's.
 
Zuletzt bearbeitet:
Das Zentrale ist, dass es Änderungen auf der fritzbox gibt, die ein firmware update überleben (dsmod, cfg_asterisk, cfg_capircvd), weil die Konfiguration in flash devices geschrieben wird (oder werden kann).

Mit dem patch der die "dirty flags" wegputzt, sieht man diese Änderungen nicht mehr (und nach einem firmware-update von dsmod zurück zu avm ist auch der dsmod-Hinweis verschwunden).

Ergebnis: modifizierte box, die so aussieht wie eine normale
(und ohne irgeneine böswillige Absicht).


Deshalb finde ich den patch im dsmod, der nur das webinterface ändert (rote Meldung weg, stattdessen dsmod in die Versionskennung reingeschrieben) besser.

spblinux

edit wegen nachfolgendem Beitrag von knox: rote Formatierung, dass ich von firmware update (d.h. nicht von recover) spreche hinzugefügt.
 
Zuletzt bearbeitet:
spblinux schrieb:
Das Zentrale ist, dass es Änderungen auf der fritzbox gibt, die ein firmware update überleben (dsmod, cfg_asterisk, cfg_capircvd)
nach einem recover mit avm's recover exe ist das alles weg, oder nicht? jedenfalls die ds-mod config ist futsch.

spblinux schrieb:
Mit dem patch der die "dirty flags" wegputzt, sieht man diese Änderungen nicht mehr
mit dem patch für das webinterface auch nicht ;-)

spblinux schrieb:
Deshalb finde ich den patch im dsmod, der nur das webinterface ändert (rote Meldung weg, stattdessen dsmod in die Versionskennung reingeschrieben) besser.
die versionkennung wird unabhängig vom webif patch geschrieben. und auch der button-mod ändert nix daran: eine ds-mod gemoddete box zeigt auf der statusseite ganz oben ihre versionkennung, inkl. mod version.
 
knox schrieb:
mit dem patch für das webinterface auch nicht
@knox: ist das so schwer zu verstehen?

Nach einem firmware update mit avm firmware verschwindet die Wirkung des webinterface patches, d.h. wegepatchte rote Schrift erscheint wieder.

Nach einem firmware update mit avm firmware verschwindet die Wirkung des remove dirty flags patches nicht, d.h. wegepatchte rote Schrift bleibt verschwunden.

kriegaex schrieb:
Ich betrachte das als fruchtbare Zusammenarbeit (auf indirekter, inoffizieller Ebene).
genau um diese fruchtbare Zusammenarbeit geht es

spblinux
 
DS-Mod-Spuren beseitigen beim Wechsel zurück auf AVM-Firmware

@spblinux, knox: Ich denke jetzt mal einfach laut.

Problematik

Ich weiß, ehrlich gesagt, nicht, was exakt passiert, wenn man auf AVM zurück wechselt. Es ist jedoch anzunehmen, daß spblinux Recht hat und die Konfigurationsdateien des DS-Mod im tffs erhalten bleiben, da das FW-Upgrade von AVM ja nichts weiß von der Existenz der anderen Konfigurationsdaten. Was die Dirty Flags angeht, bin ich mir nicht sicher. Ich kenne nur zwei, TELNET und NOT_SIGNED. Ersteres verschwindet, so weit ich weiß, auch dann nicht, wenn man telnetd wieder ausschaltet und installierte Software aus der debug.cfg löscht, nachdem man einmal eingeloggt war. NOT_SIGNED sollte allerdings gelöscht werden durch ein korrekt signiertes Update - falls nicht, wäre das dumm und eher ein Grund, meinen Mod zu verwenden, weil dann die Meldung falsch wäre.

Unabhängig davon, was nun mit den Flags passiert, bleibt ja das Problem bestehen, was mit den unbenutzten Konfigurationsdaten ist, die beim Wechsel zurück auf AVM-FW übrig bleiben. Nehmen wir mal an, ich flashe zurück auf AVM, weil ich die Box verkaufe oder Support vom Hersteller brauche. Damit mir der Support gewährt wird (sagen wir mal, ein LAN-Port ist kaputt oder das DSL-Modem spinnt), muß ich Original-FW haben, um auch beweisen zu können, daß das Problem unabhängig von der FW besteht. Also flashe ich zurück, habe vorher vielleicht sogar schon, schlau wie ich bin, den Button gedrückt, um die Dirty Flags zu löschen bzw. hatte vielleicht einen Patch in der debug.cfg oder in der FW, der das regelmäßig erledigt. Dann wäre alles sauber nach dem Wechsel auf AVM-FW außer dem tffs.

Lösung

Schritt 1: Backup AVM-Einstellungen

Vor dem FW-Wechsel würde ich empfehlen, in der AVM-Oberfläche ein ganz normales Backup der Benutzereinstellungen zu machen: http://fritz.box - Einstellungen - System - Einstellungen sichern. Das sichert nur die AVM-Einstellungen, und später kann ich sie wieder einspielen (siehe Schritt 2).

Schritt 2: tffs löschen

Folgenden Code ausführen, um Box auf Werkseinstellungen zurückzusetzen. Er stammt übrigens direkt aus einem FW-Install-Skript von AVM (29.04.29 für 7170, Datei /var/install, Abschnitt "Downgrade"):

Achtung! Ich weiß nicht, ob die Werte für jede Hardware dieselben sind. Am besten mal in ein FW-Image für Eure Box schauen und den Code von dort nehmen.
Code:
echo "Force: factorysettings ..."
id=$((0x10))
while [ $id -le 255 ] ; do
    echo "clear_id $id" >/proc/tffs
    id=$(($id + 1))
done
id=$((0x4000))
while [ $id -le $((0x4040)) ] ; do
    echo "clear_id $id" >/proc/tffs
    id=$(($id + 1))
done
id=$((0x4400))
while [ $id -le $((0x4440)) ] ; do
    echo "clear_id $id" >/proc/tffs
    id=$(($id + 1))
done
echo "Force: factorysettings done."

Danach sollte das tffs sauber sein.

Schritt 3: Restore AVM-Einstellungen

Reset, Ethernet-Kabel anschließen (nicht WLAN), dann beim nächsten Neustart ggf. gerade so viele Fragen beantworten, bis man wieder das Fritz!-Menü sieht, um dort die gesicherten Einstellungen wiederherzustellen. Anschließend hat man eine sauber konfigurierte Box ohne DS-Mod-Einstellungen oder sonstigen support-gefährdenden Ballast wie LCR Updater in debug.cfg etc. Nur die FW-Version ist noch falsch.

Schritt 4: Installation AVM-Firmware

Das brauche ich wohl nicht zu erklären.

Edit: Mögliche Alternativ-Lösung (ungetestet!)

Mir fiel gerade wieder ein, daß es ja auch /bin/setfactorydefaults gibt. Das Skript sieht recht simpel aus und macht wohl etwas Ähnliches. Ich habe gerade keine Zeit, es auszuprobieren bzw. näher zu analysieren. Vielleicht wurde ja schon mal etwas darüber geschrieben. Das einzige, was ich fand, war, daß sich jemand mit einer Eumex damit die Box tot geschossen hat, aber das war wohl ein Spezialfall.

Code:
echo werkseinstellung >/proc/tffs
echo cleanup >/proc/tffs

Der erste Aufruf könnte etwas Ähnliches oder das Gleiche tun wie der Code weiter oben. Der zweite defragmentiert das tffs und könnte oben auch angehängt werden. Der zweite Befehl ist es auch, der ausgeführt wird, wenn man in der DS-Mod-Oberfläche auf "Cleanup tffs" klickt.

P.S.: So langsam glaube ich, das wäre einen eigenen Thread wert, aber ich mag jetzt gerade nicht. Schließlich mülle ich meinen eigenen Thread zu.
 
Zuletzt bearbeitet:
Alternative zu recover.exe

@kriegaex: Ein grosses Dankeschön für die reiche Informationssammlung (hier im thread und im wiki)!

Damit ist ein Weg beschrieben, wie man ohne recover.exe eine fritzbox wieder in den Originalzustand zurücksetzen kann. (Einschränkung: nach momentanem Kenntnisstand und momentanen firmware Versionen). Und wer dies zu umständlich oder zu unsicher findet, der kann ja recover.exe verwenden.

spblinux
 
knox schrieb:
ich hab einen patch erstellt, der einen netten button ins ds-mod webinterface einfügt: "Attribute bereinigen" ;)

Das ist meiner Meinung nach eine äusserst beschissene Idee ;-)
Die Sache ist die: Die Infos sind hier, und jeder der will bekommt die Meldung jetzt weg.
Ist das Ganze ZU einfach, ist AVM angehalten das wieder zu unterbinden, weshalb es weder Patches oder Updates zum Download geben sollte.
Zusätzlich gilt ab jetzt: Wer eine gebrauchte Fritz!Box nicht erst mal per Recover plättet, hat ein gewaltiges Sicherheitsproblem!
 
Ich hab mal einen Export mit NoChecks=yes zurückgespielt.
Code:
# cat /var/flash/fw_attrib
NOT_SIGNED,TELNET,IMPORT#
MfG Oliver
 
spblinux schrieb:
Nach einem firmware update mit avm firmware verschwindet die Wirkung des webinterface patches, d.h. wegepatchte rote Schrift erscheint wieder.
falsch. nach einem recover mit avm's recover.exe ist die rote schrift auch weg.

ich sehe nach wie vor keinen unterschied, ob auf einer gemoddeten box der text ausgeblendet wurde, oder die dirty flags bereinigt wurden. tut mir leid :)
 
shadow000 schrieb:
Das ist meiner Meinung nach eine äusserst beschissene Idee ;-)
Die Sache ist die: Die Infos sind hier, und jeder der will bekommt die Meldung jetzt weg.
Ist das Ganze ZU einfach, ist AVM angehalten das wieder zu unterbinden, weshalb es weder Patches oder Updates zum Download geben sollte.
ich verstehe die aufregung einfach nicht.
wie du selbst sagst, sind die infos bekannt und jeder kann sie anwenden. wenn sich jeder die paar zeilen shellcode aus dem wiki kopieren und auf seiner box ausführen kann, wieso das dann nicht in einem praktischen button im webinterface integrieren? wo bitte ist da der unterschied?!
falls sich avm daran stören sollte, werden sie es vielleicht irgendwann ändern. ich glaube nicht, dass erst mein patch die ursache dafür sein sollte. schließlich ist der patch für die anzeige der fehlermeldung im webinterface seit langem bekannt und im umlauf und keiner hat sich darüber aufgeregt. falls avm wirklich etwas gegen das fudging mit firmware und das modding haben sollte, dann werden sie sich bestimmt nicht mit ein paar ollen dirty flags aufhalten, sondern andere einschränkungen einbauen.
außerdem mal ganz generell: informationen wollen frei sein. und ich halte überhaupt nichts von elitärem geheimwissen. die katze ist aus dem sack und das ist gut so. :saufen2:
 
@ .spblinux:

Ein bisschen OT:

Sollte man vor einer Weitergabe der Fritz!Box nicht außer dem Recovern auch noch unbedingt auf Werkseinstellung zurücksetzen? Denn die Gesprächsdaten (vielleicht sonst noch was?) überleben das Recovern!

Gruß gianna

Edit zu jojo-schmitz (nachstehender Beitrag):
Gilt vielleicht nicht immer und bei allen Boxen und Firmware-Versionen, ist bei mir aber definitiv schon mehrfach vorgekommen, letztmals gestern (Recover 08.04.15 über vorhandene Firmware 08.04.27, dann wieder upgadatet auf 08.04.27 -> alle Gesprächsdaten noch vorhanden).
 
Zuletzt bearbeitet:
Bei mir haben die Gesprächsdaten bisher noch kein Recover überlebt.
 
kriegaex schrieb:
...
Schritt 2: tffs löschen
...
Danach sollte das tffs sauber sein.

Schritt 3: Restore AVM-Einstellungen

Reset, ...

Schritt 4: Installation AVM-Firmware

Das hier hab ich grad in der "moduninstall" gefunden:
Code:
The next time you save or reboot /var/flash/ds_mod will be created again.
Das bedeutet doch, dass nach Deiner Anleitung das tffs nicht sauber ist, oder? Man muss eine AVM-Originalfirmware einspielen unmittelbar nachdem man das tffs vom dsmod befreit hat, ohne Reboot.

@knox:
spblinux schrieb:
Nach einem firmware update mit avm firmware...
spblinux hat Recht, Du aber auch. Nach einem "simplen" Firmware-Update ist die rote Meldung noch/wieder da, nach einem Recover nicht, weil da ja das tffs gesäubert wird.

Ich glaube, man sollte hier verschiedene Szenarien auseinander halten:
Auf einer gemoddeten Box macht es keinen Unterschied, ob die Meldung via WebIf-Patch oder Button oder wie auch immer ausgeschaltet ist, solange die Box bei jemanden steht, der selbst gemoddet hat.
Gibt man eine gemoddete Box aus der Hand, sollte schon irgendwie ein sichtbarer Hinweis auf die Modifikation zu sehen sein und nur der veränderte Versionsstring ist IMHO nicht ausreichend, weil der "Normaluser" nicht wirklich erkennen kann, dass das Anhängsel "ds-0.2.9" nicht von AVM verursacht wird.
Die Variante mit einem alternativen Logo würde ich begrüßen.
Und dann gibts noch die Variante, dass man eine ehemals gemoddete Box wieder mit Originalfirmware versehen hat und diese weggibt/verkauft... Dann sollte einfach der Fairness gegenüber AVM und dem neuen Besitzer wirklich alles absolut sauber sein. Und da kann eine geänderte /var/flash/fw_attrib zu einer Täuschung führen, wenn man vergisst/unterlässt/..., die Box mit Recover zu bearbeiten...
 
@derheimi: Gut aufgepaßt, setzen, Eins. ;) Wie einleitend geschrieben: Ich habe nur laut gedacht und dabei etwas übersehen. Ausprobiert habe ich es nämlich nicht. Aber Du hast vollkommen Recht. Also sollte man entweder doch recovern oder die AVM-Firmware manuell auf der Box entpacken, um sie direkt zu installieren (auch nie probiert, werde ich aber mal des Nachts machen, wenn meine einzige Fritz!Box hier nicht als Telephonanlage benötigt wird.)

@knox, spblinux: Wer eine gebrauchte, gemoddete Box aus der Hand gibt, sollte so nett sein, sie vorher zu recovern, alleine schon, um die eigenen Spuren zu verwischen. Es könnten ja noch die Porno-Downloads über BitTorrent in der To-Do-Liste im Flash gespeichert sein nach dem Aufspielen der normalen FW. ;-) (Rein theoretisch, ich habe das Torrent-Paket nicht installiert und keine Ahnung, was das tut und speichert. Ihr versteht aber, was ich meine.)

Wer eine gebrauchte Box kauft, tut auch gut daran, sie zu recovern, aber mir ist klar, daß das Problembewußtsein bei einem Neukunden evtl. nicht da ist. Der will einfach billig eine Fritz!Box kaufen. Allerdings kann ein böswilliger Verkäufer auch, wie mehrfach diskutiert, im normalen DS-Mod die Meldung der Flags unterdrücken und vor dem Kompilieren auch die Versionsnummer "original" aussehen lassen. Im Hintergrund hat er dann einen Tunnel so groß wie der St. Gotthard geöffnet und einen Logger, der den Netzwerkverkehr mitschneidet. Ja ja, alles möglich, aber auch bevor ich diese Lösung gepostet habe. Edit: Dafür reicht schon ein Mini-Mod, also Meldung unterdrücken und eine Kleinigkeit in die debug.cfg oder in der ar7.cfg einen Telnet-Port auf die öffnen.

P.S.: Ich hatte nicht gedacht, meine Erkenntnisse seien von so einsteinscher Tragweite, daß nicht andere evtl. auch schon drauf gekommen sein könnten. Nur veröffentlicht ein böswilliger Dritter es nicht, was dazu führt, daß keiner was davon weiß. Und das ist dann wirklich gefährlich. Security by obscurity funktioniert einfach nicht auf Dauer.

Edit: Oops, zu viel qequotetes Zeug drin gelassen.
 
Zuletzt bearbeitet:
ich will noch mal die weiter oben gestellte frage aufwerfen:

nach wie vor gibt es im ds-mod einen patch, der die meldung ausblendet. außerdem sind im wiki die informationen offen beschrieben, wie und wo die "dirty flags" gespeichert sind und wie man sie ändern kann.

wieso darf dann mein patch nicht ins ds-mod?
 
knox schrieb:
wieso darf dann mein patch nicht ins ds-mod?

Weil AVM damit praktisch gezwungen wird, weitere Maßnahmen zu ergreifen.
Es ist ein Unterschied, ob die Meldung nur ausgeblendet wird, oder die Manipulation nicht mehr zu erkennen ist.
Und genau deshalb wird das nicht bequem und für alle zur Verfügung gestellt werden.
Niemand hier hat Interesse daran einen Kleinkrieg mit AVM anzufangen, die sind so schon beschäftigt genug ;-)
 
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.