0

I encrypted a disk using cryptsetup. I want to be able to visualize that a known text before encrypting the disk became gibberish after encrypting.

How do I do such comparison?

Here's an example for the best scenario:

In a decrypted disk, assume I make a text file that has the word "test string" inside it. I will somehow be able to visualize "test string" before encryption, and then after encryption, visualize that the "test string" became gibberish. I would want to use the same methods to visualize "test string" and the gibberish so that I can be sure that it's "test string" that became gibberish. If it means I have to find "test string" in hex, then so be it. I just need to be able to see that there's "test string" and then "test string" is nowhere to be found (and instead there are other gibberish).

Any idea what kind of methods I should use to probe the disk to find "test string"?

closed as unclear what you're asking by Michael Homer, Archemar, GAD3R, countermode, techraf Nov 11 '16 at 11:14

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What level of "proof" are you requiring? – Michael Homer Nov 11 '16 at 8:07
  • Ideally, be able to visualize that a known data inside the disk became gibberish. For example, if I made a text file that has the word "foo" inside it, I will somehow need to be able to read "foo" before encryption, and then after encryption, visualize that the "foo" became gibberish. – CuriousKimchi Nov 11 '16 at 8:16
  • What you've described doesn't sound much like proving anything is encrypted. Fragmentation could do that, UTF-32 could do that, malice could do that, etc. – Michael Homer Nov 11 '16 at 8:33
  • Is that "prove that this data is statistically indistinguishable from random", "show that this part of the logical disk contains the data corresponding to a given file", "show that a known plaintext string is not anywhere on the device", all of the above, or what? – Michael Homer Nov 11 '16 at 8:34
  • While ideally all of the above, currently I'm only looking for ways to do "show that this part of the logical disk contains the data corresponding to a given file" and "show that a known plaintext string is not anywhere on the device". Yes, you are right that this doesn't prove encryption, and so I worded the question wrong. But, that's where I'd like to start. – CuriousKimchi Nov 11 '16 at 8:37
4

For example, consider the server I work on. The hard disk has a small /boot partition, /dev/sda1, which is by necessity not encrypted, and a large encrypted partition, /dev/sda2, which hosts a LUKS container, which, when opened by cryptsetup automatically at boot after entering the passphrase, appears as /dev/mapper/Serverax. In the container there is a LVM physical volume, on which lives a LVM volume group; the volume group contains the logical volumes Root, Home, Srv and Swap.

$ lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                   8:0    0   20G  0 disk  
├─sda1                8:1    0  294M  0 part  /boot
└─sda2                8:2    0 19.7G  0 part  
  └─Serverax        252:0    0 19.7G  0 crypt 
    ├─Serverax-Root 252:1    0 10.7G  0 lvm   /
    ├─Serverax-Swap 252:2    0    1G  0 lvm   [SWAP]
    ├─Serverax-Srv  252:3    0    6G  0 lvm   /srv
    └─Serverax-Home 252:4    0    2G  0 lvm   /home

To see the raw data on the disk, read some blocks directly from /dev/sda2. In the example, the skip=$((2*1024)) skips over the 2 MiB LUKS header, and lands in the LVM header:

