First I'd like to apologize for asking in these forums, as my problem is not directly OpenWRT related. But I feel the only experts are here. And who knows, maybe any results here can help future OpenWRT hardware support.
Recently I acquired a box of broken routers with a "Telekom Speedport 4 Type A" (made by Arcadyan) inside. This device was initially dead as a doornail. All step down converters on the board were not operating. I found the short circuit at the VCC/GND pads of the NAND IC. It was soaked in flux, and whoever swapped it out apparently overlooked the tiny solder bridge between a pair of Vcc/GND pads. After removing that bridge, the device started and showed a Telekom logo on the front display while flashing a green LED. But that was it all. No DHCP, no WiFi.
Speedport Firmware Download
DOWNLOAD 🔥 https://bltlly.com/2yGcoW 🔥
It looks like CFE first tries to boot an image at offset 0x00100000. After the last output of "got hash for rootfs" the device then seems to reset and it attempts another boot, this time from offset 0x05100000. It then stalls at the output of "got hash for rootfs". Unfortunately, there's no output from the booted kernel itself. So there's no hint on what it doesn't like about the two apparently existing 010139.2.1.002.0 images. My guess is that the rootfs hashes don't match the NAND content.
As it offers a firmware update option, I thought that I may be able to just update the firmware to replace the possibly damaged firmware images in the flash. However, official firmware update files are rejected ("invalid image format"). If I take a closer look at those official firmware update files, they seem very much completely encrypted to me (and not compressed). As expected, binwalk shows no results at all.
Any ideas what I could try next? I -could- remove the NAND again and read it to get unencrypted access to the installed images for some reverse engineering, but I'd rather like to avoid that if possible
Adding new device support This article assumes your device is based on a platform already supported by OpenWrt. If you need to add a new platform, see ->add.new.platform If you already solved the puzzle and are looking for device support...
does not sound promising, apart from the rest of the hardware (all Broadcom) not being very accommodating to OpenWrt support either (there will never be drivers for the modem, wireless or phone functions).
The T-Home Speedport W 504V is an IAD sold by Deutsche Telekom with an ADSL2+ Annex B/J Modem, 802.11abgn Wifi and two FXS ports as well as a S0 bus connector.
The device is manufactured by Arcadyan.
I tried the method described in the wiki article for ARV7506. I was now able to flash the image via the bootloader's recovery webinterface (signature BRNDTW504 seems to be correct).However, the bootloader didn't boot the encrypted image.
In the german ip-phone-forum I found some information about the encryption methods used in the Speedport W722V. I think this might be the correct method for this device, too. In this thread, it is described how to decrypt the firmware and a C program (for Windows ) is provided.
I bought that device on Ebay, but I can not use it, because it only works with German Telecom (Deutsche Telekom). In Hungary it does not work. There is an LTE sim slot built in it, and I would like to use it with OpenWrt. There is a dsl connection too, and I would like to use it as a WAN port to connect it to another router. Please build a firmware for it, because it is not supported yet. And sorry if my English is bad, it is because I am from Hungary.
Sorry but it's not that easy. You have to first identify what SoC it is using (assuming it's a relatively modern device), then you can try to find a similar device, compare the .dts and .dtsi files, then try to make some minor modifications to those and get it to work. Anyway, assuming you can get OpenWrt installed, you can try using ModemManager and luci-proto-modemmanager to get the LTE modem working quite easily.
Unfortunately, I don't have the time or knowledge to do get into this -- I rather bought a new router to have at least a bit of up to date security, as the Speedport Hybrid firmware hasn't been updated for some time anymore. But maybe it helps s.b. to rescue some of these devices. They can still be bought and they can also still be used with the T-Com subscriptions.
SoC & modem appear to be Lantiq according to the wiki, which is supported by OpenWrt in general. However, the wireless is Broadcom, which only has limited/poor support due to a lack of wireless driver source from Broadcom.
Now that generates a whole new set of questions for me:
- Is that even legal?
- The driver binaries would have to be included in the "source" package which the telekom provides via download. Could these be used for the free OpenWRT? Or is that impossible due to legal or other issues?
- If the telekom/Arcadyan firmware is based on OpenWRT - would it be possible to somehow "convert" the telekom sources into "regular" OpenWRT - e.g. by substituting the telekom GUI with the regular OpenWRT gui package (if the GUI is somehow isolated enough to do this)
Telekom source code incomplete - doesn't compile
I tried to compile the telekom firmware. But it didn't build correctly. It seems there are some missing libraries. The build script tries to download these, but fails:
I have to admit that I actually don't know what I am doing here. I know almost nothing about OpenWRT and I never compiled a router firmware myself. So forgive me if I am doing some stupid noob mistakes here.
Now my question is:
- If this blob is closed source - is someone obligated to provide at least the binary?
- would it be possible to extract this blob from the compiled firmware? The binary isdownloadable from the telekom web site Firmware_Speedport_W724V_TypB_v01011603.00.007.bin
edit:
compressed or encrypted firmware binary?
Is it possible that the firmware is somehow compressed or encrypted?
The 'strings' command (I used '-n 10') doesn't give me anything usefull from this file:
- Wouldn't there be at least some readable identifyers and headers if it wasn't encrypted?
- And if it was only compressed - wouldn't there be at least something readable in the first bytes? E.g. with gzip I see the original file name somewhere in the first 30 bytes.
Binwalk also falied to detect any file system. But the '-E' option reviled a drop in entropy between offsets 0x199A00 and 0x1DFE00. In the rest of the file the entropy is >0.97, but between 0x199A00 and 0x1DFE00 it drops to values around 0.83.
I gained a small new insight regarding the low entropy block in the firmware binary. While the rest of the firmware binary sems to be encrypted (and compressed?), this block consists of a sequences of 480 bytes which is identically repeated of 601 times.
Did you check the download list and binary cutting instructions at -xdsl-firmware-info/ ?
The page seems to contain a link to the download, and the "show downloads" help contains cutting advice, instructions how to separate the needed binary blob from the whole firmware.
Hi hnyman, thank's a lot for the reply. I didn't know the site and it helped me moving one step forward. I managed to compile the dsl_vr9_firmware_xdsl using the extracted firmware binary as described in the link. Now the next trouble is with drv_tapi-4.7.3.3.
The embedded installer at the web frontend don't like the openwrt-ltqcpe-squashfs.image file :-(
Are there chances to flash the image via serial connection or TFTP or so?
There is an function at image.mk which defines a function Image/mkfs/jffs2 which is never called.
Can I check how this function can be called, and perform this function?
I didn't continue working on it. I finally managed to compile the provided open source code. I needed to download a ton of additional open source libraries which were not provided with the Telekom package (which is no GPL compliant behaviour of Telekom I guess, but only authors of these packages can sue them). I didn't even try to flash the resulting image, because I was sure it wouldn't be accepted by the router. The original Telekom image on the router is somehow encrypted, and the build process of the provided open source package doesn't include this encryption routine.
The encryption method is a fixed key xor followed by a byte scrambling. The length of the xor key length is 160 bytes, but the key is changed after maybe 2 MB (?) (not sure if i remember correctly) of data.
In the process i gained some crypto knowledge (I'm not a crypto expert unfortunately), but not enough to get it decrypted completely. I was able to undo the scrambling. But I could only extract parts of the key (or better: the keys).
My guess is, that the installer embedded in the original firmware does the decryption, and then flashes the decrypted image. Other possibility would be, that the hardware itself does the decryption, and the encrypted firmware is directely flashed, and the installer only checkes if the firmware is correctly encrypted.
Thanks for your explanations about the decryption Sadly that's not my line - so I think someone other can try to decrypt the image. In my opinion I think the decryption is done at software. I looked at the GPL-sources of the type C of this device, an I found out, there is an binary called "imageupgrade" which is called via the webfrontend. This binary has a command line switch to decrypt (and flash) an given image. Maybe with this device it is similar. As you wrote, we don't know because of the incomplete sources.
So is there any chance to flash an compiled openwrt on this device (Sorry, I don't have some experience about openwrt, I've done only some freetz-ing)? Has someone checked the boot process via the serial command line? (At the wiki there is a big "yes" on the serial line feature). (Maybe I should do it, and provide some logs - if there are any available). 152ee80cbc
road to makkah pdf free download
face recognition dataset download