Detect if USB is Inserted through Application - windows

I want to create an application or modify USB in a way so that, upon insertion into any PC, I can get the information that PC was inserted.
eg. upon insertion, I can read PC name and make an API call with this as post data so I'm able to know that my USB was inserted in some PC. But this should happen right away as USB is read by the machine, so even if the user formats it thereafter, it should not matter.
If it was earlier windows, I could write autorun and that would work. But I want this detection mechanism for Windows 7 and above.
I have done some research on the topic but could not find any reliable content. Some articles were related to USB based hacking attacks by changing wiring (USB hardware, to harm the computer) or something like that. But I totally don't want to do that. Just the detection, that USB was used.

Related

Autorun USB Windows 7

I would like to create a USB stick with a simple HTML file in it which opens when the stick gets plugged in. It is meant to be some kind of merchandise thing. Thing is that I read that Microsoft disabled Autorun on Windows 7 for security reasons. But despite that I have such a USB stick lying around which does the exactly the thing I'm looking for. Unfortunately it is not displayed as a removable drive, therefore I can not take a look into it.
Can anyone recommend a method, which works on as many devices (with different OS, different Settings) as possible?
i think you are searching for the autorun.inf http://en.wikipedia.org/wiki.Autorun.inf
you can write your own autorun.inf and copy it on the stick (if it does not show up as removable disk format it, maybe run a data rescue tool first) if this will work depends on the os settings of the specific computer you plug in the stick. if autorun is disabled in the os it will not work...

C++ Builder - Handle to OS to Iterate Through All Drives

I'm using Borland C++ Builder for a project which connects to a database.
There is a configuration which does backups to a USB drive. The problem with the current approach is that the drive is manually configured by the end user and sometimes things get messed up. E.g. People move the USB drive to a different port, get a different letter and then the back up process no longer works. As a side note, we have other "better" processes for backing up to the cloud, etc., however some locations don't have internet access and aren't running on a RAID... so backing up to USB gives them a saving grace from a HD crash.
I'm hoping to do some coding to help remove this issue. I'm hoping to be able to get a handle to the OS (Windows 8/7/XP) and be able to identify the drives on the machine. Once I have those, I can then iterate through them and check for a path location (e.g. File marker, so if a the file exists, I know its the USB we supplied). Then once I have that, I can do the back up.
As a worse case scenario, I will be able to iterate through all 26 letters to test each drive. However I'm using this as a learning opportunity and hoping to get a handle to the OS so reduce the number of checks/fails I can run into. Besides, I'm curious if anyone has a better approach :)
I don't think there's much to be gained by trying to do something more advanced than iterating over the 26 drive letters.
Before attempting to check whether or not the marker path exists you could add a call to GetDriveType and compare the return value against DRIVE_REMOVABLE. This will make sure that your code doesn't spin up the CD/DVD drive, or hit the network in the case of a mapped share.

Test a embeded system (PC) from another PC

Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.

retrieving detailed usb midi device information on windows xp

The function midiOutGetDevCaps returns a structure MIDIOUTCAPS.
I'd need more specific information when querying a usb midi device on windows xp, in particular I'd need the information displayed under "Location" when opening the respective device using the Device Manager.
I need this information in order to programmatically distinguish between several MIDI Interfaces connected to a computer. Using midiOutGetDevCaps, I uniformly get "USB Audio Device" for every midi usb interface connected to the computer, so distinguishing between the interfaces is impossible.
To make matters worse, this string is localized, so e.g. on a German Windows you'll get "USB Audiogerät" instead of "USB Audio Device".
I guess it depends on how desperate you are. I've had my own run in with USB devices. In my case I needed to enumerate certain USB COM port related devices . . . regardless if they are currently attached to the system or not.
It is all company proprietary code, sorry I cannot post it, but the search for all information regarding USB related devices starts here (Perl):
$hostnamePrefix = "//$hostname/";
my $baseKey = "${hostnamePrefix}HKEY_LOCAL_MACHINE/System/CurrentControlSet/";
my $regVidList = Win32::TieRegistry->new("${baseKey}Enum/USB/", $optionsRef);
If memory serves me it is a reasonably straight forward structure. I believe you actually have to loop through two separate sections of the registry to get everything you need . . . if you are desperate enough to attempt this, I'm happy to answer questions where I can, but posting code would required approval from our legal department. (Not impossible, but it would take weeks to obtain.)
Also, while this will work on XP . . . I have no idea how it will work on Win7. (I don't know either way, nobody has tried it yet that I am aware of.)
Coding this was not that bad (resulting Perl Script is around 1000 lines of code which is almost 50% comments), but working out all the relationships between the keys and the special cases took several days.

What's the best way to authorize a USB Key

We have an auto update for our software that is installed via USB key (with the auto run). If I wanted to ensure that only authorized USB Keys were used, what's the best way?
Our installer is already signed, and it won't run otherwise. But I'm more wanting to inspect the USB Key for a signed installer, and if it's not there, just ignore, or even "Eject" the USB device.
And I should be able to tell the difference (in code) between a usb storage device, and say a camera, or keyboard.
I'm only wanting to disable non-authorized storage devices.
Thank you for your ideas.
non-authorized storage devices? This depends on how secure you want it to be. For the most secure level, it would consist of:
special firmware written to the flash drive to get extra "meta info" (read: expensive custom manufacturing of flash drives)
special windows driver to read that meta info from the flash drive
your program talking to that device driver to confirm it's authorized.
Or to the least secure level you have these options:
using a hidden file and a special key(possibly hashed time of last filesystem modification or something?) (dd breakable)
dropping below the filesystem level and recreating your own very simple filesystem.. (more security through obscurity though and dd could break that)
Also, for the "most secure" option, you really need a more secure way of running the program than auto-run and a device driver(which could be half-baked to make anything appear authorized). Why do you want it to only update from an authorized flash drive anyway?
You might be able to read the USB drive's serial number (assuming you get USB drives that have serial numbers; not all do). Then your application could call home to get the latest list of authorized serial numbers, and check to see if there is a match.
Earlz response is good, though I don't think you'd need custom manufacturing of flash drives... you would just need flash drives with some sort of unique firmware encrypted identifier. Perhaps something in the Kingston Data Traveler Line might do the trick. (I've never actually used one of these encrypted usb sticks, so I'm a bit foggy on the actual implementation details).

Resources