Thread: Re: [sleuthkit-users] ntfs.c.patch
Brought to you by:
carrier
From: Brian C. <ca...@at...> - 2003-02-18 17:52:27
|
> I use TASK&Autopsy to analyze NTFS. > NTFS disk image includes a Japanese file name. > However Autopsy cannot display Japanese file names. This is true (well, actually TASK has the issues with Unicode). I will begin by stating that I have extremely little knowledge about the details of Unicode beyond the ASCII subset of UTF-16. Which, is why that is the only part of Unicode for NTFS that has been implemented thus far. > > Mr.Takahashi wrote the patch which converted file > names into Unicode(UTF-8). > http://damedame.monyo.com/ntfs.c.patch > > Using the above patch, it is possible to display Japanese name. > Please check the following URL. > http://www.port139.co.jp/task/taskjptest.JPG > > However, it is not a complete patch. > If I use a long file name, Buffer over flow occurs. This is because the bounds on the 'asc' array are not being checked. You need to make sure that 'i' is less than 'alen'. Since it appears that you could have three bytes per character, then the size of the array should be increased in the functions that call uni2ascii and the check when 'l' is set should be modified. > I hope that TASK supports a Unicode option at the next version. I can't really do much in this area with out help and testing from non-english users since I don't have access to test images. And, this is the first request that I have gotten for it. What happens when you run this on the command line? Does the shell display the Japanese symbols? For example: fls -f ntfs img.dd thanks, brian --- ntfs.c.org Mon Jan 13 06:58:16 2003 +++ ntfs.c Sat Feb 15 21:42:12 2003 @@ -103,7 +103,7 @@ void uni2ascii(char *uni, int ulen, char *asc, int alen) { - int i, l; + int i, l, j; /* find the maximum that we can go @@ -115,15 +115,31 @@ else l = ulen; - for (i = 0; i < l; i++) { - /* If this value is NULL, then stop */ - if (uni[i*2] == 0 && uni[i*2 + 1] == 0) - break; + i = 0; j = 0; - if (isprint((int)uni[i*2])) - asc[i] = uni[i*2]; - else - asc[i] = '?'; + while (i < l) { + unsigned short *uni2p = (unsigned short *)uni; + /* If this value is NULL, then stop */ + if (uni2p[j] == 0) + break; + /* If this value is NULL, then stop */ + + if (uni2p[j] <= 0x7f) { + asc[i] = uni2p[j] & 0x007f; + i++; + } + else if (uni2p[j] <= 0x7ff) { + asc[i] = 0xc0 | ((uni2p[j] & 0x7c0) >> 6); + asc[i+1] = 0x80 | (uni2p[j] & 0x003f); + i = i + 2; + } + else if (uni2p[j] > 0x800) { + asc[i] = 0xe0 | ((uni2p[j] & 0xf000) >> 12); + asc[i+1] = 0x80 | (uni2p[j] & 0xfc0) >> 6; + asc[i+2] = 0x80 | (uni2p[j] & 0x003f); + i = i + 3; + } + j++; } /* NULL Terminate */ asc[i] = '\0'; |
From: Brian C. <ca...@at...> - 2003-02-24 17:18:43
|
> Why I did not create the complete patch is that I do not want to > distribute and maintainance another (Japanese local) version TASK > and hope that TASK natively support UTF-8. > Also that what character to use for UTF-8 option and how to keep this > option in TASK is a matter of coding policy. Takahashi, Please send me your patch that allows it to be turned off and on. I would rather provide a flag to the tools that would need UTF-8 (fls, ffind, and maybe others) instead of making it the default action (I haven't examined what that may screw up yet). What happens when you run 'fls -m' on an image and then import the data into mactime? Does mactime care that it is not ASCII? thanks, brian |
From: TAKAHASHI M. <mo...@ho...> - 2003-02-25 19:40:51
Attachments:
utf8.patch
|
Brian Carrier wrote: >Please send me your patch that allows it to be turned off and on. OK, the patch and simple description are available from http://www.monyo.com/technical/unix/TASK/utf8.patch http://www.monyo.com/technical/unix/TASK/README.txt And I attached it in this mail. I added -8 (Use UTF-8) option for fls and ffind. I have not enough time to examine if other tools need to modify or not. Please examine others > Hideaki :-) >What happens when you run 'fls -m' on an image and then import the data >into mactime? Does mactime care that it is not ASCII? Japanese filenames can be correctly displayed with UTF-8'ed fls. Although perl does not care Japanese, it does not modify anything in the file name string. ----- TAKAHASHI, Motonobu (monyo) mo...@ho... http://www.monyo.com/ |
From: Hideaki I. <hi...@po...> - 2003-02-26 23:18:03
|
Hi On Wed, 26 Feb 2003 04:37:39 +0900 TAKAHASHI Motonobu <mo...@ho...> wrote: >I added -8 (Use UTF-8) option for fls and ffind. >I have not enough time to examine if other tools need to modify or >not. Please examine others > Hideaki :-) I will test a patch. :-) # I'm sorry, I need a few days for a test. Best regards, -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: Hideaki I. <hi...@po...> - 2003-03-01 05:50:42
|
Hi On Wed, 26 Feb 2003 04:37:39 +0900 TAKAHASHI Motonobu <mo...@ho...> wrote: >I added -8 (Use UTF-8) option for fls and ffind. >I have not enough time to examine if other tools need to modify or >not. Please examine others > Hideaki :-) I tested utf8.patch. (http://www.port139.co.jp/task/ntfs.dd) fls and ffind displayed Japanese file names in Unicode correctly. However, icat and istat displayed error 'Segmentation fault'. [OK] ./fls -f ntfs -8 -l ntfs.dd [OK] ./fls -f ntfs -8 -l -D ntfs.dd [OK] ./fls -f ntfs -8 -l -p ntfs.dd [OK] ./fls -f ntfs -8 -l -p -r ntfs.dd [OK] ./fls -d -f ntfs -8 ntfs.dd [OK] ./fls -u -f ntfs -8 ntfs.dd [OK] ./fls -m /body -f ntfs -8 ntfs.dd [OK] ./ffind -f ntfs -8 -a ntfs.dd 34 [NG] ./istat -f ntfs ntfs.dd 34 Segmentation fault [NG] ./icat -f ntfs ntfs.dd 34 Segmentation fault Are there other commands that I must test? Please advise me. > all -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: TAKAHASHI M. <mo...@ho...> - 2003-03-01 12:26:11
|
Hideaki Ihara wrote: >I tested utf8.patch. >(http://www.port139.co.jp/task/ntfs.dd) >fls and ffind displayed Japanese file names in Unicode correctly. >However, icat and istat displayed error 'Segmentation fault'. OK, I created the refined one. Please examine again. The patch is available at http://www.monyo.com/technical/unix/TASK/utf8-3.patch In the prior version, the pointer for UCS-2 conversion function is NULL by default, so we need explicitly to initialise that on each command. Now the default is pointed to original uni2ascii() function. This makes the commands which need not to support UTF-8 (such as icat) are not required to modify its source. I added -8 option to fls, ffind and istat. ----- TAKAHASHI, Motonobu (monyo) mo...@ho... http://www.monyo.com/ |
From: Hideaki I. <hi...@po...> - 2003-03-02 01:57:47
|
Hi On Sat, 01 Mar 2003 21:22:53 +0900 TAKAHASHI Motonobu <mo...@ho...> wrote: >OK, I created the refined one. Please examine again. >http://www.monyo.com/technical/unix/TASK/utf8-3.patch Thank you for a new patch. I tested utf8-3.patch. utf8-3.patch is wonderful. :-) 1.[OK] ./fls -f ntfs -8 -l ntfs.dd 2.[OK] ./fls -f ntfs -8 -l -D ntfs.dd 3.[OK] ./fls -f ntfs -8 -l -p ntfs.dd 4.[OK] ./fls -f ntfs -8 -l -p -r ntfs.dd 5.[OK] ./fls -d -f ntfs -8 ntfs.dd 6.[OK] ./fls -u -f ntfs -8 ntfs.dd 7.[OK] ./fls -m /body -f ntfs -8 ntfs.dd 8.[OK] ./ffind -f ntfs -8 -a ntfs.dd 34 9.[OK] ./istat -f ntfs ntfs.dd 34 10.[OK] ./icat -f ntfs ntfs.dd 34 You can confirm a test result. http://www.port139.co.jp/task/test03/ Best regards, -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: Brian C. <ca...@at...> - 2003-03-04 14:27:15
|
>>OK, I created the refined one. Please examine again. >>http://www.monyo.com/technical/unix/TASK/utf8-3.patch > > Thank you for a new patch. > I tested utf8-3.patch. > utf8-3.patch is wonderful. :-) Great! I am swamped right now, but will work on incorporating this later. For scaling reasons, I'm more inclined to make a new flag that specifies ASCII or UTF-8 and just have fls and ffind set the flag and not have to deal with different function calls. It would be useful if you could make a small partition (10 MB or so that is wiped so it compresses nicely) with Japanese characters in it. Can you run one more test? Can you make a second data attribute with a Japanese name (aka alternate data stream)? echo "Test" > JAPANESE_NAME.txt echo "Hidden Test" > JAPANESE_NAME.txt:JAPANESE_NAME2 Then, do an 'istat' on the file and make sure that the attribute name appears. thanks a lot! brian |
From: Hideaki I. <hi...@po...> - 2003-03-10 01:05:54
|
Hi On Tue, 4 Mar 2003 09:24:10 -0500 Brian Carrier <ca...@at...> wrote: >It would be useful if you could make a small partition (10 MB or so >that is wiped so it compresses nicely) with Japanese characters in it. I made a NTFS image of eight mega size. http://www.port139.co.jp/task/ads02.dd It includes a Japanese character. In addition, it has 255 characters as length of a file name. Mr.Takahashi and I have tried to solve this problem in these days. http://www.securiteam.com/windowsntfocus/5QP08156AQ.html He made a new patch.(utf8-5.patch ) UTF-8 output patch for task-1.60 http://www.monyo.com/technical/unix/TASK/ >echo "Test" > JAPANESE_NAME.txt >echo "Hidden Test" > JAPANESE_NAME.txt:JAPANESE_NAME2 > >Then, do an 'istat' on the file and make sure that the attribute name >appears. ./istat -f ntfs -8 ads02.dd 30 It's OK. -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: Brian C. <ca...@ce...> - 2003-03-10 03:08:14
|
On Mon, Mar 10, 2003 at 10:06:11AM +0900, Hideaki Ihara wrote: > Brian Carrier <ca...@at...> wrote: > > >It would be useful if you could make a small partition (10 MB or so > >that is wiped so it compresses nicely) with Japanese characters in it. > > I made a NTFS image of eight mega size. > http://www.port139.co.jp/task/ads02.dd > > It includes a Japanese character. > In addition, it has 255 characters as length of a file name. Great, I'll check it out. > > Mr.Takahashi and I have tried to solve this problem in these days. > http://www.securiteam.com/windowsntfocus/5QP08156AQ.html Interesting. The only place that TASK would have a problem with this though is with 'ffind'. The path in 'ffind' is limited to 2048. If you were to browse via directories though (like in Autopsy) it should not matter. Is there another place that I am not thinking of? brian |
From: Hideaki I. <hi...@po...> - 2003-03-11 00:30:17
|
On Sun, 9 Mar 2003 22:07:54 -0500 Brian Carrier <ca...@ce...> wrote: >> Mr.Takahashi and I have tried to solve this problem in these days. >> http://www.securiteam.com/windowsntfocus/5QP08156AQ.html > >Interesting. The only place that TASK would have a problem with this >though is with 'ffind'. The path in 'ffind' is limited to 2048. If >you were to browse via directories though (like in Autopsy) it should >not matter. Is there another place that I am not thinking of? It is OK as long as I checked. (But I have not tested all functions.) I will let you know if I find another problem. -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: Eagle I. S. <in...@ea...> - 2003-03-11 02:40:17
|
I'm searching a drive for a keyword "Linda". It returns 143 hits, all listed like this:: 438592 (Hex - Ascii) offset 419 bytes However, some of these show data and some do not. Example I could have another hit that has a size of 419 bytes and when I click on the Ascii link, all I get is: Error identifying block size (dcat -s output) How can I see what's there? Also, is there a way to enter multiple keywords in the search box? TIA Niall. |
From: Brian C. <bca...@at...> - 2003-03-11 05:28:36
|
> I'm searching a drive for a keyword "Linda". > > It returns 143 hits, all listed like this:: > > 438592 (Hex - Ascii) > offset 419 bytes The 438592 is the data unit address that contains the keyword. You can also view this via the 'Data Unit' interface. The 419 means that the string is 419 bytes into the data unit. > However, some of these show data and some do not. > Example I could have another hit that has a size of 419 bytes > and when I click on the Ascii link, all I get is: > > Error identifying block size (dcat -s output) > > How can I see what's there? That is strange. Can you edit the 'autopsyfunc.pm' file and add the following: print "$dcat_out\n"; after line 8148: print "Error identifying block size (dcat -s output)\n"; So, you should have: print "Error identifying block size (dcat -s output)\n"; print "$dcat_out\n"; exit(1); Restart Autopsy and try the search again. What are you searching? Is it a live device or a dead image? What file system type? Is it just the unallocated space or all of the partition? Did you make a strings file? What happens when you enter the address from the Data Unit mode? Is the message in the top half, the bottom half, or both halves of the right-side of the screen? Does the link always generate the error, or just sometimes? Does it happen for both Ascii and Hex mode? thanks, brian |
From: Eagle I. S. <in...@ea...> - 2003-03-11 14:53:29
|
Brian, Sorry for not giving more details. I am searching a dead image, FAT32, WIN95, 6 Gigs. single partition. It's a wrongful death case and I'm searching for conversations between a daughter and her deceased father, about his doctor, named "Linda". >> Is it just the unallocated space or all of the >>partition? As far as I can tell, I'm searching the entire partition. The page is titled "Keyword search on images/hdb1 - which is the name of the image. I left the defaults with regard to Strings file etc. However, when I unchecked the MD5 options, in an effort to speed searching, I got the same error in the LHS frame : "Error identifying block size (dcat -s output)", and of course no results. No, I repeated the search for Linda, and got a different result but still a blank ascii data page. The message was : ASII Contents of Sector 1205162 (512 bytes) in images/hdb1 and that was all that was displayed. I clicked on the Hex tab and it displayed the data in that sector. When I clicked on the Ascii tab after that the ASCII characters were displayed. Could this be a browser problem? I'm using Konqueror 3.03 (using KDE 3.03) Another anomaly, I've found that clicking the Ascii link several times eventually (sometimes 2, sometimes 4 clicks) brings up the data. I have not edited the files you referred to as of yet. Regards, Niall. -----Original Message----- From: Brian Carrier [mailto:bca...@at...] Sent: Tuesday, March 11, 2003 12:27 AM To: Eagle Investigative Services Cc: sle...@li... Subject: Re: [sleuthkit-users] Question regarding keyword search > I'm searching a drive for a keyword "Linda". > > It returns 143 hits, all listed like this:: > > 438592 (Hex - Ascii) > offset 419 bytes The 438592 is the data unit address that contains the keyword. You can also view this via the 'Data Unit' interface. The 419 means that the string is 419 bytes into the data unit. > However, some of these show data and some do not. > Example I could have another hit that has a size of 419 bytes > and when I click on the Ascii link, all I get is: > > Error identifying block size (dcat -s output) > > How can I see what's there? That is strange. Can you edit the 'autopsyfunc.pm' file and add the following: print "$dcat_out\n"; after line 8148: print "Error identifying block size (dcat -s output)\n"; So, you should have: print "Error identifying block size (dcat -s output)\n"; print "$dcat_out\n"; exit(1); Restart Autopsy and try the search again. What are you searching? Is it a live device or a dead image? What file system type? Is it just the unallocated space or all of the partition? Did you make a strings file? What happens when you enter the address from the Data Unit mode? Is the message in the top half, the bottom half, or both halves of the right-side of the screen? Does the link always generate the error, or just sometimes? Does it happen for both Ascii and Hex mode? thanks, brian |
From: Brian C. <bca...@at...> - 2003-03-12 01:06:00
|
> >> Is it just the unallocated space or all of the > >>partition? > > As far as I can tell, I'm searching the entire partition. The page is > titled "Keyword search on images/hdb1 - which is the name of the > image. This is true. You can also just search the unallocated space by using the 'Extract Unallocated Space' button on the bottom. > I left the defaults with regard to Strings file etc. However, when I > unchecked > the MD5 options, in an effort to speed searching, The initial MD5 check value will have no impact on the speed of the process. The MD5 only takes longer when the image is initially imported. > I got the same error in > the > LHS frame : "Error identifying block size (dcat -s output)", and of course > no results. The error is on the left-hand side now? That is very strange, since it means that sometimes it works and sometimes it doesn't. The errors last night were on the right-hand side correct? > No, I repeated the search for Linda, and got a different result but still > a blank ascii data page. The message was : > > ASII Contents of Sector 1205162 (512 bytes) in images/hdb1 > > and that was all that was displayed. > > I clicked on the Hex tab and it displayed the data in that sector. > > When I clicked on the Ascii tab after that the ASCII characters were > displayed. > > Could this be a browser problem? I'm using Konqueror 3.03 (using KDE 3.03) The above sounds like a browser issue. I use Mozilla and it also sometimes does not display a page. But, it is rare. > I have not edited the files you referred to as of yet. That would be the most helpful. I can send you the file with the edits in it if you send me a copy of your autopsyfunc.pm (off line). thanks, brian |
From: Eagle I. S. <in...@ea...> - 2003-03-13 03:32:17
|
Hello group, Does anyone know how I could do the following from within Autopsy? I want to search for a certain name, say Foo, and then search only the results for another term - bar? How can this be done? Can it be done from the command line in TASK? if so can someone please walk me through it? Thank you Niall -----Original Message----- From: Brian Carrier [mailto:bca...@at...] Sent: Tuesday, March 11, 2003 12:27 AM To: Eagle Investigative Services Cc: sle...@li... Subject: Re: [sleuthkit-users] Question regarding keyword search > I'm searching a drive for a keyword "Linda". > > It returns 143 hits, all listed like this:: > > 438592 (Hex - Ascii) > offset 419 bytes The 438592 is the data unit address that contains the keyword. You can also view this via the 'Data Unit' interface. The 419 means that the string is 419 bytes into the data unit. > However, some of these show data and some do not. > Example I could have another hit that has a size of 419 bytes > and when I click on the Ascii link, all I get is: > > Error identifying block size (dcat -s output) > > How can I see what's there? That is strange. Can you edit the 'autopsyfunc.pm' file and add the following: print "$dcat_out\n"; after line 8148: print "Error identifying block size (dcat -s output)\n"; So, you should have: print "Error identifying block size (dcat -s output)\n"; print "$dcat_out\n"; exit(1); Restart Autopsy and try the search again. What are you searching? Is it a live device or a dead image? What file system type? Is it just the unallocated space or all of the partition? Did you make a strings file? What happens when you enter the address from the Data Unit mode? Is the message in the top half, the bottom half, or both halves of the right-side of the screen? Does the link always generate the error, or just sometimes? Does it happen for both Ascii and Hex mode? thanks, brian |
From: Brian C. <bca...@at...> - 2003-03-13 04:32:17
|
On Wed, Mar 12, 2003 at 10:27:03PM -0500, Eagle Investigative Services wrote: > Hello group, > > Does anyone know how I could do the following from within > Autopsy? > > I want to search for a certain name, say Foo, and then > search only the results for another term - bar? How can this be done? The short answer is probably no. You can try the regular expression of: "foo.*bar" The long answer is that it may not work as well as you would like because Autopsy does not search by file. it searches by logical units. It just does a grep on the image file and when the keyword is found, it goes up the tree to find out which inode/MFT allocated the unit and which file name points to the inode/MFT. Therefore it has no notion of ensuring that a file has both keywords in it. > Can it be done from the command line in TASK? if so > can someone please walk me through it? Your best bet would be to mount the image in loopback and run a grep script. I have no clue exactly what it would be though. It would look something like this for one keyword: # grep -H -d recurse "foo" * Good luck. brian |
From: Silent P. <sp...@si...> - 2003-03-15 21:51:37
|
Quoting: "Brian Carrier" > Your best bet would be to mount the image in loopback and run a grep > script. I have no clue exactly what it would be though. It would look > something like this for one keyword: Task/Autopsy have information regarding hidden / deleted files. When it works with images, does it undelete such files into the image so that they are available for manual searching if the image is mounted in loopback? Sid. |
From: Brian C. <bca...@at...> - 2003-03-17 04:16:11
|
On Sat, Mar 15, 2003 at 09:51:58PM -0000, Silent Partner wrote: > Quoting: "Brian Carrier" > > Your best bet would be to mount the image in loopback and run a grep > > script. I have no clue exactly what it would be though. It would look > > something like this for one keyword: > > Task/Autopsy have information regarding hidden / deleted files. When it works > with images, does it undelete such files into the image so that they are > available for manual searching if the image is mounted in loopback? No! That would be very bad since it would modify the image and any integrity checks would fail. TASK isn't an automated file recovery tool yet. It gives you all the information about where stuff is on the disk, but in general it requires manual recovery. brian |
From: Silent P. <sp...@si...> - 2003-03-27 23:22:21
|
Quoting: "Brian Carrier" Sent: Monday, March 17, > On Sat, Mar 15, 2003 at 09:51:58PM -0000, Silent Partner wrote: > > Quoting: "Brian Carrier" > > > Your best bet would be to mount the image in loopback and run a grep > > > script. I have no clue exactly what it would be though. It would look > > > something like this for one keyword: > > > > Task/Autopsy have information regarding hidden / deleted files. When it works > > with images, does it undelete such files into the image so that they are > > available for manual searching if the image is mounted in loopback? > > No! That would be very bad since it would modify the image and any > integrity checks would fail. TASK isn't an automated file recovery > tool yet. It gives you all the information about where stuff is on the > disk, but in general it requires manual recovery. > > brian Am revisiting this point..... more in light of your recent postings to the list saying that a new version of the tools are being cooked at present..... and apologies for not just trying this out myself, have had to wipe my linux partitions... Is it correct to say that in terms of a forensic analysis involving Task / Autopsy : (1) It performs limited searches on files, hidden or unhidden (2) Hyperlink to view the not-hidden files (3) No support to show the contents of the hidden files found in a basic search if discovered. (4) Suggest mounting a partition in loopback for extensive searches, but outside autopsy, but have no access to the hidden files that the Task/Autopsy tools finds in its basic searches. Also, in forensic analysis, a master image is obtained, checksummed and stored. You work from a copy of this. In this instance, shouldn't it be the case that task/autopsy undeletes hidden files into the image and re-checksums? or automatically creates a duplicate image of this nature in the locker? as long as the master is available to have the same process performed on it and can match the new checksummed image, then its fine. I agree that it is inherently "bad" to tamper with an image. But.... I also think its inherently bad for a forensic "evidence" gathering tool not to cater for hidden files. Don't crooks delete files with "interesting" info?? Any plans to extend the searching capabilities in the Autopsy interface? The timeline stuff is great, but so much of the evidence gathering process hinges on searching for info, and trying to discover evidence of info that was once on the disk that is intentionally concealed. Sid. |
From: Brian C. <ca...@ce...> - 2003-03-28 17:12:23
|
On Thu, Mar 27, 2003 at 11:23:05PM -0000, Silent Partner wrote: > Am revisiting this point..... more in light of your recent postings to the list > saying that a new version of the tools are being cooked at present..... and > apologies for not just trying this out myself, have had to wipe my linux > partitions... > > Is it correct to say that in terms of a forensic analysis involving Task / > Autopsy : > (1) It performs limited searches on files, hidden or unhidden > (2) Hyperlink to view the not-hidden files > (3) No support to show the contents of the hidden files found in a basic search > if discovered. > (4) Suggest mounting a partition in loopback for extensive searches, but outside > autopsy, but have no access to the hidden files that the Task/Autopsy tools > finds in its basic searches. How are you defining limited? Sure you can do more on the command line with grep and find, but I think the Autopsy options are fairly standard with other forensic tools. How are you defining hidden? Do you mean deleted? Autopsy and The Sleuth Kit currently make no attempts at "guessing" which data belongs to which files. They only follow pointers and values that are clearly defined. So, if a search hits a block that does not have a meta data structure that points to it, then you will not get any additional data. If all of the pointers exist for a deleted file, then its contents will be shown. > > Also, in forensic analysis, a master image is obtained, checksummed and stored. > You work from a copy of this. In this instance, shouldn't it be the case that > task/autopsy undeletes hidden files into the image and re-checksums? or > automatically creates a duplicate image of this nature in the locker? as long as > the master is available to have the same process performed on it and can match > the new checksummed image, then its fine. > > I agree that it is inherently "bad" to tamper with an image. But.... I also > think its inherently bad for a forensic "evidence" gathering tool not to cater > for hidden files. Don't crooks delete files with "interesting" info?? The future plan to integrate more advanced file recovery involves making a separate file that describes the relationships between data units and files. Then you can always say that the data was found from the original image. Otherwise, you have to show that when you rewrote the image that you did not overwrite evidence or add evidence etc. > Any plans to extend the searching capabilities in the Autopsy interface? What else are you looking for? I need to make a second searching option to search by file instead of image so that keywords across fragmented data units are found. brian |
From: Hideaki I. <hi...@po...> - 2003-02-19 10:43:13
|
Hi, On Tue, 18 Feb 2003 12:50:34 -0500 Brian Carrier <ca...@at...> wrote: > > I hope that TASK supports a Unicode option at the next version. > >I can't really do much in this area with out help and testing from >non-english users since I don't have access to test images. And, this >is the first request that I have gotten for it. What happens when you >run this on the command line? Does the shell display the Japanese >symbols? For example: > > fls -f ntfs img.dd Many thanks for your comment. There is a result of a command as below. #fls -f ntfs jp.dd r/r 34-128-1: ?,?jp.txt r/r 34-128-4: ?,?jp.txt:stream.txt r/- * 0: ?,?jp.txt http://www.port139.co.jp/task/jp.dd (Size:8M NTFS image) A shell cannot display Japanese character (Unicode). Therefore we have to use Autopsy and Web browser. A general browser supports Unicode(UTF-8). IE, Netscape,Opera... I asked Mr.Takahashi how to display Japanese using a Shell. But I could not get a good method from him. Then he wrote a patch of Unicode for me. I think it is difficult to display a Japanese file name of NTFS with TASK. However, I can read in a Web browser if output in UTF-8 or UTF-16 as a character code of a file name. And if we use UTF-8 or UTF-16 for output, I suppose not only Japanese but any other language can be displayed. I am not sure that whether other filing systems use Unicode. Best regards, -- Hideaki Ihara <hi...@po...> Port139 URL: http://www.port139.co.jp/ PGP PUBLIC KEY: http://www.port139.co.jp/pgp/ |
From: TAKAHASHI M. <mo...@ho...> - 2003-02-24 16:40:23
|
Hello I am the author of the ntfs.c.patch. >> Mr.Takahashi wrote the patch which converted file >> names into Unicode(UTF-8). >> http://damedame.monyo.com/ntfs.c.patch >> >> However, it is not a complete patch. >> If I use a long file name, Buffer over flow occurs. > >This is because the bounds on the 'asc' array are not being checked. Yes, I know this patch is incomplete and a quick hack is to extend the length of "char *asc" 3 times. Also it's easy to add an option which controls whether UTF-8 feature is enabled or not. I've done on my private version TASK. Why I did not create the complete patch is that I do not want to distribute and maintainance another (Japanese local) version TASK and hope that TASK natively support UTF-8. Also that what character to use for UTF-8 option and how to keep this option in TASK is a matter of coding policy. In Japan, we usually use Japanese filenames for business use and Windows Japanese version also creates Japanese file names as its default. So we strongly need to support Japanese filenames. >>What happens when you run this on the command line? Does the shell >>display the Japanese symbols? For example: >> >> fls -f ntfs img.dd > >http://www.port139.co.jp/task/jp.dd (Size:8M NTFS image) > >A shell cannot display Japanese character (Unicode). >Therefore we have to use Autopsy and Web browser. >A general browser supports Unicode(UTF-8). IE, Netscape,Opera... Indeed, as Hideaki said, we do not widely use UTF-8 as the encoding method for Japanese. Most 'Japanese shell' can treat the UTF-8 only as '8 bit data string' but can display only traditional Japanese encoding method such as EUC-JP and Shift_JIS. But using UTF-8 has several merits: - UTF-8 can support all characters (scripts) which NTFS supports. - Using UTF-8, the ASCII characters are not converted. - The code conversion is reversible between UTF-8 and UTF-16(UCS-2). In historical reason, the code conversion between Japanese traditional encoding method (also character set) and Unicode is not reversible and has severe complex problems. (for example there is no standard conversion table! / Unicode has much characters than Japanese traditional character set.) Correctly supporting such traditional Japanese character sets / encoding method requires lots of Japanese knowledge and codes. Using UTF-8, the code conversion can work automatically and there needs small codes for supporting UTF-8. And we have lots of code conversion tools for Japanese. Once task wrote the file names using UTF-8, we can easily convert them with such tools as we like. The important issue is that currently uni2ascii() function wastes the code information during code conversion, because this checks the even byte only and if the even byte is not printable, converts that byte to '?'. To use my UTF-8 patch, we can keep code informations completely and converts my favorite code later with other tools. ----- TAKAHASHI, Motonobu (monyo) mo...@ho... http://www.monyo.com/ |