In my previous post on the matter I have talked about using a Vodafone-branded Huawei R205 (E586) mobile hotspot with another network operator without needing any firmware modification or special tool except for a browser and the developer tools in there. I also let it understood that I have decided to sacrifice the device, because I have another similar device that I can use, more powerful, and anyway I should get a newer generation, as this one does not have 4G support at all.
Before I venture into the gory details of yet another personal project that will most likely not get to its end, let me point you all at Juan Carlos Jimenez’s series of posts reverse engineering another Huawei device. In his case, that was a significantly friendlier Huawei ADSL modem. I still consider that almost a prerequisite reading.
In my case, the device is a Vodafone R205 “Pocket Wifi” adapter, and as I said before it is, or was, common in at least Ireland, Italy and Australia, although with different colours (the Australian version is black, while the Irish and Italian are white). As I’ll show later (but actually a bit of Googling would have showed already), this device is actually a rebranded E586 mobile hotspot, which other providers, such as Three UK, also distributed.
I was honestly afraid I would end up breaking the device once I opened it. It turned out not to be the case, but anyway before doing that I decided to snoop around what I could from the outside, or rather, while connected to it. As showed in the previous post, the device does come with a lot of non-minified JavaScript written by Huawei engineers, which makes it particularly interesting. Indeed some of the files come with a very short changelog at the top, too:
/*******************************************************************************
File Name : vendorWifi.js
File Author : s00168237
Create time : 2011-09-27 05:49
Description : support Huawei API interface
Copyright : Copyright (C) 2008-2010 Huawei Tech.Co.,Ltd
History : 2011-09-27 1.0 create the file
version : R205 firmware v1.0 and webUI v0.41
release date: 2011-11-18
version : R205 firmware v2.0 and webUI v0.5
release date: 2011-12-19
version : R205 firmware v2.3 and webUI v0.51
release date: 2012-12-21
version : R205 firmware v2.6 and webUI v0.52
release date: 2012-01-06
version : R205 firmware v2.7 and webUI v0.52
release date: 2012-01-13
version : R205 firmware v3.0 and webUI v0.6
release date: 2012-01-16
date version author(No.) description
2012.03.29 FWv4.0 UIv1.12.3389 tangyao t81004060 for vodafone fireware v4.0
2012.04.24 FWv4.1 UIv1.14.3559 tangyao t81004060 for vodafone fireware v4.1
2012.04.25 FWv4.2 UIv1.14.3559 tangyao t81004060 for vodafone fireware v4.2
*******************************************************************************/Considering that the current Vodafone firmware (or should I say fireware) is 8.0, at least on the Australian website (the Irish one does not seem to have any), mine is significantly behind times. I have explicitly not updated it, afraid that they may have covered the hole that I have been using to configure the device.
There is also another interesting fact to note at this point: if you start Googling around you’ll find plenty of shady sites (Astalavista-shady I would say) that try to either sell to you or trick you into installing possible malware. What they promise is a way to de-brand the Vodafone R205 into a standard E586, which is indeed something nice to have, but as I said they are shady, so I have not bothered even considering them.
On the other hand it means that someone already managed to find a way to extract the firmware files from the Windows executable that Huawei provides, and reverse engineered the protocol that they use to flash the firmware onto the device. And they decided not to publish them, but rather make proprietary software bundled with Norton-knows-what. I find that extremely uncool, and on this, I’m definitely more aligned with the CCC crowd than what looks like your average mobile phone/broadband “hacker”.
Moving on, I decided to check for what may be open on the device. For instance if telnet or SSH were open it would make it easier to figure out ways around the device, but that didn’t help either. Indeed very few ports are open on the device: DNS, DHCP, HTTP and HTTPS (more in a second) and ports 1900 UDP and 50000 TCP for UPnP/IGD.
Nmap reports the following for the HTTPS configuration, which suggest a well expired certificate, since it is not valid after 2008, even though the firmware is clearly more recent (the changelog above reads 2012).
ssl-cert: Subject: commonName=ipwebs.interpeak.com/organizationName=Interpeak/stateOrProvinceName=Stockholm/countryName=SE
Issuer: commonName=Test CA/organizationName=Interpeak/stateOrProvinceName=Stockholm/countryName=SE
Public Key type: rsa
Public Key bits: 1024
Signature Algorithm: md5WithRSAEncryption
Not valid before: 2003-09-22T11:33:43
Not valid after: 2008-09-20T11:33:43
MD5: 2fcc e6cc bac8 8ea2 ca80 287f 2b8d 7d75
SHA-1: 7c6f 422e 37cb 83bf c3ef b004 f050 2c6f deba 6be2
ssl-date: 1970-01-01T00:20:18+00:00; -47y4d22h09m00s from scanner time.
sslv2:
SSLv2 supported
ciphers:
SSL2_RC4_128_WITH_MD5
SSL2_RC2_128_CBC_WITH_MD5
SSL2_DES_192_EDE3_CBC_WITH_MD5
SSL2_RC4_128_EXPORT40_WITH_MD5
SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
SSL2_DES_64_CBC_WITH_MD5Both the HTTP and the HTTPS ports report themselves as IPWEBS/1.4.0 (nmap considers this “Huawei broadband router http admin”, so I suppose they use it for their non-mobile routers too), and that matches the commonName found in the certificate.
Port 50000 (which is used by UPnP but responds to obvious HTTP requests, thanks SOAP), seem to have a different server altogether, with all headers shouted (all-capitals) and reporting itself as:
SERVER: PACKAGE_VERSION WIND version 2.8, UPnP/1.0, WindRiver SDK for UPnP devices/Both servers actually point to the same owners: Interpeak appears to have been bought by Wind River Systems (as you can see if you go to interpeak.com), I assume some time between 2003 and 2009, as the certificate is still pointing at the Swedish company, and in 2009, Wind River itself was bought by Intel.
My first thought (which came before realizing Interpeak was bought by Wind River) was that maybe the Intel UPnP SDK was derived off Wind River’s, but said SDK was last released in 2007, so it appears the two are unrelated. What I did not realize until I checked the Wikipedia page I linked, is that Wind River is actually the company behind VxWorks, which points almost straight at this device using VxWorks internally.
Turns out that there is an easy way to confirm this. You can find the firmware update packages online, on various Vodafone websites (different versions for different countries); these are Windows executables that look like installers, but are rather flasher applications. You can also find the update packages for the E586 (which is the same device, just without the Vodafone branding.
Though I have not found a way to extract the firmware from those files yet, I knew it was not overly complicated. There are scammy-looking sites that provide tools to flash unbranded firmware onto branded device (which is very similar to what I’m trying to look for anyway), but I would not trust those to the point of running them on any of my systems. So I turned to what every bored person with a little bit of understanding of reverse engineering would: binwalk.
While it has not been able to clearly identify something like “start of VxWorks firmware at address 0xdeadbeef”, it did have a very long list of random things starting from copyright strings and finishing with a lot of HTML fragments. This looked promising so I decided to run strings on the same file. The results were very promising and interesting. Starting from figuring out that the E586 firmware updater is written using Qt, and you can even find an XPM cursor in it (XPM, in a binary file, really? Sigh!).
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]] ]]]] ]]]]]]]]]] ]] ]]]] (R)
] ]]]]]]]]] ]]]]]] ]]]]]]]] ]] ]]]]
]] ]]]]]]] ]]]]]]]] ]]]]]] ] ]] ]]]]
]]] ]]]]] ] ]]] ] ]]]] ]]] ]]]]]]]]] ]]]] ]] ]]]] ]] ]]]]]
]]]] ]]] ]] ] ]]] ]] ]]]]] ]]]]]] ]] ]]]]]]] ]]]] ]] ]]]]
]]]]] ] ]]]] ]]]]] ]]]]]]]] ]]]] ]] ]]]] ]]]]]]] ]]]]
]]]]]] ]]]]] ]]]]]] ] ]]]]] ]]]] ]] ]]]] ]]]]]]]] ]]]]
]]]]]]] ]]]]] ] ]]]]]] ] ]]] ]]]] ]] ]]]] ]]]] ]]]] ]]]]
]]]]]]]] ]]]]] ]]] ]]]]]]] ] ]]]]]]] ]]]] ]]]] ]]]] ]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Development System
%s%s %s
]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]] KERNEL:
%s%s
]]]]]]]]]]]]]]]]]]]]]]]]] Copyright Wind River Systems, Inc., 1984-2005
Yes, I guess this firmware is based on VxWorks, if someone still had doubts. The strings are also quite telling, including the fact that the device comes with wpa_supplicant, and thus is likely able to operate as a Wireless client rather than just as an access point, which is going to be nice if I ever wanted to implement my proof of concept.
The firmware itself appears to have a lot of juicy information: in addition to the JavaScript (that does appear to be minified in the new firmware version) it provides a number of information on the webapp itself, and possible commands for the AT interface of the device. All of this is generally going to be more interesting if I can find out how to extract the actual firmware image from the device. I just need to find a working PE dumper tool and figure out which resource is exactly 32MiB in size.
Hopefully by the time I get to publish the next post in this series, I will have something more useful for everybody, either a way to flash the new firmware without the original tools, or access to the serial port on board of the device (spoilers!)