Run on mount?

[T]

Hi All,

This might not be the right place to ask this, but
when does that stop me?

When I insert a flash drive, my Anti Virus pop up
wanting to scan it.

How can I get Windows to do he same for me? Is
there something in the registry that triggers this?

The goal is to check the flash drive's label. If
it is the drive I am after, to dismount (hide) it.
(I already have code for that.)

Many thanks,
-T

[R.Wieser]

T,

Post by T
When I insert a flash drive, my Anti Virus pop up
wanting to scan it.
How can I get Windows to do he same for me?

I think you are looking for "RegisterDeviceNotification".

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerdevicenotificationa

It takes a bit of work though.

Post by T
The goal is to check the flash drive's label. If
it is the drive I am after, to dismount (hide) it

In that case it could not hurt to take a peek at the "autorun.inf" file.
Its normally used to get CDs to start installing automatically, but it will
most likely do the same for an USB stick or drive.

Than again, as this method has been abused in the past (to install malware)
it might have been disabled on later Windows versions.

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T
When I insert a flash drive, my Anti Virus pop up
wanting to scan it.
How can I get Windows to do he same for me?

I think you are looking for "RegisterDeviceNotification".
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerdevicenotificationa
It takes a bit of work though.

I am finding this example:

https://docs.microsoft.com/en-us/windows/win32/devio/detecting-media-insertion-or-removal

What I am not clear on are :

1) what is "top-level window"?

A top-level window is a window that is not a
child window, or has no parent window (which
is the same as having the "desktop window"
as a parent).
Huh?

2) is the target program spawned or running in the background?

hwnd
A handle to a window.

Huh? Handle to what?

Post by R.Wieser

Post by T
The goal is to check the flash drive's label. If
it is the drive I am after, to dismount (hide) it

In that case it could not hurt to take a peek at the "autorun.inf" file.
Its normally used to get CDs to start installing automatically, but it will
most likely do the same for an USB stick or drive.
Than again, as this method has been abused in the past (to install malware)
it might have been disabled on later Windows versions.

Most of the target computers are PCI (payment card industry) and have
autorun turned off. (I consult on PCI too.)

[R.Wieser]

T,

Post by T
1) what is "top-level window"?

When you build a GUI-based program the first/main window (either a true
window or a dialog) is called the "top level" window.

Post by T
2) is the target program spawned or running in the background?

Thats up to you to decide.

Do you see that "if (lpdbv -> dbcv_flags & DBTF_MEDIA)" line ? You could
replace what is inside it (currently the "StringCchPrintf" and "MessageBox"
commands) with whatever you want to have happening.

So no, there is no need to spawn anything. But if you wanted, you could.

Post by T
Most of the target computers are PCI (payment card industry) and have
autorun turned off.

:-D Yep, especially for those machines thats a rather good idea.
Especially as crooks have already used that method (auto-running USB sticks)
to relieve a number of ATMs of their contents.

You could still see if you could use it to alter the /appearance/ of your
USB stick though. You can change both the displayed icon as well as its
name. I've got a thumbdrive showing an avatar icon folowed by my name
(followed by the not-to-be-removed drive letter between round brackets).

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T
1) what is "top-level window"?

When you build a GUI-based program the first/main window (either a true
window or a dialog) is called the "top level" window.

Post by T
2) is the target program spawned or running in the background?

Thats up to you to decide.
Do you see that "if (lpdbv -> dbcv_flags & DBTF_MEDIA)" line ? You could
replace what is inside it (currently the "StringCchPrintf" and "MessageBox"
commands) with whatever you want to have happening.
So no, there is no need to spawn anything. But if you wanted, you could.

Post by T
Most of the target computers are PCI (payment card industry) and have
autorun turned off.

:-D Yep, especially for those machines thats a rather good idea.
Especially as crooks have already used that method (auto-running USB sticks)
to relieve a number of ATMs of their contents.
You could still see if you could use it to alter the /appearance/ of your
USB stick though. You can change both the displayed icon as well as its
name. I've got a thumbdrive showing an avatar icon folowed by my name
(followed by the not-to-be-removed drive letter between round brackets).
Regards,
Rudy Wieser

