Other dd and ewf image: how to identify its filesystem type ?

Hello guys !

Please, can you tell me if are are FreeBSD commands to retrive the filesystem type (fat16/32, exfat, ntfs, hfs+, ...) by a dd drive's image ?

Again: and for ewf images ? (forensic format)

Thanks in advance.

Vincenzo.
 
mmmmh ! file() seems doesn't work ... Before post the question I've done some checks. file() seems work on the physical device, not on their dd images.
More complicated seems for the ewf.

Other tips ?
 
file() seems work on the physical device, not on their dd images
I would say it's rather opposite: with physical devices file(1) shows
Code:
$ file /dev/mmcsd0s1
/dev/mmcsd0s1: character special (0/175)
but with an image made out of that device:
Code:
$ file sdcard-p1.img
sdcard-p1.img: DOS/MBR boot sector, code offset 0x0+2, OEM-ID "        ", sectors/cluster 64, reserved sectors 1170, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 8192, sectors 62325760 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 7607, reserved 0x1, serial number 0x64653762, unlabeled
The same with an ext4 image:
Code:
$ file usbboot-rootfs-20170927.img
usbboot-rootfs-20170927.img: Linux rev 1.0 ext4 filesystem data, UUID=b5989013-c301-474c-bd26-723f20625472, volume name "rootfs" (extents) (large files) (huge files)
Besides file(1) I use blkid from sysutils/e2fsprogs:
Code:
$ blkid usbboot-rootfs-20170927.img
usbboot-rootfs-20170927.img: LABEL="rootfs" UUID="b5989013-c301-474c-bd26-723f20625472" TYPE="ext4"
Also, keep in mind that in case you have an image of the entire disk (not just a partition), you'll have to run mdconfig(8) first to create the corresponding devices, e.g.
Code:
# mdconfig sdcard-20171103.img
md0
# blkid /dev/md0s1
/dev/md1s1: LABEL="EXODUS_EXT" UUID="eeeeeeee-eeee-eeee-eeee-eeeeeeeeeeee" TYPE="ext4"
 
I would say it's rather opposite: with physical devices file(1) shows
Code:
$ file /dev/mmcsd0s1
/dev/mmcsd0s1: character special (0/175)
Correct.

So to add to this suggestion: file can identify devices if you use the -s ("special files") parameter:

Code:
root@unicron:/home/peter # gpart show ada2
=>       40  976773088  ada2  GPT  (466G)
         40  976773088     1  freebsd-ufs  (466G)
root@unicron:/home/peter # file -s /dev/ada2p1
/dev/ada2p1: Unix Fast File system [v2] (little-endian) last mounted on /opt/plmedia, volume name plmedia, last written at Mon Jan 22 20:55:46 2018, clean flag 0, readonly flag 0, number of blocks 122096636, number of data blocks 118262225, number of cylinder groups 762, block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
 
Ok guys ! I've well understood what you speack about.

I'm not interesting how to get information of a filesystem by a physical device but from its dd image. Your replies are clear regard the use of command "file".

However, my question was also referred to the ewf file format. EWF is a container: it contains the compressed image of the physical device and other informations in its header. It seems that the FreeBSD's command "file -s" doesn't work for this format.
Please, can you confirm this assumption ?

Thanks in advance.

Regards.
 
Yes, aragats ... that format is not open.
Please, can you be more clear about "header description" ? That format is controlled by a library, the libewf. Maybe you mean that if I install libewf I can read that format with the FreeBsD "file -s" command, like any other dd images ?

I hope to hear you soon.

Thanks in advance.
 
I didn't know such a library exists for FreeBSD, now I see it, thanks.
Regarding the header: my point was to read the corresponding fields in the header. So, if such a library exists, that means the header fields are not secret.
Although I'm doubting that file(1) will understand it automatically upon installing the library, but it supports supplying custom magic files with -m option, maybe it's not hard to create one, or maybe somebody already created.
 
The package devel/libewf installs several executables as well (not just the library), so you don't need to write your own program. The cost is lang/python36 package pulled as a dependency.
I don't have any EWF file to test with, but I guess you can use ewfinfo() to get the needed info.
 
