[Info] FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht?

Mit
Code:
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git bin
aus meinem Yourfritz-Verzeichnis heraus hat es geklappt und die beiden skip_auth.image und add_user.image wurden erstellt. Ich kann #39 halt nur anmerken, falls nachfolgende Leser über dasselbe Problem stolpern. Obschon eva_discover zielsicher nunmehr die FB7412 findet, wird sie nicht immer korrekt angehalten. Z.T. meint die Konsole Bootprocess interrupted, jedoch lässt sich adam2 nicht einloggen.
Danke für die Tips, da ich mit github und möglichen Fehlern eher unbedarft bin.

Hintergrund: Ich hatte last week eine FB7412 mit FW6.83 erhalten, die nicht auf Werkseinstellungen stand, sondern nur (ohne Benutzer) mit Start-Code eingerichtet war. Das erstellte add_user.image brachte keinen neuen user "superuser" auf den Startbildschirm, jedoch skip_auth.image setzte das PW brav zurück und brachte den Passwort-Setzen-Bildschirm hervor mit dem Hinweis, Ihre Fritz!Box wurde mit Start-Code eingerichtet. Btw hatte ich die Erlaubnis des Vorbesitzers dazu, da der 1&1-Vertrag der FB letzes Jahr ausgelaufen war.
LG
 
Das Anhalten der Boxen im Bootloader funktioniert leider auch nicht bei allen Modellen auf dieselbe Weise ... bei einigen reicht es bereits, wenn man überhaupt eine FTP-Verbindung aufbaut und da stört sich der Bootloader nicht im geringsten daran, wenn man diese Verbindung (die ja nur zum Anhalten dient) einfach wieder schließt (so macht es "eva_discover").

Andere Bootloader (ob das versionsabhängig ist, weiß ich auch nicht ... für einen umfassenden Test bräuchte man sehr viele Boxen mit unterschiedlichen Bootloader-Versionen) geben sich auch mit einem "QUIT" (anstelle eines Login) vor dem Schließen der TCP-Verbindung zufrieden und wieder andere mögen auch das nicht, sondern sie erwarten eine komplette FTP-Anmeldung mit anschließendem "QUIT" und nehmen erst danach wieder weitere FTP-Verbindungen innerhalb desselben "Boot-Zyklus" an.

Die AVM-Recovery-Versionen führen bei jedem Verbindungsaufbau die komplette Anmeldung durch (und melden sich ja auch mehrfach hintereinander bei der Box an, bei einem einzelnen Recovery-Lauf) ... daher darf man vermutlich unterstellen, daß es sich dabei um den "kompatibelsten" Weg handelt.

Die Linux-Version des Discovery-Skripts kennt aber per se gar keine FTP-Kommandos und hat den ganzen Schnickschnack für FTP auch nicht an Bord (es lohnt sich auch nicht, den da irgendwie einzubauen) ... daher ist bei dieser Version auch "HOLD=0" der Standard.

