I received an interesting challenge today from my teacher(the problem can be solved). The only thing i have is a 1MB AES-encrypted file and i have to decrypt it and find some information within. I assume the mode used was ECB-128, because from what i read it is the only aes mode that can be cracked due to the repeated use of the same key, but i'm not sure if i'm on the right path. What is the best way to approach such a challenge?
EDIT: One of the hints we got is that the password contains "2014" either at the beginning or at the end of the key(not sure if it helps very much, the key space is still very big). But because the file is so large, i'm really thinking it could be an image, so i'll try reconstructing the header and reading the image, maybe i'll discover something.
In ECB mode, identical blocks of plaintext are encrypted to identical blocks of ciphertext. So typically you're looking for patterns of identical blocks of ciphertext (aligned to 16-byte boundaries). The ECB Penguin is probably the most famous demonstration of the problem and should point you in the right direction for exploring the data you have.
Related
I was hit by a ransomware infection that encrypts the first 512 bytes at the top of the file and puts them at the bottom. Upon looking at the encrypted text it seems to be some type of XOR cipher. I know the whole plain text of one of the files that was encrypted, so i figured in theory i should be able to xor it to get the key to decrypt the rest of my files. Well i am having a very hard time with this because i don't understand how the creator xor'ed it really. Im thinking he would use a binaryreader to read the first 512 bytes into an array, XOR it, and replace it. But does that mean he XOR'ed it in HEX? or Decimal? Im quite confused at this point, but i believe i am simply missing something.
I have tried Xor Tool with python, and everything it attempts to crack looks like non sense. I also tried a python script called Unxor that you give the known plain text to, but the dump file it outputs is always blank.
Good Header file dump:
Good-Header.bin
Encrypted Header file dump:
Enc-Header.bin
This may not be the best file example to see the XOR pattern, but its the only file i have that also has the original header 100% before encryption. In other headers where there is more changes the encrypted header changes with it.
Any advice on a method i should try, or application i should use to try and take this further? Thanks so much for your help!
P.S Stackoverflow yelled at me when i tried to post 4 links because im so new, so if you would rather see the hex dumps on pastebin than download the header files, please let me no. The files are in no way malicious, and are only the extracted 512 bytes and not a whole file.
To recover the keystream XOR the plaintext bytes with the cyphertext bytes. Do this with two different files so you can see if the ransomware is using the same keystream or a different keystream for each file.
If it is using the same keystream (unlikely) then your problem is solved. If the keystreams are different, then your easiest solution is to restore the affected files from backups. You did keep backups, didn't you? Alternatively research the particular infection you have got and see if anyone else has broken that particular variant, so you can derive the key(s) they used and hence regenerate the required keystreams.
If you have a lot of money then a data recovery firm might be able to help you, but they will certainly charge.
A rule of thumb to tell a decent cipher from a toy cipher is to encrypt a highly compressible file and try to compress it in its encrypted form: a dumb cipher will produce a file with a level of entropy similar to that of the original one, so the encrypted file will compress as well as the original one; on the other side, a good cipher (even without an initialization vector) will produce a file that will look like a random garbage and thus will not compress at all.
When I compressed your Enc-Header.bin of 512 bytes with PKZIP, the output was also 512 bytes, so the cipher is not as dumb as you expected — bad luck. (But it does not mean that the malware has no weak spots at all.)
I have some offline files that have to be password-protected. My strategy is as follows:
Cipher Algorithm: AES, 128-bit block, 256-bit key (PBKDF2-SHA-256
10000 iterations with a random salt stored plainly elsewhere)
Whole file is divided into pages with page size 1024 bytes
For a complete page, CBC is used
For an incomplete page,
Use CBC with cipher text stealing if it has at least one block
Use CTR if it has less one block
With this setup, we can keep the same file size
IV or nonce will be based on the salt and deterministic. Since this is not for network communication, I reckon we don't need to concern about replay attacks?
Question: Will this kind of mixing lower the security? Would we better off just use CTR throughout the whole file?
You're better off just using CTR for the entire file. Otherwise, you're adding a lot of extra work, in supporting multiple modes (CBC, CTR, and CTS) and determining which mode to use. It's not clear there's any value in doing so, since CTR is perfectly fine for encrypting a large amount of data.
Are you planning on reusing the same IV for each page? You should expand a bit on what you mean by a page, but I'd recommend unique IV's for each page. Are these pages addressable somehow? You might want to look into some of the new disk encryption modes for an idea on generating unique IV's
You also really need to MAC your data. In CTR for example, if someone flips a bit of the ciphertext, it'll flip the bit when you decrypt, and you'll never know it was tampered with. You can use HMAC or if you want to simplify your entire scheme, use AES GCM mode, which combines CTR for encryption and GMAC for integrity
There are a few things you need to know about CTR mode. After you know them all you could happily apply a stream cipher in your situation:
never ever reuse a data key with the same nonce;
above, not even in time;
be aware that CTR mode really shows the size of the encrypted data; always encrypting full blocks can hide this somewhat (in general a 1024 byte block takes as much as a single bit block if the file system boundaries are honored);
CTR mode in itself does not provide authentication (for completion, as this was already discussed);
If you don't keep to the first two rules, an attacker will immediately see the place of the edit and the attacker will be able to retrieve data directly related to the plain text.
On a possitive node:
you can happily use the offset (in, e.g., blocks) in the file to be part of the nonce;
it is very easy to seek in files, buffer ciphertext and create multi-threaded code around CTR.
And in general:
it pays off to use a data specific key specific sets of files, in such a way that if a key is compromised or changed that you don't have to re-encrypt everything;
think very well about how your keys are used, stored, backed up etc. Key management is the hardest part;
I'm implementing a web based file storage service (C#). The files will be encrypted when stored on the server, but the challenge is how to implement the decryption functionality.
The files can be of any size, from a few KB to several GB. The data transfer is done in chunks, so that the users download the data from say offset 50000, 75000 etc. This works fine for unencrypted files, but if encryption is used the entire file has to be decrypted before each chunk is read from the offset.
So, I am looking at how to solve this. My research so far shows that ECB and CBC can be used. ECB is the most basic (and most insecure), with each block encrypted separately. The way ECB works is pretty much what I am looking for, but security is a concern. CBC is similar, but you need the previous block decrypted before decrypting the current block. This is ok as long as the file is read from beginning to end, and you keep the data as you decrypt it on the server, but at the end of the day its not much better than decrypting the entire file server side before transferring.
Does anyone know of any other alternatives I should consider? I have no code at this point, because I am still only doing theoretical research.
Do not use ECB (Electronic Code Book). Any patterns in your plaintext will appear as patterns in the ciphertext. CBC (Cipher Block Chaining) has random read access (the calling code knows the key and the IV is the previous block's result) but writing a block requires rewriting all following blocks.
A better mode is Counter (CTR). In effect, each block uses the same key and the IV for each block is the sum of offset of that block from a defined start and an initial IV. For example, the IV for block n is IV + n. CTR mode is described in detail on page 15 in NIST SP800-38a. Guidance on key and IV derivation can be found in NIST SP800-108.
There are a few other similar modes such as (Galois Counter Mode) GCM.
I'm trying to reverse engineer a file from an application to learn more about the data it is storing on me. Based on the name, it appears to be XML data, but it is obviously either saved in binary or encrypted. I thought it may have been some form of .Net (or other) serialization, and have tried decoding it that way. But, no love. Inspection in hex has not given any clues either.
Maybe someone with more 'skilz' can give me some insight into it. Here is the file
Voted down and answering: the file is exactly N * 16 bytes in size, does not contain any repetition as far as I can see, and it seems to be filled with random bytes. The first bytes seems completely random as well, hinting that this is not a plain protocol.
This would probably hint that the file is AES CBC encrypted. DESede (or any cipher with a 8/16 blocksize) could of couse also have been deployed. Without the key (if any) this all is not going to help you much (if it was, I would not be answering you).
The entropy of first file is high above 7.7 that might indicate encryption. The first 28h bytes (320-bit) of the files match. Is that possible that's the key and the encoded data starts at 28h?
My php script and my c# application will pass a hash string to each other that is 32 chars long, what is the best mode for this? I thought ECB but am unsure as it says if using more then 1 block dont use. How do I know how big the block is?
They will occasionally pass a large text file, which would be the best mode for encrypting this...CBC?
Any good useful reads welcome...
Thanks
One problem of ECB (among many other problems) is that it encrypts deterministically. That is each time you encrypt the same ID, you get the same ciphertext. Thus this mode does not prevent traffic analysis. An attacker may not be able to learn the IDs that are encrypted. However, he can still determine when and how frequently the same ID is sent.
CBC and OFB when used properly use a new random IV for each encryption thus encrypting the same ID differently each time. Since you also make sure that all IDs have the same length the result should ciphertexts where the attacker cannot distinguish repeating IDs from non-repeating ones.
ECB is the simplest mode and really not recommended (it's not quite as secure as other modes).
Personally I'd use CBC.
In Addition to Accipitridae's Answer. You would need to supply the IV to the decryption procedure. That will also be a overhead in case of CBC or OFB.