[Frage] ein etwas hartnäckig Patient in der Form von Fritz!Box 6490 Kabel… OS 6.24

kyle0r

Neuer User
Mitglied seit
9 Feb 2016
Beiträge
24
Punkte für Reaktionen
0
Punkte
0
Ich bin kein muttersprachler, also bitte nimm etwas geduld mit mir!

TL;DR / zu lang; nicht gelesen: Könnten jmd. mir bitte helfen ein firmware für meinen Box zu sichern?

Erstens ... WOW! das Forum und Gemeinschaft hat mich überfordert! So viel Infos und Wissen! Um mir Wissen anzueignen habe Ich Google-Foo benutzt und ungefähr 70 webpages/posts recherchiert. Circa 27 (~40%) war von IPPF! Ich bin sehr dankbar für das. Es hat mich sehr viel geholfen.

Hier sind die 70 Links meiner Recherchen für alle Interessierten. Ein Export von meinem Browser-Tab-Tracker!

Why/Warum?

Das Ganze fängt an wenn einer von meine Familie haben Problem mit ein sehr spezifisch Internet Dienste gehabt. Natürlich hab ich mich bemüht zu helfen und Fehlerdiagnose zu machen. Das wegen wollte ich an die Kern von Lokalnetz kommen und checken die Konnektivität. Warum? Zum andere lokalen Faktoren auszuschließen.

Hab ich mich gefreut mehr Erfahrung über Fritz!box zuholen. Noch dazu habe ich auch die Chance mein Linux Problem/Lösung Fähigkeiten zu üben, und auch Sicherheit/Penetration Methode ausprobieren.

Who/Wer?

Weil ich bin ganz neu hier, ein kleines Einführung. Ich bin ein Informatiker (oft bekannt als Chief Nerd). Hessen ist meine operativen Bereich (ob der Humor lässt sich übersetzen?). Ursprünglich aus Vereinigtes Königreich. Familie und Informatik sind meinem Leidenschaften.

What/um was gehts?

Bei zwei Private Internetanschlüsse (gleich Anbieter) gibt es ein Problem ein spezifisch externe ip und port zu erreichen. Ich bin, soweit sicher das es nicht an der Infrastruktur Vorort liegt.

Bei ein remote shell server oder Telekom-Stick die socket können Problemloss aufgebaut werden.

Deswegen wollte ich mich einloggen bei Fritz!Box um direkt Tests ausfuhren.

Bei einer der Anschlüsse hatte ich leider ein etwas hartnäckig Patient ;-) in der Form von Fritz!Box 6490 Kabel… OS 6.24.

Laut Recherche #96*7* (auch bei IPPF) blah blah und dann gibst Telnet zugriff. Ja Perfekt! Dann kann ich mich ein direkt Socket aufbauen, um die andere Infrastruktur Vorort auszuschließen. Nein. Geht nicht.

lDMEg1j.jpg

Weitere Recherchen sagt mir bei neuer Firmware geht der Trick vielleicht nicht und ... laut offiziell post von AVM ab OS 6.25 gibt sowieso kein Telnet mehr ... "offiziell".

na dann! Zeit, die Ärmel hochkrempeln!

Untitled3.png

ein anderer Problematik ist der Fakt AVM und meine Anbieter offiziell erlauben kein Manuale Endkunden Firmware Updates. Na toll.

jacki-wtf.png

Ich habe durchs Manuelle Konfig Änderung bis jetzt (trotz online Hinweise) kein Erfolg gehabt die Manuale Update Feature anzuschalten ...

Aber ... Ich habs durch online Recherchen und Browser Code Inspektion und Manipulation, ein Weg gefunden wie Mann ein Pseudo-Firmwareupdates machen kann.

Laut die Politik von AVM bzw. Anbieters, mehr Details über diese Methode wurde ich jetzt nicht schreiben.

