What was going on?

Recently, I had the unique opportunity to open-source flash a “Fritz!Box 7360 EWE Edition” with the guarantee of no consequences in case I completely brick it! So my first choice fell on OpenWrt, as it is a well-known and well-documented open-source firmware for routers and modems. Especially, this would fix issues with increasingly decreasing wireless performance with the original firmware after multiple weeks of uptime (thanks AVM).

Luckily, the model is somewhat officially supported with the only limitation being that the special “EWE Edition” I’ve had, seemed to be shipping with an own hardware revision (according to boxmatrix.info). According to the same page, this would be negligible, as this hardware revision only existed in the number reported to the OS and would otherwise match the “Fritz!Box 7360 v1” model. Keen readers would note, that the “Fritz!Box 7360 v1” is not listed on the OpenWrt page, but the “Fritz!Box 7360 SL” is. This is because the “Fritz!Box 7360 SL” is the same hardware as the “Fritz!Box 7360 v1” but with a different firmware, restricting the functions of the built-in modem.

So, here is my battle plan:

1. Get the stock firmware for the device from its vendors download-server with its recovery-tool in case it goes really wrong (for both the “Fritz!Box 7360 v1” and the “Fritz!Box 7360 SL” models, as I was not sure which would work).
2. Convince the bootloader to report an unbranded model to the OS (incorrect guide from here)
3. “Recover” and boot it to check if it still works
4. Flash OpenWrt with their official guide
5. Enjoy better and more stable wireless performance!

What really happened…

Obtaining the stock image

While this sounded fairly straight-forward, I quickly realized that the download-server also offered an additional, seemingly empty folder for the “Fritz!Box 7360” model (see here). As I really did not want to brick the device, there was an ongoing quest to understand why this folder existed and (more important) was empty - like, did they pull the firmware due to legal reasons? Can I only recover my device using this non-existing firmware? I was not able to find any information on this topic, so I decided to just download the firmware and recovery-tool for the “Fritz!Box 7360 v1” model, as it was the closest match to my device.

Directly after this, I would try to use the recovery-tool to validate if the firmware would actually be usable with my box - if not, I would have aborted the whole mission. Luckily, the tool reported that my device is compatible (worked like a charm using wine running under Linux), but refused operation due to the branding of the box. Nice - next step!

Removing the branding (via ADAM2)

This was really simple - if you know the FTP protocol / commands of your FTP client¹, as the commonly shared commands are not quite correct. So, here are the correct ones:

debug # this command has NO arguments, even if otherwise suggested online - also, it is entirely optional
quote GETENV provider # this reported for the "EWE Edition" the value "addition" - idk, why
quote UNSETENV provider
quote SETENV firmware_version avm
quote REBOOT # yes, commands are written in capital letters, idk why other guides suggest otherwise

¹You first have to connect using ftp 192.168.178.1, directly after connecting the device to power - also set your IPv4 statically to 192.168.178.2, as the device will not provide a DHCP server that early in the boot process.

“Recovering” the device

Now that the bootloader reports an unbranded device, the recovery tool by AVM worked. Executing it this time lead to a complete flash of all partitions (filesystem on mtd0, kernel on mtd1 and the rest), so I was sure I could do everything with ADAM2 without worrying about consequences.

After waiting for the flash to complete, I was greeted with the familiar ugly-yellow web-interface of the “Fritz!Box 7360” - so far, so good!

Flashing OpenWrt

And now the really hard part. As I’ve mentioned before, the OpenWrt instructions are for the “Fritz!Box 7360 SL” model, which is not exactly the same as the “Fritz!Box 7360 v1” model I’ve had. You can confirm this inside ADAM2 by entering quote GETENV HWRevision, which reported 183 (v1) instead of 181 (SL).

This led to the frustrating experience flashing the device using the wrong order of the instructions. I assume my box had a slightly older/newer ADAM2 version, which was not understanding the commands anymore, after switching to the binary transfer mode of FTP…

So, here are the OpenWrt instructions for the “Fritz!Box 7360 SL” model, which did not work for me:

quote GETENV HWRevision
bin
passiv
quote MEDIA FLSH
put openwrt-18.06.1-lantiq-xrx200-avm_fritz7360sl-squashfs-sysupgrade.bin mtd1
exit

…the following errors were reported:

• Generic transfer error - no further information
• “parse error!”
• 502 Command not implemented
• Connection reset by peer

After a long time and multiple attempts of unsuccessful flashing, I’ve found the correct instructions for the “Fritz!Box 7360 v1” model²:

quote GETENV HWRevision # not needed, as it just reading the value
quote MEDIA FLSH # after switching to binary mode THIS DOES NOT WORK anymore, so do it before
bin
passiv
passiv # read the output of it! my ftp client seemingly was already in the correct mode, so entering it only once disabled it again
debug # the "put" will take a while, so you can see the progress with this command
put fw.bin mtd1 # rename the firmware file, as longer filenames seemingly lead to a "parse error!" with my version of ADAM2
exit # idk, not used reboot in that instance - just hard-reboot the device

²You need to use sudo, as entering passive mode will instruct you FTP client to listen on ports for the device to be connecting to - these ports were <1024, so you need root privileges to bind to them.

If you are wondering about the specific transfer protocol, here is the exact output of my terminal during the successful flash:

$ sudo ftp [email protected]
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> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> bin
200 Type set to BINARY
ftp> passiv
Passive mode: off; fallback to active mode: off.
ftp> passiv
Passive mode: on; fallback to active mode: on.
ftp> debug
Debugging on (debug=1).
ftp> put fw.bin mtd1
local: fw.bin remote: mtd1
---> EPSV
502 Command not implemented
disabling epsv4 for this connection
---> PASV
227 Entering Passive Mode (192,168,178,1,12,6)
---> STOR mtd1
150 Opening BINARY mode data connection
100% |****************************************************************|  7424 KiB  479.16 KiB/s    00:00 ETA
226 Transfer complete
7602790 bytes sent in 00:15 (478.58 KiB/s)
ftp> exit
---> QUIT
221 Thank you for using the FTP service on ADAM2

Enjoying the new firmware

…mostly. After the first boot, which took a while, I was greeted with the OpenWrt web-interface. After the typical problems getting familiar with LuCI again, I was able to configure my LAN, WAN and WLAN interfaces. Sadly, the wireless performance was still similar to the one before, as the most significant bottleneck seems to be the CPU on the device, which is just being overwhelmed by the amount of traffic. So, in the end, I now have a device with a more stable and up-to-date firmware (the 6.36 from AVM had its fair share of critical vulnerabilities) including the option of further hacking as it comes with a proper open Linux environment.

Random stuff learned

• Take a look into the official firmware by AVM!
  • Updates are applied by loading a kernel module, which does stuff
  • The install script inside a package creates a post_install, which does the actual work
  • The sources from the install script are quite interesting, including…
    • Mixed German and English comments
    • Ramblings about the device’s random behavior and bootloader bugs
    • Some TODO comments about the future
• The quote-ed commands remind me heavily of u-boot commands
  • …maybe they use a predecessor like redboot from eCos?
• Careful with the removal of branding!
  • Further branding information may be stored on other partitions, so official firmware may still recognize these and refuse to boot
  • The changed HWRevision may also be checked by the official firmware
  • If the device still belongs to the ISP, they will maybe charge you for a new one