Hi Rudy,

I know I am being a total mooch here, but if you would
forgive me, would you throw together one of those
sweet assembly language definitions you do that would
spawn a program on flash drive insertions?

Calling msg.exe would do well as an example.

Many thanks,
-T

[R.Wieser]

T,

would you throw together one of those sweet assembly language definitions
you do that would
spawn a program on flash drive insertions?

I'm sorry, but thats not possible. What you are asking for is a full
program. Besides that I normally do not do that, I don't think its a good
idea either. You see, what you are asking for is three different solutions
wrapped together. What I mean by that:

1) Create a GUI program (in which you can respond to WM_* messsages)

2) Set up 'RegisterDeviceNotification' so it will cause 'WM_DEVICECHANGE' to
be send, and when that happens handle those messages.

3) Start a program of your choice.

You really should tackle those seperately. /Much/ easier. (the last one is
just a single function: 'ShellExecute')

I already gathered that you currently do not know much about the latter two.
But what do you know about the first one ? Does the language you are
using allow you do build a such a GUI program and, more importantly, catch
those WM_* messages for yourself ? If not ...

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

would you throw together one of those sweet assembly language definitions
you do that would
spawn a program on flash drive insertions?

I'm sorry, but thats not possible. What you are asking for is a full
program. Besides that I normally do not do that, I don't think its a good
idea either. You see, what you are asking for is three different solutions
1) Create a GUI program (in which you can respond to WM_* messsages)
2) Set up 'RegisterDeviceNotification' so it will cause 'WM_DEVICECHANGE' to
be send, and when that happens handle those messages.
3) Start a program of your choice.
You really should tackle those seperately. /Much/ easier. (the last one is
just a single function: 'ShellExecute')
I already gathered that you currently do not know much about the latter two.
But what do you know about the first one ? Does the language you are
using allow you do build a such a GUI program and, more importantly, catch
those WM_* messages for yourself ? If not ...
Regards,
Rudy Wieser

Okay, I have my marching orders. I thought is
was just a simple API call. Thank you!

[R.Wieser]

T,

I thought is was just a simple API call. Thank you!

:-) When using Assembly ?

Nope, Assembler is that language where you have to write multiple pages of
code to do almost nothing. :-p

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

I thought is was just a simple API call. Thank you!

:-) When using Assembly ?
Nope, Assembler is that language where you have to write multiple pages of
code to do almost nothing. :-p

Chuckle

Post by R.Wieser
Regards,
Rudy Wieser

But your definition header are so easy to understand
they are almost artwork

[R.Wieser]

T,

Post by T
But your definition header are so easy to understand
they are almost artwork

I'm sorry, but you can't blame me of that. Thats wholly the Assembly
languages fault. :-)

I'm still willing to provide you with some data about the involved functions
though. Its just that I have a very strong feeling about keeping seperate
problems seperate, and only link their solutions together.

That doesn't mean that those solutions can't be altered, but if I think it
will be a major change I copy them into their own programs and alter and
test them there.

And to be honest, the whole thing basically is, in Assembly, about six
functions:
One to start a dialog window (a classic window needs way more) and one to
exit it.
One to terminate the program.
One to start the device-change capturing and one to stop it.
And one for the "start another program".

Its just that the first and third need quite a bit of extra data and code to
be able to function.

Ofcourse, if you want to be able to supply arguments to such a program (like
the to be started program, or an option to or hide the program from the
desktop and remove it from the taskbar) than it ofcourse needs a bit more
work. :-)

The thing is, I have absolutily /no/ idea if your language allows you to
create a GUI based program, and if so if it allows you to handle such WM_*
messages yourself. Heck, I do not even know how well it handles data
structures (which you need for both the first, third and fourth steps).


