Solved Raw access to block devices?

C

canihazsekooriti

How can I raw read block devices? I tried nano /dev/md0(.eli) (or ada0pN(.eli)) and hexedit /dev/md0, and I just got an error that it's a device file or an empty hex space. In Linux I can use both of those methods to raw read such devices (which may or may not be a bad thing security-wise).
 
Special files tend to get their contents changed in real time by the operating system because they contain things like swap space and file systems. However, there is no technical problem reading a special file, provided you have permission, and choose an appropriate method.

If you tell us what you are trying to achieve, somebody may be able to suggest a plausible approach.
 
gpw928 said:
Special files tend to get their contents changed in real time by the operating system because they contain things like swap space and file systems. However, there is no technical problem reading a special file, provided you have permission, and choose an appropriate method.

If you tell us what you are trying to achieve, somebody may be able to suggest a plausible approach.
Click to expand...
Obviously, they are not static. Viewing a snapshot is just fine. So, how do I view raw contents of a block device? I thought I already asked this in this thread. It's just for purely educational purposes...for example, to examine how geli lays out the first sectors of a drive.
 
Does your /dev/ada0pN.eli really exist, and is a device? The output from ls -l for it should look roughly like this:
crw-r----- 1 root operator 0x98 Mar 24 13:55 /dev/ada2p1

The "c" in the first place is important, it identifies it as a character device. Also check the permissions on the device, to make sure your current process can read the device.
 
ralphbsz said:
Does your /dev/ada0pN.eli really exist, and is a device? The output from ls -l for it should look roughly like this:
crw-r----- 1 root operator 0x98 Mar 24 13:55 /dev/ada2p1

The "c" in the first place is important, it identifies it as a character device. Also check the permissions on the device, to make sure your current process can read the device.
Click to expand...
/dev/ada0p3.eli exitsts and is a device; ls -l looks like what you posted (including permissions).
I ran 'dd if=/dev/ada0p3.eli of=tempfile count=10' as root (sudo -s), and it's giving me 0 bytes, and dd: /dev/ada0p3.eli: invalid argument.
(Any .eli device gives this error)
 
First suggestion: Maybe geli is designed to only read full blocks. Try the same command, but with bs=512 or bs=4096.

If that doesn't work right away, I suspect the problem is the geli configuration.
 
ralphbsz said:
First suggestion: Maybe geli is designed to only read full blocks. Try the same command, but with bs=512 or bs=4096.
Click to expand...

dd default is bs=512. OP could try 4096, but shouldn't expect dumping an .eli device to reveal its encrypted content.

I suggest first trying it on the raw (non .eli) device, without expecting decryption.

ralphbsz said:
If that doesn't work right away, I suspect the problem is the geli configuration.
Click to expand...

Can't comment, never used it.

Might help if OP showed rather than telling?
 
smithi said:
dd default is bs=512. OP could try 4096
Click to expand...
Good point smithi !
Just like a CDROM cannot be read without bs=2048, the geli device might not be readable unless giving the correct blocksize - which can be retrieved like so:

Code: 
# geli list ada6p9.eli
[...]
Providers:
1. Name: ada6p9.eli
   Mediasize: 458629099520 (427G)
   Sectorsize: 4096
   Mode: r6w6e12
 
As suggested above, GELI wants 4K blocks:
Code: 
[gunsynd.894] $ su
Password:

[gunsynd.129] # dd if=/dev/vtbd0p2.eli of=/tmp/swapdump count=1
dd: /dev/vtbd0p2.eli: Invalid argument
0+0 records in
0+0 records out
0 bytes transferred in 0.000246 secs (0 bytes/sec)

[gunsynd.130] # dd if=/dev/vtbd0p2.eli bs=4096 of=/tmp/swapdump count=1
1+0 records in
1+0 records out
4096 bytes transferred in 0.001028 secs (3986247 bytes/sec)
 
It seems likely to me that GELI defaults to a 4K sector size, even when the underlying device has 512 byte sectors. My encrypted swap was made using all the defaults (by adding ".eli" to the swap partition named in /etc/fstab):
Code: 
[gunsynd.138] # geli list
Geom name: vtbd0p2.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 128
Crypto: accelerated software
Version: 7
Flags: ONETIME, W-DETACH, W-OPEN, AUTORESIZE
KeysAllocated: 1
KeysTotal: 1
Providers:
1. Name: vtbd0p2.eli
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 4096
   Mode: r1w1e0
Consumers:
1. Name: vtbd0p2
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r1w1e1
 
gpw928 said:
It seems likely to me that GELI defaults to a 4K sector size
Click to expand...
Yes, that is what I was wondering - so if the OP had done geli init with a different sector size (i.e. not sticking with the default), your suggestion to use a block size of 4096 might then not work, because it will need the same block size in dd as the sector size used in geli init. But just an idle thought on my part as opposed to any knowledge or experience!
 
You must log in or register to reply here.
Back
Top