just need some help on eject a USB ext hhd from a vfp application

[Ernesto_Paez]

Hello everyone,
I have two external usb 3.0 hhd connected to a server OS WIN 2008 SERVER STANDARD R2 64BIT, for backup.

so i use one to backup some days of the week and switch manually to the other for the other days of the week, so, what i do, i disconnect manually one of the hhd, when it is not needed to backup.

so i want to avoid in case of a Ransom-ware, get into the server and also hit the ext hhds, i would like to know of anything that i can do after the backup is done to eject the ext hhd in place, this way in case of any attack, then, it will not spread out to the backup that is contained in that ext hhd if it is ejected, now if there is an auto way to bring that one already ejected back online again, that will great, otherwise, will have to do it manually.

Any suggestions or any exsiting VFP routine, that use WMI ?
Thanks in advance

 

[GriffMG]

Well, your approach seems very sensible, but I suspect the coding is harder than you imagine.

That said there are one or two free command line utilities that would do the job, one is here:

https://www.raymond.cc/blog/download/did/3810/

can't speak for it myself...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

There is some code in c++ that would give you an idea how to use a WIN API to do it

http://forums.codeguru.com/showthread.php?281916-disconnect-usb-mass-storage-device

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

I'm not very knowledgeable in this area, but I wonder if ejecting the drive is going to solve the problem. Is it not possible to write code that will write to the drive while it is still physically present, even though you have gone through the motions of ejecting it? Clearly, you can't do that from the command prompt (because the drive will not be recognised), but I feel sure there must be some low-level API functions that will let you do that.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I think the ransomware stuff doesn't look to reconnect drives that are offline, just scan for 'live' ones and start encrypting asap...

So, I would imagine disconnecting it virtually should do the trick - until they start scanning for new hardware as well...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

You might well be right, Griff. Who can say what is going on in the minds of these people?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If both eject (unmount) and remount would be possible, eject would not be sufficient, would it? Ransomware could then remount the drive, too. Admitted, this would need a lot of knowledge about the drive still connected by USB wire, but it contradicts that step as safety.

To eject a USB attached drive by code should be possible, I have to search that myself.

The problem you have anyway is, that ransomware would be clever enough not to act on the infection day. The day you detect it, it would most probably already be on some backups. The strategy with two drives already is good, a best practice here is to use more drives in different frequencies. One for daily, one for weekly, one for monthly backups, for example. The monthly backup would only be infected by a very patient ransomware, so you might then also add in a yearly drive. And yes, that means the drives wear out differently fast.

