I want to create a .bat file in Windows that receives a password and will call a custom utility to encrypt that password.
Is really important that the password sent to the .bat file as parameter is not logged anywhere.
My question is, if running a .bat file will create any system logs? anywhere? What if the .bat fails?
Are there any other better ways of doing this?
Thanks!
The generic answer is, "No, the running of batch files is not logged." However, there is no guarantee on a given system that the information is not saved somewhere. Or to say that again without double negatives, it is possible on some system that the information could be saved. For example, there could be a custom command shell (possibly created by the "bad" guy) that does log information.
You're going to see the command line in the process list. So if something is logging processes, or if it's long-running and someone opens the Task Manager, they could see it.
Related
I have a script that loads an excel file from some link, and then writes some information from the excel file to a text file. I set up a task on Task Scheduler to run the script and then email the text file, and it works fine while logged on. It does not, however, run while the computer is locked.
Unfortunately, I need the task to be run in the early morning before I get to work. Is there any way to make this work?
Unfortunately I don't think this is possible. This link HERE contains someone with a similar situation that was solved by making the computer "lock" via custom vbscript. However this is not the traditional "Lock" of a computer and actually just disables and removes a bunch of things... Further down they mention it being possible but it's very limited on what can happen... and making windows active is one of the limitations.
I received a windows application that is create a file on my windows. How can I find out where the file is?
I guess the program create a text file to save a code or something. I want that file. What can I do and how can I find it?
Sorry for bad English.
You can use Process Monitor to monitor any changes to file system or registry a program makes. Filter for the name of your programs executable and for file creation. Then run your program and analyze the log. Be prepared there might be a lot of entries.
Also keep in mind that "codes" are often not just stored in files. It might be in the registry and it might not be in the format you expect...
This is not exactly a question but rather your views on whether I'm on the right track.
I want to schedule a powershell v2 script in windows 2008 R2. I can put C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe in the program/script textbox and the script name and the arguments in the "Add arguments(optional) textbox. My script accepts around 5 arguments and since the window is not resizable I have to scroll to view all of them. SO, I'm thinking about creating a BAT file with powershell script and the arguments in it and then schedule the BAT file.
So my question is whether this is the right approach? Wouldn't using the BAT file invoke DOS process which in turn would invoke the powershell executable?
So my question is whether this is the right approach?
It is a technically valid approach. Whether it's right or wrong is subjective. If it functions properly, then it's technically "right" but you may lose the ability to see/capture any errors that are thrown; you may want to set up your PowerShell script to email your errors, or log them to a file (or even Event Viewer).
Wouldn't using the BAT file invoke DOS process which in turn would invoke the PowerShell executable?
DOS has been dead for over a dozen years (so no DOS process will be invoked), but you are correct that an instance of cmd.exe would be started by Task Scheduler, and that in turn would start PowerShell.
Don't sacrifice long-term functionality/reliability because the window provided in Task Scheduler for entering the command line is inconvenient to you. There's no rule that says you can't write out the full command line in Notepad, and then copy/paste it into that little box. If the job works better with PowerShell being invoked directly instead of through a BAT file, do what works best for the functionality of the job itself.
I need to back up some large files that are being written to disk by a process. The process is perpetually running, and occasionally dumps large files that need to be moved over the network. Having the process do this itself is not an option, as the process locks out users whilst it is doing file dumps.
So, this runs under a windows machine, and as a primarily linux user, I am not entirely certain how to do this...
Under linux I would simply use a cron job in the folder (I know the glob that will match the output files), then check lsof, to ensure that the file is not being written to, such that I don't try to copy a partially complete file. Data integrity is critical, so I would normally md5 the files before and after the copy.
So I guess my question is -- how does one do this sort of stuff under windows? I feel like I am kneecapped from the start -- I can use python, but I can't emulate lsof, nor cron to do the task scheduling.
I tried looking at "handle" -- but it needs admin privelidges at execution time, which is also not an option. I can't run the backup process as an admin, it has to run with user privs.
Thanks..
Edit: I just realised I could keep the python instance running, with a sleep, so task scheduling is not a problem :)
For replacing cron you can use the "Task Scheduler" in windows to start your script every few minutes (or specific times).
For lsof the question was discussed here : How can I determine whether a specific file is open in Windows?
Imagine we have a program trying to write to a particular file, but failing.
On the Windows platform, what are the possible things which might be causing the file to be un-writable, and what steps could be suggested to an end user/administrator to fix it.
Please include steps which might require administrator permissions (obviously users may not be administrators, but for this question, let's assume they are (or can become) administrators.
Also, I'm not really familiar with how permissions are calculated in windows. - Does the user need write access to each directory up the tree, or anything similar to that?
Some suggestions:
No write permission (get permission through Security tab on file Properties window; you must be the file owner or an Administrator)
File is locked (close any program that may have the file open, then reboot if that doesn't help)
File has the read-only DOS attribute set (unset it from file Properties window, or with attrib -r; you must be the file owner or an Administrator)
Edit 1: Only the second item (file is locked) has a possible solution that all users are likely to be able to do without help. For the first and third, you'll probably want to provide guidance (and hope the file wasn't made read-only intentionally!).
Edit 2: Technically, the user does need write and execute (chdir) permissions on all directories up to the root. Windows may skip some of the recursive checks up the tree as a performance optimization, but you should not rely on this because admins can force on these so-called "traverse checks" for certain users.
Edit 3: #RobM: Yes, you should check that there is no obvious reason that the user should not have the permissions she needs but does not have. I alluded to this in a less direct way in my first edit. However, in some cases users should have write permission to a file but do not because of filesystem corruption, a misbehaving program, or a mistake on their own part.
If you are having trouble working out if the file is locked, try using Unlocker - it's a really useful free utility that shows you the process that has locked the file and lets you force an unlock if you need to.
On Vista could it also be that it's "marked" as unsafe because it's been downloaded from the internet and you have to click the unblock button on it's explorer properties dialog?
Lets change this around a bit. If your program is trying to write to a file and failing you either need to change the location of the file to one where the user can write to, or check the correct rights when the program starts and refuse to run if the user doesn't have them. Trampling over the system permissions is not the answer.