I have a removable device setup so it autoruns when plugged into a Windows machine and pops up a message giving the owner's information, so it can be returned if lost. Is there a way to do this in Linux as well? It doesn't need to be complex, it can be an option in a right-click menu, or a splashscreen, or anything.
No. Unlike a default installation of Windows, which looks at Autorun.inf and automatically executes a specified program (or at least asks whether the user wants to run the "default action"), no distribution of Linux does this. Any autorun-like feature upon inserting a USB device on Linux must be explicitly set up by the user.
By the way, the autorun "feature" of Windows can be disabled, and it frequently is disabled by security-conscious computer users.
I haven't understood well what you're trying to do, anyway I strongly suggest to use one of the APIs provided by dbus (expecially the hal service).
Though this approach is not immediate.
http://dbus.freedesktop.org/doc/dbus-tutorial.html
I guess you could just put a file in the root directory called README_Owner_Identification.txt. That way people using certain desktop environments would see the filename when the file browser popped up in response to a USB device being automounted. If I recall correctly, both GNOME and KDE will do this by default.
Of course, people would still have to open the file to see the info, and it wouldn't work on systems that have the settings changed, but it's probably your best option. Anything else would require that people engage in some thoroughly insecure system reconfiguration just to see your ID.
Related
Summary
I'm developing firmware and a PC test application for a custom USB device, using the STM32F072 Discovery board. The device includes Microsoft Windows Compatible IDs (WCIDs) to enable automatic installation of the WinUSB driver on the PC.
The device is enumerated correctly on other Windows 10 hosts, but not on my Windows 10 development PC. My development PC had previously tried to enumerate the device when it had the same VID/PID combo, but with different descriptors/metadata. If I change the PID to some other number (new to my development PC), it does enumerate correctly.
Questions
How can I get this to work with my desired VID/PID combo on my development PC?
Is Windows caching USB metadata the cause of the failed enumeration on this one PC?
What are best practices on the (Windows) PC-side for testing/development of USB device firmware, during the stage when device descriptors and metadata are in flux? Is it possible to avoid chewing up PIDs just to avoid the Windows caching?
Details
Because of the way Windows caches USB descriptors and the like from previous enumerations, during firmware development, I was incrementing the device Product ID (PID) in the firmware after each time I made other changes, to ensure that Windows wasn't caching things from previous iterations of the descriptors, and messing up stuff that would otherwise work.
Now I've gotten the device to enumerate successfully on Windows 7, 8, and 10 PCs as a WinUSB device, and I've established communication. But when I change the firmware back to using the VID/PID that I started with, and then connect the device to my development PC, it shows up in Device Manager under "Other devices" with an error icon. I think this is because my (Windows 10) development PC previously had seen this VID/PID combo as having different descriptors, so it's getting confused by some bad cached stuff.
I've tried using regedit to delete the device's registry keys under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy, but the problem persists. (Also, I get an error, because it can't delete the VID_xxxx&PID_yyyy\zzzzzzzzzzzzz\Properties subfolders.) I also tried using USBDeview to uninstall old iterations of the device, but that hasn't made a difference either.
Also of note is that I can no longer pass the device through to Virtual Box virtual machines. I'm not sure what happened there.
Try removing any relevant registry keys of the form:
HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\vvvvpppprrrrr
The MSDN article Microsoft OS Descriptors for USB Devices says:
The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.
I know the OP has resolved his issues, but for future reference for anyone else having this problem: I had similar issues while developing a USB device with a vendor-specific class. Specifically, (similar to your experience) I was unable to delete the keys from:
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy,
so I had to increment the PID every time I modified my device code.
The reason why these keys can't be deleted is that the Properties registry subfolder is owned by the System user, so even running as Administrator you can't delete this subfolder nor change its permissions.
Running Regedit via PsExec (which is part of the SysInternals suite from Mark Russinovich) from an elevated command prompt with: psexec -s -i regedit.exe runs regedit as System user, which means you can delete that pesky Properties subfolder and the parent VID_xxxx&PID_yyyy keys.
I'm confronted with the same issue and uninstalling the device did not help.
Messing around with the registry makes me feel uneasy.
I still don't see a real answer to question #3.
What worked in my case: open device manager, select the non-working device and do "update driver". Select the driver manually from the list of locally available (Microsoft) drivers.
This did not solve all my problems but at least Windows does not ignore my device anymore and I can continue developing.
EDIT: I found a very helpful description on a github project named WCID Devices by Pete Batard. I strongly recommend reading the section Implementation and the following on this page WCID Devices
there are tools for removing hidden traces of USB devices like USBOblivion http://www.thewindowsclub.com/usboblivion-remove-usb-traces-windows , USBDeview,...
sources of USBOblivion are here: https://sourceforge.net/projects/usboblivion/ (https://www.openhub.net/p/usboblivion)
http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-device-drivers-in-windows/
To Remove TrustedInstaller Owned Registry Keys
Unfortunately the old PsExec trick of running RegEdit doesn't always work. In that case try to use:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
To repair file and registry permissions
You can also try using the very old tool: subinacl.exe
Example:
subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB\VID_0000&PID_0002\
Further described here. And has been shown to still work on Win10.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.
I was wondering if there was a way to make a *.dll that mounts archives in Windows without the need for installing drivers. I've tried mounting *.isos (and was successful), but I needed to install drivers, which was not something my intended audience wants to do (or can do). The other relevant alternatives were for Linux (fuse-zip) or dead projects (zipios++).
Something along the lines of this...http://mountziplibrary.codeplex.com/
Oh, and it'd be great if the solution was GPL v3'd or at least open source.
Thanks.
Have you looked at Dokan? It looks like a Windows equivalent to Fuse.
What you're describing is called an Installable File System (IFS). It theory you don't need a driver: implement a SMB server in application space, and let the existing kernel network client talk to that. It's just TCP/IP at that level.
The proper solution is indeed an IFS driver. Fundamentally, drives are objects in the kernel namespace. As such, the code for them should be part of the kernel, and an application never is.
There was a hobbyist project called WinFUSE once, which worked as an SMB server and redirected FS requests to your .NET code. But it's gone, as far as I know. Proper way is to use a driver-based approach. The driver can be installed and removed on-the-fly if the user has admin rights, and if he doesn't, installation of the application requires admin rights anyway. In Unix/Linux it's the same - you can't mount a disk (not saying about the driver now) if you are not an admin. Could I not mention that Callback File System is the only professional supported solution that lets you accomplish the task?
I've decided to Google around for some answers.
One of particular interest was zziplib. It's for C and transparently accesses archives, just like Windows does, treating it as an actual folder.
Of course, the other implementations given by users work too. This one just fit the bill for me.
Maybe this one helps you: ZLib
I have an application written in Delphi 2006 that was working fine in Windows XP. I packed the application using Inno Setup, using Program Files as the default folder. A few users migrated to Windows Vista and Windows 7. The issue here is that the application creates some files inside its installation folder by its own. This was working in XP but in Windows Vista the users were having problems with the created files (they don't appear and so on). After investigating the users' reports I discovered KB 927387: "Common file and registry virtualization issues in Windows Vista or in Windows 7."
Running the application with administrator rights just solves the problem, but that is (I think) an awful workaround. I would like to know if there are any directives or tips for making the application compatible with Vista and 7, because more users will migrate to these OS soon.
You need to re-write your application to store its files in the proper locations, even in XP, but especially in Vista onwards, particularly if UAC is enabled. This is becoming more and more important to get right as Microsoft keeps locking down and enforcing its security models with each new OS version. The rules for how to properly manage application- and user-related files is documented on MSDN, for example: "Application Specification for Microsoft Windows 2000 for Desktop Applications, Chapter 4: Data and Settings Management" and "Application Specification for Microsoft Windows 2000 for Desktop Applications Appendix A: Best Practices" (yes, they are old, but are still quite relevant). Look at SHGetSpecialFolderLocation(), SHGetFolderPath(), SHGetKnownFolderPath() and other related functions to help you.
For Vista/Win7, your app can't put the files in a subfolder of Program Files / Programs unless UAC is turned off or the app is running as elevated. Note that "elevated" does not necessarily mean "logged in as Administrator." Non-administrator users can elevate, and Administrator isn't necessarily elevated.
If the app does attempt to write to Program Files but is not elevated, the OS will either block the app or "virtualize" the write (put the files somewhere else), depending upon how UAC is configured. Neither one helps the app succeed at what it was trying to od.
So it needs to put them somewhere else. Where depends on why the files are being created, and you haven't told us that. You can read this article to learn about the options. Note that in addition to the user's AppData and Roaming folders, there is also an "All Users" (shared) profile.
You should probably look at this article and screencast, which discusses UAC in depth from a Delphi point of view.
Files you create for use by your application other than at installation time should go into the ProgramData directory if its global to the workstation, or into the users ApplicationData directory if its specific to the user.
For cases where you absolutely must place a file in the program files directory, you can use com to request elevation. This is discussed in great detail, and delphi specific bits are also available. One example that I have used this is in patching my users installation base. They are warned by UAC that the system needs to make changes, so if your doing this as an automated task, you might need to rethink the logic to be more user driven.
Here is another article, by Zarko Gajic, which shows how to get different system directories. Also have a look at this related question.
I had a similar enquiry here (Stack Overflow).
In the end I realised that I needed to put my application into Program Files at install time (requiring UAC/elevation) and then store my app's data in the user's App Data folder. I had to change the way my program generated 'default' configuration settings and also where I was saving this stuff, but it was worth the effort in the end - we ended up with something that installs and runs fine on XP, Vista and Windows 7.
The only UAC hit we get is at installation time, which makes sense to me (and you get a similar hit at install-time on the Mac too). We didn't have any data that would be common to all users in this particular case but I would have looked at the Program Data special folder if that had been the case.
The installer software we use (Setup Factory) made this fairly straightforward (we just wrote a small bit of code to detect XP versus Vista/Win7 and choose the right special folder accordingly). It would be easy to do this in Inno Setup too, from what limited experience I have of it.
On Windows, is there any way to programatically approve a USB device after insertion, if it is of a certain type (say Removable Drive) allow its use, otherwise not? Also not to allow running of drivers, only allow usage of the device in an approved way?
I.E. We want to allow the insertion of USB drives, but not have to worry about virus's being installed.
EDIT Sorry, I wasn't very clear on the posting of this question. Yes this is Windows, but I am not worried about auto-run programs, that is of course turned off. Users will not be able to access any executables, just data will be read off of the drive. They will not have access to any UI other than what we allow (it's a Kiosk). What I am concerned about is device drivers running and installing software (ala U3, and other USB software that installs itself when you insert a USB drive). There are a bunch of virus's in the wild that can be run just by inserting a USB drive into a system. We have restricted things with group-policy to the level that we can, but I can't find a way to not allow the installation of drivers without creating a base whitelist of USB drives that come pre-installed and nothing else would work (ie. Do not allow installation of drivers).
(Since you're worried about viruses I'll assume that we're talking about Windows.)
There is no point in restricting the user like that. Make sure the user does not have Administrator privileges. And install an up-to-date virus scanner.
Rationale: If you're not going to permit even reading files, then allowing a USB drive would be useless anyway. So you are going to permit reading files from a USB drive. But then someone could already install a virus by copying it to the local hard drive and run it from there.
If it's your own kiosk application, make sure your kiosk has drive letters A-Z assigned. To access the USB drive, you'll need a path of the form \??\Volume{GUID}\Filename. But by keeping it out of the normal file system, you're safe against most attacks.
You're never entirely safe. As Raymond Chen would point out, it doesn't help a lot if you disapprove forks. The (physical) damage is already done.
Also, on Windows, disable Autoplay/Autorun on the USB drives.
With Group Policy:
http://www.howtogeek.com/howto/windows/disable-autoplay-of-audio-cds-and-usb-drives/
There are also options in the TweakUI utility:
http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx
No. You can restrict access to removable media using GPO, but you can't specify what kind of files are allowed on the removable media or if they can execute or not.
EDIT: upvoting thomas. better answer than mine.