Blog: Reverse Engineering

ARM Firmware Reverse Engineering

Christopher Wade 23 Apr 2017

Static Analysis

  • Debugging isn’t always feasible
  • It can provide insight into a device without physical access
  • Only works if you have a goal in mind

The Target – Scalance x200

  • Industrial network switch
  • Known exploits allow for dumping of configs and firmware
  • Unusual password hashes in configuration file
  • May be reversible encryption

Characteristics of the passwords

  • Small size
  • Variable depending on password size rounded to 8 characters
  • Heavily implies block cipher
  • 64-bit size implies DES or Blowfish
  • This could allow for reversible passwords
  • Admin user has two hashes

First Steps – Firmware payload

  • ARM ELF file, lots of data, not a lot of code
  • Binwalk finds “VxWorks” RTOS version string and compressed data
  • This implies the key firmware payload is compressed in the ELF

  • Hexdump of the decompressed binary shows that it is ARM firmware

Loading into IDA

Decompressed Firmware

  • Loading in IDA at address 0x00000000 does not yield a good disassembly
  • Not all function references are accurate
  • Lots of strings not accounted for

Finding the entry point and RAM

  • We don’t know the ARM MCU being used so don’t know the memory map
  • There are numerous techniques we can use, such as identifying switch cases in the code with absolute references however we can bypass this
  • The firmware is using VxWorks, so there’s a shortcut:

  • The VxWorks symbol table provides function references, which can be joined to strings
  • This provides debugging information about each function, and by identifying the sysInit function used at the start of firmware, one can find the entry point of the firmware
  • With a small IDC script, one can add the function references to every function in the firmware

  • RAM can be identified by values being set in the code, and will aid IDA with disassembling the remainder of the firmware
  • It will also help in identifying functions with similar memory references

Finding the password encryption

  • Find function references with the word password
  • Find any function calls which look like encryption
  • Trace the values loaded into the parameters before calling them, for ARM R0, R1, R2 etc
  • Try and decrypt the password

  • Blowfish function calls were identified in this function, proving that reversible encryption was used
  • A Blowfish test function was identified using specific constants which could be searched for on the internet, which allowed for identification of the exact Blowfish library used, which could be downloaded from GitHub

  • Using this information, one can trace the encryption key used for Blowfish, by identifying the value passed to register R1
  • Analysis of this showed that the encryption key was “ELS_key” however attempts to decrypt passwords using this string failed
  • Further analysis showed a second key was used, but could not be identified statically

When Static Analysis Isn’t Feasible

  • Dynamic analysis should be used by having access to the device and attaching a debugger
  • A Scalance switch was provided, and JTAG was identified on the board
  • Using the Segger GDB Server, it was possible to add breakpoints
  • From this, the exact variables used by the encryption could be identified
  • Decryption of the passwords was possible

Conclusion – The encryption algorithm used

  • The administrator password is encrypted with the static key “ELS_key”
  • The second administrator password is a static string “ELSDebug” which is encrypted with the plaintext administrator password
  • All other user passwords are encrypted with the plaintext administrator password
  • I couldn’t work this out via static analysis because it is stupid
  • Due to the reversible nature of the passwords, this was disclosed to Siemens