# Reverse engineering SREC firmware

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

• renesas.com/in/en/products/software-tools/tools/simulator/… Mar 1, 2019 at 3:25
• Try the Reverse Engineering Stack or consider writing your version from scratch... Mar 1, 2019 at 5:22
• Hex-Ray's Disassembler. Altrough you will spend months to get a tiny part of the program. Mar 1, 2019 at 7:25
• Don't upload it in s-record format? Or if this is all you have, take the s-record, download it into a M16C, then attach a debugger and dump the flash memory from there. Then translate from op codes to assembler. If the original code was written in C, which is likely, you'll have a nightmare reading it. Less so if originally written in assembler. Mar 1, 2019 at 14:43

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.

• "You have just over 8 kB of data there, so it's very likely an assembly-language program" Eh? What has program size to do with that? All you can conclude is that they probably didn't bloat the poor MCU with stdio.h or some madness like that. But otherwise it might as well be written in C. Note that these mid-range 16 bitters were quite code-efficient, so 8k will probably correspond to 20k or so of the equivalent, modern 32-bitter. Mar 1, 2019 at 14:46
• @Lundin: You may be right, but it really has no significant effect on the effort required to reverse-engineer the code to a level sufficient to make modifications to it. Mar 1, 2019 at 15:07

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.