TeraByte Unlimited

TeraByte Support wrote:
> If you restored a single partition outside of encryption (and write
> standard mbr) it would work, but inside it's saying it's unpartitioned, and so it's
> adjusted as such (but it's really not). We'll have to add a some special
> processing for restoring to those truecrypt volumes since they mount per
> partition instead of mounting one unencrypted physical drive.

Well, the MBR wasn't changed at all. It was the first sector of the C partition that was changed. The physical location where a partition is located is written not only in the partition table in the MBR, but also in the first sector of the partition itself. Through the IFL settings, apparently I was able to prevent it from messing with the partition table, but it looks like it still "updated" the location information in the partition.

I've looked at what's included in the changed portion of the Bios Parameter Block, and the item that most likely was changed is the 4-byte Hidden Sectors value. That's the number of sectors on the physical drive before the current sector, or, in other words, where the partition is located on the drive. Since I did away with the 100MB Win 7 boot partition, my HS value is 2048 (00 08 00 00).

Logically, since IFL may be restoring a partition to a different drive than the original, or even to a different place on the original drive, it probably checks to determine where the partition has been installed, and updates both the MBR and the BPB. But of course the data isn't being written to the physical drive, but rather to the Truecrypt-mounted pretend drive, so however it determines where the restoration is being written may not work properly. Well, I'm just guessing, of course. The other possibility is that it is assuming that the 100MB partition is still there, and updates accordingly.

By doing an uncompressed backup of the C partition, I have confirmed that the image itself contains the correct values for the block in question. So the change does occur on the restore, as you said.

What's odd about this is that the restore worked correctly on my D partition, with no changes being made. And since D is a primary partition, it had a BPB too. So I don't understand why it would work in one case, but not in the other. Well, I have more experimenting to do.

But what we really need for these types of backups is an option to let IFL restore the partition, and update nothing at all, either in the MBR or in the BPB - just an exact restoration of the image, and that's all.

TeraByte Support(TP) wrote:
> Peabody wrote:
>
> Yes, testing here shows basically the same thing as you are seeing. The bytes that
> can get changed are at locations 0x18 through 0x1f in the first sector of the C drive
> (boot sector). Those locations hold the sectors per track, # of heads, and hidden
> sectors values. It could be as few as 3 of those 8 bytes getting changed, but could
> be more. These bytes get changed when restoring the image.

Ok, if you look at the bytes in question unencrypted using hexedit with the partition mounted in Truecrypt, you should be able to determine exactly what bytes were changed and what the new values are.

Here's an idea: When I run IFL and go through the backup or restore process after mounting the partition in Truecrypt, at some point I select the TC-mounted partition as the source or the destination. Then, I can click on Information, and it gives me cylinders/heads/sectors plus the sectors where the partition is located. For my C partition (mounted version), it says 1023/84/13 and 0 to 188948472.

However, if I select instead the actual unmounted partition, Information gives me 1022/254/63 and 2048 to 188950527.

Being a glutton for punishment, on a whim I checked to see whether the sizes of these two versions of the partition are the same, and in fact the TC mounted partition is 7 sectors smaller than the real one. So, I went looking, and found at physical sector 188950520 a version of the first sector of the partition, but with the 1023/84/13 values and 0 as the hidden sectors. Then in sector 188950527 (the real last sector), there's a copy of the actual first sector, with the right numbers - I believe that is normal for NTFS.

I also found an identical copy of those sectors ...20 to ...26 in a file in C in the early part of the partition, but I can't tell what file it is in.

So I wonder if when you install TC on the computer, it does this 7-sector reduction in the partition length, and copies those six sectors from one of its install files.

Oddly, on the D partition, there is no 7-sector haircut, or 6-sector copy of anything, just the last sector copy of the first sector, per normal. I regret that I didn't do the Information comparison, but the D partition DID restore correctly.

Anyway, I would just bet that IFL is updating these values based exactly on what's being reported to it by TC. It wants to update because the partition may be restored on a different drive, or to a different place. It would also want to update the partition table, but it looks like one of the settings can prevent that.

And thanks very much on the hex editor. Just what I was looking for.

You're going to be able to get this to work. I know you can. But while you're doing this, remember that so far we've only looked at whole drive encryption, not individually encrypted partitions, and we haven't looked at the Win 7 100 MB partition because I had removed mine. So you have some experimenting yet to do. But when completed, I think yours will be the only imaging program that does this correctly. If others already can, they're keeping it a secret.

I wanted to report that I tried the backup/restore process on my D drive, and found that it makes the same 16-byte changes as on the C drive. But for some reason this didn't screw things up as far as booting is concerned.

And IFL also changes the same values in the copy of the first partition that's found in the last partition of the physical sector.

Peabody wrote:
> TeraByte Support(TP) wrote:
> > Peabody wrote:
> >
> > Yes, testing here shows basically the same thing as you are seeing. The bytes
> that
> > can get changed are at locations 0x18 through 0x1f in the first sector of the C
> drive
> > (boot sector). Those locations hold the sectors per track, # of heads, and
> hidden
> > sectors values. It could be as few as 3 of those 8 bytes getting changed, but
> could
> > be more. These bytes get changed when restoring the image.
>
> Ok, if you look at the bytes in question unencrypted using hexedit with the partition
> mounted in Truecrypt, you should be able to determine exactly what bytes were changed
> and what the new values are.
>
> Here's an idea: When I run IFL and go through the backup or restore process after
> mounting the partition in Truecrypt, at some point I select the TC-mounted partition
> as the source or the destination. Then, I can click on Information, and it gives me
> cylinders/heads/sectors plus the sectors where the partition is located. For my C
> partition (mounted version), it says 1023/84/13 and 0 to 188948472.
>
> However, if I select instead the actual unmounted partition, Information gives me
> 1022/254/63 and 2048 to 188950527.
>
> Being a glutton for punishment, on a whim I checked to see whether the sizes of these
> two versions of the partition are the same, and in fact the TC mounted partition is 7
> sectors smaller than the real one. So, I went looking, and found at physical sector
> 188950520 a version of the first sector of the partition, but with the 1023/84/13
> values and 0 as the hidden sectors. Then in sector 188950527 (the real last sector),
> there's a copy of the actual first sector, with the right numbers - I believe that is
> normal for NTFS.
>
> I also found an identical copy of those sectors ...20 to ...26 in a file in C in the
> early part of the partition, but I can't tell what file it is in.
>
> So I wonder if when you install TC on the computer, it does this 7-sector reduction
> in the partition length, and copies those six sectors from one of its install files.
>
> Oddly, on the D partition, there is no 7-sector haircut, or 6-sector copy of
> anything, just the last sector copy of the first sector, per normal. I regret that I
> didn't do the Information comparison, but the D partition DID restore correctly.
>
> Anyway, I would just bet that IFL is updating these values based exactly on what's
> being reported to it by TC. It wants to update because the partition may be restored
> on a different drive, or to a different place. It would also want to update the
> partition table, but it looks like one of the settings can prevent that.
>
> And thanks very much on the hex editor. Just what I was looking for.
>
> You're going to be able to get this to work. I know you can. But while you're doing
> this, remember that so far we've only looked at whole drive encryption, not
> individually encrypted partitions, and we haven't looked at the Win 7 100 MB
> partition because I had removed mine. So you have some experimenting yet to do. But
> when completed, I think yours will be the only imaging program that does this
> correctly. If others already can, they're keeping it a secret.

Yes, this issue is being looked at.

The values getting changed are the sectors/track, # of heads, and hidden sectors values that are contained in offsets 0x18 thru 0x1f in the boot sector. These values getting changed only cause a problem on the actual partition being booted from (the C partition if no SRP, or the SRP partition if one is in use). Here's some info on the layout of the NTFS boot sector:

http://www.ntfs.com/ntfs-partition-boot-sector.htm

As far as the difference in size that you're seeing, I'm not sure, but I don't see that happening here (sizes are identical). What you see may be unrelated to TC. One thing to check would be the size of the file system in sectors as recorded in the boot sector. That value is in the 8 bytes at offsets 0x28 thru 0x2f (Total Sectors, see link above), so you could compare that value to the size of the unmounted partition (i.e. dev/sda1) that IFL shows, and see if they are different. Normally those values should be the same (and are here).

The 7-sector size difference must be related to Windows in some way because it's there before I even encrypt the drive. In other words, if I run the HxD hex editor, and look at the C partition, it shows the partition as ending 7 sectors before the partition table does. So apparently TC is just picking that up. Or, actually, it could even be a Samsung thing, but not TC's fault.

However, for the D partition it's the same 7-sector haircut in HxD, but that haircut does not flow through to TC and IFL, both of which cover the whole partition. So, I don't know what the 7 sectors are all about.

I have two questions about the Linux stuff on the IFL CD.

I can mount any partition in TC and view the decrypted contents with hexedit. But how would I do that for parts of the drive that aren't located inside a partition? Itried to mount the whole drive in TC, but it gave me some long-winded error message about there being no such partition. Is this even possible?

With regard to your dd command lines for saving and restoring the first sector of the partition - is it possible to save and restore a block of sector numbers that fall in the middle of the partition? What would such a command line look like?

Peabody wrote:
> The 7-sector size difference must be related to Windows in some way because
> it's there before I even encrypt the drive. In other words, if I run the
> HxD hex editor, and look at the C partition, it shows the partition as
> ending 7 sectors before the partition table does. So apparently TC is just
> picking that up. Or, actually, it could even be a Samsung thing, but not
> TC's fault.
>
> However, for the D partition it's the same 7-sector haircut in HxD, but
> that haircut does not flow through to TC and IFL, both of which cover the
> whole partition. So, I don't know what the 7 sectors are all about.
>
> I have two questions about the Linux stuff on the IFL CD.
>
> I can mount any partition in TC and view the decrypted contents with
> hexedit. But how would I do that for parts of the drive that aren't
> located inside a partition? Itried to mount the whole drive in TC, but it
> gave me some long-winded error message about there being no such partition.
> Is this even possible?

I don't think you can do that - it only mounts partitions (or file containers) containing encrypted file systems, as far as I know.

>
> With regard to your dd command lines for saving and restoring the first
> sector of the partition - is it possible to save and restore a block of
> sector numbers that fall in the middle of the partition? What would such a
> command line look like?

Yes, to skip over blocks on input you would use the 'skip' option:
dd if=/dev/sda1 of=filename.bin bs=512 count=1000 skip=200
This command would skip over the first 200 blocks of size 512 bytes on /dev/sda1, and then read the next 1000 blocks of /dev/sda1 into filename.bin

And, to skip over blocks on output you would use the 'seek' option:
dd if=filename.bin of=/dev/sda1 bs=512 count=850 seek=23
This command would write 850 blocks of size 512 bytes from filename.bin to /dev/sda1, after first skipping over the first 23 blocks of /dev/sda1

You can get brief help on 'dd' by running 'dd -h', or here's the full man page for it:
http://linux.die.net/man/1/dd

TeraByte Support(TP) wrote:

> Yes, this issue is being looked at.

> The values getting changed are the sectors/track, # of heads, and hidden sectors
> values that are contained in offsets 0x18 thru 0x1f in the boot sector.

I just wondered if any progress has been made on this issue.

Peabody wrote:
> TeraByte Support(TP) wrote:
>
> > Yes, this issue is being looked at.
>
> > The values getting changed are the sectors/track, # of heads, and hidden sectors
> > values that are contained in offsets 0x18 thru 0x1f in the boot sector.
>
> I just wondered if any progress has been made on this issue.

Yes, and it will be addresed in the next release of IFL.

Well I see that we have a new version, and the change log for IFL includes improved handling of encrypted drives. Is there a further explanation of what was changed, or what limits still remain - such as not changing the size or location of the restored partition? Any changes to the Manual?

Peabody wrote:
> Well I see that we have a new version, and the change log for IFL includes
> improved handling of encrypted drives. Is there a further explanation of
> what was changed, or what limits still remain - such as not changing the
> size or location of the restored partition? Any changes to the Manual?

Basically, the handling of TC volumes in IFL was improved/corrected so that it's no longer necessary to manually edit the boot sector after restoring an image of a TC volume. So the image/restore operations that you were trying previously should now work without having to do that.

We will try to get something written up (probably a KB article) to cover the overall topic of dealing with TC volumes in IFL, including reszing, etc.