The encryption principle is as follows:
Read SRC and perform some operations on the SRC and key to obtain the encrypted result. The same key is required for decryption. simply put, the result = FN (SRC, password, operator) SRC is the password to be encrypted, the password is the corresponding password, and the operator is the corresponding encryption operation (that is, result = SRC <operator> password ), the returned result is the encrypted result. the SRC and password operations are performed here, so if you do not know the password, you cannot solve the SRC from the result.
Encryption programs written by most software workers (excluding those on the market, such as "high-strength encryption masters, and other money fraud software") use this method.
For example:
To Encrypt int SRC [] = {11111111,111 11110, 11111100,111 11000} (Binary ).
Assume that the encrypted operation is an exception or operation (^ ).
The entered password is 11111111 (Binary)
Compare SRC [] with 11111111 or (^.
The encrypted data is {0000000,000 00001, 00000011,000 00111} (Binary)
During decryption, you only need to perform another (^) operation on the encrypted data.
Without knowing the key (password 11111111), it is impossible to obtain the original data. if you enter a wrong password for decryption, the final result is only the wrong data.
So it seems that the application cannot be cracked.
However, the author or user often ignores one point: if the prototype of a part of the encrypted information is known, and when your encryption method is simple enough (even if your encryption method is quite complex, it just takes a little longer), you can take advantage of it.
For example. you can use ultraedit to open any RAR. The first 20 bytes of the RAR are fixed. if the preceding encryption method is used for encryption. if the password is set to password [] = {0x65, 0x66, 0x67, 0x68} (that is, the string "ABCD ")
The first few bytes of the rarfile are 52 61 72 21 // string Rar! Hexadecimal
The first 4 bytes of the encrypted file must be 55, 7, 21, and 66.
Without knowing the password ("ABCD"), the decrypted user can obtain the password value through the fixed first 4 bytes of the original data.
Specific Operation: 0x52 ^ 0x55
0x7 ^ 0x61
0x21 ^ 0x72
0x66 ^ 0x21
The result is {0x65, 0x66, 0x67, 0x68} (the string "ABCD ")
Of course, there are many restrictions. For example, for plain text txt, the original file does not have header information, so it cannot be cracked.
The attack here is a simple encryption, and the password length is 4 characters. however, for a rarfile, the first 20 bytes are known. You can enumerate a limited number of possible results for semi-guessing and semi-decoding. the other several bytes are of the same fixed file type. although increasing the encryption strength can increase the difficulty of cracking, it only increases the time of the attacker.
There are many ways to avoid such security risks. The simplest is to not encrypt the known bytes (for rarfile, the first 20 bytes are not encrypted ). in this way, the decrypted cannot find clues.