Nach mehrmals Probieren und Diagnose von das pseudo-update Prozess, zum Erlernen wie und was möglich ist ... hab Ichs geschafft Telnet zum Laufen bringen und ohne reboot von das Box. Musste aber die rc.net und rc.voip Laufen nachher.

Na endlich konnte ich Telnet benutzen mein Ziel zu erreichen.

aww-yeah.png

Your help/Könnten Sie mir bitte helfen?

Laut mein post hier wurde ich gerne bekomm ein Firmware Back-up falls ich bekomme ein beschissener update aus der Ferne. Oder ob ich selbe ein Fehler machen beim Rumspielen!

Ich habe mehrere Seiten gelesen, wie man die Firmware auslesen kann.

Ich habe probiert die entsprechend devices von adam2 bootloader zu sichern aber die ftp GET geht nicht (verschiedener FTP clients ausprobiert). Ich vermute die bootloader ist neu genug das die Operation blockiert ist?

Ich habe angefangen die Flash-Partitionen im laufenden Betrieb zu sichern, aber meiner Meinung nach, habe ich merkwürdiger Byte große bekommen:

Code:
# block device		# name			# bytes from wc -c
######################################################
/dev/mtdblock0		# urlader		131072
/dev/mtdblock1		# tffs (1)		262144
/dev/mtdblock2		# tffs (2)		262144
/dev/mtdblock3		# config-space		655360
/dev/mtdblock4		# cefdk			524288
/dev/mtdblock5		# cefdk_config		65536
/dev/mtdblock6		# gpt_backup		65536

# mtdblock7 to 20 are: No such device or address, agrees with /sys/dev

# cat /proc/partitions
major minor  #blocks  name

  31        0        128 mtdblock0
  31        1        256 mtdblock1
  31        2        256 mtdblock2
  31        3        640 mtdblock3
  31        4        512 mtdblock4
  31        5         64 mtdblock5
  31        6         64 mtdblock6
 179        0    1875968 mmcblk0
 179        1      65536 mmcblk0p1
 179        2       8192 mmcblk0p2
 179        3      65536 mmcblk0p3
 179        4       8192 mmcblk0p4
 179        5      65536 mmcblk0p5
 179        6       8192 mmcblk0p6
 179        7      65536 mmcblk0p7
 179        8       8192 mmcblk0p8
 179        9    1580015 mmcblk0p9
 254        0      16384 zram0

# cat /proc/sys/urlader/environment | grep mtd
mtd0	0x0,0x4000000
mtd1	0x4000000,0x4800000
mtd2	0xa0000,0xc0000
mtd3	0xc0000,0x100000
mtd4	0x100000,0x140000
mtd5	0x140000,0x1e0000
mtd6	0x4800000,0x8800000
mtd7	0x8800000,0x9000000
mtd8	0x0,0x80000
mtd9	0x80000,0x90000
mtd10	0x90000,0xa0000
mtd11	0x9000000,0xd000000
mtd12	0xd000000,0xd800000
mtd13	0xd800000,0x11800000
mtd14	0x11800000,0x12000000

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "urlader"
mtd1: 00040000 00001000 "tffs (1)"
mtd2: 00040000 00001000 "tffs (2)"
mtd3: 000a0000 00001000 "config-space"
mtd4: 00080000 00001000 "cefdk"
mtd5: 00010000 00001000 "cefdk_config"
mtd6: 00010000 00001000 "gpt_backup"

# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock3 on /nvram type jffs2 (rw,relatime)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
169.254.1.2:/ on /var/remote type nfs4 (rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=169.254.1.1,minorversion=0,local_lock=none,addr=169.254.1.2)
169.254.1.2:/var/media/ftp/ on /var/media/ftp type nfs4 (rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=169.254.1.1,minorversion=0,local_lock=none,addr=169.254.1.2)
169.254.1.2:/var/tmp/ on /var/remote/var/tmp type nfs4 (rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=169.254.1.1,minorversion=0,local_lock=none,addr=169.254.1.2)

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                14.6M     14.6M         0 100% /
tmpfs                   123.7M      1.1M    122.6M   1% /var
tmpfs                   123.7M     16.0K    123.7M   0% /dev
/dev/mtdblock3          640.0K     56.0K    584.0K   9% /nvram
169.254.1.2:/           114.3M    416.0K    113.9M   0% /var/remote
169.254.1.2:/var/media/ftp/
                          1.5G     35.5M      1.4G   2% /var/media/ftp
169.254.1.2:/var/tmp/
                        114.3M    416.0K    113.9M   0% /var/remote/var/tmp

Ich sehe kein device große genug fürs 14.6M squashfs?

Hilfe! was ist zu tun?



Annex

I also developed (Nach meinen Recherchen) a short bash script that (works in cygwin too) to try to get AVM to give me a firmware link. However I had no luck with this. Perhaps someone has some better suggestions on the values for the URL parameters?

kann jmd. ein Fehler im URL sehen?

Careful with this, it will make more than >900 curl HTTP requests to AVM the server!

Code:
echo -e "curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06."{10..31}"&oem="{avm,lgi}"&lang=de&country=049&fw=141.06."{10..31}"&macaddr=0\n" | bash | grep -v 'NO UPDATE FOUND'

example URL's

 curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06.31&oem=lgi&lang=de&country=049&fw=141.06.27&macaddr=0
 curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06.31&oem=lgi&lang=de&country=049&fw=141.06.28&macaddr=0
 curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06.31&oem=lgi&lang=de&country=049&fw=141.06.29&macaddr=0
 curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06.31&oem=lgi&lang=de&country=049&fw=141.06.30&macaddr=0
 curl --silent http://update.avm.de/cgi-bin/cati?hw=141.06&sw=06.31&oem=lgi&lang=de&country=049&fw=141.06.31&macaddr=0

Here is the units info, in case its needed:

Code:
ftp> GETENV ProductID
Invalid command.
ftp> quote GETENV ProductID
ProductID             Fritz_Box_HW213a

200 GETENV command successful
ftp> quote GETENV annex
annex                 Kabel

200 GETENV command successful
ftp> quote GETENV mtd1
mtd1                  0x4000000,0x4800000

200 GETENV command successful
ftp> quote GETENV firmware_info
firmware_info         141.06.24

200 GETENV command successful
ftp> quote GETENV firmware_version
firmware_version      lgi

200 GETENV command successful
ftp> quote GETENV HWRevision
HWRevision            213
 
Hi opto, thanks for the insightful answer :)

I will let you know if I have success extracting 6.24. PeterPawn script also look very good. I'm still learning/reading about it and will post more soon.
 