Bei der PowerShell-Version ist so ein FTP-Login dann wesentlich einfacher (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA-Discover.ps1#L118) und mit 6-10 Zeilen Code erledigt - daher ist bei dieser Version auch das Anhalten wieder die Standard-Einstellung.

Das Anhalten mit dem Linux-Skript (also "HOLD=1") wird aus diesen Gründen von mir eigentlich gar nicht empfohlen (steht in #1 in der letzten Aufzählung über dem achten CODE-Kasten) ... das funktioniert in der Art, wie es von "eva_discover" ausgeführt wird, eben nicht bei allen Modellen zuverlässig, daher sollte man gleich mit einem anderen FTP-Client, der auch ein richtiges Login beherrscht (das kann auch wieder eines meiner anderen Skripte sein) fortsetzen, anstatt auf "HOLD=1" zurückzugreifen (in #1 steht auch ein entsprechender Vorschlag für ein eigenes Skript zum Aufruf der Kommandos nacheinander).

---------------------------------------------

Das mit dem Klonen des Repos ist so eine Sache ... auf der einen Seite braucht lange nicht jeder die kompletten Verzeichnisse mit den binären Daten und auf der anderen Seite sollten natürlich die "Standardeinstellungen" am ehesten zu den häufigsten Einsatzfällen passen. Am Ende macht es für diejenigen, die tatsächlich die Binärdateien haben wollen bzw. brauchen, eher keinen Unterschied, ob sie direkt beim Klonen einen anderen Branch angeben müssen (mit "-b binaries", wie es bisher war und von mir manchmal beschrieben wurde) oder ob sie da ein "--recurse-submodules" in das "git clone"-Kommando einbauen und auch beim nachträglichen Checkout des "binaries"-Branch vs. nachträglicher Aufruf von "git submodule" sehe ich keinen allzu großen Unterschied für den Verwender.

Aber spätestens dann, wenn es mehrere (unabhängige) "Branches" mit Binärdateien gibt, funktioniert es mit den Branches eben nicht mehr (man kann nur einen Branch gleichzeitig ausgecheckt haben) und da eignen sich dann die Submodules in Git deutlich besser.

Ich habe vorhin mal alle alten Commits mit Binärdateien aus dem YourFritz-Repo entfernt (und dabei auch gleich noch ein paar aufeinanderfolgende Commits zusammengefaßt, damit wurden aus 511 Commits vorher jetzt nur noch 438) und komme damit beim "normalen" Klonen noch auf etwas weniger als 7 MB an Daten im geklonten Repository (die bei der Übertragung von Git auch noch mal komprimiert werden):
Code:
pi@raspberrypi:~ $ git clone https://github.com/PeterPawn/YourFritz.git yf
Klone nach 'yf' ...
remote: Counting objects: 2324, done.
remote: Compressing objects: 100% (365/365), done.
remote: Total 2324 (delta 403), reused 737 (delta 396), pack-reused 1561
Empfange Objekte: 100% (2324/2324), 3.46 MiB | 2.31 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1438/1438), Fertig.

pi@raspberrypi:~ $ du -hsc yf
6,7M    yf
6,7M    insgesamt

pi@raspberrypi:~ $ cd yf

pi@raspberrypi:~/yf $ git submodule update --init --remote --force bin
Submodul 'bin' (https://github.com/PeterPawn/yf_bin.git) für Pfad 'bin' in die Konfiguration eingetragen.
Klone nach '/home/pi/yf/bin' ...
Submodul-Pfad: 'bin': '62c3d702f4abb78ca026b69385715ceb407325bb' ausgecheckt

pi@raspberrypi:~/yf $ du -hsc bin
30M     bin
30M     insgesamt

pi@raspberrypi:~/yf $ git submodule update --init --remote --force first_aid/
Submodul 'first_aid' (https://github.com/PeterPawn/first_aid.git) für Pfad 'first_aid' in die Konfiguration eingetragen.
Klone nach '/home/pi/yf/first_aid' ...
Submodul-Pfad: 'first_aid': '1caf1f082eb93e5e1fb88bcf1169c70674efc992' ausgecheckt

pi@raspberrypi:~/yf $ du -hsc first_aid/
33M     first_aid/
33M     insgesamt

pi@raspberrypi:~ $ cd ..

pi@raspberrypi:~ $ du -hsc yf
107M    yf
107M    insgesamt

pi@raspberrypi:~ $ sudo rm -r yf

pi@raspberrypi:~ $ git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git yf
Klone nach 'yf' ...
remote: Counting objects: 2324, done.
remote: Compressing objects: 100% (365/365), done.
remote: Total 2324 (delta 403), reused 737 (delta 396), pack-reused 1561
Empfange Objekte: 100% (2324/2324), 3.46 MiB | 1.61 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1438/1438), Fertig.
Submodul 'bin' (https://github.com/PeterPawn/yf_bin.git) für Pfad 'bin' in die Konfiguration eingetragen.
Submodul 'first_aid' (https://github.com/PeterPawn/first_aid.git) für Pfad 'first_aid' in die Konfiguration eingetragen.
Klone nach '/home/pi/yf/bin' ...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (107/107), done.
remote: Total 128 (delta 23), reused 126 (delta 21), pack-reused 0
Empfange Objekte: 100% (128/128), 10.72 MiB | 4.78 MiB/s, Fertig.
Löse Unterschiede auf: 100% (23/23), Fertig.
Klone nach '/home/pi/yf/first_aid' ...
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 20 (delta 5), reused 20 (delta 5), pack-reused 0
Submodul-Pfad: 'bin': '62c3d702f4abb78ca026b69385715ceb407325bb' ausgecheckt
Submodul-Pfad: 'first_aid': '1caf1f082eb93e5e1fb88bcf1169c70674efc992' ausgecheckt

pi@raspberrypi:~ $ du -hsc yf
107M    yf
107M    insgesamt
Damit müssen nicht mehr alle anderen ~100 MB an unnützen Daten übertragen (auch wenn es bei der Übertragung etwas weniger ist, aber die Binärdateien sind gar nicht so gut zu komprimieren für den Git-Server) und bei sich speichern ... ich hoffe mal, daß ich damit allen Seiten irgendwie gerecht werden kann - auf das "Problem" wurde ich in einem anderen Thread aufmerksam, wobei 100 MB am Ende auch nicht sooo viel sind in der heutigen Zeit.
 
bräuchte man sehr viele Boxen mit unterschiedlichen Bootloader-Versionen
K.A. ob es von der 7412 unterschiedliche Subrevisions, Boootloaderversionen gab.
Code:
##### TITLE Version 137.06.83
##### TITLE SubVersion
##### TITLE Produkt Fritz_Box_HW209
##### TITLE Datum Thu Jan  1 01:03:22 CET 1970
##### BEGIN SECTION Support_Data Supportdata Linux fritz.box 3.10.73 #1 SMP Tue Feb 7 16:47:48 CET 2017 mips GNU/Linux Version 137.06.83
Support Data
------------
Thu Jan  1 01:03:23 CET 1970
3.10.73
HWRevision   209
HWSubRevision   1
ProductID   Fritz_Box_HW209
SerialNumber   0000000000000000
annex   B
autoload   yes
bootloaderVersion   1.2834
bootserport   tty0
cpufrequency   500000000
crash   [0]0,[1]0,[2]3b6ef3c,[3]0,4;Tue Dec 6 17:44:17 2016 GMT by crash report

firstfreeaddress   0x811FB68C
firmware_info   137.06.83
firmware_version   1und1
flashsize   nor_size=0MB sflash_size=0KB nand_size=128MB
linux_fs_start   0
maca   38:10:D5:XX:XX:0C
macb   38:10:D5:XX:XX:0D
macwlan   38:10:D5:XX:XX:0E
macwlan2   38:10:D5:XX:XX0F
macdsl   38:10:D5:XX:XX:10
memsize   0x08000000
modetty0   38400,n,8,1,hw
modetty1   38400,n,8,1,hw
mtd0   0x840000,0x3840000
mtd1   0x440000,0x840000
mtd2   0x0,0x40000
mtd3   0x40000,0x440000
mtd4   0x0,0x200000
my_ipaddress   192.168.178.1
prompt   Eva_AVM
req_fullrate_freq   250000000
sysfrequency   250000000
urlader-version   3834
usb_board_mac   38:10:D5:XX:XX:11
usb_device_id   0x0000
cut
Ich hänge meinen Kurzauszug an, um u.a. die Vergabe der MAC-Nomenklatur zu erkennen, was für den decode-Zweig interessant sein könnte.

ich hoffe mal, daß ich damit allen Seiten irgendwie gerecht werden kann
Ich persönlich muss auf den Kanaren auch mit nur "Kleinen Mobilfunktrafficraten" zurechtkommen ;) nur ist dies irgendwo eher die Ausnahme.

Btw begrüsste mich tumbleweed heute just mit 252 Updates seit Freitag/Samstag :D ... Für Update-Junkies sicherlich ein "feines Stöffchen" ;)
LG
 
252 Updates seit Freitag/Samstag
Das ist halt ein System mit "rollendem Release" ... beim "zypper dist-upgrade" habe ich innerhalb von vier Wochen auch locker mal 2.500 Pakete zu aktualisieren (und ich habe längst kein "komplettes System" installiert):
Code:
The following product is going to be upgraded:
  openSUSE Tumbleweed  20180528-0 -> 20180623-0

2627 packages to upgrade, 85 new, 23 to remove.
... aber das muß man ja nicht von Hand machen.

Aber genau das ist ja der Sinn des Ganzen, wenn man Tumbleweed verwendet ... wer nur "normale" Updates haben will und natürlich Security-Fixes, der nimmt halt eine der Leap-Versionen, wenn es openSUSE sein soll.
 
ShellInABox / Telnet Varianten für FB 7490 ?

Hallo an die Fritzbox Experten!

Ich habe mich in den letzten Wochen ziemlich intensiv durch alle möglichen Wikis und Foren gearbeitet, so dass mir mittlerweile der Kopf raucht … Dabei habe ich gelernt, dass wegen den vielen H/W-/Bootloader-/Firmware-Varianten viele Informationen entweder veraltet sind, oder für die eigene Box gar nicht gelten. Bevor ich also etwas falsch mache, kann mir hoffentlich ein Experte hier sagen, ob ich irgendwo falsch liege:

Meine Ausgangslage: FB 7490, mit o2 “Branding”, aktuelle Firmware (6.90/6.92), aber älterem Bootloader (urlader-version=2964).
Mein Ziel: Shell-Zugriff erhalten (für spätere FritzLoad-Installation). Aber alles muss reversibel sein, und ohne die “provideraddtive.tar” zu gefährden.
Mögliche Vorgehensweisen:
  1. Shell-In-A-Box (SIAB), so wie im aktuellen Thread (Post #1 in Kombination mit #3) bzw. hier beschrieben.
    (Konzept: Ein spezielles “image” via FTP Bootloader in den Hauptspeicher laden, welches die bestehende Firmware im Flash “modifiziert”; danach spätere Firmware-Updates ggf. via modfs).

  2. Freetz
    (Konzept: Neues Image mit aktiviertem Telnet von Freetz erstellen lassen, das Ergebnis via FTP Bootloader in den Hauptspeicher laden, woraufhin es sich selbst ins Flash schreibt; spätere Firmware-Updates auf gleichem Weg durchführen, ggf. auch via Web-GUI, nachdem man das Signatur-Problem gelöst hat)

  3. Downgrade auf v6.24 via FTP Bootloader upload
    (Konzept: altes AVM Image via “eva_tools/image2ram” aufbereiten, dann das Ergebnis via FTP Bootloader in den Hauptspeicher laden …; nach Telnet-Aktivierung ein Update auf aktuelle Firmware via modfs durchführen)

  4. Downgrade auf v6.24 via AVM Recovery Firmware
    (vorher “UNSETENV provider”, leider geht beim Recovery aber die “provideraddtive.tar” verloren => TFFS Backup/Restore notwendig)
Rollback der Änderungen: Einfach Original-AVM-Image einspielen.
Zusätzlich noch die Meldung “In Ihrer FRITZBox wurden vom Hersteller nicht unterstützte Änderungen durchgeführt.” wegbekommen.

Vermutlich werde ich Variante #1 ausprobieren, aber bei meiner Box sollten doch alle 4 Varianten funktionieren, oder?

Danke & VG Martin
 
Zuletzt bearbeitet:
kann mir hoffentlich ein Experte hier sagen, ob ich irgendwo falsch liege:
Ich bin vielleicht nicht "der" Experte, ABER was hat dein Problem mit dem Thema "Kennwort vergessen" zu tun?
IMO bist du hier an der völlig falschen Stelle.
 
Guten Morgen,

> ... Ich bin vielleicht nicht "der" Experte ...
Entschuldigung. Um AGG konform/PC zu sein: suche eine[n] Expertin/Externen.

> ... ABER was hat dein Problem mit dem Thema "Kennwort vergessen" zu tun?
Ich stimme zu, ist etwas verwirrend und ungünstig, deshalb aber auch der fette Titel in meinem Post. Leider gibt's m.W. keinen wirklich dedizierten Thread zum Thema "ShellInABox (Variante 03.2018 für VR9 Boxen)", wollte aber auch keinen neuen öffnen. Statt dessen gibt's nur:
  1. [INFO] modfs-Starter - "Einmal-Impfung" mit ShellInABox für VR9-Boxen
    (der Thread ist aber eigentlich seit 2016 tot und das Verfahren geht nicht mehr, und nur Post #1 enthält ein sehr knappes Update, dass aber auf diesen Thread verweist)
  2. [INFO] FRITZ!Box-Kennwort vergessen ... POST #3 (=dieser Thread):
    Hier geht's um die Anpassung des "Kennwort vergessen" Verfahrens, um SIAB zu bekommen. Zitat von PeterP.: "Ich habe eine neue Inkarnation von "modfs-Starter" auf diesem Wege zusammengebaut ..."
    Und u.a. in Post #23 geht's dann um SIAB-Probleme: "Habe laut Post #3 ein SIAB Image zusammengebaut...."
  3. Es gibt noch einige andere Posts (insbes. von PeterP.), die bzgl. ShellInABox auf den Thread hier als "Master" verweisen.
Ich kann's auch gerne irgendwo anders hin verschieben, wenn ich nur wüsste wohin ...
 
Zuletzt bearbeitet:
Meine Ausgangslage: FB 7490, mit o2 “Branding”, aktuelle Firmware (6.90/6.92), aber älterem Bootloader (urlader-version=2964).
Mein Ziel: Shell-Zugriff erhalten (für spätere FritzLoad-Installation). Aber alles muss reversibel sein, und ohne die “provideraddtive.tar” zu gefährden.
die "provideradditive.tar" kann mit einem laufenden System mit FW 06.9x problemlos per "erweiterten Supportdaten Datei" gesichert werden.
http://fritz.box/?lp=support
die "provideradditive.tar" kann mittels PeterPawns eva-tools extrahiert werden; ggf. mit telnet nach Recovery "re-implantiert" werden.

Ergänzung:
es gibt noch Variante 5 "Nutzung einer Dev-FW" https://www.ip-phone-forum.de/threads/sammelthema-für-fb-7490-mit-sonstiger-firmware-z-b-von-internen-versionen.281201/, diese kann (sofern man die FW-Datei gecurled hat) einfach per Web-IF als Update installieren und hat dann nach Reboot eingebautes SIAB; anschließend mit "modfs" das inaktive Partitionsset modden; nochmals booten; das war's;
 
Zuletzt bearbeitet:
@Shirocco88: Danke für die info.
Insbes. zur "provideradditive.tar" habe ich schon viele Stunden investiert und m.E. alle notwendigen Infos zusammen (wollte zum Backup/Restore Thema auch noch 2ten Thread erstellen). Trotzdem bevorzuge ich ein Weg, der komplett "ungefährlich" ist. Ich hatte hier auch gar nicht nach "Wie genau mache ich das und das ..." gefragt, sondern nur "Habe ich einen Denkfehler gemacht?" :)

Zur Variante 5: "Nutzung einer Dev-FW"
Hatte ich tatsächlich nicht auf dem Schirm. Ich werde mal suchen, ob ich so eine interne Entwicklerversion irgendwo finde ... Bei den Labor-Versionen gab's noch den großen Nachteil, dass ich auf "offiziellem" Weg nicht wieder davon weg komme, weil FW-Update als Downgrade nicht geht, und Firmware Recovery geht nicht bei einer "provideradditive.tar". Inoffiziell geht's natürlich schon :)
 
Ich würde (logisch) zu Variante 1 greifen ... für die letzte Release-Version (also den älteren 3.10.73-Kernel und die alte uClibc) gibt es ein fertiges Image im "first_aid"-Repository und man braucht parallel nur noch eine der Möglichkeiten, die Firmware in den Speicher der Box zu bringen. Unter Windows sind das drei Downloads (die beiden PS-Skripte + das Image) und ca. 5 Minuten. Das ändert auch die aktuell installierte Version vom Provider - wobei "o2" davon eher nichts mitkriegen würde. Die Änderung überlebt das Update auf die nächste Version nicht - das ist aber Absicht.

Beim Einsatz einer Inhouse-Version kriegt der Provider die Änderung mit (solange TR-069 aktiv bleibt), denn die Informationen im "INFORM"-Request ändern sich ebenfalls ... von der Versionsnummer bis zu möglichen Änderungen an den implementierten TR-069-Interfaces.

Die ganzen Downgrade-Varianten gehen zwar ... die Frage wäre nur, warum man sich den Aufwand (inkl. Beschaffung von alten Images, Sicherung der "provider_additive.tar", Entfernen der "provider"-Sicherung im Environment, usw.) und Verlust von Einstellungen (und nicht alles wird bekanntlich wieder importiert) überhaupt antun will, wenn man in Wirklichkeit gar nichts von dieser Firmware will.

Das wäre ja nun wirklich der denkbar komplizierteste Weg, wie man die Aufgabenstellung angehen könnte ... was natürlich nicht heißt, daß er nicht funktioniert. Nur der Sinn des Ganzen, wenn man die leichteren Wege auch kennt und verstanden hat (und die beinhalten ja eigentlich auch keine anderen Schritte, für die man zusätzliche Kenntnisse o.ä. bräuchte und die beim Downgrade dann wegfallen können, denn wenn man am Ende ein (aktuelles) System mit Shell-Zugang in der Box haben will, ist es rein mit Recovery ja noch nicht getan und man muß schon noch weitere Schritte gehen), erschließt sich mir halt nicht ... ich kann auch von Berlin erst nach Hamburg fahren, um den ICE Hamburg-München zu nehmen, aber ich muß das nicht tun.

Für ein komplettes Freetz-Image braucht es (wie für die meisten anderen Schritte, wenn man nicht auf das fertige Image und die PS-Skripte zugreift) dann das eigene Linux ... und bei einem Freetz-Image auch noch ein deutlich "umfangreicheres" Linux (und mehr Zeit), als bei Variante 1, selbst wenn man sich das eigene Image erst mit den "toolbox"-Skripten erstellen lassen müßte.

Es führen also viele Wege nach Rom ... die einen direkt, die anderen über die Seidenstraße. Das Restaurieren ist auch bei der SIAB-Variante ganz einfach ... man setzt mit dem letzten eigenen Shell-Zugriff das "tainted"-Flag in TFFS-Node 87 zurück (das würde erst bei der nächsten Anmeldung erneut gesetzt) und installiert (per Datei) einfach noch einmal dieselbe Firmware, die gerade installiert ist (das sollte sogar übers GUI problemlos funktionieren, weil nur Downgrades blockiert werden - notfalls macht man es eben über den Bootloader) und der SIAB-Zugang ist wieder verschwunden.

So ein Update ist leider notwendig, weil bei der SIAB-Installation Dateien überschrieben werden (müssen), deren Restaurierung viel zuviel Aufwand wäre (deshalb gibt es auch - anders als beim ersten "modfs-Starter" - hier keine Vorkehrungen für ein "uninstall"), weil das mit einer neuerlichen Installation der Firmware (bei der ja auch nichts anderes verloren geht, als genau diese SIAB-Installation) viel einfacher zu realisieren ist. Selbst wenn man davor vergessen hat, das "tainted"-Flag zurückzusetzen ... dann kann man das immer noch nachträglich mit einem einzelnen Start des passenden Images (dafür gibt es ein "toolbox"-Skript und für die 7490 auch wieder das fertige Image in "first_aid") löschen lassen.

Bei GRX-Boxen wird es dann halt schwieriger ... aber die VR9-Modelle mit dem YAFFS2-Dateisystem sind da sehr dankbare Patienten, weil man dessen Inhalte sehr leicht auch dauerhaft ändern kann. Bei den GRX-Boxen geht das im Prinzip auch, wenn man das SquashFS-Image ändert ... da beim Laden in den Speicher über den Bootloader der verfügbare Hauptspeicher begrenzt werden muß, braucht man (für das Packen) eigentlich wieder Swap-Space und damit den USB-Stack. Ich habe mal mit ein paar Experimenten in dieser Richtung angefangen (auch ohne Swap-Space, weil man ja eigentlich keine weiteren AVM-Dienste starten muß für solche Modifikationen) ... aber am Ende ist das auch recht umständlich.

Wenn man ohnehin so ein Image zum Modifizieren bauen muß (und das ist etwas umfangreicher als die VR9-Toolbox-Images), kann man irgendwie auch gleich die komplette Firmware nehmen und entsprechend modifizieren. Der einzige Vorteil des "umständlichen" Weges wäre es, daß man dabei auch Images erstellen und selbst verbreiten kann (wie die in "first_aid"), ohne gegen die Bestimmungen in der AVM-Lizenz zu verstoßen, solange man nur den Kernel und GPL-Programme dafür verwendet.

Leider geht es aber schon bei der Frage der LEDs dann los ... wenn man irgendwelche länger laufenden Sachen auf der Box macht (und das Einpacken eines SquashFS-Images dauert etwas), möchte man das ja auch irgendwie nach außen signalisieren ... aber schon die komplette LED-Ansteuerung macht AVM eben nicht auf den "Lantiq-Weg", wo es am Ende sogar Zugriff auf die LEDs über das "procfs" gäbe, sondern da geht man den eigenen Weg mit dem LED-LKM (was zugegebenermaßen dann auch noch einen "Stack" für die Zustände verwaltet und nach dem Wegfall einer Kondition auf den vorherigen Stand der LEDs zurückschalten kann) und das ist natürlich auch der einzige, der in dem AVM-Kernel unterstützt wird ... dessen "Nachnutzung" ist aber der Knackpunkt bei diesem gesamten Vorgehen. Wenn man sich erst noch den eigenen Kernel kompilieren muß, ist dieser Weg (wie er hier im Thread beschrieben wurde) Nonsens.

Bei den VR9-Boxen kann man sich wieder mit direktem "memory mapped I/O" für die LED-GPIO-Pins behelfen und bei der 6490 hat AVM sogar noch das GPIO-Interface unter "/sys/class/gpio" im Kernel, über das man die LEDs auch steuern kann, wenn man den richtigen Pin kennt ... aber bei den GRX-Boxen (und um die ginge es beim Packen des SquashFS-Images auf der Box ja gerade) sind die noch mal hinter einem Multiplexer versteckt und da kommt man mit den "üblichen" I/O-Möglichkeiten (z.B. über das "devmem"-Applet in der BusyBox) nicht mehr ohne weiteres ran. Mit eigenem Treiber wieder kein Problem ... heißt aber auch wieder eigener Kernel oder zumindest, daß man immer den passenden Treiber zum AVM-Kernel zusätzlich bereithalten (und zuvor natürlich erst mal erzeugen) müßte.

Alles das hat ja am Ende dazu geführt, daß ich bei GRX-Boxen die "Technik" des "modfs"-Projekts nicht fortsetzen will (irgendein Weg würde sich schon finden lassen - nur wäre der eben in meinen Augen komplizierter, als wenn man gleich außerhalb der Box das passende Image zusammenstellt) und an anderen Wegen arbeite.

-----------------------------------------------------------------------------------------------------

Der präferierte Weg ist es für mich im Moment, die Box mit einem eigenen öffentlichen Key für das Signieren von Images "zu impfen" (das geht - mit ein paar Kniffen - sogar bei den GRX-Modellen und zwar auch mit der originalen AVM-Firmware und ist der einzige Schritt, der dann tatsächlich auch den Zugriff auf den Bootloader braucht ... aber mit so fest definierten Abläufen und über alle Modelle einheitlich, daß man das tatsächlich - so wie AVM's Recovery-Programm - fix vorgeben kann und der Benutzer nicht länger "von Hand" irgendwelche Funktionen aufrufen müßte) und dann kann man auf diesem Key aufbauen und die diversen, von AVM bereits selbst vorgesehenen und genutzen Mechanismen in der originalen Firmware "nachnutzen".

Das geht dann von der Akzeptanz selbst-signierter Images beim dateibasierten Update (wo man dann ggf. wieder mit den alten Problemen der "Pseudo-Updates" zu kämpfen hat, daß vor deren Start erst mal das System weitgehend heruntergefahren wird) bis zu den DECT-Updates per USB-Stick ... denn auch wenn da ein fester Name gesucht wird (je nachdem, wofür so ein Update sein soll), kann man auch dort in der "var/install" problemlos eigene Befehle unterbringen, solange das Image nur eine Signatur hat, die von der Firmware akzeptiert wird ... und da wird nicht erst das halbe System gestoppt, bevor das "install"-Skript zur Ausführung gelangt.

Der eigentliche Knackpunkt für "Modifikationen für Dummies" ist also die Frage, wie man den eigenen öffentlichen Key in die Firmware bugsiert ... und hier ist AVM durchaus dadurch hilfreich, daß bisher halt nur RSA-Keys mit 1024 Bit verwendet werden. Deren Modulus (das ist praktisch der öffentliche Teil des Schlüssels, denn der Exponent ist fix und bei AVM immer 65537) paßt in hexadezimaler Kodierung (es ginge natürlich auch mit Base64 noch kürzer) ziemlich genau in eine Environment-Variable einer FRITZ!Box (256 Byte) und da gibt es (derzeit zumindest) noch so einige, die von AVM nicht (mehr) genutzt werden. Ein Beispiel wären die "bbn"-Einträge - hier kann man wunderbar zusätzliche öffentliche Schlüssel hinterlegen, die dann nur irgendwie von der Firmware in "richtige Dateien" überführt werden müssen, bevor man zu einer Signaturprüfung gelangt ... aber der Weg dafür, wäre eben immer derselbe (und damit einer, den man auch am Stück vorbereiten kann), während der konkrete eigene Schlüssel wieder aus dem Environment käme und man damit weiterhin "sicher" bleibt.

Dazu trägt es auch bei, daß man Environment-Einträge mit 256 Byte für den Wert tatsächlich nur über den Bootloader einrichten kann ... aus dem System heraus ist die gesamte Zeile zum Schreiben auf max. 256 Byte begrenzt und man kriegt deshalb (wegen der 4 oder 5 Zeichen für den Namen der Variablen und das erste Trennzeichen) keinen kompletten Modulus in einen solchen Wert, wenn man es aus dem laufenden FRITZ!OS heraus versucht. Ein Angreifer auf das laufende System kann also keinen eigenen Schlüssel dort eintragen ... wer an den Bootloader kommt und dort etwas anderes eintragen kann, dem steht die Box ohnehin sperrangelweit offen.

Da man diesen Key eben über den Bootloader setzen kann, gehört das auch zu den automatisierbaren Abläufen ... die exakten Einstellungen für eine spezielle Box sind auf diesem Weg von allen Skript-Inhalten und allen notwendigen Modifikationen der Firmware entkoppelt und man kann solche Änderungen und Skript-Dateien erstellen und anbieten, ohne daß sich deren Benutzer dabei automatisch ins Knie schießen, weil die Sicherheit ihrer Geräte damit aufgeweicht wird.

Was der Einzelne dann aus den Möglichkeiten, ein selbst-signiertes Image zu laden und die dort enthaltene "var/install" zur Ausführung zu bringen, macht, steht wieder auf einem anderen Blatt ... aber dieser eigene öffentliche Key, den die Firmware auch zur Prüfung heranzieht, ist am Ende für mich "der Schlüssel" für alles weitere.

Ein paar der Skripte für diesen Weg gibt es auch schon ... das Einbinden eines solchen Keys in die laufende Firmware (allerdings nicht das Auslesen aus dem Environment, weil das ja nicht die einzige Möglichkeit zur Bereitstellung eines Modulus ist und bleiben soll) ist z.B. hier realisiert (und getestet): https://github.com/PeterPawn/YourFritz/blob/master/framework/implant_public_key - dem Skript wirft man nur noch den gewünschten Weg der "Impfung" und den Modulus vor die Füße und um den Rest kümmert es sich selbst und zwar bei VR9-, GRX- und Puma-Boxen, jeweils mit "fallback", falls ein Weg nicht funktioniert aufgrund des Modells. Das Skript kann man dann wieder über NAS-Verzeichnisse auf die Box bringen ... das eigentliche Problem ist, wie man es zur (erstmaligen) Ausführung bringt und zwar auch mit der originalen AVM-Firmware.
 
gibt es wirklich eine gebrandete O2-FW ?
Es steht zwar kein "o2" in der Web-GUI, aber trotzdem ist im Env. provider=o2, und damit gibt's vermutlich auch eine "provideradditive.tar".

> was ist denn das besondere am o2 “Branding” bzw. otwo-provideradditive ?
Eigentlich scheint die o2 provideradditive total überflüssig zu sein. Aber weil ich die Box irgendwann an o2 zurückgeben muss, könnte eine fehlende provideradditive Probleme machen ...

> aktuell ist doch die FW 06.93 für die FB7490
Hatte erst vor kurzem die automatischen Updates abgeschaltet, keine Ahnung warum meine FB die 6.93 bei mir noch nicht installiert hatte ... Mir ging es auch hauptsächlich um die Größenordnung der Version (also z.B. nur signierte FW via Web, aber im Bootloader könnte ich "provider=o2" rauslöschen).
 
Zuletzt bearbeitet:
Aber weil ich die Box irgendwann an o2 zurückgeben muss, könnte eine fehlende provideradditive Probleme machen ...
das wird sie...
aber trotzdem ist im Env. provider=o2
provider=o2 ? Sicher? Wie sieht denn der Auszaug aus den Supportdaten bzw direkt aus dem Bootloader (quote GETENV provider) aus?

Mit erweiterteten Supportdaten und Peters tffs... scripts sollte es möglich sein, diese Additive zu sichern und anschließend wiederherstellen zu können.
 
@PeterPawn : Vielen Dank für die ausführliche Antwort.
Aus meiner Sicht ist erstmal alles geklärt :)

Ich würde (logisch) zu Variante 1 greifen ...
Sehe ich inzwischen auch so.
Habe auch "first_aid/implant_siab.image.7490" gefunden :)
FTP Zugriff ist kein Problem, und auch beim Rest sehe ich keine prinzipiellen Schwierigkeiten.

> Beim Einsatz einer Inhouse-Version kriegt der Provider die Änderung mit (solange TR-069 aktiv bleibt)
Danke für den Hinweis, wieder etwas gelernt :) Werde wohl schauen, TR-069 vorsichtshalber zu deaktivieren.

