Re: E01 (Was: Raspberry Pi floppy interface.
eg: What is the structure of the "Header Case Information" block? The E01 would be adequate (barely), if accompanied by an additional "metadata" file that describes the physical format. (In much more detail than just "IBM PC 360K", etc.) For MOST situations, OS, encoding, bytes per sector, sectors per track, interleave, side pattern, size of index and inter-sector gaps, etc. might do. That would still be far from PERFECT, because it would fail to catch . . . On Mon, 4 Feb 2019, Chuck Guzis via cctalk wrote: Somewhere on the LOC website, there is a bit more detail--and source for Linux tools under "ewf-tools" is also available. The header information for E01 files is fairly rigid in structure. But a text description of, say, a Victor 9000 floppy is kind of hard to put into 50 words or less. not even 64 bit ones. With a lot more space, you could write a reasonably usable description. But it would have to be an extensible variable length field to permit identifying various exceptions and oddities. Therefore, the media physical format description would have to be a separate file from the E01 "data from the disk". So, when an archivist talks about forensic data image, I scratch my head in bewilderment. I try to put things in terms that they might understand; to wit, "If you had temporary custody of an extremely rare book, would you be content with just the text of the book, or would you want photographic images of every page?" An excellent analogy. I guess that they would not be interested in a separate file of a photographic image of every page to accompany the file of the text of the book. But I'm sure that Fred is well acquainted with the "This is what they told us was the Right Thing to Do, so that's what we want." phenomenon. BTDT. In addition to Xenosoft (concurrently!), I was a community college professor, dealing with college administrators for 35 years. Sometimes you can not get past the Misplaced Authority Syndrome to explain reality. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: E01 (Was: Raspberry Pi floppy interface.
And, of course, a lossy compression, such as MP4 leaves room for an enormous amount of steganographic data, with documants and data hidden in porn. (MANY different MP4 files will still play the same movie) On Mon, 4 Feb 2019, John Foust via cctalk wrote: That would be a very sneaky criminal if they were still using floppies. "Hey, Captain! Does anybody know what this 8 inch square thing is, and whether it goes with a computer?" That paragraph was not specifically about floppies, but about the entire concept of hidden data.
Re: E01 (Was: Raspberry Pi floppy interface.
On 2/4/19 3:40 PM, Jim Manley via cctalk wrote: > Did someone say "punched cards ... with steganographic bits in chads that > are only attached along a couple of edges"? NCR CRAM?
Re: E01 (Was: Raspberry Pi floppy interface.
Did someone say "punched cards ... with steganographic bits in chads that are only attached along a couple of edges"? On Mon, Feb 4, 2019 at 4:36 PM Chuck Guzis via cctalk wrote: > On 2/4/19 3:22 PM, John Foust via cctalk wrote: > > At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: > >> And, of course, a lossy compression, such as MP4 leaves room for an > enormous amount of steganographic data, with documants and data hidden in > porn. (MANY different MP4 files will still play the same movie) > > > > That would be a very sneaky criminal if they were still using floppies. > > As opposed to, say DECtape? > >
Re: E01 (Was: Raspberry Pi floppy interface.
On 2/4/19 3:22 PM, John Foust via cctalk wrote: > At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: >> And, of course, a lossy compression, such as MP4 leaves room for an enormous >> amount of steganographic data, with documants and data hidden in porn. >> (MANY different MP4 files will still play the same movie) > > That would be a very sneaky criminal if they were still using floppies. As opposed to, say DECtape?
Re: E01 (Was: Raspberry Pi floppy interface.
On 2/4/19 2:49 PM, Fred Cisin via cctalk wrote: > Well, conversion between E01 and IMD or teledisk formats looks > straightforward. > > http://www.forensicsware.com/blog/e01-file-format.html > Is there a better description handy? > > eg: What is the structure of the "Header Case Information" block? > > The E01 would be adequate (barely), if accompanied by an additional > "metadata" file that describes the physical format. (In much more > detail than just "IBM PC 360K", etc.) For MOST situations, OS, > encoding, bytes per sector, sectors per track, interleave, side pattern, > size of index and inter-sector gaps, etc. might do. That would still be > far from PERFECT, because it would fail to catch several obvious ways to > hide additional data on a disk; eg. different physical interleaves that > would still read the same on "normal" reading, or RSA encrypted data > with the key stored in intersector gaps. Or, a small amount of data > stored as locations of deliberate disk errors. Think about ProLock. Somewhere on the LOC website, there is a bit more detail--and source for Linux tools under "ewf-tools" is also available. The header information for E01 files is fairly rigid in structure. But a text description of, say, a Victor 9000 floppy is kind of hard to put into 50 words or less. There seems to be a notion that "an image used for forensic purposes" is job-guarantee. In fact, when the term "forensic" is used, it has to do with crime detection and use as evidence in a legal proceeding. That is, the point of forensic examination is to prove or disprove something--completeness isn't necessary in all cases. For example, if examining DNA evidence is used to tie or eliminate a suspect, it isn't necessary that the whole genome be sequenced; presence or absence of a certain number of "markers' will do the job. (I spent some years (1987-2000) providing products and training for law enforcement forensics and am a life member of IACIS.) So, when an archivist talks about forensic data image, I scratch my head in bewilderment. I try to put things in terms that they might understand; to wit, "If you had temporary custody of an extremely rare book, would you be content with just the text of the book, or would you want photographic images of every page?" But I'm sure that Fred is well acquainted with the "This is what they told us was the Right Thing to Do, so that's what we want." phenomenon. --Chuck
Re: E01 (Was: Raspberry Pi floppy interface.
At 04:49 PM 2/4/2019, Fred Cisin via cctalk wrote: >And, of course, a lossy compression, such as MP4 leaves room for an enormous >amount of steganographic data, with documants and data hidden in porn. (MANY >different MP4 files will still play the same movie) That would be a very sneaky criminal if they were still using floppies. - John
Re: E01 (Was: Raspberry Pi floppy interface.
On Mon, 4 Feb 2019, Chuck Guzis via cctalk wrote: Based on my conversations with clients, the problem is not the equipment, but rather the lack of an open, vetted and documented file format. As an example, customers of mine insist on a "forensic" image file of type E01 (Encase format), which has been endorsed by the Library of Congress and several law enforcement agencies as a valid "forensic" format. As insane as it sounds, I've had to provide floppy images as E01 files. The insanity stems from the loss of information that would enable one to recreate the original (e.g. sector headers, modulation, data rate, track spacing, etc.). But one does what one does to keep customers happy. Well, conversion between E01 and IMD or teledisk formats looks straightforward. http://www.forensicsware.com/blog/e01-file-format.html Is there a better description handy? eg: What is the structure of the "Header Case Information" block? The E01 would be adequate (barely), if accompanied by an additional "metadata" file that describes the physical format. (In much more detail than just "IBM PC 360K", etc.) For MOST situations, OS, encoding, bytes per sector, sectors per track, interleave, side pattern, size of index and inter-sector gaps, etc. might do. That would still be far from PERFECT, because it would fail to catch several obvious ways to hide additional data on a disk; eg. different physical interleaves that would still read the same on "normal" reading, or RSA encrypted data with the key stored in intersector gaps. Or, a small amount of data stored as locations of deliberate disk errors. Think about ProLock. And, of course, a lossy compression, such as MP4 leaves room for an enormous amount of steganographic data, with documants and data hidden in porn. (MANY different MP4 files will still play the same movie) -- Grumpy Ol' Fred ci...@xenosoft.com
