Using binwalk to analyze PLC firmware

[ghost]

I was wondering if you have any information or have ventured into this area. I understand due to the critical nature of systems that implement PLCs that typically vendors try to keep people from reverse engineering their firmware. When I run binwalk on say this firmware. This is what I got from binwalk:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
33131         0x816B          LZMA compressed data, properties: 0xD0, dictionary size: 1048576 bytes, uncompressed size: 13510798884208640 bytes
34035         0x84F3          LZMA compressed data, properties: 0xA2, dictionary size: 33554432 bytes, uncompressed size: 2732199881 bytes
341411        0x535A3         LZMA compressed data, properties: 0xD8, dictionary size: 8388608 bytes, uncompressed size: 110500231412449280 bytes

However, when these files are extracted using -Mre, all that I get out are files that are either empty or very small.

[devttys0]

Those LZMA results are definitely false positives. I suspect you're either running an older version of binwalk or you don't have the python-lzma module installed (binwalk uses this to validate LZMA results), because my binwalk reports no results for this binary.

The reason for that is because there appears to be no compression or known file systems in this firmware image. There are a bunch of readable strings and what is probably code, but I'm not sure of the architecture. If you know the architecture I'd expect that you should be able to load this firmware image into a disassembler and start reversing.

[ghost]

So I've tried throwing it at IDA and it's not able to give me anything. Any chance it could obfuscated or encrypted even though there are strings?

[devttys0]

There's always that chance, but it would seem unlikely from what I've seen. Do you know what CPU architecture the PLC uses?

[ghost]

I've been trying to figure that out, but it doesn't seem to openly exposed by the vendor. My goal was to do this without having the physical PLC to determine this, but through device specifications.

[devttys0]

Without knowing the architecture, IDA isn't going to be much help. I haven't used it, but you might try cpu_rec; it claims to be able to identify a wide variety of architectures by analyzing the raw binary data.

[ghost]

I tried running cpu_rect at it, and it's giving me that it's seeing SuperH architecture. Never heard of it, but it makes sense considering that the company is Automation Direct and SuperH was developed by Hitachi. Now to find a disassembler for it.

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             None (size=0xa800)
43008         0xA800          SuperH (size=0x3000)
55296         0xD800          None (size=0x800)
57344         0xE000          SuperH (size=0x5000)
77824         0x13000         None (size=0x2000)
86016         0x15000         SuperH (size=0x14800)
169984        0x29800         None (size=0x800)
172032        0x2A000         SuperH (size=0x2000)
180224        0x2C000         None (size=0x2000)
188416        0x2E000         SuperH (size=0x1800)
194560        0x2F800         None (size=0x1000)
198656        0x30800         SuperH (size=0x1800)
204800        0x32000         None (size=0x1000)
208896        0x33000         SuperH (size=0x800)
210944        0x33800         None (size=0x3800)
225280        0x37000         SuperH (size=0x2000)
233472        0x39000         None (size=0x800)
235520        0x39800         SuperH (size=0x7000)
264192        0x40800         None (size=0x1800)
270336        0x42000         SuperH (size=0xa000)
311296        0x4C000         None (size=0x4000)
327680        0x50000         SuperH (size=0x5000)
348160        0x55000         None (size=0x800)

[devttys0]

Seems reasonable! I've dealt with SuperH before actually. Like MIPS it's a RISC architecture that has jump/branch delay slots, and IDA Pro supports it.