[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[Mateusz Jończyk]

W dniu 01.11.2021 o 11:55, Milan Broz pisze:

> Hi,
>
> On 31/10/2021 23:36, Mateusz Jończyk wrote:
>> Hello,
>>
>> Back in June, I wrote to the mailing list seeking some help with
>> reverse-engineering the DiskCryptor volume format [1].
>>
>> Since then, I have implemented decryption of the volume header (for all
>> cipher combinations, with autodetection) and would like to know whether
>> you would be interested in merging support for opening DiskCryptor
>> volumes once it is ready.
>>
>> The DiskCryptor development has largely stalled, with the last beta
>> release in April 2020. Releases by DavidXanatos have the following
>> problem [3]:
>>
>>>         The Disk Cryptor driver needed to be updated, and since the
>>>         ReactOS foundation no longer offer a driver signing service, I
>>>         head to use a leaked code signing certificate I found laying
>>>         around the Internets. This means some anti malware applications
>>>         may wrongfully flag it as potentially dangerous.
> How much is DiskCryptor used in reality? The note above would qualify
> it as a regular malware for me 
> I would like to have support for various formats, but the line where
> it becomes bloatware is very thin...
>
> Anyway, if
>  - code is licensed under LGPL (no new GPL-only code in libcryptsetup)

Yup

>  - it only allows to open existing formats (no code to modify metadata;
>    our primary format is LUKS and it will stay this way)

OK

>  - it does not add complicated dependences
>    (I think we should care about memory footprint more now)

that's correct (it won't add any external dependencies).

> then the best is perhaps open merge request (or issue) on the project
> page and discuss it there.
> (For now, the code looks simple enough.)

You mean open now, or once the code is ready?

> What is missing to more "stable" code? Only the parts marked TODO,
> or something crucial for format parsing?

The major parts missing in the code I posted:

- setting up mapping in the device mapper,

