Jump to content











Photo
- - - - -

ImDisk accessing remote volume with SystemRescueCd/DevIo


  • Please log in to reply
9 replies to this topic

#1 sjevtic

sjevtic
  • Members
  • 4 posts
  •  
    United States

Posted 22 December 2016 - 08:09 PM

I booted a Windows 7 machine via SystemRescueCd 4.8.1.  I was interested accessing my data volume remotely from my laptop with ImDisk 2.0.9 using DevIo 3.04.  Here are some details about the volume on the disk I want to access:

 

root@sysresccd /mnt/stuff % fdisk -l /dev/sdb
Disk /dev/sdb: 7.3 TiB, 7988628684800 bytes, 15602790400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D05A6B72-771C-4272-9464-5C7D1F96BD8C
 
Device      Start         End     Sectors  Size Type
/dev/sdb1      34      262177      262144  128M Microsoft reserved
/dev/sdb2  264192 15602788351 15602524160  7.3T Microsoft basic data
root@sysresccd /mnt/dpl8419g % 
 
So, I tried getting DevIo going.  This seemed like a suitable command:
 
root@sysresccd /tmp % ./devio_Linux_i686 -r 666 /dev/sdb2 15602524160 0 1 2091752
Successfully opened '/dev/sdb2'.
Image size used: 7988492369920 bytes.
Total size: -146800640 bytes. Using 7988492369920 bytes from offset 0.
Required alignment: 1 bytes.
Buffer size: 2091752 bytes.
Waiting for connection on port 666. Press Ctrl+C to cancel.
 
Then on my laptop I tried to start ImDisk:
 
C:\>imdisk -a -t proxy -o ip -f 10.0.194.101:666 -m Z:
Creating device...
Created device 1: Z: -> 10.0.194.101:666
Notifying applications...
Done.
 
And before I knew it, I got this output from DevIo:
 
Got connection from 10.0.194.19:51062.
Connection closed.
Image close result: 0
 
I also tried starting DevIo like this:
 
root@sysresccd /tmp % ./devio_Linux_i686 -r 666 /dev/sdb 15602524160 264192 1 2097152
Successfully opened '/dev/sdb'.
Image size used: 7988492369920 bytes.
Total size: -146800640 bytes. Using 7988492369920 bytes from offset 135266304.
Required alignment: 1 bytes.
Buffer size: 2097152 bytes.
Waiting for connection on port 666. Press Ctrl+C to cancel.
 
But once again, as soon as I started ImDisk, the result was the same.
 
What am I doing wrong?  The negative "total size" value definitely seems odd.
 
Thanks.
 
Sasha
 
 


#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1338 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 22 December 2016 - 08:25 PM

It indeed looks strange. I could check later if there is some mistake with variable sizes etc around there. Could you try meanwhile to manually specify size and offset of the partition at the imdisk.exe command lune. That is, add -s and -b switches to imdisk.exe command line instead of devio command line.

#3 sjevtic

sjevtic
  • Members
  • 4 posts
  •  
    United States

Posted 22 December 2016 - 09:19 PM

I tried starting DevIo like this:

 

root@sysresccd /tmp % ./devio_Linux_i686 -r 666 /dev/sdb
Successfully opened '/dev/sdb'.
Detected a master boot record at sector 0.
Using partition 1.
Total size: 0 bytes. Using 18446744073709551104 bytes from offset 512.
Required alignment: 1 bytes.
Buffer size: 2097152 bytes.
Waiting for connection on port 666. Press Ctrl+C to cancel.
 
Then I started ImDisk like this:
 
C:\>imdisk -a -t proxy -o ip -f 10.0.194.101:666 -m Z: -b 264192 -s 15602524160
Creating device...
Created device 0: Z: -> 10.0.194.101:666
Notifying applications...
Done.
 
Things seemed okay. But then:
 
C:\>dir Z:
The volume does not contain a recognized file system.
Please make sure that all required file system drivers are loaded and that the volume is not corrupted.
 
The NTFS filesystem is definitely good.
 
I thought it was interesting that DevIo made mention of offset 512, so I also tried this:
 
imdisk -a -t proxy -o ip -f 10.0.194.101:666 -m Z: -b 264191 -s 15602524160
 
But I ended up with the same situation.
 
Thanks.
 
Sasha
 
