Introduction
Edit: Ok… as I was going to get some specific error codes to put on here (for searching sake) I was able to compile the solution no problem… Sigh… (Such is the life of compiling Libewf I suppose). The zlib requirement is still there, but I didn’t hit the dependency issue. I’ll leave this up so that I may have it for future reference (or if anybody else has these issues).
Ok, so yet another “how to” compile something posts. Whenever you get good software you always over look this step because generally the classic configure; make; make install; is all you need and you’re rocking and rolling. (you might have to do that a million times for each dependency), but in general its rare to come across something that won’t compile because the actual project file, or whatever organizing it is just completely messed up.
Libewf is probably one of the biggest backbones of the Digital Forensics community as it provides the underlying decompressing software for computer images compressed with Encase software. While this library is a dependency to many other tools it contains its own suite of tools for handling Encase Images. I needed the ability to acquire content in the E01 format so I decided to get the latest and use ewfacquire on a Windows machine. I had forgotten the pains of getting this guy to compile last time, and here I found myself again, having forgotten how I did it.
The Main Problems
There are three problems that plague this solution. A. zlib is missing (and you wouldn’t know it by looking at the solution file in visual studio, nor how to fix it without having a keen eye), B. The dependencies for the projects either are not setup, or they’re setup incorrectly, and C. most importantly its using Visual Studio / Windows.
The biggest problem, naturally, of this software is its using Visual Studio. God shoot me for compiling a C++ program with Visual Studio. Its the most annoying and esoteric setup you could possibly have. Since I did it in college (for one class, I wasn’t a computer science major), I had some idea how to link together projects and roughly what was going on, so I’m the “resident expert” for figuring out jacked up c++ solutions. I’m not sure who is the culprit of this problem. The writer of the software, or me for having to want to use it in Windows. (Probably its more like my problem).
The first problem is zlib. zLib is a library that provides adler32 compression. The source must be downloaded and placed into the proper location. This seems easy and obvious enough to do. Unfortunately unlike every other project/source you aren’t supposed to have it INSIDE the solution’s directory… This is a tricky thing to figure out and you’d only know it by looking at the solution file and look where the shortcuts are pointing to and instead of seeing ../../zlib its ../../../zlib.
The dependencies issue is either a new thing, or I don’t remember fixing it this way last time. The version i was using is the 20130416 version. What appears to be going on is the dependencies aren’t properly linked, it may be an issue with the “conversion” that Visual Studio has to do when you open it for the first time, I’m not entirely sure, I just know the projects are not hooked up correctly. If you do a build, they just don’t seem to link properly and you end up getting a bunch of unresolved symbol errors. Effectively it can’t find the DLL that it was expecting. If you look at the dependencies for the project they’re setup correctly, but its not until you look under references do you find the issue. (I have no idea what the difference is, I just know it fixed the problem).
The Fixes
Zlib
Real simple. Download zlib source and put it located in the same parent directory that contains the libewf source. (Don’t put it in the libewf source directory). Make sure that the folder name lines up with the project references.
Dependencies
For each problematic project you’ll need to add the “references” for them. You’ll have to right click on each project, go to References, add each project reference and make sure it says “copy local” (on the right). I basically kept trying to built it, it would fail then I would see the error, and note which file it was (based on the prefix) and made sure to add that as a reference. Eventually once all the references are in there, it’ll work. You could probably also just make all of them a reference and it might end up working.
Summing up
Well that’s all there is to it. That probably took me half a day of working to figure out and I know other people I work with have tried compiling this guy and none of succeeded. So now I have this as a reference for the next time I try and compile this tool… I should do another on running any libewf tool in Linux…. considering the LD_LIBRARY_PATH is always not set…… (I just gave the solution away).
Software and Forensics (And all things GNU) 