Slashdot Mirror
Domain: forensicswiki.org
Stories and comments across the archive that link to forensicswiki.org.
Comments · 22
-
Re:Slightly off-topic: I want "WORM SSDs" for back
Most people that care about "forensic purposes" purchase a device called a "hardware write blocker".
-
Re:So forgetting a password
I think you're describing something akin to a steganographic partition. According to Wikipedia "FreeOTFE and TrueCrypt allow a second encrypted file system to be hidden within another encrypted file system. The goal of this filesystem-within-a-filesystem is to allow the users to have a “decoy” file system with data that is interesting but not overtly sensitive. A person who is arrested or captured with a laptop encrypted using this software could then give up the first file system’s password, with the hope that the decoy would be sufficient to satisfy the person’s interrogators." It's not precisely what you're describing, but close.
-
Re:What the gzip spec says about MTIME
Vote parent up.
The article the summary references is just a summary of this: http://jcarlosnorte.com/securi...
In which, he notes:
Offset Size Value Description
0 2 0x1f 0x8b Magic number to idenitfy gzip streams
2 1 Compression method
3 1 Flags
4 4 Compression Date
8 1 Compression flags
9 1 Operating systemHe references that as coming from: http://www.forensicswiki.org/w...
But that document does not say "Compression Date". It actually says:4 4 Last modification time. Contains a POSIX timestamp.
Even his proof of concept shows that he's parsing that field as a POSIX timestamp: https://github.com/jcarlosn/gz...
echo date('l jS \of F Y h:i:s A', $rdate);
It appears that either:
a) Something else in his php script is setting the TZ before doing that parse
b) The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause. -
Email blockchains
FWIW, this paper on Bitcoin-like email blockchains appears to really be TFA: http://web.media.mit.edu/~guyz...
I think if providers just held on to "Message IDs" (e.g., http://forensicswiki.org/wiki/...) they'd have most of this capability today. I'm not sure what blockchains bring to the table here other than authenticity, and that doesn't seem to be the issue here.
-
DCO and HPA (Host Protected Area of Hard Disk Driv
-
DCO and HPA (Host Protected Area of Hard Disk Driv
DCO and HPA (Host Protected Area of Hard Disk Drives)
---DCO and HPA (Host Protected Area of HDDs)---------
http://en.wikipedia.org/wiki/H...
http://www.forensicswiki.org/w...
http://hddguru.com/software/20...
http://hddguru.com/software/20...
http://hddguru.com/software/20...
http://www.itsecure.at/hparemo...
http://www.sleuthkit.org/infor... -
DCO and HPA (Host Protected Area of HDDs
-
extracting keys from RAMThis tool extracts the keys from RAM dumps. There are free tools that do this too, of course.
But isn't it difficult to get a RAM dump, you say? Not really:
- Hibernating a computer writes this data to disk. Starting in Windows 8, "shutdown" actually writes some hibernate data by default.
- VMs also have their own suspend functionality that does a RAM dump, as well as non-SAN VM migration.
- Firewire ports actually allow devices to scan RAM of the machine they're connected to.
- Obviously, if you have access to a live machine, you can get the keys directly from RAM.
-
Epoch Fail
Eschatology is simply a matter of your particular brand of religion.
Every Unix user knows the world doesn't end until January 18th or 19th, 2038.
Mac users know the world doesn't end until February 6, 2040, at 6:25:15 a.m.
Windows users know that the world ended at the dawn of the Ballmerzoic Epoch in January 2000.
(I couldn't remember when the Ballmer Epoch began, so I asked Google and somehow got "Did you mean: when did batman take over Microsoft?") -
DC Experiences
I work in a datacenter with large numbers of un-raided servers. Generally when someone wants to fix a drive, they just want their data off. Corrupted Filesystems due to Physical Problems: Corrupted filesystems are frequently due to bad blocks in the filesystem metadata. The fs metadata tends to go first because its the most read part of the disk. I've had really good luck with ddrescue for this sort of error (at least for ext3). Have ddrescue skip error blocks and keep a log of bad blocks, otherwise it'll literally take a week to recover. (Instructions: http://www.forensicswiki.org/wiki/Ddrescue) Fried Drive Controllers: These will generally completely fail to turn on or read at all. They're usually not detected as disks. Replacing the PCB would probably work if I were any good at hacking type soldering. If you're tempted to try sticking a drive in the freezer, just let it sit for 1-4 months instead. I believe it's effectively the same fix but with far lower of a chance of borking the electronics due to mosture. Believe it or not a fair number of drives will come back to live after this period of time (~15-20% I would *guess*). Mainly you should just be aware of the warning signs. Disappearing files, folders that cause crashes, ext3 related stack traces, and filesystems being auto-remounted as read-only are all signs that its about time the evacuate to a new disk within a day, two at the max. Bad ball bearings generally don't kill hard drives. Disks making weird unlubricated drive bearing/shaft sounds can still work for a year or so. If this disk seems to shutter or obviously has problems starting to spin you should definetely copy your data to a new disk, anything less will mainly just injure people's hearing. The main problem with bad bearing is that it *really* increases the amount of heat in the computer (which in turn can kill hard drives).
-
The FBI would like ALL SSD drives banned
SSD's are forensically very much harder to deal with. When the computer user erases such a drive, the control data is re-zeroed and the wear leveling controller in the drive starts rearranging data among the various memory chips as soon as the drive is powered up, whether in a computer or otherwise. For this reason forensic data on an SSD drive cannot be relied upon if it can even be recovered at all. The data is randomly spread out among all the chips in the drive, which makes it very hard to reassemble, even if the controller did not immediately start messing it up, as soon as the drive was given a new erase command from the OS.
Here is more information:
http://www.forensicswiki.org/wiki/Solid_State_Drive_(SSD)_Forensics -
Re:Wha???
Why they were even bothering with the unlock screen rather than just slurping up all the data on the phone with a UFED is beyond me.
Because cops are idiots and the only reason the system works is because criminals are usually even dumber ?
What makes you think that the system is working?
-
Re:Wha???
Why they were even bothering with the unlock screen rather than just slurping up all the data on the phone with a UFED is beyond me.
Because cops are idiots and the only reason the system works is because criminals are usually even dumber ?
-
Re:Wha???I assumed that too, but it doesn't seem true in this case:
Technicians apparently mis-entered the pattern enough times to lock the phone, which could only be unlocked using the phone owner's Google account credentials.
Why they were even bothering with the unlock screen rather than just slurping up all the data on the phone with a UFED is beyond me.
-
Re:I wish this was the case in the UK
A decent idea, except you can tell in the registry whether it was a usb mass-storage device or not.
http://www.forensicswiki.org/wiki/USB_History_Viewing -
Re:This is what easy over safe design gets ya
I really, really hate what Gigabyte does with their BIOSes, considering their BIOS backed itself up on the end on some of my disks, changed the OS-visible size of the disk using Host Protected Area (HPA), squashing the mdraid metadata that was happily living there.
By the time I understood what was happening, I had had 3 of my 6 RAID disks screwed, as I had swapped the disks around ignorantly thinking it was some controller error.
That feature was not advertised, and that version of the BIOS had a bug where this feature didn't properly detect which disks it could accomplish this on (it only looked for NTFS/VFAT partitions, natch) and could not be disabled. While I can understand the purpose and usefulness of the feature, releasing with such a bug has made me swear off Gigabyte.
For the reference, it was a GA-P35-DS3, with BIOS F12.
-
Re:Better question is how overwritten was the rest
It is your word against mine. One of us is going to have to provide a citation. Let me ask google.
http://www.forensicswiki.org/wiki/Remnant_Data
Well, it works on floppy disks. So that supports my account: That this technique was once viable, long ago, on drives of very low bit density compared to todays. It is viable no longer.
Yes, it's a wiki. But it links to an actual paper if you want to research further. -
Re:Better question is how overwritten was the rest
But once that physical block is overwritten, the previous data is gone. Assertions to the contrary are nothing but urban legend and speculation. Nobody seems comfortable claiming that one pass with zeroes is sufficient, but I've seen no evidence that it isn't.
See Peter Gutmann's Secure Deletion of Data from Magnetic and Solid-State Memory from the 6th USENIX Security Symposium Proceedings, San Jose, California, July 22-25, 1996. It certainly surpasses the "urban legend" bar for me (it was peer-reviewed and academically vetted).
Available online here: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
The whole paper is worth reading, and it certainly applies to hard drives and not cassettes or earlier meda. A relevant excerpt:
The problem lies in the fact that when data is written to the medium, the write head sets the polarity of most, but not all, of the magnetic domains. This is partially due to the inability of the writing device to write in exactly the same location each time, and partially due to the variations in media sensitivity and field strength over time and among devices.In conventional terms, when a one is written to disk the media records a one, and when a zero is written the media records a zero. However the actual effect is closer to obtaining a 0.95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one. Normal disk circuitry is set up so that both these values are read as ones, but using specialised circuitry it is possible to work out what previous "layers" contained. The recovery of at least one or two layers of overwritten data isn't too hard to perform by reading the signal from the analog head electronics with a high-quality digital sampling oscilloscope, downloading the sampled waveform to a PC, and analysing it in software to recover the previously recorded signal.
That said, Gutmann later proposed a 2-pass overwrite method that should be sufficient with modern drives, and offered a discussion of why some of the things proposed in the paper are less relevant on modern, denser hard drives than previously:
http://www.forensicswiki.org/wiki/Epilogue_to_Gutmann's_1996_paper -
Make a disk image
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.
-
Make a disk image
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.
-
Image it first
You might have done this already, but since you do not mention it: I would highly suggest making an image of the disk (using dd or dd_rescue) and working on a copy of that, before the original disk dies. Maybe foremost can be of any use, although I doubt it can either handle the original Xenix file system - whatever it might have been - or BBS text files very well...
-
Re:Really?
It seems that this usb stick was designed to bypass full disk crypto etc. It allows an investigator to pull as much important data as possible off of a running system before it is confiscated.
http://www.forensicswiki.org/wiki/Incident_Response
Its mention in that wiki entry makes it sound like nothing more than a graphical frontend for various other forensics tools.
While it would be easy enough to write something like this for any operating system, it goes a bit beyond a knoppix disk.