Ive been looking for answer to this questions for days, and still I haven't found anything about it.
I'm trying to execute a .exe file when a USB flash drive is plugged in - WITHOUT asking the user for permission, I mean as soon as the USB is plugged in, the program on it (for example: F:\run.exe) is starting, without any click made by the user.
I tried this code with shell execute in the autorun.inf file:
[Autorun]
open=
shell\open=Explore
shell\open\Command=rundll32.exe .\\svcpacj.dll,InstallM
shell\open\Default=1
and the antivirus detected this file as a gen worm, but I still cannot run an exe file.
Thank You!
This just means autorun is disabled. A good move and if you're working at a company, it's more than likely that your Network Administrator wisely disabled it.
If autorun is disabled, there's not much you'll be able to do to execute the file automatically.
You can't do this if on W7 or W8.
Windows 7 removed this functionality. I guess to prevent virus's from being automatically run.
More reading http://www.addictivetips.com/windows-tips/autorun-inf-does-not-work-in-windows-7-anymore/
Related
I've written a Win32 program that at regular intervals retrieves content from a dedicated server on the internet.
Sometimes the Win32 program itself needs to be updated. What I do is exit the said program and run a download-program which replaces the main exe I need to uopdate. This works for users running in Administrator mode but not other mode that has sufficent rights for most tasks. The program runs on it own directory which is not under "c:\Windows\program files\".
I've set a manifest file to no avail.
Is there a workable workaround solution for this (any)?
For security reasons you cannot place files in Program Files without admin rights. If you would be able to this you could in theory change Windows files and place malware as well.
Same goes for Linux and OSX systems.
However you could prompt the user for an Administrator password and gain the admin rights in that way.
You need your updater program to have admin rights. You achieve that by adding the requireAdministrator option in the requestedExecutionLevel section of the application manifest. You said that you have tried this to no avail. Well, you must have got something wrong because this is the solution. You just need to persevere until you get the manifest correct.
I presume that when you say that the [program is not under the Program Files directory you refer to the updater. If the program being updated is not under the Program Files directory then there would seem to be no obvious reason that the updater needs admin rights. If that is so then you need to investigate further.
I have a .exe file in my pen drive sitting in a long chain of directories
(driveLetter:\dir1\dir2....\dir8\program.exe)
Now I don't wanna go through all those directories to get to the file and run it,
Problem is that in Windows7, running a .exe file with the autorun.inf open command doesn't work anymore in pen drives but it does in CDs, that's why I wanna make my pen drive appear like a CD to windows upon insertion.
Please don't ask me if I'm writing a virus here, cuz I'm not.
Any ideas how can I achieve this ?
if making it appear as a CD won't work, is there a way to run the .exe file
(I know, this might be a separate Q)
Thank you so much for anything you can provide me with.
You can make a flash drive use autorun by having the autorun and exe file in the default directory (i.e.: not a dozen folders deep). That's how I've done it when installing W7 on computers without a CD drive.
Here's what Windows 7 autorun.inf looks like
[Autorun.Amd64]
open=setup64.exe
icon=setup64.exe,0
[Autorun]
open=setup.exe
icon=setup.exe,0
It's pretty straight-forward: the top one is for a 64-bit OS, while the bottom is for 32-bit.
Since 2011, Microsoft has removed the autorun.inf option, so it will not work, not even if CD drivers will replace the current drivers. Both CDs and flash drives can't be automatically started without at least a prompt shown to the end user. That is for security reasons.
I ran into a problem after creating a screensaver that requires writing to a file located in Program Files. When the screensaver becomes active it can successfully read a file from there but fails to write to a file.
I noticed that when I use and elevated command prompt to run the screensaver, with /s, the screensaver successfully writes the file. So I assumed this was a permission problem.
To see if it was a permission problem I went in and changed Program Files and the subfolders permissions so that anyone and system could read and write, but it still didn't help.
Any idea what I should do? Is there a way to force a screensaver to run as admin? Or did I miss some important permissions?
You can't get the system to start screensavers with elevated rights. If that were possible then it would be a truly bone-headed security and design flaw. Screensavers should simply not be writing to Program Files or other restricted areas. You will have to find a different location to write this file.
We've got a VB6 application that reads a simple text file with a .LIC file extension. When everything is working correctly, if the file exists in the same directory as the executable, it reads it. If not, it does other stuff.
I've got a customer with Windows 7 machines, and if he right-clicks the EXE and "Runs as Administrator" it "sees" the LIC file. If he runs the EXE as a basic user, the LIC file cannot be seen.
I've had enough issues with UAC to guess that UAC is running the application from a virtual directory of some sort and that's why the LIC file isn't seen. My customer swears he's turned UAC off.
Anyone have any pointers for me? It would be great if there was a way to tell UAC "let this app do what it wants in this directory". That's out of my expertise. I've been Googling till my fingers fall off, and I can't find the right answer.
Thanks!
If you think virtualization is happening (which would cause it to look somewhere other than Program Files), give him a manifest file called foo.exe.manifest where foo is your executable name and have him put it in the same folder as the exe and the .lic file. This manifest should set the required execution level to asInvoker. This will suppress virtualization and so you can rule that out as part of the problem. He may then get access denied errors but that will help you sort out the problem.
It could also be permissions? If the user is not logged on as administrator, then your program may not have permissions to read the ".lic" file. Have you checked whether the user can open it in Notepad? Is it possible your code might be trying to open it with read/write permissions, which is even more likely to fail?
You may need to change your install so that it lowers the permissions on your apps installation directory.
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.