What's the easiest way to determine the OS contained in a firmware binary?

Question

I have pulled the Firmware binary from a PPC and have it loaded into IDA. Now I'm trying to determine what operating system it contains but don't know where to start.

Answer 1

NB: Problem is that such an endeavor is very specific to the file one is looking at. So a lot of common sense and presumably experience is required to deviate from the path outlined here when necessary.

Okay, you have numerous options, and all of us probably have kind of a recipe for this.

1. I for one would start with file (Windows version here).
2. Assuming that fails, I would search the web for the hex values of the first 8 to 16 bytes to see what comes up. In addition I would throw in search terms that fit my scenario.
3. That not yielding anything, I would proceed to see whether I can convince the tool strings to show me anything useful (there is a Windows version of strings at Sysinternals). This may be sufficient already.
4. However, if the file contains compressed or encrypted blobs, I would now bring in firmware-mod-kit. It'll build straight from SVN (tested it only a few days ago), comes with binwalk included and allows to also unpack some initrds which cannot be unpacked by the vanilla binwalk. Alternatively you can try find-firmware.pl (or in general the set of scripts of which it is part)
5. Failing all that, I would open the file in a hex editor that supports some kind of binary templates (e.g. 010 Editor or freeware Neo).

... from there I would look for patterns. And that's where it gets really hard to describe how I tick, it's a visual thing. Basically I would be looking for offsets, but the patterns of 00 and non-00 would also tip me off in some cases. Additionally I might use the histogram functionality, provided the hex editor has one, to see whether a particular blob of data is likely to be encrypted or compressed (which both makes for a relatively even distribution of the byte values). Knowing that the platform (PPC) is Big Endian, I would assume that the offsets will also be Big Endian. So that setting would be switched on and then I'll see whether I can decode the meaning of something like a file header. If I can, then I'll check all of the blobs that I find and see whether I can discern some kind of information from them, such as a compression algorithm. For example gzip has specific lead bytes, whereas raw deflate doesn't unless the programmer chose to use them. Failing all of that, I would have to assume this is some other compression format for the time being and would use the LZMA SDK as a reference to come up with a working theory which one (usually the binwalk step from before is responsible to do exactly that). Looking for fingerprints of these I would hopefully be able to extract the blobs that are files in their own right and can be handled by external tools.

If all of those previous methods would fail, I would set out to find a piece of software that is supposed to know the file format to some extent, such as a firmware flasher program which takes the firmware file as input.

NB: If your firmware blob comes from a driver, e.g. in Linux, you would of course start by looking into that driver for clues.

---

Original answer (before it was clear that this is a firmware binary)

I would start with the file command (Windows version here, thanks to amccormack - see his comment). It will usually tell you for the well-known executable formats for which OS (and kernel etc) it was built.

Example:

# 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

Answer 2

As 0xC0000022L already stated, strings is really the first step. Since this is a dump you obtained directly from the flash chip, there should be some readable strings (such as those from the bootloader for example), unless it is encrypted.

You mentioned it's a PPC based device, so you can also search for common PPC opcodes (binwalk can do this, specify the -A option); you should see at least some opcodes pop out.

Another thing to check is the entropy of the binary data (binwalk's -E option can do this, as can many other tools). It is typical for firmware to have certain sections (such as the kernel and file system) compressed, and this will show up as separate, very high entropy sections inside the firmware image. Strings and code have a medium-ish entropy. Encrypted data has very high entropy.

The hardware of the device can give you a bit of a clue as well. Devices with very little flash storage (say, 2MB or less) are unlikely to be running a large OS such as Linux for example; they are probably running a smaller RTOS of some kind.

Another thing to take into account is how you dumped the flash, what type of flash chip it is, and the flash chip's data bus. Parallel flash chips operating in 16-bit mode on little-endian systems for example have every two bytes flipped. So the string "ABCD" would be read out as "BADC" if you did a raw read of the chip in 16-bit mode. This would obviously mess up any signature-based analysis and cause strings to look oddly familiar yet simultaneously unreadable.

Answer 3

It isn't rocket science. IDA is not the tool to use for making this simple determination. Check the strings found in the firmware image. If you can't find any, it may be encrypted and/or compressed in its entirety. In either case, try Binwalk for additional assistance. The type of file system used in the firmware can also be a clue.

Also, there aren't but so many possible choices. Some are (most common in bold):

• Linux (various branches, uLinux, OpenWrt, ...)
• VxWorks
• BSD (various branches, iOS would be one)
• LynxOS
• QNE
• QNX
• Windows CE
• Windows NT embedded

To poster, since you say it may be VxWorks, here's one possible header data structure, as used in the WR54G(S)v5, as documented here.

////////////////////////////////////////////////////////////////
// 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;

Answer 4

Most operating Systems have some kind of string in it that identifies the os and version. So by looking at the file with a hex editor you can often identify the os. Else you'll need to search for known signatures/footprints.