> Für ein komplettes Freetz-Image braucht es ... ein deutlich "umfangreicheres" Linux (und mehr Zeit).
Habe für FTP ein Mint-Linux verwendet, aber für Freetz hätte ich die fertige Freetz-VM benutzt. Angefangen hätte ich wohl mit Freetz/fwmod im "no freetz"-Modus (und "restore telnet support" in fwmod_custom). Stimme aber zu, dass Freetz für meine Zwecke ein Overkill ist, und lasse erstmal meine Finger davon ...

> Verlust von Einstellungen (und nicht alles wird bekanntlich wieder importiert)
Evtl. reden wir aneinander vorbei. Mein geplanter Weg war, ein "TFFS Backup" via Erweiterte-Support-Daten zu erstellen, daraus dann ein Image via “tffs/tffs_add_file” erzeugen, und dieses via Bootloader FTP upload direkt ins NOR Flash (mtd3/4) schreiben.
Hatte bisher nur etwas von SSL Zertifikaten gelesen, die verloren gehen (aus welchem Grund auch immer, vielleicht stehen die direkt in /var/flash/) .
Mir ist aber ehrlich gesagt auch noch unklar, wer überhaupt das "mknod /var/flash/provideradditive.tar c MAJOR MINOR" ausführt, damit speziell diese Datei im Filesystem erscheint (falls ein Standard Firmware Recovery das "/var/flash/" Filesystem ohne provideradditive.tar erzeugt hat).
Ist hier aber alles Off-Topic, und plane dazu einen extra Thread.
 