I most always use "DialogBoxParam" for my window creation (
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxparama )
, as its generally the easiest one to use. The call itself isn't the
problem, but just take a look at the "lpTemplateName" and "lpDialogFunc"
arguments.

The first one is a structure which describes what your window looks like
(including al its elements, like buttons, text-entry boxes, etc). Creating
that structure is a challenge in itself (my Assembly environment has a
"resource compiler" for that, meaning I only have to describe the dialog
window and its contents), and than you have to put it into a resource file.

The other option is to use "DialogBoxIndirectParam" (
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparama )
, which allows you to put that template data in the program itself (no
resource file needed).

The latter one is a pointer to a callback function which receives /all/ WM_*
messages ment for that window, and which you need to handle to make the
whole thing work. Luckily, for a dialog window you only need to handle the
WM_CLOSE message and as a result call "EndDialog" call to have it work as
expected (if you do not handle WM_CLOSE you can't dismiss the window - which
actually, in your case, might be usefull ...)


It also will, after after you called 'RegisterDeviceNotification' as a
result of receiving the WM_INITDIALOG message, receive that WM_DEVICECHANGE
message which you are interrested in.

Just first make sure you have a working dialog window, so that you /can/
receive that message. :-)

Regards,
Rudy Wieser

[Kaz Kylheku]

Post by T

Post by R.Wieser
T,

I thought is was just a simple API call. Thank you!

:-) When using Assembly ?
Nope, Assembler is that language where you have to write multiple pages of
code to do almost nothing. :-p

Chuckle

Counterexample: Pac Man that fits into a 512 byte boot sector.

https://github.com/nanochess/pillman

[R.Wieser]

Kaz,

Post by Kaz Kylheku
Counterexample: Pac Man that fits into a 512 byte boot sector.

Pah! playing games *is* doing nothing ! :-)

But yes, /some/ of us can make (very) small (assembly) programs do the most
astounding things. I'm still in awe of how much the thanwhile "demo scene"
was able to squeeze outof the Commodore 64 - including lengthy 3D graphics.

Still got the sourcecode to a "fire" example stored here. Less than 600
bytes.

Regards,
Rudy Wieser

[R.Wieser]

T,

I've got some bad news for you ...

I was revisiting the MS documentation to the "RegisterDeviceNotification"
function, and, under "remarks" saw something I didn't notice before : "The
DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events are automatically
broadcast to all top-level windows for port devices.".

I just checked that, and indeed, inserting an USB drive generates
WM_DEVICECHANGE messages in a GUI program *even though
"RegisterDeviceNotification" hasn't been used*.

This means that I'm fraid that your job (so to speak) has become a lot
simpler. My apologies. :-)


Just grab that WM_DEVICECHANGE message and check if its "wParam" contains
DBT_DEVICEARRIVAL (0x00008000). If so "lParam" contains a pointer to a
DEV_BROADCAST_HDR record.

If the "DeviceType" field in there contains DBT_DEVTYP_VOLUME (0x00000002)
the DEV_BROADCAST_HDR is actually a DEV_BROADCAST_VOLUME record, in which
the "UnitMask" field holds the drive-letter of the just arrived volume (bit
0 -> A: , bit 1-> B: , etc)


The only thing after that is how to launch another program (preferrably
providing te above driveletter as an argument ...)

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,
I've got some bad news for you ...
I was revisiting the MS documentation to the "RegisterDeviceNotification"
function, and, under "remarks" saw something I didn't notice before : "The
DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events are automatically
broadcast to all top-level windows for port devices.".
I just checked that, and indeed, inserting an USB drive generates
WM_DEVICECHANGE messages in a GUI program *even though
"RegisterDeviceNotification" hasn't been used*.
This means that I'm fraid that your job (so to speak) has become a lot
simpler. My apologies. :-)
Just grab that WM_DEVICECHANGE message and check if its "wParam" contains
DBT_DEVICEARRIVAL (0x00008000). If so "lParam" contains a pointer to a
DEV_BROADCAST_HDR record.
If the "DeviceType" field in there contains DBT_DEVTYP_VOLUME (0x00000002)
the DEV_BROADCAST_HDR is actually a DEV_BROADCAST_VOLUME record, in which
the "UnitMask" field holds the drive-letter of the just arrived volume (bit
0 -> A: , bit 1-> B: , etc)
The only thing after that is how to launch another program (preferrably
providing te above driveletter as an argument ...)
Regards,
Rudy Wieser

