Jump to content











Photo
* * * * * 1 votes

Imdisk proxy type mount can't work with WinHEX


  • Please log in to reply
4 replies to this topic

#1 taursw_wang

taursw_wang
  • Members
  • 3 posts
  •  
    China

Posted 08 March 2008 - 11:57 AM

This is the trobule i have encount. Let't me describle it.

First, establish the socket server using the devio.exe program.

C:\ImDisk>devio -r 9000 c:\30.dd 0B 32256B

Second, mount the first partition of image to the driver letter T:

C:\ImDisk>imdisk.exe -a -t proxy -o ip -f 127.0.0.1:9000 -m T:
The ImDisk Virtual Disk Driver Helper Service was started.
Created device 0: T: -> 127.0.0.1:9000

OK, T: Driver seems can be access property by the Windows Explore.
But WinHex can't access the T: Driver. :)

Here is the test code I've wrotten for test.


int wmain(int argc,wchar_t* argv[])
{
//compare the to driver sector by sector
wchar_t mount_point[] = L"\\\\.\\T:";

DWORD gotbytes=0;
HANDLE h = CreateFile(mount_point, GENERIC_READ,FILE_SHARE_READ | FILE_SHARE_WRITE,NULL,
OPEN_EXISTING, FILE_FLAG_NO_BUFFERING | FILE_FLAG_SEQUENTIAL_SCAN, NULL);
//FlushFileBuffers(h);

DISK_GEOMETRY_EX geometry_ex; // imdisk doestn't handle this , it won't work!
if (DeviceIoControl( h, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX, NULL, 0,
&geometry_ex, sizeof(geometry_ex), &gotbytes, NULL))
{
my_DbgPrint(L"disk_get_geometry_win32(%s) IOCTL_DISK_GET_DRIVE_GEOMETRY_EX ok\n",mount_point);
my_DbgPrint(L"CHS (%u, %u, %u), sector_size=%u\n", geometry_ex.Geometry.Cylinders.QuadPart-1,
geometry_ex.Geometry.TracksPerCylinder-1, geometry_ex.Geometry.SectorsPerTrack, geometry_ex.Geometry.BytesPerSector);

}

BYTE sector[512];
DWORD bread = 0;

ReadFile(h,&sector[0],512,&bread,NULL); // i don't know why it's can't work!


memset(sector,0,512);

ReadFile(h,&sector[0],512,&bread,NULL);
// get LastError return the value is @err,hr 0x00000057
CloseHandle(h);

return 0;
}

#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 08 March 2008 - 06:44 PM

About this "Raw reading fails on proxy-disks" bug
That was a kind of strange bug you have found... :( ...and it seem to occur only for proxy-type virtual disks. I will definitley take a look at this and see what on earth is happening here...

About DISK_GEOMETRY_EX support
This IOCTL and a couple of other "modern" ones are currenlty not supported. It should not be needed since it is not required for disk devices, applications and file-system drivers should fall-back to the old DISK_GEOMETRY request if DISK_GEOMETRY_EX is not supported and that seems to work with everything I have came across so far. If DISK_GEOMETRY_EX still seems to be needed for something, please tell me. :)

#3 taursw_wang

taursw_wang
  • Members
  • 3 posts
  •  
    China

Posted 09 March 2008 - 02:00 PM

Thank you.

And I also found proxy-disks can't be mounted when NOD32 is runing. This can proved by the WinDgb output string or DbgView output string. DbgView just inform that Nod32 Antivirus will cause the IOCTL_IMDISK_REFERENCE_HANDLE request failed. NOD32 protect the \Device\Afd\Endpoint sockets object.
So I just modify the devio, using named pipe service rather socket service.
When the Imdisk NT Helper Service received the connection request. It will replace the Target Proxy Device with the named pipe client Handle, rather than stocke client Handle.
So the Overlapped read and write is deal with the Named Pipe, just like Imdisk NT Helper Service handle the connection request.
It works fine when the Nod32 is running. :)
But the consequence is named pipe just can run at WIN32 platform not other *nix platform.

And for the raw reading proxy-disk, i still no idea what's cause that kind of way read faild.

Most people can't debug the windows by source code line by line.
If we can got the windows source code. Maybe spend some hours can location the problem and fix it.
But I have no idea about it. :(
So has anyone can give me some clue ?

#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 09 March 2008 - 02:57 PM

Problem seems to be related to the AlignmentRequirement field in the device objects. ImDisk sets this flag to the alignment requirement of the image file used, or just FILE_BYTE_ALIGNMENT for virtual memory disks. For proxy-type disks this is set by devio, by default to FILE_512_BYTE_ALIGNMENT and this seems to be the problem. When devio reports 1 as required alignment it works. The alignment can be set using the fifth parameter to devio but there was a bug in devio causing it to misinterprete the command line, but that is fixed now, download http://www.ltr-data.se/files/devio.exe and use this command line:
devio -r 9000 c:\30.dd 0B 32256B 1
The reason devio sets the alignment to 512 bytes by default is that it seems to be needed when devio is using a raw device object under FreeBSD (and possibly also under Linux, have not checked that though).

About the NOD32 issue
The IOCTL_IMDISK_REFERENCE_HANDLE is a quite ugly trick to make a user-mode service initialize communication for the driver and I can understand that it is looking suspicious in the eyes of an antivirus application. If you have rewritten a version of devio to use named pipes you can skip the helper service entirely and use this syntax:
imdisk -a -t proxy -f \\.\pipe\your_named_pipe -m T:
Note that we have skipped out -o ip here and are using the named pipe directly.

#5 taursw_wang

taursw_wang
  • Members
  • 3 posts
  •  
    China

Posted 10 March 2008 - 04:34 AM

Great!
Thank u. !
This problem has beem sovled!
Thank u for the great job!
:cheers:
:cheers:
:)
:cheers:
:(




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users