$ sudo dd if=/dev/sda2 bs=1K count=1 skip=$((2*1024)) 2>/dev/null | hd
00000000  33 b2 f7 1b 03 ce a6 3a  87 b4 03 98 7d a7 b1 cc  |3......:....}...|
00000010  1a c9 99 80 01 19 c0 db  f0 54 a7 4c 1c 2b 9c ea  |.........T.L.+..|
00000020  f3 84 b0 d8 0c 54 c0 fe  ec c0 06 a8 8c c0 6b 10  |.....T........k.|
...
00000200  d4 0b 67 3b ba d1 21 06  58 ce 84 b4 3b 3b e0 f2  |..g;..!.X...;;..|
00000210  4d eb 99 d3 15 63 81 f3  92 b7 ff c2 17 95 ed b3  |M....c..........|
00000220  92 51 ab dc 29 84 9b 6f  68 cc a9 fe 35 cd e0 08  |.Q..)..oh...5...|
00000230  1f d1 e0 52 34 46 13 90  38 c4 3d 18 30 1a 1d c8  |...R4F..8.=.0...|
00000240  1c 05 2f 17 0b ad 39 6f  56 9c 28 71 e3 f7 78 10  |../...9oV.(q..x.|
00000250  97 09 cb 49 50 f5 b1 06  a1 8a e0 4d 7a 0e 39 94  |...IP......Mz.9.|
00000260  15 2d 05 b5 94 75 c0 a2  d1 bf 78 3d ba 30 06 61  |.-...u....x=.0.a|
00000270  e6 82 8d 4a 60 90 81 e7  0a 34 5a f8 03 fc a6 89  |...J`....4Z.....|
00000280  12 11 19 b2 2b 44 9b 0a  07 c1 40 d9 4b df bd 54  |....+D....@.K..T|
00000290  0a 40 2b 4f 1f 55 f5 e2  fa 10 41 3b f9 58 5a 2f  |.@+O.U....A;.XZ/|
...

The same data, decrypted, can be read from /dev/mapper/Serverax; note that this time there is no skip=:

$ sudo dd if=/dev/mapper/Serverax bs=1K count=1 2>/dev/null | hd
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000210  be af fb 35 20 00 00 00  4c 56 4d 32 20 30 30 31  |...5 ...LVM2 001|
00000220  47 41 70 58 43 62 74 55  65 6b 33 41 6b 53 54 73  |GApXCbtUek3AkSTs|
00000230  4f 6b 6a 49 49 72 6e 53  66 54 41 77 6e 31 53 6e  |OkjIIrnSfTAwn1Sn|
00000240  00 00 60 ed 04 00 00 00  00 00 20 00 00 00 00 00  |..`....... .....|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000270  00 f0 1f 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000280  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00000290  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400
  • wow that's exactly what I need! One random question though, hd doesn't seem to exist on centos. Is that true? – CuriousKimchi Nov 11 '16 at 9:03
  • You mean /dev/hd*? Previously some disk interfaces (traditionally IDE/PATA) used /dev/hd* and others (traditionally SCSI but latterly SATA) used /dev/sd*. Then the drivers for IDE/PATA were deprecated and IDE support was added to the SATA drivers, so distros switched to using the SATA drivers for all disks, and so /dev/sd* became the norm. Nowadays of course everyone has SATA, so /dev/sd* is still very common. There are probably some exotic pieces of hardware that would still get assigned to /dev/hd* though. And of course non-Linux OSes will do other things. – Muzer Nov 11 '16 at 9:08
  • no i mean the "hd" command that he uses in his answer – CuriousKimchi Nov 11 '16 at 9:18
  • oh maybe "hd" is his alias to hexdump – CuriousKimchi Nov 11 '16 at 9:23
  • hd and hexdump can be emulated by od. Instead of hd say ` od -Ax -tx1z. – AlexP Nov 11 '16 at 9:24
0

To see the encrypted data, just read from the raw device, on Linux that's typically /dev/sdX (for some X).

An example from my box:

grove@mary> ll /dev/mapper/luks_crypto_*
lrwxrwxrwx 1 root root 7 nov  7 08:32 /dev/mapper/luks_crypto_58cf05c2-a296-46ff-80f4-70476ee06ae0 -> ../dm-3
lrwxrwxrwx 1 root root 7 nov  7 08:32 /dev/mapper/luks_crypto_ff052855-76f5-48cd-bf11-e4af60126484 -> ../dm-2
grove@mary> ll /dev/disk/by-uuid/ff052855-76f5-48cd-bf11-e4af60126484
lrwxrwxrwx 1 root root 9 nov  7 08:32 /dev/disk/by-uuid/ff052855-76f5-48cd-bf11-e4af60126484 -> ../../sdg
grove@mary> sudo file -s /dev/dm-2
/dev/dm-2: Linux rev 1.0 ext4 filesystem data, UUID=e33a9842-a597-4311-a37b-10adfca1eabd (needs journal recovery) (extents) (large files) (huge files)
grove@mary> sudo file -s /dev/sdg
/dev/sdg: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: ff052855-76f5-48cd-bf11-e4af60126484
  • Im still confused. Your example doesn't show any gibberish data. – CuriousKimchi Nov 11 '16 at 8:09
  • If you want to see gibberish just read some data from the raw device (/dev/sdg in my example), and compare to data read from the luks device (/dev/dm-2 in my example) - but note that there's the header file recognises at the start of the raw device, so you'll need to find out how large that is before you'll know what to compare, and depending on your data they may look like gibberish too (e.g. images). – Henrik Nov 11 '16 at 9:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.