I am writing this all down. Thank you!

[R.Wieser]

T,

Post by T
I am writing this all down. Thank you!

You're welcome.

Regards,
Rudy Wieser

[R.Wieser]

T,

Post by T
The goal is to check the flash drive's label. If
it is the drive I am after, to dismount (hide) it.

I vaguely remembered that you could just remove a driveletter from a drive,
and still access it. So, I did a quick(is) search:

-- remove the drive letter (seems to work the same way in XP):
https://winaero.com/blog/remove-drive-letter-windows-10/

-- Access the drive by its guid:
https://superuser.com/questions/465730/access-to-a-disk-drive-using-volume-id-instead-of-a-drive-letter-in-windows

(you can test this without even removing the drive letter)

Needs to be done only once for every 'puter you want to hide the thumbdrive
on.

Mind you, I'm not fully sure if the above "remove drive letter" does exactly
that, and not makes the thumbdrive switch back to its dynamic assignment of
it ...

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T
The goal is to check the flash drive's label. If
it is the drive I am after, to dismount (hide) it.

I vaguely remembered that you could just remove a driveletter from a drive,
https://winaero.com/blog/remove-drive-letter-windows-10/
https://superuser.com/questions/465730/access-to-a-disk-drive-using-volume-id-instead-of-a-drive-letter-in-windows
(you can test this without even removing the drive letter)
Needs to be done only once for every 'puter you want to hide the thumbdrive
on.

Mostly, but not totally reliable.

Post by R.Wieser
Mind you, I'm not fully sure if the above "remove drive letter" does exactly
that, and not makes the thumbdrive switch back to its dynamic assignment of
it ...
Regards,
Rudy Wieser

Hi Rudy,

I wrote a module to do all that: WinMount.pm6

sub GetLUA( Bool $Debug = False ) returns Bool is export( :GetLUA )


sub SetLUA( Bool $LUA, Bool $Debug = False ) returns DWORD is
export( :SetLUA )


sub Mount( Str $UUID, Str $Label, Str $DriveLetter ) is export(
:Mount )


sub Umount( Str $DriveLetter ) is export( :Umount )


sub FindPartitionByLabel( Str $Label, Bool $Fuzzy = False ) is
export( :FindPartitionByLabel )


sub FindPartitionByUUID( Str $UUID ) is export(
:FindPartitionByUUID )


sub FindPartitionByDrive( Str $Drive ) is export(
:FindPartitionByDrive )

Your LUA has to be set to 0 to hide drive letters. You
helped me with the registry programming for that.

What I am after is trying to make ransomware's life difficult.
So far they do not go after hidden drives. Problem with
flash drives is when you insert them -- unlike Linux -- they
automount, giving the bad guys a shot at encrypting your backup
drives.

Customer stick their backup flash drives in and leave
them in all day, which is only reasonable.

This is why I want to catch a freshly mounted flash
drive, see it is one of my backup drives (UUID), and hide
it if it is. My backup wrapper will unhide it when the
backup gets triggered and rehide it afterwards. This
does give the bad guys another shot at it, but I use
multiple partitions, so at worse, they only get
one partition.

Too much information , huh.

-T

[R.Wieser]

T,

Post by T

Post by R.Wieser
Needs to be done only once for every 'puter you want to hide the thumbdrive
on.

Mostly, but not totally reliable.

I assume, reading the rest, you ment "not totally reliable" as in "still
accessible" ?

Post by T
Problem with flash drives is when you insert them -- unlike Linux --
they automount

Than ... switch that feature off ?

I threw "Windows stop automounting thumbdrives" into google and got this:

