FBEditor

[NDiIPP]

... und die Checksumme wurde Angepasst und sollte mit viel Glück auch mit der Frimware 7.20 gehen, kann es selbst nicht Testen da ich keine Aktuelle Box mit der Firmware habe, Sorry.

Werde ich heute Abend mal schauen, ob die richtige Checksumme erstellt wird (Peters Tool erstellt jedenfalls schon einmal eine passende Checksumme, sollte also dann damit übereinstimmen). Wenn es nicht geht, könnte ich dir bei Bedarf eine export (einer auf Werkseinstellungen zurückgesetzten) 7590 zur Verfügung stellen.

--- Zusammengeführt ---

Habe eben mal für eine (veränderte) Export-Datei einer 7590 mit FRITZ!OS 7.20 die CRC32 Checksumme per Decoder von @PeterPawn berechnen lassen:

**** END OF EXPORT 0A51C693 ****

Und anschließend vom aktuellen FBEditor 0.6.9.7i:

**** END OF EXPORT A51C693 ****

Ich befürchte, das passt also noch nicht so ganz...

Edit:
Die vorhergehende Ver. 0.6.9.7h berechnet folgende Prüfsumme (welche bei FRITZ!OS 7.20 natürlich auch falsch ist):

**** END OF EXPORT 43B3AE63 ****

 

[Pikachu]

Sorry, da hast du wohl einen Zufallstreffer, habe es jetzt mal versucht, aber mir wurde auch beim
hundertsten Lesen der Konfig von der Box die Checksumme immer 8 Stellig Angezeigt auch mit führender null.

FritzBox 7430 Firmware Version 146.06.26

 

[NDiIPP]

In der originalen (unveränderten) Export ist diese auch bei mir 8-stellig (EDC3DED4). Und bei der marginal veränderten (0A51C693) macht Peters Decoder und auch das Tool von M. Engelke ebenfalls eine 8-stellige Prüfsumme daraus (die stimmt). Nur die FBEditor-Ver. 0.6.9.7i macht daraus eine 7-stellige (falsche).

Habe die marginal veränderte Export-Datei noch an einem weiteren Punkt verändert (und die vorhandenen Änderungen belassen um diese als Ursache auszuschließen) und schon macht auch der FBEditor 0.6.9.7i wieder eine 8-stellige daraus (DB2D2D67), die sogar mit der vom Decoder berechneten übereinstimmt. So etwas sollte doch eigentlich nicht passieren, oder?

---

Edit:
Laut FBEditor Log hatte dieser bei der problematischen Export-Datei die Checksumme "0A51C693" berechnet und beim abspeichern der Datei wird offensichtlich die führende 0 entfernt. Ist mir zugegebenermaßen auch jetzt erst aufgefallen, dass das die gleiche Checksumme ist und lediglich die führende 0 fehlt. Irgendwie hatte da mein Gehirn bei "A" als erstem Zeichen den Vergleich mit den restl. Zeichen bereits "abgebrochen" (da != 0)...

 

[Pikachu]

Nein das sollte nicht Passieren, aber wie kann ich das verhindern ?
Den Zufall den du hast, da müste ich diese Datei schon haben, aber wenn damit bei mir
der Fehler nicht auftritt dann könnte ich das Fehlverhalten auch nicht Fixen Sorry.

Aber mal eine andere Frage mit welcher Java Version wurde der FBEditor benutzt, ich hatte zum Testen nur Java 8.

PS: Meine E-Mail müsstest du auf Github finden, Gruß Erwin

 

[NDiIPP]

Wie gesagt, mir war gar nicht aufgefallen, dass da lediglich die führende 0 fehlte (siehe mein Edit oben). Weiß gar nicht, ob die Box die Prüfsumme so akzeptieren würde (probiere ich aber gleich mal). Die problematische Export kannst du dennoch gerne bekommen (habe deine Mail-Adresse jetzt nicht auf Anhieb gefunden, kannst aber auch per PN mit mir in Kontakt treten und darüber einen DL-Link erhalten) denn das ist eine "neutralisierte", frisch erstellt nach dem Laden der Werkseinstellungen (sollte also unproblematisch sein).

Aber mal eine andere Frage mit welcher Java Version wurde der FBEditor benutzt, ich hatte zum Testen nur Java 8.

OpenJDK Runtime Environment (build 1.8.0_262-b10), aka JDK 8, auf einem x86_64 Arch-Linux System mit Kernel 5.7.9.

---

Edit:

(probiere ich aber gleich mal)

