Add write support for windows 8 and 8.1 about dislocker HOT 35 OPEN

hamidi2 read/write support for windows 10 encrypted volumes has just been added, see release v0.6.

@Aorimn, Is this still the case?

I formatted a new drive on windows 10 today (1903) and put bitlocker on it. When asked if I want "compatibility mode" I choose yes, however in using dislocker v0.7.1 on Fedora 30 I get a segmentation fault right away, with no additional information, even with -v

Compatible Question

from dislocker.

I've actually tested Win8.1 write support (by removing the check for it that disables write), and found no errors with some relatively simple tests. I had intended to do some more formalized testing (using the XFS test suite generic tests) before submitting a patch to enable it, but I have not found time for it so far.

Perhaps a patch to hide write support behind a mount option (eg, force_win8_write) would be acceptable in the mean time?

from dislocker.

I'm currently testing write support on a Win8 pro BitLockered-encrypted partition. As stated by Thalience, there doesn't seem to be any problem when removing the check in normal conditions.

Therefore, I'm planning to add write support as soon as possible.

@Thalience : let me know if you find problems, everything's fine from my tests.

from dislocker.

Commit fc4132c on the develop branch partially enables write support for windows 8. I'm not absolutely sure about 8.1 as I don't have any such Windows to test on it.

The Win 8 volumes which aren't yet supported are the one using EOW, I don't have enough data to work with.

Feedback appreciated, of course.

from dislocker.

Would a VM running Server 2012 help?

from dislocker.

I'm not sure exactly, it might. I can't seem to find when this EOW thing is used, maybe this is only on servers version, maybe I'm completely mistaken.

from dislocker.

The EOW thing may be related to full-disk encryption versus used space only encryption in BitLocker 2. I don't know what EOW refers to however, but it seems to me that's a good candidate based on the guess that it means "end of write".

from dislocker.

I used to thought it was meant for "encrypt on write", but I can't find how to make a disk with the EOW structures on it, even if I enable to the used space only encryption. So now I kind of doubt it has something to do with it, but maybe I'm wrong and it has something to do with it, I just don't know.

from dislocker.

It could also be for currently encrypting disks, which haven't completed their initial encryption, yet. Though the documentation states, that BitLocker will not encrypt data written newly to disk, while encryption is still in progress. It is obvious that this has to be false, of sorts, because at least all writes to the already encrypted portion must be encrypted in order to not cause data loss or a data snapshot management nightmare. It is far more likely that the lack of protection referred to is meant for the not yet encrypted section or the volume protector, which can be a "no protector use this key" protector.
Maybe the official BitLocker source code could yield some information on this, though, this likely falls under the limitations of the standard NDA and I then wouldn't be able to tell anyone, but it can't hurt to ask... ☺️

from dislocker.

The initial encryption seems to be more related to something called the "conversion" in the public symbols. That's something I didn't touch too much really, I just implemented the support of partially encrypted drives, but I didn't find any correlation between conversion and eow while looking at fvevol.sys.

from dislocker.

I used dislocker on a Windows 10 encrypted partition and got segmentation fault. as the Windows said, it uses a non-compatible method for encrypting a drive. will it be supported?

from dislocker.

This will be once libraries implement the XTS-AES encryption mode, which is used by the new Windows 10 release by default. So far, I haven't found a library able to provide that block-cipher-encryption mode in user-space.

from dislocker.

what's the benefits of this new mode and why Microsoft has changed its method of encryption?
also please let me know how much is the risk of mounting a bitlocker drive in ubuntu by using dislocker and writing randomly to it? is it 100% safe?

from dislocker.

@hamidi2
The previous encryption mode employed by Bitlocker before Windows10 is susceptible to targeted manipulation if the attacker knows the plain text. Given that Bitlocker is generally employed on OS partitions, the attacker can reasonably pick an OS file to use to carry out their attack. See here: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
While this article describes the attack on a Linux machine, the same methods and theories apply to windows.

XTS is not susceptible to the above attack, and according to NIST, offers better protection against tampering than competing modes of disk encryption.
See here: http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf

Microsoft likely added this mode to keep current with the latest cryptanalysis of disk encryption.

Aorimn can answer your other questions better than I.

-----Original Message-----
From: "hamidi2" [email protected]
Sent: ‎12/‎13/‎2015 2:17 AM
To: "Aorimn/dislocker" [email protected]
Subject: Re: [dislocker] Add write support for windows 8 and 8.1 (#10)

what's the benefits of this new mode and why Microsoft has changed its method of encryption?
also please let me know how much is the risk of mounting a bitlocker drive in ubuntu by using dislocker and writing randomly to it? is it 100% safe?
—
Reply to this email directly or view it on GitHub.

from dislocker.

@rossica Thanks for the detailed answer.

@hamidi2 dislocker doesn't randomly write on drives, but if you write randomly on it, then it's not safe at all. If dislocker doesn't recognize the encryption cipher being used, it doesn't even present a partition whereto write randomly.

from dislocker.

thanx rossica
i didn't mean that the dislocker writes randomly. it was better to say, after dislocker recognizes the drive, if i write freely to the partition as i do in Windows, may i suppose that i'm using Windows to write to it? or the writes are not 100% compatible and in some (rare) conditions may corrupt data?

from dislocker.

Ha sorry, I misunderstood your question. Write support is disabled when not totally supported. That is, as far as I can test, I enable the write-feature when I'm sure it works.

However, nobody's free of bugs and maybe one is lurking in the shadow of dislocker for some (rare) conditions, and that may result of corrupted data. I'm sorry if it doesn't sound particularly enthusiastic, but I prefer to be realistic instead of feeding you a marketing speech.

from dislocker.

ok, i'm glad you could enable write. anxiously wait for win10 version.
good luck

from dislocker.

@hamidi2 read/write support for windows 10 encrypted volumes has just been added, see release v0.6.

from dislocker.

thx :)

On Sat, Mar 5, 2016 at 3:25 PM, Aorimn [email protected] wrote:

@hamidi2 https://github.com/hamidi2 read/write support for windows 10
encrypted volumes has just been added, see release v0.6.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from dislocker.

umm.. so at the moment, did write to Windows 8.1 bitlocker partition supported yet? I compiled dislocker yesterday and all data write to bitlocker partition make in windows 8.1 has vanished

from dislocker.

This is supported indeed. Can you describe what you've done exactly? What's the filesystem on your partition? What's the partition type (C: drive, data drive, external drive, ...)?

from dislocker.

oh wait, it did work if I'm write to it directly by cp or mv but it just vanished if I write it via SMB shared folder, there is few error in kmsg below:

[ 42.496981] loop: Write error at byte offset 3219877888, length 4096.
[ 42.503770] blk_update_request: I/O error, dev loop0, sector 6288824
[ 42.510414] Buffer I/O error on dev loop0, logical block 786103, lost async page write
[ 42.519134] loop: Write error at byte offset 3219881984, length 4096.
[ 42.525767] blk_update_request: I/O error, dev loop0, sector 6288832
[ 42.532416] Buffer I/O error on dev loop0, logical block 786104, lost async page write
[ 42.541192] loop: Write error at byte offset 3221229568, length 4096.
[ 42.547932] blk_update_request: I/O error, dev loop0, sector 6291464
[ 42.554455] Buffer I/O error on dev loop0, logical block 786433, lost async page write
[ 42.563659] loop: Write error at byte offset 3221438464, length 4096.
[ 42.570425] blk_update_request: I/O error, dev loop0, sector 6291872
[ 42.576954] Buffer I/O error on dev loop0, logical block 786484, lost async page write
[ 42.628079] VFS: Dirty inode writeback failed for block device loop0 (err=-5).

my drive is external hdd and use ntfs fs

from dislocker.

Can you give me further details on your setup:

• Which distribution are you using?
• Which architecture (at least 32 or 64 bits)?
• Is this a samba server, sharing the external hdd (thus writing to it)?

I'll also need the output of dislocker using -vvvv, and eventually passing the -d option for fuse (dislocker -vvvv -V blah -- /mnt/point -d).