I dont know any way to read only the real data
If this is really necessary, you could check (prior to copying or after you saved the content to a file) where's the point in the file after which only "ones" or "zeroes" are present (hex FF or 00). Then you may shorten the copy operation to this length ... if you're using "block mode commands" (like dd), you have to change the commands used in "savepart" for "block device" partitions (you could check the specified input device (from "savepart"(s) view), if it's a block device using "stat" command) and then you could limit the copy operation to the "real size" immediately or you truncate the copied files manually later at the appropriate point.

Example:
If the hexdump of a kernel image shows this:
Code:
 # hd kernel_ARM_141.06.22-29874 | tail -n 5
001bce50  95 59 0e a3 14 01 a3 be  e2 ea a4 31 b2 fd 67 34  |.Y.........1..g4|
001bce60  2c a9 e1 09 aa 00 00 00  00 00 80 00 48 ff ff ff  |,...........H...|
001bce70  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00800000
you can truncate the kernel image file to length 0x1bd000 (0x1bce70 rounded up to a 4K boundary). For SPI partitions this should be done at an "erase size boundary" (which is 0x1000 for the 6490) and for MMC partitions it doesn't really matter, but an "integral size" isn't a worse bad idea and the mentioned 4K boundary is a good choice, even for MMC partitions.
 
Zuletzt bearbeitet:
Thanks PeterPawn, great infos.

dd was on my list to check results/contents/sizes too. So its good to have this guide.
 
So a few updates.

PeterPawn's script worked well and was a great learning tool, I made a few personal tweaks so I could also see the progress over an open socket in realtime. Here is the logfile.

Before I ran it, I took time to understand it, and read more online about the duel nature of the 6490. There is also the very fruitful thread on-going which has similar useful infos about the 6490. [thread=283851]here[/thread]

Code:
2016-02-11 11:20:49.133 - Waiting for NAND flash to appear ...
2016-02-11 11:20:49.260 - NAND flash is mounted now on /var/media/ftp
2016-02-11 11:20:49.418 - Saving serial flash content:
2016-02-11 11:20:49.460 - dev:    size   erasesize  name
2016-02-11 11:20:49.460 - mtd0: 00020000 00001000 "urlader"
2016-02-11 11:20:49.461 - mtd1: 00040000 00001000 "tffs (1)"
2016-02-11 11:20:49.461 - mtd2: 00040000 00001000 "tffs (2)"
2016-02-11 11:20:49.461 - mtd3: 000a0000 00001000 "config-space"
2016-02-11 11:20:49.461 - mtd4: 00080000 00001000 "cefdk"
2016-02-11 11:20:49.461 - mtd5: 00010000 00001000 "cefdk_config"
2016-02-11 11:20:49.461 - mtd6: 00010000 00001000 "gpt_backup"
2016-02-11 11:20:50.496 - Copying /dev/mtd0 to /var/media/ftp/debug/savesystem/ARM/mtd0_urlader done, rc=0
2016-02-11 11:20:51.909 - Copying /dev/mtd1 to /var/media/ftp/debug/savesystem/ARM/mtd1_tffs_1 done, rc=0
2016-02-11 11:20:52.705 - Copying /dev/mtd2 to /var/media/ftp/debug/savesystem/ARM/mtd2_tffs_2 done, rc=0
2016-02-11 11:20:55.008 - Copying /dev/mtd3 to /var/media/ftp/debug/savesystem/ARM/mtd3_config-space done, rc=0
2016-02-11 11:20:57.777 - Copying /dev/mtd4 to /var/media/ftp/debug/savesystem/ARM/mtd4_cefdk done, rc=0
2016-02-11 11:20:58.705 - Copying /dev/mtd5 to /var/media/ftp/debug/savesystem/ARM/mtd5_cefdk_config done, rc=0
2016-02-11 11:20:59.088 - Copying /dev/mtd6 to /var/media/ftp/debug/savesystem/ARM/mtd6_gpt_backup done, rc=0
2016-02-11 11:20:59.173 - Saving serial flash done
2016-02-11 11:20:59.285 - Saving kernel and filesystem partitions
2016-02-11 11:21:02.406 - Device /dev/mmcblk0p1 contains active filesystem_ARM with version 141.06.24-30308 created at 20.04.2015 13:07:13
2016-02-11 11:22:04.138 - Successfully saved /dev/mmcblk0p1 to /var/media/ftp/debug/savesystem/ARM/filesystem_ARM_141.06.24-30308
2016-02-11 11:22:14.082 - Successfully saved /dev/mmcblk0p2 to /var/media/ftp/debug/savesystem/ARM/kernel_ARM_141.06.24-30308
2016-02-11 11:22:14.344 - Error 255 mounting /dev/mmcblk0p5 to /var/tmp/savesystem.mp
2016-02-11 11:22:22.388 - Successfully saved /dev/mmcblk0p6 to /var/media/ftp/debug/savesystem/ARM/kernel_ARM_141.06.24-30308

I also manually cat the mmc blk devices to check their content.

Code:
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p1-filesystem_ARM | head -n 5
00000000: 7371 7368 0000 17a6 00e8 6732 0001 0000  sqsh......g2....
00000010: 0000 0130 0004 0010 02c0 0001 0004 0000  ...0............
00000020: 0000 0000 afd0 14e8 0000 0000 00e8 6732  ..............g2
00000030: 0000 0000 00e8 672a ffff ffff ffff ffff  ......g*........
00000040: 0000 0000 00e6 aacc 0000 0000 00e7 6016  ..............`.
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p2-kernel_ARM | head -n 5
00000000: 8112 edfe f3cd 1b00 0080 0048 0102 5a07  ...........H..Z.
00000010: dbcd 1b00 6407 4f00 4dc6 7625 5d00 0080  ....d.O.M.v%]...
00000020: 0000 0000 0071 885a 0d4d ee67 154a 9d6b  .....q.Z.M.g.J.k
00000030: 8750 32a4 eaa4 d338 9ebc b1eb cee5 1f97  .P2....8........
00000040: ce97 f7a2 10e9 7ea5 86d7 940e 606b b754  ......~.....`k.T
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p3-filesystem_ATOM | head -n 5
00000000: 6873 7173 3411 0000 28bc b300 0000 0100  hsqs4...(.......
00000010: b000 0000 0400 1000 c002 0100 0400 0000  ................
00000020: 4d1e f683 0000 0000 28bc b300 0000 0000  M.......(.......
00000030: 20bc b300 0000 0000 ffff ffff ffff ffff   ...............
00000040: 3064 b200 0000 0000 c0ee b200 0000 0000  0d..............
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p4-kernel_ATOM | head -n 5
00000000: 1281 edfe 3039 3800 0000 b240 ea05 00c0  ....098....@....
00000010: 078c c88e d88e c08e d031 e4fb fcbe 2d00  .........1....-.
00000020: ac20 c074 09b4 0ebb 0700 cd10 ebf2 31c0  . .t..........1.
00000030: cd16 cd19 eaf0 ff00 f044 6972 6563 7420  .........Direct
00000040: 626f 6f74 696e 6720 6672 6f6d 2066 6c6f  booting from flo
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p5-filesystem_reserved_ARM | head -n 5
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p6-kernel_reserved_ARM | head -n 5
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p7-filesystem_reserved_ATOM | head -n 5
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
# anon@kmi7m://Fritz.nas/fritz.nas/debug/tmp
# $ xxd.exe mmcblk0p8-kernel_reserved_ATOM | head -n 5
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................

My cat and PeterPawn's script outputs had matching checksums, at least for filesystem_ARM (the one I checked).

So does it mean that I have no "recovery" loaded yet?

---

I tried to boot the "alternative/recovery" fs, but that ended in a trip the basement ... greeted with a red flashing INFO light. Had to use bootloader to set back to 0 and everything was OK.

This would make sense for me, given the zero byte nature of the blocks?

Code:
echo linux_fs_start 1 > /proc/sys/urlader/environment

---

Learning from [thread=283851]thread 283851[/thread], this is what I get back from rpc cat /proc/cpuinfo

Code:
# rpc cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 53
model name      : Intel(R) Atom(TM) CPU  652   @ 1.20GHz
stepping        : 8
cpu MHz         : 1200.028
cache size      : 256 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dts tpr_shadow vnmi flexpriority
bogomips        : 2400.05
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 53
model name      : Intel(R) Atom(TM) CPU  652   @ 1.20GHz
stepping        : 8
cpu MHz         : 1200.028
cache size      : 256 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dts tpr_shadow vnmi flexpriority
bogomips        : 2399.93
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Now I think I have a good understanding of the duel nature of the system. Let me test myself ...

There are two independent CPU's and also double mmc devices.

The ARM CPU is always the "primary"... its performs the core services and management etc. Running an ARM kernel and filesystem.

The ATOM CPU is like a slave in a way, and gets used for heavier processing tasks. Running an ATOM kernel and file system.

I think this is aligned with PeterPawn's input from [thread=283851]thread 283851[/thread] and the info the wehavemorefun wiki http://www.wehavemorefun.de/fritzbox/Dual-Boot-System

The two kernels/file systems are tailored to for the CPU's role, and are not the same.

The "double" mmc devices are a way to "flash" the system without completely bricking it. The running "current" system is untouched, the "future" devices are flashed, then it is possible for the system boot with those "future devices" with the "current" available as a rollback. The two CPU's concept are independent of this concept.

Is it a good summary?
 
Your device was never updated with a newer version ... therefore the alternative system partitions are unused/empty.

If you would like to start own modifications, you should first copy the existing system from the primary partition set to the alternative one or you'll be unable to switch to the alternative system, if something wents wrong.
 
Zuletzt bearbeitet:
PeterPawn. Thank you. Danke!

You also answed my next question!

Was my summary accurate?
 
That are different questions ...

kyle0r schrieb:
1. Is it a good summary?
2. Was my summary accurate?
The answer could be "I don't want to make this decision" (1) and "may be" (2) in some aspects.

I'm unsure, which core will be the "primary" system at boot time ... some strings within the cefdk partition look strange - it could be, that the ARM kernel is brought to memory and started there from the ATOM bootloader.

But the roles of the cores - while the FRITZ!OS is running - are correct, as far as I found it during my own examinations (a long time ago - Chrismas 2014).

The "hot-flash capabilities" (writing the new system to an unused partition and switching between them for the next reboot, after the write operation has been completed successfully) are present on every newer router model built by AVM ... the "NAND models" (containing an - much smaller than that in the 6490 - amount of NAND flash storage for the system instead of the earlier used NOR flash) are using the same mechanism to ensure valid (and possibly unattended) updates of the firmware. The only known NOR model supporting such this "hot-flash mechanism" is (afaik) the 6360 model ... the predecessor of the 6490, which uses 2x 16 MB NOR flash for the system.
 
Hehe. Danke nochmals.

I will try loading the 4 partitions and see if I can boot it.
 
Is it normal that the sums for the kernel are the same for both arch's ?

Code:
e406b26bd60053d279601d8e846c33ff *./ARM/filesystem_ARM_141.06.24-30308
96995b58d4cbf6aaa9041b4f00c7f6ae *./ARM/kernel_ARM_141.06.24-30308
1ad201def136100ea92e79cba19e87eb *./ARM/logfile.txt
338e5c881e3893f9329cc111fbb179ae *./ARM/mtd0_urlader
9fa076d3f796bbfe87bf0b9c0e821813 *./ARM/mtd1_tffs_1
50b9e9c22c64af880a714a3bb0df99a0 *./ARM/mtd2_tffs_2
a1b30ce6543111f1c00b7079882df25a *./ARM/mtd3_config-space
20562c478bf69e8d879703e2e1ed9445 *./ARM/mtd4_cefdk
2638f80816c974610cc1fa43c4020bd5 *./ARM/mtd5_cefdk_config
6564275a1933e980766d970fb890f51f *./ARM/mtd6_gpt_backup
0ff26384a3c588331f6206fb4b531f8f *./ATOM/filesystem_ATOM_141.06.24-30308
96995b58d4cbf6aaa9041b4f00c7f6ae *./ATOM/kernel_ATOM_141.06.24-30308
8fc167782ab570843d4985f1bf73f853 *./ATOM/logfile
2393eb480c0ab1c73af033b431b3dc43 *./ATOM/mtd0_nmyx25
338e5c881e3893f9329cc111fbb179ae *./ATOM/mtd1_urlader
b9bec539fc3be9146afca23b97854cba *./ATOM/mtd2_tffs_1
2c411416693443ce6a965855d595cb8f *./ATOM/mtd3_tffs_2
6da65c3bb45b3089601bac3693f4c1ae *./ATOM/mtd4_config-space
20562c478bf69e8d879703e2e1ed9445 *./ATOM/mtd5_cefdk
2638f80816c974610cc1fa43c4020bd5 *./ATOM/mtd6_cefdk_config
6564275a1933e980766d970fb890f51f *./ATOM/mtd7_gpt_backup
 
Quick update, through cross-checking I spotted that the kernel dumps produced by savesystem script were full of /dev/zeros...

I spotted it because 96995b58d4cbf6aaa9041b4f00c7f6ae matched the empty sums from my direct cat'ing of the reserved partitions.

I will see if I can debug the script later, when I have time.
 
Now ... if there is an empty filesystem partition, the "version" variable remains unchanged (and dumping the filesystem partition is skipped), but the next line points to a kernel again and the script attempts to save it. Now the existing (valid) dump of the first partition will be overwritten by the content of the empty partition.

As I mentioned, the script is a "proof of concept" ... if there's a "virgin box" which never was updated yet, you've to add another component to the name of a dumped file. Simply add the the remainder of "dev" after the last slash to the filename in the savepart function and everything works as expected. I've choosen my partition/file names after some considerations ... if you'd like to extract the filesystem automatically after saving the dump files, an additional (or not exactly predictable) filename component is rather a handicap than an advantage.

As I mentioned in another context (truncating dumps to the real length of the content), there's no simple way to detect an empty (or shortened) partition with the available busybox applets or binaries - at least I don't know one and so you/I have to save even an empty partition ... or you use the mount error as indicator to skip the next kernel partition too (which needs another variable signaling this state). The script may be enhanced in many aspects ... it's only a "working tool" from my toolbox (that's why it doesn't contain comments or further explanations and/or expressive variable names) and publishing it in the other thread was only a favor or the easiest way to answer your question - the script doesn't catch all possible error conditions.
 
Alles Klar. I found the script educational :)
 
Im not really sure if there are 2 MMCs, I believe that depending of linux_fs_start it selects the 1,2,3,4 or 5,6,7,8 partitions for booting
As PeterPawn said I would check which one you use for booting and do a dd to copy them to recovery partitions so you have a recovery if something goes wrong, but care to not copy the empty partitions to working ones

An interesting tool for linux users is binwalk, you can do hex diff, file analysis, shows the kernel version and build string, unix path strings...

A word of warning, several CEFDK using devices (mainly TV related) often have signed booloader, kernel and FS checking. Im not sure if Fritz's CEFDK checks for booloader and linux kernel signature or not (I didnt put any modified kernel nor bootloader) at least the root FS is not being checked
https://www.google.com/search?q=CEFDK

Also someone noticed the "/usr/sbin/cefdk" command? seems that there would be a way to upload a image to "NP-CPU" or "APP-CPU" without actually flashing it to SFlash, but yet again I preffer to not mess with bootloader...
 
I think not messing with the bootloader is a good policy.

Thanks for the additional infos.
 
Du hast es tatsächlich geschafft auf einer Kabelfritzbox mit 06.24 einen Telnet-Dienst zu starten? Das würde mich sehr interessieren (da die "Hostname"-Lücke ab > 06.10 oder so nicht mehr klappt). Kannst du mir da irgend ne Anleitung per PN schicken? Hast du das mit der Hostname-Lücke gemacht (und die ist in 06.24 immer noch da?) oder irgendwie anders?

You've actually found a way to get a telnet server running on a cable fritzbox? I'm very interested in this, because AVM has fixed the old "hostname" exploit in, i guess, 06.10 and I cannot access my 6360 via telnet any more. Could you send me a description on how to get Telnet via PM? Or did you use the hostname exploit and it still isn't fixed in 06.24? (
 
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.