Reversing Vxworks image

Steps

Find out the size of the header in the vxworks file. (i removed 32 bytes of header)
Find out the rebase address of the program.  (rebase address was at offset 0x14 to 0x17)
    You can get it from the vxworks file header.
    You can get it from debug message displayed by the box .

Open the vxworks file in the idapro as binary file and change the "loading offset" to the rebased address.

Try to create the function (start autoanalysis now).
Write a simple python script to create all the missed function’s that start with "push bp…" combination.

Check whether you have symbol information, if you have that just use that to rename the functions and variables.

==============

Other Resources (mostly cut and paste from various resources)

I was wondering if anyone here has experience in reversing and generally making sense of the software running on embedded systems? Personally, I want to figure out what is running on standalone VoIP phones but I would imagine the principles are the same from analysing anything from toasters to mp3 players.

At the moment my questions extend to…

1. How do I figure out what OS is running? For Cisco VoIP phones I think this is some sort of VxWorks derivative but that is based entirely on hear-say
2. What is the best way to go about analysing this software. Is it best to start by grabbing some sort of firmware install, tossing it into IDA and working from there or is there a better way?
3. If firmware + IDA is the way to go, are there any decent tutorials on where to start? Having an asm disassembly is great and all but it’s not much use if you’ve no idea what the hell you’re looking at. I’m fairly experienced with REing ELF and PE binaries but I know nothing at all about the internal workings of the software running on such devices.

I’m going to have a look at some of the blackhat/defcon talks on analysing Cisco IOS soon-ish in the hope that they have a methodology that might/might not be applicable. We’ll see…..

Bleh,
nnp

================
Welcome to the world of no ELF or PE!

But seriously, embedded device RE does not look like, nor taste like malware-analysis except for a few fundamental tools in common (IDA Pro and your favorite hex editor.)

The only real way to start is to obtain a firmware image and begin the analysis in an outside to inside fashion.  Firmware analysis requires an even more strict layered approach in order to not potential miss a vital piece of information that will almost always accelerate later efforts.

Basically, what I recommend in familiarizing yourself with checksum algorithms (CRC16, CRC32, simple 32bit, etc) and compression algorithms – particularly focus on any and all magic bytes they exhibit.  From there you can begin to unravel a firmware image piece by piece. 

Generally, firmware will have a header and you can start to discern pieces of it fairly quickly after you have done it awhile.  What you want to look for (in no real particular order):
   * Image size – can be total image including the header or it can be an embedded portion of the image
   * Offset information – This, again, can vary widely from the start of an embedded image to the actual loading address of the firmware image itself
   * Checksum Data
   * Version information

If you obtain more than one version of the same firmware it makes the job of comparing potential header values a lot easier particularly when shown side-by-side in a hex editor capable of performing a binary diff. 

Last but not least of my ramblings – do not expect to get a nice and neat ELF/COFF file once you have extracted the firmware itself.  Generally all of that is stripped away and you end up with a flat binary.  The structure you will have to begin to introduce yourself.  Basically, if you can find the loading offset you can begin finding strings and references and hopefully start to discern what is going on.  If the firmware is based on VxWorks or something similar you will absolutely find strings elucidating this fact and then you can begin to understand VxWorks itself.

Good luck.  Sadly, information on this subject is, at best, non-existent.

=============
the original link seems to be dead but you can read an imported entry here that talked about reversing firmaware by matasano

http://www.woodmann.com/forum/showthread.php?t=11707

==============
Excellent, cheers guys. It would appear somebody else has at least started playing around with the firmware one VoIP phone already

http://www.voip-info.org/wiki/view/GXP-2000+Firmware+Hacking

If I come across anything interesting I’ll post it here and any other advice, links or info is appreciated.

Cheers,
nnp

======================
I was reading the comments on the blog entry mentioned by anonymouse through google’s cache and found a link that might be helpful.

http://igorsk.blogspot.com/2007/12/hacking-kindle-part-1-getting-console.html

Also, there’s another link in the post that seems dead but is viewable through archive.org

http://web.archive.org/web/20070825202509/http://www.matasano.com/log/147/why-i-love-vulnerability-analysis-in-2005/

================

Advertisements
This entry was posted in Reversing, Vxworks and tagged , . Bookmark the permalink.

One Response to Reversing Vxworks image

  1. Pingback: Vxworks | TagHall

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s