From: Cameron Simpson <cs@zip.com.au>
To: linux_forensics@yahoogroups.com
Cc: 
Bcc: 
Subject: Re: Using dd to image  unknown backup tape
Reply-To: cs@zip.com.au
In-Reply-To: <200206191951.g5JJpnG27134@red.all.net>

[ Quoting order fixed. Irrelevant content trimmed for readability. ]

On 12:51 19 Jun 2002, Fred Cohen <fc@all.net> wrote:
| Per the message sent by Steve Fowler:
| > Per the message from:  "jon_48392"
| > >I am trying to use dd to create an image of a DDS3 tape (content
| > >unknown) using a Sony SDT-S9000 tape drive. [...]
| > >[root@ws5]# dd if=/dev/nst0 of=tape.dd bs=512
| >
| > We have found that the EOF marker precludes the drive from reading anything 
| > from a DDS (aka 4mm DAT) tape beyond the point where it's 
| > encountered.  This function is designed into the firmware of all DDS tape 
| > drive makes.  The data may be there, but unless you can recode the firmware 
| > built into that hardware, the game is over.
| > Steve Fowler
| > Micro Com Worldwide Data Recovery
|
| I think the problem here is not the EOT hardware marker but the EOF
| marker associated with the end of a tape extent, hence 'mt fsf' to skil
| past the first end of file marker.  If it is the hardware marker, you
| have to splice the tape beyond to get around it - or use a different
| reader with 'special' electronics.

Leaving aside any special DDS weirdness, the original poster probably
doesn't realise that a tape is usually presented as a sequence of files,
each with one EOF marker (zero sized block) at the end; the end of the
set of files is marked by two EOFs.

So it's likely you have merely read the "label" file off the tape
(a short, typically single block) file at the start of the tape for
identification purposes.

What you need to do is determine what files are on the tape, then read
each in turn (with the no-rewind device).

Adding to the fun is that when you read from a tape the tape reads a
whole block; if you ask for less than a block you get that much data
and _miss_out_ on the back of the block; the next read will be from the
start of the next tape block.

I use this perl script:

	http://www.cskk.ezoshosting.com/cs/scripts/taprd

to examine tapes. It wants my cs::Upd module, but you can get working
behaviour by commenting out the "use cs::Upd" at the start and not using
the "-v" option.

Usage is:

	TAPE=/dev/the-no-rewind-tape-device-name
	export TAPE
	mt rewind
	taprd

Taprd's default block size is 32k. This may well be too small. For
example, try:

	mt rewind
	taprd -b 262144

for a potential 256kb block size. Wind that up until taprd starts
reporting block sizes below what you set -b to; taprd will report
actual block sizes provided you set -b big enough. Because of the above
mentioned "short read" behaviour, using a small block size doesn't let
taprd "notice" larger tape blocks.

Once you have taprd's report you can pull the files off. Each file may
have a different block size (taprd will tell you). Use dd to get the
data, thus:

	mt rewind
	dd if=$TAPE of=file1 bs=BBBB1
	dd if=$TAPE of=file2 bs=BBBB2
	dd if=$TAPE of=file3 bs=BBBB3
	... etc ...
	mt rewind
	mt eject	## or "unload" on some systems

where file1, file2 etc are the files you'll be storing the tape data in,
and BBBB1, BBB2 are the block sizes appropriate for each file as reported
by taprd, in bytes.

I hope this clarifies things a bit about dealing with tapes in general.

Good luck,
-- 
Cameron Simpson, DoD#743        cs@zip.com.au    http://www.zip.com.au/~cs/

Yes, we plot no less than the destruction of the West. Just the other day a
friend and I came up with the most pernicious academic scheme to date for
toppling the West: He will kneel behind the West on all fours. I will push it
backwards over him.	- Michael Berube