I am trying to disassemble the firmware for the Cisco Sx300 switch as found here: https://software.cisco.com/download/release.html%3Fmdfid%3D283019611%26softwareid%3D282463181%26release%3D1.2.7.76
While some documentation for other iterations of Wind River's firmware exist, I have not encountered a working set of tools for this particular firmware.
Binwalk gives some results:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Cisco VxWorks firmware header, header size: 80 bytes, number of files: 15, image size: 6988894, firmware version: "1.2.7.76"
209 0xD1 LANCOM WWAN firmware
1483 0x5CB LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 16016448 bytes
3984149 0x3CCB15 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 859164 bytes
4153128 0x3F5F28 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2962457 bytes
4847723 0x49F86B LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2122505 bytes
6914211 0x6980A3 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 66664 bytes
6932632 0x69C898 XML document, version: "1.0"
6950635 0x6A0EEB LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 121427 bytes
However, extraction with the -e flag doesn't provide meaningful results. Several files are extracted, but others end up as corrupt archives, or file that are are too small to be actual files. I am not certain that the LZMA compressed data isn't false positive.
Disassembly with IDA fails, as I do not know the loader address.
This Cisco help resource suggests that there is some form of compression going on: https://supportforums.cisco.com/t5/small-business-support-documents/how-to-recover-a-reboot-loop-on-sx300/ta-p/3134953
This help support post confirms that the Firmware is ARM based, but I am not certain as to the exact make of the chip.
I am aware that previous iterations of the VxWork's Firmware had the loader address in the header. Analysis of the header did not find a useable address at the suggested location (0x14)
I attempted to match up the strings in the firmware to string tables and was not able to find any string tables, despite a thorough search. This supports my notion that it is compressed, or otherwise packed.
Lastly, I searched through the binary for probable addresses in order to deduce the loader address. I was not able to find any commonly referenced addresses or ranges. This was especially hard, as none of the binary was able to be correctly analyzed by IDA.
Am I missing something easy and fundamental here? Is there a special technique for VxWorks firmware?