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@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