from dislocker.

• Debian stretch
• armhf
• yes, the mounted folder being shared rw

this is kmsg including log, maybe you'll find something interesting in there
http://pastebin.com/xBtx16t6

edit: when I put something to bitlocker through samba, it's working at the moment, I can checksum it by using the client connected through samba and it's matched with original file but when I umount the hdd and plug to windows machine, the file I write is having 0 bytes and no create, modify, accessed time
I already tried to disable write cache but no help, still the same result

from dislocker.

To be honest, I've never tested dislocker on arm, it might have some impact.

Some more questions then:

• Do you see the files when writing through the samba share but looking in the folders using the commandline (ls/cat/md5sum)?
• Did you try running the samba rw share on a linux-native filesystem, just to be sure and rule out it's not samba alone?

When running dislocker, could you add the -d option to fuse, in a dislocker commandline like so:
dislocker -vvvv -V /dev/blah -- /tmp/dislocker -d and repaste the result?

from dislocker.

• yes, I checked the file in mount point with commandline sha1sum, checksum is matched with source after copy through samba. After umount and plug to windows machine there is 2 possibility, 1 is the file which i copied not found or it's became zero byte with no attributes (create/modify dates)
• I'm sure it's not samba fault because my exthdd have 2 partition, 1 is ntfs, mounted via ntfs-3g and shared through samba. The partition 2 is bitlocked, mounted with dislocker and shared through samba with same configuration

dislocker log: http://pastebin.com/c2R3rCw4
fuse log: http://pastebin.com/0LtfCYYQ

dislocker seem freezing forever with log above if use with -d, so there is no /tmp/dislocker/dislocker-file to mount

and no, not only samba but if I drop large file (~50mb) via sftp to dislocker mounted folder then when I umount, plug to windows machine then it become corrupted the same as samba (0 byte)
but if I create small text file with some text in there then file is fine and not became corrupted so this maybe can only dislocker fault but not samba or anything.

from dislocker.

With the -d option passed to fuse, dislocker should print debug information, but still produce the /tmp/dislocker/dislocker-file (the -d option isn't even registered in dislocker). For the linked logs, did you copy some large file? They're empty, so it will be difficult for me to pinpoint the bug.

from dislocker.

dislocker -vvvv -V /dev/sda2 -- /tmp/dislocker -d
http://pastebin.com/zv9zBKvu
nothing in /tmp/dislocker

dislocker -vvvv -V /dev/sda2 -p443674-476245-317306-454267-286385-670351-697972-676764 -- /tmp/dislocker -d with mount -o loop,rw /tmp/dislocker/dislocker-file /mnt/exthdd_bitlocker, with file copying; log too big so i put it in attachment

dislocker.log.gz

from dislocker.

I format the bitlocker partition to exfat and now things seem to be working, md5 is matched after plug to windows computer and there is no "loop: Write error.." spamming anymore, i use ntfs-3g to mount another partition and everything work fine so i don't think if there is any problem with ntfs either... or maybe i'm using Debian stretch so ntfs fuse is unstable version and broke dislocker?

edit: no, just randomly it's work and after a while it's doesn't work anymore, don't know why

from dislocker.

@SandPox : thank you very much for the logs, it seems like it might be a bug in dislocker, as you thought in the beginning. Can you tell me your encrypted partition's size?

from dislocker.

about 50GB (on windows report capacity 49.9GB), I already delete the bitlocker partition because i don't think that i'll need to use bitlocker now so I can't give you future log with that old partition, if you want to debug with ARM arch then i'll encrypt my other USB flash and test it

from dislocker.

Ok so this part is fine then. I think I found the bug, and it has already been fixed in the develop branch. You would need a partition bigger than 4GB to reproduce the issue, if you want to test it from the develop branch.

For reference, here's the commit which should fix your problem: 4cbef4d

from dislocker.

hi Aorimn. We had same issue with partitions bigger than 4GB and 32bit build of dislocker. Mentioned commit 4cbef4d fixed the issue.

from dislocker.

Hi @avgdev007, thank you for the feedback!

from dislocker.