18 Jan
2019
18 Jan
'19
7:40 a.m.
This looks like a project with a ton of potential for archviving media
without having to deal with the asshattery of the kryoflux people.
https://github.com/picosonic/bbc-fdc
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
4 Feb
4 Feb
1:05 p.m.
On 1/18/19 7:40 AM, geneb via cctalk wrote:
This looks like a project with a ton of potential for
archviving media
without having to deal with the asshattery of the kryoflux people.
https://github.com/picosonic/bbc-fdc
Yes, you can do this, as I've said many times before, with just about
any semi-modern MCU that has sufficient memory. I've got a couple of
prototypes from years back, that, for example, use AVR (Mega162 and
Mega256) to do this. The 162 version had write buffers also, so it
could emulate a floppy quite nicely.
An Orange Pi Zero with appropriate buffers could also do this and would
essentially be a $10 sledgehammer.
-----------------
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.
--Chuck
1:17 p.m.
On Feb 4, 2019, at 4:05 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> 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.
--Chuck
Yes, but if the current format is wrong for the job, and people who should know better do
not realize this, it would be a good idea (as a separate activity) to educate them and
propose a better answer.
paul
1:53 p.m.
On 2/4/19 1:17 PM, Paul Koning wrote:
Yes, but if the current format is wrong for the job,
and people who should know better do not realize this, it would be a good idea (as a
separate activity) to educate them and propose a better answer.
Yes, I know, and
I've tried and written volumes about the subject when
E01 for floppies requested. To no avail.
I'll make E01 files and then toss in the IMD file as a freebie The
simple fact is that archivists in general seem to have a "don't rock the
boat" mentality.
--Chuck
2:49 p.m.
New subject: 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 cisin at xenosoft.com
3:22 p.m.
New subject: 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
3:36 p.m.
New subject: 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:
As opposed to, say DECtape?
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. 
3:40 p.m.
New subject: 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 <cctalk at classiccmp.org>
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?
4:53 p.m.
New subject: 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.
3:32 p.m.
New subject: 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
5:13 p.m.
New subject: 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 cisin at xenosoft.com
1917
days inactive
1935
days old
11 comments
6 participants
participants (6)
-
cclist＠sydex.com -
cisin＠xenosoft.com -
geneb＠deltasoft.com -
jfoust＠threedee.com -
jim.manley＠gmail.com -
paulkoning＠comcast.net