- libcryptsetup: support for *dm_error_target_set()* that would be
similar to *dm_zero_target_set()* to create a region in the block
device that errors out reads and writes. This is necessary as sometimes
the first 2048 bytes of the encrypted filesystem are relocated to another
place in the image ( https://diskcryptor.org/volume/ ):

> Relocation area - is a contiguous sequence of sectors where the first 2048
> bytes of partition are stored.
>
> Currently there are two methods of placement of this area that are being 
> used: in $dcsys$ file, or at the end of partition. On encryption of partition 
> that has data on it, this area is being placed in $dcsys$ file [its name 
> contains the dollar signs] , which is located in a contiguous sequence of 
> clusters. On formatting a new partition, this area is being placed at the 
> end of partition, after user data.
>
> In order to protect the $dcsys$ file from being deleted, fragmented or 
> moved, its access is forbidden by the driver.

It will be necessary to just inform the user not to delete the $dcsys$
file as there is no other workable way to protect it.

- some boilerplate in lib/setup.c and src/cryptsetup.c (and perhaps
some code to require a confirmation about the $dcsys$ file from the user).

- documentation,

- tests,

- unlocking with keyfiles (should not be complicated).


I have rebased the code on cryptsetup v2.4.1 and did some further
development (began work on devicemapper setup). It can be found on a new branch:

https://github.com/matjon/cryptsetup/tree/dcryptor_support_on_2.4.1/lib/dcryptor

> Thanks,
> Milan

Greetings,

Mateusz

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[Milan Broz]

On 02/11/2021 21:23, Mateusz Jończyk wrote:
>> then the best is perhaps open merge request (or issue) on the project
>> page and discuss it there.
>> (For now, the code looks simple enough.)
> 
> You mean open now, or once the code is ready?

Once the code is ready for review (so all major parts, like activation, are there).

> 
>> What is missing to more "stable" code? Only the parts marked TODO,
>> or something crucial for format parsing?
> 
> The major parts missing in the code I posted:
> 
> - setting up mapping in the device mapper,
> 
> - libcryptsetup: support for *dm_error_target_set()* that would be
> similar to *dm_zero_target_set()* to create a region in the block
> device that errors out reads and writes. This is necessary as sometimes
> the first 2048 bytes of the encrypted filesystem are relocated to another
> place in the image ( https://diskcryptor.org/volume/ ):


Please do not use error target, this will cause more problems.
(Error can trigger unexpected actions. Perhaps integrity error
can work here, but we do not have such DM target yet.)

We use zero mapping segments for Bitlocker (where it covers metadata area,
or fake NTFS files tat maps to underlying metadata) - use exactly the same approach.

See Vojta's talk https://vtrefny.fedorapeople.org/misc/devconf-bitlocker.pdf
(and bitlk code). I think you are solving exactly the same problem here.

>> Relocation area - is a contiguous sequence of sectors where the first 2048
>> bytes of partition are stored.
>>
>> Currently there are two methods of placement of this area that are being used: in $dcsys$ file, or at the end of partition. On encryption of partition that has data on it, this area is being placed in $dcsys$ file [its name contains the dollar signs] , which is located in a contiguous sequence of clusters. On formatting a new partition, this area is being placed at the end of partition, after user data.

See above. For existing systems it can be masked/reallocated the same way as in bitlk code.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[Mateusz Jończyk]

W dniu 01.11.2021 o 11:55, Milan Broz pisze:

> Hi,
>
> On 31/10/2021 23:36, Mateusz Jończyk wrote:
>> Hello,
>>
>> Back in June, I wrote to the mailing list seeking some help with
>> reverse-engineering the DiskCryptor volume format [1].
>>
>> Since then, I have implemented decryption of the volume header (for all
>> cipher combinations, with autodetection) and would like to know whether
>> you would be interested in merging support for opening DiskCryptor
>> volumes once it is ready.
>>
>> The DiskCryptor development has largely stalled, with the last beta
>> release in April 2020. Releases by DavidXanatos have the following
>> problem [3]:
>>
>>>         The Disk Cryptor driver needed to be updated, and since the
>>>         ReactOS foundation no longer offer a driver signing service, I
>>>         head to use a leaked code signing certificate I found laying
>>>         around the Internets. This means some anti malware applications
>>>         may wrongfully flag it as potentially dangerous.
> How much is DiskCryptor used in reality? The note above would qualify
> it as a regular malware for me I would like to have support for various formats, but the line where
> it becomes bloatware is very thin...
>
> Anyway, if
>  - code is licensed under LGPL (no new GPL-only code in libcryptsetup)

Yup

>  - it only allows to open existing formats (no code to modify metadata;
>    our primary format is LUKS and it will stay this way)

OK

>  - it does not add complicated dependences
>    (I think we should care about memory footprint more now)

that's correct (it won't add any external dependencies).

> then the best is perhaps open merge request (or issue) on the project
> page and discuss it there.
> (For now, the code looks simple enough.)

You mean open now, or once the code is ready?

> What is missing to more "stable" code? Only the parts marked TODO,
> or something crucial for format parsing?

The major parts missing in the code I posted:

- setting up mapping in the device mapper,

- libcryptsetup: support for *dm_error_target_set()* that would be
similar to *dm_zero_target_set()* to create a region in the block
device that errors out reads and writes. This is necessary as sometimes
the first 2048 bytes of the encrypted filesystem are relocated to another
place in the image ( https://diskcryptor.org/volume/ ):

> Relocation area - is a contiguous sequence of sectors where the first 2048
> bytes of partition are stored.
>
> Currently there are two methods of placement of this area that are being used: in $dcsys$ file, or at the end of partition. On encryption of partition that has data on it, this area is being placed in $dcsys$ file [its name contains the dollar signs] , which is located in a contiguous sequence of clusters. On formatting a new partition, this area is being placed at the end of partition, after user data.
>
> In order to protect the $dcsys$ file from being deleted, fragmented or moved, its access is forbidden by the driver.

It will be necessary to just inform the user not to delete the $dcsys$
file as there is no other workable way to protect it.

- some boilerplate in lib/setup.c and src/cryptsetup.c (and perhaps
some code to require a confirmation about the $dcsys$ file from the user).

- documentation,

- tests,

- unlocking with keyfiles (should not be complicated).


I have rebased the code on cryptsetup v2.4.1 and did some further
development (began work on devicemapper setup). It can be found on a new branch:

https://github.com/matjon/cryptsetup/tree/dcryptor_support_on_2.4.1/lib/dcryptor

> Thanks,
> Milan

Greetings,

Mateusz


_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: [RFC] Partial support for reading DiskCryptor volumes

[Milan Broz]

Hi,

On 31/10/2021 23:36, Mateusz Jończyk wrote:
> Hello,
> 
> Back in June, I wrote to the mailing list seeking some help with
> reverse-engineering the DiskCryptor volume format [1].
> 
> Since then, I have implemented decryption of the volume header (for all
> cipher combinations, with autodetection) and would like to know whether
> you would be interested in merging support for opening DiskCryptor
> volumes once it is ready.
> 
> The DiskCryptor development has largely stalled, with the last beta
> release in April 2020. Releases by DavidXanatos have the following
> problem [3]:
> 
>>         The Disk Cryptor driver needed to be updated, and since the
>>         ReactOS foundation no longer offer a driver signing service, I
>>         head to use a leaked code signing certificate I found laying
>>         around the Internets. This means some anti malware applications
>>         may wrongfully flag it as potentially dangerous.

How much is DiskCryptor used in reality? The note above would qualify
it as a regular malware for me :-)


I would like to have support for various formats, but the line where
it becomes bloatware is very thin...

Anyway, if
  - code is licensed under LGPL (no new GPL-only code in libcryptsetup)
  - it only allows to open existing formats (no code to modify metadata;
    our primary format is LUKS and it will stay this way)
  - it does not add complicated dependences
    (I think we should care about memory footprint more now)

then the best is perhaps open merge request (or issue) on the project
page and discuss it there.

(For now, the code looks simple enough.)

What is missing to more "stable" code? Only the parts marked TODO,
or something crucial for format parsing?


Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de