Slashdot Mirror


Linux and Forensic Discovery

Max Pyziur writes "Found this on cryptome.org where Linux is cited in a DOJ document against Moussaoui (sometimes referred to as the "20th man"). FBI: Moussaoui E-mail Not Recoverable - January 1, 2003." An interesting read which gives some insight into how computer evidence is handled in court.

31 of 260 comments (clear)

  1. This is a great example... by craenor · · Score: 4, Informative

    Of the fact that lawyers will argue over anything.

    Heh, this seems to be a discussion about whether they used "approved methods" of retrieving a deleted email. According to one person, the LinuxGNU was the only one approved by NIST (national institute of standards and technologies). This of course, is wrong...NIST doesn't "approve" software, they just test it and declare whether or not it works.

  2. Secure File Deletion by b1ng0 · · Score: 5, Informative

    To anyone who is concerned about having their deleted files recovered, take a look at Wipe - in its strongest mode it will make 37 passes over the data in order to be sure that electron microscopes cannot reconstruct the bit patterns.

    1. Re:Secure File Deletion by Speare · · Score: 4, Informative

      It seems that journaling filesystems like ext3 cause hell for secure deletions, because changes aren't always committed as the application level assumes and requires. Has anyone suggested a kernel/filesystem hook to make secure media deletions possible?

      --
      [ .sig file not found ]
    2. Re:Secure File Deletion by Pathwalker · · Score: 3, Informative
      Or, for FreeBSD, you could just do rm -P.
      Overwrite regular files before deleting them. Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted.
    3. Re:Secure File Deletion by bloxnet · · Score: 5, Informative

      Wipe is a nice program, but it is simply overkill. It has been shown in studies that typically 3 passes of a data wiping program should make your data non-recoverable by standard means (using popular forensics tools such as EnCase, Maresware, NTI's batch of programs, or disk editors on whatever platform you are interested in). As to how much the U.S. government investigators are able to retrieve...well that falls into your urban legends category I suppose. For the most part, DoJ guildelines suggest wiping your data 7 times as part of the norm. This is because of the non precise manner in which hard drive read/write heads pass over the disk itself (more of a wobble rather than a perfect circular motion). I just recently saw a whitepaper on Encase's site that covered users of WinXP using EFS (encrypted filesystem) secure deletion (which just does 3 passes) that makes recovery of the files deleted not possible this is the whitepaper. Just as the above reference article concludes, it should be kept in mind that there is so many places to look on Windows and Unix machines other than what files were deleted. Perhaps pictures of your latest porn stash or the Word document covering your NDA violations are gone, but registry settings, file slack (as was mentioned in the parent article briefly), pagefiles, memory dumps, and many other locations that track your activities on a given machine can be used as well. Wow, I did not mean to get so long winded...I just really get into computer forensics. My personal advice for decent file security and deletion is encryption + multi-pass deletion. There are several encrypted filesystems out there for both Windows and *nix, and a few options that are viable with both (BestCrypt File system containers and also BCWipe for deletion is a good example). I don't see the need to start advertising products, so check out the options for OS level and OS independent solutions.

    4. Re:Secure File Deletion by Russ+Steffen · · Score: 3, Informative

      The hook is already there. The chattr can set a "secure delete" extented attribute on a file or directory which will make a subsequent normal rm perform a secure delete. However the man page says it's not implemented yet, but said man page hasn't been updated since kernel version 2.2.

  3. NIST Computer Forensics Tool Testing by metatruk · · Score: 5, Informative
    From the article:
    Before addressing the authentication for the four specific computers, an error in Mr. Allison's affidavit must be corrected. In his affidavit, Mr. Allison writes: "Many methods are available to create an exact duplicate; however, only one method - the GNU/Linux routine dd - has been approved by the National Institute of Standards and Technologies." Allison Affidavit at 3. This statement is simply wrong. The National Institute of Standards and Technologies (NIST) does not "approve" software, it merely tests it and then publishes the results of its tests.

    The test reults are abailable here:
    http://www.ojp.usdoj.gov/nij/sciencetech/cftt.htm
    1. Re:NIST Computer Forensics Tool Testing by metatruk · · Score: 2, Informative

      Or more specifically, here:
      http://www.ncjrs.org/pdffiles1/nij/196352.pdf

  4. Re:Oh Please! by The+Turd+Report · · Score: 3, Informative

    To be honest, 'dd' is not a Linux utility. Various *nixes used it before Linux was even started.

  5. Re:Why not a windows tool by zabieru · · Score: 2, Informative

    Actually, if you read on in the article, they state that Linux dd COULD have been used, that NIST had tested it and found it acceptable, but if you read the procedures used to the four HDDs, they actually used the other methods listed exclusively.

  6. Re:Why not a windows tool by grub · · Score: 3, Informative

    dd is a common Unix program. The SGIs at work have it, my various BSDs at home and work have it and Linux has it.

    --
    Trolling is a art,
  7. Re:Hotmail and Privacy in this article: by zabieru · · Score: 2, Informative

    You do realize that in the event of a search warrant or subpoena that privacy policy no longer applies, right? Of course, they can't turn over anything they no longer have, but if they have it the government will too. On a side note, the libraries in my city (seattle) have a very explicit privacy policy that states that they do not ever save information about books a patron has read and returned. The only things on the books are currently checked-out items, for exactly this reason.

  8. To make up for my fp by danielsmc · · Score: 1, Informative

    The United States respectfully responds to Standby Counsel's Reply to the Government's Response to the Court's Order on Computer and E-Mail Evidence (hereafter "Reply") as follows:

    Authentication

    The foundation of standby counsel's discovery requests regarding the computer and e-mail evidence rests upon their complaints regarding the "authentication" of the hard drives provided in discovery. "Authentication" in this context means the process of ensuring that the duplicate of the hard drive provided in discovery is an exact copy of what the FBI originally acquired. As FBI Supervisory Special Agent Dara Sewell explains in her attached affidavit, the FBI uses three different methods to duplicate or image a hard drive:1
    (1) GNU/Linux routine dd command via Red Hat Linux 7.1 (hereafter "Linux dd");

    (2) Safeback version 2.18 imaging software by New Technologies (hereafter "Safeback");

    (3) Solitaire Forensics Kit, SFK-000A hand-held disk duplicator by Logicube, Inc. (hereafter "Logicube").

    Sewell Affidavit at 2. Standby counsel seek the "complete authentication information for all of the hard drives produced in discovery, particularly the information for Mr. Moussaoui's laptop, the University of Oklahoma system, and Mukkarum Ali's laptop." Reply at 8.

    Before addressing the authentication for the four specific computers, an error in Mr. Allison's affidavit must be corrected. In his affidavit, Mr. Allison writes: "Many methods are available to create an exact duplicate; however, only one method - the GNU/Linux routine dd - has been approved by the National Institute of Standards and Technologies." Allison Affidavit at 3. This statement is simply wrong. The National Institute of Standards and Technologies (NIST) does not "approve" software, it merely tests it and then publishes the results of its tests. NIST did, indeed, test Linux dd and publish the results, which included some criticism. Sewell Affidavit at 3. Like Linux dd, Safeback has also been submitted to NIST for review and its final report was published on December 13, 2002. Sewell Affidavit at 3. NIST reported criticisms of Safeback comparable to those cited for GNU/Linux routine dd. Sewell Affidavit at 3-4.2 Thus, for purposes of NIST, both Linux dd and Safeback are accurate imaging tools. With this in mind, the authentication of the four computers at issue follows.3

    More important, the manufacturers of both Safeback and Logicube engaged in extensive self-testing of their programs before marketing them. Further, both contain verification programs\functions that ensure that the image\duplicate accurately reflects the data contained on the original. Sewell Affidavit at 4-5. Finally, FBI CART has validated the use of both Safeback and Logicube during their own use of the methods on hundreds of computers. Sewell affidavit at 4-5. Both Safeback and Logicube, like Linux dd, are methods that are accepted within the forensic computer community. Sewell Affidavit at 4-5.

    Additionally, Mr. Allison writes: "Further, once the duplicate has been created, a product such as the Message Digest version 5 (MD5) or the Secure Hash Algorithm version 1 (SHA-1) should be used to confirm that the duplication process has been done properly." Allison Affidavit at 3. Mr. Allison refers to programs that generate a unique value for both the data on the original hard drive and the data on a purported duplicate of that hard drive in order to further verify the results of the duplication process. However, as set forth in detail in SSA Sewell's affidavit, both Safeback and Logicube contain self-validating programs that ensure the image or copy process generates an exact duplicate of the original. Sewell Affidavit at 4-6. Therefore, the MD5 or SHA-1 programs only provide an additional layer of verification beyond the already proven reliability of the tool itself. Sewell Affidavit at 6.

    Both defendant's and Mukkarum Ali's laptops were duplicated using the Safeback software. To eliminate any questions about authentication, the FBI employed the MD5 program suggested by Mr. Allison on both laptops. The program demonstrated that the images of both laptops provided to the defense in discovery were accurate reproductions of the originals. Sewell Affidavit at 7-10. The significance of this point is two-fold. First, there can be no question that the defense has the exact same copy of the original that the Government has, so they can conduct any further investigation on their copy that they wish. Second, the results of the MD5 program as to these two laptops further demonstrate the reliability of the Safeback program.

    Finally, standby counsel seek the BIOS (Basic Input/Output System) settings for defendant's laptop based upon the following assertion by Mr. Allison in his affidavit:
    The complete authentication information for Mr. Moussaoui's laptop is even more critical given the indication in the above documents, particularly Bates no. M-LBR-0002265, that the laptop had lost all power by the time of the government's CART examination on August 6, 2002. [Footnote omitted]. The loss of all power means that the original date and time settings cannot be retrieved, and that other settings, such as how the computer performed its boot sequence, the types of ports and peripherals enabled, and the settings regarding the hard disk and the controller, are all lost as well. All of this is essential information on how the laptop was set up.

    Allison Declaration at 3-4. As SSA Sewell makes clear in her affidavit, however, the BIOS settings for defendant's laptop were recorded at the time that it was imaged, September 11, 2001, before any loss of power. The BIOS settings are set forth in SSA Sewell's affidavit. Sewell Affidavit at 11. Therefore, no authentication issues exist as to defendant's or Mukkarum Ali's laptops.4

    Unlike the laptops, the two hard drives at the University of Oklahoma (known as "PC 11" and "PC 14") were never removed from the university and are not currently in the Government's possession. Due to the nature of the hard drives, the FBI used the Logicube hand-held disk duplicator to copy the drives and then imaged the duplicates with the Safeback program. Logicube was selected to duplicate the University of Oklahoma hard drives because of its portability. Sewell Affidavit at 3-5, 18. Like Safeback, Logicube has been verified by both its manufacturer and the FBI. Moreover, Logicube performs self-checking functions to ensure that the duplicate drive accurately reflects the contents of the original drive. Finally, although Logicube has not yet been reviewed by the NIST, hand-held disk-duplicators such as Logicube are widely accepted in the information and forensic communities. Sewell Affidavit at 5. Consequently, there can be no challenge to the authenticity of the duplicates of the University of Oklahoma hard drives.

    The Request for a Chart for the Remaining Hard Drives

    Standby counsel next seek a chart "for the approximately 140 remaining hard drives. At a minimum, the chart should include the origin/source for each drive and the significance of the drive to the case." Reply at 9.5 On November 22, 2002, the Government supplied the defense with a chart listing each hard drive produced in discovery, when it was produced, and a detailed description of its source from which the defense can assess its significance. Further, in a letter dated December 18, 2002, the Government identified the computer evidence that it believes to be relevant for this prosecution. Of course, the burden rests with the defense to determine the significance of a piece of evidence to their defense. Cf. United States v. Comosona, 848 F.2d 1110, 1115 (10 th Cir. 1988) ("The Government has no obligation to disclose possible theories of the defense to a defendant. If a statement does not contain any expressly exculpatory material, the Government need not produce that statement to the defense. To hold otherwise would impose an insuperable burden on the Government to determine what facially non-exculpatory evidence might possibly be favorable to the accused by inferential reasoning."); United States v. Nachamie, 91 F. Supp. 2d 565, 569 (S.D.N.Y. 2000) ("The clear language of Rule 16(a)(1), however, does not require the Government to identify which documents fall in each category - it only requires the production of documents responsive to any category."); United States v. Greyling, 2002 WL 424655 at *3 (S.D.N.Y. 2002) ("Fed. R. Cr. P. 16(a)(1)(C) only requires that the Government afford defendants an opportunity to inspect the documents it intends to introduce at trial. It does not require the Government to identify which documents it intends to introduce.") (emphasis in original). Therefore, this request is now moot.

    The University of Oklahoma Hard Drive

    Standby counsel next request the Court to "[o]rder the Government to confirm that the UO hard drive produced in discovery has not been contaminated and explain why the 70 GB of unused storage space on that hard drive contains material that should not be there." Reply at 9. As the affidavit of SSA Sewell makes clear, the following answers Mr. Allison's concerns about University of Oklahoma PC 11. Approximately 9.537 gigabytes of information were duplicated from PC 11's hard drive by the Logicube program onto a 40 gigabyte drive. Thereafter, all data on the Logicube 40 gigabyte drive was imaged and later restored using the Safeback program onto a 80 gigabyte hard drive, which was then turned over to the defense. The primary partition which exists on the defense 80 gigabyte duplicate hard drive accurately represents the approximately 9.529 gigabytes captured from the primary partition of PC 11 without contamination. The balance of the space on the 80 gigabyte hard drive provided to the defense contains the following:
    (1) Approximately 7.26 megabytes of data of the 9.537 gigabytes of data captured from PC 11. This information actually appeared on PC 11 outside of the primary partition and was duplicated by Logicube. Therefore, this data previously existed on the PC 11 and did not result from the imaging/duplication process;

    (2) Unused space which consists of a series of zeroes; and,

    (3) Approximately 4 megabytes of repetition of the 9.537 gigabytes of information captured from PC 11, which was created by the Logicube tool when it first began to duplicate the material contained on PC 11.6

    Sewell Affidavit at 19-20. All of this simply means that the first 9.537 gigabytes of the 80 gigabyte hard drive provided to the defense accurately contains all of the data that existed on PC 11 at the time of duplication and was not "contaminated" by any outside data.

    The Examination of Moussaoui's Laptop

    Standby counsel's fourth request questions whether the defendant's laptop was imaged before it lost power. The defendant's laptop was imaged on September 11, 2001, before the laptop lost power. Sewell Affidavit at 11. The BIOS settings for the laptop requested by standby counsel are set forth in SSA Sewell's affidavit. Sewell Affidavit at 11. Therefore, this request is now moot.

    The xdesertman@hotmail Account and Other E-Mail Accounts

    In their fifth request, standby counsel ask the Court to "[o]rder the Government to examine all of the temporary files of the computers Mr. Moussaoui used (those at UO, his laptop, and Mukkarum Ali's laptop) and determine whether information can be obtained from them concerning the xdesertman@hotmail.com account and the other email accounts listed in paragraph 33 of the Lawler Affidavit." Reply at 10. SSA Sewell's affidavit describes the unsuccessful searches of each hard drive conducted by FBI CART Field Examiner Thomas Lawler for the xdesertman@hotmail.com e-mail account as well as at least 27 variations of this account and other e-mail accounts associated with the investigation of this case. Sewell Affidavit at 15. Moreover, as previously demonstrated in the first section of this pleading addressing the authentication issues, the defense now has an exact copy of what the Government has. Therefore, there is no reason that the defense, including their computer expert, cannot conduct the same examinations of the four hard drives at issue as the Government. Consequently, this request should be denied.

    Similarly, in their sixth request, standby counsel ask the Court to order the Government to conduct an investigation at their behest when they have the same ability to conduct the investigation. The defense possesses the same subpoena power as the Government and, if they wish to serve a subpoena on Hotmail, Microsoft, or any other company, they should do so. See Fed. R. Crim. P. 17(c); 18 U.S.C. 3005. Moreover, the Group Manager for Policy Enforcement for MSN Hotmail reports that a search as suggested by Mr. Allison in his Declaration (see Allison Declaration at 6) would have no success. Sewell Affidavit at 21-22. Therefore, this request should fail.

    The Internet Provider Address for University of Oklahoma PC 11 Computer

    Next, standby counsel ask the Court to "[o]rder the Government to (A) explain the reason for the discrepancy in IP addresses for the UO PC 11 computer, (B) confirm that the UO hard drive produced to the defense in discovery (129.15.110.31) comes from the computer used by Mr. Moussaoui at the University of Oklahoma, and (C) confirm that Mr. Moussaoui did not use any other UO computer." Reply at 11. Simply put, a typographical error exists in the Lawler Affidavit submitted by the Government. The correct internet provider address for University of Oklahoma PC 11 computer is 129.15.157.31. Sewell Affidavit at 18. As discussed in the first section of this pleading regarding authentication, a duplicate of the hard drive for PC 11 has been provided to the defense. As to whether Mr. Moussaoui used any other computer at the University of Oklahoma, only the defendant definitively knows the answer. The only evidence that the Government has regarding Mr. Moussaoui's computer use at the University of Oklahoma involves PC 11 and PC 14, copies of which have been provided to the defense in discovery.

    The Kinko's in Eagan, Minnesota

    In their eighth request, standby counsel seek "more information about the procedures used by Kinko's personnel and the steps they took to clean the Kinko's system and verify that no evidence of Mr. Moussaoui's communications via Kinko's internet access still remains on the Kinko's system." Reply at 11. SSA Sewell's affidavit describes in detail the procedures used by Kinko's to overwrite ("clean") their systems. The affidavit reveals that during the month between the defendant's use of the computers at Kinko's on August 12, 2001, and September 11, 2001, Kinko's cleaned their machines at least one time and perhaps many more, since their policy was to re-image (clean) the computers weekly. Sewell Affidavit at 12. Since September 11, 2001, the computers have been re-imaged several times and Kinko's personnel adamantly state that they are unable to recover any pre-existing data from a work station hard drive after the re-imaging process. Sewell Affidavit at 13. Further supporting the inability to locate references to xdesertman@hotmail.com is the fact that FBI CART examiners searched all data related to this e-mail account on both defendant's and Mukkarum Ali's laptops as well as the University of Oklahoma computers, none of which were ever "cleansed" or overwritten, and no data was found collaborating even the existence of any such account, or its use by the defendant. Sewell Affidavit at 15-17. Thus, there is no reason to believe that a search of the Kinko's computers in Eagan, Minnesota, would recover any relevant information about the defendant's e-mail use on these computers. Sewell Affidavit at 17.7

    The "File Slack" Portions of Mukkarum Ali's Laptop

    Standby counsel next ask "the Government to confirm that the 'file slack' portions of Mukkarum Ali's computer do not contain relevant information about Mr. Moussaoui's use of the computer to send e-mails." Reply at 11. As previously stated in the first section of this pleading addressing authentication, the defense has an identical duplicate of what the Government has; therefore, they can search Mukkarum Ali's computer as they wish. Moreover, FBI Cart Examiner Thomas Lawler thoroughly reviewed Mukkarum Ali's computer, including the "file slack" portions, and found no relevant information. Sewell Affidavit at 15. Therefore, this request should be denied.

    The "Ghosting" of the University of Oklahoma Computers

    Standby counsel conclude their requests by asking "the Government to identify the procedures employed by UO personnel to 'ghost' the computer(s) allegedly used by Mr. Moussaoui and order the Government, despite the fact that it may be 'likely lost' (see Lawler Affidavit at 28), to retrieve any forensic evidence showing use of those computers by Mr. Moussaoui and what he did while using those computers." Reply at 11. Calvin Weeks, the technical security officer for the University of Oklahoma, told the FBI that the University of Oklahoma used the commercial software Norton Ghost to restore a previously recorded hard drive image. Sewell Affidavit at 21. As to the second part of standby counsel's request, the defense has in their possession a duplicate of University of Oklahoma PC 11 and PC 14; therefore, they can perform any investigation of these hard drives that the Government can. Therefore, this request should be denied.

    Conclusion

    The attached affidavit by SSA Sewell fully addresses the issues raised by standby counsel and demonstrates beyond question that the FBI properly and exhaustively examined all computer evidence in this case.

    Respectfully Submitted,

    PAUL J. McNULTY
    UNITED STATES ATTORNEY

    By: /s/

    Robert A. Spencer
    Kenneth M. Karas
    David J. Novak
    Assistant United States Attorneys

  9. Re:Why not a windows tool by Anonymous Coward · · Score: 1, Informative

    wrong again.

    dd if=/dev/hdax of=/dev/hdbx

    And what could be easier than using a bootCD to use dd? No need to install anything on any computer. Hell, they can just hook up their drive to the suspects computer.

  10. Eraser is the best for windows by Anonymous Coward · · Score: 1, Informative

    shell integration
    uses Guttmann's method
    http://www.usenix.org/publications/library /proceed ings/sec96/full_papers/gutmann/
    can also do free disk space
    I think there is also a dos version you can use with a boot disk which would be better.

    Don't waste your time with other crap like bcwipe or the one that came with your system utility software.
    Besides running your disks through a grinder, this is the best deletion software available commerical or not. There are no "better" proprieatary software methods and anything you would pay for is a waste. Either use this set to Guttmann, or physcially destroy the disk.

    Realize that no software is 100%, especially if the agency wants your info back enough, but this software is the best if your not going to destroy your disk(again destroying is preferred).

    1. Re:Eraser is the best for windows by po8 · · Score: 3, Informative

      At the current state of the art, your best bet is to buy a new disk, and make sure that you never put any unencrypted bits on it: use a cryptographic filesystem such as CFS, and make sure your swap is encrypted also. As Gutmann notes, you may also want to take measures to make sure that sensitive data doesn't sit in RAM too long (!).

      Once data is in clear on disk, there's really no way to be sure it's gone except to physically destroy the platter.

  11. More info at Cryptome by Alien54 · · Score: 3, Informative
    Cryptome has, on it's front page, details on what the FBI is up against. Just scroll down a bit.
    • The Eagan, Minnesota Kinkos Computers

      19. The Initial September 2001 Inquiry at the Eagan, MN Kinkos: On October 17, 2002, I spoke with Minneapolis FBI Special Agent David Rapp. At that time, SA Rapp told me that, to the best of SA Rapps unrefreshed recollection, on or about September 19, 2001, SA Rapp went to the Kinkos store in Eagan, Minnesota, to inquire about a receipt found on the person of Zacarias Moussaoui at the time of his arrest. At that time, SA Rapp met with a person who represented himself as a Kinkos employee responsible for managing and maintaining customer computer workstations. At that time, the Kinkos employee informed SA Rapp, in substance, as follows:

      (A) The Kinkos receipt did indicate that a computer workstation had been utilized;

      (B) It could not be determined from the copy of the Moussaoui receipt alone which computer workstation was used;

      (C) In response to SA Rapps inquiry about the possibility of acquiring any information from the computer workstations regarding the use of the computers by Moussaoui, the Kinkos employee stated that, since the date of the receipt, all computers had been wiped clean/formatted and started with a fresh install; and,

      (D) The computer workstations were generally wiped weekly or bi-weekly approximately, even though Kinkos policy called for weekly wipings. At a minimum, the Eagan Kinkos store wiped the computers at least once per month.

      [....]

      21. Eagan Follow-up: On October 11, 2002, I requested that the Minneapolis FBI Field Office contact Kinkos personnel at the Eagan store and determine if, as alleged by the defense, the Kinkos computer could still maintain evidence of defendant Zacarias Moussaouis use from August 2001. On or about October 15, 2002, Special Agents Brendan Hansen and Christopher Lester visited the Eagan Kinkos and interviewed Brian Fay, who, as of August 11, 2001, was one of two Kinkos employees who knew how to restore an image onto the six computers with internet access designated for customer use. Mr. Fay stated that the six computers presently at the store are the same computers (with the same hard drives) that were present in August of 2001. These six computers are leased and scheduled to be replaced at the end of this year.

      The computers are maintained by formatting the computers hard drives and reloading an image using Norton Ghost whenever business is slow and time allows. There are no logs recording the dates or frequency of loading images on to the computers and Fay could not estimate how frequently they were imaged. Although Fay was not personally familiar with the exact details of the formatting and imaging process he administers to the computers, Fay had been advised by Kinkos that the formatting and restoration process destroyed all files associated with previous users.

    This would be rather thorough, it seems.

    ouch

    --
    "It is a greater offense to steal men's labor, than their clothes"
  12. Re:CRC/SHA-1/MD5 by metatruk · · Score: 5, Informative
    Are they saying that two different files can't have the same hash value? That's a load of crap! It's not hard at all to modify data to create any hash value that you want

    From http://www.itl.nist.gov/fipspubs/fip180-1.htm:

    The SHA-1 is called secure because it is computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages which produce the same message digest. Any change to a message in transit will, with very high probability, result in a different message digest, and the signature will fail to verify.
    So yes, two different files can have the same hash, but it's infeasible to do this. That's why hashing methods like SHA are used in cryptography; SHA-1 is used in DSA signatures.
  13. shred obsolescence by radon28 · · Score: 3, Informative

    the shred utility will only work on non-log structured and non-journaling filesystems, i.e. ext2, but not ext3, jfs, reiserfs, etc. see: "man 1 shred" for more info.

    1. Re:shred obsolescence by ahi · · Score: 3, Informative

      Nor will wipe, according to the author's page. In fact, no user-space utility can.

      --
      This is NOT an empty signature.
    2. Re:shred obsolescence by aardvarkjoe · · Score: 3, Informative

      If you're using ext3, you could always remount it as ext2 in order to run shred. Not practical to do it for each deletion, but if you only want to shred the occasional file, it's an option. (I don't know if there's a way to do something similar for other journaled filesystems.)

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
  14. Re:'dd' isn't _quite_ an image by wfmcwalter · · Score: 4, Informative
    Hey, there's something else - they're doing checksum calculation not on the disk image (/dev/hda) but on the partition image (/dev/hda1) - which means they're not entirely capturing everything that's potentially on the disk (in particular: the boot sector, the MBR, and any other partitions).

    Now, the document says the examiner determined that there was only one partition, and that he used a "a Linux Boot CD" - this implies (it's not terribly clear what that actually is) that he used linux's fdisk command (or diskdruid or something) to determine that there was indeed only one partition - by examining the current contents of the drive's partition table.

    Doing this doesn't capture any space not currently assigned to a partition - in particular, if another partition were present but was then deleted, or if the extant FAT32 partition were resized (say with partition magic).

    Infact it's rather unusual for a windows laptop to only have one FAT32 partition - many (most?) vendor-created laptops ship with a sleep-to-disk partition on the disk as well (Dell seems to always to this on windows systems).

    In a non-forensic setting, these gripes would be beyond pedantic, but given the seriousness of the crime concerned, and the alleged technical skill of the terrorist groups implicated, these omissions are not immaterial. I do hope that they're omissions only in this document and that the examiners actual procedure did properly image, checksum and examine _all_ of the disk's contents.

    --
    ## W.Finlay McWalter ## http://www.mcwalter.org ##
  15. Re:CRC/SHA-1/MD5 by bwt · · Score: 3, Informative

    Are they saying that two different files can't have the same hash value? That's a load of crap! It's not hard at all to modify data to create any hash value that you want, especially when you're including "deleted space" in the CRC calculations... It's good at telling you if there were any random modifications caused by errors during copying, but not that the files are identical.

    There are no known examples of two files that have the same MD5 (or SHA-1) hash values, so I think you should reevaluate your statement. While it certainly is true that such files do exist (2^128 MD5 values, > 2^128 possible files, pigeon-hole principle, etc...), that does not mean that finding them is computationally easy or even possible.

    A brute force search of files would require ~2^128 files to be search to find a match. If 2^32 computers each processed 2^16 files a second on average per year (60*60*24*365 20^30 seconds), then it would take greater than 2^50 years to find a match. Equivalently, the odds that any of the files that have ever been produced by humans have the same MD5 are pretty bad.

    It might be possbile that a cryptographic flaw in MD5 exists that could be exploited to reduce the number of files that needed to be searched. I believe no such flaw is known. If one does exist, I'm quite sure it doesn't provide dramatic benefits.

  16. Re:How is wipe overkill? by ion++ · · Score: 3, Informative

    someone already made that for you.

    The dude is in our local lug, http://www.sslug.dk/ and his name is Ole "perl" Tange.

    You can get the program here
    http://www.linux-kurser.dk/secure_harddisk_e raser. html

  17. Misconceptions about data forensics by MoralHazard · · Score: 5, Informative

    Call this off-topic if you must, but I've seen gazillions of posts in this and many other threads about forensics and data recovery that are terribly misinformed about the realities of the field. Here's the two cents of a real, live forensic examiner:

    First, it is NOT realistically possible to recover data that has been overwritten ONE time. Yes, yes--I've read all the white papers on magnetic force microscopy (MFM) and I understand that a theory exists about recovery of overwritten data. In practice, nobody actually does it. Maybe one time, six years ago, some dude at NASA or MIT actually made this work conditions on an older disk with a lower bit density, but anyone telling you that old patterns can be read in the real world is full of shit. And yes, it's been tried. Millions have been spent on this, and nobody can do it. Anybody selling you software that claims under laboratory to be "more secure" because it overwrites more than once is being silly. It's not even paranoia, just lacking a clue.

    That's why forensic examiners don't need to have the original media. In fact, one of the big tenets of the job is to never, ever, ever perform analysis on the originals. You make a bitstream copy of the perp's (excuse me, "client's") disk, and you work with that.

    Oh, and electron microscopes have nothing to do with this theorized recovery process. MFM is a related but very different technology.

    Second, Linux versus Windows versus LogicCube versus ImageMasster (another brand) is utterly beside the point. Forensic shops use what they find to be cost effective, fast, and convenient. The dd command is great, and all, and many examiners use it on Linux platforms for their disk imaging needs, but it's not an analytical tool.

    Let me put it this way: do you actually think that a forensic examiner sits down, opens /dev/hdX in vi, and starts paging through 5 GB or hex? Oh, god, no--that would take years. Making the bitstream image is the easy part, and your choices are virtually unlimited. For the actual analysis (what does it MEAN), you need something that can examine an allocation table, interpret the results, and display the contents in an easy-to-understand format. You need software that can quickly search across a drive for a particular keyword, regular expression, or file signature. You need something that can analyze data for randomness in order to re-assemble images that have been chunked out across virtual memory. Linux does NOT have basic utilities for all of this, and neither does Windows.

    Last, a good forensic examiner is less constrained by his/her knowledge of computers than by his/her investigative skills. I know more about operating systems, file allocation, and troubleshooting than any of the 30-50 year old former cops/feds/spooks that I work with, but they're capable of far more effective work than I am. Why? Because once you have a few basic computer operations taken care of, the work has as much to do with computers as Computer Science does.

    The folks that put the child pornographers, embezzlers, script kiddies, and the rest of the computer criminals in jail generally know much, much less than you about computers, Slashdotters. They also don't give a rat's ass about Linux, Windows, Bill Gates, RMS, or any of it.

    1. Re:Misconceptions about data forensics by Zeinfeld · · Score: 4, Informative
      Call this off-topic if you must, but I've seen gazillions of posts in this and many other threads about forensics and data recovery that are terribly misinformed about the realities of the field. Here's the two cents of a real, live forensic examiner:

      One reason why security software is overdesigned is that it has to deal with improvements in technology. To take your point about older low density drives, any drive more than five years old falls into that category.

      The other reason is that forensics rarely deals with information that is deliberately concealled and the fact that information that may become available in 10 or 20 years time is rarely relevant. This is not the case with intelligence where the activities of ten or even twenty years ago might be of major interest.

      The folks that put the child pornographers, embezzlers, script kiddies, and the rest of the computer criminals in jail generally know much, much less than you about computers, Slashdotters. They also don't give a rat's ass about Linux, Windows, Bill Gates, RMS, or any of it.

      Probably right there, but they are not the main customer for the technology we provide and even if they do buy it, it is not that likely to do them a major amount of good. The main customers for computer security are commercial interests, banks and major corporations. There are many documented instances of national security organizations being used for commercial espionage, the French openly boast about it. The people who commit major wire fraud are typically well funded and backed by significant organized crime, at the moment the Russian mafia are the main players.

      There arn't that many investigations into that type of crime because it is amazingly rare. But the level of attack is very sophisticated and very real.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  18. Re:'dd' isn't _quite_ an image by Anonymous Coward · · Score: 1, Informative

    It's rather unusual for a Windows laptop to have any FATxx partitions these days, thanks to NTFS. And nobody uses the old vendor-specific suspend-to-disk software any more; Windows will hibernate to a file named HIBERFIL.SYS in the root of your %SystemDrive%.

  19. Re:Uh, September 11? by sheldon · · Score: 3, Informative

    Ask your self: How the hell did they know to image his laptop on September 11th? This means they already knew he was part of the attack, and they were already on to him. Funny how we, the people, were never warned.

    Have you been living in a Cave for the past year?

    You've never heard of Moussaoui?

  20. Block size limitation in dd noted by Krellan · · Score: 3, Informative

    I read the NIST document and noticed they mentioned a limitation of dd.

    When copying, dd only copies entire blocks. If there is an incomplete block of information remaining at the end of the disk, for example, dd will not copy that last block at all.

    Since dd defaults to a block size of 1024 bytes, and PC hard drives use a sector size of 512 bytes, this could happen. In this case, dd will not copy the final sector of the hard disk, as it is an incomplete block.

    Because of a stupid decision made decades ago, traditional PC hard disk addressing uses 63 sectors per track, not 64. Therefore, odd total numbers of sectors are common. Modern addressing does away with CHS and just numbers all sectors from 0 to the end of the disk (many millions, in most cases). Still, because of the legacy of having 63 sectors per track, many disks have an odd total number of sectors.

    It would be nice if dd had an option to correctly copy a partial block at the end of the source. If there is an incomplete block, it should simply copy one byte at a time until there are no more bytes to copy.

    This would be easy to add to dd. Has it been done already? If so, it should be documented. Making it the default behaviour might break existing applications, so have it as an option that is highly recommended.

    1. Re:Block size limitation in dd noted by Anonymous Coward · · Score: 1, Informative

      > Since dd defaults to a block size of 1024 bytes,

      Historically, a block is 512 bytes, and that's certainly the case for my copy of dd (RH6.2):

      $ dd if=/dev/zero of=foo count=1
      1+0 records in
      1+0 records out
      [glynn@cerise glynn]$ ls -l foo
      -rw-r--r-- 1 glynn root 512 Jan 2 00:51 foo

      AFAIK, the "odd number of sectors" issue is due to the Linux block layer, not "dd"; the final sector simply isn't visible to user-space by any means.

  21. Am I stupid, or.... by BigBadBri · · Score: 2, Informative

    did I read in all the legal bullshit that all the FBI uses for verification is a CRC sum?

    It's easy to defeat CRC - just add empty space to the end of each file until you get the result you want. SHA-1 or MD-5 is safe(ish), but a straight CRC is too easy to forge.

    I wouddn't trust these disk copies with a bargegepole.

    --
    oh brave new world, that has such people in it!