|
File-Spector project and can be found at
the SourceForge™
development web site under the links:
Project Home Page:
http://file-spector.sourceforge.net
Project Development Page:
https://sourceforge.net/projects/file-spector/
Current Developers:
- Bruno Santos ( bmsantos@users.sourceforge.net)
- Initial project idea
Please note that you are encouraged to join
and contribute in whatever you can and also to submit any
ideas or comments to this project.
Introduction
File-Spector is a small, fast and easy to
use binary file analyzer and Inspector. It allows the
user/developer to format a binary file and then use it to read
any binary file that matched the specified format.
What is it all about?
While working at GMV I
realised that the project that I was currently involved in
required a binary file reader to analyse and inspect the
several thousand fields and structure hierarchies involved in
each binary file. The most frustrating thing was that, for
every time we had a change of structure, we had to completely
change the binary file reader (fortunately I wasn’t involved
in this, since it seemed to be a head hake). Still, I came up
with the idea of developing something that would be generic
and that could be used to read any binary file that would
cross our way. Searching on the web, and until now, I’m still
not ware of any package or application that can do so and,
that’s precisely the idea of this tool. The most similar tools
are a simple hexadecimal editor and I, if I’m not mistaken, it
seems that ILOG also has a tool that allows a user to strip a
simple binary file.
File-Spector, by itself is nothing but a name for a group
of two other tools that complement themselves. It is a small,
fast and easy to use binary file analyser and inspector. The
main advantage is the modularity provided and it's extreme
scalability. Any user/programmer willing to extend it can do
so if, and for whatever reason the currently available
application nodes do not provide the necessary formatting to
its needs. In this case, and on any other case, the user is
most welcome to develop it himself or request for someone to
develop it for him.
Therefore, File-Spector isn’t another plain vanilla
hexadecimal editor that we all like to play with. The
File-Spector utility is composed by two main applications.
They are:
1)
Struct-A-File : With this tool the user is
able to easily specify the binary file format with it's
necessary ramifications and dependencies.
2)
File-A-Nyzer : Along with the format file
exported from the Struct-A-File application, this application
is able to read the intended binary file either in little
(currently only for PC) or bigendian formats. The user can
then browse through the data structures or simply plot some
data.
Programming Languages and modules
- Python ( http://www.python.org)
is the main development language to be used, although in the
future any other language such as C or C++ might be applied.
- wxPython ( http://www.wxpython.org)
for GUI development.
- wxPyPlot ( http://www.cyberus.ca/~g_will/wxPython/wxpyplot.html)
will be also used for simple data plotting. Developed mainly
by Gordon Williams and with "Use as you wish" license.
Target Platforms
At least on both Windows and Linux. Since the development
is mainly in Python and wxPython, then it should be easily
ported to any other platform supporting these two
technologies.
Major expected obstacles
The idea is to, and with similarity to any other XML or
HTML document, to strip down a binary file in a tree based
format. Each tree node will be configurable on its way,
pointing to other sub-nodes or node-dependencies. The
resulting tree is what I call the format file exported from
the " Struct-A-File"
application. The "File-A-Nyzer"
application will then parse any binary file according with the
rules defined in the format file.
It is impossible for one to guess how one organises its
binary format. Because of this the application should mainly
provide a simple common API based on simple classes that will
allow any user/programmer to extend accordingly with its needs
by developing the necessary node/s to be used on the format
tree. Therefore, modularity and its obvious influence in
scalability are the main obstacles for this project. That’s
why Python is a major piece of this project since it’s by
itself based on modularity.
The idea is then to use a "Visitor" style pattern to visit
"DataNode" object instances that define the format and
indicate how the field is supposed to be read and visualised.
The applications provide functionality common to every
node, and, the user/programmer will be able to interface with
them by importing the necessary modules.
|
