bulk_extractor
bulk_extractor copied to clipboard
compiled windows executable does not have E01 compatibility
Hi Simson,
I'm having issues when cross compiling bulk_extractor to the win64 executable. It doesn't appear to compile with E01 compatibility
.
I've tested the linux binary which works with E01s fine so I believe it's isolated to the win64 executable or I'm not compiling it correctly.
I'd appreciate any support or guidance on this matter.
Thanks
How are you preparing the VM on which you are doing the compilation? Are you running our prep script? There are a lot of modules that need to be installed.
Cheers for the quick response.
The steps for compilation were as follows:
- Cloned the git repo to Fedora 35 VM
- Installed the submodules
- Ran bootstrap.sh
- Ran /src_win/CONFIGURE_FEDORA31.bash
- Ran make win64
- Copied bulk_extractor executable to windows machine and tested on E01
The prep script is: https://github.com/simsong/bulk_extractor/blob/main/etc/CONFIGURE_FEDORA34.bash
Not /src_win/CONFIGURE_FEDORA31.bash
Did you typo?
The prep script is: https://github.com/simsong/bulk_extractor/blob/main/etc/CONFIGURE_FEDORA34.bash
Not /src_win/CONFIGURE_FEDORA31.bash
Did you typo?
No this appears to be my mistake.
Are the instructions here -> https://github.com/simsong/bulk_extractor/wiki/Installing-bulk_extractor out of date? This is what I was following.
Let me retry with the up-to-date config script and report back
Thanks
Yes, that is out of date. Please feel free to update it.
So I've utilised the current prep script which successfully installed the libewf dependency for E01s, ran bootstrap.sh -> ./configure -> make win64 but the resulting executable is still incompatible with E01.
Any ideas?
Did you run on a clean VM, or one that you have used for other things? Which version of Fedora did you use? I need to modify the prep script to complain if libewf is not installed after it runs. Can you post your config.log here for me to review?
Sorry for the delayed response. The VM has been spun up specifically for cross compiling BE so it should be clean.
I'm running Fedora 35
Please see the attached config.log. You'll see at "configure:8767" it fails to get the libewf version and does not compile with E01 support although it seemingly finds libewf earlier in the compilation although I could be interpreting that incorrectly. Take a look and see what you think.
Thanks
Hi, I am facing a similar issue when using Fedora 36. The libewf appear to have issue.
Thanks for looking into this. There is a new, updated version of libewf that handles SSL3.0. Can you try this release? https://github.com/libyal/libewf/releases/tag/20230212
Thank you.
These changes should also be in the latest libewf stable https://github.com/libyal/libewf-legacy/releases/tag/20140814 (from July 2022) what version is being used?
Look like 20201230 was used that's the experimental version.
Hi, I am facing a similar issue when using Fedora 36. The libewf appear to have issue.
@nkl0x55 - are you trying to compile for Linux or cross-compile for Windows?
@simsong Hi, was trying to cross compile for Windows.
Steps taken:
- Prepare a fresh Fedora 36 VM
- Ran the Fedora 36 script found in the etc folder
- Encounter the error
Hi. The Fedora 36 script needs to be updated to use the more recent version of libewf.
Can you try this release? https://github.com/libyal/libewf/releases/tag/20230212
Hi, I tried updating the etc/paths.bash file to point to https://github.com/libyal/libewf/releases/download/20230212/libewf-experimental-20230212.tar.gz
However, error still occurred.
Attached is the log that I save. installation.log
Hi, @nkl0x55 . It's easier for the maintainer (@joachimmetz ) if you post the actual error, which is here:
ewftools_output.c: In function ‘ewftools_output_version_detailed_fprint’:
ewftools_output.c:244:10: error: ‘SHLIB_VERSION_NUMBER’ undeclared (first use in this function); did you mean ‘SSLEAY_VERSION_NUMBER’?
244 | SHLIB_VERSION_NUMBER );
| ^~~~~~~~~~~~~~~~~~~~
| SSLEAY_VERSION_NUMBER
ewftools_output.c:244:10: note: each undeclared identifier is reported only once for each function it appears in
@joachimmetz - this is cross-compiling on FC36 with mingw. My guess is that SHLIB_VERSION_NUMBER
doesn't exist when compiling as a linkable win32 library.
That should not matter, it's a pre-compilation macro that gets translated into a string.
It looks like installation.log uses CMake based make files to build libewf and not autotools? Not libewf's autotools based make files? or maybe the different looking output is due to the cross-compilation?
otherwise please attach config.log it should indicate what version of openssl configure detects
Also installation.log indicates that you're still trying to build version 20201230
make[1]: Leaving directory '/home/kl/Downloads/bulk_extractor-main/etc/libewf-20201230/ewftools'
Also installing libewf-legacy devel from the Fedora repo, can confuse the build process
libewf x86_64 20140608-23.fc36 fedora 552 k
libewf-devel x86_64 20140608-23.fc36 fedora 27 k
also if you only need the library for cross-compilation why not use make lib
instead of building everything ?
also if you only need the library for cross-compilation why not use
make lib
instead of building everything ?
Didn’t know it was an option.
@joachimmetz - what is the make install
target to install just the library? Otherwise make install
will cause everything to be made.
Good question make lib
is an alias for the autoconf/automake generated make library
so for install maybe make install-libLTLIBRARIES
. I would need to do some experimentation
Looks like make library
is something I might added in the past. I can have a look to see if I can add a corresponding make install-library
target
I have a PR that I think will build win32 with libewf, but the VM I was running it on wasn’t large enough, so I am still testing.
https://github.com/simsong/bulk_extractor/pull/386
Okay, I was able to test #386 and it has a problem:
x86_64-w64-mingw32-g++ -std=c++17 -DHAVE_CONFIG_H -I. -I../../src -I.. -I../../src/be20_api -DUNICODE -D_UNICODE -D__MSVCRT_VERSION__=0x0601 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -g --static -DUTC_OFFSET=+0000 -g -static-libstdc++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -Wno-format --static -static-libgcc -static-libstdc++ -pthread -Wall -MD -Wpointer-arith -Wshadow -Wwrite-strings -Wcast-align -Wredundant-decls -Wdisabled-optimization -Wfloat-equal -Wmultichar -Wmissing-noreturn -Woverloaded-virtual -Wsign-promo -funit-at-a-time -O3 -MT image_process.o -MD -MP -MF $depbase.Tpo -c -o image_process.o ../../src/image_process.cpp &&\
mv -f $depbase.Tpo $depbase.Po
../../src/image_process.cpp: In static member function 'static void process_ewf::local_e01_glob(std::filesystem::__cxx11::path, char***, int*)':
../../src/image_process.cpp:117:30: error: no matching function for call to 'std::__cxx11::basic_string<char>::basic_string(std::filesystem::__cxx11::path&)'
117 | std::string dirname(fname);
| ^
What's weird here is that it looks like we are using C++11 std::filesystem, even though we are clearly compiling with C++17. I'm in a low-connectivity environment and this is a high-demand weekend. Nevertheless, if I can get this working this weekend, I'll create a .exe that people can download.
Okay, https://github.com/simsong/bulk_extractor/pull/386 now compiles and runs. However, the test_be.exe
does not run under wine because of a pathname issue. Working on it.
Works.