Gerade probiert, die Box akzeptiert die Datei auch ohne führende 0 bei der Checksumme (meine Test-Änderungen waren nach einem Neustart auch definitiv übernommen). Daher kann man das wohl auch so lassen.

 

[elg33180]

Dumme Frage:

Hier wird von einer Checksumme geredet.

Wenn das eine Summe ist, arithmetisch berechnet, warum soll eine führende Null eine bedeutung haben ....

 

[NDiIPP]

Einerseits zwar richtig aber FRITZ!OS hätte sich beim Import ggf. dennoch daran stören können (da Bedingung 8-stellig nicht erfüllt, das wird aber offensichtlich nicht überprüft), auch wenn es mathematisch keine Bedeutung hat. Die Fritzbox speichert auch beim Export im Falle einer 7-stelligen Checksumme mit führender 0 und somit 8-stellig ab (wie mir mittlerweile von einem dritten mitgeteilt wurde, der schon ein paar mal den Zufall beim Export hatte) und somit wäre es ein Zeichen, dass die Prüfsumme nicht von der Fritzbox erstellt und somit verändert wurde.

 

[PeterPawn]

Zumal es auch nicht so ganz ungewöhnlich ist, wenn es Probleme mit Hexadezimalwerten mit einer " odd number of digits" gibt. Denn um das dann korrekt in einen Dezimal- oder Binärwert zu überführen aus der hier verwendeten Darstellung als Zeichenkette, muß man ja entweder die Konvertierung von rechts nach links ausführen oder vorher mit Null auf eine gerade Anzahl von Ziffern auffüllen. Beides ist zusätzlicher (Programmier-)Aufwand und wenn die Konvertierung sich nicht auf Zahlen beschränkt (mit bekannter Anzahl von Bits), sondern beliebige Speicherinhalte als "Stream" verarbeiten kann (z.B. die Hex-Kodierung, die AVM bisher für binäre Inhalte nutzte bei BINFILE), dann braucht es auch eine gerade Anzahl von hexadezimalen Ziffern.
EDIT: Bei bekannter Größe des Zielwertes kann man auch bei ungerader Anzahl von links nach rechts konvertieren, wenn man bei jeder Stelle um vier Bit nach links verschiebt (also mit 16 multipliziert}, das erfordert aber eben das Wissen, wo der Überlauf stattfinden würde.

 

[Pikachu]

Laut FBEditor Log hatte dieser bei der problematischen Export-Datei die Checksumme "0A51C693" berechnet und beim abspeichern der Datei wird offensichtlich die führende 0 entfernt.

Na, das Wundert mich jetzt im Log richtig sonst nicht, würde das selbst gerne mal mit Eclipse 4 Testen,
wo der der Feher in deiner Datei begraben ist, meine E-Mail müsstest du auf Github unter dem Pikachu Bildchen finden, kannst es gezipt per E-Mail Anhang schicken Danke.

PS: Meine E-Mail müsstest du auf Github finden, Gruß Erwin

 

[NDiIPP]

Hier mal das Log dazu (geladen wurde die bearbeitete Export, die noch die falsche (ursprüngliche) Checksumme enthielt):

