sleuthkit-developers Mailing List for The Sleuth Kit (Page 3)
Brought to you by:
carrier
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Edward D. <eld...@tr...> - 2016-07-22 15:55:47
|
The failure I am about to describe occurs on both TSK 4.2.0 and the recently released TSK 4.3.0 on Windows 8.1 using the binaries provided. I use a program called FTK Imager Lite 3.1.1.8 from AccessData to create ewf images. If I create ewf images from a single logical drive, which naturally has a single file system, TSK and tsk_recover work fine. Instead my problem with TSK is when creating ewf images from a physical drive, which has a number of different file systems. In my example I create ewf images from a physical drive which has separate FAT32, NTFS, EXT3, and EXT4 with files in each logical partition. The FTK Imager Lite program creates the ewf image for me in the directory of my choice from the physical drive without any problems. I then run tsk_recover with the -v verbose option, passing the full path to the ewf image and the directory where I want the files to be put. The results of running tsk_recover are: ------------------------------------------------------------------------------------------------------------------------ E:\Utilities\sleuthkit-4.3.0-win32\bin>tsk_recover -v C:\Utilities\FTImages\PhysDrive\MyPhys.E01 C:\Utilities\TSKDirs\Rec1\Unallocated tsk_img_open: Type: 0 NumImg: 1 Img1: C:\Utilities\FTImages\PhysDrive\MyPhys.E01 ewf_open: found 1 segment files via libewf_glob Error opening vmdk file Error checking file signature for vhd file fsopen: Auto detection mode at offset 0 ewf_image_read: byte offset: 0 len: 65536 ntfs_open: invalid cluster size: 0 fatxxfs_open: Invalid sector size (23552) exfatfs_get_fs_size_params: Invalid sector size base 2 logarithm (23552), not in range (9 - 12) fatxxfs_open: Invalid sector size (23552) ext2fs_open: invalid magic ewf_image_read: byte offset: 65536 len: 65536 ufs_open: Trying 256KB UFS2 location ewf_image_read: byte offset: 262144 len: 65536 ufs_open: Trying UFS1 location ufs_open: No UFS magic found ewf_image_read: byte offset: 156160 len: 65536 ewf_image_read: byte offset: 426496 len: 65536 ewf_image_read: byte offset: 561664 len: 65536 ewf_image_read: byte offset: 696832 len: 65536 ewf_image_read: byte offset: 832000 len: 65536 ewf_image_read: byte offset: 967168 len: 65536 ewf_image_read: byte offset: 1102336 len: 65536 ewf_image_read: byte offset: 1237504 len: 65536 ewf_image_read: byte offset: 1372672 len: 65536 ewf_image_read: byte offset: 1507840 len: 65536 ewf_image_read: byte offset: 1643008 len: 65536 ewf_image_read: byte offset: 1778176 len: 65536 ewf_image_read: byte offset: 1913344 len: 65536 ewf_image_read: byte offset: 2048512 len: 65536 ewf_image_read: byte offset: 2183680 len: 65536 ewf_image_read: byte offset: 2318848 len: 65536 ewf_image_read: byte offset: 2454016 len: 65536 ewf_image_read: byte offset: 2589184 len: 65536 ewf_image_read: byte offset: 2724352 len: 65536 ewf_image_read: byte offset: 2859520 len: 65536 ewf_image_read: byte offset: 2994688 len: 65536 ewf_image_read: byte offset: 3129856 len: 65536 ewf_image_read: byte offset: 3265024 len: 65536 ewf_image_read: byte offset: 3400192 len: 65536 ewf_image_read: byte offset: 3535360 len: 65536 ewf_image_read: byte offset: 3670528 len: 65536 ewf_image_read: byte offset: 3805696 len: 65536 ewf_image_read: byte offset: 3940864 len: 65536 ewf_image_read: byte offset: 4076032 len: 65536 ewf_image_read: byte offset: 4211200 len: 65536 ewf_image_read: byte offset: 4346368 len: 65536 ewf_image_read: byte offset: 4481536 len: 65536 ewf_image_read: byte offset: 4616704 len: 65536 ewf_image_read: byte offset: 4751872 len: 65536 ewf_image_read: byte offset: 4732928 len: 65536 ewf_image_read: byte offset: 4887040 len: 65536 ewf_image_read: byte offset: 5022208 len: 65536 ewf_image_read: byte offset: 5157376 len: 65536 ewf_image_read: byte offset: 5292544 len: 65536 ewf_image_read: byte offset: 5427712 len: 65536 ewf_image_read: byte offset: 5562880 len: 65536 ewf_image_read: byte offset: 5698048 len: 65536 ewf_image_read: byte offset: 5833216 len: 65536 ewf_image_read: byte offset: 5968384 len: 65536 ewf_image_read: byte offset: 6103552 len: 65536 ewf_image_read: byte offset: 6238720 len: 65536 ewf_image_read: byte offset: 6373888 len: 65536 ewf_image_read: byte offset: 6509056 len: 65536 ewf_image_read: byte offset: 6644224 len: 65536 ewf_image_read: byte offset: 6779392 len: 65536 ewf_image_read: byte offset: 6914560 len: 65536 ewf_image_read: byte offset: 7049728 len: 65536 ewf_image_read: byte offset: 7184896 len: 65536 ewf_image_read: byte offset: 7320064 len: 65536 ewf_image_read: byte offset: 7455232 len: 65536 ewf_image_read: byte offset: 7590400 len: 65536 ewf_image_read: byte offset: 7725568 len: 65536 ewf_image_read: byte offset: 7860736 len: 65536 ewf_image_read: byte offset: 7995904 len: 65536 ewf_image_read: byte offset: 8131072 len: 65536 ewf_image_read: byte offset: 8266240 len: 65536 ewf_image_read: byte offset: 8401408 len: 65536 ewf_image_read: byte offset: 8536576 len: 65536 ewf_image_read: byte offset: 8671744 len: 65536 ewf_image_read: byte offset: 8806912 len: 65536 ewf_image_read: byte offset: 8942080 len: 65536 ewf_image_read: byte offset: 9077248 len: 65536 ewf_image_read: byte offset: 9212416 len: 65536 ewf_image_read: byte offset: 9347584 len: 65536 ewf_image_read: byte offset: 9482752 len: 65536 ewf_image_read: byte offset: 9617920 len: 65536 ewf_image_read: byte offset: 9753088 len: 65536 ewf_image_read: byte offset: 9888256 len: 65536 ewf_image_read: byte offset: 10023424 len: 65536 ewf_image_read: byte offset: 10158592 len: 65536 ewf_image_read: byte offset: 10293760 len: 65536 ewf_image_read: byte offset: 10428928 len: 65536 ewf_image_read: byte offset: 10564096 len: 65536 ewf_image_read: byte offset: 10699264 len: 65536 ewf_image_read: byte offset: 10834432 len: 65536 ewf_image_read: byte offset: 10969600 len: 65536 ewf_image_read: byte offset: 11104768 len: 65536 ewf_image_read: byte offset: 11239936 len: 65536 ewf_image_read: byte offset: 11375104 len: 65536 ewf_image_read: byte offset: 11510272 len: 65536 ewf_image_read: byte offset: 11645440 len: 65536 ewf_image_read: byte offset: 11780608 len: 65536 ewf_image_read: byte offset: 11915776 len: 65536 ewf_image_read: byte offset: 12050944 len: 65536 ewf_image_read: byte offset: 12186112 len: 65536 ewf_image_read: byte offset: 12321280 len: 65536 ewf_image_read: byte offset: 12456448 len: 65536 ewf_image_read: byte offset: 12591616 len: 65536 ewf_image_read: byte offset: 12726784 len: 65536 ewf_image_read: byte offset: 12861952 len: 65536 ewf_image_read: byte offset: 12997120 len: 65536 ewf_image_read: byte offset: 13132288 len: 65536 ewf_image_read: byte offset: 13267456 len: 65536 ewf_image_read: byte offset: 13402624 len: 65536 ewf_image_read: byte offset: 13537792 len: 65536 ewf_image_read: byte offset: 13672960 len: 65536 ewf_image_read: byte offset: 13808128 len: 65536 ewf_image_read: byte offset: 13943296 len: 65536 ewf_image_read: byte offset: 14078464 len: 65536 ewf_image_read: byte offset: 14213632 len: 65536 ewf_image_read: byte offset: 14348800 len: 65536 ewf_image_read: byte offset: 14483968 len: 65536 ewf_image_read: byte offset: 14619136 len: 65536 ewf_image_read: byte offset: 14754304 len: 65536 ewf_image_read: byte offset: 14889472 len: 65536 ewf_image_read: byte offset: 15024640 len: 65536 ewf_image_read: byte offset: 15159808 len: 65536 ewf_image_read: byte offset: 15294976 len: 65536 ewf_image_read: byte offset: 15276032 len: 65536 ewf_image_read: byte offset: 15430144 len: 65536 ewf_image_read: byte offset: 15411200 len: 65536 ewf_image_read: byte offset: 15565312 len: 65536 ewf_image_read: byte offset: 15546368 len: 65536 ewf_image_read: byte offset: 15700480 len: 65536 ewf_image_read: byte offset: 15681536 len: 65536 ewf_image_read: byte offset: 15835648 len: 65536 ewf_image_read: byte offset: 15816704 len: 65536 ewf_image_read: byte offset: 15970816 len: 65536 ewf_image_read: byte offset: 15951872 len: 65536 ewf_image_read: byte offset: 16105984 len: 65536 ewf_image_read: byte offset: 16087040 len: 65536 ewf_image_read: byte offset: 16241152 len: 65536 ewf_image_read: byte offset: 16222208 len: 65536 ewf_image_read: byte offset: 16376320 len: 65536 ewf_image_read: byte offset: 16357376 len: 65536 yaffsfs_open: could not find valid spare area format See http://wiki.sleuthkit.org/index.php?title=YAFFS2 for help on Yaffs2 configuration ewf_image_read: byte offset: 1024 len: 65536 iso9660_open img_info: 34734152 ftype: 2048 test: 1 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 Trying RAW ISO9660 with 16-byte pre-block size fs_prepost_read: Mapped 32768 to 37648 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 Trying RAW ISO9660 with 24-byte pre-block size fs_prepost_read: Mapped 32768 to 37656 iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 iso9660_open: Error loading volume descriptor Cannot determine file system type (Sector offset: 0)Files Recovered: 0 -------------------------------------------------------------------------------------------------------------------------------- Yet if I ask FTK Imager to show me the file in the ewf image, using its Add Evidence Item... functionality it does indeed show me the files in the image without any errors. Is TSK supposed to work with physical drives containin different file systems ? If so can anyone suggest how I can get TSK to work properly ? Eddie Diener |
From: Brian C. <ca...@sl...> - 2016-07-21 21:31:19
|
Parallel. Based on the number of ingest threads. An instance of FileIngestModule will be created for each thread so you don’t need to worry too much about thread safety if you stay away from static variables. > On Jul 21, 2016, at 9:09 AM, khoirunnisa Afifah <k....@ro...> wrote: > > Hi. > > Autopsy 4 documentation say that org.sleuthkit.autopsy.ingest.FileIngestModule.process will be called for each file in datasource. I'm curious, does that method being called parallel for all file or sequentially waiting for one file finish and go for another file? > > Best regard, > Afik > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev_______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: khoirunnisa A. <k....@ro...> - 2016-07-21 13:09:37
|
Hi. Autopsy 4 documentation say that org.sleuthkit.autopsy.ingest.FileIngestModule.process will be called for each file in datasource. I'm curious, does that method being called parallel for all file or sequentially waiting for one file finish and go for another file? Best regard,Afik |
From: Brian C. <ca...@sl...> - 2016-07-21 00:47:54
|
Hey Eddie, You are correct. There should be that check in place. I think our other places do the check at a higher level, but it is certainly safer to do it in the method. Can you do a pull request for this? thanks, brian > On Jul 20, 2016, at 5:12 PM, Edward Diener <eld...@tr...> wrote: > > The code for TskAuto::isFATSystemFiles is: > > uint8_t > TskAuto::isFATSystemFiles(TSK_FS_FILE *a_fs_file) > { > if (a_fs_file && a_fs_file->fs_info && a_fs_file->name) { > FATFS_INFO *fatfs = (FATFS_INFO*)a_fs_file->fs_info; > TSK_INUM_T addr = a_fs_file->name->meta_addr; > if ((addr == fatfs->mbr_virt_inum) || > (addr == fatfs->fat1_virt_inum) || > (addr == fatfs->fat2_virt_inum && fatfs->numfat == 2)) { > return 1; > } > } > > return 0; > } > > This code blindly casts a pointer to a TSK_FS_INFO struct to a pointer > to a FATFS_INFO struct and then tries to access data in the FATFS_INFO > struct. I am showing this leading to an access violation in some code I > am developing using TSK. Shouldn't the code instead be: > > uint8_t > TskAuto::isFATSystemFiles(TSK_FS_FILE *a_fs_file) > { > if (a_fs_file && a_fs_file->fs_info && a_fs_file->name > && TSK_FS_TYPE_ISFAT(a_fs_file->fs_info->ftype)) { > FATFS_INFO *fatfs = (FATFS_INFO*)a_fs_file->fs_info; > TSK_INUM_T addr = a_fs_file->name->meta_addr; > if ((addr == fatfs->mbr_virt_inum) || > (addr == fatfs->fat1_virt_inum) || > (addr == fatfs->fat2_virt_inum && fatfs->numfat == 2)) { > return 1; > } > } > > return 0; > } > > In other words shouldn't the code be checking for the fact that the file > type is FAT before trying to cast the TSK_FS_INFO pointer to a > FATFS_INFO pointer ? > > I am not cognizant of TSK code but I am a C++ expert and the code does > not look like it can be correct as is ( besides leading to an access > violation <g> ). > > Eddie Diener > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Edward D. <eld...@tr...> - 2016-07-20 21:12:23
|
The code for TskAuto::isFATSystemFiles is: uint8_t TskAuto::isFATSystemFiles(TSK_FS_FILE *a_fs_file) { if (a_fs_file && a_fs_file->fs_info && a_fs_file->name) { FATFS_INFO *fatfs = (FATFS_INFO*)a_fs_file->fs_info; TSK_INUM_T addr = a_fs_file->name->meta_addr; if ((addr == fatfs->mbr_virt_inum) || (addr == fatfs->fat1_virt_inum) || (addr == fatfs->fat2_virt_inum && fatfs->numfat == 2)) { return 1; } } return 0; } This code blindly casts a pointer to a TSK_FS_INFO struct to a pointer to a FATFS_INFO struct and then tries to access data in the FATFS_INFO struct. I am showing this leading to an access violation in some code I am developing using TSK. Shouldn't the code instead be: uint8_t TskAuto::isFATSystemFiles(TSK_FS_FILE *a_fs_file) { if (a_fs_file && a_fs_file->fs_info && a_fs_file->name && TSK_FS_TYPE_ISFAT(a_fs_file->fs_info->ftype)) { FATFS_INFO *fatfs = (FATFS_INFO*)a_fs_file->fs_info; TSK_INUM_T addr = a_fs_file->name->meta_addr; if ((addr == fatfs->mbr_virt_inum) || (addr == fatfs->fat1_virt_inum) || (addr == fatfs->fat2_virt_inum && fatfs->numfat == 2)) { return 1; } } return 0; } In other words shouldn't the code be checking for the fact that the file type is FAT before trying to cast the TSK_FS_INFO pointer to a FATFS_INFO pointer ? I am not cognizant of TSK code but I am a C++ expert and the code does not look like it can be correct as is ( besides leading to an access violation <g> ). Eddie Diener |
From: Edward D. <eld...@tr...> - 2016-07-15 16:35:59
|
According to the libewf docs, LIBEWF_DLL_IMPORT must be defined before including libewf.h. Where is this defined in the SleuthKit solution for VS2010 ? |
From: Edward D. <eld...@tr...> - 2016-07-12 18:14:16
|
<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 7/12/2016 1:36 PM, Richard Cordovano wrote:<br> </div> <blockquote cite="mid:CAPuuEWQ+2PnNYhDzJZUFx0CvD6n3ZwiNQOmNhooRqOaGHh=HA...@ma..." type="cite"> <div dir="ltr">For those of using then free edition of Visual C++ 2010, installing the Windows 7 SDK was a prerequisite for getting 64-bit compiler support. The SleuthKit team did not explicitly set the Platform Toolset property value;</div> </blockquote> If you get SleuthKit from Github you will see that on the 'master' branch the Platform Toolset property for the 64-bit build is set to "Windows7.1SDK".<br> <br> Eddie Diener<br> <blockquote cite="mid:CAPuuEWQ+2PnNYhDzJZUFx0CvD6n3ZwiNQOmNhooRqOaGHh=HA...@ma..." type="cite"> <div dir="ltr"> it is my understanding that it is set when one does the following, as described in BUILDING.txt:<span class=""> <div><br> </div> <div> <div>Visual Studio 2010 Express cannot make 64-bit versions of the</div> <div>executables. To do that, you must download and install an additional SDK:</div> <div><br> </div> <div><a moz-do-not-send="true" href="http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx" target="_blank">http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx</a></div> <div><br> </div> <div>The SDK installation may fail, particularly if Visual Studio 2010 Service</div> <div>Pack 1 has been installed. In this case, re-run the SDK installer but</div> <div>un-check the compilers box. After the SDK is installed, run the following</div> <div>fix to get the 64 bit compiler:</div> <div><br> </div> <div><a moz-do-not-send="true" href="https://www.microsoft.com/en-us/download/details.aspx?id=4422" target="_blank">https://www.microsoft.com/en-us/download/details.aspx?id=4422</a></div> </div> </span></div> <div class="gmail_extra"><br> <div class="gmail_quote">On Tue, Jul 12, 2016 at 1:20 PM, Edward Diener <span dir="ltr"><<a moz-do-not-send="true" href="mailto:eld...@tr..." target="_blank">eld...@tr...</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7/8/2016 11:42 PM, Brian Carrier wrote:<br> > Did you follow the build instructions in win32/BUILDING.txt for 64-bit versions? I think the Windows7.1SDK is the one that makes 64-bit builds for VS 2010.<br> </span> I have no problems creating a 64-bit build using the default "v100"<br> Platform Toolset value. My question is what technical reason exists for<br> using "Windows7.1SDK" as the Platform Toolset value, especially as this<br> value is not supported in my VS2010 AFAICS. Perhaps "Windows7.1SDK" was<br> needed for the free version of VS2010, along with a download of a<br> particular SDK to which that value refers, but for the VS2010<br> Professional version which I have always had this "Windows7.1SDK" value<br> is not needed to create a 64-bit build, and does not exist as an option.<br> <span class="">><br> ><br> >> On Jun 29, 2016, at 3:26 PM, Edward Diener <<a moz-do-not-send="true" href="mailto:eld...@tr...">eld...@tr...</a>> wrote:<br> >><br> >> I am seeing the platform toolset in the VS2010 projects for<br> >> libewf_64bit and sleuthkit set to "Windows7.1SDK" for the 64-bit build<br> >> and "v100" for the 32-bit build in sleuthkit. Is there a reason for this ?<br> >><br> >> I do not have a "Windows7.1SDK" platform toolset for VS2010 either under<br> >> Windows 7 or Windows 8.1.<br> >><br> >> Eddie Diener</span><br> </blockquote> </div> </div> </blockquote> <p><br> </p> </body> </html> |
From: Richard C. <rco...@ba...> - 2016-07-12 18:05:17
|
For those of using then free edition of Visual C++ 2010, installing the Windows 7 SDK was a prerequisite for getting 64-bit compiler support. The SleuthKit team did not explicitly set the Platform Toolset property value; it is my understanding that it is set when one does the following, as described in BUILDING.txt: Visual Studio 2010 Express cannot make 64-bit versions of the executables. To do that, you must download and install an additional SDK: http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx The SDK installation may fail, particularly if Visual Studio 2010 Service Pack 1 has been installed. In this case, re-run the SDK installer but un-check the compilers box. After the SDK is installed, run the following fix to get the 64 bit compiler: https://www.microsoft.com/en-us/download/details.aspx?id=4422 On Tue, Jul 12, 2016 at 1:20 PM, Edward Diener < eld...@tr...> wrote: > On 7/8/2016 11:42 PM, Brian Carrier wrote: > > Did you follow the build instructions in win32/BUILDING.txt for 64-bit > versions? I think the Windows7.1SDK is the one that makes 64-bit builds > for VS 2010. > I have no problems creating a 64-bit build using the default "v100" > Platform Toolset value. My question is what technical reason exists for > using "Windows7.1SDK" as the Platform Toolset value, especially as this > value is not supported in my VS2010 AFAICS. Perhaps "Windows7.1SDK" was > needed for the free version of VS2010, along with a download of a > particular SDK to which that value refers, but for the VS2010 > Professional version which I have always had this "Windows7.1SDK" value > is not needed to create a 64-bit build, and does not exist as an option. > > > > > >> On Jun 29, 2016, at 3:26 PM, Edward Diener < > eld...@tr...> wrote: > >> > >> I am seeing the platform toolset in the VS2010 projects for > >> libewf_64bit and sleuthkit set to "Windows7.1SDK" for the 64-bit build > >> and "v100" for the 32-bit build in sleuthkit. Is there a reason for > this ? > >> > >> I do not have a "Windows7.1SDK" platform toolset for VS2010 either under > >> Windows 7 or Windows 8.1. > >> > >> Eddie Diener > >> > >> > ------------------------------------------------------------------------------ > >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries > >> present their vision of the future. This family event has something for > >> everyone, including kids. Get more information and register today. > >> http://sdm.link/attshape > >> _______________________________________________ > >> sleuthkit-developers mailing list > >> sle...@li... > >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers > |
From: Edward D. <eld...@tr...> - 2016-07-12 17:30:32
|
On 7/8/2016 11:27 PM, Brian Carrier wrote: > Typically when either: > - The format is not supported by TSK OK, understood. But then specifying that format instead of autodetection will not work either I would suppose. > - There are multiple formats that TSK thinks could exist and it will therefore force the user to pick That makes sense. In what specific situations does TSK have difficulty choosing among similar multiple formats ? Eddie Diener > >> On Jul 6, 2016, at 3:31 PM, Edward Diener <eld...@tr...> wrote: >> >> In what situations do the autodetection of the image type for an image, >> or the autodetection of file system types in a volume of an image, not >> work ? >> >> Eddie Diener >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Edward D. <eld...@tr...> - 2016-07-12 17:20:57
|
On 7/8/2016 11:42 PM, Brian Carrier wrote: > Did you follow the build instructions in win32/BUILDING.txt for 64-bit versions? I think the Windows7.1SDK is the one that makes 64-bit builds for VS 2010. I have no problems creating a 64-bit build using the default "v100" Platform Toolset value. My question is what technical reason exists for using "Windows7.1SDK" as the Platform Toolset value, especially as this value is not supported in my VS2010 AFAICS. Perhaps "Windows7.1SDK" was needed for the free version of VS2010, along with a download of a particular SDK to which that value refers, but for the VS2010 Professional version which I have always had this "Windows7.1SDK" value is not needed to create a 64-bit build, and does not exist as an option. > > >> On Jun 29, 2016, at 3:26 PM, Edward Diener <eld...@tr...> wrote: >> >> I am seeing the platform toolset in the VS2010 projects for >> libewf_64bit and sleuthkit set to "Windows7.1SDK" for the 64-bit build >> and "v100" for the 32-bit build in sleuthkit. Is there a reason for this ? >> >> I do not have a "Windows7.1SDK" platform toolset for VS2010 either under >> Windows 7 or Windows 8.1. >> >> Eddie Diener >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: noxdafox <nox...@gm...> - 2016-07-09 08:35:46
|
Is there any specific reason why the APIs contained in the two files are not exposed? At least I could not find any reference in the documentation. On 09/07/16 06:47, Brian Carrier wrote: > Hello, > > Sorry for the very late replies. I certainly think it would be of interest to the TSK users. My 2 cents would be to take a look at the existing journal infrastructure in TSK that was not designed with the knowledge of NTFS structures (so it maybe too limited). But, it would be good to try to enhance that versus adding in a parallel journal infrastructure. Examples of it can be found in ext2fs_journal.c and hfs_journal.c and it provides callbacks for each entry. > > thanks, > brian > >> On Jun 28, 2016, at 12:49 PM, noxdafox <nox...@gm...> wrote: >> >> Greetings, >> >> recently I've been playing around with NTFS Update Sequence Number >> Journals which I find a fairly good instrument for extracting timelines >> from NTFS drives. >> >> I have been writing few parsers for it, the last one been written in C. >> >> I was thinking about porting it to sleuthkit. Do you think it would be >> beneficial for the library? >> >> The idea would be to expose a visitor API (in similar fashion as for >> tsk_fs_dir_walk) and then a command line tool built on top of it. >> >> More info about UsnJrnl files: >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365722%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396# >> >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:47:53
|
Hello, Sorry for the very late replies. I certainly think it would be of interest to the TSK users. My 2 cents would be to take a look at the existing journal infrastructure in TSK that was not designed with the knowledge of NTFS structures (so it maybe too limited). But, it would be good to try to enhance that versus adding in a parallel journal infrastructure. Examples of it can be found in ext2fs_journal.c and hfs_journal.c and it provides callbacks for each entry. thanks, brian > On Jun 28, 2016, at 12:49 PM, noxdafox <nox...@gm...> wrote: > > Greetings, > > recently I've been playing around with NTFS Update Sequence Number > Journals which I find a fairly good instrument for extracting timelines > from NTFS drives. > > I have been writing few parsers for it, the last one been written in C. > > I was thinking about porting it to sleuthkit. Do you think it would be > beneficial for the library? > > The idea would be to expose a visitor API (in similar fashion as for > tsk_fs_dir_walk) and then a command line tool built on top of it. > > More info about UsnJrnl files: > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365722%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396# > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:42:23
|
Did you follow the build instructions in win32/BUILDING.txt for 64-bit versions? I think the Windows7.1SDK is the one that makes 64-bit builds for VS 2010. > On Jun 29, 2016, at 3:26 PM, Edward Diener <eld...@tr...> wrote: > > I am seeing the platform toolset in the VS2010 projects for > libewf_64bit and sleuthkit set to "Windows7.1SDK" for the 64-bit build > and "v100" for the 32-bit build in sleuthkit. Is there a reason for this ? > > I do not have a "Windows7.1SDK" platform toolset for VS2010 either under > Windows 7 or Windows 8.1. > > Eddie Diener > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:39:40
|
Hi Eddie, For our projects and incident response scenarios, a static library has been better. But, there are certainly other scenarios that a dll is good too. I don’t believe there is any reason why you can’t make a separate visual studio project that makes a dll from the static library. thanks, brian > On Jul 1, 2016, at 9:11 AM, Edward Diener <eld...@tr...> wrote: > > In TSK libtsk is a static library. Is there any technical reason libtsk > could not be a DLL or series of DLLs offering TSK functionality ? I > belive this would allow other languages to use its functionality much > easier as long as each C function in lbtsk were specified 'extern "C"' > so that C++ name mangling were not being done. What are the issues > involving this as seen by others who know TSK much better than I do ? > > Eddie Diener > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:38:12
|
Yes, you are right. For so long, I released from a 32-bit system and didn’t update the release script on the last one to pull the right ones. Thanks. brian > On Jul 3, 2016, at 12:52 PM, Edward Diener <eld...@tr...> wrote: > > The VC++ DLLs which are included in the SleuthKit 4.2.0 Windows release > at > https://sourceforge.net/projects/sleuthkit/files/sleuthkit/4.2.0/sleuthkit-4.2.0-win32.zip/download > are the wrong ones. They are 64-bit VC++ DLLs for msvcp100.dll and > msvcr100.dll in VS2010 instead of the correct 32-bit versions. Running > either: > > dumpbin /headers msvcp100.dll > dumpbin /headers msvcr100.dll > > or running Dependency Walker on those DLLs clearly shows that they are > the wrong ones. Shouldn't they be corrected for people wanted to > downlaod the latest official SleuthKit release ? > > Edward Diener > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:28:56
|
Hi Roberto, The existing releases out there have a bug in which if you create a custom artifact, it is not shown in the tree. We have that fixed, but have not gotten the release out because other things keep coming up. I’m hoping to get it out next week though and then any custom artifact will be shown in the tree. thanks, brian > On Jul 6, 2016, at 12:58 PM, Roberto Amelio <g.r...@gm...> wrote: > > Hi, > > I am developing an ingest module in python and I didn't get whether it's possible to create my own artifact type. To be more specific, how can I collect all my results under the same label in the tree on the left-hand side? > > Regards, > Roberto > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape_______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Brian C. <ca...@sl...> - 2016-07-09 03:27:09
|
Typically when either: - The format is not supported by TSK - There are multiple formats that TSK thinks could exist and it will therefore force the user to pick > On Jul 6, 2016, at 3:31 PM, Edward Diener <eld...@tr...> wrote: > > In what situations do the autodetection of the image type for an image, > or the autodetection of file system types in a volume of an image, not > work ? > > Eddie Diener > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: Edward D. <eld...@tr...> - 2016-07-06 19:31:09
|
In what situations do the autodetection of the image type for an image, or the autodetection of file system types in a volume of an image, not work ? Eddie Diener |
From: Rajmund <ra...@4e...> - 2016-07-06 17:35:15
|
Hi Roberto, For Autopsy 3 I did some testing which Artifact to use as I faced the same issue. Under the link you can find how the different Artifacts show up in Autopsy and what fields you can use. http://www.4ensics.co.uk/2014/05/autopsy-3-artifacts-attributes-quick-overview/ Regards Rajmund From: Roberto Amelio [mailto:g.r...@gm...] Sent: 06 July 2016 17:59 To: sle...@li... Subject: [sleuthkit-developers] Python Ingest Module - Blackboard artifacts Hi, I am developing an ingest module in python and I didn't get whether it's possible to create my own artifact type. To be more specific, how can I collect all my results under the same label in the tree on the left-hand side? Regards, Roberto |
From: Roberto A. <g.r...@gm...> - 2016-07-06 16:59:06
|
Hi, I am developing an ingest module in python and I didn't get whether it's possible to create my own artifact type. To be more specific, how can I collect all my results under the same label in the tree on the left-hand side? Regards, Roberto |
From: Edward D. <eld...@tr...> - 2016-07-03 16:53:53
|
The VC++ DLLs which are included in the SleuthKit 4.2.0 Windows release at https://sourceforge.net/projects/sleuthkit/files/sleuthkit/4.2.0/sleuthkit-4.2.0-win32.zip/download are the wrong ones. They are 64-bit VC++ DLLs for msvcp100.dll and msvcr100.dll in VS2010 instead of the correct 32-bit versions. Running either: dumpbin /headers msvcp100.dll dumpbin /headers msvcr100.dll or running Dependency Walker on those DLLs clearly shows that they are the wrong ones. Shouldn't they be corrected for people wanted to downlaod the latest official SleuthKit release ? Edward Diener |
From: Edward D. <eld...@tr...> - 2016-07-01 13:11:28
|
In TSK libtsk is a static library. Is there any technical reason libtsk could not be a DLL or series of DLLs offering TSK functionality ? I belive this would allow other languages to use its functionality much easier as long as each C function in lbtsk were specified 'extern "C"' so that C++ name mangling were not being done. What are the issues involving this as seen by others who know TSK much better than I do ? Eddie Diener |
From: Edward D. <eld...@tr...> - 2016-06-29 19:26:42
|
I am seeing the platform toolset in the VS2010 projects for libewf_64bit and sleuthkit set to "Windows7.1SDK" for the 64-bit build and "v100" for the 32-bit build in sleuthkit. Is there a reason for this ? I do not have a "Windows7.1SDK" platform toolset for VS2010 either under Windows 7 or Windows 8.1. Eddie Diener |
From: Jon S. <JSt...@St...> - 2016-06-28 17:26:39
|
My company released NTFS-Linker last year, which links with libtsk and Joachim Metz's libvshadow to parse $UsnJrnl and $LogFile entries on all volume shadow copies and the current state of the volume and organizes them into a unified timeline in a sqlite database. More information is here: http://strozfriedberg.github.io/ntfs-linker/ Cheers, Jon > -----Original Message----- > From: noxdafox [mailto:nox...@gm...] > Sent: Tuesday, June 28, 2016 12:49 PM > To: sle...@li... > Subject: [sleuthkit-developers] Update Sequence Number Journal support > > Greetings, > > recently I've been playing around with NTFS Update Sequence Number > Journals which I find a fairly good instrument for extracting timelines > from NTFS drives. > > I have been writing few parsers for it, the last one been written in C. > > I was thinking about porting it to sleuthkit. Do you think it would be > beneficial for the library? > > The idea would be to expose a visitor API (in similar fashion as for > tsk_fs_dir_walk) and then a command line tool built on top of it. > > More info about UsnJrnl files: > https://msdn.microsoft.com/en- > us/library/windows/desktop/aa365722%28v=vs.85%29.aspx?f=255&MSPPErr > or=-2147217396# > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
From: noxdafox <nox...@gm...> - 2016-06-28 17:12:15
|
There are few open source and commercial solutions which rely on NTFS internals in order to retrieve data useful to build timelines of events. My point is that sleuthkit is missing such a capability and I was wondering if the community would be interested in such a feature. I'd rather ask than come with a pull request out of the blue :) On 28/06/16 20:06, Jon Stewart wrote: > My company released NTFS-Linker last year, which links with libtsk and Joachim Metz's libvshadow to parse $UsnJrnl and $LogFile entries on all volume shadow copies and the current state of the volume and organizes them into a unified timeline in a sqlite database. > > More information is here: http://strozfriedberg.github.io/ntfs-linker/ > > Cheers, > > Jon > >> -----Original Message----- >> From: noxdafox [mailto:nox...@gm...] >> Sent: Tuesday, June 28, 2016 12:49 PM >> To: sle...@li... >> Subject: [sleuthkit-developers] Update Sequence Number Journal support >> >> Greetings, >> >> recently I've been playing around with NTFS Update Sequence Number >> Journals which I find a fairly good instrument for extracting timelines >> from NTFS drives. >> >> I have been writing few parsers for it, the last one been written in C. >> >> I was thinking about porting it to sleuthkit. Do you think it would be >> beneficial for the library? >> >> The idea would be to expose a visitor API (in similar fashion as for >> tsk_fs_dir_walk) and then a command line tool built on top of it. >> >> More info about UsnJrnl files: >> https://msdn.microsoft.com/en- >> us/library/windows/desktop/aa365722%28v=vs.85%29.aspx?f=255&MSPPErr >> or=-2147217396# >> >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |