使用嵌入式系统时，通常最容易使用可下载的固件文件，而不是从设备恢复固件。
大多数情况下，这些是 .bin 文件形式的 ROM 映像。有时，它们是摩托罗拉 SREC 文件（通常称为 .s19 文件或 .mot 文件）。
这些可以使用许多可用工具轻松转换为 bin 文件。SREC 文件往往只包含实际存在数据/代码的记录，并且在转换过程中用填充值填充间隙。填充往往是 0x00 或 0xFF。
这可以为我们提供有关图像数据段的提示 - 它允许我们判断内存是否已被编译器/汇编器有意用 0x00/0xFF 初始化，或者它是否只是填充。有时这可以使识别数据结构更容易。
SREC 文件还有什么可以泄漏的吗？
如果我错了，请纠正我，但由于 SREC 是二进制数据的 ASCII 表示，因此相应的二进制文件不会“泄漏”填充有 0x00/0xFF 的数据部分吗？
话虽如此，是的，我认为在某些情况下，假设供应商正确使用 SREC 的记录类型，SREC 可以公开有关固件的有用信息，否则您不会通过二进制映像获得这些信息。SREC 文件中的每一行文本都以记录代码（S0、S1、S2 等）开头。来自维基百科SREC 页面的一些示例记录类型：
S0 记录数据序列包含供应商特定数据而不是程序数据。带有文件名和可能的版本信息的字符串。
数据序列，取决于所需地址的大小。16位/64K系统使用S1，24位地址使用S2，全32位使用S3。
S7、S8 或 S9 记录的地址字段可能包含程序的起始地址。
显然，SREC 文件提供有关每条记录中数据的信息——这些信息通常不会包含在二进制文件中。例如，如果您看到 S7/8/9 记录，您可能会假设固件的入口点位于那里。同样，使用 S2 与 S3 可以告诉您数据是包含 24 位地址还是 32 位地址。
不过，我不能说在实践中使用这些不同的 SREC 记录类型有多普遍。供应商可能只是用相同的记录类型（例如 S1）标记所有内容，这不会真正为您提供比二进制文件更多的关于数据的信息。
通常您只能获得地址和原始字节，但某些工具/编译器可能会使用自定义记录类型或添加额外信息。例如，Tricore 的 Tasking VX 工具链使用 S0 记录进行识别：
S0-记录
'S' '0' <length_byte> <2 bytes 0> <comment> <checksum_byte>链接器生成的 S-record 文件以 S0 记录开头，内容如下：
长度字节：0x6
注释：ltc（TriCore 链接器）
校验和：0xB6l t c S00600006C7463B6S0 记录为注释记录，不包含程序执行的相关信息。