OS: linux
Properties Set using default values
position_top: 205
position_left: 1044
position_height: 480
position_width: 680
importPropertiesDefaultValue:
(25.07.20 13:58:49): OS Language: de
(25.07.20 13:58:49): OS Country: DE
(25.07.20 13:58:49): Selected language: de_DE
(25.07.20 13:58:49): Selected language setting manuell: no
(25.07.20 13:58:49): INFO: Loading locale: de_DE
(25.07.20 13:58:49): Java version: 1.8.0_262
Font: Consolas
LoginLua: true
(25.07.20 13:58:51): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://fritz.box/login_sid.lua
(25.07.20 13:58:51): DEBUG: HttpURLConnection postdata: sid=0000000000000000
(25.07.20 13:58:51): DEBUG: HttpURLConnection getResponseCode: 200
(25.07.20 13:58:51): DEBUG: HttpURLConnection getContentType: text/xml
(25.07.20 13:58:51): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://fritz.box/login_sid.lua
(25.07.20 13:58:51): DEBUG: HttpURLConnection postdata: page=/login_sid.lua&response=a1234567-b123456789012345678901234567890c&username=
(25.07.20 13:58:52): DEBUG: HttpURLConnection getResponseCode: 200
(25.07.20 13:58:52): DEBUG: HttpURLConnection getContentType: text/xml
(25.07.20 13:58:52): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://fritz.box/cgi-bin/system_status
(25.07.20 13:58:52): DEBUG: HttpURLConnection postdata:
(25.07.20 13:58:52): DEBUG: HttpURLConnection getResponseCode: 200
(25.07.20 13:58:52): DEBUG: HttpURLConnection getContentType: text/html; charset=iso-8859-1
(25.07.20 13:58:52): DEBUG: HttpURLConnection encoding: iso-8859-1 -> iso-8859-1
(25.07.20 13:59:17): DEBUG: **** FRITZ!Box 7590 CONFIGURATION EXPORT
(25.07.20 13:59:17): DEBUG: **** CFGFILE:ar7.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:wlan.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:voip.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:usb.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:tr069.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:fx_cg
(25.07.20 13:59:17): DEBUG: **** B64FILE:fx_conf
(25.07.20 13:59:17): DEBUG: **** B64FILE:fx_def
(25.07.20 13:59:17): DEBUG: **** B64FILE:fx_lcr
(25.07.20 13:59:17): DEBUG: **** B64FILE:telefon_misc
(25.07.20 13:59:17): DEBUG: **** B64FILE:phonebook
(25.07.20 13:59:17): DEBUG: **** B64FILE:calllog
(25.07.20 13:59:17): DEBUG: **** B64FILE:dect_misc
(25.07.20 13:59:17): DEBUG: **** B64FILE:fonctrl
(25.07.20 13:59:17): DEBUG: **** B64FILE:dect_eeprom
(25.07.20 13:59:17): DEBUG: **** B64FILE:dmgr_handset_user
(25.07.20 13:59:17): DEBUG: **** B64FILE:tamconf
(25.07.20 13:59:17): DEBUG: **** CFGFILE:vpn.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:user.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:umts.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:configd
(25.07.20 13:59:17): DEBUG: **** CFGFILE:ahausr.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:aha.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:ahadect.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:ahanet.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:ahaglobal.cfg
(25.07.20 13:59:17): DEBUG: **** B64FILE:ahapushmail.cfg
(25.07.20 13:59:17): DEBUG: **** CFGFILE:avmnexus.cfg
(25.07.20 13:59:17): DEBUG: **** END OF EXPORT EDC3DED4 ****
(25.07.20 13:59:17): DEBUG: CHECKSUM FIXED: 0A51C693(old: EDC3DED4)

Das Ende dieser Datei sieht dann folgendermaßen aus:

[...]
**** END OF FILE ****
**** END OF EXPORT A51C693 ****

Interessant auch, wenn man diese Datei erneut mit dem FBEditor öffnet, dann erkennt er eine falsche Checksumme und erstellt eine neue Checksumme (mit führender 0) und schreibt diese Datei dann aber wieder ohne 0 bei der Checksumme:

[...]
(25.07.20 14:00:00): DEBUG: **** END OF EXPORT A51C693 ****
(25.07.20 14:00:00): DEBUG: CHECKSUM FIXED: 0A51C693(old: A51C693 )

Dateiende dann s.o.

Lädt man die gleiche Export aber bei der Checksumme mit führender 0, dann stellt der FBEditor (korrekterweise) fest, dass diese bereits stimmt und ändert sie nicht (speichert die Datei auch unverändert mit führender 0 ab):

[...]
(25.07.20 14:00:29): DEBUG: **** END OF EXPORT 0A51C693 ****
(25.07.20 14:00:29): DEBUG: CHECKSUM OK: 0A51C693

Dateiende dann also so:

[...]
**** END OF FILE ****
**** END OF EXPORT 0A51C693 ****

Die entsprechende Export-Datei habe ich dir soeben per Mail zukommen lassen.

 

[Pikachu]

Danke, habe es hier per Anhang im FBEditor Version 0.6.9.7j gefixt,
es ist kein Fehler deiner Datei eher ein Fehler von Java.

Datei: FBEditor-0.6.9.7j.jar
Datum: 26.07.2020 14:57:50
Größe: 555.163 Bytes (542 KB, 0,53 MB)

md5: b28e3c9a7b1ec2605d91e279979e1a3d

Datei: FBEditor-0.6.9.7j.zip
Datum: 26.07.2020 15:05:41
Größe: 516.905 Bytes (505 KB, 0,49 MB)

md5: 6d4d267662b88bef9aa516dc45c6cf79

PS: Lang It geändert Update Italian language by bovirus Italien (wahr heute hoffentlich die letzte korrektur von bovirus)

Download: FBEditor Version 0.6.9.7k

 

[Pikachu]

