December 6, 2024 14:12
What was going on?
Recently, I had once again the unique opportunity to flash a “Fritz!Box 6490 KDG Edition” with the guarantee of no consequences in case I completely brick it. This time, because I needed the DECT functionality still working after this operation, I chose to stay on the proprietary firmware by AVM. 🤷♂️
So, here is my battle plan:
- Get the stock firmware for the device from its vendors download-server with its recovery-tool in case it goes really wrong.
- Convince the bootloader to report an unbranded model to the OS (guide from here)
- “Recover” and boot it
- Enjoy a more open experience!
What really happened…
Obtaining the stock image
This is where I hit the first road-block: The manufacturer offers seemingly no recovery.exe-tool for this device. So, to proceed, I just grabbed the original firmware image from their download server and extracted the partition images from it:
wget https://download.avm.de/fritzbox/fritzbox-6490-cable/deutschland/fritz.os/FRITZ.Box_6490_Cable-07.57.image # get it
tar xf FRITZ.Box_6490_Cable-07.57.image # unpack it
ls -lah var/remote/var/tmp/*.image # these are the ARM64 images
ls -lah var/remote/var/tmp/x86/*.image # these are the x86_64 images
Removing the branding (via ADAM2)
This should have been simple, just by using the FTP client (see my last post):
bin # not needed here, but I did that anyways...
passiv # look for "Passive mode: off"
debug # enable it for the "QUOTE xxx" responses
quote GETENV firmware_version # reported "kdg"
quote SETENV firmware_version avm # use the unbranded firmware variant
quote UNSETENV provider # drop it, if it was set before
Bootloop. Ooops. Well, according to this forum thread, the branded firmware does not come with the unbranded package for the AVM variant… Nice, so it will just crash and reboot indefinitely. You can always revert to the branded frimware again, but this is of course not what I wanted.
Recovering the device
…but this time for real. As I have realized before, there is no recovery tool available. Also, hexedit-ing the recovery tool for another device did not yield in any success (careful, the recovery tool also contains part of the device-specific firmware partitions - so make sure you replace everything).
So, here I am… With a bootlooping device and no idea how to continue - until I found this blog post from somebody in a similar situation. It turns out the Firtz!Box contains multiple copies of the firmware on its flash memory. You can switch between them inside the ADAM2 bootloader by changing the linux_fs_start environment variable. This will then, upon reboot, control which parts of the flash are being available as mtd0, mtd1, etc. partitions.
Next, I just quickly prepared the partition images to prevent any mishaps due to path names and too quickly accepted TAB-completions:
cp var/remote/var/tmp/filesystem.image arm_filesystem.image
cp var/remote/var/tmp/kernel.image arm_kernel.image
cp var/remote/var/tmp/x86/filesystem.image atom_filesystem.image
cp var/remote/var/tmp/x86/kernel.image atom_kernel.image
Continuing, using a random partition table I found in the internet, I flashed the images to the correct partition labels (once again using ADAM2 via FTP) and swapped the firmware slot.
$ ftp [email protected] # yes, I forgot to "sudo" here, which caused some "errors"
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> bin
200 Type set to BINARY
ftp> passiv
Passive mode: off; fallback to active mode: off.
ftp> debug
Debugging on (debug=1).
ftp> quote MEDIA FLSH
---> MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> binary
---> TYPE I
200 Type set to BINARY
ftp> passiv
Passive mode: on; fallback to active mode: on.
ftp> put arm_filesystem.image mtd11
local: arm_filesystem.image remote: mtd11
ftp: setsockopt SO_DEBUG (ignored): Permission denied # ignore this...
---> EPSV
502 Command not implemented
disabling epsv4 for this connection
---> PASV
227 Entering Passive Mode (192,168,178,1,54,69)
---> STOR mtd11
150 Opening BINARY data connection
100% |**********| 5316 KiB 2.50 MiB/s 00:00 ETA
226 Transfer complete
5443592 bytes sent in 00:02 (2.48 MiB/s)
ftp> put arm_kernel.image mtd12
local: arm_kernel.image remote: mtd12
ftp: setsockopt SO_DEBUG (ignored): Permission denied # ignore this...
---> PASV
227 Entering Passive Mode (192,168,178,1,54,69)
---> STOR mtd12
150 Opening BINARY data connection
100% |**********| 1887 KiB 2.16 MiB/s 00:00 ETA
226 Transfer complete
1932808 bytes sent in 00:00 (2.11 MiB/s)
ftp> put atom_filesystem.image mtd13
local: atom_filesystem.image remote: mtd13
ftp: setsockopt SO_DEBUG (ignored): Permission denied # ignore this...
---> PASV
227 Entering Passive Mode (192,168,178,1,54,69)
---> STOR mtd13
150 Opening BINARY data connection
100% |**********| 27540 KiB 3.76 MiB/s 00:00 ETA
226 Transfer complete
28200968 bytes sent in 00:07 (3.75 MiB/s)
ftp> put atom_kernel.image mtd14
local: atom_kernel.image remote: mtd14
ftp: setsockopt SO_DEBUG (ignored): Permission denied # ignore this...
---> PASV
227 Entering Passive Mode (192,168,178,1,54,69)
---> STOR mtd14
150 Opening BINARY data connection
100% |**********| 3469 KiB 2.03 MiB/s 00:00 ETA
226 Transfer complete
3552264 bytes sent in 00:01 (2.00 MiB/s)
ftp> quote GETENV linux_fs_start
---> GETENV linux_fs_start
linux_fs_start 0
200 GETENV command successful
ftp> quote SETENV linux_fs_start 1 # switch to the other firmware slot
---> SETENV linux_fs_start 1
200 SETENV command successful
ftp> exit
---> QUIT
221 Thank you for using the FTP service on ADAM2
Finally, the device boots up and I can access the web-interface again - this time with the unbranded firmware.
Random stuff learned
- This device seemingly has two processors - one ARM64 and one x86_64. The x86_64 is used for the main operation (web-interface), while the ARM64 likely being used for DSL/LTE operations (based on its filesystem-contents)
- you can extract the filesystem for the ARM64 processor via (my
binwalkdoes not seem to pick up the compression used here):binwalk -Me filesystem.image 7z e 0.squashfs binwalk -Me 0
- you can extract the filesystem for the ARM64 processor via (my
Matrix
