Jump to content

Windows7 C: partition shows as RAW in diskpart?


Recommended Posts

Thanks Jaclaz.

I am waiting to find out from him the name of the encryption now.

The Kaspersky was a livecd but I think it downloaded updates automatically, its crazy that it writes these files to HDD not to ramdisk or something.

Do you think it wrote Kaspersky files to the main RAW partition? or maybe only write over the [HDDRECOVERY] partition which has no important data?

The Windows recovery attempts was also not smart before imaging :(

No, the encrypted partition was simply "not mountable" (either due to the encryption or to the corruption) the Kaspersly, besides having stupidly written on the [system] partition (NOT on the [HDDRECOVERY] one) is innocent.

The "stupidly" may be referred BOTH to the good Kaspersky guys and to the good guy that attempted running an Antivirus on a disk where there was an encryption/partition issue AND having that machine connected to the Internet :w00t: .

It is more likely that the "bootsect.exe /nt60 all /force" has made some damages. :unsure:

Rule of the thumb (for next time :rolleyes: ) is to NEVER (and when I say NEVER, I do mean NEVER) write anything before having made an image (at least of what you are going to overwrite, like the MBR and the PBR's).

Consider how - particularly Notebooks with "recovery partition" and or with hard disk encryption connected to the motherboard - may use non-standard MBR code (less likely non-standard PBR code) and possibly also use some of the hidden sectors, but what the heck, we are talking here of saving a bunch of sectors, not necessarily image the whole disk (for which one may be unable to provide a big enough storage space).

JFYI ;) :

http://en.wikipedia.org/wiki/Primum_non_nocere

jaclaz

Edited by jaclaz
Link to comment
Share on other sites


You're right of course Jaclaz.

I found finally the encryption is Mcafee. I have password now and was able to use 'Mcafee emergency disk' to write the bootsector. Now there is encryption password prompt when booting up like it used to be, I enter password and it accepts it, but then it says 'cant load OS'.

Do you think there is a way to restore the HDD so the encryption software can recognize it as encrypted? so it can then decrypt it?

Here is how the HDD looks after Mcafee emergency disk repair:

post-86056-0-51938700-1369167618_thumb.p

It is Disk 1 with 126GB partition and the rest unallocated, which is not correct.

Compared to Disk 3 which is image file of same HDD before emergency disk repair, showing 3 partitions, but probably those are not right either. Usually system is 100MB not 1.46GB right?

What do you think can be done to see some files of this disk?

Edited by rcll
Link to comment
Share on other sites

After the emergency disk wrote its repair I did another testdisk analyze, deep analyze and rebuildbs. Also dmde scan but it looks very similar to before emergency disk.

Should i try chkdsk or some other tool for corruption?

Is there anything that can be done with disk editor?

testdisk.log.txt

post-86056-0-00150300-1369241518_thumb.p

Link to comment
Share on other sites

It is Disk 1 with 126GB partition and the rest unallocated, which is not correct.

Yes, but usually (cannot say specifically) there is an option in the encryption software to "convert" the encrypted disk to non-encrypted without booting it.

I am not familiar with McAfee encryption software, and there are more versions of it than stars in the sky, if I recall correctly, how exactly did you write the bootsector?

Maybe the emergency disk "unencrypted" the existing bootsector (which was altered before) instead of replacing it with the original one.

But the partitioning would never be affected by any change to the PBR or VBR or bootsector, if the partitioning layout changed it means that the McAfee Emergency disk changed the MBR! :w00t::ph34r:

Still following - no offence intended towards the guy that encrypted that disk, that surely did that in perfect good faith :) - my theory that on average users of encryption solution don't know enough about data preservation, it could be that what was given to you was the recovery disk generated on another machine.

I mean, a "normal" MBR (and/or PBR/VBR/bootsector) is made of two parts, code and data.

It is possible that the *whatever* the emmrgency disk wrote was the "right" code (generic) but the "wrong" data (belonging to another machine). :unsure:

Compared to Disk 3 which is image file of same HDD before emergency disk repair, showing 3 partitions, but probably those are not right either. Usually system is 100MB not 1.46GB right?

Yes, but 100 Mb is the "default" for Windows 7, an OEM (like Toshiba) might well have decided that a larger one was needed/smart/whatever.

Out of the three partitions 1st and 3rd were OK, so I doubt that

What do you think can be done to see some files of this disk?

You need to check if Mcafee (or a third party) provides a solution to "convert the disk" to unencrypted (without changing/restoring/whatever) the MBR or the bootsector.

jaclaz

Link to comment
Share on other sites

Thanks Jaclaz.

I talked to their support and you are right. They said that the emergency disk is special for the machine and has a copy of the mbr and partition table and it just overwrites the old one. They said if it was from the wrong machine it would give an error.

They have a Mcafee program to decrypt the disk, but when I try to decrypt it won't recognize the disk as encrypted, but we know it is encrypted.

They think its something about the encryption headers being corrupted and they cant do more on the phone.

Do you think the encryption headers can be fixed with a disk editor?

I have the keyfiles and password, maybe I can encrypt the whole disk again and it will write the same headers? Then it will recognize as encrypted and decrypt it?

Link to comment
Share on other sites

Well, you are back to #1, so seemingly the (put here any adjective heavily offending your customer's mental capabilities) guy provided you with the wrong disk? :realmad:

However, nothing prevents you from re-writing ONLY the (good) DATA of the MBR you had before on the current MBR (which has now the McAfee CODE).

Of course IF part of the CODE contains a form of checksum, it won't work, but trying doesn't harm anyone.

In a MBR offsets:

0-445 Code (including Disk Signature on Windows NT OS at bytes 440-443)

446-509 DATA partition table, 4 parttiion table entries, each 16 bytes

510-511 Magic bytes 55AA

So basically you have to copy bytes at offsets 440-443 (4 bytes, the disk signature) and bytes 446-509 (48 bytes, the partition table) from the "old" MBR and replace the corresponding bytes on the "new" McAfee one.

Next step would be to create THREE :w00t: copies (images) of the disk, wipe (write with 00's) the area where the "middle missing partition" is, then format with the same OS originally used (I believe 7) the "missing partition in the middle" as NTFS, then attempt installing the encryption using the same keys.

Then compare the three of them, two at a time.

If they result (at least the first few sectors) substantially similar, then you may have a chance.

Explanation:

When you format two filesystems you do it (obviously) one after the other, the result is that the freshly formatted filesystem will never be identical, because the volume serial (which is misteriously created by the OS on a semi-random base) will be different and expecially on NTFS filesystem structures will have different timestamps.

The point is if the encryption algorithm (the "initial loading part") uses just the provided keyfiles and/or password or it uses a "salt" based on "specific data":

What you can reproduce is:

  1. size of the volume
  2. position of the volume of disk
  3. contents of it's first few sectors (but not the volume serial)

if anything else (like the volume serial or current date/time or date/time of any filesystem structure) has a role in the encryption algorithm yu will have different results (and thus you won't be able to recreate the original "headers").

There is a possibility, still, (again it may depend on the exact version of the software used), at least in older releases there was the possibility of accessing a ("sound") encrypted volume without original key and password by using a "tech access" and a "daily code" (or something like that).

Such an approach may work even with the headers of a "different" volume, but it is really hard to say. :unsure:

JFYI ;):

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...