Wine, the Windows “emulator” March 24, 2008Posted by lizardo in Linux, Windows.
add a comment
Just saw some good news about Wine approaching 1.0 stable release. It remembered me of how capable Wine is now. Some years ago, I would try running an application under Wine and hope it would at least show something and not crash. Nowadays, when I find some Windows application I need to use, I first try running it under Wine and if it does not work as I like, I fall back to QEMU or VMWare. Hopefully, for most applications I have tried, Wine worked just fine.
Boomerang and gcov March 12, 2008Posted by lizardo in Reverse Engineering.
1 comment so far
Last night I tried enabling coverage in boomerang compilation. It seems it will not be as easy as I thought. Gcov is failing to find source files, although the .gcda and .gcno files are being generated and are on the correct location. Snippet from gcov error:
$ gcov c/ansi-c-parser.gcda -o c -b >/dev/null
ansi-c.y:cannot open source file
/usr/local/lib/bison.cc:cannot open source file
ansi-c-parser.cpp:cannot open source file
In this case the source file is in c/ansi-c-parser.cpp, but it insists on looking for it in the current directory. For this specific case, I figured out the errors are due to #line directives generated by bison++, but there are various errors like this. I’ll look into them at another time. Currently, I’m investigating unexpected errors reported by the functional testsuite (more on this later).
Boomerang testsuite March 11, 2008Posted by lizardo in Reverse Engineering.
add a comment
Last weekend I made my first code contribution to the Boomerang project: I fixed some tests from the testsuite that were segfaulting or failing due to changes in the debug output. After sending the patch to the mailing list, I was given write access to their CVS repository so I can now commit my fixes myself .
My plans for now are to:
- do test coverage analysis on the current code using gcov/lcov
- if coverage is not acceptable, add more tests to the testsuite
- when coverage become acceptable (I still need to define the acceptance criterion), I can then starting making improvements or more complex changes to the code
Of course, before doing any big changes that would affect current functionality, I will submit a patch to the list, so other developers can comment on it. That’s the “Open Source way” of development IMHO.
Research in reverse engineering March 8, 2008Posted by lizardo in Reverse Engineering.
I am about to graduate in Computer Science at Universidade Federal do Amazonas (UFAM), so I think I will now have more time to continue my personal research on some subjects I am interested in, but never found time to continue after I entered college.
One of these subjects is Reverse Engineering (RE). Before entering college, I played a little with RE and started a project on reverse engineering a driver for my scanner. It was quite challenging, and I liked it a lot, but never had time since then to either continue this project or start new ones.
Now it is time to change . During college I developed interest in Artificial Intelligence (IA) and ontologies. This (somehow ) led me to create interest in a research area known as “program comprehension” or “program understanding”. This is a research domain that, in my opinion, includes RE when it is applied to understanding how a system works. Therefore, my focus will be on applying RE techniques for program understanding.
As a first step, I started gathering some domain knowledge, but I would like to make something more pragmatic in parallel, so my studies could have a focus. I decided for now to work with the Boomerang decompiler and make some RE experiments with it. I chose it because It is, to my knowledge, the most advanced Open Source decompiler I am aware of, and decompilers can help understanding programs for which you don’t have sources. Of course, there are some other tools I would like to experiment with, such as Sparse.
I will probably make some kind of schedule so I don’t lose track during my research. More to follow!