https://www.tenforums.com/tutorials/117336-enable-disable-automount-new-disks-drives-windows.html

Yeah, /sometimes/ my google-fu actually works. :-)

Ofcourse, that would work for /all/ USB drives (I think). Than again, not
allowing ever tom-dick-and-harry to just copy files from their thumbdrives
and/or execute programs from them is a good first line of defense.

Post by T
My backup wrapper will unhide it when the
backup gets triggered and rehide it afterwards.

The problem with that approach is that the malware quite likely registers
storage media becoming available (the "RegisterDeviceNotification" function
you initially got), which ofcourse also likely gets triggered by your
"unhiding" wrapper ...

In other words, better do /not/ give that USB (thumb) drive a drive letter -
keep it hidden.

Post by T
Too much information , huh.

Nope, not really. "Just enoug" for me to comment upon it actually. :-)

Regards,
Rudy Wieser

[T]

Post by R.Wieser
T,

Post by T

Post by R.Wieser
Needs to be done only once for every 'puter you want to hide the thumbdrive
on.

Mostly, but not totally reliable.

I assume, reading the rest, you ment "not totally reliable" as in "still
accessible" ?

Post by T
Problem with flash drives is when you insert them -- unlike Linux --
they automount

Than ... switch that feature off ?
https://www.tenforums.com/tutorials/117336-enable-disable-automount-new-disks-drives-windows.html
Yeah, /sometimes/ my google-fu actually works. :-)
Ofcourse, that would work for /all/ USB drives (I think). Than again, not
allowing ever tom-dick-and-harry to just copy files from their thumbdrives
and/or execute programs from them is a good first line of defense.

Post by T
My backup wrapper will unhide it when the
backup gets triggered and rehide it afterwards.

The problem with that approach is that the malware quite likely registers
storage media becoming available (the "RegisterDeviceNotification" function
you initially got), which ofcourse also likely gets triggered by your
"unhiding" wrapper ...
In other words, better do /not/ give that USB (thumb) drive a drive letter -
keep it hidden.

Post by T
Too much information , huh.

Nope, not really. "Just enoug" for me to comment upon it actually. :-)
Regards,
Rudy Wieser

Okay, a long shot. How to you read and write to a
hidden drive without a drive letter?

[T]

Needs to be done only once for every 'puter you want to hide the
thumbdrive
on.

Mostly, but not totally reliable.

I assume, reading the rest, you ment "not totally reliable" as in "still
accessible" ?

By that I mean they do not always stay hidden.

A drive will come up on F:\, you hide it. Then several
months later it will come up on G:\. I have to clean
it out of the registry and start over. It is just
Windows being Windows.

Yesterday it worked.
Today it is not working.
Windows is like that.

:'(

-T

[R.Wieser]

T,

Post by T
By that I mean they do not always stay hidden.
A drive will come up on F:\, you hide it.

Thats what I ment with "... makes the thumbdrive switch back to its dynamic
assignment of it ...".

Post by T
Then several months later it will come up on G:\.

Can't say I've ever seen that happen. Than again, I assigned my thumbdrive
a fixed drive letter (easier to find and access from the commandline :-) )

Regards,
Rudy Wieser

[R.Wieser]

T,

Post by T
How to you read and write to a
hidden drive without a drive letter?

That was what that second link I posted was about. In short, you use
"mountvol" do see which drive is there that does not have am associated
drive letter, and than use the displayed GUID path to access the drive (that
GUID path doesn't change, so you only have to look it up once).

But, I have to confess that I assumed that you could use that GUID path from
the commandline. Alas, it refused to do so on XP. It does seem to work
in combination with the DLL functions though (tested it with FindFirstFile).
Its quite possible that approach will work from within LUA too.

And if you are using a backup program than simply replacing the drive letter
with that GUID path could work ...

Regards,
Rudy Wieser

[T]

Post by R.Wieser
And if you are using a backup program than simply replacing the drive letter
with that GUID path could work ...

I have not had success with that, but wish I could