libyal / libewf-legacy Goto Github PK

Legacy version of libewf

License: GNU Lesser General Public License v3.0

Makefile 0.72% M4 6.18% Shell 2.47% C++ 3.21% C 85.34% Roff 1.19% Python 0.26% PowerShell 0.65%

libewf-legacy's Introduction

The name libyal was initially a pun on the naming theme of the various library 
projects. Now it serves the purpose of providing an overview of the available 
projects in a single location and as a home for scripts to help maintain the 
projects.

For more information see:

* Project documentation: https://github.com/libyal/libyal/wiki/Home
* Overiew of available projects: https://github.com/libyal/libyal/wiki/Overview

libewf-legacy's People

Contributors

Stargazers

Watchers

Forkers

sleuthkit ldgriffin hoyt-harness daichifukui bbkot

libewf-legacy's Issues

Fix support for ewftools-mt

ewftools-mt/Makefile.am:37: warning: source file '../ewftools/digest_hash.c' is in a subdirectory,
ewftools-mt/Makefile.am:37: but option 'subdir-objects' is disabled

State of EWF2/bzip2 support (and documentation)

ewfacquirestream -h
says bzip2 is supported only for EWF2 formats. According to the readme my understanding is that EWF2 formats are not supported (which would mean pbzip2 is not supported as well), but if that was true: why is bzip2 "supported" anyway? (maybe only for decryption like for mount ?)

Migrate to new test runner and test with asan

How to build a DLL?

Dear @joachimmetz

I reach out to you in the hope you could guide me a little.

I've spent much of the weekend attempting to compile a DLL for Windows of the latest "legacy release" of the library.

I first did so (in error I think) from the "Releases" section using the experimental release to try and get a V3 DLL. That compiled OK, I got a libewf-v3.dll file, but I can't load it with my LoadLibrary routines. It keeps returning zero (nil handle).

So having spent a while longer trying to find a pre-compiled DLL, I read one of your posts where you rightly point out we should be using the legacy releases. So I downloaded that from https://github.com/libyal/libewf-legacy/releases and recompiled. And I got a libewf-v2.dll which would have been fine as I only need the E01 verification routines anyway.

But again, my LoadLibrary routine just keeps returning zero.