Hello aragats, thanks for your further help. I'll try with ewfinfo ... also if I've just done some test and it seems that ewfinfo doesn't detect filesystem type by a ewf image ... for this reason I've tryed to find another way. The file() command should be welcome for this. However I'll try.

However, if I do not take much of your time, I can send you a ewf image of a usb stick. You could try to use the file command and ewfinfo to see which of the two gives informations about the filesystem type. (I've formatted the usb stick fat32).

Have you a storage cloud (Google Drive) wher I can upload it ?

I'll do the same so to compare with you the results.

Best Regards.

Vincenzo.
 
vince66 , sure, I'd like to see an EWF image. Not sure where you can upload it to. If you have it in your Google Drive you can share the link with me.
How large is it?
 
Sincerely I'm not sure ... I only asked your kindly disponibility, because I've seen your friendly approach. The images are about 23 MB. Probably, I need of your email to share it with you on google drive.

Thanks in advance !!!
Regards.

Vincenzo.
 
I used ewfmount from devel/libewf, then file(1):
Code:
# ewfmount /tmp/HFS_ewf.E01 /mnt/tmp/
ewfmount 20140802
# ls -l /mnt/tmp/
-r--r--r--  1 root  wheel  7782531072 Jan 25 11:42 ewf1
# file /mnt/tmp/ewf1
/mnt/tmp/ewf1: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 15200255 sectors, extended partition table (last)
 
OK ... here is the problem ! ... before mount (in any way) the image I would retrive informations about filesyste type. Once I have this information I'll take a decision about the mounting program (Freebsd mount, Linux xmount, ewfmount you have used).
As you can see ewfmount (and ewfinfo) don't give informations about the type of filesystem.

I'm sorry to see that also file(1) doesn't show the filesystem type.
Very big problem.

Note: the image you have is however corrupted (the original one is about 37 MB).

See you !
 
Also, you can use sysutils/linuxfdisk, may be your file is incomplete, it shows only an EFI partition:
Code:
# fdisk-linux -l /mnt/tmp/ewf1

Disk /mnt/tmp/ewf1: 264646951852.2 GB, 6392534820271584768 bytes
255 heads, 63 sectors/track, 1225870278 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

         Device Boot    Start       End    Blocks   Id  System
/mnt/tmp/ewf1s1             1       947   7600127+  ee  EFI GPT
 
OK very good

I think it's correct to summarize what I want to verify.

First: my goal is to use exclusively FreeBSD with CLI. No Linux/Windows O.S., that is no O.S. with Graphical User Interface (windows, ubuntu, ...)
Second: I would retrive APRIORI informations on filesyste type . Once I have this information I'll take a decision about what mounting program have to be used.

So, if I've well understood:

1- for dd/ewf images of disks formatted FAT the command file(1) should show the type FAT
2- for dd/ewf images of disks formatted NTFS the command file(1) should show the type NTFS
3- for dd/ewf images of disks formatted HFS/HFS+ the command file(1) probably is not able to detect the type of filesystem.

Today, I'll try to send you three ewf images (I'll use a high speed internet connection):

- FAT32_EWF.E01
- NTFS_ewf.E01
- HFS_ewf.E01

The question is: is there a FreeBSD command that can show (retrive) the filesystem type for the above images ?

Thanks very much for your time and patience.

See you !!!!

Vincenzo.
 
I tried inspecting and mounting those 3 files. All of them cannot be handled by ewf* programs with the following error message:
Code:
Unable to open EWF file(s).
libewf_segment_file_read_file_header: unsupported segment file signature.
libewf_handle_open_file_io_pool: unable to read segment file header.
libewf_handle_open: unable to open handle using a file IO pool.
info_handle_open_input: unable to open file(s).
What's different compared to the first file?
The first file you sent is good:
Code:
$ ewfinfo ~/HFS_ewf.E01
ewfinfo 20140802

Acquiry information
   Notes:           5C07105A76EE3BF084
   Acquisition date:   Wed Jan 24 15:55:06 2018
   System date:       Wed Jan 24 15:55:06 2018
   Operating system used:   Linux caine 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64
   Software version used:   guymager 0.8.4-1
   Password:       N/A
   Model:           Sony Storage_Media
   Serial number:       5C07105A76EE3BF084

