I'm trying to use OpenGPG and when trying to decrypt something It opens up a prompt for the password. Now I'm trying to run this automatically therefore none to enter password. So My question is how do you pass in the password to this new prompt opened up by the exe I'm running form the batch file. Ive looked in gpg2.exe -help and there is no way to pass in the password as a parameter if anyone is familiar with OpenGPG or if there is a command I can run to pass the password into the new prompt, that would be great.
gpg2.exe -o output.txt -d series.txt.gpg
After many attempts at trying to get this working I, finally checked out the manual for gpg2.exe at http://linux.die.net/man/1/gpg2 and after adding the command line argument --batch the --passphrase is accepted by the application.
Not doing so results in the user being prompted.
Hope this helps anyone in the future attempting to do this hack.
echo password | gpg2.exe -o output.txt -d series.txt.gpg
GnuPG offers multiple ways to pass the passphrase non-interactively. Using the parameter --passphrase [password] is probably the most simple one, depending on your use case the others also could be of interest (for example if you do not want to store the passphrase within your application code).
From man gpg:
--passphrase-fd n
Read the passphrase from file descriptor n. Only the first line will be read
from file descriptor n. If you use 0 for n, the passphrase will be read from
STDIN. This can only be used if only one passphrase is supplied.
--passphrase-file file
Read the passphrase from file file. Only the first line will be read from
file file. This can only be used if only one passphrase is supplied. Obvi-
ously, a passphrase stored in a file is of questionable security if other
users can read this file. Don't use this option if you can avoid it.
--passphrase string
Use string as the passphrase. This can only be used if only one passphrase
is supplied. Obviously, this is of very questionable security on a multi-
user system. Don't use this option if you can avoid it.
Related
In my C program I can set environmental variable via.. setenv
However setenv only allows me to setup an environmental variable via a string.
Currently in my environment I have the below setup in my bash profile...
export MY_PASSWORD=`java -jar decrpytpassword $ENCRYPTED_PASS`
where decryptpassword is a Java executable jar file which accepts encrypted password and prints out decrypted password.
I want to do something similar in my C program where I will pass the encrypted password via a string and decrypt it.
One way to do this would be:
Use popen to run the command and capture its output.
Read a string from that output (perhaps using fgets).
Put that new string in the environment using setenv.
P.S. If you use fgets in step 2, you may have to add a step 2a to strip the trailing \n.
I am writing a system service on FreeBSD where I need to take user credentials to verify identity, something like this:
./compression_bin -i <input_file> --type=<type> --password=<secret key>
Here, the secret key is used to authenticate user before compressing the given file. Currently, the secret key shows up in history which is bad and can be exploited. Is there a way where above can be invoked without displaying password field:
./compression_bin -i <input_file> --type=<type> --password=*********
The history will always record the text of the commands as they were issued. You could conceivably go back and modify the history file, but not only is that nasty, it still affords a window within which the password can be read.
Moreover, that's not even the easiest exploit. If the password is given on the command line then there are other ways it can be read while the command is running, such as from the output of the ps command, which is accessible to all users.
So don't take the password as a command-line argument. Read it from a file or from the standard input or from a socket, or some other such thing.
I'm using a batch file to execute some adb commands. When trying to do a longpress of the power key I use the following line:
adb -s <ipaddress>:5555 shell input keyevent --longpress 26.
If I type this command into cmd, it works without a hitch. Running it from the batch file, however, results in a short press. I created a single line batch file, with the above command as the sole contents. When running the batch file (I just type the file name in cmd), the command is printed as:
adb -s <ipaddress>:5555 shell input keyevent -ΓÇôlongpress 26
Is there a setting I may have unknowingly enabled that is causing this, or do I need some sort of escape character?
I'm rather embarrassed that I came across a solution to my issue only a few minutes after posting this, but I figure I should share and not waste anyone's time.
I've replaced the second hyphen in my command with its own alt code (i.e. alt 45) and it is now interpreted correctly in the batch file. The line still reads:
adb -s <ipaddress>:5555 shell input keyevent --longpress 26
I don't understand why this works, and would appreciate it if someone would shed light on the subject.
Edit: Based off the recommendation of the comment below, I looked up the differences between encoding schemes. If I understand it correctly, when encoding in ASCII or ANSI, characters are limited to 7 bits of data. This will keep characters in the first 128 members of the ASCII table, so the alt codes I saw previously couldn't be generated.
I was trying to upload a file through application i wrote in c.
As i did not find any API, i decided to go through commands.
Input command line looked like this.
ftp -u ftp://ftpuser:password#123#x.x.x.x/test.txt /tmp/test.txt
Whenever a special character is present, login will fail. when i tried with different user without any special characters in the password upload works.
How this issue can be resolved or is there any another method available like API which can be made use of.
If any sample code available then it will be of great help.
Special character means #, $, # (Ex : password#123, password$123)
code snippet:
RunCommandWithPipe(PSTRING CmdLine)
{
FILE *fp;
int status;
fp = popen(CmdLine, "r");
if (fp == NULL)
{
ErrGen(constErrOpenFile);
}
status = pclose(fp);
if (status == -1)
{
ErrGen(constErrCloseFile);
}
}
The reason why this doesn't work is because you are passing unfiltered meta characters into the shell. This is very dangerous. If someone untrustworthy gets to decide the value of any of the parameters to your ftp command, such as the username, password, ftp server, or file name, then that person will be able to run arbitrary shell commands.
You can see what's going on by putting an "echo" in front of your ftp command:
echo ftp -u ftp://ftpuser:password$123#x.x.x.x/test.txt /tmp/test.txt
You'll get this result:
ftp -u ftp://ftpuser:password23#x.x.x.x/test.txt /tmp/test.txt
The shell is trying to evaluate $1 as a variable, leaving an empty result.
There's a couple of things you can do.
1) Make the command safe by escaping all the meta characters. Here you need to be very careful, using a whitelist approach rather than just trying to get rid of the special characters you've thought of. In the whitelist approach you accept that some set of characters are safe, such as [A-Za-z0-9:_-]. Every other character you either strip out or escape by preceding it with a backslash. (eg. "foo:bar$baz&abc" becomes "foo:bar\$bazabc") If you do this way don't try to think of all the characters you know of that are special and escape those. You will most likely forget some, and not handle input this like:
ftp -u ftp://ftpuser:; rm -rf /;echo #x.x.x.x/test.txt /tmp/test.txt
2) Don't pass arguments on the shell, instead control the FTP client through fread()/fwrite() on the pipe that popen() gave you.
In this case what you do is launch the ftp client with no arguments. Then you write "OPEN 192.168.1.1" or wherever you want to connect. Then you write the username. Then you write the password. Then you write the GET or PUT command want. Then you write "EXIT" or write an EOF. You should read the result codes from the server. You'll get 200 series results on success. You'll get a 500 series result if the login is bad, etc.
You still have to watch out when piping into the FTP command because it will take shell escapes like "!rm -rf /", but there is much less opportunity for that than on the shell. You just need to make sure the strings you get to build your FTP commands are one line and that you always precede them with a valid FTP command. You should also watch out for any funny business with untrustworthy filenames. (eg. don't allow absolute paths, "..", and so forth)
You propably using a wrong charset to send the password
I am decrypting a gpg file using a batch file with the below code.
gpg.exe --output test.csv --batch --passphrase-fd 0 --decrypt WSB330TJ.CSTDJIDF.TXT.asc.14.04.22_00.59.gpg
Although it does Decrypt the file but I have to enter the passphrase manually.
How can I improve it so that it automatically pick the passphrase and decrypt the file without any manual intervention?
What should I add here?
You tell GnuPG to read the passphrase from stdin by using --passphrase-fd 0. There are different options to read the passphrase, from man gpg:
--passphrase-fd n
Read the passphrase from file descriptor n. Only the first line
will be read from file descriptor n. If you use 0 for n, the
passphrase will be read from STDIN. This can only be used if only
one passphrase is supplied.
--passphrase-file file
Read the passphrase from file file. Only the first line will be
read from file file. This can only be used if only one passphrase
is supplied. Obviously, a passphrase stored in a file is of ques-
tionable security if other users can read this file. Don't use this
option if you can avoid it.
--passphrase string
Use string as the passphrase. This can only be used if only one
passphrase is supplied. Obviously, this is of very questionable
security on a multi-user system. Don't use this option if you can
avoid it.
If you use GnuPG 2, remember to use --batch, otherwise the passphrase options will be ignored.
If you stored the passphrase in a file, use --passphrase-file password.txt, if you want to pass it as a string use --passphrase "f00b4r" (both times using appropriate parameter values, of course).
#Thierry noted in the comments that (especially when using Windows) make sure to end the file with a UNIX line feed (\n / LN) instead of a Windows line feed + carriage return (\n\r / LNRF).
For myself I had to do *gpg --batch --passphrase "MyPassword" --decrypt-files C:\PGPFiles\\\*.pgp*. Doing it with --passphrase not before --decrypt-files would always prompt me for the password. Also as Thierry said when I was using a password file I had to use Notepad++ to convert to unix style (Edit->EOL->Unix/OSX Format)
Try this:
gpg2 -se --passphrase yourpassword --batch --yes -r user#mydomain.com filename