What techniques are used in reverse engineering embedded firmware?

Question

This question is related to another question I posted here.

I'm working with a small public transit agency on a neat open-source project that will help us to offer realtime data to local developers. A key piece of data we need is the current bus route a given vehicle is on. Currently, there is only a single electronic system that knows this information: the vehicle logic unit (VLU) that each vehicle is equipped with.

When a bus driver begins a route, they type its ID number into the keypad on the operator control unit (OCU). This ID number is sent to the VLU, which then displays the appropriate text on the LED signs on the bus.

On the OCU, there are two DB9F ports. In the manual, they are described as "J1708 PORTS". One of them is connected to the VLU, and the other one is available for me to plug in to. Connecting to it gets me some data that you can read about in my other question.

What I'd like to do is reverse engineer the firmware of the VLU and see how it decides what data to send or how to interpret received data. From what I can tell, the firmware is using RTTarget-32 as a base. I believe this is the case because the following strings can be found in the firmware file:

RTTarget-32 5.0 16-Bit Boot Code (c) 1996,2006 On Time Informatik
On Time RTOS-32 5.0 Disk Loader (c) 1996,2009 On Time

I didn't post a link to the firmware file because I know linking to external files is generally frowned upon on SE sites. If I should upload it, though, what file host should I use?

So, as my question title states, what techniques should I be using to begin reverse engineering this firmware file?

Answer 1

Reversing the firmware format can involve many different things, depending on the level of difficulty.

You would start with manual analysis with a hex editor.

If the data appears nicely structured, except for blocks that appear compressed (a few plaintext characters visible here and there), then it's probably not obfuscated.

If it appears like all gibberish with little or no structure (e.g. few runs of 0s), you'll need to disassemble the boot loader (dumped from the device) to extract the obfuscation algorithm, assuming you can't guess at it.

From there, start identifying the header fields and component parts of the firmware image. Most will have a kernel and a compressed file system. Often times there are offsets in the header, pointing to the components of the firmware.

You would want to try BinWalk, to see if it identifies any common components to the file format. It is designed for exactly this task. It generally works best on linux firmwares, which use common open source filesystems like squashfs or jffs2, but it's worth a try here.

Answer 2

On Time has an evaluation kit here that might help you learn more about it. It looks like it would be running on fairly standard hardware. Worst case you might have to dump an eeprom and decompile that with IDA or the like.

http://en.wikipedia.org/wiki/J1708

The protocol for those ports is open. So you could even communicate with it from your own code. Odd that it is RS-485 rather that RS-232 (its a bus version of RS-232 basically and you would probably need a different card to use it). The wiki page there lists possible higher level protocols you might try invesigating.