provider=o2 ? Sicher?

Ja, bin mir sicher:
ftp> quote GETENV provider
provider: o2

Wegen dem Wert lief ja das FW Recovery Programm nicht durch ...

SIAB hat funktioniert, kann mir jetzt auch meine provideradditive direkt anschauen:
Code:
# tar tf /var/flash/provideradditive.tar
provider_additive/            
provider_additive/voip.cfg    
provider_additive/tr069.cfg   
provider_additive/startinfo.txt
provider_additive/desc.txt    
provider_additive/ar7.cfg

//edit by stoney: [CODE] TAG [/CODE] eingefügt
 
Zuletzt bearbeitet von einem Moderator:
Ich habe die hier beschriebenen Skript-Files erneuert: https://www.ip-phone-forum.de/threa...ierte-fritz-boxen.273304/page-76#post-2297067

Wer damit auf der Basis eines 07.0x-Images von AVM ein eigenes Image erstellen will, muß mittels "kernel_version=3.10.107" direkt in derselben Zeile vor dem Aufruf eines Skripts signalisieren, daß er ein solches Image zu verwenden gedenkt. Die automatische Erkennung habe ich nur in das "build_shellinabox_implant_image" eingebaut, weil das bisher auch als einziges Binärdateien dauerhaft in einem fremden System verankert.
 