EWF information
   File format:       EnCase 6
   Sectors per chunk:   64
   Error granularity:   1
   Compression method:   deflate
   Compression level:   good (fast) compression
   Is corrupted:       yes

Media information
   Media type:       removable disk
   Is physical:       yes
   Bytes per sector:   512
   Number of sectors:   15200256
   Media size:       7.2 GiB (7782531072 bytes)
 
After inspecting the headers of those files I believe your ftp client used ASCII mode transfer, which in not acceptable in this case. You should explicitly tell it to use BINARY mode.
I already mentioned above that you should use md5 or whatever checksum to verify the files are transferred correctly. Here what I have, you can run on the originals to compare:
Code:
$ md5 /tmp/*E01
MD5 (/tmp/FAT32_EWF.E01) = 60d0f94361ad999e116df2ed5ae5a68f
MD5 (/tmp/HFS_ewf.E01) = 4ba61ab2b518aebe242aba606b0d773e
MD5 (/tmp/NTFS_ewf.E01) = bf48b078b036627e0d6f2cb473e4a75a
 
Okay, your files can be mounted with ewfmount:
Code:
# ewfmount HFS_ewf.E01 /mnt/tmp/
# ls -l /mnt/tmp/
-r--r--r--  1 root  wheel  7782531072 Jan 29 15:29 ewf1
As I already mentioned, file used with an entire disk image is useless: it shows that it's an MBR disk or so. So, you have to run file on a partition. However, mdconfig() fails when used with that ewf1. I think, the easiest way is to use sysutils/gdisk:
Code:
$ sudo gdisk -l /mnt/tmp/ewf1
GPT fdisk (gdisk) version 1.0.3
....
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     AF00 
   2         4196352         8390655   2.0 GiB     AF00 
   3         8390656        15198207   3.2 GiB     0700
You can see that partitions have codes AF00 and 0700. The first two are Apple HFS/HFS+ and the third one is obviously NTFS. I don't know where a complete list of partition types codes is available from, but those codes can be retrieved from the gdisk itself:
Code:
0700 Microsoft basic data  0c01 Microsoft reserved    2700 Windows RE        
3000 ONIE boot             3001 ONIE config           3900 Plan 9            
4100 PowerPC PReP boot     4200 Windows LDM data      4201 Windows LDM metadata
4202 Windows Storage Spac  7501 IBM GPFS              7f00 ChromeOS kernel    
7f01 ChromeOS root         7f02 ChromeOS reserved     8200 Linux swap        
8300 Linux filesystem      8301 Linux reserved        8302 Linux /home        
8303 Linux x86 root (/)    8304 Linux x86-64 root (/  8305 Linux ARM64 root (/)
8306 Linux /srv            8307 Linux ARM32 root (/)  8400 Intel Rapid Start  
8e00 Linux LVM             a000 Android bootloader    a001 Android bootloader 2
a002 Android boot          a003 Android recovery      a004 Android misc      
a005 Android metadata      a006 Android system        a007 Android cache      
a008 Android data          a009 Android persistent    a00a Android factory    
a00b Android fastboot/ter  a00c Android OEM           a500 FreeBSD disklabel  
a501 FreeBSD boot          a502 FreeBSD swap          a503 FreeBSD UFS        
a504 FreeBSD ZFS           a505 FreeBSD Vinum/RAID    a580 Midnight BSD data  
a581 Midnight BSD boot     a582 Midnight BSD swap     a583 Midnight BSD UFS  
a584 Midnight BSD ZFS      a585 Midnight BSD Vinum    a600 OpenBSD disklabel  
a800 Apple UFS             a901 NetBSD swap           a902 NetBSD FFS        
a903 NetBSD LFS            a904 NetBSD concatenated   a905 NetBSD encrypted  
a906 NetBSD RAID           ab00 Recovery HD           af00 Apple HFS/HFS+    
af01 Apple RAID            af02 Apple RAID offline    af03 Apple label
 
Back
Top