Ich sehe, dass es die Datei speichern kann, aber ich weiß nicht mit welchem Passwort.
Im FB-Editor kann ich das Menü für das Sicherungskennwort sehen, aber wenn ich darauf klicke, passiert nichts.
Alessio

@Alessio71

Das ist hier: Download hier in der FBEditor Version 0.6.9.7.j
mittlerweile gefixt worden wenn du es noch brauchst.

Gruß Erwin

PS: Wenn man eine mit Kennwort gesicherte Datei hat, dann muss man das Kennwort
im FBEditor eingeben sofern man die Konfiguration im FBEditor zurückspielt, sonst klappt es nicht.
Wenn man die geänderte Datei aber nur mit neuer Checksumme abspeichert braucht man das Kennwort nicht angeben.

 

[NDiIPP]

In dem Zusammenhang mal ein kleiner Feature-Request:

Der FBEditor scheint beim Starten immer zu versuchen sich mit der Fritzbox zu verbinden um die Konfiguration auszulesen. Wäre nicht schlecht, wenn man das abschalten könnte. Denn wenn ich ihn mal nutzen sollte, dann eigentlich nur indem ich die entsprechende Export manuell über 'Datei > Öffnen' bzw. Strg+O lade. Da stören dann die erfolglosen Verbindungsversuche welche, 2 Dialogfelder ("Beim Einlesen der Daten ist ein Fehler aufgetreten!" + "Fritz!Box wurde nicht gefunden, Bitte die Einstellungen prüfen.") hervorrufen die erst weggeklickt werden müssen.

--- Zusammengeführt ---

Und BTW:
Welchen Sinn/Aufgabe hat eigentlich die Option "Kennwort Sicherungsdatei"? Er stellt (laut Log) zwar fest, dass das eingegeben Passwort stimmt, aber entschlüsselt werden die verschlüsselten Daten weder bei der Anzeige im FBEditor noch beim abspeichern der Export.

 

[Pikachu]

In dem Zusammenhang mal ein kleiner Feature-Request:

Der FBEditor scheint beim Starten immer zu versuchen sich mit der Fritzbox zu verbinden um die Konfiguration auszulesen. Wäre nicht schlecht, wenn man das abschalten könnte.

Dann nim mal denn Haken raus im Menü Einstellungen Konfiguration automatisch einlesen

Da stören dann die erfolglosen Verbindungsversuche welche, 2 Dialogfelder ("Beim Einlesen der Daten ist ein Fehler aufgetreten!" + "Fritz!Box wurde nicht gefunden, Bitte die Einstellungen prüfen.") hervorrufen die erst weggeklickt werden müssen.

Diesen Netzwerk Fehler konnte ich bis heute nicht lösen, er kommt zum Glück nicht so oft vor.

--- Zusammengeführt ---

Welchen Sinn/Aufgabe hat eigentlich die Option "Kennwort Sicherungsdatei"? Er stellt (laut Log) zwar fest, dass das eingegeben Passwort stimmt, aber entschlüsselt werden die verschlüsselten Daten weder bei der Anzeige im FBEditor noch beim abspeichern der Export.

Der FBEditor enschlüsselt und verschlüsselt nichts weil das die Box beim Lesen oder Zurückspielen selbst macht,
und das Kennwort braucht man wenn man eine mit Kennwort gesicherte Datei benötigt,
wie zum Beispiel bei den Aktuellen Firmwareversionen.

 

[NDiIPP]

Dann nim mal denn Haken raus im Menü Einstellungen Konfiguration automatisch einlesen

Der ist raus. Siehe auch "readOnStartup" in der "FBEditor.properties.xml":

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
    <comment>Properties for FBEditor</comment>
    <entry key="program.start.dialog">false</entry>
    <entry key="readOnStartup">false</entry>
    <entry key="position.left">128</entry>
    <entry key="position.top">64</entry>
    <entry key="position.width">1024</entry>
    <entry key="position.height">640</entry>
    <entry key="language">de_DE</entry>
    <entry key="language.setting.manuell">no</entry>
    <entry key="NoChecks">false</entry>
    <entry key="box.ConfigImExPwd"/>
    <entry key="box.login.lua">true</entry>
    <entry key="box.address">fritz.box</entry>
    <entry key="box.username"/>
    <entry key="box.password">121-203-238-10-54-180-181-42</entry>
</properties>

---

und das Kennwort braucht man wenn man eine mit Kennwort gesicherte Datei benötigt,
wie zum Beispiel bei den Aktuellen Firmwareversion.