Code:
vidar:/tmp # git clone -b binaries https://github.com/PeterPawn/YourFritz yf
Cloning into 'yf'...
remote: Counting objects: 2555, done.
remote: Compressing objects: 100% (73/73), done.
remote: Total 2555 (delta 41), reused 83 (delta 30), pack-reused 2449
Receiving objects: 100% (2555/2555), 27.73 MiB | 5.02 MiB/s, done.
Resolving deltas: 100% (1516/1516), done.
vidar:/tmp # cd yf/juis
vidar:/tmp/yf/juis # juis_check 192.168.178.65 ===> meine (für diese Demo benutzte) 7412 hat diese Adresse als IP-Client
root/bin/juis_check: No newer version found, check was made with source version '137.06.83-43527'.
vidar:/tmp/yf/juis # juis_check 192.168.178.65 Version=137.06.00-00000
root/bin/juis_check: Found newer version: 137.06.83
URL=http://ftp.avm.de/archive/fritz.box/fritzbox.7412/firmware/deutsch/FRITZ.Box_7412.137.06.83.image
DelayDownload=3385
vidar:/tmp/yf/juis # cd ../toolbox/
vidar:/tmp/yf/toolbox # wget -q http://ftp.avm.de/archive/fritz.box/fritzbox.7412/firmware/deutsch/FRITZ.Box_7412.137.06.83.image
vidar:/tmp/yf/toolbox # TOOLBOX_IMAGE_SIZE=3 ./build_shellinabox_implant_image FRITZ.Box_7412.137.06.83.image > SIAB-7412.image
vidar:/tmp/yf/toolbox # ls SIAB-7412.image
SIAB-7412.image
vidar:/tmp/yf/toolbox #
vidar:/tmp/yf/toolbox # cd ../eva_tools/
vidar:/tmp/yf/eva_tools # eval $(./eva_discover INTERFACE=vlan10 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1);[ $EVA_FOUND -eq 1 ] && ./eva_to_memory ../toolbox/SIAB-7412.image
Found AVM bootloader: AVM EVA Version 1.2605 0x0 0x47409
Found hardware revision: 209
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0x563e00 (5 MB)
Setting temporary memory size to: 0x07a9c200
Setting temporary kernel args to: mtdram1=0x87a9c200,0x88000000
Image uploaded to device.
vidar:/tmp/yf/eva_tools #

