How to identify and use filesystem from embedded device's firmware image.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I wonder if anybody might be tell me how, or whether it's likely to be
possible to identify and mount the filesystem contained within the following
(gzipped) firmware image.
The device is a GSM VoIP gateway, which I have just received from the makers
in Taiwan. After running for 10 minutes, one is unable to connect to the web
configuration interface, and some time later (maybe another 15 minutes) SIP
calls do not pass through the device rendering it useless. I am hoping that
perhaps I can see something, or modify its firewall rules or something.

The firmware is located at http://www.css-networks.com/voip.gz or
alternatively directly from the manufacturer at
http://www.portech.com.tw/eweb/MV370/voip_DualBand.gz

I have emailed the manufacturer, and hopefully they will acknowledge the
problem and perhaps work on a fix for the firmware, or replace my unit if it
is deemed faulty. But as ever, being so far away in Taiwan, it could be the
case that I never hear back from them at all.

I'd really appreciate any help that anyone could give. I have g'unzipped the
file and tried mounting with -o loop -t cramfs/jffs2/ext2/ext3 etc. but have
had no joy.

thanks,
Carl



Re: How to identify and use filesystem from embedded device's firmware image.
Hello Carl,

I have looked at the firmware packet and to me it seams to be encryptet
or compressed. No readable text when view in a hexeditor which there
would be in case of a partition/disk image or executable file. The
magic cookie does not give any clue either.

Is there any telnet access, serial port or any other interesting
connectors. What processor is it based on and is the software in
onboard flash or in a seperate module.

Mogens

Carl Farrington skrev:

Quoted text here. Click to load it


Re: How to identify and use filesystem from embedded device's firmware image.

Quoted text here. Click to load it

Mogens, thanks for your reply. Did you remember to gunzip the file? I was
able to see lots of readable text towards the end of the file. Unfortunately
there is no telnet access or any kind of logging. There is a set of 12
solder pads on the board in the shape of a pin-header though (JP4 in picture
http://www2.css-networks.com/mv-370/1.jpg)

However, I spent a lot of time experimenting again last night, and I think
all is working now. The problem only seems to occur if I access the
web-console using Firefox (1.5.0.4 on Windows XP). This seems quite bizzare
but I wonder if firefox doesn't 'close' the TCP connections or something and
this causes some kind of too many connections DoS to the device.

Strange, but I have told the lady at Portech and she has forwarded my
message to the R&D dept. For now everything is working fine as long as I
don't enter the unit with Firefox.

Thanks for your response anyway. It would be interesting to have a look
inside. Telnet to port 23 just gives me the GSM modem's output. I see output
like the following, going round and round repeating itself:
AT+CSQ

TA-004AT+CLCC
 : CLI
AT+COPS?
AT+CLCC
AT^SCID
AT+CSQ



Re: How to identify and use filesystem from embedded device's firmware image.
Hello Carl,

Yes, I did gunzip it, but I didn't look thorougt it all (Sorry). Sounds
nice that you have a workaround to the problem.

Do you know which webserver it is using - e.g. test it by entering a
page which does not exists. They might not have implemented custom
error pages. If you find out which server they use you could checkout
if there is any known errors in it which can help you to gain access to
the box.

Also it would be worth the try to make a portscan e.g. with nmap to see
if they are listning on any other ports.

Since there is clear text in the image file it seams like a disk image
or partition image. If it is a disk image you can not mount it like you
already tried. The partition table have to be removed first, and since
we don't know the partition type it might be a hard task to ditermen
the size of it. A script using dd and removing 1 byte at the time and
testing with the mount command could be worth the test.

You could also take a look on the magic cookie in the image file and se
it makes any sense to you and google. :-) The 'file' command didn't
know the type though.

Mogens


Carl Farrington skrev:

Quoted text here. Click to load it


Site Timeline