确定固件二进制文件中包含的OS的最简单方法是什么？

#1 楼

注意：问题是这样的尝试非常针对一个人正在查看的文件。因此，在必要时，要偏离这里列出的路径，需要很多常识和大概的经验。

好吧，您有很多选择，我们所有人都可能对此有所了解。 br />

我将以file（此处为Windows版本）开头。
如果失败，我将在网络上搜索前8到16个字节的十六进制值以查看发生了什么。另外，我会输入适合我的情况的搜索字词。
没有产生任何结果，我将继续观察是否可以说服工具strings向我展示有用的东西（Sysinternals提供了Windows版本的字符串） 。这可能已经足够了。
但是，如果文件包含压缩或加密的Blob，我现在要带入firmware-mod-kit。它可以直接从SVN构建（仅在几天前进行了测试），包括binwalk，还可以解包一些initrd，而香草binwalk无法解包。或者，您可以尝试find-firmware.pl（或者通常是它的一部分脚本集）
全部失败，我将在支持某种二进制模板（例如010 Editor或免费软件Neo）的十六进制编辑器中打开文件。 ）。

...从那里我会寻找模式。这就是很难描述我如何打勾的地方，这是视觉上的事情。基本上，我会寻找偏移量，但是在某些情况下，00和非00的模式也会使我失望。另外，如果十六进制编辑器具有直方图功能，则我可能会使用直方图功能，以查看特定的数据块是否可能被加密或压缩（这两者都使字节值分布相对均匀）。知道平台（PPC）是Big Endian，因此我认为偏移量也将是Big Endian。这样将打开该设置，然后查看是否可以解码文件头之类的含义。如果可以，那么我将检查找到的所有斑点，看看是否可以从中识别出某种信息，例如压缩算法。例如，gzip具有特定的前导字节，而原始deflate除非程序员选择使用它们，否则不会。如果所有这些都失败了，我暂时必须假定这是其他某种压缩格式，并且将使用LZMA SDK作为参考来提出一种工作理论，该理论（通常是之前的binwalk步骤负责完成）那）。寻找这些指纹，我希望能够提取本身就是文件的blob，并且可以由外部工具处理。

如果所有这些先前的方法都将失败，我将着手查找应该在某种程度上了解文件格式的软件，例如将固件文件作为输入的固件刷新程序。

NB：如果固件blob来自驱动程序，例如在Linux中，您当然会先从该驱动程序中寻找线索。


原始答案（在很明显这是固件二进制文件之前）

我将从file命令开始（这里是Windows版本，这要感谢amccormack-参见他的评论）。它通常会告诉您构建操作系统（和内核等）的众所周知的可执行格式。

示例：

# On an AIX 5.3 machine
$ file python
python: executable (RISC System/6000) or object module not stripped
# Debian 6 on PPC64
$ file python
python: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, with unknown capability 0x41000000 = 0x13676e75, with unknown capability 0x10000 = 0xb0401, stripped
# Ubuntu 10.04, x64
$ file python
python: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
# Windows
>file C:\Python27\python.exe
C:\Python27\python.exe; PE32 executable for MS Windows (console) Intel 80386 32-bit

#2 楼

正如0xC0000022L已经指出的那样，字符串实际上是第一步。由于这是您直接从闪存芯片获得的转储，因此应该有一些可读的字符串（例如来自引导加载程序的字符串），除非已对其进行了加密。

您提到它是基于PPC的设备，因此您还可以搜索常见的PPC操作码（binwalk可以执行此操作，请指定-A选项）；您应该至少看到一些操作码弹出。

要检查的另一件事是二进制数据的熵（binwalk的-E选项可以做到这一点，许多其他工具也可以做到）。固件通常会压缩某些部分（例如内核和文件系统），这将在固件映像中显示为单独的非常高的熵部分。字符串和代码具有中等熵。加密的数据具有很高的熵。

设备的硬件也可以为您提供一些线索。闪存很少（例如2MB或更少）的设备不太可能运行大型操作系统，例如Linux。他们可能正在运行某种较小的RTOS。

还要考虑的另一件事是如何丢弃闪存，闪存是什么类型以及闪存芯片的数据总线。例如，在小端系统上以16位模式运行的并行闪存芯片每两个字节翻转一次。因此，如果您以16位模式原始读取芯片，则字符串“ ABCD”将被读出为“ BADC”。显然，这会搞乱任何基于签名的分析，并导致字符串看起来很陌生，但同时却不可读。

#3 楼

这不是火箭科学。 IDA不是用于进行此简单确定的工具。检查固件映像中找到的字符串。如果找不到任何内容，则可能会对它进行整体加密和/或压缩。无论哪种情况，请尝试Binwalk以获得其他帮助。固件中使用的文件系统类型也可能是一个线索。

此外，可能的选择不多。一些是（最常见的粗体）：




Linux（各种分支，uLinux，OpenWrt等）
VxWorks
BSD（各种分支机构，iOS就是其中之一）。
LynxOS
QNE
QNX
Windows CE
Windows NT Embedded


<<可能是VxWorks，这是WR54G（S）v5中使用的一种可能的标头数据结构，如此处所述。

////////////////////////////////////////////////////////////////
// Linksys VxWorks based firmware image format
#pragma pack(1)

typedef struct _VxFileDescriptor
{         
  DWORD nFileId_BigEnd;     // file type (see below)
  DWORD nFileSize_BigEnd;   
} VxFileDescriptor, *pVxFileDescriptor;

typedef struct _VxLinksysHeader
{
  DWORD nCodePattern;                        
  BYTE cUnknown_4[4];
  BYTE cYear;       
  BYTE cMonth;      
  BYTE cDay;        
  BYTE nProductVersion_0;   
  BYTE nMinorVersion_0;   
  BYTE cZUnknown_0D;
  BYTE cImageFormatVersion[4];    
  BYTE cZUnknown_12[238];  
  //
  // offset 0x100  -- begining of an secondary header?
  //  
  // After this point, all integers are stored big endian 
  // and should be read by endian neutral code 
  // (that is, read as big endian). 
  //
  BYTE nProductVersion_1;   
  BYTE nMinorVersion_1;     
  WORD nMajorVersion_1;       
  BYTE cZUnknown_104[2];  
  WORD nHeaderSizeBigEnd;
  DWORD nChecksumBigEnd; 
  BYTE cZUnknown_10B[2];  
  WORD nUnknown_10D;     
  BYTE cZUnknown_110[0x30]; 
  BYTE cModelName[0x20]; 
  BYTE cVendorName[0x20];
  VxFileDescriptor TrailingFiles[8]; 
    // parts of file that follow primary file descriptors 
  VxFileDescriptor FileDescriptors[8]; 
    // primary file descriptors, immediately follow header  
} VxLinksysHeader, *pVxLinksysHeader;

#4 楼

大多数操作系统中都有某种字符串，用于标识操作系统和版本。因此，通过使用十六进制编辑器查看文件，您通常可以识别os。否则，您需要搜索已知的签名/足迹。