Firmware analysis is a fascinating area within the vast world of reverse engineering, although not very extended. Sometimes you end up in an impasse until noticing a minor (or major) detail you initially overlooked. That’s why sharing methods and findings is a great way to advance into this field.
While looking for certain information during a session of reversing, I came across this great post. There is little to add except for solving the ‘mystery’ behind that simple filesystem and mentioning a couple of technical details.
This file system is part of the WindRiver’s Web Server architecture for embedded devices, so you will likely find it inside firmwares based on VxWorks. It is known as MemFS (watch out, not the common MemFS) or Wind River management file system, and basically allows devices to serve files via the embedded web server without needing an ‘actual’ file system since this one lies on its non-volatile memory.
VxWorks provides pagepack, a tool used to transform any file intended to be served by a WindWeb server into C code. Therefore, a developer just compiles everything into the same firmware image.
From a reverser’s point of view, what we should find is the following structure:
There are a few things here worth mentioning:
- The header is not necessarily 12 but 8 so the third field seems optional.
- The first 4 bytes look like a flag field that may indicate, among other things, whether a file data will be compressed or not (1 = Compressed, 2 = Plain)
- The signature can vary between firmwares since it is defined by the constant ‘HTTP_UNIQUE_SIGNATURE’ , in fact, we may find this signature twice inside a firmware; the first one due to the .h where it is defined (close to other strings such as the webserver banner )and the second one already as part of the MemFS.
Hope these additional details help you on your future research.