8

When working with embedded systems, it is often easiest to use a downloadable firmware file rather than recover the firmware from the device.

Mostly these are ROM images in the form of a .bin file. Sometimes, they are Motorola SREC files (often called .s19 files or .mot files).

These are easily converted into bin files using many available tools. The SREC files tend to only contain records where there is actually data/code and the gaps are filled with padding values during conversion. Padding tends to be 0x00 or 0xFF.

This can gives us a hint about the data segment of the image - it allows us to tell if the memory has been initialised with 0x00/0xFF intentionally by the compiler/assembler, or if it is just padding. Sometimes this can make identifying data structures easier.

Is there anything else an SREC file can leak?

Improve this question

2 Answers 2

Reset to default
7

Correct me if I'm wrong, but since SREC is an ASCII representation of the binary data, wouldn't the corresponding binary file also "leak" sections of data that are padded with 0x00/0xFF?

With that said, yes, I think that in some cases SREC could expose useful information about the firmware that you wouldn't otherwise get with a binary image, assuming the vendor makes proper use of SREC's record types. Each line of text in an SREC file starts with a record code (S0, S1, S2, etc). Some example record types from Wikipedia's SREC page:

The S0 record data sequence contains vendor specific data rather than program data. String with file name and possibly version info.

Data sequence, depending on size of address needed. A 16-bit/64K system uses S1, 24-bit address uses S2 and full 32-bit uses S3.

The address field of the S7, S8, or S9 records may contain a starting address for the program.

Clearly, an SREC file provides information about the data in each record - information which normally would not be contained in a binary file. If you see an S7/8/9 record for example, you can probably assume that the firmware's entry point is located there. Likewise, the use of S2 vs S3 can tell you if the data contains 24 bit addresses or 32 bit addresses.

How common it is to use these different SREC record types in practice though, I couldn't say. A vendor could probably just mark everything with the same record type (S1 for example), which wouldn't really give you any more information about the data than a binary file would.

Improve this answer
1
  • Thanks. SREC files often seem to only contain the bare minimum required - so if there is a row of FFFFFFFF, something in the compiler has put it in there. It's often not much to go on though.
    – Cybergibbons
    May 19, 2013 at 21:11
6

Usually you only get addresses and raw bytes, but some tools/compilers may use custom record types or add extra information. For example, Tasking VX toolchain for Tricore uses an S0 record for identification:

S0-record

'S' '0' <length_byte> <2 bytes 0> <comment> <checksum_byte>

A linker generated S-record file starts with a S0 record with the following contents:

length_byte : 0x6
comment : ltc (TriCore linker)
checksum : 0xB6

        l t c
S00600006C7463B6

The S0 record is a comment record and does not contain relevant information for program execution.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.