Encryption Cracking - Given the algorithm & process hot to crack the the file

I have created a program for self-use now for some reason i need to crack it.
Here how the alogorithm works.
1. a key is created 128-bit to 1024-bit long random (signed chars)
2. file is signed Md5 for consistency check when decrypted
3.the algorithm goes as follows

pseudo_code
while( filedata )
{
ReadFileData --> buffer
for( int index = 0 ; index < dataread ; index++ )
{
     for( int keyindex =0 ; keyindex < keysize ; keyindex++ )
     {
         buffer[index] XOR key[keyindex];
         key[keyindex]++;
     }
}
write_to_file( buffer );
} //end of read buffer

the key is stored in the middle of the file with the users password the same algorithm as abow just the key in this case is the password and the buffer is the starting key.


now to the cracking
since we know cerain file markers like jpg ( 0xff 0xd8 ) or .exe (MZ) how would someone crack it.
I'm unable to brake it.

any suggestions?

 

 

 

Comment/Reply (w/o sign-up)

here is an ecrypted file of this image gif


result is binary therefore here is a hex dump followed by some prinable binary data
2e 73 67 65 7c 32 7c 31 36 7c 61 31 34 30 61 35 38 64 35 66 32 63 39 31 37 31 64 65 63 30 66 33 35 38 32 66 65 37 35 37 30 66 7c 23 70 82 8d ef e6 ba cf 3f 63 7b 9d 6d 0f f4 ee 2d e9 ee 29 0b 5e 9b 45 3b f6 2a 14 ad b5 96 54 b6 ac 54 e9 cf 23 86 86 a7 d3 de d8 f8 c3 12 6e 5f 0a f6 e9 16 10 09 0f 36 15 cd 35 06 3d 39 1a d4 a5 ce 28 a1 88 46 ae e9 ea 0b 35 0d ed bc 19 e4 d1 1c 73 10 83 5e 07 4b b1 e7 4f d5 82 d2 94 86 e3 68 52 a9 0a 7a d0 8a 54 0d e3 cf de aa 9d 75 c6 c4 ce d2 c4 6f af 8d 9e c5 2d 7d 38 2d 71 ab 8d df 09 73 ca 7f 58 30 e5 09 77 ca a0 1b b5 9f 1c b6 87 fe 6d 6b 7c b6 9a d3 02 1b 5f 85 d2 46 a9 e4 5b e3 d2 55 c0 0f 30 9a ac 6c a2 76 0c a2 98 19 84 5a f5 5c 65 5b 09 6b cb 11 70 dd 1b 54 3d ac 8f 4f 24 31 1b 98 7d ea 10 d2 18 d2 ac 02 da 91 00 ac 11 ab 68 ef 42 c1 25 a7 74 41 c2 01 6a c0 22 10 c6 41 b4 f8 58 6f 32 84 89 6e e4 fd e4 82 6f 30 bf e9 70 e9 d8 55 8c a1 80 d0 3a 48 e5 79 dd 75 a3 d0 16 95 63 94 aa 0b d7 dc db 7d 48 3a ef 4b a9 57 72 c6 be 8f fb 6f f8 5c 27 01 70 9e e9 5b 8f 95 9f 12 67 33 9e 8c 8e 67 58 05 71 5b 17 4f 99 c0 5d 5d da bc 88 e9 21 07 d1 10 85 5a 24 01 55 eb c8 2d 8d 92 c4 c9 be 1b 62 5a 37 de df bb 4c 6f a6 f7 d1 54 83 10 c2 0e 2c 72 a1 22 e8 9a 85 2e 99 c7 0c ce 39 69 bc 1f 18 05 23 54 c0 bf 94 d3 39 48 24 51 6b 1e 90 9e 73 7c 76 38 48 03 6f 83 a0 41 a8 bd 79 82 b6 b6 4b 4f 37 cb cb d7 df db db 3f 77 7b 7b 17 0f 2a f2 0b 16 0b 0b 8d bf 97 bb df d7 db cf b7 5b 4b 4b 48 88 cb 31 d5 dc df de f9 b3 36 57 2f 32 11 11 66 48 7b 06 b0 7d f2 fc bf e9 8a be af 9c e3 bf c8 3e cc 54 49 1b 0f 23 3a f2 83 e8 03 58 22 15 10 92 03 60 50 c7 b9 b8 5e 56 58 59 cf df c5 f9 96 ff 48 80 9d b7 dd d7 ff 4e f3 42 17 03 0d 0f 16 45 1a 04 b5 52 1c 16 5d 90 2c 92 00 4f 49 59 59 75 95 ea 55 eb ed a3 3c bf a2 93 6e 0c 73 01 1a 33 2b 89 e0 e5 be ba 35 3d da de b3 69 06 5c cd 7c 0c a1 72 44 c3 7c a0 09 18 30 e9 fe 3b 4c 3f 0e 30 0e 44 7d df 2f ac b6 53 5f 9c c2 72 b2 9c f4 09 c7 77 4f 35 53 2b cc 6d 97 4e bc 07 4b af c3 1a 1f 55 36 b5 b3 eb 3b ba 49 d7 4f 9c 47 d2 ac 71 c3 ad cf ba 57 fc 3d 28 cb cb 16 a1 c1 8e 8e 05 38 95 72 39 3b 99 5e dd 44 7d 47 5b 1b 2f 36 48 41 d9 ea 19 db 1c 23 be b5 9a 18 1e 4f 87 bf 9b e8 fa b3 9d ed 41 cb 71 3f 35 8b 41 65 3e 60 c1 6b c6 ac 32 c9 e1 31 18 03 83 d7 bb aa 0b 90 1a 99 db f5 d5 ef d7 d7 e0

