Mount encrypted disk on other Linux maschine

[keros1]

Hi

I have an TS-869L (Firmware Version 4.0.2).

I have just played with the encryption option of one disk.
On the web interface I have created an encrypted disk on the whole disk.

After that I have unplugged the disk and plugged it into an debian 7 system.
The disk in my system is shown as "sdc" and sdc3 is the encrypted partition.

So I tried the following:

Code: Select all

cryptsetup luksOpen /dev/sdc3 encdisk
Enter Password: 
... failed

I have tried the same password that I have set on the web interface.
But does not work.
After that I see the option for downloading an keyfile on the web interface.
I downloaded it (took ages for for 256k -.-) and tried it out

Code: Select all

cryptsetup luksOpen /dev/sdc3 encdisk --key-file=/tmp/mykey.key
... failed

Does also not work.
Looks like qnap does some obfuscating with the password and the keyfiles.

I need to know what I have to do that I can mount the encrypted volume on other systems.
I think a snipped of the obfuscating code would be enough.

keros

[keros1]

push

[keros1]

push again ...

[keros1]

does nobody know how the magic happens?

[glacier]

Unfortunately, QNap's documentation is garbage...

Maybe you have more luck using LVM and dm-crypt (instead of luks).

[glacier]

It does seem to be the case that luks1 is used though.

[keros1]

luks is a extension for dm-crypt.

To use such partitions:
dm-crypt luksOpen ...

Qnap uses the luks extension (luks header and everything else is on the harddisk).

The really funny thing is when I create a luks partition on a Linux system and put it into the Qnap machine it works.
So their mount script tries different ways how to use the password.

Our workaround is now to initialize the disc by hand and put it into the Qnap device.
But it ** really hard that Qnap breaks compatibility on things that are normally perfect compatible.

It makes absolute no sense for me why Qnap has done this.
It can't be an security feature and I really hope nobody of the Qnap staff thinks so. Security by obscurity does NOT work. It only makes the live of normal users harder.

keros

[crmccluskey]

Was there any conclusion to mounting an encrypted disk initialized in QNAP outside of the QNAP?

I have validated that the drive is LUKS-based (on the header on the first part of the partition), and can do a dump of the LUKS header -- I see a single key setup in LUKS -- which I'm confident is the one I need to access.

From this post: http://forum.qnap.com/viewtopic.php?f=11&t=18863, It looks like it should be a simple MD5 hash with a specific salt and the passphrase. However, when I try to do this I get the error message "No key available with this passphrase". This suggests that there is more than just the passphrase required to unlock the key.

Any more ideas?

[Bjorn Stronginthearm]

I just had this problem and my solution was, that my passphrase was longer than 16 chars. So after I used only the first 16 chars the above method worked and I can access my files.

On related news: absolute dick move Qnap, 16 chars is not enough.

[doktornotor]

I just had this problem and my solution was, that my passphrase was longer than 16 chars. So after I used only the first 16 chars the above method worked and I can access my files.
On related news: absolute dick move Qnap, 16 chars is not enough.

Is this for real?!? Can someone verify this? The SNAFU with the backdoor has not been enough?!?

[SeparateReality]

I can verify!
Ran into the same problem and searched for hours until stumbling over this post.
Then the inglorious solution: Using only the first 16 chars of the pass works just fine!

WTF. Fortunately we moved away from QNAP anyway (exactly because of such sh... software and support!). Foolishly we still have some leftovers...

[dolbyman]

thanks for digging up this old thread..but I think that character limit was fixed a couple of versions ago..so you must have ran outdated firmware

[NASUSer1200]

thanks for digging up this old thread..but I think that character limit was fixed a couple of versions ago..so you must have ran outdated firmware

It has not been fixed yet! I can confirm it with Firmware 4.3.3.0262 (2017/07/27 - TS-421). In this case digging up the thread was very helpful.

I can verify!
Ran into the same problem and searched for hours until stumbling over this post.
Then the inglorious solution: Using only the first 16 chars of the pass works just fine!

WTF. Fortunately we moved away from QNAP anyway (exactly because of such sh... software and support!). Foolishly we still have some leftovers...

I am looking for a solution for over a year, that helps me a lot. Thank you

[mdt390]

Hello everyone, which command did you use:
cryptsetup luksOpen /dev/sdc3 encdis
or
cryptsetup luksOpen /dev/sdc3 encdisk --key-file=/tmp/mykey.key
?
In my case I have no key, just the password.
Thank you!

[dolbyman]

with new firmwares and lvm probably futile