compiled windows executable does not have E01 compatibility

[tomnewman86]

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

[simsong]

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.

[tomnewman86]

Cheers for the quick response.

The steps for compilation were as follows:

1. Cloned the git repo to Fedora 35 VM
2. Installed the submodules
3. Ran bootstrap.sh
4. Ran /src_win/CONFIGURE_FEDORA31.bash
5. Ran make win64
6. Copied bulk_extractor executable to windows machine and tested on E01

[simsong]

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?

[tomnewman86]

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

[simsong]

Yes, that is out of date. Please feel free to update it.

[tomnewman86]

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?

[simsong]

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?

[tomnewman86]

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

config.log

[nkl0x55]

Hi, I am facing a similar issue when using Fedora 36. The libewf appear to have issue.

[simsong]

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.

[joachimmetz]

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.

[simsong]

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?

[nkl0x55]

@simsong Hi, was trying to cross compile for Windows.

Steps taken:

1. Prepare a fresh Fedora 36 VM
2. Ran the Fedora 36 script found in the etc folder
3. Encounter the error

[simsong]

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

[nkl0x55]

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

[simsong]

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.

[joachimmetz]

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

[joachimmetz]

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'

[joachimmetz]

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

[joachimmetz]

also if you only need the library for cross-compilation why not use make lib instead of building everything ?

[simsong]

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.

[simsong]

@joachimmetz - what is the make install target to install just the library? Otherwise make install will cause everything to be made.

[joachimmetz]

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

[joachimmetz]

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

[simsong]

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

[simsong]

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.

[simsong]

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.

[simsong]

Works.