Reverse engineering SREC firmware

Question

I have a firmware from a long discontinued product that I would like to improve on. The firmware is in a .mot file format (SREC from my research) and is uploaded using a tool called M16C asynchronous serial flash loader. From what I can tell the M16C specifies the type of micro controller. I attached the first three lines of the code below to show what the file looks like.

How would I start to go about extracting any useful information from this firmware so it could be modified? I assume it's not possible to go back to the source code that was originally compiled, but what can be accomplished from reverse engineering this? and what tools and software would point me in the right direction?

S0030000FC
S2240C0000FEFF0F00FEEF0F00FEDF0F00FEBF0F00FE9F0F00FE7F0F00FEFF0E00FEFF0D00C2
S21C0C0020FEFF0C00FEFF0B00FEFF0A00FEFF0900FEFF0800FEFF000097

Here is a dropbox link to the whole file if needed: https://www.dropbox.com/s/7tues99wdllkzc8/ThrottleControl.mot?dl=0

Answer 1

SRecord is, according to the website, "a collection of powerful tools for manipulating EPROM load files". The collection is free and runs on Windows and Linux. It's well documented and, once you understand the command line syntax, easy to use.

The collection contains the srec_cat program that can convert between many different programming file formats, including S-Record and binary. Once your S Records are converted into binary, assuming that you have documentation on what processor they run on, a disassembler can help you figure out what they contain.

Here is the man output.

Here are some examples on how to use srec_cat to convert between formats.

Answer 2

You have just over 8 kB of data there, so it's very likely an assembly-language program, not a high-level language. This will help a bit.

You need a disassembler, specific to the processor that's used in the product, to convert the hex data back into assembly-code mnemonics. However, the instruction arguments will simply be shown as numbers initially (data and addresses). It requires a lot of work and a fair amount of intuition to assign meaningful labels to those numbers.

My approach is to identify all of the separate subroutines and build up a "call tree" for the program overall. Then, using the instruction set manual, work out what the lowest-level subroutines do and give them meaningful names. This will assist with working out what the higher-level routines that call them do.

You'll eventually need an assembler (for the same processor) to convert your source code back into hex data. You can use this to verify your disassembly work prior to making any changes.

After making your changes, you'll need a programmer to put the new hex data into the product's memory.