Camera firmware reverse engineering

Why is this camera not able to take pictures in RAW, while in auto mode?

I own a Fuji X-T10 camera, and I asked myself this question a hundred times. This camera includes a tiny lever that locks it in full-auto mode. Just put it on "auto" before giving the camera to your wife, kids or strangers so they can take a picture of you, without having to be an advanced photographer. When you get the camera back, unclutch it to get full manual again!

Photo by Math on Unsplash

Unfortunately, this mode locks the pictures to JPEG only. And it would be really usefull to be able to get both JPEG and RAW files, because you still want to edit the pictures taken in auto mode. And there is the same restriction for all the special effects available in the camera. This is a software limitation, because camera always capture pictures in RAW (RAW just means raw sensor data), before compressing them to JPEG. It turns out that on the new X-S10, you can shoot in RAW while auto mode is enabled.

That's why I wish that camera makers publish their firmware sources. To be able to get rid of some restrictions they made, and this way make my camera more powerfull. But I guess they don't do it for several (arguably) good reasons:

Those sources contain some "industrial secrets" that give them some advantages over their concurrents. For instance eye or face detection, film simulations, noise reduction, or IBIS algorithms.
They keep new features or performance improvements for recent models to incentive people to switch to newer cameras. For instance, Fujifilm adds new film simulations to their brand new cameras, but don't backport them to previous ones. But people could also switch brand, so it might not be a winning situation for them.

For me, what makes a good camera is mostly fulfilled by physical aspects. Appart from out of the box jpeg quality and snapiness, I really pay attention to physical switches and dials, weight, handling. To me, firmware quality is a necessary but non-sufficient condition of a good camera.

So, I decided to make a bit of reverse engineering of a firmware update file. I have no experience at all in this field, so don't expect to find revolutionnary things in here. In the likely case that I fail to modify the firmware, at least I would have learnt something. For this first step, I just want to have a quick look and see what's going on in here.

I hope it will be fun though, and that you will learn nice stuff too!

Let's begin with the file utility (I'm using Linux, by the way). file reads the given file's header and compares it to known magic numbers to determine it's type:

> file FWUP0007.DAT 
FWUP0007.DAT: data

data just means that file dit not recognize any particular file type, and for it it's just a bunch of data. Let's see if we can find actual files bundled in it with binwalk. It works like file, but parses the whole file looking for known magic numbers (binwalk has a lot of other interesting features, as we will see later).

> binwalk FWUP0007.DAT 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1075178       0x1067EA        MySQL MISAM index file Version 3
1088215       0x109AD7        MySQL ISAM index file Version 9
1095021       0x10B56D        MySQL ISAM compressed data file Version 5
1103309       0x10D5CD        MySQL MISAM index file Version 4
1104101       0x10D8E5        MySQL ISAM compressed data file Version 6
1107096       0x10E498        MySQL MISAM index file Version 1
1110906       0x10F37A        MySQL MISAM index file Version 2
1111940       0x10F784        MySQL MISAM index file Version 9
1114746       0x11027A        MySQL MISAM index file Version 2
1115130       0x1103FA        MySQL MISAM index file Version 2
1116666       0x1109FA        MySQL MISAM index file Version 2
1118471       0x111107        MySQL MISAM index file Version 3
1118522       0x11113A        MySQL MISAM index file Version 2
1118796       0x11124C        MySQL MISAM index file Version 6
1119076       0x111364        MySQL MISAM index file Version 8
1119319       0x111457        MySQL MISAM index file Version 3
1119469       0x1114ED        MySQL MISAM compressed data file Version 8
1120442       0x1118BA        MySQL MISAM index file Version 2
2835533       0x2B444D        MySQL ISAM compressed data file Version 2
7262593       0x6ED181        Cisco IOS microcode, for "7["
7262677       0x6ED1D5        Cisco IOS microcode, for "L["
7262753       0x6ED221        Cisco IOS microcode, for "_["
7262821       0x6ED265        Cisco IOS microcode, for "p["

We got some results, but binwalk can be fooled by binary sequences that happen to match some magic numbers. It's very unlikely that our camera firmware contains Cisco microcode.

We can try the strings utility, that shows the "words" contained in a file. Let's look for the "fujifilm" word.

strings FWUP0007.DAT | grep -i fujifilm

No match. Also, strings by itself does not output any meaningfull text. At this point, I guess that the firmware is either compressed, obfuscated or encrypted, preventing to read clear data from it.

A way to identify the encryption method used is to look at the file entropy. Entropy can be defined as the level of randomness of the file data, between 0 (no randomness, like a block of repeating identical bytes) and 1 (total randomness). We can use binwalk again for this:

binwalk -E FWUP0007.DAT

We can see that the entropy level varies a lot which seems to indicate that no strong encryption was performed. The file could be rather obfuscated, maybe with a simple XOR operation. We can also see that in some areas of the file, the entropy is 0. This is maybe due to some padding that split the file in different functional aras.

It turns out that some people clever than me (or maybe more persistent) found that the Fuji X100 firmware is inverted with the NOT operation! And it's the same for the X-T10 firmware, and likely for many other Fuji cameras!

References:

Cover Photo by NordWood Themes on Unsplash