Verstehe ich noch nicht. Ich brauchte das noch nie beim FBEditor um eine neue Checksumme berechnen zu lassen, habe da auch bei aktuellen Boxen und Firmware-Versionen nie das Passwort der Export eingetragen. Erst vorhin mal, weil ich das testen wollte. Zum berechnen der korrekten Checksumme wird das Passwort der Export-Datei jedenfalls nicht benötigt.

Edit:
Ach jetzt verstehe ich erst! Das ist wohl nur dafür da, dass das Auslesen/Erstellen (und den anschließenden Import) der Export-Datei über den FB-Editor funktioniert (da ja neue FRITZ!OS-Versionen dort ein Passwort verlangen). Zu beachten ist da wohl ggf. auch, dass aktuelle FRITZ!OS-Versionen dort ebenfalls eine gewisse "Passwortstärke" voraussetzen (prüft das eigentlich der FBEditor?).

Der FBEditor enschlüsselt und verschlüsselt nichts weil das die Box beim Lesen oder Zurückspielen selbst macht,

Schade. Decoder von @PeterPawn kann das (und berechnet dabei mit der Option "-c" auch gleich eine neue Prüfsumme)...

 

[Pikachu]

Der ist raus. Siehe auch "readOnStartup" in der "FBEditor.properties.xml":

Na ja verstehe ich jetzt nicht könnte eventuell auch daran liegen hier:
<entry key="box.address">fritz.box</entry>
anstelle der Direkten IP
<entry key="box.address">192.168.178.99</entry>

Der FBEditor baut beim starten eine Verbindung zur Fritzbox auf sofern die IP und Passwort eingegeben ist, wenn man das nicht möchte IP und Passwort Löschen.

Wie schon erwähnt ist es wohl ein Netzwerk Fehler der FBEditor ist schneller als die Verbindung aufgebaut werden kann deshalb kommt es wohl ab und zu zur Fehler Meldung, Sorry.

Zu beachten ist da wohl ggf. auch, dass aktuelle FRITZ!OS-Versionen dort ebenfalls eine gewisse "Passwortstärke" voraussetzen (prüft das eigentlich der FBEditor?).

Nein

Schade. Decoder von @PeterPawn kann das (und berechnet dabei mit der Option "-c" auch gleich eine neue Prüfsumme)...

Für so einen hack wahr der FBEditor nicht vorgesehen aber wenn Peter das umsetzen will ich halte in nicht davon ab, Sorry.

PS: FBEditor Versione 0.7.2.1j

 

[NDiIPP]

Mit

    <entry key="readOnStartup">false</entry>
    <entry key="box.address"/>
    <entry key="box.username"/>
    <entry key="box.password"/>

erscheint nur noch ein Dialogfeld ("Fritz!Box wurde nicht gefunden, Bitte die Einstellungen prüfen."). Aber ganz weg bekommt man es nicht. Weder mit OpenJDK 1.8 noch mit OpenJDK 1.14.

 

[koyaanisqatsi]

Vielleicht weil bei box.address gar nichts drinne ist?
Was passiert denn bei...

<entry key="box.address">0.0.0.0</entry>

...oder...

<entry key="box.address">localhost</entry>

...ganz "Neu" die IPv6 Variante...

<entry key="box.address">[::1]</entry>

...nur aus Neugier.

Grad selber getestet ( Linux/Eclipse ), Obiges bringt nichts, der Dialog des Nichtfindens bleibt nach Neustart und check der XML.


Mit diesen Einstellungen startets bei mir "Fehlerfrei"...

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Properties for FBEditor</comment>
<entry key="position.width">680</entry>
<entry key="position.top">60</entry>
<entry key="language.setting.manuell">no</entry>
<entry key="box.address"/>
<entry key="language">de_DE</entry>
<entry key="position.left">60</entry>
<entry key="box.username"/>
<entry key="box.password">121-203-238-10-54-180-181-42</entry>
<entry key="program.start.dialog">false</entry>
<entry key="NoChecks">false</entry>
<entry key="position.height">480</entry>
<entry key="box.login.lua">true</entry>
<entry key="readOnStartup">false</entry>
</properties>

 

[NDiIPP]

In allen 3 Fällen das gleiche Ergebnis, als wenn nichts drin stehen würde bei "box.address".

 

[eisbaerin]

Mir ist noch aufgefallen, daß du beim aller 1. Start erst das Passwort und dann den Benutzernamen abfragst.
Üblicherweise ist es umgedreht.
Auch unter Einstellungen steht oben das Passwort und darunter Benutzername.
Ich würde es umdrehen.

BTW:
Was ist jetzt der Unterschied zwischen 0.6.9.7j und 0.7.2.1j?