Hallo PeterPawn,

danke für Deine Arbeit und Deine Mühe!
Ich habe versucht obiger Anleitung zu folgen und habe auch herausgefunden, dass sich das Auschecken ein wenig geändert hat und dass man das Script als root ausführen muss (habe es im Script selbst erst entdeckt, nachdem ich es viele bereits Male als normaler user probiert hatte), aber leider bleibe ich an der Stelle mit der Image-Erzeugung stecken. Das Image file wird zwar angelegt, aber es ist wird nichts hinein geschrieben, die Datei bleibt 0 Byte groß. Der Befehl zum erzeugen des Images gibt keine Rückmeldung und beendet sich auch nicht. Ich habe mal einen screenshot davon gemacht.

Vielen Dank im voraus.

Viele Grüße aus der Türkei
Sash
 

Anhänge

  • yf.png
    yf.png
    130.1 KB · Aufrufe: 17
Dann rufe das Skript mal nicht nur mit dem Namen, sondern mit "TOOLBOX_IMAGE_SIZE=3 bash -x build_shellinabox_implant_image -d ..." auf ... dann sollte man zumindest sehen, wo es hängenbleibt.

Die gesamte Konsolenausgabe ist dann wichtig und zwar bitte als Text (in einer CODE-Box oder als Anhang) und nicht als Screenshot; das paßt dann ohnehin nicht in einen einzelnen hinein und n Bilder anzustarren, ist auch nicht so lustig.

