Greetings everyone. First post here on LinuxQuestions and I'm really looking forward to this site.

I've always been interested in data forensics. Unfortunately, in the 7 years I've been working with computers, I haven't been too involved with it until quite recently when I became serious about Linux and the Open Source community.

Right now I'm experimenting with the following programs and some old junk computers:

dd
dcfldd
foremost
scalpel
tsk with autopsy
DEFT Linux

I'm coming along quite nicely with learning about how these programs work and what it means to use these programs however I'm still not too sure about some things and that's why I'm posting here. I'm hoping that someone else is interested in this area of study and can give me a hand because I can't find anything concrete on the internet.

My primary question comes from using either foremost or scalpel. foremost.conf comes with header and footer details for certain media file types like mp3, au, wmv, etc... Now somewhere I read that the actual header for MPEG3 files depends upon the frame contents of the file. I'm not sure if there are other files like this or not but I got to thinking that if the headers were dependent upon frame contents then how would it be possible to accurately reconstruct the actual file simply from the header/footer information? I've attempted to reconstruct some media files with the default data provided in foremost.conf but I've found out two things that are really confusing:

1. I've imaged actual media players that have at least 90 songs of mp3 type on them. In an attempt to reconstruct the data from the image using foremost, it'll reconstruct jpg images from metadata on the mp3 files but will only actually reconstruct 4 to 6 mp3 files.

2. Out of the 4 to 6 mp3 files successfully reconstructed, only 1 of them is accurately reconstructed (i.e. it's an actual song). The other 3 or 5 files are spliced; it plays as if the end of one song was attached to the beginning of another song.

One thing that I think may be happening, I could be very wrong because I'm still not too sure how dd or dcfldd works, is that the image is built by reading the memory in a linear fashion with padding but the file carver can't "undo" the padding. Again, I'm just taking pot shots because I'm not too sure.

Can anyone with background in this area give me some insight?

Welcome to LQ, hope you like it here.

Good to see you're interested in forensics basics. What I could suggest is reading filesystems documentation because this addresses block pointer lists, contiguousness, indirect blocks, and other things that should get you going. If you have an hour time to spare and have or can locate a copy of "Understanding the Linux Kernel, 3rd Edition" see chapter 18: "The Ext2 and Ext3 Filesystems" (actually best start reading at 12: "The Virtual Filesystem" even though delayed allocation and compounded write ops are actually governed by the VMM as explained in earlier chapters), "Basic File System Concepts" from Design and Implementation of the Second Extended Filesystem (or more in-depth: The Second Extended File System), "Finding a file" from Analyzing a filesystem and maybe State of the Art: Where we are with the Ext3 filesystem. (On the "lighter side" there's Why Recovering a Deleted Ext3 File Is Difficult which gives some insight but doesn't exactly explain what you're looking for.)

Thanks for those links. All of these documents have/are proving to be very useful and I'm currently looking for a copy of the Linux Kernel book. Thank you very much.

You're welcome. There's legality issues involved so I won't comment on locating a copy of the book. Just add a reply when you're willing to discuss this topic further, I'm following this thread.

Since your last post unSpawn, I've been reading numerous documentation about filesystems and a bit of computer forensics information but I'm noticing that I'm coming across a lot of red flags about usage of some of these applications.

My question, although a seemingly a bit naive and simplistic, is that if there are so many legal issues regarding the use of these programs/applications while you're not inside the loop if you will, why are more than half of them available in the public domain? I must say that I was especially astonished to find that a program like dcfldd was freely available in my software repository as well as tsk.

Don't get me wrong, I'm very glad that a majority of these programs are freely available so that I can learn how to use them and familiarize myself with the field. It just seems a backward double standard if you know what I mean.

Ultimately, do these legal issues only arise if you take it upon yourself to try and turn profit from using these programs or if you use them for anything other than personal purposes?

Not PD but OSS (or equivalent) licensed. Big difference. Wrt red flags pointers or excerpts are welcome.


W/o details and given tools are made available as OSS I'd say that's the case. While part of the certification, accreditation and registration scheme is obviously red tape meant to fill someones pockets having the business shackled in laws and regulations is good I think because the results of doing stuff wrong are desastrous.