It’s amazing what you can find inside the RAM on embedded devices using a JTAG!
I’m currently dumping the RAM image of an energy usage monitor. So far I’ve seen OpenVPN keys and a few other interesting files still in memory.
With any luck I’ll get a copy of /etc/passwd 😉
I’ve been playing around with my old DroboPro and in the process managed to frag the uBoot config rendering the unit basically useless as the vxWorks side didn’t boot the special disk applications required for correction function. Fortunately I have another Drobo, in this case a Drobo FS. I was able to disassemble that (I didn’t even break the waranty void sticker) and gain access to the serial ports on the main board. From there I was able to read the Drobo FS uBoot config and use that to guess what the values needed to be for the DroboPro. After doing this the vxWorks side started working again 🙂
I also figured out what is up with the Drobo dashboard app. It definitely uses the serial number reported by the Drobo to determine the type unit it is talking to. It turns out the device type is the 5th from last digit, so if your serial number is TDBxxx7xxxx you have a Drobo FS for example.
0 = "Drobo"
1 = "Drobo S"
2 = "Drobo 5D"
3 = "Drobo Mini"
4 = "DroboPro"
5 = "B800i"
6 = "DroboElite"
7 = "Drobo FS"
8 = "Drobo 5N"
9 = "B800fs"
A = "DroboPro FS"
B = "B1200i"
So, how do I go about changing the serial number reported by the firmware? After a bit of messing around in the uBoot environment I discovered the
printenv command. This shows all the environment variables. It is then possible to track down the variable containing the serial number and change it to the desired value. Using the
saveenv command is not enough however, it is necessary to call another custom command
updateFlashToken to have the vxWorks side of things take notice of the new value.
The thing I did wrong was try out another of the custom commands
tdsetup. Don’t make the same mistake I made as it will frag all of the custom set up and leave you with a boat anchor. I was just lucky enough to have another one to examine to get the config back 🙂 I think I need to see if I can find a way to reload the firmware again as it appears I may have damaged something else as it is still not showing up quite right in the Drobo dashboard, but at least it is back to running the file server and so on 🙂
After working through it a bit more it appears that the problem is actually in the Drobo Dashboard. For some reason it is refusing to show the “Drobo ProFS”. I loaded up the 1.8.4 version of the Drobo Dashboard and it sees the unit just fine but doesn’t allow much to be configured. Maybe I will need to write my own client to get at all the functionality….
I recently saw a post somewhere that showed the internals of one of the newer high end Drobo machines. It appeared to use the same motherboard as the Drobo Pro I have sitting here on my desk gathering dust so I decided to take another look at what I could do with the thing. I had previously opened the machine up to get around the rebooting problem by disconnecting all the batteries with some success and in the process discovered the on board serial ports. It turns out they have a dual core processor in them running completely different OS code on each. One running Linux and the other running VXWorks. The linux one gives a plain old shell with lots of interesting stuff running on it. The VXWorks one doesn’t give much though. From what I can see the VWWorks side handles the actual disk access, while the Linux side handles the “UI” side of things, such as iSCSI on the Drobo Pro or file sharing on the Drobo Pro FS.
To get to the meat of the matter, I downloaded the firmware for the Drobo Pro FS and tried loading it into the Drobo Pro, which of course it rejected as I was expecting. I then had a look at the firmware files and saw they both had a very similar header. After patching the firmware file with the correct header values (an exercise for the reader to find the correct 12 bytes to alter) I was able to load the Drobo Pro FS firmware successfully into my Drobo Pro.
At first it didn’t seem to boot, but after putting some fresh disks in and rebooting the unit, up it came. 🙂 At the moment the device doesn’t show up in the Drobo Dashboard, but it does present a public share, so it’s not a complete loss. I also took the opportunity while I had a serial cable plugged into the board to enable the telnet and ssh servers to allow me to poke around some more.
It looks like the control software on the unit is expecting there to be two ethernet ports while the physical hardware only has 1. I may need to patch the binary…
I have to admit is a little disappointed with the phone when I got it. I updated the firmware as far as it would allow me, but the more recent versions of the software would not install 🙁 After a bit of googling I found that there was supposedly a procedure for updating the old firmware to one of the newer sets, but that it was a secret. That got me really interested so I dug a little deeper. I found a PDF that contained a link to a Yealink FTP server which I’m not sure is supposed to be publicly available. On the FTP server was a set of files that detailed in rather broken English the process. Basically you put the phone into a special mode that causes it to download a new firmware from a TFTP server running on the same network and off it goes with the new firmware.
My phone now says is has firmware version 184.108.40.206 and it now has all the features I was hoping to get. From what I can see it now has pretty much the same software as the new VP530.
Happy now 🙂
I also tested the technique used to get root on the old firmware and it is no longer available, however the technique used for the T38G now works.
Yesterday I took delivery of a Yealink VP-2009 VIOP phone. I was hoping it would be a nicer phone than it actually turned out to be. I have a Yealink T38G and was really happy with it. Unfortunately a lot of the features I like in the T38G are not present in the VP-2009. Ah well, live and learn I guess 😉
To the meat of it. When I plugged the new VP-2009 in to my network and attempted to configure it there was a weird caching issue with my browser as it took the same IP address as the old T38G which resulted in an error page being shown. Initially I thought the phone by broken in some strange way, so I started to investigate a firmware download for the phone. After extracting the firmware using binwalk I found the HTML for the web interface and found that there is a back door that allows arbitrary commands to be executed on the phone. The first thing I did was remove the password on the root user (
passwd -d root) so I was able to telnet into the device. Once on the device I was able to poke around and see all sorts of interesting stuff.
I was interested to see if there was anything like this back door in the T38G. It turns out there is, although it isn’t as easy to use as the one in the VP-2009. There is a hidden page that allows the telnet server to be turned on, and the same code can be exploited to remove the root user password 🙂
Time for bed. I’ve successfully hacked an app I need for work to do something it is not supposed to do 🙂 A little reverse engineering, byte patching and single stepping through machine code and I now have it being quite naughty 🙂
I’ve been using a new disassembler a lot over the last couple of weeks called Hopper. I’m finding it to be well worth the money. So much so that I initially purchased it through the Apple App store, and then purchased it again directly from the developer so I could get access to the latest version more quickly.
It has many of the features of IDA Pro at a fraction of the cost!