Firmware Analysis Tools - Page 1
Forum section: electronics / projects

author: vandersonpc
author_rank: Contributor
timestamp: February 01, 2014, 01:37:24 pm
content: Hi Guys,Which kind of software tools do you guys use to analyse firmware binary files!?Currently I'm using the HxD hex viewer only! Is there any better tools out there!?Many Thanks!Cheers, Vanderson

author: marshallh
author_rank: Unknown
timestamp: February 01, 2014, 03:52:50 pm
content: winhex, xvi32, IDA

author: lapm
author_rank: Frequent Contributor
timestamp: February 01, 2014, 05:48:06 pm
content: I see lot has not change since 80's when i was kid and we hacked games... Hex displays..Only thing i would now days do different is to try dissemble the code to see what it really is doing. This how ever can be difficult depending how update firmware file is handled between uploading it to instrument and actually flashed into memory chip..

author: vandersonpc
author_rank: Contributor
timestamp: February 01, 2014, 06:31:25 pm
content: That's right! I'm currently trying to hack a firmware for the Uni-T DSO UTD2042C. No luck until know, but I'll keep working on that!Cheers,Vanderson

author: Stonent
author_rank: Super Contributor
timestamp: February 02, 2014, 02:11:01 pm
content: Mike seems to be pretty good at hacking firmware. You might watch his videos on the xray machine where he hacks the firmware to bypass the password.

author: hans
author_rank: Super Contributor
timestamp: February 02, 2014, 04:45:32 pm
content: IDA is a very universal disassembler for many platforms (not all..) which can also do some subroutine recognition, or figure out where constant/strings are being used where in the code. (so you can cross correlate stuff quickly).The newer IDA's can also decompile to pseudo-C on x86 and ARM, which means it's much easier to get an overview and "browse" through the code base. However, often code gets a bit obfuscated by compilers, and there are often no symbols (so variabeles are called like v1 through... whatever, v9999?)), so you have to very very stubborn to find what you're looking for. This process can take hours or days.Reverse engineering firmware is a very slow, time consuming and complex process. First priority: make sure you have the real unprotected binary image. You can stare until the cows come home on what you think is the firmware image, but it may not.Firmware update files may be compressed or encrypted in some way, trying to stop (*cough* slow down) hacks. To discover this, I always scroll through the binary file with a text editor and look for text and constants at the end of the FLASH file (or do CTRL+F and search for obvious strings, like branding, model names, etc., stuff you see in the interface). If they are in there; chances are it's not protected.If they aren't, it's probably compressed and/or encrypted. I usually figure out first if it's compressed. Compress the firmware file (again?) with something like 7zip or winrar. If the size drops by a huge amount (say 20%+) , chances are it's uncompressed but it may still be encrypted. It's not a certainty though; who knows what is combined into 1 FLASH image. They may include FPGA bitstreams, CPU and DSP programs. I've also used an entropy tool to figure out the entropy versus file position. High entropy = compressed data. Sometimes, "some" parts of the image is compressed, some are not, and are offset. So in that case, you have to write your own script and hit-and-miss find the compression type and binary offset (complex firmware images often include binary headers).Often they aren't going to write their own compression technique.This may not be very effective, but this is how I figured some things out by myself, and got the job done. In that case the firmware image was protected with standard inflate/deflate streams, which is probably sufficient protection for most, until you figure out they use inflate/deflate......Encryption can be rather though to break, and may require to 'investigate' some desktop tools instead. Often you need to know what encryption algorithm they use, and more importantly the keys. This is where I personally would give up, because things get very convoluted very quickly.Other shortcut is to get the firmware out of the device itself, if they haven't turned on code protection or use external FLASH devices. This isn't always possible though. After you have finally acquired the actual program, you can start "deeper investigation".I would first make sure you have real firmware in front of you, and then focus on disassembling that code and figure out what you want to know.I guess this is also how the Rigol's scopes have been hacked. It makes or breaks on being very stubborn to get through the huge jungle of unknowns.

author: vandersonpc
author_rank: Contributor
timestamp: February 03, 2014, 02:11:52 am
content: Hans,I don't think the Uni-T firmware files are protected or encrypted! I think the only security measure is the CRC to avoid the DSO model to be changed on the file header or something else inside file.I was not able to identify the location of this CRC inside file, but with your guys help we can achieve that! I included the firmware update file for you guys take a look!Cheers, Vanderson