sleuthkit-developers Mailing List for The Sleuth Kit (Page 38)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Brian C. <ca...@sl...> - 2004-07-16 20:29:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 16, 2004, at 3:29 PM, Kucenski, Matthew A. wrote: > "read block read error" What values are in the parentheses? That shows from where it was trying to read. brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA+DqyOK1gLsdFTIsRAnoUAJ9MoPLx8r2FrNX9vQN5saUE+J8rQACfb6GU mX3J9ae+xOjUB08vyUsx7VA= =Zr9T -----END PGP SIGNATURE----- |
|
From: Kucenski, M. A. <Mat...@di...> - 2004-07-16 20:24:25
|
"read block read error" FreeBSD 4.10 Using version 1.70 of sleuthkit that I complied from the sources. (not using the FreeBSD package) -Matt -----Original Message----- From: Brian Carrier [mailto:ca...@sl...] Sent: Friday, July 16, 2004 4:19 PM To: Kucenski, Matthew A. Cc: Sleuthkit Subject: Re: [sleuthkit-developers] Problems trying to extract slack using dls -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 16, 2004, at 2:59 PM, Kucenski, Matthew A. wrote: > I get the error "read block error (...): File too large (data block)" Was that the exact initial error or was it "read block lseek error" or "read block read error"? The "read block error" message should only occur if an error occurs on Solaris. It looks like your system doesn't like the large file and it can't read that far into the file. What version of FreeBSD do you have? brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA+Dg7OK1gLsdFTIsRArRYAJ0WPsTaqfQZ5UjsTmgBX4qfUCu2ugCfYqLt cNNmZVbYwLYisVHGEdz7PBk= =MT0l -----END PGP SIGNATURE----- |
|
From: Brian C. <ca...@sl...> - 2004-07-16 20:19:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 16, 2004, at 2:59 PM, Kucenski, Matthew A. wrote: > I get the error "read block error (...): File too large (data block)" Was that the exact initial error or was it "read block lseek error" or "read block read error"? The "read block error" message should only occur if an error occurs on Solaris. It looks like your system doesn't like the large file and it can't read that far into the file. What version of FreeBSD do you have? brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA+Dg7OK1gLsdFTIsRArRYAJ0WPsTaqfQZ5UjsTmgBX4qfUCu2ugCfYqLt cNNmZVbYwLYisVHGEdz7PBk= =MT0l -----END PGP SIGNATURE----- |
|
From: Kucenski, M. A. <Mat...@di...> - 2004-07-16 19:54:33
|
I get the error "read block error (...): File too large (data block)" Running on FreeBSD against a 60GB NTFS dd image. (dls -f ntfs -s image.dd > image.slack.dls) Anyone know if this is a known bug? Workaround? Fix on the way? Something wrong with my machine? Bueller...? Thanks, -Matt Matt Kucenski Defense Intelligence Agency Voice: (202) 231-1847 Pager: (877) 587-0126 |
|
From: <msh...@ag...> - 2004-06-09 11:26:03
|
Check out cdfs, or Agilerm.net and linux forensics article 1. M Shannon Agile Risk Management LLC -----Original Message----- From: sle...@li... Date: 6/8/04 11:07 pm To: sle...@li... Subj: sleuthkit-developers digest, Vol 1 #41 - 1 msg Send sleuthkit-developers mailing list submissions to sle...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers or, via email, send a message with subject or body 'help' to sle...@li... You can reach the person managing the list at sle...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of sleuthkit-developers digest..." Today's Topics: 1. CD-RW Recovery (M=E1rcio Carneiro) --__--__-- Message: 1 From: "M=E1rcio Carneiro" <ma...@di...> Date: Tue, 8 Jun 2004 11:16:03 -0300 To: sle...@li... Subject: [sleuthkit-developers] CD-RW Recovery Hello! Does anybody know if it's possible to recovey data of a CD-RW that was = rewritten (I suppose that there are data after the new track)? The software I know, just read the recorded track. I wonder if it's = possible to read the whole CD... M=E1rcio. --__--__-- _______________________________________________ sleuthkit-developers mailing list sle...@li... https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers End of sleuthkit-developers Digest |
|
From: Márcio C. <ma...@di...> - 2004-06-08 14:34:57
|
Hello! Does anybody know if it's possible to recovey data of a CD-RW that was rewritten (I suppose that there are data after the new track)? The software I know, just read the recorded track. I wonder if it's possible to read the whole CD... Márcio. |
|
From: <ben...@id...> - 2004-05-22 12:55:06
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Paul B. <ba...@fo...> - 2004-05-06 06:57:14
|
Michael, > While we are on the topic of searching, I was thinking=20 > about comments made=20 > previously on this list with regards to indexing=20 > (specifically the thread=20 > "[sleuthkit-developers] blindly indexing garbage..."). Rather=20 > than indexing=20 > every possible string in the image (which would take huge=20 > amounts of space=20 > for the index file - almost the same size of the image itself=20 > in some cases).=20 > Would it make more sense to have a dictionary of words to=20 > search for and then=20 > only index the offsets of these words in the image? You would=20 > get stuck if=20 > you wanted to search for a word not in the dictionary, but it=20 > might be useful=20 > for a standard initial search. For example, the english=20 > language dictionary=20 > on my linux box is about 85k words big. While I'm not convinced that this is wanted behaviour, I will think about adding this feature to the Searchtools.... One of the problems that you might encounter is that you cannot use a very large dictionary file... As one wants to load the entire dictionary file in memory in some tree like format... This takes precious memory.... Thus limiting the size of your dictionary.... But as said... I will look into this and probably integrate this functionality in either release 3 of release 4 of Searchtools.. Paul Bakker |
|
From: Michael C. <mic...@ne...> - 2004-05-05 11:46:25
|
Hi List, While we are on the topic of searching, I was thinking about comments made= =20 previously on this list with regards to indexing (specifically the thread=20 "[sleuthkit-developers] blindly indexing garbage..."). Rather than indexing= =20 every possible string in the image (which would take huge amounts of space= =20 for the index file - almost the same size of the image itself in some cases= ).=20 Would it make more sense to have a dictionary of words to search for and th= en=20 only index the offsets of these words in the image? You would get stuck if= =20 you wanted to search for a word not in the dictionary, but it might be usef= ul=20 for a standard initial search. For example, the english language dictionary= =20 on my linux box is about 85k words big. If all those were indexed, (because= =20 im never likely to search for an arbitrary random string only english words= ),=20 would this be more effective than indexing the whole thing? I imagine the=20 dictionary might also grow to contain non words too like hax0r or pr0n etc,= =20 or even might contain binary sequences of magic signatures etc. This technique is also a great alternative to the standard "strings" method= =20 (i.e. running strings over an image and grepping the result for hits),=20 because it will automatically not include the random printable strings that= =20 are garbage in most cases. Also there is no ambiguity with respect to what= =20 constitutes a valid string (e.g. 4 consecutive printable chars is ambigous = =2D=20 what chars are printable depends on the target language, unicode encoding=20 etc). If the dictionary contains the required words in a number of common=20 unicode encodings (binary sequences) it will automatically index. Michael. On Wed, 5 May 2004 03:02 am, M=E1rcio Carneiro wrote: > On Mon, 3 May 2004 13:19:06 -0700 (PDT), Linux Tard <lin...@ya...>= =20 escreveu: > > While not part of Sleuthkit you can use GLIMPSE. > > No, Glimpse only indexes text files. > > Lucene (http://jakarta.apache.org/lucene) seems to be a nice indexer, but > still doesn't indexes other types of files (but has a framework for one to > implement classes that understand other formats). > > :-/ > > M=E1rcio. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: please p. <ple...@ya...> - 2004-05-04 22:47:44
|
--- Brian Carrier <ca...@sl...> wrote: > yes it is. I will probably get to it this summer > during my cleanup and > expansion process. I just did an overhaul of FAT > this past weekend. > I guess it could be a new set of commands, the 'j' > commands. Then > there could be 'jls' that lists the entries in the > journal, 'jstat' > for details of an entry, and 'jcat' to get the data > from the entry. I agree with you. > Are you interested in working on it? Yes, I am. I have just studied journal in ext3 since last three weeks. I use e2fsprog (version 1.35) as reference. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Brian C. <ca...@sl...> - 2004-05-04 22:28:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2004, at 4:28 PM, please please wrote: > I would like to know if 'list contents of journal' is > still a to-do task. yes it is. I will probably get to it this summer during my cleanup and expansion process. I just did an overhaul of FAT this past weekend. > If so, what do you think it will be better: > * create a new command > * add as a flag e.g. '-j' in some already existing > command I guess it could be a new set of commands, the 'j' commands. Then there could be 'jls' that lists the entries in the journal, 'jstat' for details of an entry, and 'jcat' to get the data from the entry. Are you interested in working on it? brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAmBjvOK1gLsdFTIsRAt04AJ4wMS8+o+WBAnZt7Y0b8y4cVbHa3gCfbYRf NoN6RHoOQqmmu1uDaVC/X8Q= =+Vwt -----END PGP SIGNATURE----- |
|
From: please p. <ple...@ya...> - 2004-05-04 21:29:21
|
Hi, I would like to know if 'list contents of journal' is still a to-do task. If so, what do you think it will be better: * create a new command * add as a flag e.g. '-j' in some already existing command Let me know your suggestions. Regards. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Márcio C. <ma...@di...> - 2004-05-04 17:04:44
|
On Mon, 3 May 2004 13:19:06 -0700 (PDT), Linux Tard <lin...@ya...> escreveu: > > While not part of Sleuthkit you can use GLIMPSE. > No, Glimpse only indexes text files. Lucene (http://jakarta.apache.org/lucene) seems to be a nice indexer, but still doesn't indexes other types of files (but has a framework for one to implement classes that understand other formats). :-/ Márcio. |
|
From: Linux T. <lin...@ya...> - 2004-05-03 20:19:43
|
While not part of Sleuthkit you can use GLIMPSE. -happy! lt --- Brian Carrier <ca...@sl...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On May 3, 2004, at 1:43 PM, MXrcio Carneiro wrote: > > > Are there any option to do the index of a image > (or mounted file > > system), like dtSearch does? I know that there are > plans to Sleuth do > > that, but I think there is no code, yet. Am I > right? > > Paul Bakker is working on something like that. > There is a list of > "Add-on" projects on the download page of > sleuthkit.org. > > http://www.sleuthkit.org/sleuthkit/download.php > > brian > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFAlqaVOK1gLsdFTIsRAnI9AJ9LDN1OgLW+MUoJDletJQU0mjQ7vACfZ9DR > LY6/J0OadQOEL0CMomPvgHo= > =Z611 > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the > market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the > exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Brian C. <ca...@sl...> - 2004-05-03 20:08:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2004, at 1:43 PM, MXrcio Carneiro wrote: > Are there any option to do the index of a image (or mounted file > system), like dtSearch does? I know that there are plans to Sleuth do > that, but I think there is no code, yet. Am I right? Paul Bakker is working on something like that. There is a list of "Add-on" projects on the download page of sleuthkit.org. http://www.sleuthkit.org/sleuthkit/download.php brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAlqaVOK1gLsdFTIsRAnI9AJ9LDN1OgLW+MUoJDletJQU0mjQ7vACfZ9DR LY6/J0OadQOEL0CMomPvgHo= =Z611 -----END PGP SIGNATURE----- |
|
From: Márcio C. <ma...@di...> - 2004-05-03 18:47:55
|
Hi! Are there any option to do the index of a image (or mounted file system), like dtSearch does? I know that there are plans to Sleuth do that, but I think there is no code, yet. Am I right? Thanks, Márcio. |
|
From: Brian C. <ca...@sl...> - 2004-04-11 22:05:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition to Michael's comments, HTML is slow when dealing with large directories (such as /dev/ on many Linux systems) because Autopsy makes a big table with thousands of entries and many browsers were not designed for that. With HTML you can't stop intensive processes, such as keyword searching. You can't right click on something to get a menu listing etc. There also aren't any menus for each mode. Some of this could be fixed with javascript, but I'm too paranoid about having java script enabled while viewing suspect systems. brian On Apr 11, 2004, at 7:41 AM, Michael Cohen wrote: > On Sun, 11 Apr 2004 02:53 pm, t f wrote: > Hi dorkus, > >> I noticed that, on your projects page, you specify a "non-HTML" >> GUI...Is >> Autopsy slow? It seems that a well-designed web page (PHP) >> presenting data >> from a well-designed database would be the ideal solution. Apache, >> MySQL, >> and PHP seem to run on just about everything these days...This >> approach >> would make logging and metrics much cleaner, too. > > Sometimes its not a matter of having the gui too slow, some guis are > more > appropriate than others for certain tasks. For example pyflag uses > mysql/python html gui which is fine for many things. However, we are > currently thinking about implementing a gtk gui for it in order to > experiment > with some gui elements that are not possible to do in html (e.g. live > progress bars etc). Also we currently have a command shell for pyflag > called > flash ( the flag shell)... this is used for scripting analysis - so we > do a > long nsrl comparison, and extract images/word document after loading > the case > in automatically in about 5 lines of flash script. > > This way all the time consuming tasks are done overnight, > automatically, and > we just examine the results. This is an example of a cli being better > than > html for this task. > > Michael. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAecEkOK1gLsdFTIsRAg16AJ0d8azwPUtS5GECDsBHp2bjWTOJbwCfdu6P gUbeoiegzM6JeS7PEgY9+LU= =fyNO -----END PGP SIGNATURE----- |
|
From: Michael C. <mic...@ne...> - 2004-04-11 12:40:16
|
On Sun, 11 Apr 2004 02:53 pm, t f wrote: Hi dorkus, > I noticed that, on your projects page, you specify a "non-HTML" GUI...Is > Autopsy slow? It seems that a well-designed web page (PHP) presenting data > from a well-designed database would be the ideal solution. Apache, MySQL, > and PHP seem to run on just about everything these days...This approach > would make logging and metrics much cleaner, too. Sometimes its not a matter of having the gui too slow, some guis are more appropriate than others for certain tasks. For example pyflag uses mysql/python html gui which is fine for many things. However, we are currently thinking about implementing a gtk gui for it in order to experiment with some gui elements that are not possible to do in html (e.g. live progress bars etc). Also we currently have a command shell for pyflag called flash ( the flag shell)... this is used for scripting analysis - so we do a long nsrl comparison, and extract images/word document after loading the case in automatically in about 5 lines of flash script. This way all the time consuming tasks are done overnight, automatically, and we just examine the results. This is an example of a cli being better than html for this task. Michael. |
|
From: t f <dor...@ho...> - 2004-04-11 04:53:35
|
Brian, Your points are well taken. You want to do the right thing and keep the temple pure. Good for you. Excellent! Glad to hear that the IO Subsys will be included, and that you're looking at UTF8. Is there a roadmap/strawman available for v2? I noticed that, on your projects page, you specify a "non-HTML" GUI...Is Autopsy slow? It seems that a well-designed web page (PHP) presenting data from a well-designed database would be the ideal solution. Apache, MySQL, and PHP seem to run on just about everything these days...This approach would make logging and metrics much cleaner, too. If only I had some spare time... -dorkus _________________________________________________________________ Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/ |
|
From: Brian C. <ca...@ce...> - 2004-04-10 18:13:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 1) what's the status of integrating utf8 support for both FAT and > NTFS filesystems? > > 2) what's the status of the io subsystem patch? that sounded very > promising, but i haven't seen much chatter about it in the past few > weeks on the list. Both of these are targeted to be added to v2. v2 will include a cleanup of some of the flags and output and new features. I'm still not sure if the full impact of adding UTF8 into the code, so I need to fully examine that before I just remove the filters. > (This last one is more a request for the group to ponder...I really do > want to hear something back, so don't ponder indefinitely.) > > 3) don't you suppose it's better to offer OS-specific (LKM-based) > filesystem access as a stop-gap measure than to leave the capability > out completely? The code seems to be structured in a fairly modular > way to allow you to "drop in" fileystem drivers...Why not give folks > the option of pointing your code at the existing (be they OSX and/or > *nix) hfs+ and ufs2 drivers?? It gives them more flexibility, and > allows them to use sleuthkit for those cases NOW, while you coordinate > coding of your own cross-platform drivers. It is a good idea, but there are several reasons why it probably won't happen. - - It would be a lot of work to integrate them in because the design of TSK is different than what is given from file system LKMs. I would rather spend the time working on more long-term things (which is currently the problem with adding new features). - - It wouldn't really give you much. From the little that I have looked into it, the only features that would be useful for the forensics part is the ability to list allocated file names. I don't think you would be able to map a cluster to an inode to a file, see deleted file names, or extract unallocated blocks etc. So, you get the same functionality as mounting the image in loopback. It would be really clumsy in Autopsy because so many of the features would have to be disabled. - - I don't really feel comfortable having output from "The Sleuth Kit" from code that I didn't package with it. While it maybe more convenient and faster to deploy new support, I'm not sure if it is good for forensic tools and knowing where the code came from. I would rather take the module code and work it into libraries or some other code like existing TSK files where everyone who uses a given version of TSK is using the same code and it does not depend on what platform and patch version you have on your local system. > IMO, folks will not shy away from a case because sleuthkit doesn't > support the filesystem...They'll just use something else. I > understand that you're not directly profiting from use of your product > to conduct examinations, but there is definitely a lot of potential > here... Maybe, but I am more interested in finding more people who are willing to help develop code to do it the right way (or develop a better GUI) instead of focusing on short-term patches. brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAeDk8kllA35nbwSURAuRSAJ0fPK004f0WcNA2sXdu1bFm7crhZwCfVfwA 2OtMexpcQFX1/oIGWmWutQ4= =7wl3 -----END PGP SIGNATURE----- |
|
From: Michael C. <mic...@ne...> - 2004-04-10 10:01:18
|
Hi Dorkus, > 2) what's the status of the io subsystem patch? that sounded very > promising, but i haven't seen much chatter about it in the past few weeks > on the list. The IO subsystems patch is pretty complete at this point and is used heavily in flag: http://pyflag.sourceforge.net/. I currently support encase evidence files as well as a new compressed format called sgzip. (as well as split dd images, or images of the entire disk). I have only converted the tools I needed to use it namely dcat,fls,icat, istat and dbtools (david collett's SQL tool). I never got around to do the rest of the tools in fstools, i dont normally use any other tools, but it would be nice to complete them all. > 3) don't you suppose it's better to offer OS-specific (LKM-based) > filesystem access as a stop-gap measure than to leave the capability out > completely? The code seems to be structured in a fairly modular way to > allow you to "drop in" fileystem drivers...Why not give folks the option of > pointing your code at the existing (be they OSX and/or *nix) hfs+ and ufs2 > drivers?? It gives them more flexibility, and allows them to use sleuthkit > for those cases NOW, while you coordinate coding of your own cross-platform > drivers. This is an excellent idea - I previously had a look at it though and it seemed that the LKM approach is quite complex. Obviously the kernel modules are far more functional than anything we need in sk, i.e. they allow to write new data, or create new data etc. There are two ways i can think of making this work: 1) dynamic linking directly into the lkm module - this is a neat solution but it sounds very complex to me - i guess we need to create a kernel driver like interface (like the loopback driver), and allow the module to call it. (We need to create an environment which is familiar enough to the lkm to require emulating large chunks of the kernel), also we need to write specific filesystem wrapping stubs to link between the sk concept of a "driver" and the lkm. Im no kernel hacker and my assesment is that this method is far too complex? 2) Create a new psuedo sk filesystem driver, which rather than do its own reading of a dd image, simply does ioctls on the mounted filesystem files etc. Pros of this method is that it should be very simple to implement, Cons are that it only operates on a mounted filesystem, so users need to be root to mount the image, also iosubsystems wont work because you cant get the kernel to read an encase file for example (hmm i just has an idea - maybe iosubsystems can include a custom loop device which will allow kernel mounting of all image files like encase, sgzip etc - something to think about). > IMO, folks will not shy away from a case because sleuthkit doesn't support > the filesystem...They'll just use something else. I understand that you're > not directly profiting from use of your product to conduct examinations, > but there is definitely a lot of potential here... That is something i have been thinking or lately. I needed to use iso9660 once for example, and missed not having that in sk. Of course i could always mount it and look at the image by other means, but I could not use flag or autopsy which was mildly annoying. Michael. |
|
From: t f <dor...@ho...> - 2004-04-09 13:22:58
|
hello, brian. first, i wish to commend you on your excellent work with the sleuthkit. i have a few questions: 1) what's the status of integrating utf8 support for both FAT and NTFS filesystems? 2) what's the status of the io subsystem patch? that sounded very promising, but i haven't seen much chatter about it in the past few weeks on the list. (This last one is more a request for the group to ponder...I really do want to hear something back, so don't ponder indefinitely.) 3) don't you suppose it's better to offer OS-specific (LKM-based) filesystem access as a stop-gap measure than to leave the capability out completely? The code seems to be structured in a fairly modular way to allow you to "drop in" fileystem drivers...Why not give folks the option of pointing your code at the existing (be they OSX and/or *nix) hfs+ and ufs2 drivers?? It gives them more flexibility, and allows them to use sleuthkit for those cases NOW, while you coordinate coding of your own cross-platform drivers. IMO, folks will not shy away from a case because sleuthkit doesn't support the filesystem...They'll just use something else. I understand that you're not directly profiting from use of your product to conduct examinations, but there is definitely a lot of potential here... thanks for hearing me out. -dorkus _________________________________________________________________ Check out MSN PC Safety & Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp |
|
From: Matthew M. S. <msh...@ag...> - 2004-04-06 11:40:31
|
> Hi EP > > > Slightly OT, but is this a bad idea to use the Linux > > kernel to access > > these other file systems? > > > why is this? > > kind regards, > > -lt > lt- I would guess it's because of the lack of cross-platform portability. Brian is a OSX user, and I'm sure there are even a few Sun users as well. In addition, I would guess that tying your application to linux kernel code might make for a more difficult upgrade path. For instance, does SMART run under the 2.6.x kernel? These are just suggestions, Brian can most likely answer this better than I. Warmest Regards, -- Matthew M. Shannon, CISSP Principal Agile Risk Management LLC www.agilerm.net msh...@ag... (o)813.676.5197 |
|
From: Linux T. <lin...@ya...> - 2004-04-05 20:14:48
|
Hi EP > Slightly OT, but is this a bad idea to use the Linux > kernel to access > these other file systems? why is this? kind regards, -lt __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
|
From: Epsilon <ep...@ya...> - 2004-04-05 13:41:12
|
Brian Carrier wrote: >> SMART "understands" many file systems, including VFAT, NTFS, ext2, >> ext3, Reiser, HFS, HFS+, XFS, JFS, ISO9660, BeFS and many more. > > SMART uses a combination of the local Linux kernel file system support > and custom code. It mounts images in loopback using the standard Linux > file systems and then has custom modules for the deleted files and > such. Slightly OT, but is this a bad idea to use the Linux kernel to access these other file systems? Ep __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
1 message has been excluded from this view by a project administrator.