So after spending several hours convinced my calls to LoadLibrary routines must be incorrect, and going through with the debugger, I used Depenancy Walker to look at the generated DLLs. DW reports several "errors" (I'm not sure if they are actually proper errors or not but it does not look happy). And I have insufficient experience at DLL compilation to work out how to correct them, or even find them. There seems to be lots of failings, which I am sure will be my fault. Birds eye view in the screenshot.

Strangely though, I can't even load an older version of the DLL that I made back in 2015. Which makes me wonder if it relates to something to do with Windows 10

I also tried (for the first time) to compile it using Visual Studio 2019 by cloning the repository
libewf-DLLs.zip
but that also listed dozens of errors and I don't really know what I'm doing. So it is probably me.

Suffice to say : is there any scope for you, as the developer, to helpfully compile a release DLL for users that can be added to the repository here, to simply download? It would certainly save folks who want to use the library with their tools some considerable pain (your comments here are of course noted). If not, do you happen to know what I may be doing wrong? I am using Windows 10 x64, with the MSYS2 MinGW 64-bit compiler and the following configure line : CPPFLAGS=-DWINVER=0x0501 ./configure --prefix=/mingw followed by make. The resulting DLL's all look spiffing and valid, except for what Dependency Walker says.

As it stands right now, sadly I am thinking I might just have abandon the effort which seems rather tragic considering the immense power and effort that has gone into creating the library. I have attached the v2 DLL, in case anyone reading has the skills to confirm if it is a valid DLL, or not.
libewf-DLLs.zip

Question related different libewf versions

Created test program which performs linear read of the e01 image (reads 4096 byte sectors from beginning to end ). Noticed that libewf version 20171104 and 20150126, are twice slower than version 20130416. Is it any method to improve performance using 20171104, or maybe I should use different version of the libewf library ?

Unable to acquire input. libmfdata_array_resize: invalid entries size value exceeds maximum.

Hi,

The following acquiry parameters were provided:
Image path and filename:		/backup/hdd1.E01
Case number:				
Description:				
Evidence number:			
Examiner name:				
Notes:					
Media type:				fixed disk
Is physical:				yes
EWF file format:			EnCase 6 (.E01)
Compression method:			deflate
Compression level:			none
Acquiry start offset:			0
Number of bytes to acquire:		5.4 TiB (5997921828864 bytes)
Evidence segment file size:		1.4 GiB (1572864000 bytes)
Bytes per sector:			512
Block size:				64 sectors
Error granularity:			64 sectors
Retries on read error:			2
Zero sectors on read error:		no

results in:

Acquiry started at: May 03, 2023 13:58:45
This could take a while.

Acquiry failed at: May 03, 2023 13:58:45
Unable to acquire input.
libmfdata_array_resize: invalid entries size value exceeds maximum.
libmfdata_list_resize: unable to resize elements array.
libewf_write_io_handle_write_new_chunk: unable to resize chunk table.
libewf_handle_write_buffer: unable to write new chunk.
imaging_handle_write_buffer: unable to write storage media buffer.
ewfacquire_read_input: unable to write data to file.
Unable to close output file(s).
libmfdata_array_resize: invalid entries size value exceeds maximum.
libmfdata_list_resize: unable to resize elements array.
libewf_write_io_handle_write_new_chunk: unable to resize chunk table.
libewf_handle_write_finalize: unable to write new chunk.
libewf_handle_close: unable to finalize write.
imaging_handle_close: unable to close output handle.

If the bytes to aquire is reduced, it will work:

Image path and filename:		/backup/hdd1.E01
Case number:				
Description:				
Evidence number:			
Examiner name:				
Notes:					
Media type:				fixed disk
Is physical:				yes
EWF file format:			EnCase 6 (.E01)
Compression method:			deflate
Compression level:			none
Acquiry start offset:			0
Number of bytes to acquire:		286 MiB (300000000 bytes)
Evidence segment file size:		1.4 GiB (1572864000 bytes)
Bytes per sector:			512
Block size:				64 sectors
Error granularity:			64 sectors
Retries on read error:			2
Zero sectors on read error:		no

Continue acquiry with these values (yes, no) [yes]: 

Acquiry started at: May 03, 2023 14:00:45
This could take a while.

Status: at 50%.
        acquired 144 MiB (151650304 bytes) of total 286 MiB (300000000 bytes).
        completion in 4 second(s) with 35 MiB/s (37500000 bytes/second).

Acquiry completed at: May 03, 2023 14:00:52

Written: 286 MiB (300001316 bytes) in 7 second(s) with 40 MiB/s (42857330 bytes/second).
MD5 hash calculated over data:		6f0250647748b3925ba1738e0bfdc883
ewfacquire: SUCCESS

Also everything < 4 TB will work.

Is there some more elegant way to get this done, but to manipulate the starting offset to virtually slice the device in multiple logical parts?

Thank you and great project work!

Greetings
Oliver

Question: How large of an L01 is libewf capable of opening?

I have an L01 that is 525GB+ in size that cannot be opened (error is libewf_handle_get_root_file_entry: invalid handle - missing single files.) was wondering if there is a limit? Reviewing the code but asking in case there is a quick answer, it's also possible that the L01 was corrupted but smaller L01's seem to be ok.

ewfmount for images using guymager

I have already acquired hardisk (linux-system) using guymager and saved with EWF format.
I got trouble to mount the image file to mount point using ewfmount command.
This is the error log:
[root@ADIA forensics-test]# ewfmount /mnt/hgfs/OSI/DE01/serverRepo.E* /mnt/source/
ewfmount 20140806

Unable to open source image(s)
libcdata_internal_array_resize: invalid entries size value exceeds maximum.
libcdata_array_resize: unable to resize array.
libmfdata_list_resize: unable to resize elements array.
libewf_segment_file_read_volume_section: unable to resize chunk table list.
libewf_handle_open_read_segment_files: unable to read section: volume.
libewf_handle_open_file_io_pool: unable to read segment files.
libewf_handle_open: unable to open handle using a file IO pool.
mount_handle_open: unable to open file(s).

I tried to used the vmware from this
https://forensics.cert.org/appliance/ADIA-CentOS7-x86_64-VMware.ova
and
https://forensics.cert.org/3-all_announcements.html
sudo yum-config-manager --enable forensics-test

I am not use that already used the latest version
This is the log:
[root@ADIA forensics-test]# ewfmount -V
ewfmount 20140806

Copyright (C) 2006-2019, Joachim Metz.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Report bugs to [email protected].

Thank you for your help.

libcdata_internal_array_resize: invalid entries size value exceeds maximum.

I saved a suspected defective external drive with guymager. (To ewf image : multiple E01, E02, E03, etc, Exx files)

I can mount the RAW data of the backup on my linux mint 19.02 computer with xmount v0.7.3:

xmount --version

WARNING: Your system does not seem to have a "fuse" group. If mounting works, you can ignore this message.

WARNING: FUSE will not allow other users nor root to access your virtual harddisk image. To change this behavior, please add "user_allow_other" to /etc/fuse.conf or execute xmount as root.

xmount v0.7.3 Copyright (c) 2008-2014 by Gillen Daniel <[email protected]>

  compile timestamp: Apr  3 2018 12:52:49
  gcc version: 7.3.0
  loaded input libraries:
    - libxmount_input_aaff.so supporting "aaff"
    - libxmount_input_aff.so supporting "aff"
    - libxmount_input_aewf.so supporting "aewf"
    - libxmount_input_raw.so supporting "raw", "dd"
    - libxmount_input_ewf.so supporting "ewf"
  loaded morphing libraries:
    - libxmount_morphing_raid.so supporting "raid0"
    - libxmount_morphing_unallocated.so supporting "unallocated"
    - libxmount_morphing_combine.so supporting "combine"

But not on an other computer on a linux mint 20.2 USB live with xmount v0.7.6.

xmount --version

WARNING: FUSE will not allow other users nor root to access your virtual harddisk image. To change this behavior, please add "user_allow_other" to /etc/fuse.conf or execute xmount as root.

xmount v0.7.6 Copyright (c) 2008-2018 by Gillen Daniel <[email protected]>

  compile timestamp: Sep  2 2018 12:00:15
  gcc version: 8.2.0
  loaded input libraries:
    - libxmount_input_raw.so supporting "raw", "dd"
    - libxmount_input_ewf.so supporting "ewf"
    - libxmount_input_aff.so supporting "aff"
    - libxmount_input_aewf.so supporting "aewf"
    - libxmount_input_aaff.so supporting "aaff"
  loaded morphing libraries:
    - libxmount_morphing_unallocated.so supporting "unallocated"
    - libxmount_morphing_raid.so supporting "raid0"
    - libxmount_morphing_combine.so supporting "combine"

I get this error:

sudo xmount --in ewf /media/veracrypt1/xxx.E?? --out raw /home/mint/mntxxxRAW/
ERROR: main@3692 : Unable to open input image file '/media/veracrypt1/xxx.E01': Unable to open EWF file(s)!

I have this strange behavior only with this specific drive image. All other drives images I have done the same way on the same day, are working with both versions of xmount. This drive is the larger one 1TB for 870GB total of image files (2.1GB files).

Maybe this doesn't comes directly from xmount : on the computer with the 0.7.6 xmount version, I tried it with ewfmount (20140807 version):

ewfmount /media/veracrypt1/xxx.E01 /home/mint/mntxxxRAW/

And get this error:

Unable to open source image(s)
libcdata_internal_array_resize: invalid entries size value exceeds maximum.
libcdata_array_resize: unable to resize array.
libmfdata_list_resize: unable to resize elements array.
libewf_segment_file_read_volume_section: unable to resize chunk table list.
libewf_handle_open_read_segment_files: unable to read section: volume.
libewf_handle_open_file_io_pool: unable to read segment files.
libewf_handle_open: unable to open handle using a file IO pool.
mount_handle_open: unable to open file(s).

On the computer where it works:

apt-cache policy libewf2
libewf2:
  Installé : 20140608-6.1build1

apt-cache policy ewf-tools
ewf-tools:
  Installé : 20140608-6.1build1

On the computer where it doesn't works:

apt-cache policy libewf2
libewf2:
  Installé : 20140807-2build1

apt-cache policy ewf-tools
ewf-tools:
  Installé : 20140807-2build1

Any idea why it works on older version but not on newer?

I found this issues talking about similar problems:

But I'm too noob to understand what to do or to install an other version. Could you please drive me?

Thanks for having read, Sorry for my bad English level :/

ewfaquire libcdata_internal_array_resize: invalid entries size value exceeds maximum

Version 20140808 installed via brew

command ewfaquire -t %destpath% -c fast /dev/rdisk5
Error message:
Unable to aquire input.
libcdata_internal_array_resize: invalid entries size value exceeds maximum.
...
Unable to close output file(s).
libcdata_internal_array_resize: invalid entries size value exceeds maximum.
...

(shortened as I need to type it from screen of a airgapped system, let me know if you need more lines.)

functional dd version:
dd if=/dev/rdisk5 bs=1m | ewfaquirestream -t %destpath% -c fast

rdisk6, which is synthesized from disk 6, works. Maybe the "synthesization" is cause of the issue?

Unable to build HEAD on Mac OS X 12.4

Making all in libcaes
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../common  -I../include -I../common -I../libcerror    -I/usr/local/opt/[email protected]/include -I/usr/local/include -I/opt/macports/include -Wall -MT libcaes_context.lo -MD -MP -MF .deps/libcaes_context.Tpo -c -o libcaes_context.lo libcaes_context.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../common -I../include -I../common -I../libcerror -I/usr/local/opt/[email protected]/include -I/usr/local/include -I/opt/macports/include -Wall -MT libcaes_context.lo -MD -MP -MF .deps/libcaes_context.Tpo -c libcaes_context.c  -fno-common -DPIC -o .libs/libcaes_context.o
libcaes_context.c:358:6: error: use of undeclared identifier 'libcaes_tables_initialized'; did you mean 'libcaes_context_initialize'?
        if( libcaes_tables_initialized == 0 )
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
            libcaes_context_initialize
libcaes_context.c:262:5: note: 'libcaes_context_initialize' declared here
int libcaes_context_initialize(
    ^
libcaes_context.c:372:3: error: use of undeclared identifier 'libcaes_tables_initialized'
                libcaes_tables_initialized = 1;
                ^
libcaes_context.c:3062:5: error: implicit declaration of function 'libcaes_calculate_forward_table_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                                libcaes_calculate_forward_table_round(
                                ^
libcaes_context.c:3078:4: error: implicit declaration of function 'libcaes_calculate_forward_table_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                        libcaes_calculate_forward_table_round(
                        ^
libcaes_context.c:3086:4: error: implicit declaration of function 'libcaes_calculate_forward_substitution_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                        libcaes_calculate_forward_substitution_round(
                        ^
libcaes_context.c:3086:4: note: did you mean 'libcaes_calculate_forward_table_round'?
libcaes_context.c:3062:5: note: 'libcaes_calculate_forward_table_round' declared here
                                libcaes_calculate_forward_table_round(
                                ^
libcaes_context.c:3098:5: error: implicit declaration of function 'libcaes_calculate_reverse_table_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                                libcaes_calculate_reverse_table_round(
                                ^
libcaes_context.c:3114:4: error: implicit declaration of function 'libcaes_calculate_reverse_table_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                        libcaes_calculate_reverse_table_round(
                        ^
libcaes_context.c:3122:4: error: implicit declaration of function 'libcaes_calculate_reverse_substitution_round' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                        libcaes_calculate_reverse_substitution_round(
                        ^
libcaes_context.c:3122:4: note: did you mean 'libcaes_calculate_reverse_table_round'?
libcaes_context.c:3098:5: note: 'libcaes_calculate_reverse_table_round' declared here
                                libcaes_calculate_reverse_table_round(
                                ^
8 errors generated.
make[1]: *** [libcaes_context.lo] Error 1

Need help troubleshooting high memory usage issue

Hi @joachimmetz. First, thank you very much for your work with this great library.

Using latest released version 20140812, seems it could be leaking memory reading large E01 images. This was first reported in our project here:
sepinf-inc/IPED#993

Are you aware of some related issue? We would like some advice from you if possible, can libewf-experimental-20201230 be used for production? Or is libewf-legacy or other stable libewf version still trying to fix memory leaks when confirmed?

Thank you very much in advance.

ewfverify ETA more than 5 days on 1TB E01?

Hi,
I am currently running ewfverify on a 1TB E01 file which is segmented into 2GB chunks. The E01 file is stored on a new 1TB 3.5" 7200RPM Seagate HDD that is connected from a HDD Caddy, via a USB 3.0 cable, to an Ubuntu virtual machine, where the verification is being run.

The verification started at an expected speed (based on my previous attempts), verifying at ~150 MiB/s.
However, at about 20% completion, the verification has slowed right down to less than 3 MiB/s and has not increased for the last 24hours. The total verified is increasing, but very slowly and at this current speed, with ewfveryify is saying it will complete in 3 day's time. I have done this in the past and not seen the speed drop this low.

Could you please help identify if this is an issue with ewfverify on large images, or wheteher it is an issue with the hardware or other set up I am using (considering I have done this previous with an equally large sample and have it complete in about a day).

libewf_handle_get_utf8_hash_value returns 1 on Windows but -1 on Linux

Dear @joachimmetz

I making great progress with the library, and I am sorry to keep coming back posing questions.

Last night I was up into the early hours trying to debug a mysterious issue.

My implementation of the library computes the E01 hash, and that is working perfectly. And on Windows, it also successfully looks up the existing embedded MD5 or SHA1 hash. However, on Linux, the exact same routine returns -1.

Forgive me as I know you're a C developer. I use a modern object orientated version of Pascal called FreePascal (please, no jokes about how old Pascal is). But I hope you will still be able to see what is happening.

Tlibewfhandlegetutf8hashvalue     = function(handle : PLIBEWFHDL;identifier:pansichar;identifier_length:TSIZE;utf8_string:pansichar;utf8_string_length:TSIZE; error:pointer) : integer; cdecl;
 TLibEWF = class(TObject)
  private              
   flibewfhandlegetutf8hashvalue              : Tlibewfhandlegetutf8hashvalue;  

 TLibEWF.Create
//etc etc
 @flibewfhandlegetutf8hashvalue     :=GetProcAddress(fLibHandle,'libewf_handle_get_utf8_hash_value'); 

// Calls libewfhandlegetutf8hashvalue
function TLibEWF.libewf_GetHashValue(identifier:ansistring;var value:ansistring) : integer;
var
  err:pointer;
  p:pansichar;
  l:tsize;
begin
  err:=nil;
  Result:=-1;
  if fLibHandle<>0 then
  begin
  getmem(p,255);
  if LIBEWF_VERSION='V2' then

  Result:=flibewfhandlegetutf8hashvalue(fCurEWFHandle,
                                          pansichar(identifier),
                                          length(identifier),
                                          p,
                                          l,
                                          @err);
  if result=1 then value:=strpas(p);
  FreeMemory(p);
  end;
end;        

// Call libewf_GetHashValue
var
  strCurrentMD5HashVal : string = Default(string); // declaring as ansistring specifically makes no difference here. Same debug data. (https://wiki.freepascal.org/Character_and_string_types#String) because program is compiled with {$H} switch

begin
// Other stuff goes on first and towards then towards the end I lookup the existing hash
CurrMD5HashValResult  := fLibEWFVerificationInstance.libewf_GetHashValue('MD5', strCurrentMD5HashVal);
             if CurrMD5HashValResult = -1 then result.ExistingHash := 'Unable to retrieve value from image'; // Failed to get existing hash
             if CurrMD5HashValResult =  0 then result.ExistingHash := 'Not available';                                 // Hash not available to get
             if CurrMD5HashValResult =  1 then                                                               // Hash found
             begin
               result.ExistingHash := strCurrentMD5HashVal;
// More stuff
end;

So, for an image that I know contains an MD5 hash, on Windows, the above works flawlessly, returning the existing hash. But on Linux, it returns -1. And I cannot for the life of me see why. I compiled the exact same source code on both Windows and Linux as per some of our other talks.

Note, that on Windows, when going through with a debugger, the following values are reported :

fCurEWFHandle : address to handle
pansichar(identifier) : MD5
length(identifier) : returns the length of the MD5 hash value
p, : the hash string itself
l, : =1
err); = nil

On Linux, all looks good and largely as expected, except :

p = pchar($00007FFFEDA33C20) #152'7'#163#237#255#127, (p)^ = 152 #152
and
l = 3902020624

So there in seems to be the issue. Do you have any ideas or see something that is obvious?

Unable to mount E01 files on MacOS 10.14.2 installation

I just downloaded the legacy libewf from this website, built it, and tried to mount a disk image:

[nimi ~/gits/libewf-20140608 13:23:02]$ sudo /usr/local/bin/ewfmount -X volicon=/Library/Filesystems/osxfuse.fs/Contents/Resources/Volume.icns  /Volumes/SanDisk\ Extreme/tracy-home-2012-07-16-final.E01 /mnt/
ewfmount 20140608

[nimi ~/gits/libewf-20140608 13:24:08]$ df
Filesystem         1K-blocks       Used  Available Capacity iused               ifree %iused  Mounted on
/dev/disk1s1       976797816  954522992   14176600    99% 2254745 9223372036852521062    0%   /
devfs                    243        243          0   100%     842                   0  100%   /dev
/dev/disk1s4       976797816    7343084   14176600    35%       6 9223372036854775801    0%   /private/var/vm
map -hosts                 0          0          0   100%       0                   0  100%   /net
map auto_home              0          0          0   100%       0                   0  100%   /home
/dev/disk12s1      976557016  122210720  854143908    13%    2230 9223372036854773577    0%   /Volumes/SanDisk Extreme
ewfmount@osxfuse0          0          0          0   100%       0                   0  100%   /mnt
[nimi ~/gits/libewf-20140608 13:24:09]$ ls -l /mnt/
ls: /mnt/: No such file or directory
[nimi ~/gits/libewf-20140608 13:24:11]$

I am not sure what to do at this point.

Unable to build on Mac OS 10.14

Operating system: 10.14.2
MacPorts.
Clean install

Making all in libcaes
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../common  -I../include -I../common -I../libcerror  -I/opt/local/include/ -I/opt/local/include  -g -O2 -Wall -MT libcaes_context.lo -MD -MP -MF .deps/libcaes_context.Tpo -c -o libcaes_context.lo libcaes_context.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../common -I../include -I../common -I../libcerror -I/opt/local/include/ -I/opt/local/include -g -O2 -Wall -MT libcaes_context.lo -MD -MP -MF .deps/libcaes_context.Tpo -c libcaes_context.c -o libcaes_context.o
libcaes_context.c:365:6: error: use of undeclared identifier 'libcaes_tables_initialized'; did you mean 'libcaes_context_initialize'?
        if( libcaes_tables_initialized == 0 )
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
            libcaes_context_initialize
libcaes_context.c:258:5: note: 'libcaes_context_initialize' declared here
int libcaes_context_initialize(
    ^
libcaes_context.c:365:6: warning: comparison of function 'libcaes_context_initialize' equal to a null pointer is always false
      [-Wtautological-pointer-compare]
        if( libcaes_tables_initialized == 0 )
            ^~~~~~~~~~~~~~~~~~~~~~~~~~    ~
libcaes_context.c:365:6: note: prefix with the address-of operator to silence this warning
        if( libcaes_tables_initialized == 0 )
            ^
            &
libcaes_context.c:379:3: error: use of undeclared identifier 'libcaes_tables_initialized'
                libcaes_tables_initialized = 1;
                ^
libcaes_context.c:2819:5: warning: implicit declaration of function 'libcaes_calculate_forward_table_round' is invalid in C99
      [-Wimplicit-function-declaration]
                                libcaes_calculate_forward_table_round(
                                ^
libcaes_context.c:2835:4: warning: implicit declaration of function 'libcaes_calculate_forward_table_round' is invalid in C99
      [-Wimplicit-function-declaration]
                        libcaes_calculate_forward_table_round(
                        ^
libcaes_context.c:2843:4: warning: implicit declaration of function 'libcaes_calculate_forward_substitution_round' is invalid in C99
      [-Wimplicit-function-declaration]
                        libcaes_calculate_forward_substitution_round(
                        ^
libcaes_context.c:2855:5: warning: implicit declaration of function 'libcaes_calculate_reverse_table_round' is invalid in C99
      [-Wimplicit-function-declaration]
                                libcaes_calculate_reverse_table_round(
                                ^
libcaes_context.c:2871:4: warning: implicit declaration of function 'libcaes_calculate_reverse_table_round' is invalid in C99
      [-Wimplicit-function-declaration]
                        libcaes_calculate_reverse_table_round(
                        ^
libcaes_context.c:2879:4: warning: implicit declaration of function 'libcaes_calculate_reverse_substitution_round' is invalid in C99
      [-Wimplicit-function-declaration]
                        libcaes_calculate_reverse_substitution_round(
                        ^
7 warnings and 2 errors generated.
make[1]: *** [libcaes_context.lo] Error 1
make: *** [all-recursive] Error 1
nimi:libewf-legacy simsong$

How can I prepend data (e.g. partition table) to an EWF single-volume image?

In order to convert a huge e01 from volume image to disk image I would like to prepend blocks in an existing (segmented) image like

old.e01 old.e02 old.e03 ... + prepend.e01
becoming
prepend+old.e01 old.e02 old.e03

It should be possible to only edit old.e01 and thereby a much smaller amount of data compared to export both images, binary merge and recreation of e01. As e01 itself does not care about the size of each segment it should not be a problem per-se. Change the number of blocks in the header, fix header CRC, append blocks of prepend.e01 to new header, append blocks of old.e01 to new_header+blocks_of_prepend.e01 and append a md5 to it, right?

Should libewf_handle_close usually take quite some time to complete?

@joachimmetz

My implementation of libewf_handle_close seems to take a very long time in my Windows 10 virtual machine with 16Gb RAM. Several minutes it seems. During this process, the memory in use according to task manager gradually drops, from a few hundred Mb to the normal startup usage of about 40Mb.

I want to check this is normal\expected (for it to take a while), or work out if I am perhaps mis-using it? I am using only these functions:

libewf_handle_open
libewf_handle_get_media_size
libewf_handle_read_buffer
libewf_handle_get_utf8_hash_value
libewf_handle_close

And the segment of my wrapper call to libewf_handle_close is :

if libewf_version='V2' then
      begin
      Result:=flibewfhandleclose (fCurEWFHandle,@err);
      if result=0 then result:=flibewfhandlefree (@fCurEWFHandle,@err);
      end;

Need help mounting E01 file on cygwin

Hello,

I built the source code according to the guide for cygwin/gcc and it appears to spit out the expected files. Running help flags of ewfmount appears to produce the expected output, but actually attempting to mount a file produces the below error. I get the same error in both a regular and elevated prompt. Any thoughts on what I could be missing? The image is in multiple fragments on a network share, would these potentially cause problems?

Thank you

unable to compile with openssl 3

Here are the errors:

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

Here are the warnings:

  CC       libewf_header_values.lo
libewf_header_values.c: In function ‘libewf_header_values_convert_utf8_header_string_to_header’:
libewf_header_values.c:2648:25: warning: pointer ‘header’ used after ‘free’ [-Wuse-after-free]
 2648 |                 *header = NULL;
      |                         ^
In file included from libewf_header_values.c:23:
../common/memory.h:100:9: note: call to ‘free’ here
  100 |         free( (void *) buffer )
      |         ^~~~~~~~~~~~~~~~~~~~~~~
libewf_header_values.c:2645:17: note: in expansion of macro ‘memory_free’
 2645 |                 memory_free(
      |                 ^~~~~~~~~~~

  CC       libsmraw_information_file.lo
libsmraw_information_file.c: In function ‘libsmraw_information_file_read_section’:
libsmraw_information_file.c:548:68: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  548 |                                 input_string[ input_string_index ] = 0;
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
libsmraw_information_file.c:368:14: note: at offset 128 into destination object ‘input_string’ of size 128
  368 |         char input_string[ 128 ];
      |              ^~~~~~~~~~~~

It's easy to launch from here

Travis and AppVeyor test support

Make Travis and AppVeyor test support operational

add zlib-devel for cygwin and mingw
Failing https://travis-ci.org/libyal/libewf-legacy/
- ~~include libcstring, libcsystem in synclibs~~
- ~~include libmfdata in sources~~
- update code to work with latest libcsystem - https://travis-ci.org/libyal/libewf-legacy/jobs/273196066#L1546
- migrate away from libcstring, libcsystem

How to write a "logical" volume image?

Hi,

I am using this library for physical drive compression and its working fine. Now, I want to use this library for volume based(logical drives) compression. Can somebody help me in it.

Either I have to update the library or I just have to set the parameters.

Your support in this regard will be highly appreciated.

Thanks & Regards
Sami Cheema