.sge|2|16|a140a58d5f2c9171dec0f3582fe7570f|#p�����?c{�m��-��)^�E;�*���T��T��#��������n_
�� 6�5=9ԥ�(��F���5
����s�^K��OՂ�"��hR�
zЊT
��ު�u�����o����-}8-q��� s�X0� w� �����mk|���_��F��[��U�0��l�v���Z�\e[ k�p�T=��O$1�}��Ҭ�'


the key size is given in the 3rd place after .sge|2|16 16 being 16 bytes long 128-bit the key itself is stored in the middle of the file - recordsize and the key is encrypted with the password 'password'
thought this might help someone analyze it in more details
the md5 hash value is the md5 hash of the decrypted file.
the 2 stands for the version of the program nothing else.
the # stands for end of header the actual encrypted data starts after # the record

 

 

 

Comment/Reply (w/o sign-up)

Crypto is a very nasty and complex beast. I would never trust data to an algorithm that I created myself. Computer history is scattered with the tales of encryption gone wrong, WEP is a good example of this.

From my understanding, using an XOR is actually a really good method of encrypting data as long as the key is cryptographically strong. The de facto method of breaking any encryption scheme is using brute force methods. This is trying every possible key combination and then checking the result with known good plaintext. Brute force can take a long long long long time to complete depending on how long the key is and which encryption scheme you use. A key that is 20 or so characters can be broken in a matter of hours to weeks. Anything over 50 or so could take years.

One disadvantage to using XOR is the speed it takes to reverse the encryption. XOR is a single operation so checking one brute force attempt will take no time at all. AES in comparison has thousands of operations so checking one brute force attempt will take thousands of times longer. If you have a very determined attacker, they could even design special hardware to blow through XORs at an even higher rate. DES was considered secure until a group designed special hardware that dropped the brute force rate from years to days.

The next attack vector is the key. I will assume that you are using alpha, numeric, and symbols that can be typed on the keyboard. Given you are using ASCII; the characters that are typeable are only a small portion of the possible ASCII set. You are missing over 75% of the possible characters. I would then design a brute force attack that only tried typeable characters which would cut my time down by no less than 75%.

There are still other attacks such as using a dictionary (I assume you are not silly enough to use a password from a dictionary so I decided to skip this) or using language heuristics (http://web.cecs.pdx.edu/~bart/decrypter/paper.pdf).

The underlying question is this. Why are you trying to reinvent the wheel when you have AES and other tested ciphers at your disposal? They have been shown to withstand a torrent of attacks from people much smart than myself and they are still standing. Your method may work but I wouldn�t risk it.

Comment/Reply (w/o sign-up)

I'm not trying to re-invent anything . this program was for self-use nothing more.
The advantages of specialized software are many.
1. No one has the algorithm. (until now)
2. No one knows the file structure.(until now)
3. it's simple yet effective

The generated key contrary to your assumtion is randomly generated binary not ascii chars. and that key is then is locked with the password ascii.

I'm trying to get some help cracking it. I tried to analize the rate of change of the key (as you can see the key is constantly changing) unsuccessfuly. bruteforce in this case does not work because it's simply to slow. to ckeck if a certain key is it, you need to process the entire file(slow).

The only way i think must be to derive a mathematical function wich mimics the rate of change of the key itself. you can extract the entire key into one char by xor'ing the file marker with the encrypted data. That way you get the entire key compacted in to 8-bits and then you get the second permutation of the key by doing the same thing with the secod filemarker.
But it did not help me anything.
Therefore here i am.

Comment/Reply (w/o sign-up)