How can I run this command in OSX?
dd if=mybackup.ab bs=24 skip=1|openssl zlib -d > mybackup.tar
When I run this I get the following errors
$ dd if=mybackup.ab bs=24 skip=1|openssl zlib -d > mybackup.tar
dd: mybackup.ab: No such file or directory
openssl:Error: 'zlib' is an invalid command.
Standard commands
asn1parse ca ciphers crl crl2pkcs7
dgst dh dhparam dsa dsaparam
ec ecparam enc engine errstr
gendh gendsa genrsa nseq ocsp
passwd pkcs12 pkcs7 pkcs8 prime
rand req rsa rsautl s_client
s_server s_time sess_id smime speed
spkac verify version x509
Message Digest commands (see the `dgst' command for more details)
md2 md4 md5 mdc2 rmd160
sha sha1
Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc
aes-256-ecb base64 bf bf-cbc bf-cfb
bf-ecb bf-ofb cast cast-cbc cast5-cbc
cast5-cfb cast5-ecb cast5-ofb des des-cbc
des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx rc2 rc2-40-cbc
rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40 rc5 rc5-cbc rc5-cfb
rc5-ecb rc5-ofb seed seed-cbc seed-cfb
seed-ecb seed-ofb
Openssl on mac is compiled without zlib support. Alternative method described in this article works on my Yosemite:
dd if=backup.ab bs=1 skip=24 | python -c "import zlib,sys;sys.stdout.write(zlib.decompress(sys.stdin.read()))" | tar -xvf -
Optionaly, if you just want to convert it into tar archive:
dd if=backup.ab bs=1 skip=24 | python -c "import zlib,sys;sys.stdout.write(zlib.decompress(sys.stdin.read()))" > backup.tar
It skips first 24 bytes of Android header and then uncompresses zlib data.
Just fix it
Get latest version from OpenSSL Official Repo.
$ wget https://www.openssl.org/source/openssl-1.1.0e.tar.gz
$ tar -zxvf openssl-1.1.0e.tar.gz
$ cd openssl-1.1.0e
Configure OpenSSL with zlib support
$ ./config zlib
$ make
$ sudo make install
Happy days
$ which openssl
/usr/local/bin/openssl
Related
Trying to encrypt a file & make executable using openssl. Found an interesting link that was suitable to my problem with one issue. which is "I had to pass the password used for encryption in openssl command" which is resulting error.
Create Write your script (script-base.sh)
#!/bin/sh
echo "Hello World"
Encrypt your script (give a password): foobar is my password
openssl enc -e -aes-256-cbc -a -in script-base.sh > script-enc
Write de Wrapper (script-final.sh):
#!/bin/sh
openssl enc -d -aes-256-cbc -a -in script-enc | sh -passin pass:foobar
Running "script-final.sh" I see following error in console
enter aes-256-cbc decryption password: bad password read
Though the following code works but its deprecated
openssl enc -d -aes-256-cbc -a -in script-enc -k foobar | sh -
when used the following error is thrown
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
bad decrypt
... works but [] deprecated: openssl enc -d -aes-256-cbc -a -in script-enc -k foobar | sh -
In that case you give -k foobar as an option to the openssl enc -d command, so it is used as the password to decrypt, which succeeds since you did in fact encrypt using foobar as the password (and the same cipher and default KDF). See below about deprecation.
openssl enc -d -aes-256-cbc -a -in script-enc | sh -passin pass:foobar [gives]
enter aes-256-cbc decryption password: bad password read
Here you didn't give -passin pass:foobar as an option to openssl, you gave it as an option to the shell that is the second component of the pipeline. Since you didn't give the password as an argument to openssl and it is needed, openssl prompted you to input it, but you didn't give valid input (perhaps entering control-D or similar) so it failed. If you did instead
openssl enc -d -aes-256-cbc -a -in script-enc -passin pass:foobar | sh
it would work exactly the same as the -k version, except for taking more space in your script.
It is indeed true that the key-derivation long used (and still default) by openssl enc is very poor and weak and has been widely criticized for decades; OpenSSL 1.1.1 (released 2018, after the date of the answer you link to) and up finally offers a better method with -pbkdf2 and warns about using the old one. However, you should pay attention to this warning on the encrypt side rather than decrypt; once you've encrypted with the poor method, you must use it to decrypt (and suffer the warning). Also note, as I commented at that link, OpenSSL 1.1.x (and 3.0) are incompatible with earlier versions, so if any system(s) you or anyone (like your users if any) want this to work on are running older software it will fail.
Alternatively, consider using something that was properly designed in the first place, such as GPG which was recommended in the answer by Gilles on that same question (well over a year earlier). Although GPG, depending on the version, makes it less convenient to provide the password on the commandline because that usually allows it to be compromised -- but in your case you are already compromising it yourself, so GPG's attempt to give you security is wasted.
I use this command to give me the output from openssl without the (stdin)= the beginning.
openssl x509 -noout -modulus -in certfile.crt | openssl sha1 -binary | xxd -p
with output
7857b35259019acc7484201958ac7e622c227b68
If I change openssl to create a sha256 digest, xxd prints it over two lines
openssl x509 -noout -modulus -in certfile.crt | openssl sha256 -binary | xxd -p
with output
b274c19ac31cc7893dc2297804a2ca666fe168d5cd5eb4d4b6c47616bad9
8996
How can I write that output on line one?
b274c19ac31cc7893dc2297804a2ca666fe168d5cd5eb4d4b6c47616bad98996
Is it something else I have to do with xxd now that the digest is longer or is there a need to pipe it through some other command to get the combined output?
As usual there are several ways.
The first general solution which came into my mind is this:
printf "%s" $( openssl x509 -noout -modulus -in certfile.crt | openssl sha256 -binary | xxd -p )
Of course, if the output is less than 256, you could use xxd -f -c 256 as stated by tshiono.
Another solution for this special case with openssl would be this:
openssl x509 -noout -modulus -in certfile.crt | openssl sha256 -r
or
openssl x509 -noout -modulus -in certfile.crt | openssl sha256 -hex
but both are not exactly like the output you want. The hex string is in the output, but padded before or after which can be cut off, by piping to the command cut -d" " -f 1 or cut -d" " -f 2 for the removal of the prefix or postfix.
For background, I am working through the Matasano Crypto Challenges. One of the problems (Set1, Challenge 7) is to decrypt an AES-128 ECB mode file with a given key, YELLOW SUBMARINE.
The file is base64 encoded and I can decrypt the file in Python but I cannot using the Windows 10 openssl command line tool.
The command I am running is:
openssl aes-128-ecb -d -a -in 7.txt -pass pass:"YELLOW SUBMARINE"
When I run this I am told that I have a bad magic number.
Does anyone have an idea of why I am getting this error?
Looks like the -pass option doesn't like the space in the passphrase.
You can use the option -K with the hexadecimal key like this:
openssl aes-128-ecb -d -a -K 59454c4c4f57205355424d4152494e45 -in 7.txt
Or use the passphrase directly with this command:
openssl aes-128-ecb -d -a -in 7.txt -K $(echo -n "YELLOW SUBMARINE" | hexdump -v -e '/1 "%02X"')
Just for completeness: encrypting with -a params ( Perform base64 encoding/decoding (alias -base64) ) and decrypting without it ( or vice-versa ), bad magic number given.
So I have a basic communication stream that managed by netcat. A user can create a bash shell and forward control to localhost at port 5555, for example. How could you pipe this through OpenSSL to achieve a connection that is symmetrically encrypted? I am only able to work with tools that come installed on an OSX machine.
Create Shell
bash -i >& /dev/tcp/localhost/5555 0>&1
Catch Shell
nc -l -p 5555
Encrypt data with OpenSSL
openssl aes-256-cbc -salt -a -e -in plaintext.txt -out encrypted.txt
Decrypt data with OpenSSL
openssl aes-256-cbc -salt -a -d -in encrypted.txt -out plaintext.txt
Kind of what I'm looking for
bash -i & | openssl -e > /dev/tcp/localhost/5555 0>&1
nc -l -p 5555 | openssl -d
Based on additional information from your comment, install MacPorts, and try to use ported socat or stunnel.
dtpwmbp:~ pwadas$ uname -a ; sudo port list |egrep -i socat\|stunnel
Darwin dtpwmbp 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
stunnel #4.47 security/stunnel
socat #1.7.2.1 sysutils/socat
dtpwmbp:~ pwadas$
http://www.macports.org
I would like to sign a file using a dsa key and openssl. The DGST(1) man page says the following:
file...
file or files to digest. If no files are specified then
standard input is used.
For me this means that the following two terminal commands should give the same results, which they do not. I piped the output through od because the result is binary.
specify the file on command line
openssl dgst -dss1 -sign private_key.pem test_archive.zip | od -x
0000000 2c30 1402 e30d 9073 0059 0de7 f03e 8fd2
0000020 874b 5252 b025 8f44 1402 ed26 2f55 7fa4
0000040 f474 0426 1d44 787c ecd6 5059 921b
0000056
piping the file into the openssl command
openssl dgst -dss1 -sign private_key.pem < test_archive.zip | od -x
0000000 2c30 1402 2444 c3a5 f498 7bb8 3dfe 715d
0000020 e179 c5ad c0a5 2b16 1402 173b 692b 9d71
0000040 3970 c497 9994 9cbc 4cfd d642 62df
0000056
As you can see both outputs are not the same, although the file which should be signed is the same in both cases.
Why is this the case? Am I missing something obvious here?
Edit
I am using OpenSSL version 0.9.8y 5 Feb 2013 on FreeBSD and version 0.9.8r 8 Feb 2011 on Mac OS X 10.7.5 and observing the effect on both.
Edit 2 - How to generate a key for testing
small shell script for generating appropriate keys
#!/bin/bash
openssl=/usr/bin/openssl
${openssl} dsaparam 1024 < /dev/urandom > dsaparam.pem
${openssl} gendsa dsaparam.pem -out private_key.pem
${openssl} dsa -in private_key.pem -pubout -out public_key.pem
rm dsaparam.pem
I also ran a test on a CentOS 6 Linux system using OpenSSL version 1.0.0-fips which shows the same strange behavior.
Edit 3 - More Versions Tested
Also the freshly compiled OpenSSL version 1.0.1e 11 Feb 2013 shows this behavior.
I'm not able to reproduce this (OpenSSL 1.0.1 14 Mar 2012) . (I was using an RSA key) I think there are three possibilities:
OpenSSL bug [or different default option] You may have a different version that has a bug. For example:
http://rt.openssl.org/Ticket/Display.html?id=2965
(I don't necessarily think it's this particular bug, but it is similar.)
The key changed.
The zipfile changed
Try adding -binary to your commands. Looking at #1, it could be that my version is doing --binary by default, which excludes the digest type.
openssl dgst -sha1 </dev/null
(stdin)= da39a3ee5e6b4b0d3255bfef95601890afd80709
openssl dgst -sha1 /dev/null
SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
With the dsa key, I am able to reproduce this in multiple versions of openssl (1.0.1 and 0.9.8y)
Using the -hex option, I was also able to confirm that the prefix is changing.
(1.0.1)
openssl dgst -hex -dss1 -sign private_key.pem config
DSA-DSA(config)= 302e021500ca417b14be6e1c08426d4f4cdb3beb51181e6055021500e6a768689cfe9c6f7538e9ec2f952c9465fea80b
openssl dgst -hex -dss1 -sign private_key.pem <config
(stdin)= 302c02142a59682765ae10e37fe114ca63a21cdf4127ff5302141c8b3ac5caf538a23dc43b20cc9c01b1278c0d8e
(0.9.8y)
apps/openssl dgst -hex -dss1 -sign private_key.pem config
DSA(config)= 302e0215008aef560f547425fb4360e24be343fa6db2dc4551021500eb594cea70455400838dc0a14dae7b86614c5218
apps/openssl dgst -hex -dss1 -sign private_key.pem <config 302c02146aa92d6cf2cc9a6fb1d340fed21c29d05f936fc002141fd9e781def4897cfc306b7a68a92b90e6861cb9
Note: all 4 commands have different binary output. Given that the hex hash is the same but the prefix is different, it seems reasonable to infer that the differences in the prefixes are causing the changes in the outputs.
The behavior of OpenSSL is not a bug. The created signature is different if the file is piped in via stdin or specified on the command line, but both outputs are a valid signature if tested with
openssl dgst -dss1 -verify public_key.pem -signature file_with_archive_signature.sig test_archive.zip
Therefore I think that without looking at the algorithm there is more than one valid signature for each file, but a signature is only valid for one file (neglecting collisions).