I'm trying to crack winrar's password using some methods as explained below.
Because rar uses AES-128 encryption, brute-force and dictionary attacks are useless as they would take years.
But, if we convert a password-protected rar file into an SFX archive (I'd prefer to winconsole because GUI takes much memory) that is an EXE format, I'm quite sure that it would be out of protection from winrar's gates.
Even then rar writes the encryption keys to that exe file.
So, if we could use an exe debugger or disassembler, can't we knock out the key that contains the password?
I used w32dasm, olly dbg & pe explorer to modify these exe files.
All I could find are the strings like "Extracting, CRC failed, Encrypted" and some other things. I used several sfx archives as test files (with different passwords) and tried it through disassembly. Those hexadecimal keys are looking quite similar!
So do I need a better disassembler or debugger? OR, someone tell me that if this method is useless and why?
Another question.. Does this following image has any link to winrar encryption? If yes, please explain how.. It would be very helpful.
When you create a password-protected SFX it does not store the password. It asks you for it.
You can't just "convert" password-protected content into not-protected content. If that was possible the encryption scheme would be completely worthless.
I think the problem is that trying to change the file to an SFX does nothing to decrypt the already encrypted content of the file hence it won't work. The data is already encrypted. Unless the data is NOT encrypted, then you would have to undergo the decryption process to get to your data no matter what you did to the file. No?
It is not easier to attack an SFX file versus a RAR file. A RAR archive consists of your compressed and (optionally) encrypted data. An SFX file is, like RAR, a package of compressed and encrypted data, but it also includes a miniature form of WinRAR that can decrypt the packaged data after the user enters the password.
The SFX file needs your password to decrypt your data; when you enter the wrong password, it's not because it tested your password against one embedded in the file. It means that when it tried to decrypt the data with the supplied password, something went wrong. This is all due to the magic of symmetric-key cryptography: the ciphertext (packaged within the RAR/SFX archive) goes through the AES decryption using the password you entered and the result (plaintext) is exported to whatever location you chose.
In conclusion, you'd have the same luck trying to break an SFX file as you would with RAR archive.
Related
I wanted to basically have a script that can encrypt text on the fly as I'm writing to a file and then unlock it with a key. I wanted to give hashes a try but, there's no way to unlock hashes of sha256 or in general from what i gathered.
So far I've been giving Fernet a go but, couldn't figure out how to encrypt without saving the unencrypted file to disk.
Might anyone know a way around this?
Thank you for your time.
I am developing a tool to encrypt one or multiple files using PGP.
So far, I had no problem to encrypt a single files.
For encrypting several files, I had to resort to zip them in a single file, and then encrypt the single file.
However, I know that Symantec PGP can encrypt several files inside one .PGP file, without having to zip multiple files.
I think this is a more elegant solution, as one does not have to decrypt and unzip (two steps), but only open the PGP file and then select the files.
I have only found examples to encrypt a single files, but no information on how to encrypt several ones.
For the record, I am using BouncyCastle.
I fear there is no way around using ZIP compression before encrypting.
While you could use multiple Literal Data Packets (one per file) inside your message, section 11.3 of RFC4880 hints that there can only be a single Literal Data Packet per message. This is also the interpretation of the OpenPGP Interoperability Test Suite which shows that quite a bunch of implementations reject messages with more than one Literal Data Packet.
Going with ZIP is your best option here.
I am working in powerbuilder IDE is it good idea to encrypt a value in inifile or encrypt the entire file in order to protect user id and password ?
Encrypting passwords within text files appears to be an acceptable practice in the IT industry. It is also common to find encrypted passwords stored as a column in a database.
I have not heard of encrypting the entire file and the reason it's probably not done is that you'd end up with a file name with unsupported characters for the OS.
I recently rewrote the crypto api example so it should work better.
With the included zip utility in CentOS5 (zip command): i.e. /usr/bin/zip -P $ZIP_PASS ...
I haven't been able to find any documentation on this. I am trying to find out how secure the password is. Is this encrypted? How is it protected if not with encryption?
Thanks
Ok I found the answer I was looking for.... From http://en.wikipedia.org/wiki/ZIP_%28file_format%29 and http://en.wikipedia.org/wiki/Known-plaintext_attack
Encrypted file archives such as ZIP are prone to this attack.[citation
needed] For example, an attacker with an encrypted ZIP file needs only
(part of) one unencrypted file from the archive which forms the
"known-plaintext".[4][5] Then using some publicly available software
they can quickly calculate the key required to decrypt the entire
archive. To obtain this unencrypted file the attacker could search the
website for a suitable file, find it from another archive they can
open, or manually try to reconstruct a plaintext file armed with the
knowledge of the filename from the encrypted archive.
So... the zip is not completely secure - but with random file names (when implemented well) for the file(s) inside the zip, and immediate deletion of the unencrypted file (which is also non-web-accessible) - this appears to be a POSSIBLE solution...
More resources:
http://linux.101hacks.com/archive-compression/password-protection-for-zip-files/
However, the more I read, AES 256bit encrypted zips by 7zip (once installed on the server) is much, much more secure. It is NOT susceptible to the known plaintext attack, either.
Yes, it is encrypted. Per the manual:
-P password
use password to encrypt zipfile entries (if any). THIS IS INSECURE! Many multi-user operating
systems provide ways for any user to see the current command line of any other user; even on
stand-alone systems there is always the threat of over-the-shoulder peeking. Storing the
plaintext password as part of a command line in an automated script is even worse. Whenever
possible, use the non-echoing, interactive prompt to enter passwords. (And where security is
truly important, use strong encryption such as Pretty Good Privacy instead of the relatively
weak encryption provided by standard zipfile utilities.)
This is just found from running "man zip" on a centOS machine.
As the manual entry notes, for high security it is not good to use the password in the command to zip the file, as others could check the process list and see the password as zipping.
I don't know what kind of encryption this uses, but I looked around some and it doesn't appear to be great. There are some similiar questions on stackoverflow to this. Look into using a different zip library if encryption is truly important, use something that allows AES, such as GPG.
I have a csv file that required to be encrypted. I want to ask that is there any difference between encrypt the content and encrypt the file? Or they are the same? Because our client doesn't clearly specify what they want?
Thanks,
Encryption will always produce binary result, which can be "armored" (base64-encoded and wrapped) then in order to get the text. All implementations conformant to OpenPGP standard handle armored data by decoding it to binary automatically, so it doesn't really matter what mode you specify. One special case is when you plan to paste the result to some other text data (such as text document), then armoring is mandatory.
Usually when they say PGP encryption, they are talking about commercial programs that encrypt a file or files into one gpg file with their public, which they can decrypt with their private key.
The other way is encrypt it yourself line-by-line in code (there are libraries that do that using file streams; very easy).
Your client one way or another has to tell you how that expect to decrypt the data later on, which will tell you how you encrypt in the first place.