I can eject media in a CD/DVD/BD drive via o.NameSpace(17).ParseName("F:\").InvokeVerb("Eject"), but that doesn't work with a USB drive.

I found this solution, but you have to execute this code elevated. For testing in the VFP IDE right click vfp9.exe and start as admin.

lcDriveLetter = "F:\"
objWMIService = Getobject('winmgmts:\\.\root\cimv2')
oDrives = objWMIService.ExecQuery('Select * From Win32_Volume')
FOR EACH oDrive IN oDrives
   if oDrive.Name=lcDriveLetter 
      oDrive.DriveLetter = .null.
      oDrive.Put_()
      oDrive.Dismount(.F., .F.)
   endif
Endfor

What needs elevated permission is to rename the drive to have no drive letter (.NULL.) Dismount doesn't work without that.

I would say there is no reverse command to Mount, because you don't get the unmounted drive from Win32_Volumes, the query only returns mounted drives.

Warning: When you remount your drive, it will still have no letter, Windows Explorer won't show it. You will need to go into Control Panel > Administrative Tools > Computer Management > Storage > Disk Management. and assign a drive letter to the drive having none. You can identify it via the volume name, most probably. But above code doesn't work to set from .null. to a certain drive letter, it errors on calling Put_().

So this is a solution, if you care to reassign a drive letter via Disk Management every day.

Bye, Olaf.

 

[GriffMG]

I just tried that code on my laptop, it does disconnect the drive, but leaves it in a form / state where the system no longer recognises it is there.

So even unplugging it and popping it back in does not bring it back on line, I'm going to try rebooting!


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Hi Griff,

sorry, I posted the warning too late, but it's solvable with Disk Management, you'll get your drive back.
Besides, the drive still is in the Win32_Volume collection and you can mount it with the Mount() method. Still after that I don't get why VFP can't reassign a drive letter.

Well, ransomware would need to interate that collection and try to mount drives to also act on those, at least the automatic Dismount is making an easy discovery harder.

I think the more usual solution would involve either a very professional SAN, where storage is in extra devices anyway, or at least having a NAS device you can schedule to shut down.

Bye, Olaf.

 

[GriffMG]

No problem Olaf, that is exactly what I had to do, rebooting didn't work - although the drive worked ok in another PC.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

>though the drive worked ok in another PC.
Yes, the drive letter is stored as info of the computer (registry), not on the drive. If you attach the same drive on different computers, the same letter might not be available anyway, so this is a computer relevant property. At least MS decided that way. I have drives mounting as one letter one one PC and as another letter on another PC. Other OSes also don't use drive letters but named mount points, so this is a Windows thing.

Bye, Olaf.

 

[Ernesto_Paez]

Olaf,
I am getting an error when executing line

FOR EACH oDrive IN oDrives

here is the error "Ole error code 0x80041010:unknown COM status code"

i ran as admin the vfp 9.0 in a Win xp pro sp3 32 bit machine and have the ext usb hhd installed with letter H:, so i change the F: by the H:

don't know why it run on Griff and not from my machine, but that will dismount the drive
what about using the removedrive F: -d application with the paramemnters in an script file and then RestartDrdev * after the backup is done, i think this will eject the drive and later restart it, as you said before, if the ransomware it is still in effect, it will probably reach the drive when it is restarted or even probably the ransomware itself will restart the drive, i think the option will be having backups to different drives on different dates as weekly or monthly, or to the Cloud but cloud it is expensive i am using Acronis backup server v12 and this one does not allow me to send to a cheaper Cloud, only to their Cloud, and they want for 4tb a year about $4500,00.

 

[Olaf Doschke]

I get such an error only, when the collection is either empty or when not running elevated.

Notice running Windows as administrative user still all process you start don't automatically run elevated. There is a big difference in just running the Windows session as admin and starting a process elevated. Even as adminstrative user you need to run VFP9.exe via the context menu option I mentioned.

Well, on XP this shouldn't matter, but on XP you might not have these WMI classes defined, see

http://stackoverflow.com/questions/...n32-mountpoint-and-win32-volume-on-windows-xp

Bye, Olaf.

 

[Olaf Doschke]

You initially talked about WIN 2008 SERVER STANDARD R2 64BIT. Win32_Volume will be available there.
You can't try this on XP, though.

Bye, Olaf.

 

[Ernesto_Paez]

you need to run VFP9.exe via the context menu option I mentioned.

Yes i did that, exactly as you said

but on XP you might not have these WMI classes defined

most likely could be the above you said
will look into that link
i did look into that link but actually, don't know what i need to do, to define this WMI CLASSES in win xp.
Thanks

 

[Ernesto_Paez]

oh ok, so i need to then create an exe file from a prg file, then run it on the server, the only thing i don't like about it, it is the fact, that we need to assign each day a drive letter to it from the disk management, but the idea to backup to a NAS it is a good thing, just that i need to find the way to shutdown the Nas in an auto way to shutdown after the backup and start it manually the next day, unless we can install a Relay, that can turn off the Nas at a particular time and start up at a particular time too

 

[Olaf Doschke]

A NAS should have a management function for scheduled shutdown, perhaps even a backup functionality with automatic shutdown after finishing backup.

What I read is QNAP NAS offer a scheduled shutdown with the option to delay while a replication job (RRTR) runs. Then this shutdown happens after the replication job finishes.

Bye, Olaf.

 

[atlopes]

I believe this will do in an XP desktop

#define ssfDRIVES 17
#define DRIVELETTER "H:"

LOCAL WShell AS Shell.Application

m.WShell = CREATEOBJECT("Shell.Application")
m.WShell.Namespace(ssfDRIVES).ParseName(DRIVELETTER).InvokeVerb("Eject")

 

[Olaf Doschke]

atlopes, yes, I had that to begin with, too. but it does not unmount volumes, you can only eject removable media, eg a CD from a CD drive, aka opening the CD tray (whether empty or not). This doesn't remove a CD drive overall, though.

In the meantime I found how to mount a drive back with its drive letter. The solution is too simple to get. You don't assign DriveLetter = 'F:\', you assign 'F:' without the backslash:

objWMIService = Getobject('winmgmts:\\.\root\cimv2')
oDrives = objWMIService.ExecQuery('Select * From Win32_Volume')
FOR EACH oDrive IN oDrives
   If oDrive.Name='F:\'
      oDrive.DriveLetter = .null.
      oDrive.Put_()
      oDrive.Dismount(.f.,.f.)
      oDrive.Mount()
      oDrive.DriveLetter = 'F:'
      oDrive.Put_()
   Endif
Endfor

Oh the inconsistency.

So you would either need to keep alive the oDrive object for later mounting or you would save another identifier to later find the drive. One such identifier is the RelPath, which includes the drive GUID.

LOCAL lcRelPath
lcRelPath = ''
objWMIService = Getobject('winmgmts:\\.\root\cimv2')
oDrives = objWMIService.ExecQuery('Select * From Win32_Volume')
FOR EACH oDrive IN oDrives
   If oDrive.Name='F:\'
      oDrive.DriveLetter = .null.
      oVolume = oDrive.Put_()
      lcRelPath = oVolume.RelPath 
      oDrive.Dismount(.f.,.f.)
      Exit
   ENDIF
ENDFOR 

RELEASE oDrives, objWMIService      
* a few hours pass by

objWMIService = Getobject('winmgmts:\\.\root\cimv2')
oDrives = objWMIService.ExecQuery('Select * From Win32_Volume')
FOR EACH oDrive IN oDrives
   If oDrive.Path_.RelPath==lcRelPath
      oDrive.Mount()
      oDrive.DriveLetter = 'F:'
      oDrive.Put_()
      Exit
   ENDIF
ENDFOR

Well, this also shows, how ransomware could find all unmounted drives and mount them, as long as they are not only known in the system and listed via the query, but also still physically attached.

In the long run I would opt for NAS, it's a separate computer, so many more things are possible, though it's obviously also vulnerable to ransomware itself, not just by storing it on its drive. But NAS devices are typically Linux and have other attack vectors. It's unlikely the same ransomware can attack both Windows and Linux. I'm sure they work on it.

Bye, Olaf.

PS: It becomes a bit more consistent again, if you look for DriveLetter in the first place. Instead of [tt]If oDrive.Name='F:\'[/tt] put in [tt]If oDrive.DriveLetter='F:'[/tt].

 

[atlopes]

atlopes, yes, I had that to begin with, too. but it does not unmount volumes, you can only eject removable media, eg a CD from a CD drive, aka opening the CD tray (whether empty or not). This doesn't remove a CD drive overall, though.

Yes, you're right, the InvokeVerb works with USB pen drives, but not with external HD drives.

Landfla, if the drives are only being used for backup, could you consider maintain them in a locked state, unlock them before the backup, and resume the lock after the operation completes?

Info:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364575(v=vs.85).aspx.