P.S.  As an aside, is there a DevIo proxy for reading/writing ntfsclone's "special image format"?  This would be mighty useful!


#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13497 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 December 2016 - 10:25 AM

This seems fine:
C:\>imdisk -a -t proxy -o ip -f 10.0.194.101:666 -m Z: -b 264192 -s 15602524160

 

The issue with "automatic" commands may be connected with the GPT style of the disk.

 

But what happens if after issuing the above command you open a hex/disk viewer/editor and open frst sector of volume Z:?

Is it the actual bootsector?

EB 52 90 ... NTFS

 

:duff:

Wonko



#5 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1338 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 23 December 2016 - 12:32 PM

The GPT idea sounds interesting Wonko. I have seen similar problems with GPT in the past when I think about it. Devio only sees the "MBR" sector and the protection partition which has nothing to do with actual GPT partition offsets or sizes.

One idea here could be to use Arsenal Image Mounter at the client to expose the entire disk there. That would require manually specifying zeros as offset etc to devio and then manually specifying the exact disk size with -s switch to aim_ll command line (no offset). But in my experience this works very well.

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13497 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 December 2016 - 01:15 PM

The offset "34" for the first (MSR) partition is "unusual", usually the first partition is on 2048 on *anything* partitioned under *any* Windows OS, *maybe* *something* assumes that no less than 63 sectors should be between the MBR (protective or not) and the first partition?

 

The represented value of 34 is the bare minimum as you have 1 sector for the MBR, 1 for the main GPT, and 32 sectors (with four entries each) for the 128 possible partiton entries.

 

The "protective MBR" addresses always starts from sector CHS 2/LBA 1, but if the right offset are specified manually that shouldn't matter.

 

:duff:

Wonko



#7 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1338 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 23 December 2016 - 01:36 PM

I don't think we can trust the values printed by devio here. They are obviously not correct, there are for example negative values where such are not expected. Hopefully the variables actually have correct values when the application runs and that this problem only has to do with formatting the values when printing them to the console. For example printing 64 bit values to 32 bit positions which will cause field values to shift to other positions and parts of variable values printed in the wrong places.

#8 sjevtic

sjevtic
  • Members
  • 4 posts
  •  
    United States

Posted 23 December 2016 - 02:21 PM

This seems fine:
C:\>imdisk -a -t proxy -o ip -f 10.0.194.101:666 -m Z: -b 264192 -s 15602524160

 

The issue with "automatic" commands may be connected with the GPT style of the disk.

 

But what happens if after issuing the above command you open a hex/disk viewer/editor and open frst sector of volume Z:?

Is it the actual bootsector?

EB 52 90 ... NTFS

 

:duff:

Wonko

When I do this, I don't even have an option to open the drive in HxD:

 

 hxd_fail.png

 

Yet when I open an image normally in ImDisk, it shows up in this menu, and sector 0 begins just as described.

 

So, I'm pretty sure I'm not really "looking" at the right thing.

 

Sasha



#9 sjevtic

sjevtic
  • Members
  • 4 posts
  •  
    United States

Posted 23 December 2016 - 02:28 PM

I don't think we can trust the values printed by devio here. They are obviously not correct, there are for example negative values where such are not expected. Hopefully the variables actually have correct values when the application runs and that this problem only has to do with formatting the values when printing them to the console. For example printing 64 bit values to 32 bit positions which will cause field values to shift to other positions and parts of variable values printed in the wrong places.

I've made such mistakes in my own code before.  But of course the other question here is are the command line arguments being parsed correctly.

 

Sasha



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13497 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 December 2016 - 04:11 PM

Well, if can dir Z:, it should mean that *something* is mounted :unsure:, otherwise you should have an error *like* "cannot find specified path".

It is possible that HxD uses the mount manager (an IMDISK volume is transparent to it) or *whatever*.

 

Do another thing.

When you have :

 

 

Creating device...
Created device 0: Z: -> 10.0.194.101:666
Notifying applications...
Done.

Run:

dsfo \\.\z: 0 512 C:\mysector0.bin

 

Then try opening the C:\mysector0.bin in HxD.

 

 

Get dsfo from the dsfok toolkit here:
http://members.ozema...eezip/freeware/

or here:
http://www.softpedia...ery/dsfok.shtml

 

Or use a Windows port of dd.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users