Partition recovery/ management tools

[cheshire]

Okay, here's the deal... I'm looking for help in finding a tool to do a specific hdd recovery task. This is the situation...

one of our high mucky-mucks decided that backing up his laptop to the network was a bad idea. Now we find ourselves in a situation where his laptop is unbootable. We need to try to recover it, and if anyone's gonna have a tool to do it, it's Linux. I need to find that tool.

The HDD is a 10Gb disk, running NT4.0 sp6a. The entire hdd is encrypted, using a product called SafeGuard Easy. Basically, the app applies an algorithm to the MBR, and to the drive, on a partition by partition basis, to secure data against tampering. To boot the computer, you must enter a password, which protects the MBR. If you use a floppy to bypass the hdd MBR, then you find yourself with an unmountable volume. The drive was partitioned as follows:
hda1 -> 275mb hibernation (type 84)
hda2 -> 2GB NTFS (system)
hda3 -> 7.3GB NTFS

So the tech who was working on the laptop decided that since hda2 was almost full, that he'd use Partition Magic to resize the partitions. Worked fine, no problems. But when the laptop rebooted, the puter would just BlueScreen, claiming to find no bootable volume. Since the partition table changed, the encryption algorithm seems gibbled. The app's manufacturer is not able to help much on this one either.
So the question is this... does anyone know of a tool, app, or utility, either linux- based or otherwise, that can help me to rebuild these partitions? We're grasping at straws here... any suggestion, no matter how vague, would be appreciated, cause we're stumped.
Thanks in advance, folks.

[bigrigdriver]

I don't know if this will be of any help to you, but it's worth a try.

First: documentation found at Ultimaco states that the encryption algorithm is based on the user's password. The entire OS, or just parts thereof, can be encrypted.
(Encryption shouldn't be dependent on partition tables, unless there is some undocumentated feature of Safeguard Easy).

Second: Partition Magic rewrites the partition tables when partitions are resized. So, partition table integrity should be intact.

Third: http://212.29.1.33/pages/usa/productnews/20010829_ultimaco.cfm has this to say:
"With Safeguard Easy, the function of a system administrator, who sets up security, can be split from that of users, for whom the security system operates completely invisibly in the background. If a user forgets a password, the encrypted data is not lost because the system administrator can assign a new initialization password."

Unless the tech who resized the partitions also did something to overwrite the MBR, it should all still be there. Have you tried setting a new password in order to gain access to the OS?

Finally: Is it possible to reinstall NT on hda2(system), leaving the other two partitions alone (Partition Magic to reformat hda2); rewrite the MBR to make hda2 bootable; reinstall Safeguard Easy with the hapless user's password (for the correct encryption algorithm), and regain access to the rest of the HDD?

[slapNUT]

***This is only a theory***

First of all the high mucky-muck should quit downloading porn off the internet then he won't feel the need to encrypt his entire hard drive to hide it... nuf said bout that! :)

The way it sounds if you could get the password back on the MBR you could then put the data back on the partitions.

I figure you could:
-- Backup the partitions:
-- Reformat the drive:
-- Repartition it exactly as before:
-- Reinstall the OS:
-- Reinstall the encryption software using original password:
-- Reinstall the original encrypted data:

So here are the steps you could try (at your own risk, of course, and knowing that I will assume no responsibility for what happens) :)
[list=1]
Install the affected hard drive in a Linux system. This assums the drive is an IDE drive installed on the Primary-slave IDE controller, you might need to change the /dev/hdbX.

Collect all partition information about the drive.

/sbin/fdisk -l /dev/hdb > driveinfo.txt

NOTE: The file driveinfo.txt can now be printed as a reference to later re-partition the drive to it's original state.
Make backups of the three partitions on the affected drive.
dd if=/dev/hdb1 of=hdb1.img
dd if=/dev/hdb2 of=hdb2.img
dd if=/dev/hdb3 of=hdb3.img
NOTE:This will take an extremely long time, so be patient. This will require alot of drive space!

Put the drive back in the original system and reinstall everything as before. Be sure to make partitions exactly like the file driveinfo.txt. Must use original password.

Put the drive back in the linux system and backup the boot sectors.
dd if=/dev/hdb1 of=hdb1.boot.img bs=512 count=1
dd if=/dev/hdb2 of=hdb2.boot.img bs=512 count=1
dd if=/dev/hdb3 of=hdb3.boot.img bs=512 count=1
This step is not necessary but just a precaution.
You should now have the passwords on the boot sectors.
Put the partitions back on the drive. Once again you may need to change the /dev/hdbX.
dd if=hdb1.img of=/dev/hdb1 bs=512 seek=1 skip=1
dd if=hdb2.img of=/dev/hdb2 bs=512 seek=1 skip=1
dd if=hdb3.img of=/dev/hdb3 bs=512 seek=1 skip=1
NOTE: By setting bs=512 and seek=1 skip=1 we will skip the first 512 bytes of the image (the old boot sector) and also we will not overwrite the new boot sectors.

Pause for a moment of reflection... Do you believe in miracles?
[/list=a]
PS. If there was some sort of Time-Stamp applied when the original password was created then this is all a waste of time.

If it doesn't work you still have the data on the drive plus now the mucky-muck has a backup :)

[ 05 January 2002: Message edited by: slapNUT ]

[cheshire]

Thanks for the feedback and suggestions.

The tech involved was able to get in touch with a not-stupid at Utimaco, and they have managed to resolve the issue.

Thanks again