sleuthkit-users Mailing List for The Sleuth Kit (Page 19)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(20) |
Mar
(60) |
Apr
(40) |
May
(24) |
Jun
(28) |
Jul
(18) |
Aug
(27) |
Sep
(6) |
Oct
(14) |
Nov
(15) |
Dec
(22) |
| 2004 |
Jan
(34) |
Feb
(13) |
Mar
(28) |
Apr
(23) |
May
(27) |
Jun
(26) |
Jul
(37) |
Aug
(19) |
Sep
(20) |
Oct
(39) |
Nov
(17) |
Dec
(9) |
| 2005 |
Jan
(45) |
Feb
(43) |
Mar
(66) |
Apr
(36) |
May
(19) |
Jun
(64) |
Jul
(10) |
Aug
(11) |
Sep
(35) |
Oct
(6) |
Nov
(4) |
Dec
(13) |
| 2006 |
Jan
(52) |
Feb
(34) |
Mar
(39) |
Apr
(39) |
May
(37) |
Jun
(15) |
Jul
(13) |
Aug
(48) |
Sep
(9) |
Oct
(10) |
Nov
(47) |
Dec
(13) |
| 2007 |
Jan
(25) |
Feb
(4) |
Mar
(2) |
Apr
(29) |
May
(11) |
Jun
(19) |
Jul
(13) |
Aug
(15) |
Sep
(30) |
Oct
(12) |
Nov
(10) |
Dec
(13) |
| 2008 |
Jan
(2) |
Feb
(54) |
Mar
(58) |
Apr
(43) |
May
(10) |
Jun
(27) |
Jul
(25) |
Aug
(27) |
Sep
(48) |
Oct
(69) |
Nov
(55) |
Dec
(43) |
| 2009 |
Jan
(26) |
Feb
(36) |
Mar
(28) |
Apr
(27) |
May
(55) |
Jun
(9) |
Jul
(19) |
Aug
(16) |
Sep
(15) |
Oct
(17) |
Nov
(70) |
Dec
(21) |
| 2010 |
Jan
(56) |
Feb
(59) |
Mar
(53) |
Apr
(32) |
May
(25) |
Jun
(31) |
Jul
(36) |
Aug
(11) |
Sep
(37) |
Oct
(19) |
Nov
(23) |
Dec
(6) |
| 2011 |
Jan
(21) |
Feb
(20) |
Mar
(30) |
Apr
(30) |
May
(74) |
Jun
(50) |
Jul
(34) |
Aug
(34) |
Sep
(12) |
Oct
(33) |
Nov
(10) |
Dec
(8) |
| 2012 |
Jan
(23) |
Feb
(57) |
Mar
(26) |
Apr
(14) |
May
(27) |
Jun
(27) |
Jul
(60) |
Aug
(88) |
Sep
(13) |
Oct
(36) |
Nov
(97) |
Dec
(85) |
| 2013 |
Jan
(60) |
Feb
(24) |
Mar
(43) |
Apr
(32) |
May
(22) |
Jun
(38) |
Jul
(51) |
Aug
(50) |
Sep
(76) |
Oct
(65) |
Nov
(25) |
Dec
(30) |
| 2014 |
Jan
(19) |
Feb
(41) |
Mar
(43) |
Apr
(28) |
May
(61) |
Jun
(12) |
Jul
(10) |
Aug
(37) |
Sep
(76) |
Oct
(31) |
Nov
(41) |
Dec
(12) |
| 2015 |
Jan
(33) |
Feb
(28) |
Mar
(53) |
Apr
(22) |
May
(29) |
Jun
(20) |
Jul
(15) |
Aug
(17) |
Sep
(52) |
Oct
(3) |
Nov
(18) |
Dec
(21) |
| 2016 |
Jan
(20) |
Feb
(8) |
Mar
(21) |
Apr
(7) |
May
(13) |
Jun
(35) |
Jul
(34) |
Aug
(11) |
Sep
(14) |
Oct
(22) |
Nov
(31) |
Dec
(23) |
| 2017 |
Jan
(20) |
Feb
(7) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(22) |
Jul
(11) |
Aug
(16) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(16) |
Dec
(13) |
| 2019 |
Jan
|
Feb
(1) |
Mar
(25) |
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simson G. <si...@ac...> - 2016-03-23 23:33:06
|
Luis, This is the point at which someone (Alex?) should be asking a few pointed questions, to wit: • Does anybody know of any formal validation that's been done to compare the output of FTK, EnCase, TSK, and Autopsy? > On Mar 23, 2016, at 7:17 PM, Luís Filipe Nassif <lfc...@gm...> wrote: > > I have just confirmed this issue with 2 (of 3) ntfs images processed with tsk_loaddb I am working right now, so the problem seems quite common. There are a number of allocated files below some deleted directories in the file system tree and the path of those files shows different parents. Looking into the true parent directories (not deleted), there is no children. My colleague observed this behaviour at least in 3 ntfs images. > > I modified the logic of TskDbSqlite::storeObjId() and TskDbSqlite::findParObjId in db_sqlite.cpp to ignore the NTFS sequence number and to use the file paths when there are multiple items pointing to the same meta_addr, like is already done for other file systems. That change solved the problem, but I not sure if it could cause side effects for NTFS? > > Best regards, > Luis > > 2016-03-22 13:10 GMT-03:00 Luís Filipe Nassif <lfc...@gm... <mailto:lfc...@gm...>>: > Hi, > > A colleague of mine have observed tsk_loaddb 4.2 (so I think Autopsy too) incorrectly decoding the file system tree of some NTFS images. I analysed one sqlite sent by him and tsk_loaddb is putting a number of (very important) files into a deleted directory with the same meta_addr and meta_seq of the true (not deleted) parent directory of those files, according to tsk_objects table. The parent_path of the child files are populated correctly into sqlite. > > Maybe the parent cache table logic used internally by tsk_loaddb should be updated to handle that situation (NTFS files with same meta_addr and meta_seq)? > > We will gladly provide any other information to help solve the problem. > > Thank you very much for your attention, > Luis > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Luís F. N. <lfc...@gm...> - 2016-03-23 23:17:24
|
I have just confirmed this issue with 2 (of 3) ntfs images processed with tsk_loaddb I am working right now, so the problem seems quite common. There are a number of allocated files below some deleted directories in the file system tree and the path of those files shows different parents. Looking into the true parent directories (not deleted), there is no children. My colleague observed this behaviour at least in 3 ntfs images. I modified the logic of TskDbSqlite::storeObjId() and TskDbSqlite::findParObjId in db_sqlite.cpp to ignore the NTFS sequence number and to use the file paths when there are multiple items pointing to the same meta_addr, like is already done for other file systems. That change solved the problem, but I not sure if it could cause side effects for NTFS? Best regards, Luis 2016-03-22 13:10 GMT-03:00 Luís Filipe Nassif <lfc...@gm...>: > Hi, > > A colleague of mine have observed tsk_loaddb 4.2 (so I think Autopsy too) > incorrectly decoding the file system tree of some NTFS images. I analysed > one sqlite sent by him and tsk_loaddb is putting a number of (very > important) files into a deleted directory with the same meta_addr and > meta_seq of the true (not deleted) parent directory of those files, > according to tsk_objects table. The parent_path of the child files are > populated correctly into sqlite. > > Maybe the parent cache table logic used internally by tsk_loaddb should be > updated to handle that situation (NTFS files with same meta_addr and > meta_seq)? > > We will gladly provide any other information to help solve the problem. > > Thank you very much for your attention, > Luis > |
|
From: Luís F. N. <lfc...@gm...> - 2016-03-22 16:10:21
|
Hi, A colleague of mine have observed tsk_loaddb 4.2 (so I think Autopsy too) incorrectly decoding the file system tree of some NTFS images. I analysed one sqlite sent by him and tsk_loaddb is putting a number of (very important) files into a deleted directory with the same meta_addr and meta_seq of the true (not deleted) parent directory of those files, according to tsk_objects table. The parent_path of the child files are populated correctly into sqlite. Maybe the parent cache table logic used internally by tsk_loaddb should be updated to handle that situation (NTFS files with same meta_addr and meta_seq)? We will gladly provide any other information to help solve the problem. Thank you very much for your attention, Luis |
|
From: MATT P. <mat...@ad...> - 2016-03-07 21:10:47
|
So I had to chase other bumpers for a while. Getting back to this I find the same errors when I ingest this specific pst file. I can load the pst in outlook. The original pst file did have errors that were connected by scanpst.
From: Pasquale Rinaldi [mailto:pjr...@gm...]
Sent: Friday, February 19, 2016 6:02 PM
To: MATT PIERCE <mat...@ad...>
Cc: sle...@li...
Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest.
The java heap error references the jvm running out of memory. The best way to test if it is the jvm or the pst file would be to load the pst file in outlook or a pst viewer and see if it loads completely or errors out.
Im not sure how autopsy, the pst ingest module, or the jvm interaction are configured in terms of memory management, but how much memory does your system have?
Pasquale
On Feb 19, 2016 5:23 PM, "MATT PIERCE" <mat...@ad...<mailto:mat...@ad...>> wrote:
I ran a scanpst on the file causing errors and changed the behavior of autopsy. Now I get a Java Heap Space error.
2016-02-19 13:59:23.19 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\3077828-RE: Address: Dell India Private Limited (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:24.272 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\3259204-RE: Your Approval Required [Requisition : 3299154 - PR - 1] (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:35.273 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.IOException: attachmentStream invalid (read() fails). File Scorecard 2011.txt skipped:
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:261)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:49.05 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\2854020-C:\Users\person\AppData\Local\Temp\Inv_336802_from_Adobe_Systems_9452.pdf (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob logIngestModuleErrors
SEVERE: Email Parser experienced an error analyzing LogicalFileSet2 (jobId=4)
java.lang.OutOfMemoryError: Java heap space:
java.lang.StringCoding$StringDecoder.decode(Unknown Source)
java.lang.StringCoding.decode(Unknown Source)
java.lang.StringCoding.decode(Unknown Source)
java.lang.String.<init>(Unknown Source)
java.lang.String.<init>(Unknown Source)
com.pff.LZFu.decode(LZFu.java:115)
com.pff.PSTMessage.getRTFBody(PSTMessage.java:79)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob finishFirstStage
INFO: Finished first stage analysis for LogicalFileSet2 (jobId=4)
2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.DataSourceIngestJob finish
INFO: Finished analysis for LogicalFileSet2 (jobId=4)
2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.IngestManager finishIngestJob
INFO: Ingest job 4 completed
From: Simson Garfinkel [mailto:si...@gm...<mailto:si...@gm...>]
Sent: Friday, February 19, 2016 2:50 PM
To: MATT PIERCE <mat...@ad...<mailto:mat...@ad...>>
Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest.
But autopsy does not display the mail headers. So you are missing valuable and important metadata
----
Sent from my phone.
On Feb 19, 2016, at 3:37 PM, MATT PIERCE <mat...@ad...<mailto:mat...@ad...>> wrote:
I'm using Autopsy to scan psts to find wich might contain relevant.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Simson Garfinkel <si...@gm...<mailto:si...@gm...>>
Date: 2/19/2016 2:35 PM (GMT-06:00)
To: MATT PIERCE <mat...@ad...<mailto:mat...@ad...>>
Cc: sle...@li...<mailto:sle...@li...>
Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest.
Matt,
How are you handling the mail headers? Are you ignoring them in your investigation?
Sent from my iPhone
On Feb 19, 2016, at 1:42 PM, MATT PIERCE <mat...@ad...<mailto:mat...@ad...>> wrote:
I’m performing a logical file ingest of a pst file. I would like to search through the contents of this mail file for particular keywords. Unfortunately this pst file is generating the error GC overhead limit exceeded. An OST file from the same case is working fine. Is there anything I can do to complete the ingest? I found a few 9other users have experienced this error but no suggestions concerning what to do.
Forum Post.
http://forum.sleuthkit.org/viewtopic.php?f=6&t=2337&p=2478&hilit=gc+overhead#p2478
Version info.
Product Version: Autopsy 4.0.0 (RELEASE)
Sleuth Kit Version: 4.2.0
Netbeans RCP Build: 201411181905
Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (autopsy)
Here is what I believe to be the relevant log entry
2016-02-19 12:16:51.052 org.sleuthkit.autopsy.ingest.DataSourceIngestJob logIngestModuleErrors
SEVERE: Email Parser experienced an error analyzing LogicalFileSet1 (jobId=2)
java.lang.OutOfMemoryError: Java heap space:
com.pff.LZFu.decode(LZFu.java:60)
com.pff.PSTMessage.getRTFBody(PSTMessage.java:79)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org
|
|
From: Pasquale R. <pjr...@gm...> - 2016-02-20 00:02:32
|
The java heap error references the jvm running out of memory. The best way to test if it is the jvm or the pst file would be to load the pst file in outlook or a pst viewer and see if it loads completely or errors out. Im not sure how autopsy, the pst ingest module, or the jvm interaction are configured in terms of memory management, but how much memory does your system have? Pasquale On Feb 19, 2016 5:23 PM, "MATT PIERCE" <mat...@ad...> wrote: > I ran a scanpst on the file causing errors and changed the behavior of > autopsy. Now I get a Java Heap Space error. > > > > 2016-02-19 13:59:23.19 org.sleuthkit.autopsy.thunderbirdparser.PstParser > extractAttachments > > WARNING: Failed to extract attachment from pst file. > > java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email > Parser\3077828-RE: Address: Dell India Private Limited (The filename, > directory name, or volume label syntax is incorrect): > > java.io.FileOutputStream.open0(Native Method) > > java.io.FileOutputStream.open(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > > 2016-02-19 13:59:24.272 org.sleuthkit.autopsy.thunderbirdparser.PstParser > extractAttachments > > WARNING: Failed to extract attachment from pst file. > > java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email > Parser\3259204-RE: Your Approval Required [Requisition : 3299154 - PR > - 1] (The filename, directory name, or volume label syntax is incorrect): > > java.io.FileOutputStream.open0(Native Method) > > java.io.FileOutputStream.open(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > > 2016-02-19 13:59:35.273 org.sleuthkit.autopsy.thunderbirdparser.PstParser > extractAttachments > > WARNING: Failed to extract attachment from pst file. > > java.io.IOException: attachmentStream invalid (read() fails). File > Scorecard 2011.txt skipped: > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:261) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > > 2016-02-19 13:59:49.05 org.sleuthkit.autopsy.thunderbirdparser.PstParser > extractAttachments > > WARNING: Failed to extract attachment from pst file. > > java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email > Parser\2854020-C:\Users\person\AppData\Local\Temp\Inv_336802_from_Adobe_Systems_9452.pdf > (The filename, directory name, or volume label syntax is incorrect): > > java.io.FileOutputStream.open0(Native Method) > > java.io.FileOutputStream.open(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > java.io.FileOutputStream.<init>(Unknown Source) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > > 2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob > logIngestModuleErrors > > SEVERE: Email Parser experienced an error analyzing LogicalFileSet2 > (jobId=4) > > java.lang.OutOfMemoryError: Java heap space: > > java.lang.StringCoding$StringDecoder.decode(Unknown Source) > > java.lang.StringCoding.decode(Unknown Source) > > java.lang.StringCoding.decode(Unknown Source) > > java.lang.String.<init>(Unknown Source) > > java.lang.String.<init>(Unknown Source) > > com.pff.LZFu.decode(LZFu.java:115) > > com.pff.PSTMessage.getRTFBody(PSTMessage.java:79) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > > 2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob > finishFirstStage > > INFO: Finished first stage analysis for LogicalFileSet2 (jobId=4) > > 2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.DataSourceIngestJob > finish > > INFO: Finished analysis for LogicalFileSet2 (jobId=4) > > 2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.IngestManager > finishIngestJob > > INFO: Ingest job 4 completed > > > > *From:* Simson Garfinkel [mailto:si...@gm...] > *Sent:* Friday, February 19, 2016 2:50 PM > *To:* MATT PIERCE <mat...@ad...> > *Subject:* Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest. > > > > But autopsy does not display the mail headers. So you are missing valuable > and important metadata > > > > ---- > > Sent from my phone. > > > On Feb 19, 2016, at 3:37 PM, MATT PIERCE <mat...@ad...> wrote: > > I'm using Autopsy to scan psts to find wich might contain relevant. > > > > > > > > Sent from my Verizon Wireless 4G LTE smartphone > > > > > > -------- Original message -------- > > From: Simson Garfinkel <si...@gm...> > > Date: 2/19/2016 2:35 PM (GMT-06:00) > > To: MATT PIERCE <mat...@ad...> > > Cc: sle...@li... > > Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest. > > > > Matt, > > > > How are you handling the mail headers? Are you ignoring them in your > investigation? > > Sent from my iPhone > > > On Feb 19, 2016, at 1:42 PM, MATT PIERCE <mat...@ad...> wrote: > > I’m performing a logical file ingest of a pst file. I would like to > search through the contents of this mail file for particular keywords. > Unfortunately this pst file is generating the error GC overhead limit > exceeded. An OST file from the same case is working fine. Is there > anything I can do to complete the ingest? I found a few 9other users have > experienced this error but no suggestions concerning what to do. > > > > Forum Post. > > > http://forum.sleuthkit.org/viewtopic.php?f=6&t=2337&p=2478&hilit=gc+overhead#p2478 > > > > Version info. > > *Product Version:* Autopsy 4.0.0 (RELEASE) > *Sleuth Kit Version:* 4.2.0 > *Netbeans RCP Build:* 201411181905 > *Java:* 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 > *System:* Windows 7 version 6.1 running on amd64; Cp1252; en_US (autopsy) > > > > Here is what I believe to be the relevant log entry > > > > 2016-02-19 12:16:51.052 org.sleuthkit.autopsy.ingest.DataSourceIngestJob > logIngestModuleErrors > > SEVERE: Email Parser experienced an error analyzing LogicalFileSet1 > (jobId=2) > > java.lang.OutOfMemoryError: Java heap space: > > com.pff.LZFu.decode(LZFu.java:60) > > com.pff.PSTMessage.getRTFBody(PSTMessage.java:79) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) > > > org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) > > > org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) > > > org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) > > > org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) > > > org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) > > > org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) > > > java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > > java.util.concurrent.FutureTask.run(Unknown Source) > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > java.lang.Thread.run(Unknown Source) > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > |
|
From: MATT P. <mat...@ad...> - 2016-02-19 22:18:06
|
I ran a scanpst on the file causing errors and changed the behavior of autopsy. Now I get a Java Heap Space error.
2016-02-19 13:59:23.19 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\3077828-RE: Address: Dell India Private Limited (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:24.272 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\3259204-RE: Your Approval Required [Requisition : 3299154 - PR - 1] (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:35.273 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.IOException: attachmentStream invalid (read() fails). File Scorecard 2011.txt skipped:
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:261)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 13:59:49.05 org.sleuthkit.autopsy.thunderbirdparser.PstParser extractAttachments
WARNING: Failed to extract attachment from pst file.
java.io.FileNotFoundException: B:\test\person test\ModuleOutput\Email Parser\2854020-C:\Users\person\AppData\Local\Temp\Inv_336802_from_Adobe_Systems_9452.pdf (The filename, directory name, or volume label syntax is incorrect):
java.io.FileOutputStream.open0(Native Method)
java.io.FileOutputStream.open(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
java.io.FileOutputStream.<init>(Unknown Source)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.saveAttachmentToDisk(PstParser.java:254)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractAttachments(PstParser.java:220)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:189)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob logIngestModuleErrors
SEVERE: Email Parser experienced an error analyzing LogicalFileSet2 (jobId=4)
java.lang.OutOfMemoryError: Java heap space:
java.lang.StringCoding$StringDecoder.decode(Unknown Source)
java.lang.StringCoding.decode(Unknown Source)
java.lang.StringCoding.decode(Unknown Source)
java.lang.String.<init>(Unknown Source)
java.lang.String.<init>(Unknown Source)
com.pff.LZFu.decode(LZFu.java:115)
com.pff.PSTMessage.getRTFBody(PSTMessage.java:79)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
2016-02-19 14:00:03.618 org.sleuthkit.autopsy.ingest.DataSourceIngestJob finishFirstStage
INFO: Finished first stage analysis for LogicalFileSet2 (jobId=4)
2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.DataSourceIngestJob finish
INFO: Finished analysis for LogicalFileSet2 (jobId=4)
2016-02-19 14:00:03.619 org.sleuthkit.autopsy.ingest.IngestManager finishIngestJob
INFO: Ingest job 4 completed
From: Simson Garfinkel [mailto:si...@gm...]
Sent: Friday, February 19, 2016 2:50 PM
To: MATT PIERCE <mat...@ad...>
Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest.
But autopsy does not display the mail headers. So you are missing valuable and important metadata
----
Sent from my phone.
On Feb 19, 2016, at 3:37 PM, MATT PIERCE <mat...@ad...<mailto:mat...@ad...>> wrote:
I'm using Autopsy to scan psts to find wich might contain relevant.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Simson Garfinkel <si...@gm...<mailto:si...@gm...>>
Date: 2/19/2016 2:35 PM (GMT-06:00)
To: MATT PIERCE <mat...@ad...<mailto:mat...@ad...>>
Cc: sle...@li...<mailto:sle...@li...>
Subject: Re: [sleuthkit-users] GC overhead limit exceeded on pst ingest.
Matt,
How are you handling the mail headers? Are you ignoring them in your investigation?
Sent from my iPhone
On Feb 19, 2016, at 1:42 PM, MATT PIERCE <mat...@ad...<mailto:mat...@ad...>> wrote:
I’m performing a logical file ingest of a pst file. I would like to search through the contents of this mail file for particular keywords. Unfortunately this pst file is generating the error GC overhead limit exceeded. An OST file from the same case is working fine. Is there anything I can do to complete the ingest? I found a few 9other users have experienced this error but no suggestions concerning what to do.
Forum Post.
http://forum.sleuthkit.org/viewtopic.php?f=6&t=2337&p=2478&hilit=gc+overhead#p2478
Version info.
Product Version: Autopsy 4.0.0 (RELEASE)
Sleuth Kit Version: 4.2.0
Netbeans RCP Build: 201411181905
Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (autopsy)
Here is what I believe to be the relevant log entry
2016-02-19 12:16:51.052 org.sleuthkit.autopsy.ingest.DataSourceIngestJob logIngestModuleErrors
SEVERE: Email Parser experienced an error analyzing LogicalFileSet1 (jobId=2)
java.lang.OutOfMemoryError: Java heap space:
com.pff.LZFu.decode(LZFu.java:60)
com.pff.PSTMessage.getRTFBody(PSTMessage.java:79)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140)
org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142)
org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105)
org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222)
org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122)
org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703)
org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44)
org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org
|
|
From: MATT P. <mat...@ad...> - 2016-02-19 18:58:00
|
I'm performing a logical file ingest of a pst file. I would like to search through the contents of this mail file for particular keywords. Unfortunately this pst file is generating the error GC overhead limit exceeded. An OST file from the same case is working fine. Is there anything I can do to complete the ingest? I found a few 9other users have experienced this error but no suggestions concerning what to do. Forum Post. http://forum.sleuthkit.org/viewtopic.php?f=6&t=2337&p=2478&hilit=gc+overhead#p2478 Version info. Product Version: Autopsy 4.0.0 (RELEASE) Sleuth Kit Version: 4.2.0 Netbeans RCP Build: 201411181905 Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (autopsy) Here is what I believe to be the relevant log entry 2016-02-19 12:16:51.052 org.sleuthkit.autopsy.ingest.DataSourceIngestJob logIngestModuleErrors SEVERE: Email Parser experienced an error analyzing LogicalFileSet1 (jobId=2) java.lang.OutOfMemoryError: Java heap space: com.pff.LZFu.decode(LZFu.java:60) com.pff.PSTMessage.getRTFBody(PSTMessage.java:79) org.sleuthkit.autopsy.thunderbirdparser.PstParser.extractEmailMessage(PstParser.java:179) org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:149) org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) org.sleuthkit.autopsy.thunderbirdparser.PstParser.processFolder(PstParser.java:140) org.sleuthkit.autopsy.thunderbirdparser.PstParser.parse(PstParser.java:86) org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.processPst(ThunderbirdMboxFileIngestModule.java:142) org.sleuthkit.autopsy.thunderbirdparser.ThunderbirdMboxFileIngestModule.process(ThunderbirdMboxFileIngestModule.java:105) org.sleuthkit.autopsy.ingest.FileIngestPipeline$PipelineModule.process(FileIngestPipeline.java:222) org.sleuthkit.autopsy.ingest.FileIngestPipeline.process(FileIngestPipeline.java:122) org.sleuthkit.autopsy.ingest.DataSourceIngestJob.process(DataSourceIngestJob.java:703) org.sleuthkit.autopsy.ingest.FileIngestTask.execute(FileIngestTask.java:44) org.sleuthkit.autopsy.ingest.IngestManager$ExecuteIngestJobsTask.run(IngestManager.java:989) java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) java.util.concurrent.FutureTask.run(Unknown Source) java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.lang.Thread.run(Unknown Source) |
|
From: Brian C. <ca...@sl...> - 2016-02-17 10:32:29
|
Hi Simson, At this point, you can’t. Though, we could do like we do for HTML files and save the raw headers at the bottom of the message. I’ll make a story to do that. thanks, brian > On Feb 12, 2016, at 7:19 AM, Simson Garfinkel <si...@ac...> wrote: > > How does one view the full email header in Autopsy of an email message that was found in an Outlook PST file? It is not obvious to me from the user interface. > > Thanks. > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Simson G. <si...@ac...> - 2016-02-12 12:19:42
|
How does one view the full email header in Autopsy of an email message that was found in an Outlook PST file? It is not obvious to me from the user interface. Thanks. |
|
From: Jack O'S. <jac...@gm...> - 2016-02-09 18:32:37
|
Hi all, I'm having issues compiling on Windows using MinGW/msys. When I run ./configure the process eventuaaly fails with the following error: checking if libtool needs -no-undefined flag to build shared libraries... yes checking for getline... no checking for library containing regexec... no configure: error: missing regex I installed msys-libregex at the same time as installing MinGW, which I would have presumed would supply the necessary regex library. Am I missing something, either than I need to install or configure? I also note that slightly further up the configure output it lists a warning "Could not fine usable zlib headers" even though, again, I installed msys-zlib (and indeed mingw32-zlib), so maybe something in my library config is off, but I can't find any instructions on setting path variables that I have not already checked/followed. I was able to compile using cygwin, but it seems as though that makes the executables dependant on cygwin.dll, I would rather avoid that dependency if possible. Any help would be appreciated. Thanks, Jack |
|
From: Derrick K. <dk...@gm...> - 2016-02-05 18:15:04
|
Nice find! I'm thinking that would probably be a good bug to file on the Autopsy issues page. It may seem like a niche case but it'll probably bite someone else in the future and a quick test in Autopsy for a 'ro' case folder/file would solve this. https://github.com/sleuthkit/autopsy/issues Derrick On Wed, Feb 3, 2016 at 8:39 AM, K Murphy <km...@ci...> wrote: > Found my issue. > > I had the filesystem where the case was on marked as read-only. Evidently > Autopsy need to write in order it to come fully up. > > K Murphy > > > Quoting K Murphy <km...@ci...>: > > Hello, >> >> I have to move a case from one machine to another. While moving the files >> is not an issue, when I open the case up, and look at the keyword search >> results I get the following error message: "Could not create or open index" >> >> The original machine had the case directory off the C: drive. On the new >> machine the case directory is stored on the H: drive. >> >> Further more, I did a "netstat -a" and I do see that 127.0.0.1:23232 is >> listening. >> >> Is there a trick to making this work? >> >> Thank you, >> K Murphy >> > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > |
|
From: K M. <km...@ci...> - 2016-02-03 15:39:41
|
Found my issue. I had the filesystem where the case was on marked as read-only. Evidently Autopsy need to write in order it to come fully up. K Murphy Quoting K Murphy <km...@ci...>: > Hello, > > I have to move a case from one machine to another. While moving the > files is not an issue, when I open the case up, and look at the > keyword search results I get the following error message: "Could not > create or open index" > > The original machine had the case directory off the C: drive. On the > new machine the case directory is stored on the H: drive. > > Further more, I did a "netstat -a" and I do see that 127.0.0.1:23232 > is listening. > > Is there a trick to making this work? > > Thank you, > K Murphy |
|
From: K M. <km...@ci...> - 2016-01-28 18:54:46
|
Well tsk_gettimes worked fine. Got through the entire 3 TB drive in about 1.5 hours under Linux. I replicated my environment on the windows side. Linux exporting the dd image via nfs to a Windows 10 box. No issues with tsk_gettimes using Sleuthkit 4.1.3-win32. Is there something you would like me to try with Autopsy? Regards, K Murphy Quoting K Murphy <km...@ci...>: > It did get bigger over time. But it took days for it to increase. > > I eventually killed it and went to Bulk Extract. I was just using > Autopsy to do keyword searches. > > If there is something you'd like me to try, I still have access to > the images. > > I'll try the tsk_gettimes with the verbose option and see what > happens. Then post back. > > It would be nice to see exactly what file it is working on during > the ingest. I can see the directories but no file names. > > K Murphy > > > Quoting Brian Carrier <ca...@sl...>: > >> That time does seem way excessive and the SQLite DB has gotten quite big. >> >> Is the DB getting bigger or staying the same? >> >> I can?t think of an easy way to debug this? It maybe easiest to >> run the tsk_gettimes command from TSK on the image, which will >> produce a big text file of the files. After an hour or so, that >> output may show some insight about what it is spending so much time >> on?. >> >> >> >>> On Jan 19, 2016, at 9:11 AM, K Murphy <km...@ci...> wrote: >>> >>> Your description is what I thought it was doing. I'll answer your >>> questions below. >>> >>> >>>> Where is the disk image stored, is it on network storage, a USB >>>> drive, etc? >>> I've tried two different things: >>> 1) I originally shared out the drive images via NFS to my Windows >>> machine. Autopsy had no issues doing three of the six drives. >>> 2) I put the largest image on a drive and connected it directly to >>> the machine via usb3. >>> >>> Monitoring both situations, for is very little activity either >>> through the network (option 1 from above) or drive (option 2). >>> >>>> Where is your autopsy case directory stored, and can you see how big the >>>> file autopsy.db is? >>> Stored off on another usb3 drive in one case. I got another >>> machine with Autopsy going (same issues) where the case is stored >>> on the C: drive. >>> >>> The current size is 138,948 KB of the autopsy.db stored directly >>> on the C: drive. >>> >>>> What is the filesystem on the disk image? >>> Both drives that have been going for days are EXT3/4. >>> >>> >>> Both drives are filled with archives (of archives of archives), >>> ISOs, and virtual machine drives. It seems to me that is where it >>> is getting hung up at. >>> >>> >>> Thoughts? >>> >>> Regards, >>> K Murphy >>> >>> >>> Quoting Ketil Froyn <ke...@fr...>: >>> >>>> 5 days sounds excessive. Autopsy parses the file system(s), traversing all >>>> files and folders it can find, and stores info about this in an sqlite >>>> database (unless you've set up a postgresql environment). >>>> >>>> Where is the disk image stored, is it on network storage, a USB >>>> drive, etc? >>>> Where is your autopsy case directory stored, and can you see how big the >>>> file autopsy.db is? What is the filesystem on the disk image? >>>> >>>> Cheers, Ketil >>>> On 14 Jan 2016 20:57, "K Murphy" <km...@ci...> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> How long should the Add Data Source Wizard (Step 3 of 3) take to run? >>>>> >>>>> I got a 3 TB drive that has been running for 5 days now. I see in the >>>>> progress bar in the pop window it changes directories every now an then. >>>>> >>>>> Also what is Autopsy doing during this time frame? I ask because the I >>>>> turned all of the ingest modules off except for keyword >>>>> searches. I've seen >>>>> that kick off after Wizard is complete. >>>>> >>>>> Thanks, >>>>> K Murphy >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>>>> Monitor end-to-end web transactions and take corrective actions now >>>>> Troubleshoot faster and improve end-user experience. Signup Now! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >>>>> _______________________________________________ >>>>> sleuthkit-users mailing list >>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>> http://www.sleuthkit.org >>>>> >>>>> >>> >>> >>> <Mail >>> Attachment>------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>> http://www.sleuthkit.org |
|
From: K M. <km...@ci...> - 2016-01-27 21:47:51
|
Hello, I have to move a case from one machine to another. While moving the files is not an issue, when I open the case up, and look at the keyword search results I get the following error message: "Could not create or open index" The original machine had the case directory off the C: drive. On the new machine the case directory is stored on the H: drive. Further more, I did a "netstat -a" and I do see that 127.0.0.1:23232 is listening. Is there a trick to making this work? Thank you, K Murphy |
|
From: K M. <km...@ci...> - 2016-01-27 21:43:11
|
It did get bigger over time. But it took days for it to increase. I eventually killed it and went to Bulk Extract. I was just using Autopsy to do keyword searches. If there is something you'd like me to try, I still have access to the images. I'll try the tsk_gettimes with the verbose option and see what happens. Then post back. It would be nice to see exactly what file it is working on during the ingest. I can see the directories but no file names. K Murphy Quoting Brian Carrier <ca...@sl...>: > That time does seem way excessive and the SQLite DB has gotten quite big. > > Is the DB getting bigger or staying the same? > > I can?t think of an easy way to debug this? It maybe easiest to run > the tsk_gettimes command from TSK on the image, which will produce a > big text file of the files. After an hour or so, that output may > show some insight about what it is spending so much time on?. > > > >> On Jan 19, 2016, at 9:11 AM, K Murphy <km...@ci...> wrote: >> >> Your description is what I thought it was doing. I'll answer your >> questions below. >> >> >>> Where is the disk image stored, is it on network storage, a USB drive, etc? >> I've tried two different things: >> 1) I originally shared out the drive images via NFS to my Windows >> machine. Autopsy had no issues doing three of the six drives. >> 2) I put the largest image on a drive and connected it directly to >> the machine via usb3. >> >> Monitoring both situations, for is very little activity either >> through the network (option 1 from above) or drive (option 2). >> >>> Where is your autopsy case directory stored, and can you see how big the >>> file autopsy.db is? >> Stored off on another usb3 drive in one case. I got another machine >> with Autopsy going (same issues) where the case is stored on the C: >> drive. >> >> The current size is 138,948 KB of the autopsy.db stored directly on >> the C: drive. >> >>> What is the filesystem on the disk image? >> Both drives that have been going for days are EXT3/4. >> >> >> Both drives are filled with archives (of archives of archives), >> ISOs, and virtual machine drives. It seems to me that is where it >> is getting hung up at. >> >> >> Thoughts? >> >> Regards, >> K Murphy >> >> >> Quoting Ketil Froyn <ke...@fr...>: >> >>> 5 days sounds excessive. Autopsy parses the file system(s), traversing all >>> files and folders it can find, and stores info about this in an sqlite >>> database (unless you've set up a postgresql environment). >>> >>> Where is the disk image stored, is it on network storage, a USB drive, etc? >>> Where is your autopsy case directory stored, and can you see how big the >>> file autopsy.db is? What is the filesystem on the disk image? >>> >>> Cheers, Ketil >>> On 14 Jan 2016 20:57, "K Murphy" <km...@ci...> wrote: >>> >>>> >>>> Hello, >>>> >>>> How long should the Add Data Source Wizard (Step 3 of 3) take to run? >>>> >>>> I got a 3 TB drive that has been running for 5 days now. I see in the >>>> progress bar in the pop window it changes directories every now an then. >>>> >>>> Also what is Autopsy doing during this time frame? I ask because the I >>>> turned all of the ingest modules off except for keyword searches. >>>> I've seen >>>> that kick off after Wizard is complete. >>>> >>>> Thanks, >>>> K Murphy >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>>> Monitor end-to-end web transactions and take corrective actions now >>>> Troubleshoot faster and improve end-user experience. Signup Now! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >>>> _______________________________________________ >>>> sleuthkit-users mailing list >>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> http://www.sleuthkit.org >>>> >>>> >> >> >> <Mail >> Attachment>------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org |
|
From: Fabio N. (fnigi) <fn...@ci...> - 2016-01-26 10:10:12
|
Hi all, I have installed autopsy 3 on a windows 2012 64 bit server I add a directory to the case but is not reporting the meta file informations (mtime etc) What can cause it? Thanks Fabio -- Fabio Nigi Information Security Investigator Cisco Security Incident Response Team fn...@ci...<mailto:fn...@ci...> Cisco.com<http://www.cisco.com> [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information. |
|
From: Luís F. N. <lfc...@gm...> - 2016-01-26 01:06:33
|
Could a NTFS expert kindly take a look at Gabriel's patch? I think it is
important to have a fix, so VSS files could be properly hashed, indexed,
carved, etc.
Luis
2016-01-18 9:11 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>:
> Hum, maybe testing the file name for the presence of
> {3808876b-c176-4e48-b7ae-04046e6cc752} can restrict the patch only to VSS
> files?
>
> Luis
>
> 2016-01-16 20:16 GMT-02:00 Gabriel Francisco <gab...@gm...>:
>
>> Hi,
>>
>> I'm having problems too with Volume Shadow files at the TSK (icat,
>> istat), including TSK 4.2 (same behaviour indicated by Nassif). The
>> problem with this type of file is caused by the attribute "initialized
>> stream size" or "Valid Data Length size" (VDL size). Apparently,
>> Microsoft has forced it's value to zero to make these files
>> "invisible" to the normal Windows Backup process
>> (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/).
>>
>> I don't have much familiarity with the TSK code, but I wrote one
>> possible solution to this problem, altering the "tsk/fs/ntfs.c" file,
>> at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to
>> "ssize" when "initsize" it's equal to zero. But I don't know if this
>> solution will cause problems with other types of files (like sparse or
>> virtual files) in NTFS. I didn't find a way to limit this test only to
>> the Volume Shadow Files, but it worked properly in my few test images.
>>
>> I'm sending the patch attached only to illustrate my message, because
>> I think that other users or TSK developers could implement a better
>> solution to this problem.
>>
>> Other references related to this problem:
>> https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume
>> Shadow Copy Files incorrectly decoded]
>> http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ -
>> ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack
>> bug)
>> https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ -
>> [VDL Slack in NTFS – David G Ferguson]
>>
>> Gabriel
>>
>>
>> On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...>
>> wrote:
>> > Did someone have time to look at the istat output? It is attached again.
>> >
>> > Thank you,
>> > Luis
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming! The Go Parallel Website,
>> > sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> > hub for all things parallel software development, from weekly thought
>> > leadership blogs to news, videos, case studies, tutorials and more.
>> Take a
>> > look and join the conversation now. http://goparallel.sourceforge.net
>> > _______________________________________________
>> > sleuthkit-users mailing list
>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> > http://www.sleuthkit.org
>> >
>>
>
>
|
|
From: Lloyd <llo...@gm...> - 2016-01-22 04:22:20
|
Yes I was seeing differences in the files were showing. When I opened one
directory, it was showing the contents of another directory! That's why I
checked the verbose output. Now the problem is fixed when I commented the
line "if (cimg->seek_pos != rel_offset )" in raw.c.
On Fri, Jan 22, 2016 at 7:31 AM, Brian Carrier <ca...@sl...>
wrote:
> Are you seeing differences in what files are listed or just differences in
> the verbose output?
>
> About the device, I don’t know anything about the Windows usbstor device.
>
> > On Jan 17, 2016, at 9:14 AM, Lloyd <llo...@gm...> wrote:
> >
> > Further debugging issue I found that the data read from the disk is not
> correct in the case of live disk.
> >
> > I just commented the line 115 in raw.c ( "if (cimg->seek_pos !=
> rel_offset )" ) and in my first observation the code seems to be working.
> So i think there is some issue in storing the seek position of live disks!
> >
> > Thanks a lot,
> > Lloyd
> >
> >
> >
> > On Sat, Jan 16, 2016 at 7:59 PM, Lloyd <llo...@gm...> wrote:
> > HI,
> >
> > I ran my code in verbose mode and the output files (only differences and
> line numbers are in the file) are attached for your reference. After
> parsing sector 8512 ("fatfs_dent_parse_buf: Parsing sector 8512") there
> seems to have some difference between "raw_dump" and "live_disk". I would
> greatly appreciate any input or hints.
> >
> > Thanks a lot,
> > Lloyd
> >
> > On Fri, Jan 15, 2016 at 10:01 AM, Lloyd <llo...@gm...> wrote:
> > Thanks Brian,
> >
> > Yes the drive is mounted. It is mounted at "F:", so I tried
> >
> > TSK_IMG_INFO *tsk_img = tsk_img_open_sing(_T("\\\\.\\F:"),
> TSK_IMG_TYPE_RAW, 512);
> >
> > and it gives the correct result. Why could this ("\\?\usbstor#...") be
> failing?
> >
> > Autopsy also correctly loads this as "local disk". Isn't autopsy also
> using "\\?\usbstor" name to open the device? I tried to check the code of
> autopsy, as I am not familiar with java, couldn't locate the calls to
> "tsk_img_open".
> >
> > Any help, hint, tips would be greatly appreciated.
> >
> > Thanks,
> > Lloyd
> >
> >
> >
> > On Thu, Jan 14, 2016 at 10:11 PM, Brian Carrier <ca...@sl...>
> wrote:
> > Is the drive mounted? What happens if you use something like \\.\G:?
> >
> > > On Jan 14, 2016, at 5:54 AM, Lloyd <llo...@gm...> wrote:
> > >
> > > Hi,
> > >
> > > I am using libtsk (sleuthkit 4.2) to open and find files in a "live
> usb disk (4gb)". For that I have used tsk_img_open_sing with
> TSK_IMG_TYPE_RAW. The device name starts with "\\?\usbstor#..."
> > >
> > > The files listed in this are incomplete and wrong.
> > >
> > > So I took a raw image of the disk and again fed to tsk the same way,
> this time it shows the result correctly.
> > >
> > > Am I doing something wrong? When I checked the source of
> "tsk_img_open_sing " it shows that opening "winobj" is supported.
> > >
> > > Any guidance is greatly appreciated.
> > >
> > > Thanks,
> > > Lloyd
> > >
> ------------------------------------------------------------------------------
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> > > sleuthkit-users mailing list
> > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > > http://www.sleuthkit.org
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
>
>
|
|
From: Brian C. <ca...@sl...> - 2016-01-22 02:09:07
|
That time does seem way excessive and the SQLite DB has gotten quite big. Is the DB getting bigger or staying the same? I can’t think of an easy way to debug this… It maybe easiest to run the tsk_gettimes command from TSK on the image, which will produce a big text file of the files. After an hour or so, that output may show some insight about what it is spending so much time on…. > On Jan 19, 2016, at 9:11 AM, K Murphy <km...@ci...> wrote: > > Your description is what I thought it was doing. I'll answer your questions below. > > >> Where is the disk image stored, is it on network storage, a USB drive, etc? > I've tried two different things: > 1) I originally shared out the drive images via NFS to my Windows machine. Autopsy had no issues doing three of the six drives. > 2) I put the largest image on a drive and connected it directly to the machine via usb3. > > Monitoring both situations, for is very little activity either through the network (option 1 from above) or drive (option 2). > >> Where is your autopsy case directory stored, and can you see how big the >> file autopsy.db is? > Stored off on another usb3 drive in one case. I got another machine with Autopsy going (same issues) where the case is stored on the C: drive. > > The current size is 138,948 KB of the autopsy.db stored directly on the C: drive. > >> What is the filesystem on the disk image? > Both drives that have been going for days are EXT3/4. > > > Both drives are filled with archives (of archives of archives), ISOs, and virtual machine drives. It seems to me that is where it is getting hung up at. > > > Thoughts? > > Regards, > K Murphy > > > Quoting Ketil Froyn <ke...@fr...>: > >> 5 days sounds excessive. Autopsy parses the file system(s), traversing all >> files and folders it can find, and stores info about this in an sqlite >> database (unless you've set up a postgresql environment). >> >> Where is the disk image stored, is it on network storage, a USB drive, etc? >> Where is your autopsy case directory stored, and can you see how big the >> file autopsy.db is? What is the filesystem on the disk image? >> >> Cheers, Ketil >> On 14 Jan 2016 20:57, "K Murphy" <km...@ci...> wrote: >> >>> >>> Hello, >>> >>> How long should the Add Data Source Wizard (Step 3 of 3) take to run? >>> >>> I got a 3 TB drive that has been running for 5 days now. I see in the >>> progress bar in the pop window it changes directories every now an then. >>> >>> Also what is Autopsy doing during this time frame? I ask because the I >>> turned all of the ingest modules off except for keyword searches. I've seen >>> that kick off after Wizard is complete. >>> >>> Thanks, >>> K Murphy >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >>> _______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>> http://www.sleuthkit.org >>> >>> > > > <Mail Attachment>------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Brian C. <ca...@sl...> - 2016-01-22 02:01:33
|
Are you seeing differences in what files are listed or just differences in the verbose output?
About the device, I don’t know anything about the Windows usbstor device.
> On Jan 17, 2016, at 9:14 AM, Lloyd <llo...@gm...> wrote:
>
> Further debugging issue I found that the data read from the disk is not correct in the case of live disk.
>
> I just commented the line 115 in raw.c ( "if (cimg->seek_pos != rel_offset )" ) and in my first observation the code seems to be working. So i think there is some issue in storing the seek position of live disks!
>
> Thanks a lot,
> Lloyd
>
>
>
> On Sat, Jan 16, 2016 at 7:59 PM, Lloyd <llo...@gm...> wrote:
> HI,
>
> I ran my code in verbose mode and the output files (only differences and line numbers are in the file) are attached for your reference. After parsing sector 8512 ("fatfs_dent_parse_buf: Parsing sector 8512") there seems to have some difference between "raw_dump" and "live_disk". I would greatly appreciate any input or hints.
>
> Thanks a lot,
> Lloyd
>
> On Fri, Jan 15, 2016 at 10:01 AM, Lloyd <llo...@gm...> wrote:
> Thanks Brian,
>
> Yes the drive is mounted. It is mounted at "F:", so I tried
>
> TSK_IMG_INFO *tsk_img = tsk_img_open_sing(_T("\\\\.\\F:"), TSK_IMG_TYPE_RAW, 512);
>
> and it gives the correct result. Why could this ("\\?\usbstor#...") be failing?
>
> Autopsy also correctly loads this as "local disk". Isn't autopsy also using "\\?\usbstor" name to open the device? I tried to check the code of autopsy, as I am not familiar with java, couldn't locate the calls to "tsk_img_open".
>
> Any help, hint, tips would be greatly appreciated.
>
> Thanks,
> Lloyd
>
>
>
> On Thu, Jan 14, 2016 at 10:11 PM, Brian Carrier <ca...@sl...> wrote:
> Is the drive mounted? What happens if you use something like \\.\G:?
>
> > On Jan 14, 2016, at 5:54 AM, Lloyd <llo...@gm...> wrote:
> >
> > Hi,
> >
> > I am using libtsk (sleuthkit 4.2) to open and find files in a "live usb disk (4gb)". For that I have used tsk_img_open_sing with TSK_IMG_TYPE_RAW. The device name starts with "\\?\usbstor#..."
> >
> > The files listed in this are incomplete and wrong.
> >
> > So I took a raw image of the disk and again fed to tsk the same way, this time it shows the result correctly.
> >
> > Am I doing something wrong? When I checked the source of "tsk_img_open_sing " it shows that opening "winobj" is supported.
> >
> > Any guidance is greatly appreciated.
> >
> > Thanks,
> > Lloyd
> > ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
|
|
From: K M. <km...@ci...> - 2016-01-19 14:11:28
|
Your description is what I thought it was doing. I'll answer your questions below. > Where is the disk image stored, is it on network storage, a USB drive, etc? I've tried two different things: 1) I originally shared out the drive images via NFS to my Windows machine. Autopsy had no issues doing three of the six drives. 2) I put the largest image on a drive and connected it directly to the machine via usb3. Monitoring both situations, for is very little activity either through the network (option 1 from above) or drive (option 2). > Where is your autopsy case directory stored, and can you see how big the > file autopsy.db is? Stored off on another usb3 drive in one case. I got another machine with Autopsy going (same issues) where the case is stored on the C: drive. The current size is 138,948 KB of the autopsy.db stored directly on the C: drive. > What is the filesystem on the disk image? Both drives that have been going for days are EXT3/4. Both drives are filled with archives (of archives of archives), ISOs, and virtual machine drives. It seems to me that is where it is getting hung up at. Thoughts? Regards, K Murphy Quoting Ketil Froyn <ke...@fr...>: > 5 days sounds excessive. Autopsy parses the file system(s), traversing all > files and folders it can find, and stores info about this in an sqlite > database (unless you've set up a postgresql environment). > > Where is the disk image stored, is it on network storage, a USB drive, etc? > Where is your autopsy case directory stored, and can you see how big the > file autopsy.db is? What is the filesystem on the disk image? > > Cheers, Ketil > On 14 Jan 2016 20:57, "K Murphy" <km...@ci...> wrote: > >> >> Hello, >> >> How long should the Add Data Source Wizard (Step 3 of 3) take to run? >> >> I got a 3 TB drive that has been running for 5 days now. I see in the >> progress bar in the pop window it changes directories every now an then. >> >> Also what is Autopsy doing during this time frame? I ask because the I >> turned all of the ingest modules off except for keyword searches. I've seen >> that kick off after Wizard is complete. >> >> Thanks, >> K Murphy >> >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org >> >> |
|
From: Luís F. N. <lfc...@gm...> - 2016-01-18 11:11:57
|
Hum, maybe testing the file name for the presence of
{3808876b-c176-4e48-b7ae-04046e6cc752} can restrict the patch only to VSS
files?
Luis
2016-01-16 20:16 GMT-02:00 Gabriel Francisco <gab...@gm...>:
> Hi,
>
> I'm having problems too with Volume Shadow files at the TSK (icat,
> istat), including TSK 4.2 (same behaviour indicated by Nassif). The
> problem with this type of file is caused by the attribute "initialized
> stream size" or "Valid Data Length size" (VDL size). Apparently,
> Microsoft has forced it's value to zero to make these files
> "invisible" to the normal Windows Backup process
> (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/).
>
> I don't have much familiarity with the TSK code, but I wrote one
> possible solution to this problem, altering the "tsk/fs/ntfs.c" file,
> at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to
> "ssize" when "initsize" it's equal to zero. But I don't know if this
> solution will cause problems with other types of files (like sparse or
> virtual files) in NTFS. I didn't find a way to limit this test only to
> the Volume Shadow Files, but it worked properly in my few test images.
>
> I'm sending the patch attached only to illustrate my message, because
> I think that other users or TSK developers could implement a better
> solution to this problem.
>
> Other references related to this problem:
> https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume
> Shadow Copy Files incorrectly decoded]
> http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ -
> ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack
> bug)
> https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ -
> [VDL Slack in NTFS – David G Ferguson]
>
> Gabriel
>
>
> On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...>
> wrote:
> > Did someone have time to look at the istat output? It is attached again.
> >
> > Thank you,
> > Luis
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>
|
|
From: Lloyd <llo...@gm...> - 2016-01-17 14:14:12
|
Further debugging issue I found that the data read from the disk is not
correct in the case of live disk.
I just commented the line 115 in raw.c ( "if (cimg->seek_pos != rel_offset
)" ) and in my first observation the code seems to be working. So i think
there is some issue in storing the seek position of live disks!
Thanks a lot,
Lloyd
On Sat, Jan 16, 2016 at 7:59 PM, Lloyd <llo...@gm...> wrote:
> HI,
>
> I ran my code in verbose mode and the output files (only differences and
> line numbers are in the file) are attached for your reference. After
> parsing sector 8512 ("fatfs_dent_parse_buf: Parsing sector 8512") there
> seems to have some difference between "raw_dump" and "live_disk". I would
> greatly appreciate any input or hints.
>
> Thanks a lot,
> Lloyd
>
> On Fri, Jan 15, 2016 at 10:01 AM, Lloyd <llo...@gm...> wrote:
>
>> Thanks Brian,
>>
>> Yes the drive is mounted. It is mounted at "F:", so I tried
>>
>> TSK_IMG_INFO *tsk_img = tsk_img_open_sing(_T("\\\\.\\F:"),
>> TSK_IMG_TYPE_RAW, 512);
>>
>> and it gives the correct result. Why could this ("\\?\usbstor#...") be
>> failing?
>>
>> Autopsy also correctly loads this as "local disk". Isn't autopsy also
>> using "\\?\usbstor" name to open the device? I tried to check the code
>> of autopsy, as I am not familiar with java, couldn't locate the calls to "
>> tsk_img_open".
>>
>> Any help, hint, tips would be greatly appreciated.
>>
>> Thanks,
>> Lloyd
>>
>>
>>
>> On Thu, Jan 14, 2016 at 10:11 PM, Brian Carrier <ca...@sl...>
>> wrote:
>>
>>> Is the drive mounted? What happens if you use something like \\.\G:?
>>>
>>> > On Jan 14, 2016, at 5:54 AM, Lloyd <llo...@gm...> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I am using libtsk (sleuthkit 4.2) to open and find files in a "live
>>> usb disk (4gb)". For that I have used tsk_img_open_sing with
>>> TSK_IMG_TYPE_RAW. The device name starts with "\\?\usbstor#..."
>>> >
>>> > The files listed in this are incomplete and wrong.
>>> >
>>> > So I took a raw image of the disk and again fed to tsk the same way,
>>> this time it shows the result correctly.
>>> >
>>> > Am I doing something wrong? When I checked the source of
>>> "tsk_img_open_sing " it shows that opening "winobj" is supported.
>>> >
>>> > Any guidance is greatly appreciated.
>>> >
>>> > Thanks,
>>> > Lloyd
>>> >
>>> ------------------------------------------------------------------------------
>>> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> > Monitor end-to-end web transactions and take corrective actions now
>>> > Troubleshoot faster and improve end-user experience. Signup Now!
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
>>> > sleuthkit-users mailing list
>>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> > http://www.sleuthkit.org
>>>
>>>
>>
>
|
|
From: Gabriel F. <gab...@gm...> - 2016-01-16 22:17:00
|
Hi, I'm having problems too with Volume Shadow files at the TSK (icat, istat), including TSK 4.2 (same behaviour indicated by Nassif). The problem with this type of file is caused by the attribute "initialized stream size" or "Valid Data Length size" (VDL size). Apparently, Microsoft has forced it's value to zero to make these files "invisible" to the normal Windows Backup process (https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/). I don't have much familiarity with the TSK code, but I wrote one possible solution to this problem, altering the "tsk/fs/ntfs.c" file, at the "ntfs_proc_attrseq" funtion, adding a test to set "initsize" to "ssize" when "initsize" it's equal to zero. But I don't know if this solution will cause problems with other types of files (like sparse or virtual files) in NTFS. I didn't find a way to limit this test only to the Volume Shadow Files, but it worked properly in my few test images. I'm sending the patch attached only to illustrate my message, because I think that other users or TSK developers could implement a better solution to this problem. Other references related to this problem: https://github.com/sleuthkit/sleuthkit/issues/466 - [Windows Volume Shadow Copy Files incorrectly decoded] http://sourceforge.net/p/sleuthkit/mailman/message/22341633/ - ([sleuthkit-developers] [ sleuthkit-Bugs-2367426 ] Fix NTFS VDL Slack bug) https://secureartisan.wordpress.com/2011/01/29/dc3-2011-day-2-and-3/ - [VDL Slack in NTFS – David G Ferguson] Gabriel On Wed, Jan 7, 2015 at 2:32 PM, Luís Filipe Nassif <lfc...@gm...> wrote: > Did someone have time to look at the istat output? It is attached again. > > Thank you, > Luis > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Lloyd <llo...@gm...> - 2016-01-16 14:29:45
|
HI,
I ran my code in verbose mode and the output files (only differences and
line numbers are in the file) are attached for your reference. After
parsing sector 8512 ("fatfs_dent_parse_buf: Parsing sector 8512") there
seems to have some difference between "raw_dump" and "live_disk". I would
greatly appreciate any input or hints.
Thanks a lot,
Lloyd
On Fri, Jan 15, 2016 at 10:01 AM, Lloyd <llo...@gm...> wrote:
> Thanks Brian,
>
> Yes the drive is mounted. It is mounted at "F:", so I tried
>
> TSK_IMG_INFO *tsk_img = tsk_img_open_sing(_T("\\\\.\\F:"),
> TSK_IMG_TYPE_RAW, 512);
>
> and it gives the correct result. Why could this ("\\?\usbstor#...") be
> failing?
>
> Autopsy also correctly loads this as "local disk". Isn't autopsy also
> using "\\?\usbstor" name to open the device? I tried to check the code of
> autopsy, as I am not familiar with java, couldn't locate the calls to "
> tsk_img_open".
>
> Any help, hint, tips would be greatly appreciated.
>
> Thanks,
> Lloyd
>
>
>
> On Thu, Jan 14, 2016 at 10:11 PM, Brian Carrier <ca...@sl...>
> wrote:
>
>> Is the drive mounted? What happens if you use something like \\.\G:?
>>
>> > On Jan 14, 2016, at 5:54 AM, Lloyd <llo...@gm...> wrote:
>> >
>> > Hi,
>> >
>> > I am using libtsk (sleuthkit 4.2) to open and find files in a "live usb
>> disk (4gb)". For that I have used tsk_img_open_sing with TSK_IMG_TYPE_RAW.
>> The device name starts with "\\?\usbstor#..."
>> >
>> > The files listed in this are incomplete and wrong.
>> >
>> > So I took a raw image of the disk and again fed to tsk the same way,
>> this time it shows the result correctly.
>> >
>> > Am I doing something wrong? When I checked the source of
>> "tsk_img_open_sing " it shows that opening "winobj" is supported.
>> >
>> > Any guidance is greatly appreciated.
>> >
>> > Thanks,
>> > Lloyd
>> >
>> ------------------------------------------------------------------------------
>> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> > Monitor end-to-end web transactions and take corrective actions now
>> > Troubleshoot faster and improve end-user experience. Signup Now!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
>> > sleuthkit-users mailing list
>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> > http://www.sleuthkit.org
>>
>>
>
|
38 messages has been excluded from this view by a project administrator.
