XOR encryption with a short pad (i.e., shorter than the plaintext) is basically the Vigenère cipher. So standard techniques to break Vigenère should break xor encryption.
The basic idea is that if the encryption key is d symbols long, every d-th symbol is encrypted with the same pad. Thus, take every d-th ciphertext symbol and treat it like simple ...
In case of multibyte XOR frequency analysis is the way to go.
As is commonly known, most frequent character in regular English text is E (etaoinshrdlu being the top 12) but in some cases space (0x20 in ascii) can be more frequent, especially in shorter messages.
For executable code on the other hand, tho I can't find a reference, most frequent characters ...
Just to add to the list. SANS posted a blog about a week ago on different tools for XOR encryption. The list is very good and it provides several tools, all which are good in my opinion.
Here is the link : SANS Blog on XOR tools
Good news, You're lucky!
What you're facing in front of you is a stream cipher. Why is that good? because the way stream ciphers are built makes them extremely easy to reverse - the decryption and encryption functions of stream ciphers are actually the same function.
A stream cipher is a symmetric key cipher where plaintext digits are combined with a ...
I found a full analysis of the cipher algorithm of CTB-Locker performed by Zairon.
He's not really optimistic about the possibility to cryptanalyse the files as the first paragraph of the blog post is the following:
After my last post about CTB-Locker I received a lot of e-mails from people asking for a complete analysis of the malware. Most of them ...
Lots of possibilities, for all we know there's a chance that some "other" salt is used or that either the password or the salt or both are preprocessed in some way. Additionally there could be multiple rounds of hashing one of the combinations ...
So this question literally requires looking at the code and therefore reverse code engineering to give you more ...
The first byte is a simple checksum variant. In C:
uint8_t firstbyte( uint8_t const *data, size_t bytes )
for (sum = 0; bytes; --bytes)
sum -= *data++;
The second byte is a shift and add thing something like the BSD checksum:
uint8_t secondbyte( uint8_t const *data, size_t bytes )
In fact, there has been some works on trying to relate the actual complexity of a program before and after obfuscation and its difficulty to reverse.
The seminal paper about that is a technical report from Collberg et al. from 1997 . It defines a measure of potency to classify the different types of obfuscation and order them in terms of added ...