Ich habe nämlich selbst vor weniger als 24 Stunden erst dieses Image neu erstellt: https://github.com/PeterPawn/first_aid/blob/master/implant_siab_3.10.107.image.7490 und hatte dabei dieses Problem nicht.
 
Danke für die schnelle Antwort.

Code:
root@Asus-N76VZ:/tmp/yf/toolbox# TOOLBOX_IMAGE_SIZE=3 bash -x build_shellinabox_implant_image -d FRITZ.Box_7490.113.07.01.image > SIAB-7490.image
+ tmpdir=/tmp                                                                                                                                                                                                                                                             
+ kernel_version=3.10.73                                                                                                                                                                                                                                                   
+ eval 'binaries=../bin/mips/$kernel_version'                                                                                                                                                                                                                             
++ binaries=../bin/mips/3.10.73                                                                                                                                                                                                                                           
+ image_get_file=image/get_file_from_image                                                                                                                                                                                                                                 
+ payload_script_1=scripts/copy_payload                                                                                                                                                                                                                                   
+ payload_script_2=scripts/rc.shellinaboxd                                                                                                                                                                                                                                 
+ payload_script_2_target=etc/init.d                                                                                                                                                                                                                                       
+ payload_script_3=scripts/add_startup_script                                                                                                                                                                                                                             
+ payload_script_3_target=sbin                                                                                                                                                                                                                                             
+ payload_bin_1=../bin/mips/3.10.73/shellinaboxd                                                                                                                                                                                                                           
+ payload_bin_1_target=sbin                                                                                                                                                                                                                                               
+ toolbox_scripts='image/get_file_from_image scripts/copy_payload ../bin/mips/3.10.73/shellinaboxd'                                                                                                                                                                       
++ cat                                                                                                                                                                                                                                                                     
+ create_inodes='d /bin 700 0 0
d /dev 700 0 0
d /etc 700 0 0
d /lib 700 0 0
d /proc 700 0 0
d /sbin 700 0 0
d /tmp 700 0 0
d /var 700 0 0
d /var/log 700 0 0
d /var/run 700 0 0
d /var/lock 700 0 0
f /tmp/mtab 700 0 0
f /etc/inittab 700 0 0
l /etc/mtab /tmp/mtab
c /dev/console 666 0 0 5 1
c /dev/zero 666 0 0 1 5
c /dev/null 666 0 0 1 3
l /dev/log /tmp/log
b /dev/loop0 666 0 0 7 0
b /dev/loop1 666 0 0 7 1
b /dev/loop2 666 0 0 7 2
b /dev/loop3 666 0 0 7 3
c /dev/random 666 0 0 1 8
c /dev/urandom 666 0 0 1 9
c /dev/ttyS0 555 0 0 4 64
d /payload 700 0 0
d /target 700 0 0'
+ busybox_source=../bin/mips/3.10.73/busybox
++ cat
+ busybox_applets='bin/ash
bin/cat
bin/chgrp
bin/chmod
bin/chown
bin/cp
bin/date
bin/dd
bin/df
bin/echo
bin/egrep
bin/false
bin/fgrep
bin/getopt
bin/grep
bin/gunzip
bin/gzip
bin/hostname
bin/kill
bin/ln
bin/login
bin/ls
bin/mkdir
bin/mknod
bin/mount
bin/mv
bin/nice
bin/pidof
bin/ping
bin/ps
bin/pwd
bin/rm
bin/rmdir
bin/sed
bin/sh
bin/sleep
bin/stat
bin/sync
bin/tar
bin/touch
bin/true
bin/umount
bin/vi
bin/zcat
sbin/halt
sbin/ifconfig
sbin/ifdown
sbin/ifup
sbin/init
sbin/insmod
sbin/lsmod
sbin/modprobe
sbin/pivot_root
sbin/poweroff
sbin/reboot
sbin/rmmod
sbin/route
sbin/swapoff
sbin/swapon
sbin/sysctl'
+ '[' -d = -d -o -d = --debug ']'
+ debug=1
+ dbgopt=-d
+ shift
+ '[' -t 1 ']'
+ for f in '$toolbox_scripts'
+ '[' -r image/get_file_from_image ']'
+ for f in '$toolbox_scripts'
+ '[' -r scripts/copy_payload ']'
+ for f in '$toolbox_scripts'
+ '[' -r ../bin/mips/3.10.73/shellinaboxd ']'
+ '[' -z FRITZ.Box_7490.113.07.01.image ']'
+ src=FRITZ.Box_7490.113.07.01.image
+ shift
+ known_substitutions='LOGIN SHELL HOMEDIR PORT'
+ '[' 0 -gt 0 ']'
+ CFG_LOGIN=/sbin/ar7login
+ CFG_SHELL=/bin/sh
+ CFG_HOMEDIR=/var/home
+ CFG_PORT=8010
+ substitute='LOGIN=/sbin/ar7login SHELL=/bin/sh HOMEDIR=/var/home PORT=8010'
+ '[' -d /tmp ']'
+ name=/tmp/12447_build_siab
+ rm -r /tmp/12447_build_siab
+ mkdir /tmp/12447_build_siab
+ '[' -d /tmp/12447_build_siab ']'
+ trap 'housekeeping $name' HUP EXIT INT
++ /bin/bash image/get_file_from_image -d FRITZ.Box_7490.113.07.01.image chksum
++ strings
++ sed -n -e 's|.*Buildroot \([0-9]*\).*|\1|p'
+ buildroot_year=2016
+ '[' -z 2016 ']'
+ '[' 2016 -lt 2016 ']'
+ '[' 1 -eq 1 ']'
+ printf 'Using binaries for systems with kernel version 3.10.107.\n'
Using binaries for systems with kernel version 3.10.107.
+ kernel_version=3.10.107
+ eval 'binaries=../bin/mips/$kernel_version'
++ binaries=../bin/mips/3.10.107
+ payload_bin_1=../bin/mips/3.10.107/shellinaboxd
+ toolbox_scripts='image/get_file_from_image scripts/copy_payload ../bin/mips/3.10.107/shellinaboxd'
+ busybox_source=../bin/mips/3.10.107/busybox
+ for f in '$toolbox_scripts'
+ '[' -r image/get_file_from_image ']'
+ for f in '$toolbox_scripts'
+ '[' -r scripts/copy_payload ']'
+ for f in '$toolbox_scripts'
+ '[' -r ../bin/mips/3.10.107/shellinaboxd ']'
+ /bin/bash image/get_file_from_image -d FRITZ.Box_7490.113.07.01.image kernel.image
A TI checksum signature was found on './var/tmp/kernel.image', file will be truncated by 8 byte.
++ stat -c %s /tmp/12447_build_siab/kernel
+ size=2709504
+ '[' 0 -ne 0 ']'
+ /bin/bash image/get_file_from_image -d -k FRITZ.Box_7490.113.07.01.image filesystem.image
+ dd bs=256 count=1
++ stat -c %s /tmp/12447_build_siab/header
+ size=256
+ '[' 256 -ne 256 ']'
+ printf sqsh
+ dd if=/dev/zero bs=4 count=63
++ stat -c %s /tmp/12447_build_siab/dummy_header
+ size=256
+ '[' 256 -ne 256 ']'
+ cmp /tmp/12447_build_siab/header /tmp/12447_build_siab/dummy_header
+ dd if=/dev/zero of=/tmp/12447_build_siab/ext2_image bs=1024 count=3072
+ mkfs -t ext2 /tmp/12447_build_siab/ext2_image

^C++ housekeeping /tmp/12447_build_siab
++ grep -q /tmp/12447_build_siab /proc/mounts
++ losetup -a
++ grep -q /tmp/12447_build_siab
++ rm -r /tmp/12447_build_siab
+ '[' 1 -eq 1 ']'
+ printf 'Error making ext2 filesystem structures on new filesystem image.\n'
Error making ext2 filesystem structures on new filesystem image.
+ exit 1
+ housekeeping /tmp/12447_build_siab
+ grep -q /tmp/12447_build_siab /proc/mounts
+ losetup -a
+ grep -q /tmp/12447_build_siab
+ rm -r /tmp/12447_build_siab
 
Zuletzt bearbeitet:
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.