Open ghost opened 7 years ago
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.
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?
There's always that chance, but it would seem unlikely from what I've seen. Do you know what CPU architecture the PLC uses?
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.
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.
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)
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.
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:
However, when these files are extracted using -Mre, all that I get out are files that are either empty or very small.